Filas, Lei de Little e Escalabilidade

O banco de inventário da BoxOffice está a 70% de CPU durante uma abertura de vendas normal, e as reservas levam cerca de 75 ms no p99. A equipe conclui que tem "30% de sobra". Na abertura de vendas seguinte, maior, a CPU chega a 92% — só 22 pontos a mais — e o p99 salta para quase 300 ms, quatro vezes pior e bem na meta de 300 ms da reserva. Timeouts disparam, os clientes tentam de novo e a carga extra leva o banco a 100%. Nada estava "quebrado"; a equipe simplesmente não conhecia a forma da curva que relaciona carga e latência. Esta página deduz essa curva de algumas leis simples e depois usa as mesmas leis para responder às perguntas que toda decisão de capacidade faz: quantas requisições estão em andamento? que tamanho este pool precisa ter? quão cheio este componente pode rodar? acrescentar nós vai ajudar?

O vocabulário de uma fila

Todo componente que atende requisições — um núcleo de CPU, um pool de threads, uma conexão de banco, uma API de pagamentos — pode ser visto como uma fila diante de um ou mais servidores (em teoria de filas, "servidor" é qualquer coisa que atende uma requisição):

flowchart LR
    arrivals(["Chegadas<br/>λ requisições/s"]) --> queue["Fila<br/>(espera: Wq)"]
    queue --> s1["Servidor 1<br/>(serviço: S)"]
    queue --> s2["Servidor 2"]
    queue --> s3["Servidor c"]
    s1 --> out(["Conclusões<br/>X requisições/s"])
    s2 --> out
    s3 --> out

A Lei de Little

A fórmula mais útil do planejamento de capacidade é também a mais simples¹:

O número médio de requisições num sistema é igual à taxa média de chegada vezes o tempo médio que cada requisição passa no sistema. Ela vale para qualquer sistema estável (as chegadas não excedem a capacidade no longo prazo), independentemente da distribuição das chegadas ou dos tempos de serviço, do número de servidores ou da ordem de atendimento. Você pode aplicá-la a um pool de threads, a um serviço inteiro, a uma fila, a um banco — ou a uma cafeteria: se chegam 2 clientes por minuto e cada um fica 15 minutos, há em média 30 clientes lá dentro.

Suas três formas respondem a três perguntas diferentes:

A Lei de Little como detector de mentiras para testes de carga

Uma ferramenta de teste de carga com um número fixo de usuários virtuais (VUs), em que cada um envia uma requisição, espera a resposta, "pensa" por Z segundos e repete, é um sistema fechado. A Lei de Little aplicada a ela diz:

Com 100 VUs, sem tempo de pensar (Z = 0) e R = 50 ms, o teste não consegue produzir mais que 100 / 0,05 = 2.000 req/s, seja lá o que o servidor aguentasse. Se o servidor ficar lento, R = 500 ms, o teste gera só 200 req/s — a carga cai exatamente quando o sistema sofre, escondendo o problema. Confira todo resultado de teste de carga com essa fórmula; o laboratório 2 faz isso, e a aula 15 discute modelos de carga aberto e fechado.

A lei da utilização

Uma segunda lei, igualmente simples, liga throughput e utilização:

A utilização de um recurso é igual ao seu throughput vezes o tempo de serviço por requisição. Um banco que atende 1.000 reservas/s a 5 ms de CPU cada precisa de 5 segundos de CPU por segundo: 5 núcleos a 100%, ou 62,5% de 8 núcleos. Invertida, ela dá a capacidade de um recurso: a utilização não pode passar de 100% por servidor, então

Essa é a regra "vagas paralelas divididas pelo tempo de serviço" usada na visão geral. O recurso com a maior utilização (a maior razão entre demanda e capacidade) é o gargalo: ele satura primeiro e limita o throughput do sistema inteiro.

Por que a latência explode antes de 100%: o joelho

Se as requisições chegassem em intervalos perfeitamente regulares e cada uma levasse exatamente S, um servidor poderia rodar a 99% de utilização sem nenhuma espera. O tráfego real é aleatório: as requisições chegam em rajadas, e algumas demoram mais que outras. Durante uma rajada, as requisições fazem fila; a fila esvazia nos momentos tranquilos. Quanto mais ocupado o servidor, menos momentos tranquilos ele tem para se recuperar — e mais as filas crescem.

O modelo mais simples disso é a fila M/M/1: chegadas aleatórias (Poisson), tempos de serviço aleatórios (exponenciais), um servidor. Seu tempo médio de resposta é²:

(Na M/M/1 o tempo de resposta tem distribuição exponencial, então seu p99 é ln(100) ≈ 4,6 vezes a média.) Ir de 50% para 90% de utilização — menos que o dobro da carga — deixa o tempo de resposta 5× pior; de 90% para 99% — 10% a mais de carga — mais 10× pior. É exatamente a história do inventário da BoxOffice no início desta página.

O gráfico mostra R / S em função da utilização para um servidor (M/M/1, média e p99), e para 4 e 16 servidores compartilhando uma única fila (M/M/c, calculado com a fórmula Erlang C):

Três lições das curvas:

1. O joelho (knee). A latência é quase plana em baixa utilização e depois se curva bruscamente. Para um único servidor, a curva fica em torno de 70–80%; depois dela, pequenos aumentos de carga causam enormes aumentos de latência, e a cauda (p99) explode primeiro.
2. Compartilhar a fila ajuda. Com 16 servidores compartilhando uma fila, o joelho se desloca bem para a direita: uma requisição só espera se todos os servidores estiverem ocupados. Esse é um dos motivos pelos quais um grande pool atrás de um load balancer se comporta melhor que muitas filas pequenas e separadas (por exemplo, roteamento fixo de usuários para servidores específicos).
3. A variabilidade é a inimiga. O modelo M/M/1 supõe chegadas e tempos de serviço muito aleatórios. Tráfego mais regular forma menos fila; tráfego em rajadas (uma abertura de vendas!) forma mais. A aproximação de Kingman para um único servidor deixa isso explícito³:

em que \(C_a\) e \(C_s\) são os coeficientes de variação (desvio padrão / média) dos intervalos entre chegadas e dos tempos de serviço. O primeiro fator é o efeito da utilização; o segundo, o efeito da variabilidade. Uma sala de espera que admite fãs a uma taxa constante reduz \(C_a\); cortar os casos lentos (uma consulta pesada que leva 50× o tempo normal) reduz \(C_s\). Os dois reduzem as filas sem acrescentar um único servidor.

Com que utilização você deve rodar?

A redundância empurra na mesma direção: com 4 réplicas a 60%, perder uma leva as outras três a 80% — ainda atendendo. Com 4 réplicas a 80%, perder uma exige 107%: as réplicas restantes colapsam. A folga é o que faz o failover funcionar.

Experimente: rode o perfil breakpoint, depois dobre a capacidade do banco (ou acrescente réplicas da aplicação) e rode de novo. O joelho se move? Quanto? Se acrescentar réplicas da aplicação não o move, qual componente é o gargalo?

#!/usr/bin/env bash
# Lab 2: run load.js once per arrival rate and save one k6 summary per run.
#   bash scripts/sweep.sh 25 50 100 150 200 300 400
# Then:  uv run scripts/summarize.py results/lab2/rate-*.json
set -euo pipefail
OUT=${OUT:-results/lab2}
DURATION=${DURATION:-1m}
mkdir -p "$OUT"
echo ">>> warm-up: 30 s at RATE=$1 (not recorded)"
k6 run -q -e RATE="$1" -e DURATION=30s load/load.js > /dev/null || true
for rate in "$@"; do
  echo ">>> RATE=$rate req/s for $DURATION"
  # || true: a run that crosses a threshold still produces a summary; keep sweeping
  k6 run -q -e RATE="$rate" -e DURATION="$DURATION" \
     --summary-export "$OUT/rate-$rate.json" load/load.js > /dev/null || true
  sleep 10   # let queues drain before the next step
done

Quando mais servidores deixam de ajudar

A Lei de Little e a lei da utilização sugerem que a capacidade cresce linearmente com o número de servidores: X_max = c / S. Na prática não cresce, porque os servidores se coordenam. Dois modelos clássicos descrevem como a escala se curva.

A lei de Amdahl

Se uma fração σ do trabalho é inerentemente serial (não pode ser paralelizada — um lock global, um único primário, uma etapa sequencial), então com N workers paralelos o ganho de velocidade (speedup) é limitado⁴:

Com 5% de trabalho serial, nenhum número de nós dá mais que 20× de ganho; com 1%, 100×. Na BoxOffice: se toda reserva precisa passar pelo mesmo lock na mesma linha de "contador do setor" durante apenas 5% do seu tempo, acrescentar réplicas do inventário deixa de compensar muito antes de 20 réplicas.

A Universal Scalability Law

A Universal Scalability Law (USL) de Neil Gunther acrescenta um segundo termo, κ (coerência), para o custo de manter os nós consistentes entre si — mensagens de invalidação de cache, locks distribuídos, conversa de pertencimento ao cluster, replicação —, que cresce com o número de pares de nós, aproximadamente N²⁵:

Com κ > 0, o throughput não apenas se achata — ele atinge um pico em \(N^* = \sqrt{(1 - \sigma)/\kappa}\) e depois diminui: acrescentar nós deixa o sistema mais lento.

O uso prático da USL é ajustar σ e κ a algumas medições de teste de carga (throughput com N = 1, 2, 4, 8…) e prever onde a escala para antes de comprar o hardware (aula 15). A lição de design é mais ampla: designs shared-nothing escalam. Particione o trabalho para que os nós não precisem conversar entre si — a BoxOffice particiona o inventário por evento, de modo que reservas de eventos diferentes nunca disputam recursos — e tanto σ quanto κ diminuem.

Como se conecta

flowchart LR
    LL["Lei de Little<br/>L = λ × W"] --> POOL["pools de threads e conexões<br/>→ Compute, Bancos de dados"]
    LL --> WR["espera na sala de espera<br/>W = L / λ → Mensageria"]
    LL --> LT["detector de mentiras do teste de carga<br/>→ Performance"]
    UL["lei da utilização<br/>U = X × S"] --> CAP["capacidade ≈ c / S"]
    CAP --> KNEE["o joelho<br/>R = S / (1 − ρ)"]
    KNEE --> TARGET["operar a 50–70%<br/>metas de autoscaling → Compute"]
    KNEE --> SHED["descarte de carga, backpressure<br/>→ Confiabilidade"]
    AMD["Amdahl σ<br/>linhas quentes, locks globais"] --> PART["particionamento shared-nothing<br/>→ Bancos de dados"]
    USL["USL κ<br/>custo de coerência"] --> PART

Componentes da paleta: app (threads de trabalho = λ × W por réplica) · sql (o pool de conexões, o primário que está "só" a 70%, contenção por locks de linha) · queue (a sala de espera: quanto o último fã espera) · worker (workers de lote podem operar a 80–90%) · payment (um provedor lento multiplica as chamadas em andamento) · nosql (partições shared-nothing escalam onde a USL diz que um primário compartilhado não escala). Cenários: monolith (com o perfil breakpoint), flash-sale, async-queue. Continua em: Percentis, Compute — atraso do autoscaling, Confiabilidade — descarte de carga, Bancos de dados — contenção, Performance — planejamento de capacidade, Hands-on 2.

Pontos-chave