Kafka em produção: VPS para Apache Kafka no Brasil

Resposta direta

Uma VPS para Apache Kafka no Brasil faz sentido quando você precisa de baixa latência para aplicações brasileiras, controle do sistema operacional e previsibilidade de recursos para brokers, producers e consumers. Para um ambiente pequeno de produção, pense em pelo menos 2 a 4 vCPUs, 8 GB de RAM, disco SSD ou NVMe com folga para retenção e rede estável com boa saída para o seu público. Kafka depende muito de disco sequencial, cache de página do Linux e latência entre clientes e brokers, então escolher apenas o plano mais barato costuma sair caro. Em produção, o cenário mais seguro usa três nós, replicação configurada, monitoramento, firewall, autenticação, testes de restauração e confirmação dos recursos reais do provedor antes da contratação.

Resumo rápido

• Apache Kafka em VPS exige foco em disco, rede e memória, não apenas em quantidade de vCPU.
• Para laboratório sério, 2 vCPUs, 4 GB de RAM e 80 GB de SSD já permitem testes úteis, mas com retenção curta.
• Para produção pequena, 4 vCPUs, 8 GB de RAM e 160 GB ou mais de SSD NVMe são um ponto de partida mais seguro.
• Baixa latência no Brasil depende da região do datacenter, do caminho de rede e da proximidade entre aplicação, Kafka e banco de dados.
• NVMe ajuda em throughput e picos de escrita, mas não compensa partições mal distribuídas, retenção exagerada ou replicação mal planejada.
• Cluster com três brokers reduz risco operacional, desde que replication factor, min.insync.replicas e monitoramento estejam coerentes.
• Dados de preço, bandwidth, localidade, snapshots e tipo de disco devem ser confirmados nas páginas oficiais do provedor antes da publicação.

Quando faz sentido rodar Apache Kafka em VPS no Brasil

Apache Kafka é uma plataforma de streaming de eventos. Na prática, ele fica entre sistemas que produzem dados e sistemas que consomem esses dados, como APIs, aplicativos mobile, pipelines de analytics, sistemas antifraude, integrações de e-commerce e processamento assíncrono. A escolha por uma VPS para Apache Kafka no Brasil costuma aparecer quando o time quer fugir de hospedagem compartilhada, precisa de acesso root e não quer começar diretamente em um serviço gerenciado mais caro ou complexo.

Kafka não se comporta como uma fila simples. Ele mantém logs persistentes, trabalha com partições, replica dados entre brokers e depende bastante do cache de página do sistema operacional. Por isso, um servidor que roda bem um site institucional pode sofrer com Kafka se o disco tiver baixa consistência, se a rede oscilar ou se a retenção for calculada no chute. Se sua dúvida ainda está entre Kafka e uma fila mais tradicional, o conteúdo sobre VPS para RabbitMQ e filas de mensagens ajuda a separar cenários de mensageria clássica, filas de trabalho e streaming de eventos.

A localização no Brasil entra como critério forte quando producers e consumers também estão aqui. Uma API em São Paulo publicando eventos em um broker nos Estados Unidos pode adicionar dezenas ou centenas de milissegundos por operação, dependendo da rota. Para cargas com confirmação síncrona, esse atraso aparece rápido. Em um checkout, um evento de pedido que leva 180 ms extras pode não derrubar o sistema, mas piora a experiência quando várias chamadas encadeadas dependem desse fluxo.

Também existe diferença entre VPS tradicional, Cloud Server e instância cloud. Uma VPS tradicional costuma ser uma máquina virtual dentro de um servidor físico, com recursos definidos por plano. Um Cloud Server geralmente oferece provisionamento mais flexível, upgrades rápidos, imagens, snapshots e rede integrada, embora os detalhes variem muito por provedor. Instâncias de nuvens globais, como AWS, Google Cloud, Azure, DigitalOcean, Vultr ou Linode/Akamai, podem entregar ecossistemas amplos, mas nem sempre têm região brasileira disponível para todos os produtos. Provedores com presença local, incluindo opções brasileiras como LetsCloud, podem ser interessantes quando latência e pagamento local entram no cálculo, desde que disco, região, bandwidth e backup sejam confirmados por plano.

CPU e RAM: como dimensionar brokers sem desperdício

Kafka não costuma ser o serviço que mais consome CPU em uma arquitetura simples. O gargalo aparece com compressão, criptografia TLS, muitos clients conectados, alto número de partições, replicação intensa e consumers buscando dados com frequência. Mesmo assim, começar com 1 vCPU em produção é apertado. Um broker pequeno com 2 vCPUs pode atender laboratório, homologação ou cargas leves, mas uma produção minimamente confortável pede 4 vCPUs quando há tráfego contínuo, TLS habilitado e mais de uma aplicação usando o cluster.

A memória precisa ser pensada de forma diferente de um banco relacional. Kafka usa heap da JVM, mas também depende muito do cache de página do Linux. Em servidores pequenos, reservar toda a RAM para heap pode piorar o desempenho, porque sobra pouco espaço para o sistema operacional manter segmentos de log em cache. Em um broker com 8 GB de RAM, uma configuração inicial comum é deixar algo entre 2 GB e 4 GB para heap, observar GC, uso de page cache e latência de disco, depois ajustar. Para 16 GB de RAM, heaps entre 4 GB e 6 GB costumam ser mais realistas em muitos cenários, mas o teste com sua carga manda mais do que a regra genérica.

Um ponto prático: conte partições antes de contratar. Um tópico com 12 partições, replication factor 3 e retenção de 72 horas exige muito mais do que um tópico com 3 partições e retenção de 6 horas. Se você planeja 20 tópicos, cada um com 6 partições e replicação, o cluster já terá centenas de réplicas para gerenciar. Isso consome CPU, memória, descritores de arquivo e rede entre brokers. Nessa escala, 2 vCPUs deixam de ser economia e viram risco.

Para produção pequena, uma base honesta seria 3 brokers com 4 vCPUs e 8 GB de RAM cada, ou pelo menos um broker único com 4 vCPUs e 8 GB para aplicações menos críticas, aceitando o risco de indisponibilidade. Se a aplicação usa Kafka apenas para eventos internos de baixo volume, com 50 a 200 mensagens por segundo e payloads pequenos, 4 vCPUs podem sobrar. Se o fluxo recebe eventos de telemetry, logs ou pedidos em lote, a folga desaparece. O guia sobre como escolher CPU, RAM e NVMe aprofunda essa leitura de recurso por tipo de workload e combina bem com o planejamento de Kafka.

Disco NVMe, retenção e I/O: onde Kafka costuma sofrer

O disco é o recurso que mais engana em Kafka. Como ele grava eventos em logs sequenciais, muita gente assume que qualquer SSD resolve. Na prática, a consistência de I/O, a latência de fsync, a velocidade de leitura em reprocessamento e a capacidade total para retenção pesam muito. Um SSD SATA bom pode atender cargas moderadas. Um NVMe tende a oferecer latência menor e mais IOPS, mas a diferença real depende do plano, da camada de virtualização, do compartilhamento físico e da política do provedor. Não publique nem contrate assumindo NVMe universal. Confirme no plano e na localidade.

O cálculo de retenção precisa vir antes da escolha do disco. Imagine uma aplicação que produz 500 mensagens por segundo, cada uma com 2 KB em média. Isso dá cerca de 1 MB por segundo antes de compressão, algo próximo de 86 GB por dia. Com compressão lz4 ou zstd, esse número pode cair bastante, mas payloads JSON variam. Com retenção de 72 horas e replication factor 3, o volume bruto pode passar de 250 GB lógicos e virar centenas de gigabytes replicados no cluster. Se você contrata 160 GB por broker sem fazer conta, a limpeza por retenção vai bater antes do esperado.

Outro exemplo: um e-commerce médio publica eventos de pedido, pagamento, estoque e notificação. O volume pode parecer pequeno durante o dia, mas campanhas criam picos. Se o broker precisa absorver 5 mil mensagens por segundo por alguns minutos, o disco precisa aguentar escrita contínua sem latência subir demais. Quando o disco fica perto de 80 ou 90 por cento de uso, a margem de operação desaparece. Kafka não lida bem com disco cheio. O broker pode parar de aceitar escrita, consumers atrasam e o time descobre o problema no pior horário.

Em VPS, prefira separar o sistema operacional dos dados de Kafka quando o provedor permitir volumes extras. Monte o diretório de logs em um volume dedicado, por exemplo /var/lib/kafka, use filesystem estável como XFS ou ext4 e monitore disk usage, disk I/O wait, latência de escrita e tempo de flush. Também ajuste retenção por tópico. Eventos de auditoria podem precisar de 7 dias. Eventos de cache ou sincronização temporária talvez precisem de apenas 6 horas. A retenção global é confortável no começo, mas desperdiça disco quando os tópicos têm perfis diferentes.

Rede e latência no Brasil: o detalhe que muda a experiência

Kafka trabalha melhor quando clients e brokers estão próximos. Isso vale para distância geográfica e para topologia de rede. Uma aplicação em um Cloud Server no Brasil publicando eventos em Kafka também no Brasil tende a ter latência muito menor do que a mesma aplicação falando com brokers em uma região distante. Ainda assim, não basta ler Brasil na página comercial. Latência real depende de operadora, peering, rota, congestionamento e localidade exata do datacenter. Para aplicações sensíveis, faça testes com ping, mtr, iperf3 quando possível e medições no próprio client Kafka.

A baixa latência importa mais em cenários com acks=all, transações, producers síncronos ou fluxos que esperam confirmação antes de seguir. Se o producer usa batch pequeno e espera resposta do broker a cada lote, a latência de ida e volta entra no tempo total. Um RTT de 10 ms contra 150 ms muda completamente o throughput percebido quando a aplicação não está bem ajustada. O artigo sobre VPS para baixa latência no Brasil ajuda a pensar em rota, região e distância para workloads que dependem de resposta rápida.

Rede também é custo operacional. Kafka pode gerar tráfego interno alto por causa da replicação. Com replication factor 3, cada mensagem escrita no líder precisa ser replicada para outros brokers. Se os brokers estão em regiões diferentes, a latência sobe e a conta de transferência pode crescer. Em muitos casos, é melhor manter os brokers do mesmo cluster na mesma região e resolver desastre regional com outra estratégia, como MirrorMaker 2, Cluster Linking em plataformas compatíveis ou pipelines de replicação planejados.

Confirme bandwidth mensal, limite de porta, política de tráfego excedente e se há rede privada entre instâncias. Alguns provedores diferenciam tráfego público e privado. Outros cobram transferência de saída ou aplicam políticas de uso justo. Não coloque preço ou promessa de tráfego ilimitado em produção sem revisão humana, porque esses dados mudam com frequência. Para Kafka, o que parece detalhe comercial vira incidente técnico quando o cluster começa a replicar, consumers reprocessam dados e um deploy ruim gera tráfego duplicado por horas.

Arquitetura prática: broker único, cluster e KRaft

A arquitetura mais simples é um broker único em uma VPS. Ela serve para desenvolvimento, homologação, provas de conceito e aplicações internas com baixa criticidade. Um exemplo aceitável: 2 vCPUs, 4 GB de RAM, 80 GB de SSD, retenção de 6 a 24 horas, poucos tópicos e monitoramento básico. Esse desenho não entrega alta disponibilidade. Se a VPS reiniciar, Kafka para. Se o disco encher, a aplicação sofre. Se houver manutenção no provedor, o pipeline fica indisponível. Para muitos projetos pequenos, isso é aceitável desde que o risco esteja explícito.

Em produção, o desenho clássico usa três brokers. Com três nós, você pode configurar replication.factor=3, min.insync.replicas=2 e producers com acks=all. Assim, uma mensagem só é considerada confirmada quando há réplicas suficientes sincronizadas. Essa configuração reduz perda de dados em falha de um broker, mas aumenta uso de disco e rede. Não existe almoço grátis. Se cada broker tem 4 vCPUs, 8 GB de RAM e 200 GB de NVMe, o cluster parece maior do que um servidor único, mas a capacidade líquida precisa descontar replicação, retenção e margem de crescimento.

Sobre coordenação, versões recentes do Kafka avançaram no modo KRaft, que reduz a dependência do ZooKeeper. Para novos clusters, faz sentido estudar KRaft na documentação oficial e evitar montar uma arquitetura antiga por hábito. Ainda assim, a decisão deve considerar versão, maturidade operacional do time, ferramentas de administração e compatibilidade com seu ecossistema. Se você já opera Kafka com ZooKeeper, uma migração exige planejamento, janela e teste. Não trate como simples troca de parâmetro.

Um exemplo prático de produção pequena: três Cloud Servers no mesmo datacenter brasileiro, cada um com 4 vCPUs, 8 GB de RAM, 200 GB de SSD NVMe confirmado, rede privada entre nós, firewall liberando apenas portas necessárias, TLS para clients e métricas exportadas para Prometheus. Tópicos críticos usam replication factor 3. Tópicos temporários usam retenção curta. Consumers são acompanhados por lag. Esse desenho não substitui uma plataforma gerenciada para empresas que exigem SLA formal e operação 24 horas, mas entrega controle e custo previsível para times técnicos que sabem administrar Linux.

Tabela comparativa de perfis para Kafka

A tabela abaixo não é uma tabela de preços. Ela resume perfis técnicos para orientar o dimensionamento inicial em VPS ou Cloud Server. Antes de contratar, confirme no provedor se o disco é SSD ou NVMe naquela localidade, se há rede privada, qual é o limite de tráfego, quais snapshots existem e como funciona a restauração. Dados de preço, promoção e disponibilidade mudam com frequência e precisam de revisão humana.

Perfil de uso	Configuração inicial sugerida	Disco e retenção	Rede e latência	Risco operacional
Laboratório e homologação	1 broker, 2 vCPUs, 4 GB RAM	80 GB SSD, retenção de 6 a 24 horas	Pode rodar fora do Brasil se a aplicação também for teste	Indisponibilidade aceitável, sem alta disponibilidade
Produção pequena	1 broker forte ou 3 brokers menores, 4 vCPUs e 8 GB RAM por nó	160 a 250 GB SSD NVMe por broker, retenção por tópico	Preferir Brasil se producers e consumers estão no Brasil	Broker único tem ponto único de falha, cluster reduz risco
Produção com alta disponibilidade	3 brokers, 4 a 8 vCPUs, 16 GB RAM por nó	300 GB ou mais por broker, margem de 30 por cento livre	Mesma região, rede privada e baixa latência entre nós	Exige monitoramento, runbooks e teste de restore
Streaming intenso ou analytics	3 ou mais brokers, 8 vCPUs e 16 a 32 GB RAM por nó	NVMe confirmado, retenção calculada por volume diário	Bandwidth alto, cuidado com replicação e reprocessamento	Pode exigir serviço gerenciado ou arquitetura dedicada

Use a tabela como ponto de partida, não como receita fixa. Um SaaS B2B com 300 eventos por segundo e payload pequeno pode funcionar bem em produção pequena. Uma plataforma de observabilidade com logs de aplicação pode destruir esse mesmo dimensionamento em poucas horas. O tamanho médio da mensagem, o número de partições, a compressão, a retenção e o comportamento dos consumers pesam mais do que o nome do plano.

Também vale separar tráfego de ingestão e tráfego de reprocessamento. Durante operação normal, consumers acompanham os tópicos quase em tempo real. Depois de uma falha, um novo consumer group pode precisar ler dias de dados antigos. Esse reprocessamento pressiona disco e rede ao mesmo tempo. Se a VPS foi escolhida apenas pelo tráfego médio, o incidente vira gargalo. Por isso, mantenha margem no disco, monitore lag por consumer group e teste reprocessamento antes de chamar o ambiente de produção.

Segurança, backup e operação diária

Kafka exposto na internet sem controle é um problema sério. Em VPS, o time fica responsável por firewall, usuários, certificados, autenticação, atualização do sistema e política de acesso. O mínimo é bloquear portas públicas desnecessárias, permitir conexão apenas de IPs conhecidos ou VPN, usar SSH com chave, desabilitar login por senha, aplicar atualizações de segurança e separar usuários administrativos. Para Kafka, avalie TLS, SASL ou mTLS conforme o nível de sensibilidade dos dados. Eventos de pedido, pagamento, comportamento de usuário e auditoria não devem circular sem proteção.

Uma configuração comum envolve listeners separados. O broker pode ter um listener interno para comunicação entre nós em rede privada e outro listener externo para clients autorizados. O parâmetro advertised.listeners precisa refletir os endereços que os clients realmente alcançam. Muitos problemas de conexão em Kafka nascem desse detalhe. O broker sobe, a porta responde, mas o client recebe um endereço interno inacessível e falha ao buscar metadados. Em ambientes com NAT, load balancer ou VPN, teste producers e consumers de fora do servidor antes de liberar a aplicação.

Backup de Kafka merece cuidado. Copiar a pasta de logs de um broker em execução sem consistência pode gerar uma falsa sensação de segurança. Snapshots de volume ajudam, mas precisam ser coordenados e testados. Em muitos cenários, a estratégia mais confiável combina replicação, retenção adequada, infraestrutura como código, backup de configurações, exportação de ACLs e capacidade de reconstruir o cluster. Se os eventos são a fonte primária de verdade, a exigência sobe. Se Kafka apenas transporta eventos que também estão no banco principal, a estratégia pode ser diferente.

Monitore o básico desde o primeiro dia: uso de disco, UnderReplicatedPartitions, OfflinePartitionsCount, latência de produce, latência de fetch, lag dos consumer groups, uso de heap, pausas de GC, bytes in, bytes out e taxa de erro nos clients. Ferramentas como Prometheus, Grafana e exporters específicos de Kafka reduzem o tempo de diagnóstico. Um alerta simples de disco acima de 75 por cento e lag crescendo por 15 minutos já evita muita dor. Sem monitoramento, Kafka parece estável até o momento em que todos os consumidores param de acompanhar.

Recomendações por perfil

Dev solo e laboratório sério

Para um dev solo que quer aprender Kafka, validar uma arquitetura ou montar um ambiente de homologação, não faz sentido começar com três servidores. Uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD atende bem se a retenção for curta e os tópicos forem poucos. Use Docker Compose apenas se você souber onde os volumes persistentes estão montados. Para testes mais próximos da realidade, instale Kafka diretamente no sistema ou use containers com limites claros de memória, logs persistentes e métricas. Não exponha o broker publicamente. Mesmo laboratório merece firewall, SSH com chave e senha forte para qualquer painel.

Time pequeno com aplicação em produção

Um time pequeno que depende de Kafka para eventos de negócio deve pensar em estabilidade antes de economia máxima. Se o orçamento ainda não comporta cluster, escolha ao menos um Cloud Server com 4 vCPUs, 8 GB de RAM, SSD ou NVMe confirmado, 160 GB ou mais de disco e backup operacional das configurações. Aceite no documento interno que existe ponto único de falha. Se o sistema não pode parar, migre para três brokers. Em provedores com datacenter no Brasil, confirme latência real, rede privada, tipo de disco por plano e política de tráfego. LetsCloud pode entrar nessa avaliação quando região local e operação no Brasil forem critérios, mas disponibilidade de NVMe, snapshots e recursos específicos precisa ser verificada no site oficial.

Produção crítica com retenção e replicação

Para produção crítica, trate Kafka como infraestrutura de dados, não como um serviço auxiliar. O desenho recomendado começa em três brokers, cada um com 4 a 8 vCPUs, 16 GB de RAM e disco NVMe dimensionado pela retenção real. Configure replication factor 3, min.insync.replicas=2, acks=all, TLS, controle de acesso, métricas e alertas. Mantenha os brokers na mesma região para reduzir latência interna e use estratégia separada para desastre regional. Rode testes de falha: desligue um broker, force reprocessamento, simule disco cheio em ambiente controlado e valide restauração. Se o time não consegue operar isso 24 horas, um serviço gerenciado pode ser mais seguro do que uma VPS mal administrada.