Je hebt storingsdienst voor een webdienst: een load balancer vóór een vloot instanties, een cache vóór een database en een beschikbaarheidsdoel van 99,9 %. Elke minuut berekent het model wachtrijvertraging, timeouts, cache-hits en databasebelasting uit leerboekformules — en wat jouw beslissingen kosten.
Ondergrens voor de vloot. Verhogen start meteen instanties — ze hebben nog steeds de opstartvertraging nodig voordat ze verwerken.
Target tracking op belasting; geen nieuwe opschaling zolang instanties nog opstarten. Uit = precies het minimum.
Lager = meer ruimte en meer kosten. Gemeten belasting kan niet boven 100 % komen, dus een verzadigde vloot groeit alleen stap voor stap.
Langere TTL = meer hits, maar antwoorden kunnen ouder zijn (gemiddelde leeftijd ≈ TTL/2).
Laadt hot keys gedurende 6 minuten (+12 % van de cache per minuut) ten koste van 600 extra databasequery’s/s.
Deel van de 30 % lage prioriteit (prefetch, batch, crawlers) dat bij de load balancer wordt geweigerd met “probeer het later opnieuw”.
De zware functie voegt 20 ms CPU en één databasequery per request toe. Uit = gecontroleerde degradatie.
Zet de laatste goede build uit op een verse vloot (5 min, dubbel gefactureerd) en schakelt daarna het verkeer om. Opnieuw drukken start de voorbereiding opnieuw; als er geen slechte build live is, kost het alleen geld.
| Burn rate (1 h) | 0,0 × |
|---|---|
| Requests | 1125 req/s |
| Instanties in dienst | 10 |
| Instanties die opstarten | 0 |
| Cache-hitratio | 77 % |
| Databasebelasting | 19 % |
| Afgeknepen verkeer | 0 % |
| Kosten van de vloot | 4,00 $/h |
| Kosten tot nu toe | 0,00 $ |
| Gemiddelde leeftijd van gecachete antwoorden | 30 s |
| Verkeer op de slechte build | 0 % |
| Aanbevelingen beschikbaar | 100 % |
Om 09:10 gaat een nieuwe build live. De maand is al zwaar geweest: er is nog maar 20 % van het foutbudget over. Enkele minuten na de deploy gaat de burn-rate-pagina af. Bescherm het budget.
Een link naar de dienst verspreidt zich snel en ergens vanochtend wordt een verkeerspiek verwacht — niemand weet wanneer, of hoe groot. Nieuwe instanties hebben vandaag 8 minuten nodig om te starten. Houd bij de piek fouten en latentie laag zonder geld te verbranden aan ongebruikte capaciteit.
Op de middagpiek leegt een onderhoudsscript de hele cache. Elke request gaat nu naar de database, die was gedimensioneerd op de gebruikelijke hitratio van 85 %. Krijg de dienst terug zonder de database te overbelasten.
Elk verband dat de simulator gebruikt, met bron. Constanten die als aanname zijn gemarkeerd, zijn illustratieve kalibraties.
λ(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]Aanname: aantallen workers, servicetijden, databasecapaciteit, cachegrootte, vulsnelheid, prijzen en het foutpercentage van de slechte build zijn illustratieve waarden voor een middelgrote webdienst.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]Benadering: het optellen van de service- en wachtkwantielen is niet de exacte p99 van hun som (die kan iets te hoog of te laag zijn); de wachtrij wordt binnen elke minuut als stabiel behandeld omdat verzoeken milliseconden duren.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]Aanname: aantallen workers, servicetijden, databasecapaciteit, cachegrootte, vulsnelheid, prijzen en het foutpercentage van de slechte build zijn illustratieve waarden voor een middelgrote webdienst.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]Aanname: aantallen workers, servicetijden, databasecapaciteit, cachegrootte, vulsnelheid, prijzen en het foutpercentage van de slechte build zijn illustratieve waarden voor een middelgrote webdienst.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 instancesAanname: aantallen workers, servicetijden, databasecapaciteit, cachegrootte, vulsnelheid, prijzen en het foutpercentage van de slechte build zijn illustratieve waarden voor een middelgrote webdienst.Willekeur: een mulberry32-generator met seed; gebruikte verdelingen — uniform, exponentieel (inverse CDF), normaal (Box–Muller), Poisson (Knuth). De seed wordt getoond en kan worden gedeeld.
Educatief model — niet bedoeld voor operationele beslissingen. Echte locaties stemmen elke constante af op hun eigen apparatuur en gegevens.