Este é um put up convidado co -autor do LaunchDarkly.
O LaunchDarkly A plataforma de gerenciamento de recursos equipa as equipes de software program para reduzir proativamente o risco de enviar software program ruim e aplicativos de IA enquanto acelera sua velocidade de liberação. Neste put up, exploramos como o LaunchDarkly escalou a plataforma de análise interna até 14.000 tarefas por dia, com um aumento mínimo de custos, depois de migrar de outra solução de fluxo de ar Apache gerenciado pelo fornecedor para a AWS, usando Fluxos de trabalho gerenciados pela Amazon para fluxo de ar Apache (Amazon mwaa) e Serviço de contêiner elástico da Amazon (Amazon ECS). Nós o guiamos pelos problemas que encontramos durante a migração, a solução técnica que implementamos, as trocas que fizemos e lições que aprendemos ao longo do caminho.
O desafio
O LaunchDarkly tem a missão de permitir que as equipes de alta velocidade liberem, monitorem e otimizem o software program em produção. A equipe de dados centralizada é responsável por rastrear como o LaunchDarkly está progredindo em direção a essa missão. Além disso, essa equipe é responsável pela maioria das necessidades de dados internos da empresa, que incluem ingestão, armazenamento e relatórios sobre os dados da empresa. Alguns dos grandes conjuntos de dados que gerenciamos incluem uso de produtos, envolvimento do cliente, receita e dados de advertising and marketing.
À medida que a empresa aumentava, nosso quantity de dados aumentou e os casos de complexidade e uso de nossas cargas de trabalho se expandiram exponencialmente. Ao usar outras soluções baseadas em fluxo de ar gerenciadas pelo fornecedor, nossa equipe de análise de dados enfrentou novos desafios a tempo de integrar e integrar novos serviços da AWS, localidade de dados e uma solução de orquestração e monitoramento não centralizada em diferentes equipes de engenharia da organização.
Visão geral da solução
O LaunchDarkly tem uma longa história de uso de serviços da AWS para resolver casos de uso de negócios, como Escalando nossa ingestão de 1 TB para 100 TB por dia com fluxos de dados da Amazon Kinesis. Da mesma forma, a migração para a Amazon MWAA nos ajudou a dimensionar e otimizar nossos pipelines de extrato, transformação e carga internos (ETL). Utilizamos o monitoramento e a infraestrutura existentes como implementações de código (IAC) e, eventualmente, estendemos a Amazon MWAA a outras equipes, estabelecendo -a como uma solução de processamento de lote centralizada que orquestra vários serviços da AWS.
A solução para nossos trabalhos de transformação inclui os seguintes componentes:
Nosso plano authentic para a migração da Amazon Mwaa foi:
- Crie uma nova instância do Amazon MWAA usando o Terraform após os padrões de serviço do LaunchDarkly.
- Levante e mude (ou re -roste) Nossa base de código do fluxo de ar 1.12 para o fluxo de ar 2.5.1 no provedor de nuvem authentic para a mesma versão na Amazon MWAA.
- Cortar tudo Gráfico acíclico direcionado (DAG) corre para a AWS.
- Atualize para o fluxo de ar 2.
- Com a flexibilidade e facilidade de integração no ecossistema da AWS, faz aprimoramentos iterativamente em torno da contêinerização, registro e implantação contínua.
As etapas 1 e 2 foram executadas rapidamente – usamos o Provedor de Terraform AWS e a infraestrutura de Terraforma de Launchdarkly existente para criar um módulo Amazon MWAA reutilizável inicialmente no Airflow versão 1.12. Tivemos uma instância da Amazon Mwaa e as peças de apoio (CloudWatch e Artifacts S3 Bucket) rodando na AWS dentro de uma semana.
Quando começamos a cortar DAGs para a Amazon Mwaa na Etapa 3, encontramos alguns problemas. No momento da migração, nossa base de código de ar estava centrada em torno de uma implementação de operador personalizado que criou um Ambiente Digital Python Para nossos requisitos de carga de trabalho no disco do funcionário do fluxo de ar atribuído à tarefa. Por tentativa e erro em nossa tentativa de migração, aprendemos que esse operador personalizado dependia essencialmente do comportamento e do isolamento dos executores de Kubernetes do Airflow usados na plataforma authentic do fornecedor de nuvem. Quando começamos a executar nossos DAGs simultaneamente na Amazon Mwaa (que usa Executor de aipo Trabalhadores que se comportam de maneira diferente), encontramos alguns problemas transitórios em que o comportamento desse operador personalizado pode afetar outros DAGs em execução.
Nesse momento, demos um passo atrás e avaliamos soluções para promover o isolamento entre nossas tarefas de corrida, eventualmente aterrissando Fargate para tarefas de ECS Isso poderia ser iniciado na Amazon Mwaa. Inicialmente, tínhamos planejado mover nossas tarefas para seu próprio sistema isolado, em vez de fazê -las correr diretamente no ambiente de tempo de execução do Python do Airflow. Devido às circunstâncias, decidimos avançar nesse requisito, transformando nosso projeto de renovação em uma migração de refatoração.
Escolhemos a Amazon ECS em Fargate por sua facilidade de uso, Integrações de fluxo de ar existentes (EcsruntaskOperator), baixo custo e menor sobrecarga de gerenciamento em comparação com uma solução baseada em Kubernetes, como Amazon Elastic Kubernetes Service (Amazon EKS). Embora uma solução usando o Amazon EKS melhorasse ainda mais o tempo de provisionamento de tarefas, a solução Amazon ECS atendeu aos requisitos de latência dos pipelines de lote da equipe de análise de dados. Isso foi aceitável porque essas consultas são executadas por vários minutos periodicamente; portanto, mais alguns minutos para aumentar cada tarefa do ECS não afetaram significativamente o desempenho geral.
Nossa primeira implementação da Amazon ECS envolveu um único contêiner que baixa nosso projeto de um repositório de artefatos na Amazon S3 e executa o comando passado para a tarefa ECS. Nós acionamos essas tarefas usando o ECSRunTaskOperator Em um DAG na Amazon Mwaa, e criou um invólucro em torno do operador interno da Amazon ECS, para que analistas e engenheiros da equipe de análise de dados pudessem criar novos DAGs apenas especificando os comandos com os quais já estavam familiarizados.
O diagrama a seguir ilustra os fluxos de implantação de DAG e tarefas.
Quando nossa implementação inicial do Amazon ECS foi concluída, conseguimos cortar todos os nossos DAGs existentes para a Amazon MWAA sem os problemas anteriores de simultaneidade, porque cada tarefa foi executada em sua própria tarefa isolada da Amazon ECS na Fargate.
Dentro de alguns meses, passamos à etapa 4 para atualizar nossa instância da Amazon Mwaa para o fluxo de ar. Guia de migração da Amazon Mwaa e posteriormente derrubando nossos recursos herdados.
O aumento de custo da adição de Amazon ECS aos nossos dutos foi mínimo. Isso ocorreu porque nossos oleodutos são executados em cronogramas de lotes e, portanto, não estão ativos o tempo todo, e o Amazon ECS nas cobranças de Fargate apenas para os recursos de VCPU e memória solicitados para concluir as tarefas.
Como parte da etapa 5 para Avaliação e melhorias contínuasaprimoramos nossa implementação do Amazon ECS para empurrar logs e métricas para Datadog e CloudWatch. Poderíamos monitorar erros e modelar o desempenho e capturar falhas no teste de dados juntamente com o monitoramento de lançamento existente.
Escalando a solução além da análise interna
Durante a implementação inicial da equipe de análise de dados, criamos um módulo Amazon MWAA Terraform, que nos permitiu aumentar rapidamente mais ambientes da Amazon MWAA e compartilhar nosso trabalho com outras equipes de engenharia. Isso permitiu que o uso do fluxo de ar e da Amazon MWAA para alimentar os pipelines em lote dentro do próprio produto de lançamento em alguns meses emblem após a equipe de análise de dados concluir a migração inicial.
O numeroso Integrações de serviços da AWS suportadas pelo fluxo de aro embutido Pacote do provedor da AmazonE a Amazon Mwaa nos permitiu expandir nosso uso entre as equipes para usar a Amazon Mwaa como um orquestrador genérico para pipelines distribuídos em serviços como Amazon AthenaAssim, Amazon Relational Database Service (Amazon RDS) e Aws cola. Desde a adoção do serviço, a bordo de um novo serviço da AWS para a Amazon Mwaa tem sido direta, normalmente envolvendo a identificação do operador ou gancho de fluxo de ar existente para usar e, em seguida, conectar os dois serviços com AWS Id and Entry Administration (EU SOU).
Lições e resultados
Através de nossa jornada de orquestrar pipelines de dados em escala com a Amazon MWAA e a Amazon ECS, obtivemos insights e lições valiosas que moldaram o sucesso de nossa implementação. Uma das principais lições aprendidas foi a importância do isolamento. Durante a migração inicial para a Amazon MWAA, encontramos problemas com nosso operador de fluxo de ar personalizado que se baseava no comportamento específico dos executores de Kubernetes usados na plataforma authentic do fornecedor de nuvem. Isso destacou a necessidade de execução de tarefas isoladas para manter a confiabilidade e a escalabilidade de nossos oleodutos.
À medida que escalamos nossa implementação, também reconhecemos a importância do monitoramento e observabilidade. Aprimoramos nosso monitoramento e observabilidade, integrando -se com ferramentas como Datadog e CloudWatch, para que pudéssemos monitorar melhor os erros e modelar o desempenho e capturar falhas no teste de dados, melhorando a confiabilidade geral e a transparência de nossos pipelines de dados.
Com a implementação anterior do fluxo de ar, estávamos executando aproximadamente 100 tarefas de fluxo de ar por dia em uma equipe e dois serviços (Amazon ECS e Floco de neve). No momento da redação deste put up, escalamos nossa implementação para três equipes, quatro serviços e execução de mais de 14.000 tarefas de fluxo de ar por dia. A Amazon MWAA tornou -se um componente crítico de nossos pipelines de processamento de lote, aumentando a velocidade de integrar novas equipes, serviços e pipelines em nossa plataforma de dados de semanas para dias.
Olhando para o futuro, planejamos continuar iterando esta solução para expandir nosso uso da Amazon MWAA para serviços adicionais da AWS, como AWS Lambda e Amazon simples serviço de fila (Amazon Sqs) e automatiza ainda mais nossos fluxos de trabalho de dados para suportar uma escalabilidade ainda maior à medida que nossa empresa cresce.
Conclusão
A orquestração de dados eficaz é essencial para que as organizações coletem e unifiquem dados de diversas fontes em um formato centralizado e utilizável para análise. Ao automatizar esse processo entre equipes e serviços, as empresas podem transformar dados fragmentados em informações valiosas para impulsionar uma melhor tomada de decisão. O LaunchDarkly conseguiu isso usando serviços gerenciados como a Amazon MWAA e adotando as melhores práticas, como isolamento e observabilidade de tarefas, permitindo que a empresa acelere a inovação, mitigasse os riscos e reduza o tempo para o valor de suas ofertas de produtos.
Se sua organização planeja modernizar sua orquestração de pipelines de dados, comece a avaliar sua configuração atual de gerenciamento de fluxo de trabalho, explorando os recursos da Amazon MWAA e considerando como a contêiner poderia beneficiar seus fluxos de trabalho. Com as ferramentas e a abordagem certas, você pode transformar suas operações de dados, impulsionar a inovação e ficar à frente do aumento das demandas de processamento de dados.
Sobre os autores
ASENA UYAR é um engenheiro de software program na LaunchDarkly, com foco na criação de produtos de experimentação impactantes que capacitam as equipes a tomar melhores decisões. Com experiência em matemática, engenharia industrial e ciência de dados, a ASENA trabalha no setor de tecnologia há mais de uma década. Sua experiência abrange vários setores, incluindo SaaS e logística, e ela passou uma parcela significativa de sua carreira como engenheiro de plataforma de dados, projetando e gerenciando sistemas de dados em larga escala. Asena é apaixonada por usar a tecnologia para simplificar e otimizar os fluxos de trabalho, fazendo uma diferença actual na maneira como as equipes operam.
Dean Verhey é um engenheiro de plataforma de dados da LaunchDarkly com sede em Seattle. Ele trabalhou em todos os dados no LaunchDarkly, desde pilhas de relatórios de lote internos a streaming de pipelines alimentando recursos do produto, como experimentação e gráficos de uso de sinalizadores. Antes do LaunchDarkly, ele trabalhou em engenharia de dados para uma variedade de empresas, incluindo saas de compras, startups de viagens e gerenciamento de registros de fogo/EMS. Quando ele não está trabalhando, muitas vezes você pode encontrá -lo nas montanhas esqui.
Daniel Lopes é um arquiteto de soluções para ISVs na AWS. Seu foco é permitir que o ISVS projete e construa seus produtos em alinhamento com suas metas de negócios com todas as vantagens que os serviços da AWS podem oferecê -los. Suas áreas de interesse são arquiteturas orientadas a eventos, computação sem servidor e IA generativa. Fora do trabalho, Daniel orienta seus filhos em videogames e cultura pop.