Equilibrio de carga y failover

1) Objetivos y términos

El equilibrio distribuye el tráfico entre instancias/zonas/regiones para el rendimiento y la sostenibilidad.
Failover - Conmutación controlada por error.
RTO/RPO: tiempo de recuperación objetivo y pérdida de datos admisible.
SLO: nivel objetivo de disponibilidad/latencia; sirve como «portón» para el failover automático y retroceso.

2) Capas de equilibrio

2. 1 L4 (TCP/UDP)

Ventajas: rendimiento, simplicidad, TLS passthrough. Contras: no hay comprensión de la ruta/cookies.
Ejemplos: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Ventajas: enrutamiento a lo largo del camino/headers, pesos canarios, sticky. Contras: más caro por CPU/latencia.
Ejemplos: NGINX/HAProxy/Envoy/Cloud AMB/API Gateway.

2. 3 Nivel global

DNS/GSLB: health-checks + geo/respuesta ponderada.
Anycast/BGP: una IP en todo el mundo, el punto de anuncio más cercano.
CDN/Edge: caché/failover en el perímetro.

3) Algoritmos de distribución

Round-robin/weighted - básico.
Conexiones Least/latency - para consultas «pesadas».
Consistent hashing - adhesivo por clave (usuario/tenant) sin sesión central.
Hash-based locality - para cachés y servicios stateful.

4) Sesiones y adhesivo (sticky)

Cookie sticky: L7 LB establece una cookie para volver a la instancia.
Sticky SRC-IP: en la L4, peor con NAT/CGNAT.
Consistent hashing: mejor para cachés/chats horizontales.
Aim: si es posible, haga que el servicio sea estable, de lo contrario, saque el estado (sesiones en Redis/DB) para simplificar el failover.

5) Fiabilidad: health-checks y eliminación de la rotación

Active checks: HTTP 200/Deep Business Path (por ejemplo, '/healthz/withdraw 'con dependencias).
Detección pasiva (outlier detection): eyección de backend a 5xx/timeout.
Warm-up: incorporación suave de nuevas instancias (slow-start).
Graceful drain: quitar del grupo → esperar a que se completen las solicitudes.

NGINX (ejemplo):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Envoy outlier detection (fragmento):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Control de fallos: timeout/retry/circuit-breaking

Timeouts: más corto que el tiempo de espera del cliente; especificar per-route.
Retries: 1-2 con jitter e idempotencia; prohibición de retiros en POST sin claves de idempotencia.
Circuit breaker: limitar las solicitudes/errores simultáneos; Recuperación «semiabierta».
Budgets: límites de retrayas/fusión de bursts para no conformarse con self-DDOS.

7) Patrones de Kubernetes

ClusterIP/NodePort/LoadBalancer/Ingress son primitivas básicas.
Readiness/Liveness: el tráfico sólo a las pistas terminadas.
PodDisruptionBudget: no se permite la caída simultánea de N réplicas.
HPA/VPA: escala por métricas CPU/RED, ligamento con LB.
ServiceTopology/Topology Aware Hints: Localidad por zona.
Tipo de servicio = LoadBalancer (zonal): mínimo: 2 réplicas por AZ.

Readiness de ejemplo para una ruta crítica:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Tráfico Cross-Zone y Cross-Regional

Multi-AZ (dentro de la región): distribuir uniformemente (zonal LB), almacenamiento - réplicas sincrónicas.

Multi-region:

Active-Active: ambas regiones dan servicio al tráfico; más difícil: necesita replicación de datos, consistencia y enrutamiento geográfico.
Active-Passive: la región principal sirve, la reserva es «caliente/caliente/fría». Más fácil, más rápido de cambiar, pero por encima de RPO.

Estrategias de GSLB:

Geo-DNS (región más cercana).
Weighted DNS (canario/redistribución).
Latency-based (medidas RTT).
Failover = por señales de salud/disponibilidad (probes desde múltiples puntos de vantage).

9) Datos y failover

Cache/state: si es posible, regionalmente local; para Active-Active - hashes CRDT/consistentes.

DB:

Replicación sincrónica = RPO baja, mayor latencia.
Asincrónico = menor latencia, pero RPO> 0.
Colas: espejado/topics multiclaster; desduplicación de eventos.
Diseñe la idempotencia de las operaciones y la mecánica de respuesta.

10) Perímetro: DNS/Anycast/BGP/CDN

DNS: TTL corto (30-60s) + cheques de salud fuera de su red.
Anycast: varios RR's con una sola IP: el más cercano recibe tráfico, un failover a nivel de enrutamiento.
CDN/Edge: caché y «gateway» para protección, estática/medios se mantienen cuando el origin cae; origin-shield + пер-POP health.

11) Configuraciones de muestra

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Failover automático: señales y gates

T-SLI: 5xx-rate, p95/p99, saturation, handshakes TLS, TCP resets.
SLI empresarial: éxito de depósitos/pagos, no hay errores de pago en PSP.
Gates: cuando se superan los umbrales - desconectar la zona/instance, levantar los pesos de la piscina estable, cambiar GSLB.
Runbook: instrucciones paso a paso para cambiar y devolver (rollback).

13) Pruebas e inspecciones (chaos & game-days)

Pruebas de chaos: desconexión de AZ/regiones, degradación de BD/caché, simulación de packet-loss.
Día de juego: un Feilover de entrenamiento que involucra a equipos on-call.
Diagnóstico: seguimiento desde el perímetro hasta los backends, correlación de anotaciones de liberación y métricas.

14) Seguridad y cumplimiento

mTLS entre LB↔servisy, límites WAF/Rate en el perímetro.
Zonas de falla/segmentación: aislamiento blast-radius.
Pólizas: prohibición de puntos de falla únicos (SPOF), requisitos de «mínimo N réplicas/AZ».

15) Anti-patrones

Una zona LB/una para todo el tráfico prod (SPOF).
Falta de validación profunda '/healthz '(verde - pero la DB/cola no está disponible).
Retray sin idempotencia → toma de operaciones/pagos.
El Sticky per IP en el NAT masivo → un desequilibrio.
Failover DNS con altas TTL (horas antes de cambiar).
No graceful drain en el deplay - acortamiento de solicitudes.

16) Lista de verificación de implementación (0-45 días)

0-10 días

Separar las instancias por ≥2 AZ; habilitar readiness/liveness, health-checks.
Configurar L7-timeouts/retries (1 intento), detección de outlier.
Habilitar graceful drain y slow-start.

11-25 días

Introduzca GSLB (geo/weighted) o Anycast para el perímetro.
Peso canario/políticas de rutas; sticky a través de cookies/consistent hash.
Juegos SLO para failover automático (p95/5xx + SLI de negocios).

26-45 días

RD regional: Active-Active o Active-Passive con prueba de traducción.
Días de chaos con AZ/regiones desactivadas, informes RTO/RPO.
Runbook's automatizados (scripts pause/shift/rollback).

17) Métricas de madurez

La cobertura Multi-AZ ≥ el 99% de las vías críticas.
DNS/GSLB/Anycast se han implementado para endpoints públicos.
MTTR cuando cae un AZ <5 minutos (p95).
RPO para datos críticos ≤ destino (por ejemplo, ≤ 30 segundos).
Juegos trimestrales-días y un exitoso plan de failover.

18) Conclusión

El balanceo y failover confiable es una arquitectura en capas: políticas L7 locales (timeouts/retries/CB, health-checks), adhesivo y hashing correctos, estabilidad de zona cruzada, y en el perímetro, GSLB/DNS/Anycast. Agregue gates SLO, idempotencia, drain graceful y pruebas de chaos regulares - y cualquier pérdida de nodo, zona o incluso región se convertirá en un evento manejable con RTO/RPO predecible.

Equilibrio de carga y failover