Este é um artigo traduzido originalmente publicado dia 18/08/2022 no blog do Kai Waehner: "Why DoorDash migrated from Cloud-native Amazon SQS and Kinesis to Apache Kafka and Flink". Assine a newsletter do Kai para se manter atualizado com novas publicações.
Mesmo os nativos digitais – que iniciaram seus negócios na nuvem sem aplicativos legados em seus próprios data centers – precisam modernizar sua arquitetura corporativa nativa da nuvem para melhorar os processos de negócios, reduzir custos e fornecer informações em tempo real para seus aplicativos downstream. Esta postagem explora os benefícios de uma plataforma de streaming de dados aberta e flexível em comparação com uma fila de mensagens proprietária e serviços de nuvem de ingestão de dados. Um exemplo concreto mostra como o DoorDash substituiu AWS SQS e Kinesis nativos da nuvem por Apache Kafka e Flink.
Mesmo os nativos digitais – que iniciaram seus negócios na nuvem sem aplicativos legados em seus próprios data centers – precisam modernizar sua arquitetura corporativa nativa da nuvem para melhorar os processos de negócios, reduzir custos e fornecer informações em tempo real para seus aplicativos downstream. Esta postagem explora os benefícios de uma plataforma de streaming de dados aberta e flexível em comparação com uma fila de mensagens proprietária e serviços de nuvem de ingestão de dados. Um exemplo concreto mostra como o DoorDash substituiu AWS SQS e Kinesis nativos da nuvem por Apache Kafka e Flink.
Fila de mensagens e ETL versus streaming de dados com Apache Kafka
Uma fila de mensagens como IBM MQ, RabbitMQ ou Amazon SQS permite enviar e receber mensagens . Isso funciona muito bem para comunicação ponto a ponto. No entanto, ferramentas adicionais como Apache NiFi, Amazon Kinesis Data Firehose ou outras ferramentas ETL são necessárias para integração e processamento de dados.
Uma plataforma de streaming de dados como o Apache Kafka fornece muitos recursos:
Produzindo e consumindo mensagens para mensagens em tempo real em qualquer escala
Integração de dados para evitar arquiteturas espaguete com muitos componentes de middleware no pipeline de ponta a ponta
Processamento de fluxo para processar continuamente e correlacionar dados de diferentes sistemas
Armazenamento distribuído para verdadeiro desacoplamento, manipulação de contrapressão e reprodutibilidade de eventos. Tudo em uma única plataforma.
Abordei a comparação apple vs. orange entre filas de mensagens e streaming de dados no artigo “ Comparação: JMS Message Queue vs. Apache Kafka “. Em conclusão, o streaming de dados com Kafka fornece um hub de dados para acessar facilmente eventos de diferentes aplicativos downstream (independentemente da tecnologia, API ou paradigma de comunicação que eles usam).
Se você precisa misturar uma infraestrutura de mensagens com plataformas ETL, uma arquitetura espaguete é a consequência. Se você está no local e usa ferramentas ETL ou ESB , ou se está na nuvem e pode aproveitar as plataformas iPaaS . Quanto mais plataformas você (deve) combinar em um único pipeline de dados, maiores serão os custos, a complexidade das operações e as garantias de SLA . Esse é um dos principais argumentos de por que o Apache Kafka se tornou o padrão de fato para integração de dados .
Cloud-native é o novo preto para infraestrutura e aplicativos
A maioria das arquiteturas corporativas modernas utiliza infraestrutura, aplicativos e SaaS nativos da nuvem, independentemente de a implantação ocorrer na nuvem pública ou privada. Uma infraestrutura nativa da nuvem fornece:
automação via DevOps e entrega contínua
escala elástica com contêineres e ferramentas de orquestração como Kubernetes
desenvolvimento ágil com design orientado a domínio e microsserviços desacoplados
Na nuvem pública, as ofertas de SaaS totalmente gerenciadas são a maneira preferida de implantar infraestrutura e aplicativos. Isso inclui serviços como Amazon SQS, Amazon Kinesis e Confluent Cloud para Apache Kafka totalmente gerenciado. A escassa equipe de especialistas pode se concentrar na solução de problemas de negócios e em novos aplicativos inovadores, em vez de operar a infraestrutura.
No entanto, nem tudo pode ser executado como um SaaS. Custo, segurança e latência são os principais argumentos pelos quais os aplicativos são implantados em seu próprio VPC na nuvem, em um data center local ou na borda. Operadores e CRDs para Kubernetes ou scripts Ansible são soluções comuns para implantar e operar sua própria infraestrutura nativa de nuvem se o uso de um produto de nuvem sem servidor não for possível ou viável.
DoorDash: de vários pipelines a streaming de dados para integração com o Snowflake
A DoorDash é uma empresa americana que opera uma plataforma online de pedidos e entrega de alimentos. Com uma participação de mercado de mais de 50%, é a maior empresa de entrega de alimentos nos Estados Unidos.
Obviamente, esse serviço requer pipelines escaláveis em tempo real para ser bem-sucedido . Caso contrário, o modelo de negócios não funciona. Por motivos semelhantes, todos os outros serviços de mobilidade, como Uber e Lyft nos EUA, Free Now na Europa ou Grab na Ásia, utilizam o streaming de dados como base de seus pipelines de dados.
Desafios com vários pipelines de integração usando SQS e Kinesis em vez de Apache Kafka
Os eventos são gerados a partir de muitos serviços DoorDash e dispositivos de usuário. Eles precisam ser processados e transportados para diferentes destinos , incluindo:
Armazém de dados OLAP para análise de negócios
Plataforma de aprendizado de máquina (ML) para gerar recursos em tempo real, como tempos médios de espera recentes para restaurantes
Back-end de métrica de série temporal para monitoramento e alerta para que as equipes possam identificar problemas rapidamente nas versões mais recentes de aplicativos móveis
Os pipelines de integração e os consumidores downstream utilizam diferentes tecnologias, APIs e paradigmas de comunicação (em tempo real, quase em tempo real, em lote).
Cada pipeline é construído de forma diferente e só pode processar um tipo de evento. Envolve vários saltos antes que os dados finalmente cheguem ao data warehouse.
É ineficiente em termos de custo construir vários pipelines que estão tentando atingir objetivos semelhantes. O DoorDash usou sistemas de mensagens e streaming nativos da nuvem da AWS, como Amazon SQS e Amazon Kinesis, para ingestão de dados no data warehouse Snowflake:
Misturar diferentes tipos de transporte de dados e passar por vários sistemas de mensagens/enfileiramento sem uma observabilidade cuidadosamente projetada em torno dele leva a dificuldades nas operações.
Do Amazon SQS e Kinesis ao Apache Kafka e Flink
Esses problemas resultaram em alta latência de dados, custo significativo e sobrecarga operacional na DoorDash . Portanto, o DoorDash mudou para uma plataforma de streaming nativa da nuvem desenvolvida pelo Apache Kafka e Apache Flink para processamento de fluxo contínuo antes de ingerir dados no Snowflake:
A mudança para uma plataforma de streaming de dados oferece muitos benefícios ao DoorDash :
Fontes e destinos de dados heterogêneos , incluindo APIs REST usando o proxy rest Confluent
Facilmente acessível a partir de qualquer aplicativo downstream (não importa qual tecnologia, API ou paradigma de comunicação)
Governança de dados de ponta a ponta com aplicação de esquema e evolução de esquema com Confluent Schema Registry
Escalável, tolerante a falhas e fácil de operar para uma equipe pequena
REST/HTTP é complementar ao streaming de dados com Kafka
Nem toda comunicação é em tempo real e streaming. As APIs HTTP/REST são cruciais para muitas integrações . O DoorDash aproveita o Confluent REST Proxy para produzir e consumir via HTTP de/para Kafka.
Saiba mais sobre essa combinação, seus casos de uso e compensações na postagem do meu blog “ Solicitação-Resposta com REST/HTTP vs. Transmissão de Dados com Apache Kafka – Amigos, Inimigos, Frenemies? “.
Todos os detalhes sobre essa otimização de infraestrutura nativa da nuvem estão na postagem do blog de engenharia da DoorDash : “ Construindo processamento de eventos em tempo real escalável com Kafka e Flink ”.
Não subestime o bloqueio do fornecedor e o custo das ofertas proprietárias de SaaS
Um dos principais motivos pelos quais vejo clientes migrando de serviços de nuvem proprietários sem servidor, como o Kinesis, é o custo . Embora pareça bom inicialmente, pode ficar louco quando as cargas de trabalho de dados aumentam. Tempo de retenção muito limitado e recursos de integração de dados ausentes são outros motivos.
O exemplo do DoorDash mostra como até mesmo os projetos greenfield nativos da nuvem exigem a modernização da arquitetura corporativa para simplificar os pipelines e reduzir os custos.
Um benefício colateral é a independência de um provedor de nuvem específico. Com mecanismos de código aberto como Kafka ou Flink, todo o pipeline de integração pode ser implantado em qualquer lugar . Possíveis implantações incluem:
Ligação de cluster entre países ou mesmo continentes (incluindo filtragem, anonimização e outro processamento relevante de privacidade de dados antes do compartilhamento e replicação de dados)
Vários provedores de nuvem (por exemplo, se o GCP for mais barato que o AWS ou porque a China continental fornece apenas o Alibaba)
Cargas de trabalho de baixa latência ou ambientes de segurança de confiança zero na borda (por exemplo, em uma fábrica, estádio ou trem.
Como você vê as compensações entre estruturas de código aberto como Kafka e Flink versus serviços de nuvem proprietários como AWS SQS ou Kinesis? Quais são os seus critérios de decisão para fazer a escolha certa para o seu projeto? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comments