Este é um artigo traduzido originalmente publicado dia 30/5/2022 no blog do Kai Waehner: "Error Handling via Dead Letter Queue in Apache Kafka". Assine a newsletter do Kai para se manter atualizado com novas publicações.
Reconhecer e lidar com erros é essencial para qualquer pipeline de streaming de dados confiável. Esta postagem de blog explora as práticas recomendadas para implementar o tratamento de erros usando uma Dead Letter Queue na infraestrutura do Apache Kafka. As opções incluem uma implementação personalizada, Kafka Streams, Kafka Connect, a estrutura Spring e o Parallel Consumer. Estudos de caso do mundo real mostram como Uber, CrowdStrike e Santander Bank constroem um tratamento confiável de erros em tempo real em uma escala extrema.
Reconhecer e lidar com erros é essencial para qualquer pipeline de streaming de dados confiável. Esta postagem do blog explora as práticas recomendadas para implementar o tratamento de erros usando uma Dead Letter Queue na infraestrutura Apache Kafka . As opções incluem uma implementação personalizada, Kafka Streams, Kafka Connect, a estrutura Spring e o Parallel Consumer. Estudos de caso do mundo real mostram como Uber, CrowdStrike e Santander Bank constroem um tratamento confiável de erros em tempo real em uma escala extrema.
O Apache Kafka tornou-se o middleware de integração favorito para muitas arquiteturas corporativas. Mesmo para uma estratégia que prioriza a nuvem, as empresas aproveitam o streaming de dados com o Kafka como uma plataforma de integração nativa da nuvem como serviço (iPaaS) .
Padrões de fila de mensagens em streaming de dados com Apache Kafka
Antes de entrar neste post, quero que você saiba que este conteúdo faz parte de uma série de blogs sobre “JMS, Message Queues e Apache Kafka” :
10 Critérios de comparação para JMS Message Broker vs. Apache Kafka Data Streaming (post original: Comparison: JMS Message Queue vs. Apache Kafka)
ESTE POST – Alternativas para tratamento de erros por meio de uma Dead Letter Queue (DLQ) no Apache Kafka
Implementando o padrão de solicitação-resposta com o Apache Kafka
PRÓXIMO – Uma árvore de decisão para escolher o sistema de mensagens certo (JMS vs. Apache Kafka)
PRÓXIMO – Do JMS Message Broker ao Apache Kafka: Integração, Migração e/ou Substituição
Vou linkar os outros posts aqui assim que estiverem disponíveis. Por favor , siga minha newsletter para se atualizar em tempo real sobre novos posts . (sem spam ou anúncios)
O que é o pattern de integração da Dead Letter Queue (no Apache Kafka)?
A Dead Letter Queue (DLQ) é uma implementação de serviço dentro de um sistema de mensagens ou plataforma de streaming de dados para armazenar mensagens que não são processadas com sucesso . Em vez de despejar passivamente a mensagem, o sistema a move para uma Dead Letter Queue.
Os patterns de integração empresarial (EIP) chamam o padrão de design de Dead Letter Channel . Podemos usar ambos como sinônimos.
Este artigo se concentra na plataforma de streaming de dados Apache Kafka. A principal razão para colocar uma mensagem em um DLQ no Kafka é geralmente um formato de mensagem incorreto ou conteúdo de mensagem inválido/ausente . Por exemplo, ocorre um erro de aplicativo se espera-se que um valor seja um Integer, mas o produtor envia um String. Em ambientes mais dinâmicos, uma exceção “Tópico não existe” pode ser outro erro pelo qual a mensagem não pode ser entregue.
Portanto, como sempre, não use o conhecimento de sua experiência de middleware existente. O middleware do Message Queue, como IBM MQ, TIBCO EMS ou RabbitMQ compatível com JMS, funciona de maneira diferente de um log de confirmação distribuído como Kafka. Um DLQ em uma fila de mensagens é usado em sistemas de enfileiramento de mensagens por muitos outros motivos que não mapeiam um para um para Kafka. Por exemplo, a mensagem em um sistema MQ expira devido ao TTL (tempo de vida) por mensagem.
Portanto, o principal motivo para colocar mensagens em um DLQ no Kafka é um formato de mensagem incorreto ou conteúdo de mensagem inválido/ausente .
Alternativas para uma Dead Letter Queue no Apache Kafka
Uma Dead Letter Queue no Kafka é um ou mais tópicos do Kafka que recebem e armazenam mensagens que não puderam ser processadas em outro pipeline de streaming devido a um erro . Este conceito permite continuar o fluxo de mensagens com as seguintes mensagens recebidas sem interromper o fluxo de trabalho devido ao erro da mensagem inválida.
O Kafka Broker é burro – Smart Endpoints fornecem o tratamento de erros
A arquitetura Kafka não suporta DLQ dentro do broker . Intencionalmente, o Kafka foi construído com os mesmos princípios dos microsserviços modernos usando o princípio de ' tubos burros e terminais inteligentes '. É por isso que o Kafka se adapta tão bem em comparação com os corretores de mensagens tradicionais. A filtragem e o tratamento de erros acontecem nos aplicativos clientes.
A verdadeira dissociação da plataforma de streaming de dados permite um design orientado por domínio muito mais limpo. Cada microsserviço ou aplicativo implementa sua lógica com sua própria escolha de tecnologia, paradigma de comunicação e tratamento de erros .
Em middleware e filas de mensagens tradicionais, o broker fornece essa lógica. A consequência é pior escalabilidade e menos flexibilidade nos domínios, pois somente a equipe de middleware pode implementar a lógica de integração.
Implementação personalizada de uma dead letter queue Kafka em qualquer linguagem de programação
Uma Dead Letter Queue no Kafka é independente da estrutura que você usa. Alguns componentes fornecem recursos prontos para uso para tratamento de erros e Dead Letter Queues. No entanto, também é fácil escrever sua lógica Dead Letter Queue para aplicativos Kafka em qualquer linguagem de programação como Java, Go, C++, Python, etc.
O código-fonte para uma implementação de Dead Letter Queue contém um bloco try-cath para lidar com exceções esperadas ou inesperadas . A mensagem é processada se não ocorrer nenhum erro. Envie a mensagem para um tópico DLQ Kafka dedicado se ocorrer alguma exceção.
A causa da falha deve ser adicionada ao cabeçalho da mensagem Kafka . A chave e o valor não devem ser alterados para que o reprocessamento futuro e a análise de falhas de eventos históricos sejam diretos.
Implementações de Kafka prontas para uso para uma dead letter queue
Você nem sempre precisa implementar sua Dead Letter Queue. Muitos componentes e estruturas já fornecem sua implementação DLQ.
Com seus próprios aplicativos, geralmente você pode controlar erros ou corrigir o código quando houver erros. No entanto, a integração com aplicativos de terceiros não permite necessariamente que você lide com erros que podem ser introduzidos através da barreira de integração . Portanto, DLQ se torna mais importante e é incluído como parte de alguns frameworks.
Dead Letter Queue integrada no Kafka Connect
Kafka Connect é a estrutura de integração do Kafka . Ele está incluído no download do Kafka de código aberto. Nenhuma dependência adicional é necessária (além dos próprios conectores que você implanta no cluster do Connect).
Por padrão, a tarefa Kafka Connect é interrompida se ocorrer um erro devido ao consumo de uma mensagem inválida (como quando o conversor JSON errado é usado em vez do conversor AVRO correto). Descartar mensagens inválidas é outra opção. Este último tolera erros.
A configuração do DLQ no Kafka Connect é simples. Basta definir os valores para as duas opções de configuração 'errors.tolerance' e 'errors.deadletterqueue.topic.name' com os valores corretos:
A postagem do blog ' Kafka Connect Deep Dive – Error Handling and Dead Letter Queues ' mostra um exemplo de código prático detalhado para usar DLQs.
O Kafka Connect pode até ser usado para processar a mensagem de erro no DLQ . Basta implantar outro conector que consome do tópico DLQ. Por exemplo, se seu aplicativo processar mensagens Avro e uma mensagem recebida estiver no formato JSON. Um conector então consome a mensagem JSON e a transforma em uma mensagem AVRO para ser reprocessada com sucesso:
Observe que o Kafka Connect não possui Dead Letter Queue para conectores de origem .
Tratamento de erros em um aplicativo Kafka Streams
Kafka Streams é a biblioteca de processamento de fluxo do Kafka . É comparável a outras estruturas de streaming, como Apache Flink, Storm, Beam e ferramentas semelhantes. No entanto, é nativo de Kafka. Isso significa que você cria o streaming de dados completo de ponta a ponta em uma única infraestrutura escalável e confiável.
Se você usa Java, respectivamente, o ecossistema JVM, para construir aplicativos Kafka, a recomendação é quase sempre usar Kafka Streams em vez do cliente Java padrão para Kafka . Por quê?
O Kafka Streams é “apenas” um wrapper em torno do produtor Java regular e da API do consumidor, além de muitos recursos adicionais integrados.
Ambos são apenas uma biblioteca (arquivo JAR) embutida em seu aplicativo Java.
Ambos fazem parte do download do Kafka de código aberto - sem dependências adicionais ou alterações de licença.
Muitos problemas já são resolvidos imediatamente para criar serviços de processamento de fluxo maduros (funções de streaming, armazenamento integrado com estado, janelas deslizantes, consultas interativas, tratamento de erros e muito mais).
Uma das funções internas do Kafka Streams é o manipulador de exceção de desserialização padrão . Ele permite que você gerencie exceções de registro que falham ao desserializar. Dados corrompidos, lógica de serialização incorreta ou tipos de registro não manipulados podem causar o erro. O recurso não é chamado Dead Letter Queue, mas resolve o mesmo problema imediatamente.
Tratamento de erros com Spring Kafka e Spring Cloud Stream
A estrutura Spring tem excelente suporte para Apache Kafka. Ele fornece muitos modelos para evitar escrever código clichê sozinho. O Spring-Kafka e o Spring Cloud Stream Kafka suportam várias opções de repetição e tratamento de erros , incluindo repetição baseada em tempo/contagem, Dead Letter Queues, etc.
Embora a estrutura Spring seja bastante rica em recursos, ela é um pouco pesada e tem uma curva de aprendizado. Portanto, é uma ótima opção para um projeto greenfield ou se você já estiver usando o Spring para seus projetos em outros cenários.
Existem muitas postagens de blog excelentes que mostram diferentes exemplos e opções de configuração. Há também o exemplo oficial do Spring Cloud Stream para filas de mensagens mortas . O Spring permite construir lógica, como DLQ, com anotações simples. Essa abordagem de programação é um paradigma amado por alguns desenvolvedores, enquanto outros não gostam. Basta conhecer as opções e escolher a certa para você.
Processamento escalável e tratamento de erros com o consumidor paralelo para Apache Kafka
Em muitas conversas com clientes, muitas vezes o principal motivo para solicitar uma dead letter queue é lidar com falhas na conexão com serviços da Web ou bancos de dados externos . O tempo limite ou a incapacidade do Kafka de enviar várias solicitações em paralelo derruba alguns aplicativos. Existe uma excelente solução para este problema:
O Parallel Consumer for Apache Kafka é um projeto de código aberto sob a licença Apache 2.0. Ele fornece um wrapper de cliente Apache Kafka paralelo com enfileiramento do lado do cliente, uma API de consumidor/produtor mais simples com simultaneidade de chave e processamento de E/S extensível sem bloqueio .
Essa biblioteca permite processar mensagens em paralelo por meio de um único Kafka Consumer, o que significa que você pode aumentar o paralelismo do consumidor Kafka sem aumentar o número de partições no tópico que pretende processar. Para muitos casos de uso, isso melhora a taxa de transferência e a latência reduzindo a carga em seus agentes Kafka . Também abre novos casos de uso, como paralelismo extremo, enriquecimento de dados externos e enfileiramento.
Um recurso importante é manipular/repetir chamadas de serviços da Web e banco de dados em um único aplicativo de consumidor Kafka . A paralelização evita a necessidade de uma única requisição web enviada por vez:
O cliente Parallel Consumer tem uma lógica de repetição poderosa . Isso inclui atrasos configuráveis e er ou manuseio dinâmico. Os erros também podem ser enviados para uma dead letter queue.
Consumindo mensagens de uma Dead Letter Queue
Você não terminou depois de enviar erros para uma dead letter queue! As mensagens ruins precisam ser processadas ou pelo menos monitoradas!
Dead Letter Queue é uma excelente maneira de tirar o processamento de erros de dados fora da banda do processamento de eventos, o que significa que os manipuladores de erros podem ser criados ou evoluídos separadamente do código de processamento de eventos.
Existem muitas estratégias de tratamento de erros para o uso de filas de mensagens mortas. DOs e DONTs exploram as melhores práticas e lições aprendidas.
Estratégias de tratamento de erros
Várias opções estão disponíveis para lidar com mensagens armazenadas em uma dead letter queue:
Reprocessar : Algumas mensagens na DLQ precisam ser reprocessadas. No entanto, primeiro, o problema precisa ser corrigido. A solução pode ser um script automático, interação humana para editar a mensagem ou retornar um erro ao produtor solicitando o reenvio da mensagem (corrigida).
Elimine as mensagens inválidas (após uma análise mais aprofundada) : Mensagens inválidas podem ser esperadas dependendo da sua configuração. No entanto, antes de eliminá-los, um processo de negócios deve examiná-los. Por exemplo, um aplicativo de painel pode consumir as mensagens de erro e visualizá-las.
Análise avançada : em vez de processar cada mensagem no DLQ, outra opção é analisar os dados recebidos para obter insights ou problemas em tempo real. Por exemplo, um aplicativo ksqlDB simples pode aplicar processamento de fluxo para cálculos, como o número médio de mensagens de erro por hora ou quaisquer outros insights que ajudem a decidir sobre os erros em seus aplicativos Kafka.
Interrompa o fluxo de trabalho : se raramente forem esperadas mensagens inválidas, a consequência pode ser a interrupção do processo geral de negócios. A ação pode ser automatizada ou decidida por um humano. Obviamente, interromper o fluxo de trabalho também pode ser feito no aplicativo Kafka que gera o erro. O DLQ externaliza o problema e a tomada de decisão, se necessário.
Ignorar : Esta pode parecer a pior opção. Apenas deixe a dead letter queue encher e não faça nada. No entanto, mesmo isso é bom em alguns casos de uso, como monitorar o comportamento geral do aplicativo Kafka. Lembre-se de que um tópico Kafka tem um tempo de retenção e as mensagens são removidas do tópico após esse tempo. Basta configurar isso da maneira certa para você. E monitore o tópico DLQ quanto a comportamentos inesperados (como encher muito rapidamente).
Práticas recomendadas para uma dead letter queue no Apache Kafka
Aqui estão algumas práticas recomendadas e lições aprendidas para tratamento de erros usando uma Dead Letter Queue em aplicativos Kafka:
Definir um processo de negócios para lidar com mensagens inválidas (automatizadas versus humanas)
Realidade: Muitas vezes, ninguém lida com mensagens DLQ
Alternativa 1: Os proprietários dos dados precisam receber os alertas, não apenas a equipe de infraestrutura
Alternativa 2: Um alerta deve notificar a equipe do sistema de registro de que os dados estavam incorretos, e eles precisarão reenviar/corrigir os dados do sistema de registro.
Caso ninguém se importe ou reclame, considere questionar e rever a necessidade da existência da DLQ. Em vez disso, essas mensagens também podem ser ignoradas no aplicativo Kafka inicial. Isso economiza muita carga de rede, infraestrutura e dinheiro.
Crie um painel com alertas adequados e integre as equipes relevantes (por exemplo, por e-mail ou alertas do Slack)
Defina a prioridade de tratamento de erros por tópico Kafka (parar vs. soltar vs. reprocessar)
Envie apenas mensagens de erro que não podem ser repetidas para um DLQ – problemas de conexão são de responsabilidade do aplicativo consumidor.
Mantenha as mensagens originais e armazene-as na DLQ (com cabeçalhos adicionais, como a mensagem de erro, hora do erro, nome do aplicativo onde ocorreu o erro, etc.) – isso torna o reprocessamento e a solução de problemas muito mais acessíveis.
Pense em quantos tópicos Dead Letter Queue Kafka você precisa . Sempre há trocas. Mas armazenar todos os erros em um único DLQ pode não fazer sentido para análise e reprocessamento adicionais.
Lembre-se de que um DLQ elimina o processamento em ordem garantida e torna qualquer tipo de processamento offline muito mais difícil . Portanto, um Kafka DLQ não é perfeito para todos os casos de uso.
Quando NÃO usar uma Dead Letter Queue no Kafka?
Vamos explorar quais tipos de mensagens você NÃO deve colocar em uma Dead Letter Queue no Kafka:
DLQ para manuseio de contrapressão? Usar o DLQ para limitação devido a um pico de um alto volume de mensagens não é uma boa ideia. O armazenamento atrás do log Kafka lida com a contrapressão automaticamente. O consumidor extrai dados da maneira que pode levá-los em seu ritmo (ou está mal configurado). Escale os consumidores de forma elástica, se possível. Um DLQ não ajuda, mesmo que seu armazenamento fique cheio. Esse é o problema dele, independente de usar ou não uma DLQ.
DLQ para falhas de conexão? Colocar mensagens em um DLQ devido à falha de conectividade não ajuda (mesmo após várias tentativas). A mensagem a seguir também não pode se conectar a esse sistema. Você precisa corrigir o problema de conexão. As mensagens podem ser armazenadas no tópico regular pelo tempo que for necessário (dependendo do tempo de retenção).
Registro de esquema para governança de dados e prevenção de erros
Por último, mas não menos importante, vamos explorar a possibilidade de reduzir ou até mesmo eliminar a necessidade de uma Dead Letter Queue em alguns cenários.
O Schema Registry for Kafka é uma forma de garantir a limpeza de dados para evitar erros na carga útil dos produtores . Ele impõe a estrutura de mensagem correta no produtor Kafka:
Schema Registry é uma verificação do esquema do lado do cliente. Algumas implementações como o Confluent Server fornecem uma verificação de esquema adicional no lado do broker para rejeitar mensagens inválidas ou maliciosas que vêm de um produtor que não está usando o Schema Registry.
Estudos de caso para uma Dead Letter Queue em Kafka
Vejamos três estudos de caso do Uber, CrowdStrike e Santander Bank para implantação no mundo real de Dead Letter Queues em uma infraestrutura Kafka . Tenha em mente que esses são exemplos muito maduros. Nem todo projeto precisa de tanta complexidade.
Uber – Construindo reprocessamento confiável e filas de mensagens mortas
Em sistemas distribuídos, as tentativas são inevitáveis. De erros de rede a problemas de replicação e até mesmo interrupções em dependências de downstream, os serviços que operam em grande escala devem estar preparados para encontrar, identificar e lidar com falhas da maneira mais tranquila possível.
Dado o escopo e o ritmo em que a Uber opera, seus sistemas devem ser tolerantes a falhas e intransigentes ao falhar de forma inteligente . A Uber aproveita o Apache Kafka para vários casos de uso em uma escala extrema para conseguir isso.
Usando essas propriedades, a equipe de Engenharia de Seguros da Uber ampliou o papel de Kafka em sua arquitetura orientada a eventos existente usando n reprocessamento de solicitações de bloqueio e Dead Letter Queues para obter tratamento de erros desacoplado e observável sem interromper o tráfego em tempo real . Essa estratégia ajuda o programa de Proteção contra Acidentes de Motorista a funcionar de forma confiável em mais de 200 cidades, deduzindo prêmios por milha por viagem para motoristas inscritos.
Aqui está um exemplo de tratamento de erros do Uber. Níveis de erros de trickle-down de tópicos de repetição até aterrissar na DLQ:
Para mais informações, leia o artigo técnico bem detalhado da Uber: ' Criando reprocessamento confiável e filas de mensagens mortas com Apache Kafka '.
CrowdStrike – Manipulando Erros para Trilhões de Eventos
CrowdStrike é uma empresa de tecnologia de segurança cibernética com sede em Austin, Texas. Ele fornece carga de trabalho na nuvem e segurança de endpoint, inteligência de ameaças e serviços de resposta a ataques cibernéticos .
A infraestrutura da CrowdStrike processa trilhões de eventos diariamente com o Apache Kafka . Abordei casos de uso relacionados para criar consciência situacional e inteligência de ameaças em tempo real em qualquer escala em minha ' Segurança cibernética com a série de blogs Apache Kaka '.
A CrowdStrike define três práticas recomendadas para implementar Dead Letter Queues e tratamento de erros com sucesso:
Armazene a mensagem de erro no sistema correto : Defina a infraestrutura e o código para capturar e recuperar cartas mortas. O CrowdStrike usa um armazenamento de objetos do S3 para seus volumes potencialmente vastos de mensagens de erro. Observe que o armazenamento em camadas para Kafka resolve esse problema imediatamente sem precisar de outra interface de armazenamento (por exemplo, aproveitando o armazenamento infinito na nuvem confluente).
Use a automação : coloque ferramentas para tornar a correção infalível, pois o tratamento de erros pode ser muito propenso a erros quando feito manualmente.
Documente o processo de negócios e envolva as equipes relevantes : Padronize e documente o processo para garantir a facilidade de uso. Nem todos os engenheiros estarão familiarizados com a estratégia da organização para lidar com mensagens mortas.
Em uma plataforma de segurança cibernética como a CrowdStrike, o processamento de dados em escala em tempo real é crucial . Esse requisito também é válido para tratamento de erros. O próximo ataque cibernético pode ser uma mensagem maliciosa que inclui intencionalmente conteúdo inapropriado ou inválido (como um exploit de JavaScript). Portanto, lidar com erros em tempo real por meio de uma Dead Letter Queue é OBRIGATÓRIO.
Banco Santander – Mailbox 2.0 para uma combinação de Retry e DLQ
O Santander Bank teve enormes desafios com o processamento síncrono de dados em seu aplicativo de caixa postal para processar grandes volumes de dados . Eles rearquitetaram sua infraestrutura e construíram uma arquitetura desacoplada e escalável chamada “Santander Mailbox 2.0”.
cargas de trabalho do Santander e movidos para Event Sourcing desenvolvido pelo Apache Kafka :
Um desafio importante na nova arquitetura assíncrona baseada em eventos foi o tratamento de erros. O Santander resolveu os problemas usando o tratamento de erros criado com tópicos de repetição e DLQ Kafka :
Confira os detalhes na palestra do Kafka Summit “ Reliable Event Delivery in Apache Kafka Based on Retry Policy and Dead Letter Topics ” do parceiro de integração do Santander, Consdata.
Tratamento de erros confiável e escalável no Apache Kafka
O tratamento de erros é crucial para construir pipelines e plataformas de streaming de dados confiáveis . Existem diferentes alternativas para resolver este problema. A solução inclui uma implementação personalizada de uma Dead Letter Queue ou o aproveitamento de estruturas em uso, como Kafka Streams, Kafka Connect, a estrutura Spring ou o Parallel Consumer for Kafka.
Os estudos de caso do Uber, CrowdStrike e Santander Bank mostraram que o tratamento de erros nem sempre é fácil de implementar. Ele precisa ser pensado desde o início quando você projeta um novo aplicativo ou arquitetura. O streaming de dados em tempo real com o Apache Kafka é atraente, mas só é bem-sucedido se você puder lidar com comportamentos inesperados . Dead Letter Queues é uma excelente opção para muitos cenários.
Você usa o padrão de design Dead Letter Queue em seus aplicativos Apache Kafka? Quais são os casos de uso e limitações? Como você implementa o tratamento de erros em seus aplicativos Kafka? Quando você prefere uma fila de mensagens e por quê?Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Commentaires