Tentando escalar o Apache Kafka? Considere usar o Apache Pulsar

Hoje, mesmo os aplicativos móveis e da Web mais básicos consomem muitos dados. A chave para trocar e agir com base nesses dados é um sistema de mensagens apoiado por uma arquitetura orientada a eventos.

Um sistema orientado a eventos permite que as soluções e o processamento de mensagens sejam escaláveis e assíncronos. Os sistemas assíncronos podem lidar com mais solicitações, pois cada solicitação é tratada em segundo plano.

Quando uma solicitação é feita ao servidor, ela é adicionada a uma fila, onde um processador a lerá. Isso permite que as organizações criem sistemas que aceitem centenas de milhares — ou mesmo milhões — de solicitações por segundo em escala, processando as solicitações em um cluster separado.

A indústria produziu vários sistemas intermediários de mensagens e plataformas de publicação-assinatura (pub-sub) orientadas a tópicos que seguem esse formato orientado a eventos e mensagens. Apache Kafka e Apache Pulsar são dois exemplos amplamente usados de entrega de mensagens distribuídas e sistemas de streaming .

Kafka e Pulsar são construídos em um padrão pub-sub que você pode usar para dimensionar a entrega de mensagens para milhares de clientes conectados. Ambos oferecem um modelo de armazenamento persistente para garantir que as mensagens não sejam perdidas e ambos usam partições para armazenar e processar as mensagens.

Embora o Kafka e o Pulsar sejam semelhantes em muitos aspectos, eles têm algumas diferenças notáveis nos recursos – principalmente ao gerenciar grandes quantidades de dados, criar aplicativos em tempo real e desenvolver em escala.

O Kafka oferece muitos benefícios, mas o suporte do Pulsar para escalabilidade e crescimento é incomparável. E em um determinado ponto do crescimento, a escolha ideal é não mais tentar otimizar o Kafka, mas se separar dele. Aqui, compararemos as diferenças entre Kafka e Pulsar, demonstrando como uma próxima etapa lógica para escalabilidade ao usar Kafka é mudar para Pulsar.

Desafios com aplicativos Apache Kafka

Kafka é o de fato para padrões pub-sub distribuídos na arquitetura de software. Uma organização que usa Kafka é capaz de lidar com milhares de mensagens e transmitir as mensagens para vários consumidores ao mesmo tempo.

Kafka tem vários benefícios , mas também tem certas limitações ao tentar escalar. Vamos explorar alguns desafios que você enfrentará ao tentar dimensionar aplicativos criados com o Apache Kafka.

Limitações de armazenamento

A arquitetura do Kafka cria o primeiro desafio que você enfrentará ao dimensionar seus aplicativos no Kafka: armazenamento.

Stateful brokers são a primeira razão pela qual uma organização acha difícil escalar. Os dados no Kafka são armazenados no nó líder , enquanto as partições de dados são armazenadas no disco local. Os dados estão vinculados aos nós e os corretores no Kafka são stateful. Isso significa que, uma vez que o nó líder tenha atingido a capacidade máxima de armazenamento, o cluster não pode aceitar mais mensagens, a menos que o armazenamento da infraestrutura seja aumentado. Isso é desafiador porque, em um ambiente em constante crescimento, um cluster exigirá vários upgrades.

Uma maneira de superar esse desafio é comprar um grande cluster de armazenamento, que é muito caro.

Além disso, com base nessa arquitetura, uma vez que a plataforma atinge o limite máximo de armazenamento ou memória, ela não pode aceitar novas mensagens recebidas. Isso pode levar a uma grande perda para aplicativos críticos para os negócios. A arquitetura do Kafka foi projetada para aceitar e transmitir muitas mensagens. O armazenamento de dados de longo prazo não é uma prioridade. Como resultado, dimensionar um aplicativo Kafka é muito desafiador porque ele não pode fornecer o armazenamento de que você precisa — pelo menos não sem um preço elevado.

Problemas com processamento de mensagens

O gerenciamento do Kafka é desafiador porque ele não inclui recursos necessários para monitoramento de atividades, processamento de mensagens e persistência de dados.

Kafka brilha para sistemas de transmissão de mensagens sem cabeça, onde você não precisa alterar uma mensagem antes da entrega. No entanto, suponha que você precise processar uma mensagem antes de encaminhá-la aos consumidores; isso requer dependência de plataformas adicionais, o que torna mais desafiador e complexo o processamento de mensagens com Kafka.

Além disso, o envolvimento de outras plataformas como as listadas acima aumenta significativamente a complexidade do seu sistema de entrega de dados, pois cada componente da plataforma de streaming requer manutenção e possui limitações que se aplicam a todo o cluster. Além disso, os clusters Kafka têm dados limitados e persistência de mensagem à medida que seus requisitos de dados aumentam com o tempo.

Bibliotecas de cliente complicadas

As empresas usam principalmente o Kafka para seus serviços de streaming fornecidos. A API de streaming é escrita na parte superior da entrega da mensagem pub-sub para oferecer suporte a um caso de negócios exclusivo . A API do Kafka Streams é um produto autônomo que oferece recursos avançados voltados para clientes corporativos. O recurso mais notável do Kafka Streams, as transações , ajuda as empresas a garantir a consistência da saída gerada pelo fluxo de mensagens. Por esse motivo, o Kafka possui duas APIs separadas para cada caso de uso.

Por exemplo, a biblioteca Kafka Streaming permite que as empresas ofereçam uma entrega “exatamente uma vez” para mensagens. A entrega garante que tanto a oferta Kafka quanto a Pulsar são:

• Pelo menos uma vez
• No máximo uma vez
• Exatamente uma vez

A entrega “exatamente uma vez” garante que, para cada mensagem, haverá uma saída associada, o que garante que a mensagem seja processada em caso de falha do consumidor. No entanto, isso é impossível com a API Consumers , que permite que os aplicativos leiam fluxos de dados de tópicos no cluster Kafka, exigindo que você grave a maioria dos recursos na plataforma. Isso dificulta o uso de uma única biblioteca cliente para todos os recursos necessários para o seu negócio, o que não é sustentável quando você trabalha em escala.

entrar pulsar

Para cada limitação do Kafka destacada acima, a Pulsar tem uma solução. As seções a seguir descrevem alguns dos benefícios do Pulsar.

Armazenamento de dados persistente

O Pulsar fornece os recursos de streaming e publicação de mensagens que o Kafka oferece, mas adiciona a capacidade de persistir os dados por períodos mais longos.

O Pulsar oferece persistência de armazenamento de dados usando o Apache Bookkeeper. O Bookkeeper mantém os dados e ajuda a descarregar a persistência de dados fora do cluster. Você pode usar outros meios de armazenamento de dados, como o AWS S3, para armazenar dados e dimensionar além dos limites de um disco local, o que significa que você pode expandir facilmente seus aplicativos sem preocupações com armazenamento.

Além disso, o Pulsar inclui um recurso de armazenamento em camadas que ajuda a mover os dados entre as opções de armazenamento quente e frio; os dados podem então ser armazenados em armazenamento frio pelo tempo que a empresa precisar. O cluster não requer uma mudança contínua no tamanho da infraestrutura para as opções de armazenamento.

O Pulsar também move automaticamente as mensagens mais antigas do Bookkeeper para uma opção de armazenamento a frio mais barata, tornando um segmento dos dados imutável. O segmento imutável pode ser movido para um armazenamento mais barato, permitindo efetivamente que o Pulsar aceite quantidades infinitas de dados.

Experiência do Desenvolvedor

Do ponto de vista do desenvolvedor, o Pulsar oferece uma biblioteca de cliente simples e integrada para todas as principais linguagens (Java, Python, Go e C#). As bibliotecas ajudam os desenvolvedores a começar a usar a plataforma rapidamente, o que é fundamental ao desenvolver e liberar aplicativos em escala. O protocolo binário do Pulsar estende os recursos da biblioteca do cliente conforme necessário, tornando a biblioteca adequada para crescimento. (Aqui está a lista de bibliotecas cliente Pulsar disponíveis e oficialmente suportadas. )

Funções pulsares

O Pulsar Functions é um recurso pronto para uso que permite aos desenvolvedores escrever código personalizado que pode processar mensagens no fluxo de mensagens sem a necessidade de implantar um sistema como Apache Heron, Apache Flink ou Apache Storm.

As Pulsar Functions são usadas em uma estrutura de conector sem servidor Pulsar IO, facilitando a movimentação de dados de e para o Pulsar. Esse sistema pronto para uso permite que o Pulsar seja conectado a bancos de dados SQL e NoSQL externos, como o Apache Cassandra.

Além disso, esse processamento de mensagens é nativo do fluxo, o que significa que as mensagens são processadas e transformadas dentro do cluster antes de serem entregues aos consumidores. Como o Pulsar Functions é a infraestrutura de computação do sistema de mensagens Pulsar, ele oferece suporte a objetivos de nível de negócios, incluindo produtividade do desenvolvedor, fácil solução de problemas e simplicidade operacional — qualidades cruciais para o desempenho do aplicativo e da equipe ao trabalhar em escala.

Escalabilidade

Além dos recursos e serviços mencionados acima e sua influência na escalabilidade, o Pulsar oferece vários recursos que o tornam uma opção escalável para as necessidades de publicação e transmissão de mensagens de sua empresa.

O recurso de georreplicação do Pulsar permite que o Pulsar seja altamente escalável. O cluster replica os dados para vários locais em todo o mundo para uso no caso de um desastre derrubar o aplicativo. A replicação tem suporte para ser síncrona e assíncrona. A replicação assíncrona é mais rápida, mas fornece menos garantias de consistência de dados do que a replicação síncrona.

A Pulsar usa um conceito de broker por tópico, garantindo que o mesmo broker lide com todas as requisições de um tópico. A arquitetura Pulsar demonstra como a abordagem baseada em corretor melhora o desempenho do sistema em comparação com um cluster Kafka.

Empacotando

Kafka e Pulsar têm algumas semelhanças, mas existem algumas diferenças fundamentais que vale a pena considerar ao selecionar qual plataforma usar — especialmente quando você precisa de escalabilidade.

A arquitetura, os recursos de armazenamento e a usabilidade do Kafka apresentam vários desafios que podem inibir a capacidade de crescimento de uma organização. Tentar dimensionar seus clusters Kafka além de um ponto torna-se caro e geralmente é mais problemático do que vale a pena. Desde a forma como armazena dados até a forma como oferece suporte à transformação de mensagens, o Pulsar é o desafiante unificado de próxima geração do Kafka, criado para escalabilidade.

Saiba mais sobre o DataStax Astra Streaming , construído no Apache Pulsar e entregue como um serviço totalmente gerenciado.

Por Maria Grygleski. Mary é uma defensora do desenvolvedor de streaming na DataStax. Ela se concentra no desenvolvimento de defesa e divulgação da comunidade para Java, código aberto e tecnologia de nuvem, incluindo nuvem nativa, sem servidor, orientada a eventos, microsserviços e arquiteturas reativas.