Planejamento de potência e aumento da carga

Resumo curto

1. Previsão de demanda (tendência básica + sazonalidade + iventa).

2. Modelo de carga (open-model para a Internet).

3. Reserva de resistência (headroom) e orçamento errado.

4. Zoom (horizonte/vertical/auto) + limitadores (rate-limit/backpressure).

5. Finanças: $/1000 RPS, $/ms p95, TCO em cenários.

Termos e métricas

Throghput: RPS/QPS/CPS - largura de banda real.
Latency p95/p99: SLO de destino para caminhos personalizados.
Saturation: carregar CPU/memória/IO/FD/conexões/filas.
Error rate: 5xx/timeout/429, orçamento errado para o período.
Headroom: proporção de potência livre no pico de tráfego (recomendado ≥ 30%).
Burst: alta de curto prazo (segundos/minutos), Spike: crescimento acentuado x N.

Modelos e fórmulas básicos

Little's Law (para sistemas com filas)

L = λ W

L é o número médio de solicitações no sistema, £ é a intensidade média de entrada (RPS), W é o tempo médio do sistema. Útil para estimar a profundidade das filas.

Taxa de download ( )

ρ = λ / μ

Velocidade de serviço (RPS a 100% CPU). A latência aumenta de forma não linear - mantenha o ponto de trabalho 0. 6–0. 75.

Safety factor/reserva

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Onde o Degradation _ fator leva em conta a falha N, a degradação do cachê, a perda de um RR/região (por exemplo, 1. 2).

Previsão de demanda

1. Histórico: perfis diurnos/semanais, sazonalidade, correlação com eventos (jogos/striptease/pagamentos).
2. Ivents: coeficientes cenários (dia normal x 1, torneio x 2. 3, final x 3. 5).
3. Fontes de flutuações, campanhas de marketing, lançamentos, anomalias de bots.

4. Unidades de previsão: RPS sobre rotas (login, lobby, catalog, payments), CPS TLS, QPS DB, IOPS disco, egress Gbps

5. Confiança: Guarde dois cenários: conservador e agressivo.

Simulação de carga

Open-model (Poisson-semelhante): plausível para API/website público - use para sizing.
Modelo Closed (VU + think-time): adequado para sequências internas; combinar.
Misturas de rotas: participações de peso sobre os endpoentos; inclua não apenas «quentes», mas também «caros» (registro, depósito).
Não esqueçam: Retrações, filas, limites de parceiros (PSP, API de terceiros).

Projetar reserva de resistência

Headroom alvo: ≥ 30% para o pico (para a internet); para o núcleo de pagamento e caminhos críticos, entre 40% e 50%.
N + 1/N + 2: Aguentamos a rejeição de 1-2 instâncias/zona sem violação do SLO.
Multi-region: cada região puxa ≥ 60% do pico total (para sobreviver à perda do vizinho).
Modo Degrade: desativando funções secundárias, reduzindo payload, ativando o cachê/respostas.

Sizing por camadas

Rede/Edge

CPS/RPS na frente, TLS-handshake p95, resumption≥70%, egress Gbps

Anycast/Geo-roting, limites CDN/WAF (pré-concordar).
Reserva: link/aplink ≥ pico x 1. 3, SYN backlog com reserva, UDP/443 para H3.

Balanceadores/Proxy

RPS para instância, abertura de conexões, filas, CPU/IRQ.
Keepalive e conexion pooling - reduzem as conexões de backends.
Reserva: ≤ 0. 7, limiter по CPS/RPS per route.

Aplicativos

Desempenho por núcleo (RPS/core) na plataforma.
Poulas (thread/DB/HTTP) - Não acerte limites.
Reserva: scale automático para CPU 60-70% e latency-trigger (p95).

Cash

Hit-ratio, volume de hotset, evition, réplica.
Reserva, memória ≥ 1. 2 x hotset, headroom de rede ≥ 30%.

Bancos de dados

QPS/TPM, p95 solicitações, bloqueios, kesh tampão, WAL/replicação lag.
IOPS e latency disco são a chave do p95.
Reserva: Ponto de trabalho CPU 50-65%, barra de réplica <alvo; plano de charding e read-replicas.

Discos/Armazenamento

IOPS (4k/64k), throughput, fsync cost.
Reserva: IOPS ≥ pico x 1. 5, latency p95 na janela de destino; balas individuais sob o registro/dados.

GPU/ML (se houver uma inferência online)

Samples/s, latency, VRAM headroom, batching.
Reserva: parâmetros batch sob a «serra» de carga, warm-pool GPU.

Zoom automático

HPA/KEDA: métricas CPU + customizadas (p95 latency, RPS, fila).
Warm pools: instâncias pré-aquecidas antes dos iventes.
Step-escaling: degraus com cooldown para não «pilhar».
Tempo de reação: Apontando para T _ scale ≤ 1-2 minutos para a camada de frente; para a BD, antecipadamente.

Limitadores e backpressure

Rate-limit по IP/ASN/device/route; quotas para parceiros.
Filas com TTL, rejeição «educado» (429/através de grey-walls) antes dos temporizadores.
Idempotidade: chaves de pagamento; retrai com budget + jitter.
Request collapsing/SWR: não acordar origin durante a eclosão.

Exemplo de cálculo rápido

Certo: Previsão de pico de 35k RPS por API, p95 ≤ 250 ms, média de serviço time de 8 ms por instância com 60% de CPU → μ≈125 RPS/core, 8 núcleos por instância → £1000 RPS/instância.
Passo 1 (sem reserva): 35 instâncias.
Passo 2 (headroom 30%): 35 x 1. 3 = 46.
Passo 3 (rejeição de um AZ, + 20%): 46 x 1. 2 ≈ 55.
Passo 4 (arredondamento + reserva quente 10%): 61 instâncias.
Verificação: ≈ 35k/( 61k) ≈ 0. 57 na zona verde.

Modelo financeiro (FinOps)

$/1000 RPS por camadas (edge, proxy, app, DB).
$/ms p95 (custo de redução da cauda).
Cenário TCO: on-demand vs reserved vs spot (com risco de interrupção).
Os limites trimestrais de contas/cluster, as quotas de nuvem, os limites PSP/CDN.

Disposição de falha e DR

Multi-AZ/region: cada ombro ≈ 60% de carga.
Plano Failover: withdraw Anycast, mudança GSLB, TTL ≤ 60-120 s.
Dependências críticas: limites PSP/bancos, provedor secundário.
Exercício periódico: game day desligado PoP/BG/cachê.

Observabilidade e sinais de saturação precoce

Altura de p95/p99 e filas de entrada estável.
Queda do cachê hit-ratio, crescimento origin egress.
Aumento de retransmits/ECN CE, queda de resumpção TLS.
Crescimento 429/timeout e retry-rate.
Para a base de dados - crescimento de conflitos, checkpoint time, WAL fsync.

Práticas operacionais

Capacity review mensalmente: fato vs plano.
Altere windows com iventes: freeze de núcleo e limites.
Prewarm (CDN/DNS/TLS/pula) 10-30 min antes do pico.
Versionização de limites: instale os configs rate-limit/pool em Git.

Especificidades para iGaming/Fintech

Torneios/jogos: perfis spike + plateau, rotas cinzentas para bots, limites individuais de inscrição/depósito.
Pagamentos/PSP: quotas de provedor/método, rotas fallback, pool egress-IP, SLA Time-to-Wallet.
Provedores de conteúdo, distribuição por estúdios, cachês quentes, shard pools.
Antifrod/AML: limite de regras/corte, degradação a regras light no pico.

Folha de cheque de implementação

• Previsão de pico (base/temporada/ivents), dois cenários.
• SLO/orçamento errado e headroom alvo ≥ 30%.
• Sizing por camadas (edge/proxy/app/cachê/DB/IO/rede).
• Limitadores: rate-limit, filas, idempotency, retry-budet.
• HPA/KEDA + warm pools; um plano de promoção para o Ivent.
• Multi-AZ/region, playbooks failover, TTL e GSLB.
• As quotas de nuvem/PSP/CDN estão alinhadas e documentadas.
• Observabilidade: dashboards capacity, sinais iniciais de saturação.
• Ensinamentos DR. e capacity-review regular.

Erros típicos

Plano para RPS médio sem caudas/picos.
ρ≈0. 9 «no papel», a latência explode ao mínimo ruído.
Ignorar limites de serviços externos (PSP/CDN/BB).
Nenhum modo degrade ou backpressure - feeds em cascata.
Escala automática sem pré-aquecimento - «depois» do pico.
Um único headroom para todas as camadas - um espaço estreito migra.

Mini-playbooks

Antes do evento de pico (T-30 min)

1. Aumentar minReplicas/target HPA, incluir warm pool.
2. Aqueça CDN/DNS/TLS/conectórios, aqueça os cachês.
3. Elevar os limites de pool e as quotas PSP por acordo.
4. Incluir rotas cinzentas/bot-filtros, estreitar endpoint pesados.

Perda parcial da região

1. GSLB → região vizinha, TTL 60-120 s.
2. Ativar Modo degrade (em dinheiro/emissão simplificada).
3. Redistribuir limites PSP/egress-IP.
4. Comunicação de status, controle de p95/erros.

Aumento de retrações

1. Reduzir retry-boodget, incluir backoff + jitter.
2. Incluir request-collapsing/SWR no GET.
3. Apertar temporariamente rate-limit para ASN «ruidoso».

Resultado

O planejamento de potência é uma previsão de demanda + modelo de engenharia + estoque de resistência + alavancagem operacional. Formalize o SLO e o headroom, leve em conta os limites externos, automatize a escala e a degradação, mede o «custo milissegundo» e realize a capacity-review regular. O aumento da carga não se transformará em risco, mas em uma métrica controlada de negócios.