Melhores Práticas de Configuração do Kafka para Ambientes de Produção

O Kafka é tolerante em desenvolvimento e muito menos tolerante em produção. Um tópico com uma réplica funciona bem até que um corretor morra. Um produtor com confirmações fracas parece rápido até que mensagens desapareçam durante uma falha. Um consumidor que faz commit automático de offsets parece simples até que ele confirme trabalho que não foi realmente concluído. A configuração do Kafka em produção é principalmente sobre decidir quais falhas você está disposto a tolerar e tornar essas decisões explícitas.

Este guia aborda as melhores práticas de configuração do Kafka para ambientes de produção sem fingir que existe um arquivo de configuração perfeito. As configurações corretas dependem da carga de trabalho, necessidades de latência, requisitos de durabilidade, maturidade operacional e versão do Kafka. Os exemplos abaixo são pontos de partida que você deve testar sob seu próprio tráfego.

Entendendo os Principais Componentes do Kafka e Sua Configuração

Antes de mergulhar em configurações específicas, é crucial entender os componentes principais do Kafka e como suas configurações impactam o comportamento geral do sistema.

Corretores (Brokers): Os servidores Kafka que armazenam dados e atendem a solicitações de clientes. A configuração do corretor dita desempenho, utilização de recursos e tolerância a falhas.
Tópicos: Categorias ou feeds de mensagens que são publicados.
Partições: Os tópicos são divididos em uma ou mais partições, permitindo paralelismo no processamento e armazenamento.
Replicação: O processo de copiar partições entre vários corretores para garantir durabilidade e disponibilidade dos dados em caso de falhas de corretores.
Grupos de Consumidores: Um grupo de consumidores que cooperam para consumir mensagens de um tópico. O Kafka garante que cada mensagem dentro de um tópico seja entregue a no máximo um consumidor dentro de cada grupo de consumidores.

Estratégias de Tópicos e Particionamento

A configuração eficaz de tópicos e partições é fundamental para a escalabilidade e desempenho do Kafka.

Número de Partições

Escolher o número certo de partições é uma decisão crítica. Mais partições permitem maior paralelismo no lado do consumidor, ou seja, mais instâncias de consumidores podem processar dados simultaneamente. No entanto, muitas partições podem sobrecarregar os recursos do corretor (memória, I/O de disco) e aumentar a latência. Uma regra prática comum é começar com um número de partições que reflita sua taxa de transferência máxima esperada do consumidor, considerando que você pode querer adicionar mais partições posteriormente, se necessário.

Consideração: O número máximo de partições que um corretor pode manipular é limitado por sua memória. Cada partição requer memória para suas réplicas líder e seguidora.
Recomendação: Busque um número de partições que esteja alinhado com suas necessidades de paralelismo do consumidor, mas evite particionamento excessivo. Monitore a utilização de recursos do corretor para encontrar um equilíbrio ideal.

Chave de Particionamento

Ao produzir mensagens, uma chave de particionamento (geralmente uma chave de registro) determina em qual partição uma mensagem será escrita. O particionamento consistente é essencial para o processamento ordenado dentro de um grupo de consumidores.

partitioner.class: Esta configuração do produtor pode ser definida como org.apache.kafka.clients.producer.internals.DefaultPartitioner (padrão, usa hash da chave) ou um particionador personalizado.
Melhor Prática: Use uma chave que distribua as mensagens uniformemente entre as partições. Se mensagens com a mesma chave precisam ser processadas em ordem, o Kafka garante a ordem apenas dentro de uma partição.

Replicação e Tolerância a Falhas

A replicação é o principal mecanismo do Kafka para garantir durabilidade e disponibilidade dos dados.

Fator de Replicação

O fator de replicação determina quantas cópias de cada partição são mantidas no cluster. Para ambientes de produção, um fator de replicação mínimo de 3 é altamente recomendado.

Benefício: Com um fator de replicação de 3, o Kafka geralmente pode tolerar uma falha de corretor enquanto mantém outra réplica disponível. A disponibilidade exata depende de min.insync.replicas, acks do produtor, configurações de eleição de líder e quais corretores falham.
Configuração: Isso é definido no nível do tópico, durante a criação do tópico ou por meio de comandos kafka-topics.sh.

# Exemplo: Criar um tópico com fator de replicação 3
kafka-topics.sh --create --topic meu-topico-de-producao --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Esta configuração do corretor dita o número mínimo de réplicas que devem confirmar uma operação de gravação antes que ela seja considerada bem-sucedida. Para tópicos com um fator de replicação de N, definir min.insync.replicas=M (onde M < N) garante que uma gravação seja confirmada somente após M réplicas a terem confirmado. Para evitar perda de dados, min.insync.replicas deve ser tipicamente definido como N-1 ou N/2 + 1, dependendo de suas compensações de disponibilidade e durabilidade.

Recomendação: Para tópicos críticos, defina min.insync.replicas como fator_de_replicacao - 1. Isso garante que pelo menos duas réplicas (em uma configuração de 3 réplicas) tenham os dados antes de confirmar a gravação, evitando perda se o líder falhar.
Configuração: Esta é uma configuração de nível de corretor e também pode ser definida por tópico.

# broker.properties
min.insync.replicas=2

# Configuração de nível de tópico (substitui a configuração do corretor)
# kafka-configs.sh --alter --topic meu-topico-critico --bootstrap-server ... --add-config min.insync.replicas=2

Eleição de Líder e Controlador

O Kafka usa um corretor controlador para gerenciar o estado do cluster, incluindo a liderança das partições. Configurações robustas do controlador são vitais.

controller.quorum.voters: Em clusters baseados em KRaft, isso especifica os eleitores do quórum do controlador. Clusters baseados em ZooKeeper usam uma configuração de plano de controle diferente, portanto, não copie esta configuração cegamente entre arquiteturas.
num.io.threads e num.network.threads: Essas configurações do corretor controlam o número de threads dedicados a lidar com solicitações de I/O e rede. Ajuste com base na carga de trabalho e CPU disponível.

Configurações do Produtor e Consumidor

Otimizar as configurações do produtor e consumidor é fundamental para alcançar alta taxa de transferência e baixa latência.

Configurações do Produtor

acks: Controla o número de confirmações necessárias das réplicas. Definir acks=all (ou -1) fornece a garantia de durabilidade mais forte. Combinado com min.insync.replicas, isso é crucial para produção.
retries: Defina para um valor alto (por exemplo, Integer.MAX_VALUE) para garantir que falhas transitórias não levem à perda de mensagens. Use max.in.flight.requests.per.connection efetivamente com novas tentativas.
max.in.flight.requests.per.connection: Controla o número máximo de solicitações não confirmadas que podem ser enviadas a um corretor. Clientes mais antigos costumavam usar 1 para evitar reordenamento com novas tentativas. Produtores idempotentes modernos podem preservar a ordenação com limites seguros mais altos, mas verifique sua versão e configurações do cliente.
batch.size e linger.ms: Essas configurações controlam o lote de mensagens. Lotes maiores podem melhorar a taxa de transferência, mas aumentam a latência. linger.ms adiciona um pequeno atraso para permitir que mais mensagens sejam agrupadas.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Configurações do Consumidor

auto.offset.reset: Para produção, latest é frequentemente preferido para evitar o reprocessamento de mensagens antigas na reinicialização. earliest pode ser usado se você precisar reprocessar mensagens desde o início.
enable.auto.commit: Defina como false para processamento confiável. Commits manuais lhe dão controle sobre quando os offsets são confirmados, evitando reentrega ou perda de mensagens. Use commitSync() ou commitAsync() para commits explícitos.
max.poll.records: Controla o número máximo de registros retornados em uma única chamada poll(). Ajuste para gerenciar a carga de processamento e evitar rebalanceamentos de consumidores.
isolation.level: Defina como read_committed ao usar transações do Kafka para garantir que os consumidores leiam apenas mensagens confirmadas.

# consumer.properties
group.id=meu-grupo-consumidor
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Considerações de Segurança

Proteger seu cluster Kafka é inegociável em ambientes de produção.

Autenticação e Autorização

SSL/TLS: Criptografe a comunicação entre clientes e corretores, e entre os próprios corretores. Isso requer a geração e distribuição de certificados.
SASL (Camada de Autenticação e Segurança Simples): Use mecanismos SASL como GSSAPI (Kerberos), PLAIN ou SCRAM para autenticar clientes.
Autorização (ACLs): Configure Listas de Controle de Acesso (ACLs) para definir quais usuários ou principais podem realizar operações específicas (ler, escrever, criar tópico, etc.) em quais recursos (tópicos, grupos de consumidores).

Criptografia

ssl.enabled.protocols: Certifique-se de usar protocolos seguros como TLSv1.2 ou TLSv1.3.
ssl.cipher.suites: Configure conjuntos de cifras fortes.

Exemplo de Configuração (Produtor com SASL sobre TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="meuusuario" password="minhasenha";
ssl.truststore.location=/caminho/para/truststore.jks
ssl.truststore.password=senha

Ajuste de Desempenho e Monitoramento

O monitoramento e ajuste contínuos são essenciais para manter o desempenho ideal.

Ajuste do Corretor

num.partitions: Embora esta seja uma configuração de nível de tópico, o corretor precisa lidar com o número total de partições. Monitore CPU, memória e I/O de disco.
log.segment.bytes e log.roll.hours: Controlam o tamanho e a frequência de rolagem dos segmentos de log. Segmentos menores podem levar a mais manipuladores de arquivos abertos e maior sobrecarga. Segmentos maiores podem consumir mais espaço em disco por segmento, mas reduzem a sobrecarga.
message.max.bytes: O tamanho máximo de uma mensagem em bytes. Certifique-se de que seja grande o suficiente para seu caso de uso, mas não excessivamente.
replica.fetch.max.bytes: Controla o número máximo de bytes por solicitação de busca por uma réplica seguidora. Ajuste para equilibrar a eficiência da busca e o uso de memória.

Ajuste da JVM

Tamanho do Heap: Aloque memória heap suficiente para a JVM executando o Kafka. Monitore o uso do heap e a atividade do GC.
Coletor de Lixo: Escolha um algoritmo de GC apropriado (por exemplo, G1GC é frequentemente recomendado para Kafka).

Monitoramento

Implemente monitoramento abrangente usando ferramentas como Prometheus/Grafana, Datadog ou soluções de monitoramento específicas do Kafka.

Métricas Chave: Monitore a saúde do corretor, taxa de transferência do tópico, lag do consumidor, status da replicação, latência de solicitação e utilização de recursos (CPU, memória, disco, rede).
Alertas: Configure alertas para condições críticas, como alto lag do consumidor, falta de resposta do corretor ou esgotamento do espaço em disco.

Rebalanceamentos de Grupo de Consumidores

Os rebalanceamentos de grupo de consumidores ocorrem quando consumidores entram ou saem de um grupo, ou quando as partições são reatribuídas. Rebalanceamentos frequentes podem interromper o processamento.

session.timeout.ms: Quanto tempo um corretor espera por um batimento cardíaco de um consumidor antes de considerá-lo morto. Valores mais baixos significam detecção mais rápida, mas podem levar a rebalanceamentos prematuros devido a falhas de rede.
heartbeat.interval.ms: Com que frequência os consumidores enviam batimentos cardíacos. Deve ser significativamente menor que session.timeout.ms.
max.poll.interval.ms: O tempo máximo entre chamadas de poll de um consumidor. Se um consumidor demorar mais do que isso para processar mensagens e fazer poll novamente, ele será considerado morto, acionando um rebalanceamento. Certifique-se de que seus consumidores possam processar mensagens dentro deste intervalo.
Dica: Otimize a lógica de processamento do consumidor para concluir o trabalho dentro de max.poll.interval.ms e evite rebalanceamentos desnecessários devido a consumidores lentos.

Padrões de Produção que Eu Decidiria Explicitamente

Não deixe o comportamento importante do Kafka para padrões acidentais. Alguns padrões são razoáveis para uso geral, mas os sistemas de produção precisam de decisões que correspondam aos dados.

Para fluxos de eventos críticos, use um fator de replicação de 3 ou mais onde o cluster tenha corretores e racks suficientes para suportá-lo. Combine isso com acks=all nos produtores e min.insync.replicas=2 em um tópico de três réplicas. Essa combinação significa que uma gravação só é confirmada quando o líder e pelo menos um seguidor em sincronia a possuem. Se muitas réplicas ficarem fora de sincronia, os produtores receberão erros em vez de aceitar silenciosamente uma durabilidade mais fraca.

Essa compensação é intencional. Durante uma falha, um tópico altamente durável pode rejeitar gravações em vez de confirmar dados que estão apenas em um corretor. Alguns sistemas preferem disponibilidade em vez de durabilidade para certos dados de telemetria ou clique. Tudo bem se for uma escolha consciente. É perigoso quando ninguém percebe que o tópico foi configurado dessa forma.

Desative a eleição de líder suja para tópicos onde a perda de dados não é aceitável. A eleição suja pode trazer uma partição de volta online elegendo uma réplica fora de sincronia, mas essa réplica pode estar perdendo registros confirmados, dependendo do histórico de falhas e das configurações do produtor. Para dados críticos, permanecer indisponível é muitas vezes melhor do que perder ou retroceder registros sem aviso.

Número de Partições: Escolha para Taxa de Transferência e Operações

O número de partições controla o paralelismo, mas mais partições não são gratuitas. Cada partição adiciona metadados, manipuladores de arquivos, trabalho de replicação, trabalho de eleição de líder e sobrecarga de recuperação. Também afeta o comportamento do grupo de consumidores. Um tópico com 200 partições pode suportar mais paralelismo de consumidor do que um tópico com 12, mas também cria mais peças móveis durante reinicializações de corretores e rebalanceamentos.

Comece estimando o paralelismo e a taxa de transferência do consumidor. Se o serviço consumidor executar no máximo 12 instâncias, 48 partições podem ser suficientes. Se você espera centenas de threads de processamento independentes, pode precisar de mais. Deixe espaço para crescimento, porque aumentar as partições posteriormente pode alterar a distribuição de chaves e o comportamento de ordenação para mensagens chaveadas.

A ordenação é garantida apenas dentro de uma partição. Se todos os eventos para cliente_id=123 devem ser processados em ordem, use uma chave estável baseada nesse ID de cliente. Não espere ordenação em todo o tópico. Também fique atento a chaves quentes. Se um cliente, inquilino ou dispositivo produzir uma grande parcela do tráfego, o particionamento baseado em chave pode sobrecarregar uma partição enquanto outras ficam ociosas.

Para sistemas multi-inquilinos, considere se um tópico compartilhado ou muitos tópicos de inquilino são mais fáceis de operar. Muitos tópicos minúsculos podem criar sobrecarga de metadados. Um tópico compartilhado enorme pode complicar a retenção, o controle de acesso e a resposta a incidentes. A melhor escolha depende dos requisitos de isolamento e da forma do tráfego.

Retenção é uma Decisão de Produto, Não Apenas uma Configuração do Corretor

A retenção do Kafka determina por quanto tempo os dados permanecem disponíveis para reprodução. Retenção curta economiza disco, mas limita a recuperação. Retenção longa permite backfills e fluxos de trabalho de auditoria, mas aumenta o custo de armazenamento e o tempo de recuperação.

Defina a retenção por tópico com base em como os dados são usados. Um tópico de comando pode precisar apenas de uma janela curta. Um tópico de histórico de eventos pode precisar de dias ou semanas. Um tópico compactado que representa o estado mais recente usa um modelo diferente: o Kafka mantém o valor mais recente por chave após a compactação, mais marcadores de exclusão até a limpeza.

Configurações comuns incluem:

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Para tópicos compactados:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Tenha cuidado com mensagens grandes. O Kafka pode lidar com registros maiores quando configurado de forma consistente, mas aumentar message.max.bytes significa verificar max.request.size do produtor, fetch.max.bytes do consumidor, configurações de busca de réplica do corretor e impacto na memória. Em muitos sistemas, armazenar grandes cargas úteis em armazenamento de objetos e enviar uma referência através do Kafka é mais simples e confiável.

Configurações do Produtor que Evitam Dor

Para a maioria dos produtores de produção, ative a idempotência a menos que você tenha um motivo específico para não fazê-lo. A produção idempotente ajuda a evitar gravações duplicadas causadas por novas tentativas após falhas transitórias. Muitos clientes Kafka modernos a ativam automaticamente sob certas configurações, mas vale a pena tornar a decisão visível em sua configuração de produtor.

Exemplo de linha de base do produtor:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

A escolha de compressão depende do orçamento de CPU e da versão do Kafka. zstd geralmente oferece forte compressão, enquanto lz4 e snappy são escolhas comuns de baixa latência. Teste com suas cargas úteis. Logs JSON, registros Avro, mensagens protobuf e dados binários já compactados se comportam de maneira diferente.

O lote é outra compensação. Um linger.ms pequeno dá ao produtor uma janela curta para agrupar registros, o que pode melhorar a taxa de transferência e a compressão. Configurá-lo muito alto adiciona latência. Para caminhos de solicitação voltados para o usuário, mantenha os orçamentos de latência em mente. Para ingestão em segundo plano, um pouco mais de espera pode ser aceitável.

Não ignore os erros do produtor. Se acks=all e min.insync.replicas rejeitarem uma gravação durante problemas no corretor, isso é um backpressure útil. O aplicativo deve decidir se deve tentar novamente, armazenar em buffer, falhar a solicitação ou rotear para um fallback. Registrar o erro e descartar o evento não é uma estratégia de durabilidade.

Configurações do Consumidor que Correspondem à Semântica de Processamento

Os commits de offset do consumidor definem o que "processado" significa. Com enable.auto.commit=true, o cliente pode confirmar offsets antes que seu aplicativo tenha concluído o trabalho com segurança. Isso pode ser aceitável para análises descartáveis, mas é arriscado para pagamentos, pedidos, implantações ou qualquer coisa onde perder um evento dói.

Para processamento confiável, desative o commit automático e confirme após o trabalho ser concluído:

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

A estratégia de commit depende do aplicativo. commitSync() é mais simples e fornece comportamento de falha claro, mas pode adicionar latência. commitAsync() pode melhorar a taxa de transferência, mas você precisa lidar com falhas de callback com cuidado. Muitos serviços confirmam periodicamente após lotes bem-sucedidos e tornam as gravações downstream idempotentes para que a reprodução seja segura.

Se o processamento de uma mensagem pode levar muito tempo, reduza max.poll.records, aumente max.poll.interval.ms ou mova o trabalho lento para uma fila interna enquanto o loop de poll continua de forma responsável. Um consumidor que para de fazer poll por muito tempo aciona um rebalanceamento, e rebalanceamentos repetidos fazem todo o grupo parecer instável.

Use associação estática para consumidores que reiniciam com frequência, mas retornam com identidades estáveis. Isso pode reduzir rebalanceamentos desnecessários durante implantações contínuas. O rebalanceamento cooperativo também pode reduzir a interrupção em comparação com o rebalanceamento ansioso, dependendo do suporte do cliente.

Segurança que as Equipes Podem Operar

O Kafka de produção deve usar criptografia em trânsito quando o tráfego atravessa redes não confiáveis ou carrega dados confidenciais. A maioria das organizações deve usar TLS para comunicação cliente-corretor e inter-corretor. A autenticação pode ser TLS mútuo, SASL/SCRAM, Kerberos, OAuth ou outro mecanismo suportado, dependendo do ambiente.

As ACLs devem ser específicas o suficiente para evitar danos acidentais. Um produtor para pedidos.criados não precisa de permissão para escrever em todos os tópicos. Um grupo de consumidores para faturamento não precisa de permissão para alterar configurações do corretor. Use convenções de nomenclatura que tornem as ACLs legíveis e mantenha os principais de serviço vinculados a aplicativos, não a humanos individuais.

Os segredos precisam de rotação. Se as credenciais SASL ou keystores forem copiadas manualmente para servidores, a rotação se torna dolorosa e eventualmente para de acontecer. Use o gerenciador de segredos da sua plataforma quando possível. Teste a rotação em staging, incluindo reinicializações contínuas de clientes.

Decida também quem pode criar tópicos. A criação automática de tópicos é conveniente em desenvolvimento e perigosa em produção. Um erro de digitação em um nome de tópico pode criar um novo tópico com partições padrão, replicação padrão e retenção padrão. Muitos clusters de produção desabilitam a criação automática de tópicos e gerenciam tópicos por meio de código de infraestrutura ou um fluxo de trabalho aprovado.

Verificações de Corretor e Armazenamento

O Kafka é sensível ao disco. Use armazenamento com latência previsível, monitore o uso do disco agressivamente e mantenha espaço livre suficiente para retenção, recuperação de replicação e erros operacionais. Um corretor com disco cheio pode criar um incidente muito maior do que um corretor com CPU alta.

Separe os logs do Kafka de cargas de trabalho ruidosas não relacionadas. Evite colocar dados do Kafka em discos compartilhados onde outro processo pode consumir repentinamente I/O. Em ambientes de nuvem, entenda os limites de taxa de transferência do volume, créditos de burst e comportamento de recuperação. Um disco que tem bom desempenho por um minuto ainda pode ter dificuldades sob replicação e compactação sustentadas.

A conscientização de rack é importante quando você tem várias zonas de disponibilidade ou racks. Configure IDs de rack do corretor e posicionamento do tópico para que as réplicas não estejam todas no mesmo domínio de falha. Um fator de replicação de 3 é menos útil se todas as três réplicas desaparecerem com um problema de rack ou zona.

Monitoramento e Alertas que Capturam Falhas Reais

Uma configuração de monitoramento útil do Kafka observa tanto os internos do Kafka quanto a experiência do cliente. As métricas do corretor sozinhas não informam se os consumidores estão acompanhando ou se os produtores estão vendo erros.

Monitore partições sub-replicadas, partições offline, contagem de controladores ativos, latência de solicitação, taxas de erro de produção e busca, taxa de transferência de rede, uso de disco, latência de I/O de disco, taxas de redução e expansão de ISR, tempo de fila de eventos do controlador, lag do consumidor, taxa de rebalanceamento e contagens de novas tentativas/erros do cliente.

O lag do consumidor precisa de contexto. Um lag de 100 registros pode ser bom em um tópico que recebe milhões por hora. Um lag de 100 pode ser grave em um tópico de comando de baixo volume. Alerte sobre a idade do lag ou tempo para recuperação quando possível, não apenas a contagem bruta de registros.

Teste reinicializações de corretores durante janelas de manutenção antes da primeira falha real. Um cluster Kafka de produção deve sobreviver a uma reinicialização planejada de corretor sem perda de dados e sem surpreender os clientes. Se uma reinicialização de corretor criar um incidente grave, o cluster já estava frágil.

Uma Verificação de Prontidão para Produção

Antes de considerar um cluster Kafka pronto para produção, eu verificaria estes itens:

Tópicos críticos têm partições, fator de replicação, retenção, política de limpeza e min.insync.replicas explícitos.
Produtores para tópicos críticos usam acks=all, idempotência onde suportado, novas tentativas e tratamento de erros claro.
Consumidores confirmam offsets somente após o aplicativo ter atingido seu ponto de processamento pretendido.
TLS, autenticação e ACLs estão habilitados e testados.
A criação automática de tópicos está desabilitada ou estritamente controlada.
O monitoramento cobre a saúde do corretor, erros do cliente, lag do consumidor, disco e replicação.
As expectativas de backup ou reprodução estão documentadas. A retenção do Kafka não substitui todas as necessidades de backup.
Procedimentos de reinicialização de corretor, implantação de cliente e rotação de credenciais foram testados.

A Conclusão Prática

A configuração de produção do Kafka é um conjunto de compensações, não uma receita universal. Torne as escolhas de durabilidade, ordenação, reprodução, segurança e latência explícitas por tópico e por aplicativo. Em seguida, teste essas escolhas com reinicializações de corretores, falhas de cliente, consumidores lentos e cenários de disco cheio antes que o tráfego de produção lhe ensine a lição.