Du har vakt for en nettjeneste: en lastbalanserer foran en flåte av instanser, en cache foran en database og et tilgjengelighetsmål på 99,9 %. Hvert minutt beregner modellen køforsinkelse, tidsavbrudd, cache-treff og databaselast fra lærebokformler – og hva beslutningene dine koster.
Gulv for flåten. Å øke det starter instanser med én gang – de trenger fortsatt oppstartsforsinkelsen før de betjener trafikk.
Målfølging på utnyttelse; ingen ny utskalering mens instanser fortsatt starter opp. Av = nøyaktig minimum.
Lavere = mer slingringsmonn og høyere kostnad. Målt utnyttelse kan ikke overstige 100 %, så en mettet flåte vokser bare trinn for trinn.
Lengre TTL = flere treff, men svarene kan være eldre (middelalder ≈ TTL/2).
Laster inn hete nøkler i 6 minutter (+12 % av cachen per minutt) til en pris av 600 ekstra databasespørringer/s.
Andel av de lavprioriterte 30 % (forhåndshenting, batch, crawlere) som avvises ved lastbalansereren med «prøv igjen senere».
Den tunge funksjonen legger til 20 ms CPU og én databasespørring per forespørsel. Av = kontrollert nedgradering.
Setter ut siste gode build på en fersk flåte (5 min, fakturert to ganger), og bytter deretter trafikken over. Trykker du igjen, starter forberedelsen på nytt; uten en dårlig build i drift koster det bare penger.
| Forbrenningsrate (1 t) | 0,0 × |
|---|---|
| Forespørsler | 1125 req/s |
| Instanser i drift | 10 |
| Instanser som starter opp | 0 |
| Cache-treffrate | 77 % |
| Databaseutnyttelse | 19 % |
| Trafikk kastet | 0 % |
| Flåtekostnad | 4,00 $/h |
| Kostnad så langt | 0,00 $ |
| Middelalder på cachede svar | 30 s |
| Trafikk på det dårlige bygget | 0 % |
| Anbefalinger tilgjengelige | 100 % |
Et nytt bygg slippes kl. 09:10. Måneden har allerede vært hard: bare 20 % av feilbudsjettet er igjen. Minutter etter utrullingen utløses varselet om forbrenningsrate. Beskytt budsjettet.
En lenke til tjenesten sprer seg raskt, og en trafikkbølge ventes en gang denne morgenen — ingen vet når eller hvor stor. Nye instanser trenger 8 minutter på å starte i dag. Når den kommer, hold feil og ventetid nede uten å brenne penger på ledig kapasitet.
På middagstoppen tømmer et vedlikeholdsskript hele cachen. Hver forespørsel går nå til databasen, som ble dimensjonert for den vanlige treffraten på 85 %. Få tjenesten tilbake uten å overbelaste databasen.
Hver sammenheng simulatoren bruker, med kilde. Konstanter merket som antakelser er illustrative kalibreringer.
λ(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]Forutsetning: antall arbeidere, tjenestetider, databasekapasitet, cache-størrelse, påfyllingshastighet, priser og feilraten til det dårlige bygget er illustrerende verdier for en middels stor nettjeneste.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]Tilnærming: å legge sammen kvantilene for tjeneste og ventetid er ikke den eksakte p99 av summen deres (den kan være litt for høy eller lav); køen behandles som stabil innenfor hvert minutt fordi forespørsler tar millisekunder.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]Forutsetning: antall arbeidere, tjenestetider, databasekapasitet, cache-størrelse, påfyllingshastighet, priser og feilraten til det dårlige bygget er illustrerende verdier for en middels stor nettjeneste.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]Forutsetning: antall arbeidere, tjenestetider, databasekapasitet, cache-størrelse, påfyllingshastighet, priser og feilraten til det dårlige bygget er illustrerende verdier for en middels stor nettjeneste.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 instancesForutsetning: antall arbeidere, tjenestetider, databasekapasitet, cache-størrelse, påfyllingshastighet, priser og feilraten til det dårlige bygget er illustrerende verdier for en middels stor nettjeneste.Tilfeldighet: en seedet mulberry32-generator; fordelinger som brukes — uniform, eksponentiell (invers CDF), normal (Box–Muller), Poisson (Knuth). Seeden vises og kan deles.
Pedagogisk modell — ikke for operative beslutninger. Reelle anlegg kalibrerer hver konstant mot eget utstyr og egne data.