Planejamento de Capacidade

O negócio faz uma pergunta simples: "Podemos abrir a venda do show no estádio em 14 de março às 10:00?" Por trás dela há perguntas de engenharia com respostas numéricas: quantas réplicas de cada serviço, que tamanho de banco, quantas conexões, que taxa de admissão para a sala de espera, com quanta antecedência escalar — e quanto custa. O planejamento de capacidade² transforma as medições das páginas anteriores nesses números, com margem suficiente para sobreviver ao que você não previu.

De medições a réplicas

Planejamento de capacidade é aritmética sobre três entradas que você já sabe obter:

1. Demanda — a taxa de chegada de pico por endpoint, do modelo de carga (previsão × fator de segurança).
2. Capacidade por unidade — o joelho de um pod (ou de um banco), de um teste breakpoint: a maior taxa em que ele ainda cumpre o SLO.
3. Folga (headroom) — quão abaixo do joelho você quer operar, e a quais falhas precisa sobreviver.

A Lei de Little dimensiona tudo o que segura uma requisição

Réplicas não são o único recurso. Todo componente que segura uma requisição enquanto ela está em andamento — threads, conexões, sockets, VUs, posições de fila — precisa ser dimensionado para a concorrência, e a Lei de Little a dá diretamente: concorrência = taxa de chegada × tempo em que é segurada¹.

Um modelo de capacidade para a venda

O modelo abaixo combina as taxas de pico do modelo de carga com os joelhos por pod medidos em testes breakpoint (todos os valores são premissas ilustrativas — troque-os pelas suas medições). Ele planeja operar no máximo a 75 % do joelho e espalha as réplicas por três zonas de disponibilidade, para que a perda de uma zona ainda deixe capacidade suficiente:

O que o modelo diz:

• A sala de espera economiza capacidade onde ela é mais cara. Limitar as reservas admitidas a 3 000/s (abaixo do joelho do banco) corta cerca de um terço das réplicas de inventory e order — e, mais importante, mantém limitada a carga sobre o único banco primário.
• Resiliência a zonas custa 50 % mais réplicas no pico. Esse é o preço de "uma queda de zona às 10:01 não para a venda". Pode valer a pena no dia da venda e não em uma terça-feira — os limites do autoscaling podem variar por dia.
• O número de conexões é um sinal de alerta. Perto de mil conexões de clientes não podem ir direto ao PostgreSQL; o PgBouncer (transaction pooling) as multiplexa em algumas dezenas de conexões de servidor — o número que a Lei de Little de fato exige.
• Pods viram nós, que viram dólares. Cerca de cem pods no pico é aproximadamente o "+24 nós por 2 horas" do modelo de custo de FinOps.

Folga: por que não operar a 100 % do joelho?

Metas típicas operam os serviços entre 50 e 75 % do joelho no pico esperado; o número certo depende de quão rápido você consegue adicionar capacidade e de quão caro é violar o SLO. Para a venda do BoxOffice — que dura minutos, é muito visível e não pode ser repetida —, uma folga generosa é um seguro barato.

Atraso do autoscaling: os minutos que importam

O autoscaling reage à demanda; ele não a antecipa. Uma linha do tempo aproximada para um serviço JVM no Kubernetes quando o pico começa:

Durante essa janela, o backlog cresce na diferença entre demanda e capacidade. Se as reservas saltam de 500/s para 4 500/s enquanto o deployment consegue atender 1 100/s por dois minutos, o backlog é \((4\,500 - 1\,100) \times 120 \approx 408\,000\) requisições — muito além de qualquer timeout. Elas viram erros, os retries pioram tudo, e os fãs que chegaram primeiro têm a pior experiência. Daí as regras para picos conhecidos:

• Pré-escale antes do evento (um aumento agendado às 09:45; o scaler de cron do KEDA; minReplicas elevado) e mantenha capacidade livre nos nós.
• Controle de admissão (sala de espera, rate limiting), para que a demanda excedente espere fora do sistema, em ordem, em vez de expirar dentro dele³.
• Aqueça a nova capacidade: caches pré-carregados com o evento, pools de conexão cheios (minimum-idle = maximum-pool-size), uma requisição de aquecimento a cada pod novo antes de ele ficar pronto.

Plataformas serverless encurtam o atraso, mas não o eliminam: novas instâncias de função têm cold starts, e os provedores limitam quão rápido a concorrência pode crescer e quanta concorrência uma conta pode usar (verifique as cotas atuais do seu provedor).

Experimente: o cenário abaixo envia uma rajada a um componente serverless. Rode-o com as configurações padrão e observe a latência de cold start no início da rajada e as requisições estranguladas (rejeitadas) quando o limite de concorrência é atingido. Depois aumente o limite ou adicione concorrência provisionada (pré-aquecida) e compare os primeiros segundos da rajada — a versão serverless da pré-escala.

Previsão e a revisão de capacidade

Planejamento de capacidade não se faz uma vez só. Um processo simples e sustentável:

• Preveja a demanda a partir do histórico: tendência (crescimento por mês), sazonalidade (fins de semana, feriados) e eventos (vendas são anunciadas com antecedência — use o calendário, não só a tendência).
• Meça de novo a capacidade por unidade depois de cada mudança significativa; uma nova funcionalidade pode mover o joelho mais do que qualquer mudança de infraestrutura. O orçamento de desempenho na CI (abaixo) pega a maioria das regressões antes que cheguem à produção.
• Revise mensalmente: utilização de pico vs plano, folga restante, custo por unidade de demanda, eventos futuros. Capacidade, SLOs e custo pertencem à mesma reunião.
• Prefira elasticidade a precisão: um sistema que escala em um minuto precisa de uma previsão menos precisa do que um que precisa de uma semana para comprar hardware.

Orçamentos de desempenho na CI

Uma regressão de desempenho que chega à produção é descoberta pelos fãs. Um orçamento de desempenho (performance budget) é um limite — por endpoint, por página, por build — que o pipeline impõe a cada mudança, da mesma forma que os testes impõem a correção⁴. Orçamentos úteis misturam medidas ruidosas e determinísticas:

O orçamento do k6 é um teste curto, de modelo aberto, contra uma stack parecida com a produção iniciada dentro do job. Não é um teste de capacidade — runners de CI são pequenos e ruidosos —, mas pega com confiabilidade as grandes regressões: um índice ausente, um N+1, uma chamada síncrona adicionada ao caminho quente.

import { textSummary } from 'https://jslib.k6.io/k6-summary/0.0.2/index.js';
import { browse, hold } from './lib/boxoffice.js';
export { browse, hold };

export const options = {
  scenarios: {
    browse: { executor: 'constant-arrival-rate', exec: 'browse', rate: 100, timeUnit: '1s',
              duration: '3m', preAllocatedVUs: 50, maxVUs: 200 },
    hold:   { executor: 'constant-arrival-rate', exec: 'hold', rate: 20, timeUnit: '1s',
              duration: '3m', preAllocatedVUs: 100, maxVUs: 300 },
  },
  thresholds: {
    'http_req_duration{name:GET /events/{id}}': ['p(95)<80'],
    'http_req_duration{name:POST /holds}':      ['p(95)<150'],
    http_req_failed: ['rate<0.001'],
    dropped_iterations: ['count==0'],
  },
};

export function handleSummary(data) {
  return {
    stdout: textSummary(data, { indent: ' ', enableColors: false }),
    'results/summary.json': JSON.stringify(data),
  };
}

name: perf-budget
on:
  pull_request:
  push: { branches: [ main ] }        # main's runs become the baseline

jobs:
  k6:
    runs-on: ubuntu-latest
    permissions: { contents: read, actions: read }
    steps:
      - uses: actions/checkout@v4
      - name: Start BoxOffice with production-like settings
        run: docker compose -f compose.yaml -f compose.perf.yaml up -d --build --wait
      - name: Seed a 60 000-seat event
        run: docker compose exec -T db psql -U postgres -d boxoffice -f /seed/onsale.sql
      - uses: grafana/setup-k6-action@v1
      - name: Warm up (not measured)
        run: k6 run --quiet -e BASE_URL=http://localhost:8080 --vus 5 --duration 30s k6/smoke.js
      - name: Performance budget (fails on threshold breach)
        run: mkdir -p results && k6 run -e BASE_URL=http://localhost:8080 k6/budget.js
      - name: Compare with the latest baseline from main
        if: github.event_name == 'pull_request'
        env: { GH_TOKEN: "${{ github.token }}" }
        run: |
          id=$(gh run list --workflow perf-budget --branch main --status success --limit 1 \
                 --json databaseId -q '.[0].databaseId')
          gh run download "$id" --name k6-summary --dir baseline || echo "no baseline yet"
          python3 k6/compare.py results/summary.json baseline/summary.json --max-regression 0.15
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: k6-summary, path: results/summary.json }

import argparse
import json
import os
import sys

parser = argparse.ArgumentParser(description="Compare k6 p95 per endpoint with a baseline")
parser.add_argument("current")
parser.add_argument("baseline")
parser.add_argument("--max-regression", type=float, default=0.15)
args = parser.parse_args()


def p95_by_endpoint(path):
    metrics = json.load(open(path))["metrics"]
    return {name: m["values"]["p(95)"] for name, m in metrics.items()
            if name.startswith("http_req_duration{name:")}


current = p95_by_endpoint(args.current)
baseline = p95_by_endpoint(args.baseline) if os.path.exists(args.baseline) else {}
failed = False
for name, value in sorted(current.items()):
    ref = baseline.get(name)
    if ref is None:
        print(f"{name}: {value:.1f} ms (no baseline)")
        continue
    change = (value - ref) / ref
    regression = change > args.max_regression
    failed |= regression
    print(f"{name}: {ref:.1f} -> {value:.1f} ms ({change:+.0%}){'  REGRESSION' if regression else ''}")
sys.exit(1 if failed else 0)

Dois gates protegem o orçamento: os thresholds absolutos em budget.js (derivados dos SLOs, com margem para o runner pequeno) e a comparação relativa com a main (uma desaceleração de 15 % falha mesmo que o threshold absoluto ainda passe). Para manter o gate confiável em vez de ignorado:

• Combata o ruído: taxa de chegada fixa, passo de aquecimento, o mesmo tipo de runner, e uma repetição automática antes de falhar; um runner self-hosted dedicado reduz ainda mais a variância.
• Prefira orçamentos determinísticos quando possível: uma asserção de contagem de consultas em um teste de integração nunca é instável e pega a regressão mais comum (N+1).
• Torne as falhas acionáveis: publique o resumo, aponte o trace da requisição mais lenta e diga qual endpoint regrediu e quanto.
• Rode a campanha completa em outro lugar: o gate do PR é um alarme de fumaça; os testes load, spike e breakpoint rodam todas as noites ou antes de grandes eventos no ambiente de desempenho.

export const options = {
  scenarios: {
    warmup: { // JIT, connection pools and cache: not measured
      executor: 'constant-arrival-rate',
      rate: 20,
      timeUnit: '1s',
      duration: '20s',
      preAllocatedVUs: 20,
    },
    budget: { // the measured part: an open-model load the service must sustain
      executor: 'constant-arrival-rate',
      startTime: '20s',
      rate: Number(__ENV.RATE || 50),
      timeUnit: '1s',
      duration: '40s',
      preAllocatedVUs: 50,
      maxVUs: 200,
    },
  },
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    'http_req_duration{scenario:budget}': ['p(95)<300', 'p(99)<800'],
    'http_req_failed{scenario:budget}': ['rate<0.01'],
    'checks{scenario:budget}': ['rate>0.99'],
  },
};

performance:
  name: performance budget
  needs: test
  runs-on: ubuntu-latest
  timeout-minutes: 20
  steps:
    - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
    - name: Start PostgreSQL, Redis and catalog
      run: docker compose -f .github/ci/compose.perf.yaml up -d --build --wait --wait-timeout 300
    - uses: grafana/setup-k6-action@43b9fc21641a76002687994433dd586f56e791b1 # v1.2.2
      with:
        k6-version: "1.8.2"
    - name: k6 budget (fails the job when a threshold is crossed)
      uses: grafana/run-k6-action@4082a08c7e40cf6d65863911077dfb60ae0a4f04 # v1.5.0
      env:
        BASE_URL: http://localhost:8082
      with:
        path: load/budget.js

Como se conecta

flowchart LR
    KNEE["measured knee per pod<br/>← Load testing"] --> REP["replicas = peak ÷<br/>(knee × target utilization)"]
    LL["Little's Law<br/>N = X × R"] --> CONN["threads, connections,<br/>PgBouncer"]
    REP --> HEAD["headroom:<br/>zone loss, 75 % of the knee"]
    HEAD --> LAG["autoscaling lag, cold starts<br/>→ pre-scale before 10:00"]
    LAG --> WR["waiting room admits what<br/>the database can take"]
    REP --> COST["pods → nodes → dollars<br/>→ Cloud-native FinOps"]
    FC["forecast and<br/>capacity review"] --> REP
    BUD["performance budget in CI<br/>guards the knee"] --> KNEE

Componentes da paleta: app (réplicas por serviço) · sql (conexões e o limite do primário) · queue (a taxa de admissão da sala de espera) · serverless (cold starts e limites de concorrência) · metrics (utilização, o sinal do autoscaler). Cenários: serverless-burst, scale-out, flash-sale. Continua em: Estimativas — filas, Compute — serverless e autoscaling, Cloud-native — Kubernetes, Cloud-native — FinOps, Estudo de caso — ingressos.