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 com alta capacidade de processamento e tolerância a falhas, mas pode falhar por uma variedade de razões, incluindo falhas de infraestrutura, configurações incorretas 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 do disco rígido, exaustão de memória ou problemas de rede do broker.
Problemas do ZooKeeper
O Kafka depende do Apache ZooKeeper para gerenciar metadados do cluster e eleição de líder. Falhas do ZooKeeper (devidas 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 mais recente do Apache Kafka.
Configuração incorreta 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 “brain split”.
Configuração Incorreta
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
A corrupção de logs 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) não forem reconhecidos e tratados, 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. O Kafka não possui ferramentas integradas para backup de tópicos, mas podemos alcançar isso usando alguns métodos.
Como Fazer Backup de Tópicos e Configurações do Kafka
Existem várias maneiras que podemos seguir para fazer backup de tópicos e configurações.
Consumidores do Kafka
Podemos usar consumidores Kafka para ler mensagens do tópico e armazená-las em armazenamento externo como HDFS, S3 ou armazenamento local. Usando ferramentas de consumidor Kafka confiáveis 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. Este procedimento é simples e personalizável, mas requer armazenamento grande para tópicos de alto rendimento e pode perder metadados como carimbos de data/hora ou cabeçalhos.
Kafka Connect
Ao transmitir mensagens de tópicos para Armazenamento de Objetos usando ferramentas como Kafka Connect. Podemos configurar o Kafka Connect com um conector de sink (por exemplo, Conector de Sink do S3, Conector de Sink do JDBC, etc.), configurar o conector para ler de 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
A funcionalidade 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 Kafka e republica essas mensagens para outro cluster Kafka, que pode servir como um backup usando um produtor Kafka incorporado. Precisamos garantir que o cluster de backup esteja em uma região física ou em nuvem separada para redundância. Pode alcançar replicação contínua e suportar backups incrementais, mas tem uma sobrecarga operacional maior para manter o cluster de backup.
Cópias ao Nível do Sistema de Arquivos
Cópias de segurança a nível de sistema de ficheiros, como a cópia direta dos diretórios de log do Kafka diretamente dos brokers do Kafka, podem ser realizadas ao identificar o diretório de log do Kafka (log.dirs em server.properties). Este método permite a preservação dos offsets e dos dados das partições. No entanto, requer processos meticulosos de restauração para garantir consistência e evitar potenciais problemas.
Configurações e Metadados do Kafka
No que diz respeito à configuração do Kafka, podemos especificar metadados sobre tópicos, controlo de acesso (ACL), ficheiro 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, guarde a saída num ficheiro para referência. É necessário garantir que todas as definições personalizadas (por exemplo, log.retention.ms, num.partitions) sejam documentadas. Utilizando o script integrado kafka-acls.sh, todas as propriedades acl podem ser consolidadas num ficheiro plano.
Resumo
As práticas discutidas acima são principalmente adequadas para clusters implementados localmente e limitados a um número de nós de um dígito configurados no cluster. No entanto, os fornecedores de serviços geridos lidam com as melhores práticas operacionais para executar a plataforma, portanto, não precisamos de nos preocupar em detetar e corrigir problemas.
Ao ler este artigo, espero que ganhe perceções práticas e estratégias comprovadas para lidar com falhas no Apache Kafka em implementações locais.
Source:
https://dzone.com/articles/avoid-kafka-outages-with-topic-and-configuration-backups