Airflow com Alta Disponibilidade e Escalabilidade no Amazon ECS
Que tal fazer o deploy do Airflow 2.0 com alta disponibilidade e escalabilidade para o seu ambiente de Big Data que está em constante crescimento?
Não conhece o Airflow ainda? Caso queira saber mais sobre e até um case real de utilização, recomendo a leitura deste artigo.
O Airflow atualmente é umas das principais ferramentas que compõem um ambiente de Big Data.
A capacidade de controlar cargas de dados de ponta a ponta é essencial para automatizar tarefas e manter a governança do ambiente de dados. Isso o Airflow entrega com excelência.
No momento da escrita deste artigo o Airflow está em alguma versão derivada da sua versão 2.0, com uma comunidade bem engajada, onde novas correções e melhorias são lançadas com frequência.
Tendo em mente esses conceitos, oobjetivo deste artigo é mostrar o caminho para se realizar deploy do Airflow 2.1.3 no Amazon ECS.
O repositório contendo o código completo utilizado aqui pode ser acessado no link abaixo:
Qual problema iremos resolver?
O cenário para este artigo é algo muito comum em Big Data, imagine a seguinte situação:
Uma certa empresa possui um Data Lake contendo alguns dados cuja origem é seu ERP, porém surgiram novas demandas e será necessário realizar a integração de outras fontes de dados como CRM, API e Redes Sociais.
As cargas de dados já são controladas pelo Airflow, atualmente com deploy em apenas uma máquina. Porém o mesmo está instável, apresentando indisponibilidade pela adição de várias cargas em paralelo. Com isso todas as cargas de dados estão sendo prejudicadas.
Pensando no problema destacado no cenário acima, podemos observar algumas soluções:
- Escalar a atual arquitetura do Airflow, aumentando os recursos como memória e CPU da máquina atual;
- Adicionar o processamento das cargas para serem executadas fora da máquina do Airflow;
- Mudar a arquitetura do Airflow para ser totalmente distribuída;
Todas as alternativas listadas possuem prós e contras, além de existirem outras, são algumas soluções apenas para ilustrar o cenário.
Neste artigo vamos abordar a solução de número 3, pois com ela podemos:
- aproveitar o máximo da arquitetura distribuída do Airflow;
- ter o processamento das cargas de dados sendo executadas fora dos componentes principais do Airflow.
- escalar o Airflow de forma separada, aumentando o recurso de componentes que realmente precisam dessa ação.
- Entre outros benefícios.
[Spin-off] Experiências pessoais
Já participei de diversos projetos utilizando o Airflow como principal ferramenta para Orquestração das pipelines de dados.
Dentre esses projetos sempre temos algo em comum, algumas pipelines fazem processamento dentro da própria máquina do Airflow, por questão de simplicidade e facilidade, outras pipelines executam o processamento fora do Airflow, utilizando o Spark por exemplo.
Quando o Airflow possui apenas uma máquina e temos alguns processamentos sendo realizados na própria máquina do Airflow, isso pode virar um caos, pois a medida que são criadas mais pipelines, é necessário escalar a máquina em relação a CPU e memória, armazenamento (principalmente por causa de logs e dados salvos de forma intermediária), além de gastar muito esforço na manutenção da máquina, com scripts de limpeza, monitoramento e por aí vai…Ainda temos as indisponibilidades que podem acontecer com frequência.
Ou seja, esse modelo funciona muito bem, se o ambiente permanecer pequeno.
O outro cenário que mencionei é ter apenas uma máquina mas jogar todo o processamento das pipelines fora do Airflow. Esse modelo é mais escalável, porém na medida que aumenta a utilização do Airflow, principalmente com vários projetos e áreas diferentes utilizando, iremos cair no mesmo problema anterior, precisando escalar a máquina para manter o desempenho.
Das experiências que tive, o melhor modelo foi o deploy do Airflow de forma distribuída, isolando todos os componentes e até a questão de logs ser armazenado em outro serviço, como o Cloud Watch.
Podemos até fazer a questão distribuída utilizando máquinas simples, como uma EC2, porém utilizar um serviço especializado para isso como o ECS é outro nível.
Até aquelas tasks mais simples, que antes executavam na máquina do Airflow, podem executar em um contêiner separado dentro do mesmo cluster. Inicialmente pode trazer uma complexidade para o desenvolvimento, mas depois de padronizar, fica muito simples.
Isso é um pouco das experiências que tive até o momento, agora vamos voltar para o artigo.
Componentes do Airflow
Antes de entrarmos na solução em si, vamos entender um pouco mais sobre a arquitetura do Airflow.
O Airflow é um sistema distribuído, construído com base em micro serviços, assim podemos realizar o seu deploy aproveitando o máximo dessa arquitetura, garantindo alta disponibilidade e também escalabilidade.
Os componentes do Airflow são os seguintes:
- Webserver: é o serviço responsável por manter a interface gráfica do Airflow (UI) acessível;
- Scheduler: é o serviço responsável por controlar o agendamento das DAGs no Airflow e notificar quando elas devem ser executadas.
- Workers: serviço responsável pela execução, controle e monitoramento das DAGs e suas tarefas de ponta a ponta.
- Flower: serviço que funciona como um canal de mensagens, que faz o intermédio entre scheduler e works, colocando na fila quais DAGs devem ser executadas;
- Metadata DB: banco de dados para gravar e consultar metadados de todo o ambiente do Airflow.
Arquitetura proposta para a solução
O desenho de arquitetura para referência neste artigo ficou da seguinte maneira:
Assim podemos destacar os seguintes pontos:
- Todos os serviços do Airflow serão executados dentro do ECS em contêineres separados.
- Para que a solução fique ainda mais desacoplada e escalável, iremos utilizar os serviços RDS para banco de dados e Elastic Cache para troca de mensagens (Flower) entre os serviços do Airflow.
- As DAGs serão armazenadas no S3 e depois sincronizadas para dentro do Airflow e posteriormente armazenadas dentro do EFS para que todos os contêineres tenham acesso aos arquivos.
- Ao acessar a UI do Airflow, o serviço de entrada será o ELB que faz o balanceamento de carga e direcionamento para o serviço de Web Server do Airflow.
- Por fim, todo o deploy do Airflow será baseado em Infra as Code com o Terraform.
Sobre o Amazon ECS
O Elastic Container Service ou simplesmente ECS, é um serviço da AWS para gerenciamento de contêineres, que é altamente rápido e escalável.
Com ele conseguimos executar aplicações e cargas de trabalho através de contêineres, o que permite gerenciar custos de forma mais eficiente.
A alocação de recursos no ECS é baseada em alocação de memória ram e CPU para executar tarefas e podem ser dinâmicos. O custo é gerado apenas pelo tempo de execução das tarefas.
O ECS possui duas formas de executar contêineres:
- EC2: executar as tarefas dentro de uma EC2 que será gerenciada pelo ECS.
- Fargate: executar o ECS de forma serverless utilizando o Fargate, que é o sistema gerenciado de contêineres da AWS.
Outro conceito importante do ECS são as Task e os Service:
- Task: é uma tarefa que será executada através de um contêineres, a vida útil de uma task é a execução de uma carga de trabalho.
- Service: é uma forma de gerenciar as tasks, controlando e garantindo uma quantidade mínima de contêineres que uma task deve ter em execução.
Ainda podemos destacar o ECR (Elastic Container Repository) que é o serviço para armazenar imagens Docker compiladas dentro da AWS. Ele é integrado ao ECS, porém pode ser utilizado por outros serviços como o Lambda.
Neste artigo iremos utilizar o Fargate, Taks e Services para executar os componentes do Airflow.
Deploy do Airflow no ECS
1. Um Pouco mais sobre os serviços utilizados na AWS
Tendo a arquitetura em mente e indo além do ECS, iremos utilizar os seguintes serviços na AWS:
- EFS: Elastic File System é o sistema de arquivo distribuído da AWS, onde é possível compartilhar o armazenamento de dados através de pontos montados pela rede. O EFS é utilizado para armazenar as DAGs e compartilhar os dados entre os contêineres.
- ELB: Elastic Load Balance é o serviço para balanceamento de carga na AWS, ele será responsável por encaminhar as requisições para a UI do Airflow no servidor Web.
- Elastic Cache com Redis: o Redis será o responsável por gerenciar a troca de mensagens entre schedule e workers. O serviço do Airflow Flower é o responsável por gerenciar as mensagens no Redis.
- Cloud Watch Logs: é o serviço responsável por armazenar todos os logs do Airflow, tanto dos serviços quanto das tasks em execução.
- RDS: é o serviço de banco de dados gerenciado da AWS, iremos utilizar uma instância PostgreSQL para armazenar os metadados do Airflow.
2. Imagens do Docker
Como o deploy será realizado no ECS, precisamos estruturar a imagem Docker que será executada.
Um ponto importante é que iremos utilizar apenas uma imagem Docker do Airflow e assim subir cada um dos serviços mencionados anteriormente em contêineres separados através dela.
Ainda é importante destacar que a imagem Docker será armazenada no Amazon ECR para depois ser utilizada pelo ECS.
Abaixo temos o código utilizado para a imagem Docker do Airflow na versão 2.1.3.
Podemos destacar nessa imagem Docker o ENTRYPOINT, pois é ele quem dirá qual o serviço será executado em cada um dos contêineres a serem executados no ECS.
Abaixo temos o script do ENTRYPOINT que se trata de um shell script armazenado dentro da imagem Docker. No momento da inicialização de cada contêiner ele será chamado e executado conforme parâmetros recebidos.
Podemos verificar que temos a distinção de comandos a serem executados dependendo do serviço, ou seja, se for o webserver é um comando, o worker tem outro comando e assim por diante.
Este comando será definido e enviado a partir do Terraform, conforme veremos a seguir.
3. Componentes no Terraform
Como mencionado, todo o deploy do projeto está baseado em Terraform, assim precisamos entender os principais arquivos que compõem a infraestrutura:
- airflow_flower.tf: contém as configurações para execução do contêiner com o flower do Airflow.
- airflow_scheduler.tf: contém as configurações para execução do contêiner com o scheduler do Airflow.
- airflow_web_server.tf: contém as configurações para execução do contêiner com o webserver do Airflow.
- airflow_workers.tf: contém as configurações para execução do contêiner com o woker do Airflow.
- ecs_services.tf: contém as configurações para a execução de todos os services do Airflow. É possível definir a quantidade de contêineres que serão executados para cada service.
Os arquivos que provisionam os serviços do Airflow utilizam-se de um template com o nome airflow_service.json, nele são passados alguns parâmetros importantes, inclusive o command que será direcionado ao ENTRYPOINT visto anteriormente, que indica qual serviço será executado naquele contêiner.
Ainda podemos destacar a parte do código abaixo que é comum para todos os serviços:
O principal ponto a ser considerado aqui são os parâmetros cpu e memory que definem os recursos computacionais a serem considerados por cada contêiner a executar um componente do Airflow. Para saber mais sobre configurações de memória e CPU essa documentação pode ser acessada.
4. Deploy do Airflow
Como o projeto está baseado em Terraform, o deploy pode ser realizado de diversas formas, como por exemplo através de um CI/CD no github, gitlab ou outro.
Porém, caso queira testar rodando a partir do seu computador, no repositório possui um script que facilita esse processo.
O script shell abaixo realiza a deploy do projeto em Terraform, faz o build da imagem Docker e envia para o ECR.
Assim basta executar o script com as devidas credenciais da AWS configuradas que o Airflow começará a executar de forma automática no ECS.
Porém antes de executar o script, é necessário exportar as seguintes variáveis de ambientes no terminal:
export AWS_ACCOUNT=xxxxxxxxxxxxx
export AWS_DEFAULT_REGION=us-east-1Após isso é só executar o script:
bash scripts/deploy.sh airflow-devPS: o parâmetro com nome airflow-dev será o nome da imagem Docker a ser enviada para o ECR.
5. Execução do Airflow
Depois de realizar o deploy do Airflow no ECS podemos verificar os componentes que foram criados na AWS e a aplicação em execução.
A imagem abaixo mostra o cluster do ECS que foi criado com o nome airflow-dev.
A seguir temos os services que foram criados, ao todo são quatro que correspondem aos componentes do Airflow.
Lembrando que os services garantem a disponibilidade e escalabilidade das aplicações.
A seguir temos as tasks sendo executadas conforme a definição do services, são duas para o worker e uma para os demais componentes do Airflow.
A seguir o Load Balance criado para o Airflow e que está vinculado ao service de webserver.
Acessando o link disponibilizado pelo Load Balance, temos a Interface do Airflow em execução.
Inclusive com a DAG em execução que faz a sincronização dos arquivos armazenados no S3 para o Airflow (EFS).
Considerações Finais
Alguns pontos que podemos destacar sobre esse projeto e possíveis melhorias futuras.
- Como as DAGs que serão adicionadas ao Airflow serão armazenadas inicialmente no S3, a organização do bucket pode ser por projetos, tornando o Airflow uma aplicação centralizadora para Orquestração de cargas de Big Data.
- O ECS é um bom serviço para deploy de aplicações distribuídas baseadas em contêineres igual o Airflow, porém caso queira um autogerenciamento maior e escalabilidade de forma mais natural, o Kubernetes é o indicado, assim o AWS EKS seria um serviço a se avaliar.
- O repositório desse projeto é um fork com mudança de arquitetura e melhorias de outro repositório que implementa a versão 1.0 do Airflow. Assim caso queira contribuir fique a vontade, pois ainda tem espaço para melhorias como: adicionar fluxo de CI/CD, melhorias no Terraform e outros pontos.
Conclusão
O Airflow é uma ferramenta muito útil na stack de aplicações para Big Data, por isso possuir um ambiente que suporte o crescimento da área de forma escalável pode facilitar a investidas em novos projetos.
Sempre é importante destacar que há prós e contras nas decisões de arquitetura que tomamos, assim o ECS também pode trazer custos e complexidades indesejadas, que devem ser analisadas.
Importante é avaliar o momento da sua equipe, perspectiva de crescimento da área, esforço e tempo disponível para construir e manter a solução, entre outros pontos.
Porém fica a dica e o conhecimento de uma das formas de realizar deploy do Airflow com alta disponibilidade e escalabilidade.
