Planificación de la capacidad y crecimiento de la carga

Resumen breve

1. Previsión de demanda (tendencia básica + estacionalidad + eventos).

2. Modelo de carga (modelo abierto para Internet).

3. Margen de seguridad (headroom) y presupuesto erróneo.

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

5. Finanzas: $/1000 RPS, $/ms p95, TCO por escenarios.

Términos y métricas

Throughput: RPS/QPS/CPS - ancho de banda real.
Latency p95/p99: SLO de destino para rutas personalizadas.
Saturación: carga de CPU/memoria/IO/FD/conexiones/colas.
Error rate: 5xx/timeout/429, presupuesto erróneo para el período.
Headroom: una fracción de la potencia libre en el tráfico máximo (recomendado ≥ 30%).
Burst: ráfaga a corto plazo (segundos/minutos), Spike: fuerte crecimiento × N.

Modelos y fórmulas básicos

Little's Law (para sistemas con colas)

L = λ W

L es el promedio de solicitudes en el sistema, λ es la intensidad media de inicio de sesión (RPS), W es el tiempo promedio en el sistema. Útil para evaluar la profundidad de las colas.

Tasa de carga (ρ)

ρ = λ / μ

μ - Velocidad de servicio (RPS a 100% CPU). Con ρ→1, la latencia crece de forma no lineal: mantenga el punto de trabajo ρ ≤ 0. 6–0. 75.

Safety factor/stock

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Donde Degradation_factor tiene en cuenta la falla de N, la degradación de la caché, la pérdida de un RoR/región (por ejemplo, 1. 2).

Previsión

1. Historia: perfiles diurnos/semanales, estacionalidad, correlación con eventos (partidos/streams/pagos).
2. Eventos: coeficientes de escenario (día normal × 1, torneo × 2. 3, final × 3. 5).
3. Fuentes de fluctuaciones: campañas de marketing, lanzamientos, anomalías de bots.
4. Unidades de predicción: RPS por rutas (login, lobby, catalog, payments), CPS TLS, QPS DB, disco IOPS, Gbps/s.
5. Confianza: guarda dos escenarios: conservador y agresivo.

Modelado de carga

Open-model (la llegada de Poisson-similar): plausible para las API/web- use para sizing.
Modelo cerrado (VU + think-time): adecuado para secuencias internas; combinar.
Mezclas de rutas: lóbulos de peso por endpoints; incluir no sólo «caliente», sino también «caro» (registro, depósito).
No olvides: retraídas, colas, límites de socios (PSP, API de terceros).

Diseño de stock de resistencia

Headroom objetivo: ≥ 30% al pico (para Internet); para el núcleo de pago y rutas críticas - 40-50%.
N + 1/N + 2: Resistimos el fallo de 1-2 instancias/zona sin infringir el SLO.
Multi-región: cada región tira ≥ del 60% del pico total (para sobrevivir a la pérdida de un vecino).
Degrade-modo: desactivar las funciones secundarias, reducir el payload, activar las respuestas de caché/velocidad.

Tamaño por capa

Red/Edge

CPS/RPS en el frente, TLS-handshake p95, resumption≥70%, egress Gbps.
Anycast/Geo-routing, límites CDN/WAF (negociar previamente).
Stock: link/aplink ≥ pico × 1. 3, respaldo SYN con stock, UDP/443 para H3.

Balanceadores/Proxy

RPS en instancia, conexiones abiertas, colas, CPU/IRQ.
Keepalive y connection pooling - reducen las conexiones a los backends.
Stock: ρ ≤ 0. 7, limiter по CPS/RPS per route.

las Aplicaciones

Rendimiento objetivo por núcleo (RPS/core) en la meseta.
Grupos (thread/DB/HTTP): no confiar en los límites.
Stock: auto skale a CPU 60-70% y latency-trigger (p95).

Cach

Hit-ratio, volumen hotset, eviction, réplica.
Stock: memoria ≥ 1. 2 × hotset, headroom de red ≥ 30%.

Bases

QPS/TPM, p95 consultas, bloqueos, caché de búfer, WAL/replication log.
El disco IOPS y latencia es la clave de p95.
Stock: punto de trabajo CPU 50-65%, valor de réplica <destino; plan de charding y read-replicas.

Discos/Almacenamiento

IOPS (4k/64k), throughput, fsync cost.
Stock: IOPS ≥ pico × 1. 5, latency p95 en la ventana de destino; grupos individuales bajo registro/datos.

GPU/ML (si hay una inferencia en línea)

Samples/s, latency, VRAM headroom, batching.
Stock: parámetros de batch bajo «sierra» de carga, warm-pool GPU.

Escala automática

HPA/KEDA: métricas de CPU + personalizadas (p95 latencia, RPS, cola).
Warm pools: instancias precalentadas antes de los eventos.
Paso a paso: pasos con cooldown para no «aserrar».
Tiempo de reacción: apuntar en T_scale ≤ 1-2 minutos para la capa frontal; para la DB - por adelantado.

Limitadores y backpressure

Rate-limit по IP/ASN/device/route; Cuotas de socios.
Colas con TTL, rechazo «cortesía» (429/vía grey wall) antes que los timautas.
Idempotencia: claves para los pagos; retraídas con budget + jitter.
Request collapsing/SWR: no despierte origin durante una ráfaga.

Ejemplo

Dado: pronóstico de un máximo de 35k RPS por API, p95 ≤ 250 ms, tiempo de servicio promedio de 8 ms por instancia a 60% CPU → μ≈125 RPS/núcleo, 8 núcleos por instancia → ~ 1000 RPS/instancia.
Paso 1 (sin margen): 35 instancias.
Paso 2 (headroom 30%): 35 × 1. 3 = 46.
Paso 3 (fallo de un AZ, + 20%): 46 × 1. 2 ≈ 55.
Paso 4 (redondeo + reserva en caliente 10%): 61 instancias.
Verificación: ρ ≈ 35k/( 61k) ≈ 0. 57 - en la zona verde.

Modelo financiero (FinOps)

$/1000 RPS por capas (edge, proxy, app, DB).
$/ms p95 (costo de la reducción de la cola).
scripts TCO: on-demand vs reserved vs spot (con riesgo de interrupción).
Plan de capacidad: límites trimestrales de cuentas/clústeres, cuotas de nube, límites PSP/CDN.

Preparación para fallas y DR

Multi-AZ/región: cada brazo ≈ el 60% de la carga.
Plan Fallero: withdraw Anycast, conmutación GSLB, TTL ≤ 60-120 s.
Dependencias críticas: límites PSP/bancos, proveedor secundario.
Ejercicios periódicos: game day con PoP/BG/caché apagado.

Observabilidad y señales de saturación temprana

Crecimiento de p95/p99 y colas cuando la entrada es estable.
Caída de caché de hit-ratio, crecimiento de origin egress.
Aumento de retransmisiones/ECN CE, caída de la respuesta TLS.
Crecimiento 429/timeout y retry-rate.
Para el DB - el aumento de conflictos, tiempo de checkpoint, fsync WAL.

Prácticas

Capacity review mensual: el hecho vs plan.
Cambiar Windows a eventos: freeze kernel y límites.
Prewarm (CDN/DNS/TLS/pools) 10-30 minutos antes del pico.
Versificación de límites: confirme las configuraciones de rate-limit/pools en Git.

Características específicas para iGaming/Fintech

Torneos/partidos: perfiles de spike + plateau, rutas grises para bots, límites individuales de inscripción/depósito.
Pagos/PSP: cuotas por proveedor/método, rutas fallback, grupos egress-IP, SLA Time-to-Wallet.
Proveedores de contenido: distribución por estudios, cachés calientes, grupos shard.
Antifraude/AML: límite en reglas/puntuación, degradación a reglas de luz en pico.

Lista de comprobación de implementación

• Pronóstico de picos (base/temporada/eventos), dos escenarios.
• El SLO/presupuesto erróneo y el headroom objetivo ≥ el 30%.
• Tamaño por capas (edge/proxy/app/cache/DB/IO/red).
• Limitadores: rate-limit, colas, idempotency, retry-budget.
• HPA/KEDA + warm pools; plan de promoción antes del evento.
• Multi-AZ/región, failover playbucks, TTL y GSLB.
• Las cuotas de nube/PSP/CDN están acordadas y documentadas.
• Observabilidad: dashboards capacity, señales tempranas de saturación.
• Ejercicios de DR y revisión regular de la capacidad.

Errores

Plan para un RPS medio sin colas/ráfagas.
ρ≈0. 9 «en el papel» - la latencia explota al menor ruido.
Ignora los límites de servicios externos (clúster PSP/CDN/BD).
No hay modos degrade y backpressure - fails en cascada.
Auto-escala sin precalentamiento - logra «después» del pico.
Un único espacio para todas las capas: el cuello de botella migra.

Minibuses

Antes del evento máximo (T-30 min)

1. Aumentar minReplicas/target HPA, habilitar el warm pool.
2. Calentar CDN/DNS/TLS/connects, calentar cachés.
3. Elevar los límites de las agrupaciones y cuotas de PSP por acuerdo.
4. Activar rutas/filtros de bots grises, estrechar los puntos de venta pesados.

Pérdida parcial de la región

1. GSLB → región vecina, TTL 60-120 s.
2. Habilitar el modo degrade (caché/emisión simplificada).
3. Redistribuir límites PSP/egress-IP.
4. Comunicación de estado, control de p95/errores.

Ráfaga de retraídas

1. Reducir el retroceso-budget, habilitar backoff + jitter.
2. Habilitar request-collapsing/SWR en GET.
3. Apriete temporalmente el límite de velocidad para los ASN «ruidosos».

Resultado

La planificación de la potencia es la previsión de la demanda + modelo de ingeniería + margen de seguridad + palancas operativas. Formalice SLO y headroom, tenga en cuenta los límites externos, automatice la escala y la degradación, mida el «costo de milisegundos» y realice revisiones regulares de capacity. Entonces el aumento de la carga no se convertirá en un riesgo, sino en una métrica de negocio manejable.