AWS Step Functions para gerenciamento de Cluster EMR

Bem, 2019 foi um ano de muitos desafios e desses desafios houveram alguns que foram divertidos de serem enfrentados e superados. Um deles foi: Como provisionar um EMR cluster na AWS e submeter um job, que seja efêmero e monitorável? Como checar o status do job e executar um terminate no cluster ao concluir este job?

Analisando alternativas, optamos pelo uso do serviço AWS Step Functions, onde podemos modelar uma “máquina de estados” para expressar o ciclo completo da execução, transitando pelas etapas e levando informações relevantes de etapas anteriores para subsequentes, com maior controle e visão da execução.

O Step Functions pode expressar visualmente a máquina de estados

Para esse exercício, vamos usar o nome de “Cluster Manager” para nos referirmos a esta state machine, designada a monitorar o estado de um EMR cluster. Abaixo, vamos falar um pouco mais sobre cada etapa ou task dessa state machine.

CreateAndSubmit:

Esta task é suportada por uma função AWS Lambda que utiliza a biblioteca boto3 para criar um EMR cluster e, em seguida, submeter um job flow seguindo o contrato da API e seu detalhamento. É possível personalizar a necessidade de provisionamento das máquinas, os jobs a serem executados, os argumentos a serem passados ao job, etc.

WatchAndDestroy:

Nesta segunda etapa (também suportada por uma função AWS Lambda), após o EMR cluster ter sido criado, o boto3 retorna um cluster ID único, que baseia todo o monitoramento da execução. É possível listar todos os steps submetidos ao cluster e checar seus status atuais. Observamos apenas o status do primeiro STEP recebido, pois apenas é submetida uma única tarefa ao cluster.

ChoiceState:

Nesta etapa, a state machine pode consumir os resultados da etapa anterior para implementar uma tomada de decisão. No nosso caso, se o dado recebido aqui for COMPLETED, a execução da state machine será marcada como Sucesso. Se o EMR step estiver em “Running”, a execução da state machine segue a uma etapa do tipo Wait chamado “RetryWatchAndDestroy”, que segura a transição de estados por um tempo determinado e devolve a execução novamente para a etapa “WatchAndDestroy” da state machine. Caso o EMR step não estiver marcado como COMPLETED ou RUNNING, a state machine falha totalmente.

Monitoramento:

É possível monitorar a state machine, adicionando um alarme do AWS Cloudwatch com métricas de falhas para observar. Ao ocorrer uma falha, nosso alarme envia uma mensagem para um tópico AWS SNS e este por fim pode ser consumido. Como exemplo, utilizamos uma função AWS Lambda que captura a mensagem postada no SNS e envia um detalhamento a um canal do Slack.

Como utilizar:

Existe uma função Lambda chamada Integration, que recebe como input as configurações para criação do cluster EMR e execução de um job-flow no EMR, através da state machine “Cluster Manager”. Esta função pode ser integrada a uma outra State Machine e seu output servir de input para o “Cluster Manager”.

Exemplo

No repositório do GitHub do projeto, existe um exemplo de execução, utilizando um pyspark job para wordcount.

Datenworks/cluster-manager-emr

Requisitos

• Make
• python 3+
• pyenv
• pipenv
• Serverless Framework
• aws-cli (E acesso a uma conta AWS)
• Terraform

Para clonar o repositório:

git clone git@github.com:Datenworks/cluster-manager-emr.git
cd cluster-manager-emr

Precisamos utilizar um plugin do Serverless para gerenciar as dependências do python:

serverless plugin install --name serverless-python-requirements

Após a instalação, podemos executar o deploy das funções Lambda utilizadas pela state machine na conta da AWS

make ENV=dev \
    deploy

No repositório, existe um script Terraform para provisionar os recursos necessários, como criar a state machine, as IAM roles para o EMR, um alarme no CloudWatch para monitorar falhas de execuções, e um tópico SNS para receber as mensagens do alarme

cd terraform/base
terraform init
terraform plan
terraform apply
cd ../../

Pronto! Provisionamos os recursos na AWS necessários para utilizarmos o “Cluster Manager”

Para testar, devemos efetuar o deploy do script de WordCount em um bucket no S3

make EXAMPLE_BUCKET="name-of-example-bucket" \
    deploy-word-count

Após efetuar o deploy do script, vá até a seção das Step Functions na AWS, localize a state machine pelo nome de “cluster-manager-sfn” e inicie uma nova execução com o seguinte payload:

{
    "data":{
        "name": "wordcount",
        "resource": "resource-name",
        "namespace": "wordcount",
        "arguments": [
            {
                "argument": "input_bucket",
                "value": "your-bucket-pyspark-example"
            },
            {
                "argument": "output_bucket",
                "value": "your-bucket-example"
            },
            {
                "argument": "key_path",
                "value": "dataset/lorem.txt"
            }
        ],
        "code_files": "s3://your-pyspark-bucket-example/pyspark/wordcount.py",
        "entrypoint": "s3://your-pyspark-bucket-example/pyspark/wordcount.py",
        "mem_executor": "8G",
        "mem_driver": "4G",
        "master_type": "m5.xlarge",
        "count": "3",
        "slave_type": "m5.2xlarge",
        "release": "emr-5.28.0",
        "region": "us-east-1",
        "log_bucket": "your-log-bukcket-uri",
        "subnet": "your-subnet-id",
        "spark_packages": [""]
    }
}

Após alguns minutos, enquanto o cluster EMR é provisionado, o step começará a ser executado, e por fim completo ou com falhas (onde gerará um alarme), o cluster será encerrado.

Conclusões

A AWS recentemente publicou uma novidade no Step Functions, onde agora é possível provisionar um cluster EMR e submeter steps. Fizemos alguns testes e parece fazer um bom trabalho, porém ainda existe uma certa complexidade na declaração de state machines, que demanda algumas informações hard coded a serem passadas na sua definição, exigindo em alguns cenários que sejam definidas várias state machines para realizar o trabalho de uma única state machine.

Desenvolvemos este componente para que fosse genérico ao ponto de ser possível submeter steps de natureza diferente e de fácil configuração. Como próximos passos do projeto, gostaríamos de adicionar e gerenciar um número maior de steps no cluster EMR, criando assim um fluxo mais complexo. A oportunidade de aprender a usar estes e outros componentes da AWS nestes últimos meses, sem ter tido algum tipo de experiência prévia, foi desafiador e divertido, as maiores dificuldades foram entender tais recursos do cloud e como utilizar e provisionar estes recursos via SERVERLESS FRAMEWORK e TERRAFORM, que são duas ferramentas incríveis para se trabalhar em cloud.

Muito obrigado e até a próxima.

My LinkedIn: https://www.linkedin.com/in/richardcruzlopes/

Datenworks Linkedin: https://www.linkedin.com/company/datenworks/