{"id":3725,"date":"2025-11-01T00:07:10","date_gmt":"2025-11-01T00:07:10","guid":{"rendered":"https:\/\/bloxnoticias.com.br\/reduza-suas-conexoes-kafka-em-10x\/"},"modified":"2025-11-01T00:14:47","modified_gmt":"2025-11-01T00:14:47","slug":"reduza-suas-conexoes-kafka-em-10x","status":"publish","type":"post","link":"https:\/\/bloxnoticias.com.br\/en\/reduza-suas-conexoes-kafka-em-10x\/","title":{"rendered":"Reduza suas conex\u00f5es Kafka em 10x"},"content":{"rendered":"<h2>Listen to this article<\/h2>\n<p><!--[if lt IE 9]><script>document.createElement('audio');<\/script><![endif]-->\n<audio class=\"wp-audio-shortcode\" id=\"audio-3725-1\" preload=\"none\" style=\"width: 100%;\" controls=\"controls\"><source type=\"audio\/mpeg\" src=\"https:\/\/bloxnoticias.com.br\/wp-content\/uploads\/2025\/11\/reduza-suas-conexoes-kafka-em-10x.mp3?_=1\" \/><a href=\"https:\/\/bloxnoticias.com.br\/wp-content\/uploads\/2025\/11\/reduza-suas-conexoes-kafka-em-10x.mp3\">https:\/\/bloxnoticias.com.br\/wp-content\/uploads\/2025\/11\/reduza-suas-conexoes-kafka-em-10x.mp3<\/a><\/audio><br \/>\n<\/p>\n<p>Neste artigo voc\u00ea aprende a usar um <strong>sidecar por pod<\/strong> para cortar drasticamente as <strong>connections<\/strong> with <strong>Kafka<\/strong>. Entenda por que cada processo abre conex\u00f5es, por que solu\u00e7\u00f5es como aumentar brokers ou proxies simples n\u00e3o resolvem e como um produtor central por pod preserva <strong>ordering<\/strong>, melhora <strong>batching<\/strong> e reduz a carga no broker. Veja como integrar o <strong>sidecar<\/strong> via <strong>gRPC<\/strong> com mudan\u00e7as m\u00ednimas no c\u00f3digo, monitorar com <strong>m\u00e9tricas<\/strong> e fazer um <strong>rollout<\/strong> seguro com <strong>fallback<\/strong> para evitar perda de dados. Ao final h\u00e1 passos pr\u00e1ticos para estabilizar seu cluster e reduzir o estresse dos brokers.<\/p>\n<ul>\n<li>Conte conex\u00f5es, n\u00e3o s\u00f3 throughput<\/li>\n<\/ul>\n<ul>\n<li>Use um sidecar por pod para reduzir muito as conex\u00f5es<\/li>\n<\/ul>\n<ul>\n<li>Preserva ordena\u00e7\u00e3o por parti\u00e7\u00e3o ao centralizar envios<\/li>\n<\/ul>\n<ul>\n<li>Mudan\u00e7a leve de operar com rollback local seguro<\/li>\n<\/ul>\n<ul>\n<li>Me\u00e7a tentativas, confirma\u00e7\u00f5es e lat\u00eancia e defina metas<\/li>\n<\/ul>\n<h2 id=\"reduzindoconexeskafkaem10xcomumpadrosidecar\">Reduzindo conex\u00f5es Kafka em 10x com um padr\u00e3o sidecar<\/h2>\n<p>Aqui est\u00e1 um passo a passo pr\u00e1tico sobre como cortamos as conex\u00f5es do Kafka em cerca de <strong>10x<\/strong> numa grande instala\u00e7\u00e3o: o que n\u00e3o funcionou, a solu\u00e7\u00e3o que usamos, por que ajudou e como adaptar isso ao seu ambiente.<\/p>\n<h2 id=\"oquenofuncionoueporqu\">O que n\u00e3o funcionou (e por qu\u00ea)<\/h2>\n<p>Voc\u00ea provavelmente j\u00e1 tentou atalhos r\u00e1pidos. Testamos estes e falharam:<\/p>\n<ul>\n<li><strong>Adicionar mais brokers<\/strong><br \/>Cada produtor mant\u00e9m conex\u00f5es persistentes com os brokers l\u00edderes das parti\u00e7\u00f5es. Espalhar parti\u00e7\u00f5es por mais brokers aumenta o n\u00famero de conex\u00f5es por produtor.<\/li>\n<\/ul>\n<ul>\n<li><strong>Aumentar RAM\/CPU nas VMs<\/strong><br \/>Kafka depende do cache do SO e da JVM; aumentar recursos sem abordar o multiplicador de conex\u00f5es n\u00e3o resolve o problema central.<\/li>\n<\/ul>\n<ul>\n<li><strong>Colocar um proxy gen\u00e9rico<\/strong><br \/>Protocolos como o Kafka mant\u00eam sess\u00f5es longas. Pooling simples quebra performance e ordem.<\/li>\n<\/ul>\n<ul>\n<li><strong>Tunar o cliente<\/strong><br \/>Ajustes (linger, timeouts, buffers) ajudam pouco. N\u00e3o impedem m\u00faltiplos processos por pod de abrirem conex\u00f5es separadas.<\/li>\n<\/ul>\n<h2 id=\"asoluoumsidecarprodutorporpod\">A solu\u00e7\u00e3o: um sidecar produtor por pod<\/h2>\n<p>Execute um pequeno servi\u00e7o local no mesmo pod que mant\u00e9m <strong>um \u00fanico produtor Kafka por pod<\/strong>. Os processos do app conversam com o sidecar via gRPC para enviar eventos.<\/p>\n<p>Como funciona:<\/p>\n<ul>\n<li>O app chama RPC Emit(topic, key, headers, bytes).<\/li>\n<\/ul>\n<ul>\n<li>O sidecar envia ao broker e responde com um ack.<\/li>\n<\/ul>\n<ul>\n<li>Se o sidecar cair, o app pode usar fallback para emitir direto ao Kafka (opcional).<\/li>\n<\/ul>\n<p>Interface m\u00ednima (pseudoc\u00f3digo):<\/p>\n<ul>\n<li>Emit(topic, key?, headers, event<em>bytes) \u2192 { success: bool, error<\/em>code, retry<em>after<\/em>ms }<\/li>\n<\/ul>\n<ul>\n<li>DeliveryStream \u2192 stream bidirecional de relat\u00f3rios cont\u00ednuos de sucesso\/erro<\/li>\n<\/ul>\n<h2 id=\"porqueajudou\">Por que ajudou<\/h2>\n<p>O sidecar resolve o ponto cr\u00edtico: multiplica\u00e7\u00e3o de conex\u00f5es.<\/p>\n<ul>\n<li><strong>Menos conex\u00f5es<\/strong><br \/>Muitos processos por pod se consolidam em uma conex\u00e3o por broker por pod, cortando conex\u00f5es dramaticamente.<\/li>\n<\/ul>\n<ul>\n<li><strong>Preserva ordena\u00e7\u00e3o<\/strong><br \/>Escritas para uma parti\u00e7\u00e3o saem pelo mesmo produtor do pod, mantendo a ordem por parti\u00e7\u00e3o.<\/li>\n<\/ul>\n<ul>\n<li><strong>Escala horizontal limpa<\/strong><br \/>Escalando pods, voc\u00ea escala sidecars; n\u00e3o volta o fan\u2011out por processo.<\/li>\n<\/ul>\n<ul>\n<li><strong>Fallback seguro<\/strong><br \/>Se um sidecar falhar, o problema se limita ao pod afetado.<\/li>\n<\/ul>\n<ul>\n<li><strong>Leve e com pouco retrabalho<\/strong><br \/>O sidecar consome pouco CPU\/RAM para workloads de produtor e normalmente exige s\u00f3 mudan\u00e7a de configura\u00e7\u00e3o.<\/li>\n<\/ul>\n<h2 id=\"resultadosobservados\">Resultados observados<\/h2>\n<p>Ap\u00f3s migrar os maiores servi\u00e7os:<\/p>\n<ul>\n<li>Conex\u00f5es pico: ca\u00edram cerca de <strong>10x<\/strong>.<\/li>\n<\/ul>\n<ul>\n<li>Uso de heap dos brokers: caiu ~<strong>70 pontos percentuais<\/strong> no pico.<\/li>\n<\/ul>\n<ul>\n<li>Picos de CPU \/ GC: desapareceram, reduzindo timeouts.<\/li>\n<\/ul>\n<h2 id=\"notasdeimplementaoparaadaptaraoseustack\">Notas de implementa\u00e7\u00e3o para adaptar ao seu stack<\/h2>\n<p>Passos pr\u00e1ticos:<\/p>\n<ul>\n<li>Preparation<\/li>\n<\/ul>\n<ul>\n<li>Me\u00e7a linha de base: conex\u00f5es por broker, uso de heap, lat\u00eancia tail, taxa de sucesso de emiss\u00e3o.<\/li>\n<\/ul>\n<ul>\n<li>Identifique pods com muitos processos que abrem conex\u00f5es.<\/li>\n<\/ul>\n<ul>\n<li>Client toggle<\/li>\n<\/ul>\n<ul>\n<li>Adicione no wrapper Kafka um modo <strong>sidecar<\/strong> que usa gRPC local quando habilitado.<\/li>\n<\/ul>\n<ul>\n<li>Backpressure e retries<\/li>\n<\/ul>\n<ul>\n<li>Sidecar deve ter fila por parti\u00e7\u00e3o e regras claras de retry.<\/li>\n<\/ul>\n<ul>\n<li>Defina limites de fila e pol\u00edticas de rejei\u00e7\u00e3o.<\/li>\n<\/ul>\n<ul>\n<li>M\u00e9tricas e SLOs<\/li>\n<\/ul>\n<ul>\n<li>Registre: contagem de requests, profundidade da fila, lat\u00eancias (p50\/p95\/p99), taxas de erro.<\/li>\n<\/ul>\n<ul>\n<li>Defina SLOs e alerte se muitos pods ca\u00edrem para fallback.<\/li>\n<\/ul>\n<ul>\n<li>Compress\u00e3o e batch<\/li>\n<\/ul>\n<ul>\n<li>Consolidar produtores aumenta o tamanho m\u00e9dio do batch, melhora compress\u00e3o e reduz banda.<\/li>\n<\/ul>\n<ul>\n<li>Rollout<\/li>\n<\/ul>\n<ul>\n<li>Comece com pods que mais conectam.<\/li>\n<\/ul>\n<ul>\n<li>Fa\u00e7a deploy por pod com feature flag. Monitore conex\u00f5es, GC e taxa de sucesso.<\/li>\n<\/ul>\n<ul>\n<li>Fallback seguro<\/li>\n<\/ul>\n<ul>\n<li>Permita emiss\u00e3o direta caso o sidecar falhe para evitar perda de dados enquanto corrige o problema.<\/li>\n<\/ul>\n<h2 id=\"oqueconstrumosemantivemos\">O que constru\u00edmos (e mantivemos)<\/h2>\n<ul>\n<li><strong>gRPC sidecar<\/strong> com endpoints: Emit (un\u00e1rio) e DeliveryStream (stream de relat\u00f3rios).<\/li>\n<\/ul>\n<ul>\n<li><strong>M\u00e9trica de qualidade de emiss\u00e3o<\/strong>: contagem de tentativa vs ack por app\/t\u00f3pico.<\/li>\n<\/ul>\n<ul>\n<li><strong>Relat\u00f3rios de entrega<\/strong>: sidecar mant\u00e9m ring buffer e envia relat\u00f3rios cont\u00ednuos; o worker consome e executa callbacks locais.<\/li>\n<\/ul>\n<ul>\n<li><strong>Modo de cliente toggle<\/strong>: mudan\u00e7a por configura\u00e7\u00e3o, sem reescrever o app.<\/li>\n<\/ul>\n<h2 id=\"operaeseobservabilidade\">Opera\u00e7\u00f5es e observabilidade<\/h2>\n<ul>\n<li>Conte conex\u00f5es, n\u00e3o s\u00f3 throughput: m\u00faltiplos processos multiplicam conex\u00f5es; impacto direto na heap dos brokers.<\/li>\n<\/ul>\n<ul>\n<li>M\u00e9tricas essenciais: attempt-to-ack success rate por app\/t\u00f3pico, lat\u00eancia end\u2011to\u2011end, queue depth no sidecar, taxa de fallback.<\/li>\n<\/ul>\n<ul>\n<li>Alertas: muitos pods em fallback simult\u00e2neo; queda na taxa de sucesso de emiss\u00e3o.<\/li>\n<\/ul>\n<h2 id=\"antesedepoistopologiadeconexo\">Antes e depois: topologia de conex\u00e3o<\/h2>\n<ul>\n<li>Antes: cada processo abre conex\u00f5es para cada broker.<br \/>Ex.: 1000 pods \u00d7 10 processos \u00d7 10 brokers = <strong>100.000 conex\u00f5es<\/strong>.<\/li>\n<\/ul>\n<ul>\n<li>Depois: cada pod tem 1 produtor.<br \/>Ex.: 1000 pods \u00d7 1 produtor \u00d7 10 brokers = <strong>10.000 conex\u00f5es<\/strong>.<\/li>\n<\/ul>\n<h2 id=\"oquemedirduranteorolloutprioridade\">O que medir durante o rollout (prioridade)<\/h2>\n<ul>\n<li>Conex\u00f5es por broker (count)  <\/li>\n<\/ul>\n<ul>\n<li>Uso de heap JVM dos brokers  <\/li>\n<\/ul>\n<ul>\n<li>Lat\u00eancia p99 de emiss\u00e3o  <\/li>\n<\/ul>\n<ul>\n<li>Taxa de sucesso de entrega (attempt vs ack)  <\/li>\n<\/ul>\n<ul>\n<li>Profundidade das filas do sidecar  <\/li>\n<\/ul>\n<ul>\n<li>Taxa de fallback por pod<\/li>\n<\/ul>\n<h2 id=\"dicasprticas\">Dicas pr\u00e1ticas<\/h2>\n<ul>\n<li>Comece pequeno: migre os piores ofensores primeiro.  <\/li>\n<\/ul>\n<ul>\n<li>Mantenha o blast radius pequeno: sidecar por pod \u00e9 simples para debugar.  <\/li>\n<\/ul>\n<ul>\n<li>M\u00e9tricas antes e depois: compare linhas de base.  <\/li>\n<\/ul>\n<ul>\n<li>Prefira operacionalidade: solu\u00e7\u00f5es simples e f\u00e1ceis de operar vencem truques complexos.  <\/li>\n<\/ul>\n<ul>\n<li>Documente SLOs e procedimentos de rollback.<\/li>\n<\/ul>\n<h2 id=\"emissiondeliveryreportscomointegrarcallbacks\">Emission delivery reports \u2014 como integrar callbacks<\/h2>\n<ul>\n<li>O sidecar exp\u00f5e um stream gRPC de delivery reports.  <\/li>\n<\/ul>\n<ul>\n<li>O worker abre uma thread que consome o stream.  <\/li>\n<\/ul>\n<ul>\n<li>O worker mapeia relat\u00f3rios para callbacks na linguagem do app.<\/li>\n<\/ul>\n<h2 id=\"takeaways\">Takeaways<\/h2>\n<ul>\n<li>Conte conex\u00f5es, n\u00e3o s\u00f3 throughput.  <\/li>\n<\/ul>\n<ul>\n<li>One <strong>sidecar por pod<\/strong> corta conex\u00f5es em ordem de magnitude quando h\u00e1 muitos processos.  <\/li>\n<\/ul>\n<ul>\n<li>M\u00e9tricas e rollout gradual s\u00e3o essenciais.  <\/li>\n<\/ul>\n<ul>\n<li>Mantenha o design simples e previs\u00edvel \u2014 boring wins.<\/li>\n<\/ul>\n<h2 id=\"recursoseducacionaiseartigosrelacionados\">Recursos educacionais e artigos relacionados<\/h2>\n<ul>\n<li>Leia sobre o talk do Robinhood sobre proxy\/sidecar para consumidores \u2014 foi grande inspira\u00e7\u00e3o.  <\/li>\n<\/ul>\n<ul>\n<li>Para refer\u00eancia t\u00e9cnica complementar, veja: https:\/\/zapier.com\/blog\/reducing-kafka-connections-sidecar.  <\/li>\n<\/ul>\n<ul>\n<li>Veja artigos do time de engenharia sobre KEDA, Thanos, Prometheus e gest\u00e3o de segredos.<\/li>\n<\/ul>\n<h2 id=\"comoozapierpodeajudarsuaprodutividade\">Como o Zapier pode ajudar sua produtividade<\/h2>\n<ul>\n<li>Use Zapier para automatizar tarefas repetitivas entre apps.  <\/li>\n<\/ul>\n<ul>\n<li>Zapier conecta <strong>8.000 apps<\/strong> sem c\u00f3digo e pode notificar times quando m\u00e9tricas passarem de um limiar.  <\/li>\n<\/ul>\n<ul>\n<li>Para estudos de caso e leituras pr\u00e1ticas sobre arquitetura e otimiza\u00e7\u00e3o, confira tamb\u00e9m https:\/\/zapier.com\/blog\/reducing-kafka-connections-sidecar.<\/li>\n<\/ul>\n<h2 id=\"quemescreveucrditos\">Quem escreveu \/ cr\u00e9ditos<\/h2>\n<p>Projeto liderado por engenheiros de site reliability. Cr\u00e9ditos: Mahsa Khoshab, Sugat Mahanti, Sarah Story. Inspira\u00e7\u00e3o: Robinhood. Texto adaptado para aplicar no seu ambiente.<\/p>\n<h2 id=\"concluso\">Conclusion<\/h2>\n<p>Usar um <strong>sidecar por pod<\/strong> transforma um caos de conex\u00f5es em uma arquitetura limpa: centraliza o envio, <strong>reduz conex\u00f5es (~10x)<\/strong>, preserva ordena\u00e7\u00e3o por parti\u00e7\u00e3o, melhora <strong>batching<\/strong> e diminui press\u00e3o sobre os brokers. A mudan\u00e7a \u00e9 simples de operar, permite rollout por pod, monitora m\u00e9tricas essenciais (conex\u00f5es, heap, lat\u00eancias, fallback) e oferece fallback seguro para evitar perda de dados. Comece pelos maiores ofensores, me\u00e7a antes\/depois e mantenha o blast radius pequeno \u2014 boring wins.<\/p>\n<p>Para mais guias pr\u00e1ticos, veja tamb\u00e9m https:\/\/zapier.com\/blog\/reducing-kafka-connections-sidecar e outros artigos em https:\/\/bloxnoticias.com.br.<\/p>\n<h2 id=\"perguntasfrequentes\">Frequently Asked Questions<\/h2>\n<ul>\n<li>O que causa a explos\u00e3o de conex\u00f5es Kafka?<br \/>A cada broker que tem uma parti\u00e7\u00e3o, o cliente abre uma conex\u00e3o TCP. Muitos processos por pod multiplicam essas conex\u00f5es.<\/li>\n<\/ul>\n<ul>\n<li>Por que multiprocessing piora o problema?<br \/>Bibliotecas Kafka n\u00e3o s\u00e3o fork-safe: cada subprocesso cria seu pr\u00f3prio produtor e conex\u00f5es.<\/li>\n<\/ul>\n<ul>\n<li>Por que adicionar mais brokers n\u00e3o resolve?<br \/>Mais brokers espalham parti\u00e7\u00f5es e aumentam o conjunto de brokers que cada produtor precisa contatar.<\/li>\n<\/ul>\n<ul>\n<li>Por que aumentar RAM nos brokers n\u00e3o \u00e9 solu\u00e7\u00e3o?<br \/>Aumentar heap traz tradeoffs de GC e n\u00e3o resolve o consumo extra de metadados por muitas conex\u00f5es.<\/li>\n<\/ul>\n<ul>\n<li>Por que um proxy simples n\u00e3o funciona como PgBouncer?<br \/>Kafka mant\u00e9m estado por sess\u00e3o e espera conex\u00f5es longas; proxies simples n\u00e3o preservam essas garantias.<\/li>\n<\/ul>\n<ul>\n<li>O que \u00e9 o sidecar producer por pod?<br \/>\u00c9 um processo gRPC local que executa um \u00fanico produtor Kafka por pod; apps enviam eventos ao sidecar.<\/li>\n<\/ul>\n<ul>\n<li>Como o sidecar reduz conex\u00f5es em ~10x?<br \/>Consolida muitos produtores por pod em um \u00fanico produtor, reduzindo o fan\u2011out de conex\u00f5es.<\/li>\n<\/ul>\n<ul>\n<li>A ordena\u00e7\u00e3o por parti\u00e7\u00e3o \u00e9 mantida?<br \/>Sim \u2014 eventos do mesmo pod para uma parti\u00e7\u00e3o passam pelo mesmo produtor.<\/li>\n<\/ul>\n<ul>\n<li>E se o sidecar ficar indispon\u00edvel?<br \/>H\u00e1 fallback: o cliente pode emitir direto ao Kafka, limitando o impacto ao pod afetado.<\/li>\n<\/ul>\n<ul>\n<li>Quais m\u00e9tricas devo monitorar?<br \/>Contagem de requisi\u00e7\u00f5es, profundidade de filas, tamanho de batch, lat\u00eancia (p50\/p95\/p99\/p99.9), taxa de erros, conex\u00f5es por broker e GC dos brokers.<\/li>\n<\/ul>\n<ul>\n<li>Como funcionam os delivery reports com sidecar?<br \/>Sidecar exp\u00f5e um stream gRPC; o app consome esse stream para executar callbacks locais.<\/li>\n<\/ul>\n<ul>\n<li>Como \u00e9 a interface m\u00ednima do sidecar?<br \/>Uma RPC Emit(ProduceRequest) que envia topic, key, headers e bytes do evento e retorna ack com sucesso\/erro e retry<em>after<\/em>ms.<\/li>\n<\/ul>\n<ul>\n<li>Quais resultados operacionais foram observados?<br \/>Redu\u00e7\u00e3o de conex\u00f5es de producers ~10x em pico; uso de heap dos brokers caiu ~70pp; picos de CPU\/GC desapareceram.<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>Aprenda a reduzir suas conex\u00f5es Kafka em 10x com um m\u00e9todo simples e inesperado \u2014 aumente desempenho, reduza custos e evite gargalos agora.<\/p>","protected":false},"author":4,"featured_media":3726,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[627],"tags":[],"class_list":["post-3725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-produtividade"],"_links":{"self":[{"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/posts\/3725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/comments?post=3725"}],"version-history":[{"count":2,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/posts\/3725\/revisions"}],"predecessor-version":[{"id":3735,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/posts\/3725\/revisions\/3735"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/media\/3726"}],"wp:attachment":[{"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/media?parent=3725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/categories?post=3725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bloxnoticias.com.br\/en\/wp-json\/wp\/v2\/tags?post=3725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}