Balancear carga de trabalho

1) Porquê e onde está na arquitetura

• disponibilidade (sem ponto de falha único), latência (p95 para baixo), escala (horizontal), segurança (TLS/WAF), governabilidade de lançamentos (canary/blue-green).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, maglev, proxy sem terminação.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): roteiro/cabeçalho/marca, kesh/compressão/retrai.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) Modelos e algoritmos de equilíbrio

Round-Robin (RR): simples uniforme.
Least Connections (LC): bom para conectórios de longa duração (WS, gRPC).
Least Request/Power-of-Two (P2C): comparação entre dois aleatórios - bom equilíbrio velocidade/qualidade.
Weighted RR/LC: peso para canary/nódulo «quente».
Consent Hasing (CH): pegação de sessão sem tabela (cart, redis).
Maglev/Flow-hash: distribuição rápida L3/L4 com resistência ao flapping.
Latency-aware: escolha por p50/p95 deslizante.
EWMA: leva em conta o histórico de atrasos.

Recomendação: padrão P2C (least-request) em L7; para o status/dinheiro - consistent hash; для WS/gRPC — least-connections.

3) Saúde upstream: inspeções e «despejo»

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; intervalos/temporizações/limiar de erro.
Outlier Ejation: Exclusão automática de instâncias «ruidosas» (conseqüência-5xx, sucess-rate-ejation).
Slow-start & warmup: entrada suave de novas instâncias (aumento gradual de peso).
Connation draining: Quando o/depload é desativado, os conectórios estão ativos sem penhasco.

4) Sessões e pegajosos (stickiness)

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH na chave «hash (userId'sessionId'cartId)».
IP-hash - apenas em redes fechadas (NAT quebra).
TTL de pegadinha + fallback para eucemia de nódoa.
Importante: Minimize a necessidade de pegadinha → mantenha a condição fora de instância (Redis/DB/JWT).

5) Balanceamento global (GTM/GSLB)

Anycast + health-probe: um IP, tráfego no PoP mais próximo; Um feelover automático.
GeoDNS/Latency-DNS: resposta por geo/atraso.
Clusters regionais: «dados residentes» permanecem na região (GDPR); failover interregional com replicação.
Políticos: geo-blocs, adesão por conta/token.

6) Protocolos e características

HTTP/2: multiplex, prioridades; Você precisa de uma conexão-pool para upstream.
gRPC: Striam de longa vida → least-connections, health-checks agressivos.
WebSocket/SSE: Pegajosidade no conector, grandes idle-timeouts, TCP keep-alive.
QUIC/HTTP/3: início rápido, resistência à perda; acompanhe o MTU/path-MTU.
TLS-termination/mTLS: Terminar em edge/L7-LB; para dentro - mTLS/identity (SPIFFE).

7) Proteção contra sobrecarga (overload controle)

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Adaptative Concertency (Envoy): limite dinâmico de consultas simultâneas.
Queue/Surfe-buffer: tamanho limitado da fila com rejeição honesta 503.
Hedging/Paralel racing: Duplicação de solicitações lentas (somente idumpotentes).
Timeout budget: connect/read/write separados.
Backpressure: '503 + Retry-After', retraí exponencial do cliente com jitter.
Slow-loris proteção: tempo de leitura/gravação, velocidade mínima.

8) Lançamentos e gestão de tráfego

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Blue-Green, swich instantâneo, reversão DNS/LB.
Shadow/Mirror: cópia de solicitações sem efeito na resposta; camuflagem PII.
Header/Claim-routing: `X-Canary: 1` или `JWT. claims. region/role`.

9) Skeiling automático e drenagem

HPA/ASG по CPU+RPS+p95+queue-depth.
«hook», aguardar a conclusão dos conectórios.
Warm pool/instance reuse: redução de lançamentos frios.
Capacity planning: destino 'utilization 60-70%' com p95 normal.

10) Observabilidade e SLO

Métricas LB: RPS, p50/p95/p99, 4xx/5xx, open-connections, queue-len, ejtions, retries, hit-ratio cajá.
Traceparent/x-request-ID através de serviços LB → → BD.
Logi: estruturais, máscaras PII/PAN, coreação com upstream.
SLO por exemplo: 'latency p95 ≤ 300 ms', 'availability ≥ 99. 9%`, `5xx ≤ 0. 5%`.
Alerts: por desvios (burn-rate SLO, sobe ejation, altura de 5xx/timeout).

11) Balanceamento de dados e dinheiro

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover: réplica sincronizada para RPO = 0 (mais caro).

• Redis Cluster + hash-slot; para sessões - CH; timeouts/Retryable errors.

• Equilíbrio por partitioning e consumer-groups; Não se confunde com HTTP-LB.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) K8s e LB na nuvem

O Service (ClusterIP/NodePort/LoadBalancer) é um L4 básico.
Ingresss/Gateway API - Rotação L7, peso canário, TLS.
AWS: NLB (L4, alta largura de banda), ALB (L7, WAF, sticky, header-routing).
GCP: Global LB (L7/HTTP(S) с Anycast), TCP/UDP proxy LB.
Azure: Front Door (global), Application Gateway (L7), Load Balancer (L4).

13) Exemplos de configuração

13. 1 NGINX (L7, least_conn, sticky, canary)

nginx upstream api_pool {
least_conn;
server api-1:8080 max_fails=3 fail_timeout=10s;
server api-2:8080 max_fails=3 fail_timeout=10s;
sticky cookie lb_id expires=30m path=/ secure httponly;
}

map $http_x_canary $dst {
default api_pool;
1    canary_pool;
}

upstream canary_pool {
least_conn;
server api-canary:8080 weight=1;
}

server {
listen 443 ssl http2;
location /api/ {
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_set_header X-Request-Id $request_id;
proxy_pass http://$dst;
}
}

13. 2 HAProxy (P2C, health, slowstart, stick-table)

haproxy backend api balance leastconn option httpchk GET /health default-server inter 3s fall 3 rise 2 slowstart 10s server s1 10. 0. 0. 11:8080 check server s2 10. 0. 0. 12:8080 check stick-table type ip size 100k expire 30m http-request track-sc0 src rate limit per IP http-request deny deny_status 429 if { sc_http_req_rate(0) gt 50 }

13. 3 Envoy (P2C, outlier, retries, adaptive concurrency)

yaml load_assignment: {... }
lb_policy: LEAST_REQUEST least_request_lb_config: { choice_count: 2 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s typed_extension_protocol_options:
envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency:
gradient_controller_config:
sample_aggregate_percentile: PERCENTILE_50 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 1s

13. 4 Kubernetes (Gateway API, weighted canary)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- matches: [{ path: { type: PathPrefix, value: /api }}]
backendRefs:
- name: api-v1 weight: 90 port: 8080
- name: api-v2-canary weight: 10 port: 8080

14) Folhas de cheque

Antes do lançamento do LB/rota

• Algoritmo selecionado (P2C/LC/CH) sob o tipo de tráfego.
• Health-checks e liminares de ejation são configurados.
• Slow-start, warmup, connect-drain estão ativados.
• TLS/mTLS, HSTS, códigos seguros; HTTP/2/3, se necessário.
• Sticky/CH apenas se necessário; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• Logs/trens: 'trace-id' é processado; camuflagem PII.
• SLO/alertas por p95/5xx/eletrizes/queue-len.
• Peso canário + plano de reversão; shadow em grandes alterações.

Para rotas de pagamento/compliance

• Idempotidade POST (Idempotency-Key).
• Failover entre PSP; same-method verificação.
• Códigos de erro normalizados; ETA/razões por cliente.

Para BB/dinheiro

• RW-split/réplicas; temporizadores, retry-s da rede.
• CH/slot-hash para Redis; protecção contra chaves quentes.
• Monitoramento de atrasos e replicação-lag.

15) Métricas de qualidade (mínimo)

Latency p50/p95/p99 através de rotas/métodos.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Outlier ejections e razões.
Sticky hit-ratio / cache hit-ratio.
GSLB: distribuição regional, feelowers, disponibilidade de PoP.

16) Anti-pattern

Um LB monolítico sem reserva.
Sessões de Sticky para tudo, em vez de remover o estado.
Filas infinitas globais (escondendo o problema, criando p99).
Retrai sem jitter/orçamento é uma tempestade de pedidos.
Confiança 'X-Forwarded-For' sem lista de proxy confiável.
A falta de drain nos depósitos os penhascos.
Não contabiliza os conectórios long-lived no skale automático.

17) iGaming-especificidades

Picos e torneios: micro-cachê em guias/listagens (1-5 c), carro-skale em turnos.
Jogos Live/Striam: LC para longos conectórios, prioridade para os próximos PoP.
Pagamentos: rotação por geo/moeda/montante/provedor; temporizações rigorosas e idempotidade.
Jogo e complacência responsável: prioridade para omitir solicitações de limites/bloqueios mesmo com a degradação (fail-open/close de política).

18) Processo de implementação (4 sprint)

1. Mapa de tráfego: protocolos, cargas p95/p99, rotas críticas.
2. Configuração LB: algoritmos, health/outlier, TLS, limites/temporizações, observabilidade.
3. GSLB/Edge: Anycast/GeoDNS, PoP-helscheques, políticas de dados regionais.
4. Estratégia de lançamento: canary/shadow, alertas SLO, skale de carro + drain, análise pós-incidente.

Esparguete final

Selecione o algoritmo sob o tipo de tráfego (P2C/LC/CH) e a duração do conector.
Mantenha os upstream «saudáveis»: health-checks + outlier + slow-start + drain.
Gerencie a carga máxima de rate-limit, adaptativa concurrency, filas com rejeição.
Use o GSLB/Anycast para disponibilidade global e complacência por região.
Observabilidade e SLO são obrigatórios; lançamentos - via canary/shadow com plano de reversão.
Se possível, retire a sessão das instâncias e a pegadinha do LB.