Dominando a implantação e replicação de vários clusters com Kafka

Breve visão geral do Apache Kafka e casos de uso comuns, ferramentas atuais para dimensionar implantações de vários clusters e soluções de conectividade para simplificar implantações de vários clusters.

Índice

• O que é Kafka?

• Kafka e Kubernetes

• O caso do Multi Cluster Kafka

• Multi Cluster Kafka

  • Clusters estendidos – replicação síncrona
  • Clusters conectados – replicação assíncrona

• Conclusão

  
  

O que é Kafka?

Comumente conhecido simplesmente como Kafka , Apache Kafka é uma plataforma de streaming de eventos de código aberto mantida pela Apache Software Foundation. Inicialmente concebido no LinkedIn , o Apache Kafka foi criado de forma colaborativa por Jay Kreps , Neha Narkhede e Jun Rao , e posteriormente lançado como um projeto de código aberto em 2011. Wiki Page

Hoje, Kafka é uma das plataformas de streaming de eventos mais populares, projetada para lidar com feeds de dados em tempo real. É amplamente utilizado para construir pipelines de dados de streaming escalonáveis, tolerantes a falhas e de alto desempenho.

Os usos de Kafka estão em constante expansão, com os 5 principais casos bem ilustrados por Brij Pandey na imagem a seguir.

Como uma breve introdução, é importante compreender os componentes da plataforma Kafka e como eles funcionam.

Kafka funciona como uma plataforma distribuída de streaming de eventos, projetada para lidar com feeds de dados em tempo real de maneira eficiente. Opera com base no modelo de mensagens de publicação-assinatura e segue uma arquitetura distribuída e tolerante a falhas. Ele mantém uma sequência de registros persistente, ordenada e particionada chamada "tópicos". Os produtores escrevem dados para esses tópicos e os consumidores os leem. Isso permite a dissociação entre produtores e consumidores de dados e permite que vários aplicativos consumam o mesmo fluxo de dados de forma independente.

Os principais componentes do Kafka incluem:

1. Tópicos e partições: Kafka organiza os dados em tópicos. Cada tópico é um fluxo de registros e os dados dentro de um tópico são divididos em diversas partições. Cada partição é uma sequência ordenada e imutável de registros. As partições permitem escalabilidade horizontal e paralelismo, permitindo que os dados sejam distribuídos entre vários corretores Kafka.

   
   

2. Produtores : produtores são aplicativos que gravam dados em tópicos Kafka. Eles publicam registros para tópicos específicos, que são então armazenados nas partições do tópico. Os produtores podem enviar registros explicitamente para uma partição específica ou permitir que Kafka determine a partição usando uma estratégia de particionamento.

   
   

3. Consumidores : consumidores são aplicativos que leem dados de tópicos do Kafka. Eles assinam um ou mais tópicos e consomem registros das partições às quais estão atribuídos. Os grupos de consumidores são usados para dimensionar o consumo, e cada partição dentro de um tópico pode ser consumida por apenas um consumidor dentro de um grupo. Isso permite que vários consumidores trabalhem em paralelo para processar os dados de diferentes partições do mesmo tópico.

   
   

4. Corretores : Kafka é executado como um cluster de servidores e cada servidor é chamado de corretor. Os corretores são responsáveis por lidar com solicitações de leitura e gravação de produtores e consumidores, bem como gerenciar as partições de tópicos. Um cluster Kafka pode ter vários corretores para distribuir a carga e garantir tolerância a falhas.

   
   

5. Partições/Replicação : Para obter tolerância a falhas e durabilidade de dados, Kafka permite configurar a replicação para partições de tópicos. Cada partição pode ter múltiplas réplicas, com uma réplica designada como líder e as outras como seguidoras. A réplica líder lida com todas as solicitações de leitura e gravação dessa partição, enquanto os seguidores replicam os dados do líder para permanecerem sincronizados. Se um corretor com réplica de líder falhar, um dos seguidores torna-se automaticamente o novo líder para garantir a operação contínua.

   
   

6. Gerenciamento de deslocamento : Kafka mantém o conceito de deslocamento para cada partição. Um deslocamento representa um identificador exclusivo para um registro dentro de uma partição. Os consumidores acompanham a sua compensação atual, permitindo-lhes retomar o consumo de onde pararam em caso de falha ou reprocessamento.

   
   

7. ZooKeeper : embora não faça parte do próprio Kafka, o ZooKeeper é frequentemente usado para gerenciar os metadados e coordenar os corretores em um cluster Kafka. Ajuda na eleição de líderes, informações de tópicos e partições e no gerenciamento da coordenação de grupos de consumidores. [Nota: a ferramenta de gerenciamento de metadados Zookeeper será em breve descontinuada em favor do Kafka Raft , ou KRaft, um protocolo para metadados gerenciados internamente ]

   
   

No geral, o design e a arquitetura do Kafka o tornam uma plataforma altamente escalável, tolerante a falhas e eficiente para lidar com grandes volumes de fluxos de dados em tempo real. Tornou-se um componente central em muitos aplicativos e infraestrutura de dados orientados a dados, facilitando a integração de dados, o processamento de eventos e a análise de fluxo.

Uma arquitetura Kafka típica seria então a seguinte:

O clustering Kafka refere-se à prática de executar vários corretores Kafka juntos como um grupo para formar um cluster Kafka. O clustering é um aspecto fundamental da arquitetura Kafka, oferecendo vários benefícios, incluindo escalabilidade, tolerância a falhas e alta disponibilidade. Um cluster Kafka é usado para lidar com fluxos de dados em grande escala e garantir que o sistema permaneça operacional mesmo diante de falhas.

No cluster, os tópicos Kafka são divididos em múltiplas partições para obter escalabilidade e paralelismo. Cada partição é uma sequência imutável e ordenada linearmente de registros. Portanto, as partições permitem que os dados sejam distribuídos entre vários agentes no cluster.

Deve-se observar que um cluster Kafka mínimo consiste em 3 corretores Kafka, cada um dos quais pode ser executado em um servidor separado (virtual ou físico). A orientação de 3 nós é ajudar a evitar um cenário de divisão cerebral em caso de falha do corretor.

Kafka e Kubernetes

À medida que mais empresas adotam o Kafka, há também um interesse crescente em implantar o Kafka no Kubernetes.

Na verdade, o relatório mais recente Kubernetes in the Wild 2023 da Dynatrace mostra que mais de 40% das grandes organizações executam sua plataforma de mensagens de código aberto dentro do Kubernetes - a maioria delas sendo Kafka.

Fonte .

O mesmo relatório também faz uma afirmação ousada de que “o Kubernetes está emergindo como o ‘sistema operacional’ da nuvem”.

É imperativo, então, que os administradores do Kafka entendam a interação entre o Kafka e o Kubernetes e como implementá-los adequadamente para escalar.

O caso do Multi Cluster Kafka

Executar um cluster Kafka em uma configuração de cluster único Kubernetes é bastante simples e permite escalabilidade conforme necessário em teoria. Na produção, entretanto, a imagem pode ficar um pouco turva.

Devemos distinguir o uso do termo cluster entre Kafka e Kubernetes. Uma implantação do Kubernetes também usa o termo cluster para designar um agrupamento de nós conectados, conhecido como cluster do Kubernetes. Quando a carga de trabalho Kafka for implantada no Kubernetes, você terminará com um cluster Kafka em execução dentro de um cluster Kubernetes, mas o mais relevante para nossa discussão é que você também pode ter um cluster Kafka que abrange vários clusters Kubernetes - para resiliência, desempenho e soberania de dados etc.

Para começar, o Kafka não foi projetado para configurações multilocatários. Em termos técnicos, Kafka não entende conceitos como namespaces Kubernetes ou isolamento de recursos. Dentro de um tópico específico, não existe um mecanismo fácil para impor restrições de acesso de segurança entre vários grupos de usuários.

Além disso, diferentes cargas de trabalho podem ter diferentes frequências de atualização e requisitos de escala, por exemplo, aplicação em lote versus aplicação em tempo real. Combinar as duas cargas de trabalho num único cluster pode causar impactos adversos ou consumir muito mais recursos do que o necessário.

A soberania dos dados e a conformidade regulatória também podem impor restrições à localização conjunta de dados e tópicos em uma região ou aplicação específica.

A resiliência, é claro, é outra forte força motriz por trás da necessidade de vários clusters Kafka. Embora os clusters Kafka sejam projetados para tolerância a falhas de tópicos, ainda precisamos planejar uma falha catastrófica de um cluster inteiro. Nesses casos, a necessidade de um cluster totalmente replicado permite um planejamento adequado da continuidade dos negócios.

Para empresas que estão migrando a carga de trabalho para a nuvem ou que têm uma estratégia de nuvem híbrida, talvez você queira configurar vários clusters Kafka e realizar uma migração planejada da carga de trabalho ao longo do tempo, em vez de uma migração arriscada do Kafka em grande escala.

Estas são apenas algumas das razões pelas quais, na prática, as empresas têm que criar vários clusters Kafka que, no entanto, precisam interagir entre si.

Multi Cluster Kafka

Para ter vários clusters Kafka conectados entre si, os itens principais de um cluster devem ser replicados para o(s) outro(s) cluster(s). Isso inclui tópicos, compensações e metadados. Nos termos de Kafka, esta duplicação é considerada Espelhamento. Existem duas abordagens possíveis de configurações de vários clusters. Clusters estendidos ou clusters conectados.

Clusters estendidos – replicação síncrona

Um cluster estendido é um cluster lógico que é 'estendido' por vários clusters físicos. Os tópicos e as réplicas são distribuídos pelos clusters físicos, mas como são representados como um cluster lógico, as próprias aplicações não têm consciência dessa multiplicidade.

Clusters estendidos têm consistência forte e são mais fáceis de gerenciar e administrar. Como os aplicativos não têm conhecimento da existência de vários clusters, eles são mais fáceis de implantar em clusters estendidos, em comparação com clusters conectados.

A desvantagem dos clusters estendidos é que eles exigem uma conexão síncrona entre os clusters. Eles não são ideais para uma implantação de nuvem híbrida e exigirão um quórum de pelo menos três clusters para evitar um cenário de “cérebro dividido”.

Clusters conectados – replicação assíncrona

Um cluster conectado, por outro lado, é implantado conectando vários clusters independentes. Esses clusters independentes podem funcionar em diferentes regiões ou plataformas de nuvem e são gerenciados individualmente.

O principal benefício do modelo de cluster conectado é que não há tempo de inatividade em casos de falha do cluster, uma vez que os outros clusters estão em execução de forma independente. Cada cluster também pode ser otimizado para seus recursos específicos.

A principal desvantagem dos clusters conectados é que eles dependem de conexões assíncronas entre os clusters. Os tópicos que são replicados entre os clusters não são 'cópia na gravação', mas dependem de consistência eventual. Isto pode levar a uma possível perda de dados durante o processo de espelhamento assíncrono.

Além disso, os aplicativos que funcionam em clusters conectados precisam ser modificados para estarem cientes dos vários clusters.

Antes de abordarmos a solução para esse enigma, abordarei brevemente as ferramentas comuns no mercado para permitir a conectividade do cluster Kafka.

O próprio Open Source Kafka vem com uma ferramenta de espelhamento chamada Mirror Maker.

Mirror Maker duplica tópicos entre diferentes clusters por meio de um produtor integrado. Desta forma, os dados são replicados cruzadamente entre clusters com consistência eventual, mas sem interromper processos individuais.

É importante observar que, embora o Mirror Maker seja simples em seu conceito, configurar o Mirror Maker em escala pode ser um grande desafio para as organizações de TI. O gerenciamento de endereços IP, convenções de nomenclatura, número de réplicas, etc. deve ser feito corretamente ou pode levar ao que é conhecido como 'replicação infinita', onde um tópico é replicado infinitamente, levando a uma eventual falha.

Outras desvantagens do Mirror Maker é a falta de configuração dinâmica de listas permitidas/não permitidas para atualizações. O Mirror Maker também não sincroniza as propriedades do tópico corretamente, o que o torna uma dor de cabeça operacional em grande escala ao adicionar ou remover tópicos a serem replicados. O Mirror Maker 2 tenta corrigir alguns desses desafios, mas muitas lojas de TI ainda lutam para configurar o Mirror Maker corretamente.

Outras ferramentas de código aberto para replicação Kafka incluem Mirus da Salesforce, uReplicator da Uber e Flink personalizado da Netflix .

Para opções de licença comercial, o Confluent oferece duas opções, Confluent Replicator e Cluster Linking. Confluent Replicator é essencialmente um conector Kafka Connect que fornece uma maneira resiliente e de alto desempenho de copiar dados de tópicos entre clusters. Cluster Linking é outra oferta, desenvolvida internamente e voltada para replicação multirregional, preservando compensações de tópicos.

Mesmo assim, o Cluster Linking é uma ferramenta de replicação assíncrona, com os dados tendo que cruzar os limites da rede e percorrer os caminhos de tráfego público. Como já deve estar claro, a replicação Kafka é uma estratégia crucial para aplicações de produção em escala, a questão é qual opção escolher.

Os administradores imaginativos do Kafka perceberão rapidamente que você pode precisar de clusters conectados e clusters estendidos, ou uma combinação dessas implantações, dependendo do desempenho do aplicativo e dos requisitos de resiliência.

O que é assustador, no entanto, são os desafios exponenciais de definir as configurações de cluster e gerenciá-las em escala em vários clusters. Qual é a maneira mais elegante de resolver esse pesadelo?

KubeSlice da Avesha é uma maneira simples de obter o melhor dos dois mundos. Ao criar uma conectividade de serviço direta entre clusters ou namespaces, o KubeSlice elimina a necessidade de configurar manualmente a conectividade individual entre clusters Kafka.

Basicamente, o KubeSlice cria um gateway de rede seguro e síncrono de Camada 3 entre clusters; isolado no nível do aplicativo ou do namespace. Depois de configurado, os administradores do Kafka ficam livres para implantar corretores do Kafka em qualquer um dos clusters.

Cada intermediário tem uma conectividade síncrona com todos os outros intermediários associados por meio da fatia, mesmo que os próprios intermediários possam estar em clusters separados. Isso cria efetivamente um cluster estendido entre os corretores e oferece o benefício de uma consistência forte e de baixa sobrecarga de administração.

Pegue seu bolo e coma também!

Para aqueles que desejam implantar o Mirror Maker em seus clusters, isso pode ser feito com esforço mínimo, pois a conectividade entre os clusters é delegada ao KubeSlice. Assim, os aplicativos Kafka podem ter os benefícios da replicação síncrona (velocidade, resiliência) E assíncrona (independência, escala) na mesma implantação, com a capacidade de combinar e combinar os recursos conforme necessário. Isso se aplica a data centers locais, em nuvens públicas ou qualquer combinação destes em uma configuração híbrida.

A melhor parte é que o KubeSlice é uma implantação sem interrupções, o que significa que não há necessidade de desinstalar nenhuma ferramenta já implantada. É simplesmente uma questão de estabelecer uma fatia e adicionar a implantação do Kafka a essa fatia .

Conclusão

Este blog forneceu uma breve visão geral do Apache Kafka e abordou alguns dos casos de uso mais comuns. Abordamos as ferramentas atuais disponíveis para dimensionar implantações do Kafka em vários clusters e discutimos as vantagens/desvantagens de cada uma. Por fim, o artigo também apresentou o Kubeslice – a solução emergente de conectividade de serviço que simplifica as implantações de vários clusters do Kafka e elimina as dores de cabeça associadas à configuração da replicação do Kafka em vários clusters em escala.

Alguns links que os leitores podem achar úteis:

Um blog antigo de práticas recomendadas executando Kafka na AWS (antes da introdução do KubeSlice)

Configuração guiada do KubeSlice

Implantar o Kafka no GKE