Pular para o conteúdo

Planejamento de capacidade

Avançado16 min de leiturasre

Planejar capacidade é responder a duas perguntas com números: quanta carga vem e quanta carga o sistema aguenta. Sem a primeira, você dimensiona pelo susto; sem a segunda, descobre o limite durante a Black Friday.

Comece pela métrica de negócio, não pela de infraestrutura: pedidos por minuto, sessões simultâneas, mensagens na fila. Ela é o que produto consegue prever e o que se converte em CPU depois.

# pico diário das últimas semanas — a base da projeção
max_over_time(sum(rate(http_requests_total[5m]))[1d:5m])
# crescimento: compare a semana atual com a de quatro semanas atrás
sum(rate(http_requests_total[1w])) / sum(rate(http_requests_total[1w] offset 4w))

Some três componentes: tendência (crescimento orgânico), sazonalidade (hora do dia, dia da semana, fim de mês) e eventos (campanha, Black Friday, integração de cliente grande). O terceiro não sai de gráfico nenhum — sai de conversa com marketing e vendas, e é o que mais surpreende.

Planeje para o pico, não para a média. Um sistema dimensionado pela média fica indisponível todo dia às 20h.

Utilização e saturação não são a mesma coisa. Fila crescendo, tempo de espera por conexão e throttling de CPU dizem que o recurso saturou — mesmo com utilização em 60%.

# throttling de CPU: o container está sendo freado, mesmo sem "CPU alta"
sum by (pod) (rate(container_cpu_cfs_throttled_seconds_total{namespace="loja"}[5m]))

Sistemas com fila degradam de forma não linear: a latência sobe devagar até uns 70% de utilização e explode depois. Por isso a folga usual é operar o pico planejado em torno de 60% a 70% do que o sistema aguenta — a folga cobre a falha de uma zona, o pico não previsto e o tempo que o autoscaling leva para reagir.

Calcule o N-1: se uma zona ou um nó grande cair no pico, o que sobra atende? Se a resposta for não, sua capacidade é teórica.

São experimentos diferentes e ambos são necessários:

  • Carga: sustentar o pico esperado e verificar se latência e erro ficam dentro do SLO.
  • Estresse: subir até quebrar, para conhecer o ponto de saturação e como o sistema quebra — degrada, derruba tudo, ou corrompe.
// k6 — degraus até o pico esperado, com limites ligados ao SLO
export const options = {
stages: [
{ duration: '5m', target: 200 }, // aquecimento
{ duration: '10m', target: 1200 }, // pico esperado da campanha
{ duration: '10m', target: 1200 }, // sustentação: é aqui que vazamento aparece
{ duration: '5m', target: 0 },
],
thresholds: {
http_req_failed: ['rate<0.01'],
http_req_duration: ['p(95)<800'],
},
};

Teste que só sobe e desce em cinco minutos não encontra vazamento de memória, esgotamento de pool nem enchimento de disco. Sustente a carga. E teste em ambiente com a mesma topologia de produção — tamanho pode ser menor, mas número de camadas, banco e limites precisam ser equivalentes, ou o resultado engana.

Cuidado com o que o teste não vê: dependência de terceiro com limite de taxa, cache quente que produção não teria, e dados sintéticos pequenos demais para a consulta real.

Escala automática resolve variação dentro de uma faixa já provisionada. Ela não resolve:

  • Tempo de reação. Provisionar nó, baixar imagem e passar o readiness leva minutos; um pico de trinta segundos acontece inteiro antes disso. Para eventos com hora marcada, aqueça antes.
  • Teto de cota. Cota de vCPU na nuvem, IPs na subnet e conexões máximas do banco não escalam com o maxReplicas.
  • Gargalo que não escala horizontalmente. Banco primário, licença por instância e serviço de terceiro continuam sendo o limite.

Antes de campanha, faça a lista dos limites que não escalam sozinhos e peça aumento de cota com antecedência — aprovação de cota costuma levar dias.

Capacidade é uma decisão econômica: folga custa dinheiro, falta custa receita e confiança. Torne a conta explícita — quanto custa manter 30% de folga por mês contra quanto custa uma hora fora do ar no pico. Com o número na mesa, a conversa com finanças deixa de ser sobre opinião.

Depois do evento, compare o previsto com o realizado e ajuste o modelo. Planejamento de capacidade é um ciclo trimestral, não um documento.

Próximo passo: valide na prática as suposições que você acabou de fazer em Engenharia do caos.