Otimizando Partições do Kafka para Escalabilidade e Taxa de Transferência

O número de partições do Kafka é uma daquelas configurações que parecem simples até você ter que conviver com ela. Poucas partições e os consumidores não conseguem escalar. Muitas e os corretores gastam mais tempo gerenciando metadados, os rebalanceamentos demoram mais e o ruído operacional aumenta.

Não existe um número universal melhor. Um tópico de pagamentos, um tópico de clickstream e um tópico compactado de estado do cliente têm diferentes necessidades de ordenação, tamanhos de mensagem, configurações de retenção e comportamento do consumidor. A pergunta útil não é "Quantas partições são melhores?" É "De quantas partições precisamos para a taxa de transferência, ordenação e crescimento deste tópico sem criar sobrecarga desnecessária no corretor?"

Entendendo as Partições do Kafka

Em sua essência, um tópico Kafka é dividido em uma ou mais partições. Cada partição é um log ordenado somente de acréscimo. As partições são a unidade de paralelismo no Kafka:

Produtores escrevem em partições: Um produtor pode escolher uma partição diretamente, usar uma chave ou deixar o particionador distribuir os registros.
Consumidores leem de partições: Cada consumidor em um grupo de consumidores recebe uma ou mais partições para ler exclusivamente. Isso garante que as mensagens dentro de uma partição sejam processadas em ordem por uma única instância de consumidor dentro desse grupo.
Corretores hospedam partições: Os corretores Kafka armazenam líderes e réplicas. Um tópico com várias partições pode distribuir armazenamento e tráfego entre os corretores.

Características Principais das Partições:

Ordenadas dentro de uma partição: As mensagens dentro de uma única partição são sempre ordenadas. Os consumidores dentro de um grupo mantêm essa ordem.
Não ordenadas entre partições: Não há garantia de ordem das mensagens entre diferentes partições do mesmo tópico.
Paralelismo: Em um grupo de consumidores, o número útil de consumidores ativos para um tópico não pode exceder o número de partições. Consumidores extras ficam ociosos para esse tópico.

Fatores que Influenciam o Número de Partições

Vários fatores críticos devem ser avaliados ao decidir o número de partições para um tópico Kafka:

1. Requisitos de Taxa de Transferência (Produtores e Consumidores)

Taxa de transferência do produtor: Mais partições podem distribuir as gravações entre os corretores, mas apenas se os líderes estiverem balanceados e os produtores distribuírem bem os registros. Um tópico com chave e uma chave quente ainda pode sobrecarregar uma partição.
Taxa de transferência do consumidor: Se um único consumidor pode processar 2.000 mensagens por segundo e o tópico atinge o pico de 20.000 mensagens por segundo, você precisa de partições suficientes para executar consumidores suficientes no grupo. O número exato depende da velocidade medida do consumidor, não de suposições.

2. Metas de Escalabilidade

Crescimento futuro: O Kafka permite aumentar as partições, mas reduzir o número de partições não é uma operação normal no local. Você geralmente cria um novo tópico e migra.
Rebalanceamento: Adicionar partições pode desencadear rebalanceamentos de grupos de consumidores. Com consumidores ocupados, isso pode temporariamente desacelerar ou pausar o processamento.
Comportamento da chave: Aumentar as partições altera o mapeamento chave para partição para muitos produtores que usam o comportamento de particionamento padrão. Isso pode surpreender sistemas que presumiram que uma chave sempre permaneceria na mesma partição ao longo do tempo.

3. Recursos do Corretor

Disco: Mais partições significam mais segmentos de log e mais arquivos para gerenciar, especialmente com replicação.
Rede: A replicação e as buscas do consumidor adicionam tráfego. O problema não é apenas o número de tópicos, mas réplicas, retenção, tamanho da mensagem e fan-out do consumidor.
CPU e memória: Corretores, controladores e clientes pagam alguma sobrecarga para grandes números de partições. As versões modernas do Kafka lidam com clusters grandes melhor do que as mais antigas, mas o número de partições ainda é um trabalho de planejamento de capacidade.

4. Requisitos de Ordenação de Mensagens

Ordenação Baseada em Chave: Se a ordenação for crítica e você usar uma chave de mensagem, os registros com a mesma chave geralmente vão para a mesma partição. Isso fornece ordem por chave, não ordem em todo o tópico. Uma chave quente ainda cai em uma partição e pode gargalar um consumidor.
Sem Ordenação Estrita: Se a ordenação estrita de mensagens não for um requisito, você pode distribuir as mensagens mais livremente entre as partições, priorizando a taxa de transferência e o paralelismo.

5. Escalabilidade do Grupo de Consumidores

Como mencionado, o número de partições determina o número máximo de consumidores que podem ler simultaneamente de um tópico dentro de um grupo de consumidores. Se você precisar escalar seu consumo adicionando mais instâncias de consumidor, deve ter pelo menos tantas partições quanto o número desejado de instâncias de consumidor.

Uma Maneira Prática de Escolher um Número de Partições

Aqui estão estratégias práticas para ajudá-lo a chegar a um número ideal de partições:

1. Comece com uma Linha de Base e Monitore

Uma linha de base útil começa com o paralelismo do consumidor. Se você espera quatro instâncias de consumidor para este tópico, começar com mais de quatro partições dá espaço para rebalancear e crescer.

Exemplo: se você espera executar quatro consumidores, pode começar com oito partições. Isso permite que cada consumidor possua duas partições, e você pode adicionar mais alguns consumidores antes de reparticionar. Este é um ponto de partida, não uma lei.

Monitore continuamente seu cluster Kafka e a lag do consumidor. Se você observar alta lag do consumidor que não pode ser resolvida adicionando mais instâncias de consumidor (porque você atingiu o limite de partições), é um indicador claro de que você precisa aumentar o número de partições.

2. Calcule Com Base na Taxa de Transferência Esperada

Você pode estimar as partições necessárias a partir da taxa de transferência medida:

Fórmula: Número de Partições = (Taxa de Transferência Total Esperada / Taxa de Transferência por Instância de Consumidor) * Buffer
- Taxa de transferência total esperada: Use a taxa de produção de pico, não a média diária.
- Taxa de transferência por instância de consumidor: Meça seu consumidor real com tamanhos de mensagem reais e chamadas downstream.
- Buffer: Adicione margem para picos e crescimento. Evite fingir que o cálculo é exato.

Exemplo:

Taxa de transferência de pico esperada: 50.000 mensagens por segundo
Taxa de transferência de uma única instância de consumidor: 5.000 mensagens por segundo
Buffer: 1,5x
(50.000 / 5.000) * 1,5 = 15

Neste caso, 16 partições é um ponto de partida razoável e arredondado. Se a ordenação, a capacidade do corretor ou a distribuição de chaves pressionarem contra esse número, ajuste-o.

3. Considere as Capacidades e Limites do Corretor

Esteja atento ao número total de partições em todo o cluster. Não há um único número seguro de partições por corretor que se aplique em todos os lugares. Hardware, versão do Kafka, fator de replicação, retenção, tamanho da mensagem, carga do controlador e metas de recuperação de falhas são importantes.

Em vez de tratar "100 partições por corretor" ou "1.000 partições por corretor" como verdade universal, acompanhe as métricas do corretor: latência de solicitação, E/S de disco, saúde do controlador, partições sub-replicadas, pressão no cache de página e duração do rebalanceamento. Use os limites testados da sua plataforma, se sua organização os tiver.

4. Distribuição de Chaves e Partições Quentes

Se você usar chaves de mensagem, analise a distribuição de chaves antes de decidir que "mais partições" corrigirão a taxa de transferência. Algumas chaves dominantes podem criar partições quentes. O corretor que hospeda o líder trabalha mais, e o consumidor atribuído a essa partição fica para trás.

Solução: Se você prevê partições quentes, considere estratégias como:
- Use uma chave menos distorcida quando a ordenação de negócios permitir.
- Use uma chave composta, como customer_id:event_type, se isso preservar a ordenação que você precisa.
- Divida um fluxo de trabalho quente em um tópico separado.
- Fragmentar uma chave quente deliberadamente e, em seguida, lidar com a ordenação em um escopo mais restrito.

Aumentar as partições pode ajudar com a distribuição ampla. Isso não divide uma chave entre os consumidores se todos os registros dessa chave devem permanecer ordenados.

Criando e Alterando Tópicos com Partições

Ao criar um novo tópico, você especifica o número de partições.

Criando um Tópico com um Número Específico de Partições

Usando o script kafka-topics.sh:

kafka-topics.sh --create --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092,kafka-broker-2:9092 \
  --partitions 16 \
  --replication-factor 3

--partitions 16: Define o tópico para ter 16 partições.
--replication-factor 3: Cada partição terá 3 réplicas em diferentes corretores para tolerância a falhas.

Aumentando Partições em um Tópico Existente

Esta é uma operação comum, mas tem implicações. O Kafka permite aumentar o número de partições para um tópico. Diminuir requer uma migração para outro tópico.

Usando o script kafka-topics.sh:

kafka-topics.sh --alter --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092 \
  --partitions 24

--partitions 24: Aumenta as partições para my-high-throughput-topic para 24.

Considerações Importantes ao Alterar Partições:

Rebalanceamento do consumidor: Aumentar as partições pode desencadear rebalanceamentos para grupos de consumidores inscritos. Isso pode pausar ou desacelerar temporariamente o consumo.
Novas Partições: Novas partições são anexadas ao tópico. As mensagens existentes não são reparticionadas.
Mapeamento de chave: Para produtores com chave, adicionar partições pode alterar onde os registros futuros para uma chave são escritos.
Recursos do corretor: Certifique-se de que os corretores tenham capacidade para os líderes e réplicas adicionais.

Se a ordem da chave em todo o histórico for importante, tenha cuidado. Os registros existentes permanecem nas partições antigas, enquanto os novos registros podem ser mapeados de forma diferente após a alteração do número de partições.

Métricas Que Indicam Que o Número de Partições Está Errado

A lag do consumidor é o sinal óbvio, mas não é suficiente por si só. A lag pode vir de bancos de dados downstream lentos, código de consumidor ruim, configurações de busca pequenas, sobrecarga do corretor ou poucas partições.

Procure por esses padrões:

Os consumidores estão saudáveis, mas algumas instâncias estão ociosas porque há menos partições do que consumidores.
Uma partição tem uma lag muito maior do que as outras.
Um corretor carrega muitos líderes de partições quentes.
A latência do produtor aumenta durante o tráfego de pico, embora o cluster tenha corretores sobressalentes.
Os rebalanceamentos demoram o suficiente para afetar os objetivos de nível de serviço.

Para grupos de consumidores:

kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --group my-consumer-group

Para o layout do tópico:

kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --topic my-high-throughput-topic

Se apenas uma partição estiver atrasada, adicionar consumidores não ajudará, a menos que o trabalho possa ser distribuído em mais partições.

Melhores Práticas e Armadilhas

Faça:

Comece com necessidades medidas: Use o número esperado de consumidores, testes de taxa de transferência e capacidade do corretor.
Alinhe com o paralelismo do consumidor: Certifique-se de ter partições suficientes para escalar suas instâncias de consumidor de forma eficaz.
Deixe espaço para crescimento: Adicionar partições depois é possível, mas não isento de consequências.
Entenda a distribuição de chaves: Se usar chaves, analise sua distribuição para evitar partições quentes.
Aproveite as ferramentas de monitoramento do Kafka: Use ferramentas para rastrear métricas de tópico/partição, lag do consumidor e carga do corretor.

Não Faça:

Excesso de partições: Muitas partições aumentam a sobrecarga, podem desacelerar os rebalanceamentos e podem tornar a recuperação de falhas mais ruidosa.
Poucas partições: Limita a escalabilidade e a taxa de transferência, levando à lag do consumidor.
Siga cegamente números arbitrários: Use regras práticas apenas como pontos de partida.
Esqueça a capacidade do corretor: Certifique-se de que seus corretores possam lidar com o número total de partições em todos os tópicos.
Espere ordenação perfeita entre partições: Lembre-se de que a ordenação é garantida apenas dentro de uma partição.

Um Processo de Decisão Razoável

Para um novo tópico, eu geralmente trabalho nesta ordem:

Defina o requisito de ordenação. Por cliente? Por conta? Sem ordem estrita?
Meça ou estime a taxa de transferência de pico do produtor e o tamanho da mensagem.
Faça benchmark de uma instância de consumidor com dependências downstream realistas.
Escolha as partições com base no paralelismo de consumidor necessário mais margem de crescimento.
Verifique o impacto total no cluster após a inclusão do fator de replicação.
Monitore a lag por partição e a carga do corretor após o lançamento.

O número de partições não é um concurso de beleza. Um tópico chato com oito partições bem utilizadas é melhor do que um tópico com 96 partições principalmente ociosas que desacelera cada rebalanceamento. Escolha o menor número que lhe dá o paralelismo e o espaço de crescimento que você realmente precisa.