Por que adotar Kafka para mensageria?

Elemar Júnior

Apache Kafka é uma plataforma robusta para suportar streaming distribuído. Dentre seus diversos atributos positivos, nos chama a atenção como a opção de facto para  CEP (Complex Event Processing).

Entretanto, temos percebido que a solução tem sido utilizada, com frequência, como mecanismo para suportar mensageria. Embora entendamos como uma alternativa viável, não a consideramos a mais adequada.

Nos parece muito mais resoluto utilizar soluções específicas para mensageria como uma das muitas implementações de AMQP – sendo a mais notável, RabbitMQ.

Então, nesse post, estamos abrindo espaço para debate. Adoraríamos entender os critérios que tem levado a escolha de Kafka no lugar de soluções nativamente concebidas para mensageria.

Compartilhe sua visão conosco nos comentários.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
21 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Michael Costa
Michael Costa
3 anos atrás

IMHO, se a empresa já mantém um Kafka, que já é substancialmente complexo, não vejo pq adotar mais outra ferramenta especificamente para mensageria.
Agora se precisa apenas de mensageria, e não tem Kafka, aí sim pode ser interessante usar apenas um RabbitMQ. Isso falando em On-premises.

Elemar Júnior
Elemar Júnior
3 anos atrás

Entendo e concordo com o ponto de vista. Mas, me parece estranho que a empresa precise, primeiro, de um mecanismo para streaming distribuído ANTES de mensageria.

Cesar
Cesar
3 anos atrás

Acredito que muitos estão indo pelo “Boom” do Kafka sem ter tal processamento necessário para tal, porém tem que pensar mil milhões se de fato é a melhor solução para mensageira devido toda a sua complexidade para manter.
O porque não utilizar um AMQP inicialmente? Digo isso porque passei por essa discussão em um projeto e decidimos optar pelo próprio Rabbit.

Lucas
Lucas
3 anos atrás

Na empresa que trabalhei estavamos migrando para o kafka devido sua capacidade de armazenamento e por suportar milhões de mensagens sem dar problemas no servidor/swarm. Não me recordo agora a solução que usavamos antes dele para mensageria, mas quando essa solução chegava em aproximadamente 500/600K de mensagens na fila começava a travar e os consumidores não conseguiam trabalhar, e para “destravar” só removendo as mensagens manualmente. Com kafka esse problema não existe, só vi beneficios em seu uso, apesar da complexidade.

Yan
Yan
3 anos atrás

Bem ainda não tenho propriedade para falar do Kafka, mas gostaria de deixar meu case… Hoje em um contrato para um orgão público adotamos RabbitMQ. Processamos milhões de mensagens por mês e esta ferramenta nunca nos deixou a desejar em quesitos de qualidade como performance, disponibilidade e resiliência. Para alcançarmos isso foram preciso horas de leitura sobre a documentação do RabbitMQ, ler vários cases, entender e modelar uma arquitetura de eventos etc. Ter passado por esse caminho nos deu uma propriedade e confiança sobre a ferramenta que hoje nos atende nos pontos necessários para o projeto.

Luiz Carlos Faria
Luiz Carlos Faria
3 anos atrás

Elemar, a questão é muito mais complexa. Estou preparando um post sobre o tema.

A minha compreensão sobre o tema é semelhante às tuas 2 afirmações:

“Embora entendamos como uma alternativa viável, não a consideramos a mais adequada.”

“Nos parece muito mais resoluto utilizar soluções específicas para mensageria como uma das muitas implementações de AMQP – sendo a mais notável, RabbitMQ.”

Ficando uma exceção, quando eu tenho demandas de complex event processing, como agrupamento, transformação, pipelines, reprocessamento. Demandas típicas de plataformas de stream.

Michael Costa
Michael Costa
3 anos atrás

Num cenário como este sugerido em sua resposta, é realmente estranho adotar uma plataforma de streaming antes de uma de mensageria, fato. Entretanto, a provocação do seu tópico foi quanto a adotar Kafka para mensageria, logo imagino um cenário de uma empresa que já passou pela era SOA, já teve experiência com algum produto para tal (no meu caso usamos amplamente um barramento JMS), e agora começa a mirar objetivos de event sourcing, CDC e demais atribuições que requerem alto throughput, escalabilidade e todas as buzzwords associadas ao Kafka.
Sendo assim, a minha linha de raciocínio é, se você já comprou um carro super equipado, talvez não precise mais ter dois carros, ou mesmo adquirir um mais básico.
Concorda?

Paulo Stefanelli
Paulo Stefanelli
3 anos atrás

Minha experiência com Apache Kafka e essas envolvidas neste tema mostram claramente que uma época atrás se deixaram levar pela “Tecnologia do momento”.

E um fator que ficou muito evidente e pode ter contribuído para isto: Persistência. ” Kafka Persiste “.

Concordo plenamente que tem soluções para uso de ” mensageria” que seriam mais fáceis para casos simples.

De fato, existe alguns itens técnicos no Kafka que são diferenciados :

Persistência do item no tópico para poder consumir posteriormente se necessário, Ponto positivo.

A facilidade para montar um cluster a níveis de configurações em arquivos. Ponto positivo.

Documentação técnica no site da Apache, Ponto positivo.

A leitura ser feita em disco e não em memória, Ponto positivo.

Dimensionamento de partições para distribuir com mais velocidade o dado entre os consumidores aumentando a vazão para cada consumidor , Ponto positivo.

Rebalance no Kafka para quando uso de mtas partições e principalmente em caso de cluster + data centers em regiões distantes , Ponto negativo.

Interface de administração para o ” Apache Kafka” , ponto negativo .

Elemar Júnior
Elemar Júnior
3 anos atrás

Este é o ponto! Não entendo uma solução como o RabbitMQ (ou ZeroMQ, etc) como sendo mais básicas do que o Kafka. Aliás, penso o oposto.

Ferramentas diferentes para problemas diferentes. Mas, entendo o seu ponto: Se a empresa já investiu na implantação do Kafka e ele atende, então, pode não fazer mesmo sentido ter duas soluções.

Elemar Júnior
Elemar Júnior
3 anos atrás

Como argumentei, entendemos que Kafka resolva um conjunto diferente de problemas. Não acho, mesmo, que AMQP seja “solução inicial”, mas sim “solução ideal”

Elemar Júnior
Elemar Júnior
3 anos atrás

Vocês estavam acumulando 600K mensagens? Fiquei curioso com a natureza da aplicação

Elemar Júnior
Elemar Júnior
3 anos atrás

Persistência é um ótimo ponto.

Mas, fiquei curioso para o cenário em que isso é fundamental, da forma como está destacando.

Lucas
Lucas
3 anos atrás

As aplicações faziam a integração dos Documentos Fiscais Eletrônicos com outras SEFAZ e outros sistemas internos. Ainda utilizavamos o kafka para entregar as informações diretamente no Apache Nifi que fazia o processamento e quebra dos XML’s dentro do Hadoop.
Não trabalhei com o Rabbit ainda, fiquei curioso para vê-lo funcionando, creio que em breve vou implementar algo para testa-lo.

Luís Gabriel Nascimento Simas
Luís Gabriel Nascimento Simas
3 anos atrás

Quando eu li a primeira vez sobre Kafka, pensei: por quê não RabbitMQ? O Rabbit também têm persistência de mensagens, existe um flag no qual você informa se quer mantê-lo em disco ou não. O Kafka me parece uma Ferrari. Claro que ele têm muitas soluções em uma só como o Broker, Stream e Zoekeeper… mas, em um Projeto de Médio porte e Grande porte bem menor que Uber e Netflix, vale a pena investir?

RabbitMQ:
1. Consumer
2. Publisher
3. Exchange
4. Route

Kafka:
1. Consumer / Consumer groups
2. Producer
3. Kafka source connect
4. Kafka sink connect
5. Topic and topic partition
6. Kafka stream
7. Broker
8. Zookeeper

Fonte: https://itnext.io/kafka-vs-rabbitmq-f5abc02e3912

Luís Gabriel Nascimento Simas
Luís Gabriel Nascimento Simas
3 anos atrás

Faria.

Quando trabalhamos na Órama, um Banco de Investimentos com zilhões de operações, eu e o Rodrigo Lopes, que agora trabalha aí com você, desenvolvemos uma solução de mensageria utilizando o RabbitMQ, não tivemos problemas, porém, pelo que andei lendo e conversando parece que o Kafka é mais “resiliente”, porém, com o fluxo que utulizávamos lá, o RabbitMQ em cima de um container Docker… funcionava muito bem!

Estou ansioso para ler o seu artigo sobre o melhor de ambas!

Forte Abraço, camarada!

Walter Cardoso
Walter Cardoso
3 anos atrás

Talvez porque seja a “tecnologia hipster do momento”, onde trabalho atualmente o SQS nos atende facilmente, usar Kafka seria um canhão para matar uma formiga.

Paulo Stefanelli
Paulo Stefanelli
3 anos atrás

Como trabalho em uma empresa de meio de pagamentos, e o volume eh muito grande, eh muito prático ter e poder reprocessar os itens quando a ” próxima camada/evento tem uma falha que eh catastrófica”.

De certa maneira, eh um cenário que já presenciei e realmente nos ajudou!

Wesley
Wesley
3 anos atrás

Apenas especulando sobre a forma que implementaram e defendendo o RabbitMQ.

Quanto o RabbitMQ esgota algum recurso (memória, disco, etc) ele trava as conexões onde tem producers. O seu caso pode ter acontecido isso porque os consumers e producers estavam compartilhando a mesma conexão. Eles recomendam utilizar conexões diferentes para producers e consumers.

HUGO ESTEVAM ROMEU LONGO
HUGO ESTEVAM ROMEU LONGO
3 anos atrás

Elemar,

Primeiramente belo tema, estou acompanhando os desdobramentos nos comentários, para ver se aprendo algo.

Aqui no trabalho não adotamos o KAFKA como solução de mensageria, entretanto estamos estudando e fazendo alguns laboratórios. Acredito que o ponto importante que resume porque levar o Kafka em consideração é PERFORMANCE.

O RabbitMQ por padrão, implementa filas que mantém as mensagens em cache na memória. Essas mensagens vão para esse cache assim que elas são publicadas no RabbitMQ. Quando o Broker precisa liberar memória, as mensagens desse cache são paginadas em disco . A paginação de um lote de mensagens no disco leva tempo e bloqueia o processo da fila, impossibilitando o recebimento de novas mensagens durante a paginação. Outro aspecto desse modelo é que se a aplicação falhar (como vc diz, ela vai falhar) o processo de preenchimento desse cache em memória após um restart de serviço, também pode ser demorado se existir uma grande quantidade de mensagens.

O KAFKA, sabendo desse problema de pressão na memória, implementou um design diferente, que ao invés de manter as mensagens em memória, persiste elas diretamente no sistema de arquivos. Na documentação do KAFKA eles explicam esse design “pagecache-centric” com exemplos de porquê uma implementação de gravações lineares (usando pagecache do SO) em disco pode ser mais eficiente que gravações em memória. No caso do restart do serviço em possível falha, não há necessidade de “carregar” as mensagens, pois elas já estão no pagecache do SO.

Ainda não testei essa situação na prática, mas se não estou engano isso vai na mesma linha do que seu colega @Ayende falou em uma apresentação de performance do RavenDB, dizendo que fizeram uma melhoria para não ter mais cache em memória e em contrapartida passaram a explorar mais o uso de pagecache do SO. Me parece um grande benefício quando se trata de aplicações que fazem muito I/O.

Rafael Schettino
Rafael Schettino
3 anos atrás

Meu cenário é parecido. Temos integração com muitos parceiros e frequentemente precisamos reprocessar pedidos. Sem o Kafka, tivemos que desenvolver módulos adicionais que consultam pedidos no BD pelo status e colocam eles novamente para a fila. Com a possibilidade de replay do Kafka e o devido controle de duplicidade nos consumers, isso simplifica muito a solução.

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas e profissionais a gerar mais resultados através da tecnologia.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Engenharia de Software

Três vantagens reais de utilizar orquestradores BPM para serviços

Arquiteto de software e solução com larga experiência corporativa
Desenvolvimento de Software

Os principais desafios ao adotar testes

Especialista em Testes e Arquitetura de Software
Arquitetura de Dados

Insights de um DBA na análise de um plano de execução

Especialista em performance de Bancos de Dados de larga escala

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

21
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Por que adotar Kafka para mensageria?

Para se candidatar nesta turma aberta, preencha o formulário a seguir:

Condição especial de pré-venda: R$ 14.000,00 - contratando a mentoria até até 31/01/2023 e R$ 15.000,00 - contratando a mentoria a partir de 01/02/2023, em até 12x com taxas.

Tenho interesse nessa capacitação

Para solicitar mais informações sobre essa capacitação para a sua empresa, preencha o formulário a seguir:

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?