Reduza suas conexões Kafka em 10x

Ouça este artigo

Neste artigo você aprende a usar um sidecar por pod para cortar drasticamente as conexões com Kafka. Entenda por que cada processo abre conexões, por que soluções como aumentar brokers ou proxies simples não resolvem e como um produtor central por pod preserva ordering, melhora batching e reduz a carga no broker. Veja como integrar o sidecar via gRPC com mudanças mínimas no código, monitorar com métricas e fazer um rollout seguro com fallback para evitar perda de dados. Ao final há passos práticos para estabilizar seu cluster e reduzir o estresse dos brokers.

• Conte conexões, não só throughput

• Use um sidecar por pod para reduzir muito as conexões

• Preserva ordenação por partição ao centralizar envios

• Mudança leve de operar com rollback local seguro

• Meça tentativas, confirmações e latência e defina metas

Reduzindo conexões Kafka em 10x com um padrão sidecar

Aqui está um passo a passo prático sobre como cortamos as conexões do Kafka em cerca de 10x numa grande instalação: o que não funcionou, a solução que usamos, por que ajudou e como adaptar isso ao seu ambiente.

O que não funcionou (e por quê)

Você provavelmente já tentou atalhos rápidos. Testamos estes e falharam:

• Adicionar mais brokers
  Cada produtor mantém conexões persistentes com os brokers líderes das partições. Espalhar partições por mais brokers aumenta o número de conexões por produtor.

• Aumentar RAM/CPU nas VMs
  Kafka depende do cache do SO e da JVM; aumentar recursos sem abordar o multiplicador de conexões não resolve o problema central.

• Colocar um proxy genérico
  Protocolos como o Kafka mantêm sessões longas. Pooling simples quebra performance e ordem.

• Tunar o cliente
  Ajustes (linger, timeouts, buffers) ajudam pouco. Não impedem múltiplos processos por pod de abrirem conexões separadas.

A solução: um sidecar produtor por pod

Execute um pequeno serviço local no mesmo pod que mantém um único produtor Kafka por pod. Os processos do app conversam com o sidecar via gRPC para enviar eventos.

Como funciona:

• O app chama RPC Emit(topic, key, headers, bytes).

• O sidecar envia ao broker e responde com um ack.

• Se o sidecar cair, o app pode usar fallback para emitir direto ao Kafka (opcional).

Interface mínima (pseudocódigo):

• Emit(topic, key?, headers, eventbytes) → { success: bool, errorcode, retryafterms }

• DeliveryStream → stream bidirecional de relatórios contínuos de sucesso/erro

Por que ajudou

O sidecar resolve o ponto crítico: multiplicação de conexões.

• Menos conexões
  Muitos processos por pod se consolidam em uma conexão por broker por pod, cortando conexões dramaticamente.

• Preserva ordenação
  Escritas para uma partição saem pelo mesmo produtor do pod, mantendo a ordem por partição.

• Escala horizontal limpa
  Escalando pods, você escala sidecars; não volta o fan‑out por processo.

• Fallback seguro
  Se um sidecar falhar, o problema se limita ao pod afetado.

• Leve e com pouco retrabalho
  O sidecar consome pouco CPU/RAM para workloads de produtor e normalmente exige só mudança de configuração.

Resultados observados

Após migrar os maiores serviços:

• Conexões pico: caíram cerca de 10x.

• Uso de heap dos brokers: caiu ~70 pontos percentuais no pico.

• Picos de CPU / GC: desapareceram, reduzindo timeouts.

Notas de implementação para adaptar ao seu stack

Passos práticos:

• Preparação

• Meça linha de base: conexões por broker, uso de heap, latência tail, taxa de sucesso de emissão.

• Identifique pods com muitos processos que abrem conexões.

• Client toggle

• Adicione no wrapper Kafka um modo sidecar que usa gRPC local quando habilitado.

• Backpressure e retries

• Sidecar deve ter fila por partição e regras claras de retry.

• Defina limites de fila e políticas de rejeição.

• Métricas e SLOs

• Registre: contagem de requests, profundidade da fila, latências (p50/p95/p99), taxas de erro.

• Defina SLOs e alerte se muitos pods caírem para fallback.

• Compressão e batch

• Consolidar produtores aumenta o tamanho médio do batch, melhora compressão e reduz banda.

• Rollout

• Comece com pods que mais conectam.

• Faça deploy por pod com feature flag. Monitore conexões, GC e taxa de sucesso.

• Fallback seguro

• Permita emissão direta caso o sidecar falhe para evitar perda de dados enquanto corrige o problema.

O que construímos (e mantivemos)

• gRPC sidecar com endpoints: Emit (unário) e DeliveryStream (stream de relatórios).

• Métrica de qualidade de emissão: contagem de tentativa vs ack por app/tópico.

• Relatórios de entrega: sidecar mantém ring buffer e envia relatórios contínuos; o worker consome e executa callbacks locais.

• Modo de cliente toggle: mudança por configuração, sem reescrever o app.

Operações e observabilidade

• Conte conexões, não só throughput: múltiplos processos multiplicam conexões; impacto direto na heap dos brokers.

• Métricas essenciais: attempt-to-ack success rate por app/tópico, latência end‑to‑end, queue depth no sidecar, taxa de fallback.

• Alertas: muitos pods em fallback simultâneo; queda na taxa de sucesso de emissão.

Antes e depois: topologia de conexão

• Antes: cada processo abre conexões para cada broker.
  Ex.: 1000 pods × 10 processos × 10 brokers = 100.000 conexões.

• Depois: cada pod tem 1 produtor.
  Ex.: 1000 pods × 1 produtor × 10 brokers = 10.000 conexões.

O que medir durante o rollout (prioridade)

• Conexões por broker (count)

• Uso de heap JVM dos brokers

• Latência p99 de emissão

• Taxa de sucesso de entrega (attempt vs ack)

• Profundidade das filas do sidecar

• Taxa de fallback por pod

Dicas práticas

• Comece pequeno: migre os piores ofensores primeiro.

• Mantenha o blast radius pequeno: sidecar por pod é simples para debugar.

• Métricas antes e depois: compare linhas de base.

• Prefira operacionalidade: soluções simples e fáceis de operar vencem truques complexos.

• Documente SLOs e procedimentos de rollback.

Emission delivery reports — como integrar callbacks

• O sidecar expõe um stream gRPC de delivery reports.

• O worker abre uma thread que consome o stream.

• O worker mapeia relatórios para callbacks na linguagem do app.

Takeaways

• Conte conexões, não só throughput.

• Um sidecar por pod corta conexões em ordem de magnitude quando há muitos processos.

• Métricas e rollout gradual são essenciais.

• Mantenha o design simples e previsível — boring wins.

Recursos educacionais e artigos relacionados

• Leia sobre o talk do Robinhood sobre proxy/sidecar para consumidores — foi grande inspiração.

• Para referência técnica complementar, veja: https://zapier.com/blog/reducing-kafka-connections-sidecar.

• Veja artigos do time de engenharia sobre KEDA, Thanos, Prometheus e gestão de segredos.

Como o Zapier pode ajudar sua produtividade

• Use Zapier para automatizar tarefas repetitivas entre apps.

• Zapier conecta 8.000 apps sem código e pode notificar times quando métricas passarem de um limiar.

• Para estudos de caso e leituras práticas sobre arquitetura e otimização, confira também https://zapier.com/blog/reducing-kafka-connections-sidecar.

Quem escreveu / créditos

Projeto liderado por engenheiros de site reliability. Créditos: Mahsa Khoshab, Sugat Mahanti, Sarah Story. Inspiração: Robinhood. Texto adaptado para aplicar no seu ambiente.

Conclusão

Usar um sidecar por pod transforma um caos de conexões em uma arquitetura limpa: centraliza o envio, reduz conexões (~10x), preserva ordenação por partição, melhora batching e diminui pressão sobre os brokers. A mudança é simples de operar, permite rollout por pod, monitora métricas essenciais (conexões, heap, latências, fallback) e oferece fallback seguro para evitar perda de dados. Comece pelos maiores ofensores, meça antes/depois e mantenha o blast radius pequeno — boring wins.

Para mais guias práticos, veja também https://zapier.com/blog/reducing-kafka-connections-sidecar e outros artigos em https://bloxnoticias.com.br.

Perguntas Frequentes

• O que causa a explosão de conexões Kafka?
  A cada broker que tem uma partição, o cliente abre uma conexão TCP. Muitos processos por pod multiplicam essas conexões.

• Por que multiprocessing piora o problema?
  Bibliotecas Kafka não são fork-safe: cada subprocesso cria seu próprio produtor e conexões.

• Por que adicionar mais brokers não resolve?
  Mais brokers espalham partições e aumentam o conjunto de brokers que cada produtor precisa contatar.

• Por que aumentar RAM nos brokers não é solução?
  Aumentar heap traz tradeoffs de GC e não resolve o consumo extra de metadados por muitas conexões.

• Por que um proxy simples não funciona como PgBouncer?
  Kafka mantém estado por sessão e espera conexões longas; proxies simples não preservam essas garantias.

• O que é o sidecar producer por pod?
  É um processo gRPC local que executa um único produtor Kafka por pod; apps enviam eventos ao sidecar.

• Como o sidecar reduz conexões em ~10x?
  Consolida muitos produtores por pod em um único produtor, reduzindo o fan‑out de conexões.

• A ordenação por partição é mantida?
  Sim — eventos do mesmo pod para uma partição passam pelo mesmo produtor.

• E se o sidecar ficar indisponível?
  Há fallback: o cliente pode emitir direto ao Kafka, limitando o impacto ao pod afetado.

• Quais métricas devo monitorar?
  Contagem de requisições, profundidade de filas, tamanho de batch, latência (p50/p95/p99/p99.9), taxa de erros, conexões por broker e GC dos brokers.

• Como funcionam os delivery reports com sidecar?
  Sidecar expõe um stream gRPC; o app consome esse stream para executar callbacks locais.

• Como é a interface mínima do sidecar?
  Uma RPC Emit(ProduceRequest) que envia topic, key, headers e bytes do evento e retorna ack com sucesso/erro e retryafterms.

• Quais resultados operacionais foram observados?
  Redução de conexões de producers ~10x em pico; uso de heap dos brokers caiu ~70pp; picos de CPU/GC desapareceram.