# Kafka em Escala: Tiered Storage, KRaft e Exactly-Once Uma análise aprofundada da arquitetura interna do Apache Kafka, modelo de log/segmentos, eliminação do ZooKeeper via KRaft, offload de dados para S3 com Tiered Storage, semântica exactly-once e o que o Amazon MSK abstrai (e o que ele não abstrai). Um teardown técnico para quem precisa operar Kafka de verdade. - URL: https://fernando.moretes.com/studies/kafka-tiered-storage-kraft-exactly-once - Markdown: https://fernando.moretes.com/studies/kafka-tiered-storage-kraft-exactly-once/study.md?lang=pt - Type: Teardown - Company: Apache Kafka / Amazon MSK - Domain: Streaming - Date: 2024-06-01 - Tags: kafka, streaming, event-driven, amazon-msk, tiered-storage, kraft, exactly-once, data-platform - Reading time: 10 min --- Kafka não é uma fila. Essa distinção importa mais do que parece, ela define como você dimensiona, como você retém dados, como você garante entrega e, principalmente, onde você vai errar em produção. Neste teardown, desmonto a arquitetura interna do Kafka a partir das fontes primárias: o modelo de log imutável, a transição do ZooKeeper para o KRaft, o Tiered Storage com offload para S3, a semântica exactly-once com producers idempotentes e transações, e o que o Amazon MSK realmente gerencia, e o que ainda fica na sua conta. ## Ficha Técnica - **Sistema:** Apache Kafka + Amazon MSK - **Domínio:** Streaming de eventos / Plataforma de dados - **Versão de referência:** Kafka 3.x (KRaft GA: 3.3+, Tiered Storage GA: 3.6+) - **Escala típica (produção):** Milhões de mensagens/segundo; retenção de TB a PB por cluster - **Stack principal:** Java/Scala (broker), Apache ZooKeeper (legado), KRaft (Raft interno), Amazon S3 (tiered storage via MSK) - **MSK, disponibilidade:** Multi-AZ por padrão; SLA AWS de 99,9% - **Mudança arquitetural chave:** Remoção do ZooKeeper (KIP-500/833); ZooKeeper deprecated no Kafka 3.5, removido no 4.0 - **Fontes primárias:** kafka.apache.org/documentation, KIP-405, docs.aws.amazon.com/msk ## O Problema Fundamental: Log, Não Fila A abstração central do Kafka é o **log de partição**: uma sequência imutável, append-only, de registros ordenados por offset. Isso não é detalhe de implementação, é a decisão de design que explica tudo o mais. Filas tradicionais (SQS, RabbitMQ) deletam mensagens após o consumo; o Kafka retém. Isso permite múltiplos consumer groups lendo o mesmo dado de forma independente, reprocessamento determinístico e auditoria nativa. O preço é que **o broker precisa gerenciar retenção ativa**, e disco local vira gargalo em clusters com alto volume ou retenção longa. Cada tópico é dividido em **partições**, cada partição replicada entre brokers conforme o fator de replicação configurado. O broker líder de cada partição aceita writes; os followers replicam de forma síncrona (se no ISR: In-Sync Replica set). Um producer escreve para o líder; o registro só é considerado committed quando todos os membros do ISR confirmam, esse é o contrato de durabilidade do Kafka. O parâmetro `acks=all` (ou `acks=-1`) junto com `min.insync.replicas` define o quórum mínimo de confirmação. Sem entender esse triângulo (líder, ISR, `acks`), qualquer discussão sobre exactly-once é prematura. O modelo de segmentos é onde o Kafka ganha eficiência de I/O: cada partição no disco é uma sequência de **segmentos** (arquivos `.log` + índices de offset e timestamp). O broker só escreve no segmento ativo (tail); segmentos fechados são imutáveis. Isso permite `sendfile()` direto do filesystem cache para o socket do consumer, zero-copy, sem passar pelo heap da JVM. Em workloads de alto throughput, o Kafka frequentemente satura a rede antes do disco, justamente por esse design. ## KRaft: Por Que o ZooKeeper Precisava Ir O ZooKeeper foi a escolha pragmática de 2011: um serviço de coordenação distribuída já maduro, que o Kafka usou para armazenar metadados de cluster (quais brokers estão vivos, quais são os líderes de partição, configurações de tópicos, ACLs). Funcionou por uma década, mas criou um **acoplamento arquitetural caro**: dois sistemas distribuídos para operar, dois modelos de segurança para configurar, e um gargalo de escala real, o ZooKeeper armazenava todos os metadados em memória, e clusters com centenas de milhares de partições começavam a sentir latência no controller election e na propagação de metadados. O **KRaft** (Kafka Raft Metadata) resolve isso via KIP-500: os próprios brokers Kafka passam a executar um protocolo Raft interno para consenso de metadados. Um subconjunto de brokers (ou nodes dedicados de controller) forma o **quórum de controllers**; o controller ativo mantém um log de metadados replicado, o mesmo modelo de log/segmento do Kafka, aplicado a si mesmo. Isso elimina o ZooKeeper como dependência operacional e, mais importante, **remove o limite prático de partições por cluster**: benchmarks da Confluent mostraram recuperação de controller failure em segundos com KRaft vs. dezenas de segundos com ZooKeeper em clusters grandes. A transição não foi trivial. O KIP-500 foi proposto em 2019; KRaft ficou em early access no Kafka 2.8 (2021), atingiu GA no 3.3 (2022) para novos clusters, e o suporte a migração de ZooKeeper para KRaft chegou no 3.5. O ZooKeeper foi oficialmente removido no Kafka 4.0 (2024). No Amazon MSK, clusters KRaft estão disponíveis a partir do Kafka 3.6 no MSK. **O ponto operacional crítico**: em modo KRaft, os controller nodes precisam de discos confiáveis e baixa latência de rede entre si, eles são o novo plano de controle do cluster. Em MSK, isso é abstraído; em clusters self-managed, é uma decisão de infraestrutura explícita. ## Arquitetura Kafka: Log, KRaft, Tiered Storage e Consumer Groups Visão reconstruída da arquitetura interna do Kafka 3.6+ com KRaft e Tiered Storage habilitado no Amazon MSK. Mostra o fluxo de escrita (producer → líder → ISR), o offload de segmentos frios para S3, o plano de controle KRaft e o consumo via consumer groups. ### 👤 Producers - Producer A idempotent + txn (external) - Producer B acks=all (external) ### ⚙️ MSK Broker Plane (Multi-AZ) - Broker 1 Partition Leader (AZ-a) (messaging) - Broker 2 ISR Follower (AZ-b) (messaging) - Broker 3 ISR Follower (AZ-c) (messaging) ### 🗂️ Local Storage (EBS/NVMe) - Segmentos Ativos (hot, local disk) (storage) - Segmentos Fechados (cold, candidatos a offload) (storage) ### ☁️ Tiered Storage (S3) - Amazon S3 Segmentos Offloaded (retenção longa) (storage) - Tiered Storage Plugin (RemoteLogManager) (compute) ### 🔐 KRaft Controller Quorum - Controller 1 (active: AZ-a) (compute) - Controller 2 (standby: AZ-b) (compute) - Controller 3 (standby: AZ-c) (compute) ### 📦 Consumer Groups - Consumer Group A (analytics, offset latest) (external) - Consumer Group B (audit, offset earliest / S3 fetch) (external) - Group Coordinator (broker-side) (messaging) ### Fluxos - p1 -> b1: write (acks=all) - p2 -> b1: write (idempotente) - b1 -> b2: replicação ISR - b1 -> b3: replicação ISR - b1 -> seg_hot: append segmento ativo - seg_hot -> seg_cold: segmento fechado (roll) - seg_cold -> ts_plugin: offload trigger - ts_plugin -> s3: upload segmento + índice - seg_cold -> ts_plugin: delete local após offload - kc1 -> b1: metadata / leader election - kc1 -> kc2: Raft replication - kc1 -> kc3: Raft replication - cg1 -> b1: fetch (local) - cg2 -> b1: fetch request - b1 -> s3: fetch remoto (tiered) - cg1 -> gc: heartbeat / rebalance - cg2 -> gc: heartbeat / rebalance ## Tiered Storage: Separando Hot de Cold no Log O KIP-405 (Tiered Storage) resolve um problema econômico real: **disco local em brokers Kafka é caro e não escala independentemente de compute**. Em clusters com retenção de dias ou semanas, a maior parte dos dados está fria, raramente lida, mas precisa estar disponível para reprocessamento ou auditoria. Manter isso em EBS ou NVMe local é desperdício. O mecanismo funciona assim: o `RemoteLogManager` (RLM), componente introduzido pelo KIP-405, monitora os segmentos fechados de cada partição. Quando um segmento atinge o critério de offload (configurável por tempo ou tamanho), o RLM faz upload do arquivo `.log`, dos índices de offset e timestamp, e dos metadados para o storage remoto, no caso do MSK, Amazon S3. Após confirmação do upload, o segmento local pode ser deletado, liberando disco. O broker mantém um **mapa de metadados remotos** que indica quais offsets estão em S3 vs. local. Do ponto de vista do consumer, o protocolo é transparente: ele faz um `FetchRequest` normal para o broker líder. Se o offset solicitado está em storage remoto, o broker busca o dado no S3, faz o cache localmente (configurável), e retorna ao consumer. O consumer não sabe que o dado veio de S3. Isso é elegante, mas tem implicações de latência: um fetch de dado frio tem latência de S3 (tipicamente dezenas de ms) vs. disco local ou page cache (sub-ms). **Para workloads de reprocessamento em lote, isso é aceitável; para consumidores que precisam de baixa latência em dados históricos, não é.** No Amazon MSK, o Tiered Storage é habilitado por configuração no cluster e usa S3 gerenciado pela AWS, você não configura o bucket diretamente, mas pode usar S3 Lifecycle Policies para controlar custo de armazenamento de longo prazo. A limitação atual: Tiered Storage no MSK não suporta todos os tipos de instância, e a compactação de log (log compaction) tem restrições com tiered storage habilitado, segmentos compactados não são elegíveis para offload em certas versões. Isso é crítico para tópicos de changelog (Kafka Streams, CDC). ## Exactly-Once: Idempotência, Transações e o Custo Real Exactly-once no Kafka é implementado em duas camadas complementares, e confundir as duas é um erro comum em entrevistas e em produção. **Camada 1: Producer Idempotente**: habilitado com `enable.idempotence=true` (default `true` desde Kafka 3.0). O broker atribui ao producer um `ProducerID` (PID) e rastreia o número de sequência por partição. Se o producer retransmite uma mensagem (por timeout ou falha de rede), o broker detecta o número de sequência duplicado e descarta, sem duplicatas no log. Isso garante **exactly-once por partição, por sessão de producer**. Custo: praticamente zero, é bookkeeping no broker, sem coordenação distribuída adicional. **Camada 2: Transações**: habilitado com `transactional.id` no producer. O producer coordena com um **Transaction Coordinator** (um broker especial eleito por hash do `transactional.id`) para abrir, commitar ou abortar uma transação que pode abranger múltiplas partições e múltiplos tópicos. O mecanismo usa um **two-phase commit interno**: o coordinator grava o estado da transação em um tópico interno (`__transaction_state`) antes de instruir os brokers a marcar as mensagens como committed. Consumers com `isolation.level=read_committed` só veem mensagens de transações commitadas, mensagens de transações abertas ou abortadas são filtradas. O custo real das transações é não-trivial: latência adicional de round-trip para o Transaction Coordinator, overhead de escrita no `__transaction_state`, e **o risco de transações zumbis**: producers que falharam sem abortar a transação, deixando-a aberta até o `transaction.timeout.ms`. Em sistemas de alto throughput, transações muito grandes (muitas mensagens em uma transação) ou muito frequentes (uma transação por mensagem) degradam throughput significativamente. A recomendação prática: **batch suas transações por janela de tempo ou contagem de registros**, não por mensagem individual. Um ponto frequentemente ignorado: exactly-once **end-to-end** (producer → broker → consumer → sink) requer que o sink também seja idempotente ou transacional. O Kafka garante exactly-once no log; se o consumer processa e grava em um banco sem idempotência, você ainda tem at-least-once no sistema como um todo. O Kafka Streams implementa exactly-once end-to-end usando transações Kafka para coordenar leitura, processamento e escrita atomicamente, mas isso só funciona quando source e sink são ambos Kafka. ## Consumer Groups, Rebalance e o Problema do Stop-the-World O modelo de consumer group é o que permite Kafka escalar o consumo horizontalmente: cada partição é atribuída a exatamente um consumer dentro do grupo, e múltiplos grupos podem consumir o mesmo tópico independentemente. O **Group Coordinator** (um broker eleito por hash do `group.id`) gerencia o ciclo de vida do grupo: join, sincronização de assignment, heartbeats e detecção de falhas. O problema clássico é o **rebalance**: sempre que um consumer entra, sai, ou para de enviar heartbeats dentro de `session.timeout.ms`, o coordinator dispara um rebalance. No protocolo original (Eager Rebalance), **todos os consumers do grupo param de consumir, revogam todas as partições, e aguardam o novo assignment**. Em grupos grandes com muitas partições, isso pode causar pausas de segundos a dezenas de segundos, um stop-the-world distribuído. O Kafka 2.4 introduziu o **Cooperative Sticky Assignor** (KIP-429/KIP-482), que implementa rebalance incremental: apenas as partições que precisam ser movidas são revogadas; as demais continuam sendo consumidas durante o rebalance. Isso reduz drasticamente o impacto, mas requer que todos os consumers do grupo usem um assignor cooperativo, um detalhe de configuração que frequentemente é esquecido em migrações. Outro ponto operacional crítico: `max.poll.interval.ms` define o tempo máximo entre duas chamadas a `poll()`. Se o processamento de um batch demora mais que esse intervalo (processamento pesado, chamadas externas lentas), o consumer é considerado morto pelo coordinator e um rebalance é disparado, mesmo que o consumer esteja vivo e processando. Isso cria um loop de rebalances em workloads com processamento variável. A solução não é aumentar `max.poll.interval.ms` indefinidamente (isso atrasa a detecção de falhas reais), mas **reduzir o tamanho do batch via `max.poll.records`** para garantir que o processamento caiba dentro do intervalo configurado. No Amazon MSK, esses parâmetros são configuráveis por consumer, o MSK não os gerencia; eles ficam inteiramente na sua aplicação. ## Trade-offs Arquiteturais: Decisões Chave no Design do Kafka ### KRaft vs. ZooKeeper **Pros** - Elimina dependência operacional do ZooKeeper - Recovery de controller em segundos (vs. dezenas de segundos) - Suporte a clusters com milhões de partições - Modelo de segurança unificado **Cons** - Migração de clusters existentes requer procedimento específico (3.5+) - Controller nodes precisam de discos confiáveis em self-managed - Ecossistema de tooling ainda em adaptação (monitoramento, etc.) **Verdict:** Adote KRaft para novos clusters. Sem exceções. ### Tiered Storage (S3) vs. Retenção Local **Pros** - Custo de armazenamento drasticamente menor para dados frios - Escala de retenção independente de compute - Transparente para consumers (sem mudança de protocolo) **Cons** - Latência de fetch para dados frios (dezenas de ms vs. sub-ms) - Incompatibilidade com log compaction em certas versões - Custo de API S3 (GET/PUT) pode surpreender em alta frequência de offload **Verdict:** Ideal para retenção longa (>24h) com acesso esporádico a dados históricos. Evite em tópicos compactados. ### Exactly-Once Transactions vs. At-Least-Once + Idempotência no Sink **Pros** - Garantia nativa no broker; sem lógica de deduplicação no consumer - Necessário para Kafka Streams EOS **Cons** - Latência adicional (round-trip ao Transaction Coordinator) - Throughput reduzido se transações muito frequentes ou grandes - Não garante EOS end-to-end se o sink não for idempotente **Verdict:** Use transações onde o custo de duplicata é alto (financeiro, CDC). Para analytics, at-least-once + idempotência no sink é mais simples e mais rápido. ### Amazon MSK vs. Kafka Self-Managed (EC2/EKS) **Pros** - MSK: sem overhead de gestão de brokers, patches, ZK/KRaft - MSK: integração nativa com IAM, VPC, CloudWatch, S3 (tiered) - MSK: Multi-AZ por design; failover automático de broker **Cons** - MSK: menos controle sobre configurações de broker (algumas são fixas) - MSK: custo mais alto que EC2 equivalente em escala muito grande - Self-managed: flexibilidade total, mas overhead operacional real **Verdict:** MSK para a maioria dos casos. Self-managed apenas se você tem equipe dedicada de plataforma e requisitos que o MSK não suporta. ## Leitura Well-Architected: Kafka / Amazon MSK - **security**: O Kafka tem um modelo de segurança multidimensional: autenticação (SASL/PLAIN, SCRAM, mTLS, IAM no MSK), autorização (ACLs por recurso, tópico, grupo, cluster), e criptografia em trânsito (TLS) e em repouso (EBS encryption no MSK). O ponto crítico: ACLs no Kafka são aditivas e granulares, um producer mal configurado com permissão de `WRITE` em `*` (todos os tópicos) é um vetor de injeção de dados. No MSK com IAM auth, as políticas IAM substituem as ACLs internas para autenticação, mas as ACLs ainda podem coexistir. - **reliability**: Confiabilidade no Kafka é função direta de três configurações: fator de replicação (≥3 em produção), `min.insync.replicas` (≥2, tipicamente RF-1), e `acks=all` no producer. O MSK gerencia failover de broker automaticamente, mas o tempo de eleição de líder ainda impacta producers durante o failover: `retries` e `retry.backoff.ms` no producer devem ser configurados para absorver esse intervalo. Com KRaft, o controller election é mais rápido, reduzindo a janela de indisponibilidade. - **performance**: O Kafka é otimizado para throughput, não para latência de mensagem individual. O mecanismo de batching no producer (`linger.ms`, `batch.size`) é fundamental: aumentar `linger.ms` de 0 para 5-20ms pode multiplicar o throughput por 10x às custas de latência de ponta a ponta. Compressão (`snappy` ou `lz4`) reduz uso de rede e disco com custo de CPU mínimo em dados textuais/JSON. No MSK, o tipo de instância define o throughput máximo de rede, instâncias `kafka.m5.4xlarge` e superiores têm Enhanced Networking habilitado. - **cost**: O custo do MSK tem três componentes: instâncias de broker (por hora), armazenamento EBS (por GB/mês), e transferência de dados (intra-AZ é gratuita; inter-AZ tem custo). Tiered Storage adiciona custo de S3 (armazenamento + API), mas tipicamente reduz o custo total ao permitir instâncias menores com menos EBS. O custo oculto mais comum: **retenção excessiva em tópicos de alto volume sem Tiered Storage**: times que configuram `retention.ms=7d` em tópicos de 100MB/s precisam de ~60TB de EBS por réplica. > **O que eu faria diferente, e o que o mercado ainda erra:** Depois de operar e projetar sistemas sobre Kafka em contextos financeiros, há três padrões de erro que vejo repetidamente, e que eu abordaria de forma diferente. **1. Tiered Storage como afterthought, não como design inicial.** A maioria dos times habilita Tiered Storage depois que o custo de EBS já está alto e a migração é dolorosa. Eu definiria a política de tiered storage na criação do tópico: `local.retention.ms` para hot tier (ex: 6-24h), `retention.ms` para o total (ex: 30d em S3). Isso é uma decisão de dia zero, não de dia 90. **2. Exactly-once mal aplicado.** Vejo times habilitando `transactional.id` em todos os producers por "segurança", sem entender o custo. Em sistemas financeiros, exactly-once é necessário em fluxos de pagamento e reconciliação, não em telemetria ou logs de auditoria onde at-least-once + deduplicação no sink é mais eficiente. A decisão deve ser por fluxo, não por cluster. **3. Consumer group design negligenciado.** Times criam um consumer group por serviço e colocam múltiplas responsabilidades nele. Eu separo consumer groups por responsabilidade de processamento, um grupo para processamento em tempo real (baixo `max.poll.records`, alta prioridade de SLA), outro para batch/analytics (alto `max.poll.records`, tolerante a lag). Isso permite tuning independente e evita que um consumer lento em processamento pesado cause rebalances que afetam o fluxo em tempo real. O ponto mais importante que eu enfatizaria para qualquer time adotando Kafka: **o Kafka resolve o problema de transporte e retenção; ele não resolve o problema de contrato de dados**. Sem um schema registry (Confluent Schema Registry ou AWS Glue Schema Registry) com evolução de schema versionada, você vai quebrar consumers em produção em algum momento. Isso não é opcional em sistemas de produção sérios. ## Veredicto O Apache Kafka é uma das arquiteturas de software mais bem projetadas dos últimos 15 anos, o modelo de log imutável é simples, correto e escala de formas que sistemas de fila tradicionais não conseguem. A transição para KRaft remove o último grande ponto de fragilidade operacional (o ZooKeeper) sem comprometer o modelo de consistência. O Tiered Storage resolve o problema econômico de retenção longa de forma elegante, com trade-off de latência bem definido e documentado. O exactly-once é genuinamente útil e corretamente implementado no nível do broker, mas é frequentemente mal aplicado em produção, gerando overhead desnecessário ou, pior, uma falsa sensação de segurança quando o sink não é idempotente. O Amazon MSK é a escolha certa para a maioria dos times: elimina o overhead operacional de gestão de brokers e integra nativamente com o ecossistema AWS (IAM, VPC, S3, CloudWatch). A limitação real do MSK não é técnica, é que ele abstrai o suficiente para que times menos experientes subestimem o que ainda é responsabilidade deles: tuning de producer/consumer, design de consumer groups, schema management, e monitoramento de consumer lag. ## Referências - [Apache Kafka: Official Documentation](https://kafka.apache.org/documentation/) - [KIP-405: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) - [Amazon MSK: AWS Documentation](https://docs.aws.amazon.com/msk/) - [KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) - [KIP-429: Kafka Consumer Incremental Rebalance Protocol](https://cwiki.apache.org/confluence/display/KAFKA/KIP-429%3A+Kafka+Consumer+Incremental+Rebalance+Protocol) - [Kafka Exactly-Once Semantics: Confluent Blog](https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/) - [Amazon MSK Tiered Storage: AWS Docs](https://docs.aws.amazon.com/msk/latest/developerguide/msk-tiered-storage.html) ## Fontes do caso - [Apache Kafka: Documentation](https://kafka.apache.org/documentation/) - [KIP-405: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) - [Amazon MSK: AWS docs](https://docs.aws.amazon.com/msk/)