Estratégias de Implantação para Tipos de Cluster do Apache Kafka

As organizações iniciam a adoção de streaming de dados com um único cluster Apache Kafka para implantar os primeiros casos de uso. A necessidade de governança de dados e segurança em toda a empresa, mas com diferentes SLAs, latência e requisitos de infraestrutura, introduz novos clusters Kafka. Múltiplos clusters Kafka são a norma, não a exceção. Os casos de uso incluem integração híbrida, agregação, migração e recuperação de desastres. Esta postagem no blog explora histórias de sucesso do mundo real e estratégias de cluster para diferentes implantações do Kafka em diferentes setores.

O Apache Kafka: O Padrão De Facto para Arquiteturas Orientadas a Eventos e Streaming de Dados

O Apache Kafka é uma plataforma de streaming de eventos distribuída de código aberto projetada para processamento de dados de alto rendimento e baixa latência. Ele permite publicar, se inscrever, armazenar e processar fluxos de registros em tempo real.

Kafka é uma escolha popular para construir pipelines de dados em tempo real e aplicações de streaming. O protocolo Kafka se tornou o padrão de fato para streaming de eventos em várias estruturas, soluções e serviços em nuvem. Ele suporta cargas de trabalho operacionais e analíticas com recursos como armazenamento persistente, escalabilidade e tolerância a falhas. O Kafka inclui componentes como Kafka Connect para integração e Kafka Streams para processamento de streams, tornando-se uma ferramenta versátil para vários casos de uso baseados em dados.

Embora o Kafka seja famoso por casos de uso em tempo real, muitos projetos aproveitam a plataforma de streaming de dados para consistência de dados em toda a arquitetura empresarial, incluindo bancos de dados, data lakes, sistemas legados, APIs abertas e aplicações nativas de nuvem.

Diferentes Tipos de Cluster Apache Kafka

O Kafka é um sistema distribuído. Uma configuração de produção geralmente requer pelo menos quatro brokers. Portanto, a maioria das pessoas assume automaticamente que tudo que você precisa é de um único cluster distribuído que você escala à medida que adiciona throughput e casos de uso. Isso não está errado no começo. Mas…

Um cluster Kafka não é a resposta certa para todos os casos de uso. Várias características influenciam a arquitetura de um cluster Kafka:

• Disponibilidade: Zero downtime? SLA de uptime de 99,99%? Análises não críticas?
• Latência: Processamento de ponta a ponta em <100ms (incluindo processamento)? Pipeline de data warehouse de ponta a ponta de 10 minutos? Viagem no tempo para reprocesamento de eventos históricos?
• Custo: Valor vs. custo? O custo total de propriedade (TCO) importa. Por exemplo, na nuvem pública, a rede pode representar até 80% do custo total do Kafka!
• Segurança e Privacidade de Dados: Privacidade de dados (dados PCI, GDPR, etc.)? Governança de dados e conformidade? Criptografia de ponta a ponta no nível do atributo? Traga sua própria chave? Acesso público e compartilhamento de dados? Ambiente de borda isolado?
• Throughput e Tamanho dos Dados: Transações críticas (tipicamente baixo volume)? Grandes feeds de dados (fluxo de cliques, sensores IoT, logs de segurança, etc.)?

Tópicos relacionados como on-premise vs. nuvem pública, regional vs. global, e muitos outros requisitos também afetam a arquitetura do Kafka.

Estratégias e Arquiteturas de Cluster Apache Kafka

Um único cluster Kafka é frequentemente o ponto de partida certo para a sua jornada de streaming de dados. Ele pode incorporar vários casos de uso de diferentes domínios de negócios e processar gigabytes por segundo (se operado e dimensionado da maneira certa).

No entanto, dependendo dos requisitos do seu projeto, você precisa de uma arquitetura empresarial com múltiplos clusters Kafka. Aqui estão alguns exemplos comuns:

• Arquitetura Híbrida: Integração de dados e sincronização de dados uni ou bidirecional entre múltiplos centros de dados. Frequentemente, conectividade entre um centro de dados local e um provedor de serviços de nuvem pública. Transferência de dados de sistemas legados para análises em nuvem é um dos cenários mais comuns. Mas a comunicação de comando e controle também é possível, ou seja, enviar decisões/recomendações/transações para um ambiente regional (por exemplo, armazenar um pagamento ou pedido de um aplicativo móvel no mainframe).
• Múltiplas Regiões/Multi-Nuvem: Replicação de dados por motivos de conformidade, custo ou privacidade de dados. O compartilhamento de dados geralmente inclui apenas uma fração dos eventos, e não todos os Tópicos do Kafka. A área da saúde é uma das muitas indústrias que seguem nessa direção.
• Recuperação de Desastres: Replicação de dados críticos em modo ativo-ativo ou ativo-passivo entre diferentes centros de dados ou regiões de nuvem. Inclui estratégias e ferramentas para mecanismos de fail-over e fallback em caso de desastre, garantindo a continuidade e conformidade dos negócios.
• Agregação: Agrupamentos regionais para processamento local (por exemplo, pré-processamento, ETL em streaming, aplicativos comerciais de processamento em stream) e replicação de dados filtrados para o grande centro de dados ou nuvem. As lojas de varejo são um excelente exemplo.
• Migração: Modernização de TI com migração de um ambiente local para a nuvem ou de um sistema de código aberto gerenciado internamente para um SaaS totalmente gerenciado. Tais migrações podem ser feitas sem tempo de inatividade ou perda de dados, enquanto os negócios continuam durante a transição.
• Borda (Desconectado/Isolado): Segurança, custo ou latência exigem implementações de borda, por exemplo, em uma fábrica ou loja de varejo. Algumas indústrias implementam em ambientes críticos de segurança com gateway de hardware unidirecional e diodo de dados.
• Broker Único: Não resiliente, mas suficiente para cenários como incorporar um broker Kafka em uma máquina ou em um PC Industrial (IPC) e replicar dados agregados em um grande cluster de análise de Kafka na nuvem. Um bom exemplo é a instalação de streaming de dados (incluindo integração e processamento) no computador de um soldado em campo de batalha.

Conectando Clusters Híbridos do Kafka

Essas opções podem ser combinadas. Por exemplo, um broker único na borda normalmente replica alguns dados selecionados para um centro de dados remoto. Os clusters híbridos têm arquiteturas diferentes dependendo de como são conectados: conexões pela Internet pública, link privado, VPC peering, transit gateway, etc.

Tendo acompanhado o desenvolvimento do Confluent Cloud ao longo dos anos, subestimei quanto tempo de engenharia precisa ser dedicado à segurança e conectividade. No entanto, a falta de bridges de segurança são os principais obstáculos para a adoção de um serviço de nuvem Kafka. Portanto, não há como evitar a necessidade de várias bridges de segurança entre os clusters do Kafka além da internet pública.

Há até mesmo casos de uso em que as organizações precisam replicar dados do centro de dados para a nuvem, mas o serviço de nuvem não é permitido a iniciar a conexão. A Confluent construiu um recurso específico, “link iniciado pela fonte”, para atender a esses requisitos de segurança, onde a fonte (ou seja, o cluster Kafka local) sempre inicia a conexão – mesmo que os clusters Kafka na nuvem estejam consumindo os dados:

Fonte: Confluent

Como você pode ver, isso se torna complexo rapidamente. Encontre os especialistas certos para ajudá-lo desde o início, e não depois de você já ter implantado os primeiros clusters e aplicações.

Há muito tempo, descrevi em uma apresentação detalhada os padrões de arquitetura para implantações distribuídas, híbridas, de borda e globais do Apache Kafka. Consulte esse conjunto de slides e a gravação em vídeo para mais detalhes sobre as opções de implantação e compensações.

RPO vs. RTO = Perda de Dados vs. Tempo de Inatividade

RPO e RTO são dois KPIs críticos que você precisa discutir antes de decidir sobre uma estratégia de cluster Kafka:

• RPO (Objetivo de Ponto de Recuperação) é a quantidade máxima aceitável de perda de dados medida em tempo, indicando com que frequência os backups devem ocorrer para minimizar a perda de dados.
• RTO (Recovery Time Objective) é a duração máxima aceitável do tempo que leva para restaurar as operações comerciais após uma interrupção. Juntos, eles ajudam as organizações a planejar suas estratégias de backup de dados e recuperação de desastres para equilibrar custo e impacto operacional.

Embora as pessoas frequentemente comecem com o objetivo de RPO = 0 e RTO = 0, rapidamente percebem o quão difícil (mas não impossível) é conseguir isso. Você precisa decidir quanto de dados pode perder em um desastre. Você precisa de um plano de recuperação de desastres se um desastre ocorrer. As equipes legais e de conformidade terão que dizer se é aceitável perder alguns conjuntos de dados em caso de desastre ou não. Esses e muitos outros desafios precisam ser discutidos ao avaliar a estratégia de seu cluster Kafka.

A replicação entre clusters Kafka com ferramentas como MIrrorMaker ou Cluster Linking é assíncrona e RPO > 0. Apenas um cluster Kafka estendido fornece RPO = 0.

Cluster Kafka Estendido: Zero Perda de Dados Com Replicação Síncrona Entre Data Centers

A maioria das implantações com múltiplos clusters Kafka usa replicação assíncrona entre data centers ou nuvens via ferramentas como MirrorMaker ou Confluent Cluster Linking. Isso é suficiente para a maioria dos casos de uso. Mas em caso de desastre, você perde algumas mensagens. O RPO é > 0.

Um cluster Kafka estendido implanta brokers Kafka de um único cluster em três data centers. A replicação é síncrona (pois assim o Kafka replica dados dentro de um cluster) e garante zero perda de dados (RPO = 0) – mesmo em caso de desastre!

Por que você não deveria sempre fazer clusters estendidos?

• Conexão de baixa latência (<~50ms) e estável é necessária entre os data centers.
• Três (!) data centers são necessários; dois não são suficientes, pois a maioria (quorum) deve reconhecer as gravações e leituras para garantir a confiabilidade do sistema.
• Eles são difíceis de configurar, operar e monitorar e muito mais complicados do que um cluster operando em um único data center.
• Custo versus valor não compensa em muitos casos de uso; durante uma verdadeira catástrofe, a maioria das organizações e casos de uso tem problemas maiores do que perder algumas mensagens (mesmo que sejam dados críticos como um pagamento ou pedido).

Para ser claro, na nuvem pública, uma região geralmente possui três data centers (= zonas de disponibilidade). Portanto, na nuvem, depende dos seus SLAs se uma região de nuvem conta como um cluster estendido ou não. A maioria das ofertas SaaS de Kafka são implantadas em um cluster estendido aqui.

No entanto, muitos cenários de conformidade não consideram um cluster Kafka em uma região de nuvem como suficientemente bom para garantir SLAs e continuidade de negócios se uma catástrofe ocorrer.

Confluent construiu um produto dedicado para resolver (alguns desses) desafios: Clusters Multi-Região (MRC). Ele fornece capacidades para realizar replicação síncrona e assíncrona dentro de um cluster Kafka estendido.

Por exemplo, em um cenário de serviços financeiros, MRC replica transações críticas de baixo volume de forma síncrona, mas logs de alto volume de forma assíncrona:

• Manuseia transações de ‘Pagamento’ provenientes dos EUA Leste e Oeste com replicação totalmente síncrona
• As informações de ‘Log’ e ‘Localização’ no mesmo cluster usam async – otimizado para latência
• Recuperação de desastres automatizada (sem tempo de inatividade, sem perda de dados)

Mais detalhes sobre clusters Kafka estendidos vs. replicação ativa-ativa / ativa-passiva entre dois clusters Kafka em minha apresentação global do Kafka.

Preços das Ofertas de Nuvem do Kafka (vs. Auto-gerenciado)

As seções acima explicam por que você precisa considerar arquiteturas Kafka diferentes, dependendo dos requisitos do seu projeto. Clusters Kafka auto-gerenciados podem ser configurados da maneira que você precisa. Nas ofertas totalmente gerenciadas de nuvem pública, o cenário é diferente (da mesma maneira que qualquer outro SaaS totalmente gerenciado). Os preços são diferentes porque os fornecedores de SaaS precisam configurar limites razoáveis. O fornecedor deve fornecer SLAs específicos.

O cenário de streaming de dados inclui várias ofertas de nuvem Kafka. Aqui está um exemplo das ofertas de nuvem atuais da Confluent, incluindo ambientes multi-inquilino e dedicados com diferentes SLAs, recursos de segurança e modelos de custo.

Fonte: Confluent

Garanta avaliar e compreender os vários tipos de cluster de diferentes fornecedores disponíveis na nuvem pública, incluindo TCO, SLAs de tempo de atividade fornecidos, custos de replicação entre regiões ou provedores de nuvem, e assim por diante. As lacunas e limitações muitas vezes são intencionalmente escondidas nos detalhes.

Por exemplo, se você usar o Amazon Managed Streaming for Apache Kafka (MSK), você deve estar ciente de que os termos e condições afirmam que “O compromisso de serviço não se aplica a qualquerindisponibilidade, suspensão ou rescisão … causada pelo software de motor Apache Kafka ou Apache Zookeeper subjacente que leva a falhas de solicitação.”

No entanto, precificação e SLAs de suporte são apenas uma peça crítica de comparação. Existem muitas “decisões de construir vs. comprar” que você precisa tomar ao avaliar uma plataforma de streaming de dados.

Armazenamento do Kafka: Armazenamento em camadas e Formato de Tabela Iceberg para Armazenar Dados Apenas Uma Vez

O Apache Kafka adicionou Armazenamento em Camadas para separar computação e armazenamento. A capacidade permite arquiteturas empresariais mais escaláveis, confiáveis e econômicas. O Armazenamento em Camadas para o Kafka possibilita um novo tipo de cluster Kafka: Armazenar Petabytes de dados no log de commit do Kafka de forma econômica (como em seu data lake) com timestamps e ordenação garantida para retroceder no tempo e reprocesar dados históricos. A KOR Financial é um bom exemplo do uso do Apache Kafka como um banco de dados para persistência de longo prazo.

O Kafka possibilita uma Arquitetura Shift Left para armazenar dados apenas uma vez para conjuntos de dados operacionais e analíticos:

Com isso em mente, pense novamente sobre os casos de uso que descrevi acima para múltiplos clusters Kafka. Ainda é necessário replicar dados em lote em repouso no banco de dados, data lake ou lakehouse de um data center ou região de nuvem para outro? Não. Você deve sincronizar os dados em tempo real, armazenar os dados uma vez (geralmente em um repositório de objetos como Amazon S3) e então conectar todos os motores analíticos como Snowflake, Databricks, Amazon Athena, Google Cloud BigQuery, e assim por diante, a este formato de tabela padrão.

Histórias de Sucesso do Mundo Real para Múltiplos Clusters Kafka

A maioria das organizações possui múltiplos clusters Kafka. Esta seção explora quatro histórias de sucesso em diferentes setores:

• Paypal (Serviços Financeiros) – EUA: Pagamentos instantâneos, prevenção de fraudes.
• JioCinema (Telecom/Media) – APAC: Integração de dados, análise de clickstream, publicidade, personalização.
• Audi (Automotivo/Fabricação) – EMEA: Carros conectados com requisitos críticos e analíticos.
• New Relic (Software/Nuvem) – EUA: Observabilidade e gerenciamento de desempenho de aplicativos (APM) em todo o mundo.

Paypal: Separação por Zona de Segurança

PayPal é uma plataforma de pagamento digital que permite aos usuários enviar e receber dinheiro online de forma segura e conveniente em todo o mundo em tempo real. Isso requer uma infraestrutura Kafka escalável, segura e em conformidade.

No Black Friday de 2022, o volume de tráfego do Kafka atingiu cerca de 1,3 trilhões de mensagens diariamente. Atualmente, o PayPal possui mais de 85 clusters Kafka, e a cada temporada de festas, eles ampliam sua infraestrutura Kafka para lidar com o aumento do tráfego. A plataforma Kafka continua a escalar de forma contínua para suportar esse crescimento de tráfego sem impactar seus negócios.

Hoje, a frota Kafka do PayPal consiste em mais de 1.500 brokers que hospedam mais de 20.000 tópicos. Os eventos são replicados entre os clusters, oferecendo 99,99% de disponibilidade.

As implementações de clusters Kafka são separadas em diferentes zonas de segurança dentro de um data center:

Fonte: Paypal

Os clusters do Kafka são implantados em zonas de segurança com base na classificação de dados e nos requisitos comerciais. A replicação em tempo real com ferramentas como MirrorMaker (neste exemplo, executado na infraestrutura do Kafka Connect) ou Confluent Cluster Linking (usando uma abordagem mais simples e menos propensa a erros diretamente usando o protocolo do Kafka para replicação) é usada para espelhar os dados entre os data centers, o que ajuda na recuperação de desastres e para alcançar a comunicação entre zonas de segurança.

JioCinema: Separação por Caso de Uso e SLA

O JioCinema é uma plataforma de streaming de vídeo em rápido crescimento na Índia. O serviço OTT de telecomunicações é conhecido por sua ampla oferta de conteúdo, incluindo esportes ao vivo como a Indian Premier League (IPL) de críquete, um recém-lançado Anime Hub e planos abrangentes para cobrir grandes eventos como as Olimpíadas de Paris 2024.

A arquitetura de dados aproveita o Apache Kafka, Flink e Spark para processamento de dados, conforme apresentado na Kafka Summit India 2024 em Bangalore:

Fonte: JioCinema

O streaming de dados desempenha um papel fundamental em vários casos de uso para transformar experiências de usuários e a entrega de conteúdo. Mais de dez milhões de mensagens por segundo aprimoram análises, percepções de usuários e mecanismos de entrega de conteúdo.

Os casos de uso do JioCinema incluem:

• Comunicação entre serviços
• Clickstream/Análises
• Rastreador de Anúncios
• Aprendizado de Máquina e Personalização

Kushal Khandelwal, Head of Data Platform, Analytics, and Consumption no JioCinema, explicou que nem todos os dados são iguais e as prioridades e SLAs diferem por caso de uso:

Fonte: JioCinema

O streaming de dados é uma jornada. Como muitas outras organizações em todo o mundo, o JioCinema começou com um grande cluster Kafka usando mais de 1000 Tópicos Kafka e mais de 100.000 Partições Kafka para vários casos de uso. Com o tempo, uma separação de preocupações em relação aos casos de uso e SLAs se desenvolveu em múltiplos clusters Kafka:

Fonte: JioCinema

A história de sucesso do JioCinema mostra a evolução comum de uma organização de streaming de dados. Vamos agora explorar outro exemplo em que dois clusters Kafka muito diferentes foram implantados desde o início para um caso de uso.

Audi: Operações vs. Análises para Carros Conectados

O fabricante de automóveis Audi fornece carros conectados com tecnologia avançada que integra conectividade com a internet e sistemas inteligentes. Os carros da Audi permitem navegação em tempo real, diagnóstico remoto e entretenimento aprimorado no carro. Esses veículos são equipados com serviços Audi Connect. Os recursos incluem chamadas de emergência, informações de tráfego online e integração com dispositivos domésticos inteligentes para melhorar a conveniência e segurança dos motoristas.

Fonte: Audi

A Audi apresentou sua arquitetura de carros conectados na palestra principal da Kafka Summit de 2018. A arquitetura empresarial da Audi depende de dois clusters Kafka com SLAs e casos de uso muito diferentes.

Fonte: Audi

O cluster de ingestão de dados do Kafka é muito crítico.Ele precisa funcionar 24 horas por dia, 7 dias por semana em grande escala. Fornece conectividade de última milha para milhões de carros usando Kafka e MQTT. Canais de retorno do lado de TI para o veículo auxiliam na comunicação de serviços e atualizações over-the-air (OTA).

O cluster de analytics Kafka da ACDC Cloud é a base da arquitetura de carros conectados da Audi. O cluster é a base de muitas cargas analíticas, que processam enormes volumes de dados de IoT e logs em escala com frameworks de processamento em lote como o Apache Spark.

Esta arquitetura foi apresentada em 2018. O slogan da Audi, “Progresso através da Tecnologia”, mostra como a empresa aplicou novas tecnologias para inovação muito antes da maioria dos fabricantes de carros implantarem cenários semelhantes. Todos os dados dos sensores dos carros conectados são processados em tempo real e armazenados para análise e relatórios históricos.

New Relic: Observabilidade Multi-Cloud Mundial

O New Relic é uma plataforma de observabilidade baseada na nuvem que fornece monitoramento de desempenho em tempo real e análise para aplicativos e infraestrutura para clientes em todo o mundo.

Andrew Hartnett, VP de Engenharia de Software da New Relic, explica como o fluxo de dados é crucial para todo o modelo de negócios da New Relic:

“O Kafka é nosso sistema nervoso central. Ele faz parte de tudo o que fazemos. A maioria dos serviços em 110 equipes de engenharia diferentes com centenas de serviços se conecta ao Kafka de alguma forma em nossa empresa, então ele realmente é crucial para a missão. O que procurávamos era a capacidade de crescer, e o Confluent Cloud proporcionou isso.”

O New Relic absorveu até 7 bilhões de pontos de dados por minuto e está no caminho para absorver 2,5 exabytes de dados em 2023. À medida que o New Relic expande suas estratégias multi-cloud, as equipes usarão o Confluent Cloud para uma visualização única de todos os ambientes.

“O New Relic é multi-cloud. Queremos estar onde nossos clientes estão. Queremos estar nesses mesmos ambientes, nessas mesmas regiões, e queríamos ter nosso Kafka conosco.” diz Artnett em um estudo de caso da Confluent.

Múltiplos Clusters Kafka são a Norma, Não uma Exceção

Arquiteturas orientadas a eventos e processamento de stream existem há décadas. A adoção cresce com frameworks de código aberto como Apache Kafka e Flink em combinação com serviços em nuvem completamente gerenciados. Cada vez mais organizações enfrentam desafios com a escala do Kafka. Governança de dados em toda a empresa, centro de excelência, automação de implantação e operações e melhores práticas de arquitetura empresarial ajudam a fornecer com sucesso streaming de dados com múltiplos clusters Kafka para domínios comerciais independentes ou colaborativos.

Múltiplos clusters Kafka são a norma, não uma exceção. Casos de uso como integração híbrida, recuperação de desastres, migração ou agregação permitem streaming de dados em tempo real em todos os lugares com os SLAs necessários.