Estás de guardia de un servicio web: un balanceador de carga delante de una flota de instancias, una caché delante de una base de datos y un objetivo de disponibilidad del 99,9 %. Cada minuto el modelo calcula el retraso de cola, los tiempos límite, los aciertos de caché y la carga de la base de datos con fórmulas de manual, y lo que cuestan tus decisiones.
Suelo de la flota. Subirlo lanza instancias al instante, pero aún necesitan el retraso de arranque antes de atender.
Seguimiento de objetivo sobre la utilización; sin nuevo escalado horizontal mientras haya instancias arrancando. Apagado = exactamente el mínimo.
Más bajo = más margen y más coste. La utilización medida no puede superar el 100 %, así que una flota saturada solo crece paso a paso.
TTL más largo = más aciertos, pero las respuestas pueden ser más antiguas (edad media ≈ TTL/2).
Carga las claves más usadas durante 6 minutos (+12 % de la caché por minuto) al precio de 600 consultas extra por segundo a la base de datos.
Parte del 30 % de baja prioridad (precarga, lotes, rastreadores) rechazada en el balanceador de carga con «reintentar más tarde».
La función pesada añade 20 ms de CPU y una consulta a la base de datos por petición. Apagado = degradación controlada.
Vuelve a desplegar la última versión buena en una flota nueva (5 min, se factura dos veces) y luego cambia el tráfico. Presionar de nuevo reinicia la preparación; sin una versión mala en producción, solo cuesta dinero.
| Tasa de consumo (1 h) | 0.0 × |
|---|---|
| Peticiones | 1125 req/s |
| Instancias atendiendo | 10 |
| Instancias arrancando | 0 |
| Tasa de aciertos de caché | 77 % |
| Utilización de la base de datos | 19 % |
| Tráfico descartado | 0 % |
| Coste de la flota | 4.00 $/h |
| Coste hasta ahora | 0.00 $ |
| Edad media de las respuestas en caché | 30 s |
| Tráfico en la versión defectuosa | 0 % |
| Recomendaciones disponibles | 100 % |
Una versión nueva sale a las 09:10. El mes ya ha sido duro: solo queda el 20 % del presupuesto de errores. Minutos después del despliegue salta la alerta de tasa de consumo. Protege el presupuesto.
Un enlace al servicio se está difundiendo rápido y se espera un pico de tráfico en algún momento de esta mañana: nadie sabe cuándo ni de qué tamaño. Hoy las instancias nuevas tardan 8 minutos en arrancar. Cuando llegue, mantén bajos los errores y la latencia sin quemar dinero en capacidad ociosa.
En el pico del mediodía, un script de mantenimiento vacía toda la caché. Ahora cada petición va a la base de datos, dimensionada para la tasa de aciertos habitual del 85 %. Recupera el servicio sin sobrecargar la base de datos.
Todas las relaciones que usa el simulador, con su fuente. Las constantes marcadas como supuestos son calibraciones ilustrativas.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Supuesto: el número de workers, los tiempos de servicio, la capacidad de la base de datos, el tamaño de la caché, la velocidad de recarga, los precios y la tasa de error de la versión defectuosa son valores ilustrativos de un servicio web de tamaño medio.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Aproximación: sumar los cuantiles de servicio y de espera no da el p99 exacto de su suma (puede salir algo alto o bajo); la cola se trata como estacionaria dentro de cada minuto porque las peticiones duran milisegundos.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Supuesto: el número de workers, los tiempos de servicio, la capacidad de la base de datos, el tamaño de la caché, la velocidad de recarga, los precios y la tasa de error de la versión defectuosa son valores ilustrativos de un servicio web de tamaño medio.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Supuesto: el número de workers, los tiempos de servicio, la capacidad de la base de datos, el tamaño de la caché, la velocidad de recarga, los precios y la tasa de error de la versión defectuosa son valores ilustrativos de un servicio web de tamaño medio.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesSupuesto: el número de workers, los tiempos de servicio, la capacidad de la base de datos, el tamaño de la caché, la velocidad de recarga, los precios y la tasa de error de la versión defectuosa son valores ilustrativos de un servicio web de tamaño medio.Aleatoriedad: un generador mulberry32 con semilla; distribuciones usadas: uniforme, exponencial (CDF inversa), normal (Box–Muller), Poisson (Knuth). La semilla se muestra y se puede compartir.
Modelo educativo: no sirve para decisiones operativas. Las instalaciones reales calibran cada constante con sus propios equipos y datos.