Du har vagten for en webtjeneste: en load balancer foran en flåde af instanser, en cache foran en database og et tilgængelighedsmål på 99,9 %. Hvert minut beregner modellen køforsinkelse, timeouts, cache-hits og databasebelastning ud fra lærebogsformler — og hvad dine beslutninger koster.
Bund for flåden. At hæve den starter instanser med det samme — de skal stadig bruge opstartsforsinkelsen, før de betjener.
Målfølgning på udnyttelse; ingen ny opskalering, mens instanser stadig starter. Fra = præcis minimum.
Lavere = mere luft og flere omkostninger. Målt udnyttelse kan ikke overstige 100 %, så en mættet flåde vokser kun trin for trin.
Længere TTL = flere hits, men svar kan være ældre (middelalder ≈ TTL/2).
Indlæser varme nøgler i 6 minutter (+12 % af cachen pr. minut) til en pris af 600 ekstra databaseforespørgsler/s.
Andel af de 30 % med lav prioritet (prefetch, batch, crawlere), der afvises ved load balanceren med “prøv igen senere”.
Den tunge funktion tilføjer 20 ms CPU og én databaseforespørgsel pr. request. Fra = kontrolleret nedgradering.
Udruller den sidste gode build på en ny flåde (5 min, faktureres dobbelt) og skifter derefter trafikken. Et nyt tryk genstarter forberedelsen; hvis ingen dårlig build er i drift, koster det kun penge.
| Burn rate (1 t) | 0,0 × |
|---|---|
| Requests | 1125 req/s |
| Instanser i drift | 10 |
| Instanser under opstart | 0 |
| Cache-hitrate | 77 % |
| Databaseudnyttelse | 19 % |
| Afvist trafik | 0 % |
| Flådens omkostninger | 4,00 $/h |
| Omkostninger indtil nu | 0,00 $ |
| Middelalder af cachede svar | 30 s |
| Trafik på det dårlige build | 0 % |
| Anbefalinger tilgængelige | 100 % |
Et nyt build udrulles kl. 09:10. Måneden har allerede været hård: kun 20 % af fejlbudgettet er tilbage. Minutter efter udrulningen udløses burn-rate-alarmen. Beskyt budgettet.
Et link til tjenesten spreder sig hurtigt, og en trafikbølge ventes på et tidspunkt i løbet af formiddagen — ingen ved hvornår eller hvor stor. Nye instanser skal i dag bruge 8 minutter på at starte. Når den kommer, skal du holde fejl og latenstid nede uden at brænde penge af på ledig kapacitet.
Ved middagsspidsen tømmer et vedligeholdelsesscript hele cachen. Hver request går nu til databasen, som var dimensioneret til den sædvanlige hitrate på 85 %. Få tjenesten tilbage uden at overbelaste databasen.
Alle sammenhænge, simulatoren bruger, med deres kilde. Konstanter markeret som antagelser 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]Antagelse: antal workers, servicetider, databasekapacitet, cachestørrelse, genopfyldningshastighed, priser og det dårlige builds fejlrate er illustrative værdier for en mellemstor webtjeneste.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ærmelse: at lægge service- og ventekvantilerne sammen er ikke den nøjagtige p99 af deres sum (den kan være lidt for høj eller lav); køen behandles som stabil inden for hvert minut, fordi forespørgsler tager 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]Antagelse: antal workers, servicetider, databasekapacitet, cachestørrelse, genopfyldningshastighed, priser og det dårlige builds fejlrate er illustrative værdier for en mellemstor webtjeneste.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]Antagelse: antal workers, servicetider, databasekapacitet, cachestørrelse, genopfyldningshastighed, priser og det dårlige builds fejlrate er illustrative værdier for en mellemstor webtjeneste.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 instancesAntagelse: antal workers, servicetider, databasekapacitet, cachestørrelse, genopfyldningshastighed, priser og det dårlige builds fejlrate er illustrative værdier for en mellemstor webtjeneste.Tilfældighed: en seedet mulberry32-generator; anvendte fordelinger — uniform, eksponentiel (invers CDF), normal (Box–Muller), Poisson (Knuth). Seed vises og kan deles.
Uddannelsesmodel — ikke til operative beslutninger. Rigtige anlæg kalibrerer hver konstant efter deres eget udstyr og data.