Pontos Principais
- O design do Kafka com baixa exigência de recursos e escalonamento horizontal amigável possibilitam o uso de hardware de baixo custo e ainda executar com muito sucesso.
- Fornece ao ZooKeeper uma forte largura de banda de rede usando os melhores discos, armazenando logs separadamente, isolando o processo do ZooKeeper, e desabilitando swaps para reduzir a latência.
- Aumente o fator de replicação padrão do Kafka de dois para três, o que é apropriado na maioria dos ambientes de produção.
- Mais partições significam uma maior paralelização e taxa de transferência, mas as partições também significam mais latência na replicação, rebalanceamentos e arquivos de servidor abertos.
- Monitore as métricas do sistema, como o throughput de rede, manipuladores de arquivos abertos, memória, carga, uso de disco, e estatísticas da JVM como pausas do GC e uso do heap.
Apache Kafka certamente faz jus ao seu romancista quando se trata de 1) emoção inspirada em recém-chegados, 2) profundezas desafiadoras e 3) recompensas ricas que possam resultar por conta de um entendimento mais completo. Mas, afastando-se rapidamente da Literatura Comparativa básica, certamente, seguir as mais recentes boas práticas do Kafka pode tornar o gerenciamento desta poderosa plataforma de streaming de dados muito mais fácil - e consideravelmente mais eficaz.
Aqui estão dez dicas específicas para ajudar a manter a implantação do Kafka otimizada e mais facilmente gerenciada:
- Defina os parâmetros de configuração de log para manter os logs gerenciáveis;
- Conheça os requisitos de hardware (baixos) do Kafka;
- Aproveite o Apache ZooKeeper ao máximo;
- Configure a replicação e redundância do modo certo;
- Tome cuidado com as configurações de tópicos;
- Use o processamento paralelo;
- Configurar e isolar o Kafka com segurança em mente;
- Evite interrupções aumentando o Ulimit;
- Manter uma baixa latência de rede;
- Utilize monitoramento e alertas eficazes.
Vamos analisar cada uma dessas melhores práticas em detalhe.
Defina os parâmetros de configuração de log para manter os logs gerenciáveis
O Kafka oferece aos usuários muitas opções para configuração de log e, embora as configurações padrão sejam razoáveis, personalizar o comportamento do log para atender seus requisitos específicos garantirá que os logs não se transformem em um desafio de gerenciamento a longo prazo. Isso inclui configurar a política de retenção de log, limpezas, compactação e atividades de compressão.
O comportamento do log pode ser controlado usando os parâmetros log.segment.bytes, log.segment.ms e log.cleanup.policy
(ou o equivalente no nível de tópico). Se, no seu caso de uso, você não precisar de logs passados, você pode fazer com que o Kafka exclua arquivos de log de um determinado tamanho ou após um período de tempo definido definindo cleanup.policy
como "delete". É possível também definir o cleanup.policy como "compact" para manter os logs quando necessário. É importante entender que a limpeza do log consome recursos de CPU e RAM; ao usar o Kafka como um commit log para qualquer período de tempo, certifique-se de balancear a frequência das compactações para manter o desempenho.
A compactação é um processo pelo qual o Kafka garante a retenção de pelo menos o último valor conhecido para cada chave de mensagem (dentro do log de dados para uma única partição de tópico). A compactação funciona em cada chave em um tópico para manter seu último valor, limpando todas as outras duplicadas. No caso de exclusões, a chave é deixada com o valor 'null' (que é chamado 'lápide', pois denota, pictoricamente, uma exclusão).
Imagem 1 - O processo de compactação do commit log do Kafka (source)
Documentação do commit log do Kafka:
Conheça os requisitos de hardware (baixos) do Kafka
Embora muitas equipes não familiarizadas com o Kafka superestimar as necessidades de hardware, a solução tem, na verdade, baixa carga adicional e escalonamento horizontal amigável. Isso possibilita o uso de hardware de baixo custo e ainda executar o Kafka com bastante sucesso:
CPU: A menos que o SSL e a compactação de log sejam necessários, uma CPU potente não é necessária para o Kafka. Além disso, quanto mais núcleos forem usados, melhor será a paralelização. Na maioria dos cenários, nos quais a compressão não é um fator, o codec LZ4 deveria ser usado para fornecer o melhor desempenho.
RAM: Na maioria dos casos, o Kafka pode executar otimamente com 6 GB de RAM para o espaço do heap. Para cargas de produção especialmente pesadas, use máquinas com 32 GB ou mais. RAM adicional será usado para reforçar o cache de páginas do sistema operacional e melhorar o throughput do cliente. Embora o Kafka possa executar com menos RAM, sua capacidade de lidar com a carga é dificultada quando há menos memória disponível.
Disco: O Kafka prospera ao usar várias unidades em uma configuração RAID. Os SSDs não oferecem muita vantagem devido ao paradigma de E/S de disco sequencial de Kafka, e o NAS não deve ser usado.
Rede e sistema de arquivos: O XFS é recomendado, assim como manter o cluster em um único data center, se as circunstâncias permitirem. Além disso, forneça o máximo de largura de banda possível.
O site do Apache Kafka também contém uma seção dedicada à configuração de hardware e sistema operacional com recomendações valiosas.
Outros links úteis acerca de testes de carga/desempenho do Kafka:
Benchmarking Apache Kafka: 2 milhões de gravações por segundo (em três máquinas baratas)
Testes de carga do Apache Kafka na AWS
Aproveite o Apache ZooKeeper ao máximo
Um cluster do Apache ZooKeeper em execução é uma dependência chave para executar o Kafka. Porém, há algumas práticas importantes a serem consideradas ao usar Zookeeper junto com Kafka.
O número de nós do ZooKeeper deve ser no máximo cinco. Um nó é adequado para um ambiente de desenvolvimento, e três nós são suficientes para a maioria dos clusters de produção do Kafka. Embora uma grande implantação do Kafka possa precisar cinco nós do ZooKeeper para reduzir a latência, a carga colocada nos nós deve ser levada em consideração. Com sete ou mais nós sincronizados e tratando requisições, a carga se torna imensa e o desempenho pode sofrer um impacto notável. Observe também que as versões recentes do Kafka colocam uma carga muito menor no Zookeeper do que as versões anteriores, as quais usavam o Zookeeper para armazenar os offsets dos consumidores.
Finalmente, como acontece com os requisitos de hardware do Kafka, forneça ao ZooKeeper a maior largura de banda de rede possível. Usando os melhores discos, armazenando logs separadamente, isolando o processo do ZooKeeper, e desabilitar swaps também reduzirá a latência.
A tabela abaixo destaca algumas das operações de terminal dependentes do Zookeeper em diferentes versões do Kafka. A versão anterior, 0.8.0, não tinha muitas funcionalidades A partir da versão 0.10.0.0 em diante, podemos ver algumas das principais funcionalidades removidas do Zookeeper - resultando em menor utilização do Zookeeper.
O gerenciamento adequado significa tudo para a resiliência da implantação do Kafka. Uma prática importante é aumentar o fator de replicação padrão do Kafka de dois para três, o que é apropriado para a maioria dos ambientes de produção. Isso garante que a perda de um broker não seja motivo de preocupação, e até mesmo a perda improvável de dois não interrompe a disponibilidade. Outra consideração são as zonas e regiões de disponibilidade do data center; se estiver usando o AWS, por exemplo, os servidores Kafka devem estar na mesma região, mas usar múltiplas zonas de disponibilidade para obter redundância e resiliência.
Configurando a replicação e redundância da maneira certa
O parâmetro de configuração do Kafka a ser considerado para implantação em rack é:
broker.rack=rack-id
Conforme a documentação do Apache Kafka:
Quando um tópico é criado, modificado ou as réplicas são redistribuídas, a restrição de rack será respeitada, garantindo que as réplicas abranjam quantos racks puderem (uma partição irá abranger min(#racks, fator de replicação) racks diferentes).
Um exemplo:
Vamos considerar nove brokers de Kafka (B1-B9) espalhados sobre três racks.
Imagem 2 - Cluster Kafka com ciência de rack
Aqui, um único tópico com três partições (P1, P2, P3) e um fator de replicação de três (R1, R2, R3) terá uma partição atribuída a um nó em cada rack. Esse cenário fornece alta disponibilidade com duas réplicas para cada partição, mesmo que um rack completo falhe (conforme mostrado no diagrama).
Tome cuidado com as configurações de tópicos
As configurações de tópicos têm um forte impacto no desempenho de clusters Kafka. Como alterações em configurações como fator de replicação ou contagem de partições podem ser desafiadoras, você vai querer definir essas configurações do modo certo na primeira vez, e depois simplesmente criar um novo tópico se alterações forem necessárias (sempre certifique-se de testar novos tópicos em um ambiente de homologação).
Use um fator de replicação de três e seja cuidadoso com o tratamento de mensagens grandes. Se possível, divida mensagens grandes em partes ordenadas ou simplesmente use ponteiros para os dados (como links para S3). Se esses métodos não forem possíveis, ative a compressão no lado do produtor. O tamanho do segmento de log padrão é de 1 GB e, se as as mensagens forem maiores, de uma boa olhada no caso de uso. O número de partições também é uma configuração criticamente importante, discutido em detalhes na próxima seção.
As configurações de tópico possuem uma propriedade padrão do servidor. Eles podem ser sobrescritos no momento da criação do tópico ou posteriormente de modo a ter uma configuração específica de tópico.
Uma das configurações mais importantes, conforme discutido acima, é o fator de replicação. O exemplo a seguir demonstra a criação de tópicos via terminal com três partições e um fator de replicação de três junto com outras configurações de "nível de tópico":
bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper:2181 --create --topic my-topic --partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1
Para obter uma lista completa de configurações de nível de tópico, veja aquí.
Use processamento paralelo
O Kafka é projetado para processamento paralelo e, por conta disso, uma utilização completa requer um ato de balanceamento. O número de partições é uma configuração no nível de tópico e, quanto mais partições, maior paralelização e throughput. No entanto, as partições também significam mais latência de replicação, rebalanceamentos e arquivos de servidor abertos.
Encontrar as configurações ideais de partição é tão simples quanto calcular o throughput desejável para o seu hardware e, em seguida, fazer as contas para encontrar o número de partições necessárias. Para uma estimativa conservadora, uma partição em um único tópico pode fornecer 10 MB/s e, extrapolando a partir disso, é possível chegar ao throughput total necessário. Um método alternativo para testar diretamente, é usar uma partição por broker por tópico e, em seguida, verificar os resultados e duplicar as partições se mais throughput for necessário.
No geral, uma regra útil é manter o total de partições por tópico abaixo de 10 e manter o total de partições para o cluster abaixo de 10.000. Se você não o fizer, seu monitoramento deve ser altamente capaz e pronto para enfrentar rebalanceamentos e interrupções muito desafiadores!
O número de partições é definido durante a criação de um tópico do Kafka, conforme demonstrado abaixo:
bin/kafka-topics.sh --zookeeper ip_addr_of_zookeeper:2181 --create --topic my-topic --partitions 3 --replication-factor 3 --config max.message.bytes=64000 --config flush.messages=1
O número de partições pode ser aumentada após a criação. Mas isso pode impactar os consumidores, por isso é recomendável realizar essa operação após mapear todas as consequências.
bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic topic_name --partitions new_number_of_partitions
Configurar e isolar o Kafka com segurança em mente
As duas principais preocupações em segurança na implantação do Kafka são: 1) a configuração interna do Kafka e 2) a infraestrutura em que o Kafka é executado.
Uma série de recursos de segurança valiosos foram incluídos na versão .9 do Kafka, como o suporte de autenticação Kafka/client e Kafka/ZooKeeper, bem como o suporte a TLS para proteger sistemas com clientes de Internet públicos. Enquanto o TLS representa um custo para o throughput e o desempenho, o mesmo isola e protege de maneira eficaz o tráfego para os brokers Kafka.
O isolamento do Kafka e do ZooKeeper é vital para a segurança. Além de casos raros, o ZooKeeper nunca deve se conectar à Internet pública e deve se comunicar apenas com o Kafka (ou outras soluções para as quais ele é usado). Firewalls e grupos de segurança devem isolar o Kafka e o ZooKeeper, com brokers residindo em uma única rede privada que rejeita conexões externas. Um middleware ou uma camada de balanceamento de carga devem isolar o Kafka de clientes da Internet pública.
Opções de segurança e protocolos com Kafka:
- SSL / SASL: Autenticação de clientes para brokers, entre brokers, brokers para ferramentas.
- SSL: Criptografia de dados clientes para brokers, entre brokers, brokers para ferramentas.
- Tipos de SASL: SASL/GSSAPI (Kerberos), SASL/ LAIN, SASL/SCRAM-SHA-512/ SCRAM-SHA-256, SASL_AUTHBEARER
- Segurança do Zookeeper: Autenticação para clientes (Brokers, ferramentas, produtores, consumidores), Autorização com ACL.
* Clientes do broker do Kafka: produtores, consumidores, outras ferramentas.
* Clientes zookeeper: brokers do Kafka, produtores, consumidores, outras ferramentas.
* Autorização é plugável.
Um exemplo de configuração de segurança com SASL_SSL:
#Broker configuration
listeners=SSL://host.name:port,SASL_SSL://host.name:port
advertised.listeners=SSL://host.name:port,SASL_SSL://host.name:port
security.protocol=SASL_SSL
security.inter.broker.protocol=SSL
listener.security.protocol.map=INTERBROKER\:SSL,PUBLIC_CLIENT\:
SASL_PLAINTEXT,PRIVATE_CLIENT\:SASL_PLAINTEXT
ssl.keystore.location=/var/private/ssl/server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=/var/private/ssl/server.truststore.jks
ssl.truststore.password=test1234
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN
#Client Configuration (jaas file)
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule
required \
username="[USER NAME]" \
password="[USER PASSWORD]";
Evite interrupções aumentando o Ulimit
É um cenário que ocorre frequentemente: os brokers caem aparentemente por causa de muita carga, mas na verdade é um erro benigno (embora ainda estressante) de "muitos arquivos abertos". Ao editar /etc/sysctl.conf e definir o Ulimit para permitir 128.000 ou mais arquivos abertos, você pode evitar que esse erro aconteça.
Um exemplo para aumentar o ulimit no CentOS:
- Criar um novo arquivo
/etc/security/limits.d/nofile.conf
- Adicionar:
* soft nofile 128000
* hard nofile 128000
- Reiniciar o sistema ou faça login novamente.
- Confirme executando o comando abaixo:
ulimit -a
* Note que existem vários métodos para aumentar o ulimit. Você pode seguir qualquer método adequado para sua distribuição Linux.
Manter a latência de rede baixa
Ao buscar baixa latência na implantação do Kafka, certifique-se de que os brokers estejam geograficamente localizados em regiões próximas aos clientes e considere o desempenho da rede ao selecionar os tipos de instância oferecidos pelos provedores de nuvem. Se a largura de banda está atrasando, um servidor maior e mais poderoso pode ser um investimento que vale a pena.
Utilize monitoramento e alertas eficazes
Seguir as práticas acima ao criar seu cluster Kafka pode poupá-lo de inúmeros problemas no futuro, mas você ainda vai querer estar atento para reconhecer e mapear adequadamente qualquer empecilho antes que eles se tornem problemas.
Monitorar métricas do sistema - como throughput de rede, manipuladores de arquivos abertos, memória, carga, uso de disco e outros fatores - é essencial, assim como observar estatísticas da JVM, incluindo pausas de GC e uso de heap. Painéis e ferramentas de histórico capazes de acelerar os processos de depuração podem fornecer muito valor. Ao mesmo tempo, sistemas de alertas como Nagios ou PagerDuty devem ser configurados para fornecer avisos quando surgirem sintomas como picos de latência ou pouco espaço em disco, de modo que problemas menores possam ser resolvidos antes que eles se tornem uma bola de neve.
A seguir alguns exemplos de gráficos de monitoramento Kafka via o Instaclustr:
Sobre o Autor
Ben Bromhead é Diretor de Tecnologia no Instaclustr, que fornece uma plataforma de serviços gerenciados de tecnologias de código aberto, como o Apache Cassandra, o Apache Kafka, o Apache Spark e o Elasticsearch.