Estás de garda dun servizo web: un balanceador de carga diante dunha flota de instancias, unha caché diante dunha base de datos e un obxectivo de dispoñibilidade do 99,9 %. Cada minuto o modelo calcula o atraso de cola, os tempos límite, os acertos de caché e a carga da base de datos con fórmulas de manual — e o que custan as túas decisións.
Chan da flota. Subilo lanza instancias ao momento — aínda precisan o atraso de arranque antes de servir.
Seguimento de obxectivo sobre a utilización; sen novo escalado cara arriba mentres aínda estean arrancando instancias. Desactivado = exactamente o mínimo.
Menor = máis marxe e máis custo. A utilización medida non pode superar o 100 %, así que unha flota saturada só crece paso a paso.
TTL máis longo = máis acertos, pero as respostas poden ser máis vellas (idade media ≈ TTL/2).
Carga as claves máis usadas durante 6 minutos (+12 % da caché por minuto) ao prezo de 600 consultas á base de datos/s extra.
Parte do 30 % de baixa prioridade (precarga, lotes, rastrexadores) rexeitada no balanceador de carga con «téntao de novo máis tarde».
A funcionalidade pesada engade 20 ms de CPU e unha consulta á base de datos por solicitude. Desactivado = degradación controlada.
Volve despregar a última versión boa nunha flota nova (5 min, facturada dúas veces) e despois cambia o tráfico. Se se preme de novo, reinicia a preparación; sen ningunha versión mala en vivo, só custa diñeiro.
| Taxa de consumo (1 h) | 0,0 × |
|---|---|
| Solicitudes | 1125 req/s |
| Instancias servindo | 10 |
| Instancias arrancando | 0 |
| Taxa de acertos da caché | 77 % |
| Utilización da base de datos | 19 % |
| Tráfico descartado | 0 % |
| Custo da flota | 4,00 $/h |
| Custo ata agora | 0,00 $ |
| Idade media das respostas na caché | 30 s |
| Tráfico na versión defectuosa | 0 % |
| Recomendacións dispoñibles | 100 % |
Ás 09:10 sae unha versión nova. O mes xa foi duro: só queda o 20 % do orzamento de erros. Minutos despois do despregamento salta a alerta de taxa de consumo. Protexe o orzamento.
Unha ligazón ao servizo difúndese rápido e agárdase un pico de tráfico nalgún momento desta mañá — ninguén sabe cando, nin de que tamaño. As novas instancias tardan hoxe 8 minutos en arrancar. Cando chegue, mantén baixos os erros e a latencia sen queimar diñeiro en capacidade ociosa.
Na punta do mediodía un script de mantemento baleira toda a caché. Cada solicitude vai agora á base de datos, dimensionada para o acerto habitual do 85 %. Devolve o servizo á normalidade sen sobrecargar a base de datos.
Todas as relacións que usa o simulador, coa súa fonte. As constantes marcadas como suposicións son calibracións 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]Suposición: o número de workers, os tempos de servizo, a capacidade da base de datos, o tamaño da caché, a velocidade de recheo, os prezos e a taxa de erros da versión defectuosa son valores ilustrativos para un servizo 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 os cuantís de servizo e de espera non é o p99 exacto da súa suma (pode quedar algo alto ou baixo); a cola trátase como estacionaria dentro de cada minuto porque as solicitudes tardan 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]Suposición: o número de workers, os tempos de servizo, a capacidade da base de datos, o tamaño da caché, a velocidade de recheo, os prezos e a taxa de erros da versión defectuosa son valores ilustrativos para un servizo 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]Suposición: o número de workers, os tempos de servizo, a capacidade da base de datos, o tamaño da caché, a velocidade de recheo, os prezos e a taxa de erros da versión defectuosa son valores ilustrativos para un servizo 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 instancesSuposición: o número de workers, os tempos de servizo, a capacidade da base de datos, o tamaño da caché, a velocidade de recheo, os prezos e a taxa de erros da versión defectuosa son valores ilustrativos para un servizo web de tamaño medio.Aleatoriedade: un xerador mulberry32 con semente; distribucións usadas — uniforme, exponencial (CDF inversa), normal (Box–Muller), Poisson (Knuth). A semente móstrase e pódese compartir.
Modelo educativo — non apto para decisións operativas. Os emprazamentos reais calibran cada constante segundo o seu propio equipamento e datos.