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.
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.
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.
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.
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.
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.
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.
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?
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 .
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.
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”
Vocês estavam acumulando 600K mensagens? Fiquei curioso com a natureza da aplicação
Persistência é um ótimo ponto.
Mas, fiquei curioso para o cenário em que isso é fundamental, da forma como está destacando.
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.
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
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!
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.
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!
Olhem esse paper aqui: http://www-inf.telecom-sudparis.eu/COURS/CILS-IAAIO/Articles/debs_kafka_versus_rabbitmq.pdf
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.
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.
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.