Equilibrio de carga

1) Por qué y dónde está en la arquitectura

• disponibilidad (sin un único punto de falla), latencia (p95 abajo), escala (horizontal), seguridad (TLS/WAF), manejabilidad de lanzamientos (canario/azul-verde).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, maglev, proxy sin terminaciones.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): enrutamiento por ruta/encabezado/sello, caché/compresión/retrés.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) Modelos y algoritmos de equilibrio

Round-Robin (RR): simple y uniforme.
Conexiones Least (LC): bueno para conexiones largas (WS, gRPC).
Solicitud de Least/Power-of-Two (P2C): comparar dos aleatorios es un buen equilibrio velocidad/calidad.
Weighted RR/LC: pesas para el nodo canario/« caliente ».
Consistent Hashing (CH): pegajosidad de sesión sin tabla (cart, Redis).
Maglev/Flow-hash: distribución rápida L3/L4 con resistencia al flapping.
Latency-aware: selección por deslizamiento p50/p95.
EWMA: tiene en cuenta el historial de retrasos.

Recomendación: por defecto P2C (least-request) en L7; para stateful/caché - consistent hash; для WS/gRPC — least-connections.

3) Salud de los Apstrim: controles y «desalojos»

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; intervalos/temporizadores/umbral de error.
Outlier Ejection: auto-exclusión de instancias «ruidosas» (consecutive-5xx, success-rate-ejection).
Slow-start & warmup: entrada suave de nuevas instancias (aumento gradual de peso).
Connection draining: cuando está desactivado/desinflado - «brochado» de los conectores activos sin rotura.

4) Sesiones y pegajosidad (stickiness)

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH por clave: 'hash (userId' sessionId 'cartId)'.
IP-hash: sólo en redes cerradas (NAT rompe).
TTL pegajoso + fallback en la evicción del nodo.
Importante: minimizar la necesidad de pegajosidad → mantener la condición fuera de la instancia (Redis/DB/JWT).

5) Equilibrio global (GTM/GSLB)

Anycast + health-probe: una IP, tráfico al PoP más cercano; Un failover automático.
GeoDNS/Latency-DNS: respuesta por geo/latencia.
Clusters regionales: «datos de residentes» permanecen en la región (GDPR); failover interregional con replicación.
Políticas: geo-bloques, «stickeregion» por cuenta/token.

6) Protocolos y características

HTTP/2: multiplex, prioridades; necesita una conexión-pool competente en el Apstream.
gRPC: streams de larga vida → conexiones least, cheques de salud agresivos.
WebSocket/SSE: pegajosidad por connect, grandes idle-timeouts, TCP keep-alive.
QUIC/HTTP/3: inicio rápido, resistencia a la pérdida; siga el MTU/parche-MTU.
TLS-termination/mTLS: eliminar en el edge/L7-LB; dentro - mTLS/identidad (SPIFFE).

7) Protección contra sobrecarga (control overload)

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Concurrencia adaptativa (Envoy): límite dinámico de las consultas simultáneas.
Queue/Surge-buffer: tamaño de cola limitado con un error honesto de 503.
Hedging/Parallel racing: duplicación de consultas lentas (sólo idempotentes).
Timeout budget: split connect/read/write.
Retroceso: '503 + Retry-After', retratos exponenciales de clientes con jitter.
Protección slow-loris: tiempos de lectura/escritura, velocidad mínima.

8) Lanzamientos y gestión del tráfico

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Azul-Verde: Sweet instantáneo, retroceso - DNS/LB.
Shadow/Mirror: copia de las solicitudes sin afectar a la respuesta; enmascaramiento PII.
Header/Claim-routing: `X-Canary: 1` или `JWT. claims. region/role`.

9) Auto Skaling y drenaje

HPA/ASG по CPU+RPS+p95+queue-depth.
PreStop hook: esperar a que finalicen los connects.
Warm pool/instance reuse: reducir los lanzamientos en frío.
Planificación de la capacidad: objetivo 'utilización 60-70%' a p95 normal.

10) Observabilidad y SLO

Métricas LB: RPS, p50/p95/p99, 4xx/5xx, conexiones abiertas, queue-len, ejections, retries, hit-ratio kash.
Senderismo: 'traceparent/x-request-id' a través de los servicios LB → → DB.
Logs: estructural, máscaras PII/PAN, corea con apstream.
SLO en la ruta: por ejemplo, 'latency p95 ≤ 300 ms',' availability ≥ 99. 9%`, `5xx ≤ 0. 5%`.
Alertas: por desviaciones (burn-rate SLO, estallido de ejection, crecimiento 5xx/timeout).

11) Equilibrio de datos y caché

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover: réplica sincrónica para RPO = 0 (más caro).

• Redis Cluster + hash-slot; para las sesiones - CH; temporizadores/errores retryables.

• Equilibrio a través de partitioning y consumer-groups; no confundir con HTTP-LB.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) K8s y nube LB

Servicio (ClusterIP/NodePort/LoadBalancer) - L4 básico.
API de Ingress/Gateway - Enrutamiento L7, pesos canarios, TLS.
AWS: NLB (L4, ancho de banda alto), AMB (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) Ejemplos de configuraciones

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) Hojas de cheques

Antes de la versión LB/Route

• El algoritmo está seleccionado (P2C/LC/CH) para el tipo de tráfico.
• Los controles de salud y los umbrales de ejection están configurados.
• Se incluyen slow-start, warmup, connection-drain.
• TLS/mTLS, HSTS, cifrados seguros; HTTP/2/3 si es necesario.
• Sticky/CH sólo si es necesario; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• Logs/Tracks: 'trace-id' está barrido; enmascaramiento PII.
• SLO/alertas por p95/5xx/electos/queue-len.
• Peso canario + plan de retroceso; shadow en grandes cambios.

Para rutas de pago/cumplimiento

• Idempotencia POST (Idempotency-Key).
• Failover entre PSP; same-method de verificación.
• Los códigos de error se normalizan; ATA/razones por cliente.

Para el BD/caché

• RW-split/réplicas; temporizadores, retry-s de red.
• CH/slot-hash para Redis; protección contra «llaves calientes».
• Monitoreo de retrasos y replicación-lag.

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

Latency p50/p95/p99 por rutas/métodos.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Outlier ejections y razones.
Sticky hit-ratio / cache hit-ratio.
GSLB: distribución regional, feilover, disponibilidad de PoP.

16) Anti-patrones

Un LB monolítico sin redundancia.
Sesiones de sticky «a todo», en lugar de sacar un estado.
Colas interminables globales (oculta el problema, crece p99).
Retraídas sin jitter/presupuesto - «tormenta» de solicitudes.
Confianza 'X-Forwarded-For' sin lista de proxy de confianza.
La ausencia de drain en los deploys → los acantilados WS/gRPC.
No se tienen en cuenta los conectores long-lived en el scale automático.

17) iGaming-especificidad

Picos y torneos: micro-cache en directorios/listados (1-5 s), auto-skale por turnos.
Juegos en vivo/streams: LC para conexiones largas, prioridad de los PoP más cercanos.
Pagos: enrutamiento por geo/moneda/importe/proveedor; tiempos estrictos e idempotencia.
Juego y cumplimiento responsables: es prioritario saltarse las solicitudes de límites/bloqueos incluso cuando se degradan (fail-open/close por política).

18) Proceso de implementación (4 sprints)

1. Mapa de tráfico: protocolos, cargas p95/p99, rutas críticas.
2. Configuración LB: algoritmos, salud/outlier, TLS, límites/temporizadores, observabilidad.
3. GSLB/Edge: Anycast/GeoDNS, PoP-helschek, políticas de datos regionales.
4. Estrategia de lanzamiento: canary/shadow, alertas SLO, auto skale + drain, análisis post-incidente.

Parche final

Seleccione un algoritmo para el tipo de tráfico (P2C/LC/CH) y la duración del conector.
Mantenga los apstreams «saludables»: health-checks + outlier + slow-start + drain.
Controle la carga máxima: rate-limit, concurrencia adaptativa, colas con error.
Utilice GSLB/Anycast para la disponibilidad global y el cumplimiento por regiones.
Observabilidad y SLO - obligatorios; lanzamientos - a través de canary/shadow con un plan de reversión.
Siempre que sea posible, quite la sesionalidad de las instancias y la pegajosidad de la LB.