Neste artigo, busco abordar de forma objetiva e clara conceitos, funcionalidades e alguns exemplos de arquiteturas com o Apache Kafka. Acredito que o Apache Kafka, nos últimos anos, ganhou uma maior adesão devido à era do Big data e Data Science. Período em que as empresas, que tradicionalmente utilizavam o cenário de Bussiness Intelligence clássico (ETL), tiveram a necessidade de obter a informação de forma mais rápida, seja pelo crescimento de aplicativos que as empresas dependam hoje para se enquadrarem na concorrência, como mídias sociais, aplicativos mobile e ferramentas auxiliares ou, até mesmo, pelo crescimento da própria empresa onde o trafego de informações do seu sistema principal aumentou consideravelmente. Com isso, as companhias se viram na necessidade de mudar a arquitetura atual para algo mais rápido na captura de informações, que fosse escalável e mais próximo possível de tolerância a falhas.

Durante meus estudos observei adesão recente do Apache Kafka até mesmo por grandes empresas que tinham uma arquitetura de captura de dados, mas de forma “não streaming”. Um exemplo foi a palestra “Do PostgreSQL ao Data Lake utilizando Kafka|Debezium” do Paulo Singaretti no infoQ – Brasil onde ele demostra a evolução da arquitetura do iFood, de um cenário de refinação dos dados de Postgresql/Postgresql, em que era feito um dump da base toda do Postgresql para um cenário de Postgresql com Debezium do Apache Kafka e alimentação de um DataLake.

Brevemente, o que é o Apache Kafka?

O Apache Kafka é uma plataforma de software de código fonte aberto para processamento de fluxo de mensagens escrita em Scala com Java. Entre as vantagens da plataforma podemos enfatizar sua forma de unificar os seus componentes e Plugins externos, baixa latência e alto rendimento se aproximando e muito do Feed de dados em tempo real.

Conceitos que envolvem o Apache Kafka:

Primeiramente, antes de entrarmos mais a fundo sobre o Apache Kafka, devemos entender melhor alguns conceitos que envolvem esta plataforma

• Mensagens – Entenda por mensagens toda a informação que trafega sobre o Apache Kafka, seja uma frase, uma palavra, um array de bytes etc..
• Streaming – O Streaming aplicado nesta plataforma se trata de todo fluxo de uma mensagem até a captura pelo Apache Kafka e o consumo desta mensagem, onde temos o seguinte cenário: Ator -> Ação -> Gera x mensagens, ou seja, um fluxo de pedido por exemplo: Operador de caixa->Criação->Pedido e deste fluxo pode existir uma serie de mensagens.
• Tópico – Um tópico é uma forma de rotular ou categorizar uma mensagem, imagine um armário com 10 gavetas, cada gaveta pode ser um tópico e o armário é a plataforma Apache Kafka, portanto alem de categorizar ele agrupa as mensagens, uma outra analogia melhor sobre o tópico seria tabelas em banco de dados relacionais.
• Producer – O producer ou produtor é quem se conecta a uma plataforma de mensagens e envia uma ou mais mensagens para um tópico especifico.
• Consumer – O consumer ou consumidor é quem se conecta a uma plataforma de mensagens e consome uma ou mais mensagens de um tópico especifico.
• Broker – O conceito de broker na plataforma do Kafka é nada mais do que praticamente o proprio Kafka, ele é quem gerencia os tópicos, define a forma de armazenamento das mensagens, logs etc.
• Cluster – O conceito de cluster é nada mais do que um conjunto de Brokers que se comunicam entre si ou não para uma melhor escalabilidade e tolerância a falhas.
• Log file – Cada tópico armazena seus registros em um formato de log, ou seja, de forma estrutura e sequencial, o log file portanto são os arquivos que contem a informação de um tópico.
• Partitions – As partitions ou partições como o próprio nome disse é a camada de partição das mensagens dentro de um tópico, este particionamento garante a elasticidade, tolerância a falha e escalabilidade do Apache Kafka, portanto cada tópico pode ter varias partições em diferentes localidades.
• Replicas – As replicas são como partições das partições, elas tem o mesmo papel da partição mas como uma forma de redundância de determinada partição, portanto as partições Kafka são altamente disponíveis e replicadas, quando os dados do fluxo são persistentes no Kafka, eles ficam disponíveis mesmo que o aplicativo falhe
• Segmentos – Os segmentos ficam dentro das partições e segmentam as informações contidas nos logs files daquela partição, todo tópico possui sua partição e sua segmentação, a segmentação serve para gerenciar a ordenação da informação do log file bem como o tempo que ela ira ficar persistida.

Estes são os principais conceitos do Apache Kafka devem ser compreendidos, repare que este conjunto de conceitos é o que torna a arquitetura do Kafka escalável, performática e tolerante a falha.

Principais componentes do Apache Kafka.

Agora vamos falar dos componentes do próprio Apache Kafka e também de alguns componentes complementares não obrigatórios de sua arquitetura. Primeiro componente super importante do Apache Kafka é o Zookeeper, todo Broker presente um cluster ou não é mapeado e monitorado pelo Zookeeper, ele é um sistema centralizado desenvolvido pela própria Apache Kafka para manter o controle do status de cada broker e cluster, também faz o controle de cada tópico, partições etc. Eu posso possui um Zookeeper central para um ou mais cluster mas também posso possui um Zookeeper para cada broker ou cluster e eles se comunicam entre si, portanto o Zookeeper é quem garante meu failover caso um cluster venha a falhar.

Ainda falando sobre o ZooKeeper, precisamos abordar sobre o ISR – In Sync Replicas, os tópicos como vimos anteriormente são divididos em partições e cada partição possui suas replicas, como ambos são provenientes de um tópico, existe a eleição dos Leaders que é a partição principal no qual as replicas devem ficar “seguindo” ou replicando os dados, desta forma o Lead é quem serve todas as leituras e armazenamentos de um tópico, o ISR é um serviço dentro do ZooKeeper que acompanha dinamicamente esta eleição dos Leaders e persiste no ZooKeeper, o ISR também possui todas as mensagens confirmadas pelos Leaders ou seja, as mensagens que realmente foram persistidas e desta forma ele pode eleger o Lead com as mensagens mais recentes em um cenário de failover.

Apache Kafka Connect

Agora falando de outro componente presente na plataforma Apache Kafka, o connect é uma ferramenta para transmitir dados de vários tipos de origens para um tópico e de um tópico para vários tipos de destinos:

Ele possui uma interface Rest para gerenciamento dos conectores e possui diversas formas de injeção de dados e de diversas origens, assim como um cluster de brokers o Kafka Connect pode possui um mais em execução e dentro de sua estrutura pode possuir um ou mais workers que são os responsáveis por “pingar” na fonte de dados e realizar o trabalho no qual foi configurado, em um outro artigo pretendo utilizar o Kafka connect para simular a tolerância de falhas, mas de forma geral o Kafka Connect gerencia o deslocamento de injeção dos dados automaticamente com apenas algumas informações que são informadas na sua configuração padrão ou na atribuição de novos connectores através da api rest que é fornecida.

Arquiteturas e cenários:

Diante de tudo que foi abordado anteriormente vamos agora juntar tudo isso e desenhar aqui algumas arquiteturas e discutir a escalabilidade e tolerância a falha para um entendimento melhor como um todo do Apache Kafka.

Na arquitetura acima temos 2 Producers e 3 Consumers, no qual os producers estão se conectando a cada um a um Broker especifico assim como os consumers, temos um Kafka Cluster com o total de 6 Brokers em execução, onde estão divididos em 2 rack de servidores e apenas um Zookeeper para cada conjunto dos 3 Brokers, portanto os brokers 1,2 e 3 estão apontando para o ZooKeeper 1 e os brokers 4,5 e 6 estão apontando para o Zookeeper-3. Até aqui apenas deixamos de forma mais visual o que vimos anteriormente, agora vamos simular alguns cenários e adentrar mais nesta arquitetura.

Cada Producer de nossa arquitetura é na verdade um PDV é um ponto de venda onde foi gerado 3 pedidos por cada producer e enviado a um tópico de Pedidos por exemplo.

Agora configuramos nosso tópico para que ele tenha um total de 3 replicas e 10 partições em cada replica, totalizando um total de 30 Log files.

Realizando a distribuição das partições teríamos algo na pratica parecido com a arquitetura acima, reparem que temos partições do 0 até o 9 pois na prática o Kafka distribui iniciando em 0 e observe também que existe Brokers com as mesmas partições, por exemplo a partição 0 que esta presente no Broker 1,2 e 3 isso se deve ao nosso fator de replica ser 3.

Agora vamos ver como fica a questão dos Leaders e os followers dos Leaders

Observe na imagem acima que foi distribuido as partições leaders de cada Broker e seus Followers (demais replicas), portanto por exemplo do Rack 1 – Broker 0 temos dois Leaders definidos Partição 0 e 6 e suas replicas são a partição 5 e partição 4, apenas lembrando que quem controla esta lista de Leaders e Followers é o ISR – In Sync replicas.

A forma como é distribuído as partições não é aleatória, o Apache Kafka distribui seguindo uma forma de loterancia a falha de acordo com o a arquitetura de todo o Cluster, onde caso uma partição Leader fique offline outra ja é definida. Importante também frisar a importância da localização dos Racks, em nosso caso como possuímos 2 racks, a distancia entre eles não pode ser grande, pois conforme evidenciei nas arquiteturas acima, existe partições de Broker em outro Rack e caso a região seja distante ou seja, caso exista problemas de rede, pode ser que se tenha uma latência e dependente das configurações do seu Zookeeper e ISR pode ser considerado que o determinado broker esteja offline devido ao timeout de resposta e seja elegido outro Leader.

Conclusão

O Apache Kafka vem tendo uma adotação rápida no mercado e muito se tem falado sobre diante dos cenários de Big data e Data Science, devido a sua escalabilidade e tolerância a falha o Kafka é ideal para trabalhar com integrações de sistemas através de mensagens em tempo real e também ser utilizado como um grande centralizador para os diversos sistemas que existir em sua companhia ou projeto, no entanto é de grande importância um bom desenho da sua arquitetura e configurações visto sua grande complexidade.

Referências:

• Livro Apache Kafka, autor – Nishant Garg.
• Livro Kafka Streams – Real-time Stream Processing, autor – Prashant Kumar Pandey.
• Documentação Confluent.io

Artigo original publicado nas redes sociais do autor e republicado no iMasters a pedido do autor.