Capacity Planning: Dimensione a Infraestrutura Antes que o Pico Dimensione Você

Todo sistema tem um teto. A pergunta não é se você vai encostar nele, é se vai descobrir onde ele está por um gráfico de planejamento ou por um pager tocando às três da manhã de uma sexta-feira de promoção. Capacity planning é a disciplina de responder a essa pergunta antes que o tráfego responda por você: quanta demanda o sistema aguenta hoje, quanta vai aguentar no mês que vem, e quanto de folga separa a operação normal do colapso. É trabalho de engenharia com régua, não de intuição com dedo molhado no vento.

Existe uma crença confortável de que a nuvem elástica aposentou esse assunto. "Escala sozinho, é só configurar o autoscaling." É meia-verdade, e a metade que falta é justamente a que derruba produção. Este guia é sobre a metade que falta.

Por que a nuvem elástica não matou o capacity planning#

A promessa da elasticidade é real, mas ela tem paredes concretas que você só vê quando bate nelas.

A primeira parede é a quota. Sua conta na cloud não pode criar máquinas infinitamente. Há limites por região, por tipo de instância, por família de vCPU. No dia do pico, quando você mais precisa subir cem instâncias, é exatamente quando descobre que a quota da região está em quarenta — e o pedido de aumento leva horas ou dias para ser aprovado por um humano do outro lado.

A segunda parede é o tempo de provisionamento. Uma instância nova não nasce pronta: ela boota, puxa imagem, inicializa runtime, aquece cache, entra no balanceador. Isso leva de dezenas de segundos a minutos. Se o seu pico sobe mais rápido do que a máquina fica pronta — e um lançamento com push de notificação sobe em segundos —, a capacidade que "escala sozinha" chega atrasada para o próprio incêndio. O cold start de funções serverless é a mesma armadilha em escala menor: a primeira requisição de cada instância paga o pedágio da inicialização.

A terceira parede é o custo. Escalar é sempre possível se você aceita pagar qualquer preço. Só que ninguém aceita. Escalar sem planejar é assinar um cheque em branco para o provedor, e no fim do mês alguém do financeiro vai querer conversar.

A quarta, e mais traiçoeira, são as dependências que não escalam junto. Seu serviço web sobe de dez para cem réplicas em um minuto. Lindo. Só que o banco de dados continua sendo uma instância só, com um pool de conexões finito. As cem réplicas abrem conexões, estouram o max_connections, e agora você tem cem processos saudáveis brigando por um recurso que não cresceu. A API de terceiros que você chama tem um rate limit de mil requisições por minuto — suas cem réplicas atropelam isso em segundos e começam a levar 429. Escalar a camada errada não resolve o gargalo; só muda o lugar onde ele explode.

Elasticidade é uma ferramenta poderosa de execução. Capacity planning é o que decide o que pedir a ela, quando, e até onde ela consegue entregar. Uma não substitui a outra.

Demanda, capacidade e a folga entre as duas#

Três conceitos organizam tudo o que vem a seguir.

Demanda é quanto trabalho o mundo pede ao seu sistema: requisições por segundo, mensagens na fila, gigabytes trafegados, transações por minuto. É uma variável externa — você a mede e prevê, mas não a controla.

Capacidade é quanto trabalho o sistema consegue fazer sem violar seus objetivos de latência e erro. Note a segunda metade da frase: capacidade não é o ponto onde o sistema para, é o ponto onde ele para de ser bom o suficiente. Um servidor a 99% de CPU ainda responde — só que devagar demais para importar.

Headroom é a folga entre a demanda de pico esperada e a capacidade instalada. É a margem de segurança que absorve o erro da sua previsão, o pico que ninguém previu, a instância que morreu, o deploy que ficou 20% mais pesado. Headroom não é desperdício; é o preço da tranquilidade operacional. Um sistema sem folga é um sistema que já está em incidente e ainda não sabe.

A regra mental é simples: você dimensiona a capacidade para o pico da demanda mais o headroom, nunca para a média. Voltaremos com força a esse ponto, porque planejar pela média é o erro número um do ofício.

Levantando a linha de base a partir do histórico#

Não dá para planejar o futuro sem medir o presente com honestidade. A linha de base vem das suas métricas históricas, e ela tem três componentes que precisam ser separados.

Percentis, não médias. A média mente. Se você tem mil requisições a 10 ms e uma a 10 segundos, a média fica bonita e o usuário daquela requisição de 10 segundos está xingando. Trabalhe com percentis: p50 conta a experiência típica, p95 e p99 contam a cauda que dói. Para demanda, o que interessa é o percentil alto do tráfego — dimensione para o p99 do RPS observado, não para o RPS médio do dia. Uma consulta PromQL para a série de pico por janela poderia ser algo como:

``promql max_over_time( sum(rate(http_requests_total[1m]))[7d:1m] ) ``

Isso te dá o RPS de pico da última semana, agregando por minuto e pegando o máximo — o número que importa para dimensionar, não a linha suave que a média desenharia.

Sazonalidade. O tráfego respira em ciclos. Há o ciclo diário (madrugada vazia, pico no horário comercial ou à noite, depende do seu público), o ciclo semanal (fim de semana diferente de dia útil), e às vezes o mensal (dia de pagamento, fechamento). Se você mede um único número, perde a forma. O pico das 20h de terça pode ser o triplo da média de 24 horas. Planejar contra a média de 24h significa estar subdimensionado toda terça à noite, todas as terças.

Tendência. Sobre a sazonalidade se soma o crescimento de médio prazo. O tráfego deste mês comparado ao mesmo mês do ano passado, a inclinação dos últimos seis meses. É a tendência que transforma "está tranquilo hoje" em "vai apertar em março". Um crescimento orgânico de 8% ao mês dobra a demanda em menos de um ano — e dobrar em um ano é rápido demais para ser resolvido no susto.

A linha de base, então, não é um número: é uma curva com forma diária e semanal, projetada para frente pela tendência, lida no percentil que dói.

Modelagem por dimensão: ache o recurso gargalo#

"Capacidade" no singular é uma simplificação perigosa, porque um sistema satura pela dimensão mais fraca, não pela média das dimensões. Modele cada recurso separadamente.

• CPU. O suspeito óbvio. Serviços de cálculo, serialização, compressão, criptografia batem aqui primeiro. Meça em cores efetivos e desconfie de médias que escondem picos de milissegundos.
• Memória. Não escala linearmente com carga e é implacável: quando acaba, o processo é morto (OOM), não desacelerado. Cache, buffers, conexões e o working set de cada requisição somam. Memória é uma dimensão de cliff, não de ladeira — você vai bem até não ir mais.
• IO de disco. Bancos, filas, logs. O limite raramente é espaço; é IOPS e throughput. Um volume que aguenta 3.000 IOPS vira gargalo muito antes de a CPU suar, e a latência de IO se propaga para cima como melado.
• Banda de rede. Serviços que servem mídia, fazem replicação ou movem grandes payloads esbarram no limite da NIC ou da largura de banda contratada antes de qualquer outra coisa.
• Conexões de banco. O gargalo silencioso do escalonamento horizontal. max_connections é finito, cada conexão custa memória no servidor de banco, e mais réplicas de aplicação significam mais pressão sobre esse número fixo. Pool e proxy de conexão existem exatamente por causa desta dimensão.
• Limites de terceiros. Rate limits de APIs externas, quotas de gateway de pagamento, throughput de provedores de e-mail ou SMS. São capacidades que você não controla e não pode escalar — só respeitar, enfileirar ou negociar.

O trabalho é encontrar qual dessas dimensões estoura primeiro sob a sua carga real. Esse é o gargalo, e ele é o único número que define sua capacidade. Adicionar CPU num sistema limitado por IOPS não move a agulha um milímetro — só aumenta a fatura. Identificar o gargalo certo é metade do capacity planning.

O número mágico da utilização-alvo#

Aqui está a intuição mais contraintuitiva e mais importante do assunto: você não quer rodar seus recursos a 100%. Nem perto disso.

O reflexo de eficiência diz o contrário — "CPU a 50% é metade do dinheiro jogado fora, bota pra 90%". Esse reflexo está errado, e a teoria das filas explica por quê.

Modele um recurso servidor como uma fila M/M/1: chegadas aleatórias, um servidor, tempo de serviço variável. O resultado clássico dessa fila é que o tempo de espera cresce proporcionalmente a 1 / (1 - ρ), onde ρ é a utilização (a fração do tempo em que o servidor está ocupado). Olhe o que esse fator faz conforme você aperta:

| Utilização (ρ) | Fator de espera 1/(1−ρ) | Leitura prática | |---|---|---| | 50% | 2× | folga confortável | | 70% | 3,3× | ainda saudável | | 80% | 5× | começa a doer | | 90% | 10× | latência explodindo | | 95% | 20× | à beira do colapso | | 99% | 100× | qualquer rajada derruba |

A latência não sobe de forma linear com a utilização — ela sobe como uma parede à medida que você se aproxima de 100%. A intuição: quando o servidor está a 50%, uma requisição que chega quase sempre encontra o servidor livre e é atendida na hora. Quando está a 95%, quase toda requisição chega e encontra fila, e como as chegadas são aleatórias, os momentos de aperto se empilham. Os últimos pontos percentuais de utilização são pagos com latência desproporcional. É por isso que "100% de uso" é um péssimo alvo: muito antes dos 100%, o sistema já está inutilizável do ponto de vista do usuário.

Daí a utilização-alvo: o ponto de operação que você escolhe deixar como teto normal, tipicamente entre 50% e 70% para o recurso gargalo em serviços sensíveis a latência. Não porque os 30-50% restantes são desperdício, mas porque são o headroom que segura a curva de fila longe do precipício e absorve rajadas, falhas e erro de previsão. Sistemas de batch, que só se importam com throughput e não com latência de cauda, podem viver felizes a 90% — a fila cresce, mas ninguém está esperando do outro lado. A utilização-alvo é uma decisão de produto, não uma constante universal.

Isso fecha a fórmula de dimensionamento. Para um serviço:

`` réplicas = RPS_de_pico / (throughput_por_réplica × utilização_alvo) ``

Se o pico previsto é 8.000 RPS, cada réplica aguenta 500 RPS no limite, e a utilização-alvo é 60%, então: 8000 / (500 × 0,6) = 8000 / 300 ≈ 27 réplicas. Repare que dividir pela utilização-alvo é o que embute o headroom na conta — sem esse fator, você chegaria a 16 réplicas e estaria dimensionando para rodar no vermelho.

Planejamento para eventos previsíveis#

Crescimento orgânico é uma ladeira; um evento é um degrau. Black Friday, lançamento de produto, campanha com influenciador, migração de uma base grande — são picos com data marcada, e picos com data marcada não têm desculpa para pegar ninguém desprevenido.

O método é direto:

1. Extrapole a demanda. Pegue a linha de base atual e aplique o multiplicador esperado do evento. Na Black Friday passada o tráfego foi 6× o de um dia normal? Comece por aí, some a tendência de crescimento do ano, e arredonde para cima. Errar para mais custa uma fatura maior por alguns dias; errar para menos custa a receita do evento inteiro.

1. Teste o plano com load test. Um número numa planilha é uma hipótese, não um fato. Gere carga sintética até o alvo extrapolado e observe onde o sistema quebra primeiro. Quase sempre o gargalo real não é onde você apostava — é uma conexão de banco, um lock, um serviço interno esquecido. O load test transforma o plano de teoria em evidência, e é a única etapa que descobre o gargalo que a modelagem no papel não viu.

1. Prepare os kill switches. Nem todo recurso precisa sobreviver ao pico. Feature secundária que consome banco caro pode ser degradada de propósito durante o evento. Ter o botão de desligar mapeado e testado antes é a diferença entre sacrificar uma funcionalidade e perder o sistema inteiro. Degradação graciosa é uma decisão de capacidade tanto quanto adicionar máquina.

1. Provisione antes, não durante. Como vimos, escalar reativo chega atrasado num degrau. Para eventos, pré-aqueça a frota: suba a capacidade planejada antes da porta abrir, com as instâncias já bootadas e o cache já quente. O autoscaling cuida da flutuação em cima dessa base, não da subida inicial.

As duas pontes: autoscaling e custo#

Dois assuntos vizinhos vivem sendo confundidos com capacity planning. Vale marcar a fronteira sem invadir o terreno de cada um.

Autoscaling reage; capacity planning antecipa. O autoscaling é o mecanismo que ajusta a capacidade em resposta à demanda observada, minuto a minuto, dentro de limites. Capacity planning é quem define esses limites: o piso (que segura o cold start e garante base pré-aquecida), o teto (que respeita quota e orçamento), e o alvo em torno do qual o mecanismo oscila. Autoscaling sem capacity planning é um termostato sem ninguém ter decidido a temperatura — ele reage a um alvo que ninguém pensou. Os dois trabalham juntos: o planejamento desenha o envelope, o autoscaling se move dentro dele.

Capacidade ociosa custa. Todo aquele headroom que separa você do precipício é infraestrutura ligada que você paga esteja ou não em uso. Aqui capacity planning encosta em FinOps: a utilização-alvo é, no fundo, uma negociação entre risco de latência e custo de folga. Alvo baixo demais é dinheiro dormindo; alvo alto demais é incidente esperando. O ponto certo é uma decisão de negócio informada por engenharia — e é por isso que a conta de capacidade e a conta de custo são lidas na mesma mesa, ainda que sejam disciplinas distintas.

As armadilhas que derrubam o plano#

Cinco erros aparecem repetidamente, e todos têm o mesmo sabor: usar um número confortável no lugar do número verdadeiro.

• Planejar pela média, não pelo pico. O erro-mãe. A média é um número tranquilizador e inútil para dimensionamento. O sistema morre no pico, e o pico não é a média — pode ser três, cinco, dez vezes maior. Dimensione contra o percentil alto da demanda de pico, sempre.
• Ignorar o recurso gargalo. Adicionar réplicas de aplicação num sistema limitado por conexões de banco. Turbinar CPU num serviço preso em IOPS. Escalar a dimensão errada gasta dinheiro e não move o teto real. Ache o gargalo primeiro; só ele conta.
• Esquecer as dependências. O plano cobre seu serviço e ignora o banco compartilhado, a API de terceiro com rate limit, o serviço interno que não vai escalar junto. O elo que não escala é onde a corrente arrebenta, e ele quase nunca é o elo que você estava olhando.
• Não testar o plano. Capacidade calculada e nunca exercitada é ficção com aparência de fato. Sem load test, o primeiro teste de carga real é a produção durante o pico — e a produção é um lugar caro para descobrir que a conta estava errada.
• A planilha que ninguém atualiza. O plano feito uma vez e esquecido apodrece silenciosamente. O tráfego cresceu, o serviço ficou mais pesado, uma dependência nova entrou — e a planilha ainda descreve o sistema de seis meses atrás. Capacity planning é um processo vivo, revisitado a cada ciclo, não um documento que se arquiva.

Fechando a conta#

Capacity planning não é adivinhação nem burocracia; é a prática de olhar o pico de frente antes de ele chegar. Meça a demanda pelo percentil que dói e não pela média que consola. Separe a curva em sazonalidade e tendência. Modele cada recurso — CPU, memória, IO, rede, conexões, terceiros — e persiga o gargalo, porque é ele quem define seu teto. Escolha uma utilização-alvo que respeite a física da fila e deixe headroom de verdade entre a operação e o precipício. Prove o plano com load test antes que a Black Friday o prove por você. E revise a conta antes que ela envelheça.

A nuvem elástica é uma alavanca extraordinária. Mas alavanca precisa de alguém que saiba onde apoiar e quanta força aplicar. Esse alguém é o capacity planning — e quando ele faz o trabalho direito, o pico chega, passa, e ninguém sequer percebe que houve pico. Que é, no fim, o maior elogio que uma operação de infraestrutura pode receber.