Uma interrupção no Apache Kafka ocorre quando um cluster Kafka ou alguns de seus componentes falham, resultando em interrupção ou degradação do serviço. O Kafka é projetado para lidar com streaming de dados e mensagens de alto desempenho e tolerância a falhas, mas pode falhar por uma variedade de razões, incluindo falhas de infraestrutura, erros de configuração e problemas operacionais.
Por que ocorre a interrupção do Kafka
Falha do Broker
Carga excessiva de dados ou hardware superdimensionado faz com que um broker se torne não responsivo, falha de hardware devido a falha no disco rígido, exaustão de memória ou problemas de rede do broker.
Problemas no ZooKeeper
O Kafka depende do Apache ZooKeeper para gerenciar metadados do cluster e eleição de líderes. Falhas no ZooKeeper (devido a partições de rede, configuração incorreta ou exaustão de recursos) podem interromper as operações do Kafka. Os problemas do ZooKeeper podem ser omitidos se o cluster tiver sido configurado no modo KRaft com a versão 3.5 ou posterior do Apache Kafka.
Erro de configuração de tópico
Fatores de replicação insuficientes ou configuração inadequada de partições podem causar perda de dados ou interrupções de serviço quando um broker falha.
Partições de rede
Falhas de comunicação entre brokers, clientes ou ZooKeeper podem reduzir a disponibilidade ou causar cenários de “split-brain”.
Erro de configuração
Configurações de cluster mal configuradas (políticas de retenção, alocação de réplicas, etc.) podem levar a comportamentos inesperados e falhas.
Sobrecarga
Um aumento repentino no tráfego de produtores ou consumidores pode sobrecarregar um cluster.
Corrupção de Dados
Corrupção de log do Kafka (devido a problemas de disco ou desligamento abrupto) pode causar problemas de inicialização ou recuperação de dados.
Monitoramento e Alerta Inadequados
Se sinais de alerta precoce (como picos no uso de disco ou latência longa) passarem despercebidos e não forem resolvidos, problemas menores podem levar a falhas completas.
Backups de tópicos e configurações do Apache Kafka são importantes para recuperação de desastres, pois nos permitem restaurar nossos dados e configurações em caso de falha de hardware, problemas de software ou erro humano. Kafka não possui ferramentas integradas para backup de tópicos, mas podemos conseguir isso usando alguns métodos.
Como Fazer Backup de Tópicos e Configurações do Kafka
Há várias maneiras de fazer backup de tópicos e configurações.
Consumidores do Kafka
Podemos usar os consumidores do Kafka para ler mensagens do tópico e armazená-las em um armazenamento externo como HDFS, S3 ou armazenamento local. Usando ferramentas confiáveis de consumidor do Kafka como o kafka-console-consumer.sh integrado ou scripts de consumidor personalizados, todas as mensagens do tópico podem ser consumidas a partir do offset mais antigo. Esse procedimento é simples e personalizável, mas requer um grande armazenamento para tópicos de alto rendimento e pode perder metadados como timestamps ou cabeçalhos.
O Kafka Connect
Ao transmitir mensagens de tópicos para Armazenamento de Objetos usando ferramentas como o Kafka Connect. Podemos configurar o Kafka Connect com um conector de destino (por exemplo, Conector de Destino S3, Conector de Destino JDBC, etc.), configurar o conector para ler tópicos específicos e escrever no destino de backup. Claro, precisamos ter uma configuração adicional para o Kafka Connect.
Replicação de Cluster
O recurso de espelhamento do Kafka nos permite gerenciar réplicas de um cluster Kafka existente. Ele consome mensagens de um cluster de origem usando um consumidor do Kafka e republica essas mensagens para outro cluster Kafka, que pode servir como um backup usando um produtor do Kafka incorporado. Precisamos garantir que o cluster de backup esteja em uma região física ou de nuvem separada para redundância. Pode alcançar uma replicação perfeita e suportar backups incrementais, mas tem uma sobrecarga operacional maior para manter o cluster de backup.
Cópias em Nível de Sistema de Arquivos
Backups em nível de sistema de arquivos, como copiar diretórios de log do Kafka diretamente dos brokers do Kafka, podem ser realizados identificando o diretório de log do Kafka (log.dirs em server.properties). Este método permite a preservação de offsets e dados de partição. No entanto, requer processos de restauração meticulosos para garantir consistência e evitar possíveis problemas.
Configurações e Metadados do Kafka
Em termos de configuração do Kafka, podemos especificar metadados sobre tópicos, controle de acesso (ACL), arquivo server.properties de todos os brokers e o diretório de dados do ZooKeeper (conforme definido pelo parâmetro dataDir na configuração do ZooKeeper). Posteriormente, salve a saída em um arquivo para referência. Precisamos garantir que todas as configurações personalizadas (por exemplo, log.retention.ms, num.partitions) sejam documentadas. Usando o script embutido kafka-acls.sh, todas as propriedades de acl podem ser consolidadas em um arquivo plano.
Resumo
As práticas discutidas acima são principalmente adequadas para clusters implantados no local e limitados a um número de nós de dígito único configurados no cluster. No entanto, os provedores de serviços gerenciados lidam com as melhores práticas operacionais para executar a plataforma, então não precisamos nos preocupar em detectar e corrigir problemas.
Ao ler este artigo, espero que você obtenha insights práticos e estratégias comprovadas para lidar com interrupções do Apache Kafka em implantações no local.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups