Du har jour för en webbtjänst: en lastbalanserare framför en flotta av instanser, en cache framför en databas och ett tillgänglighetsmål på 99,9 %. Varje minut beräknar modellen kötid, timeouter, cacheträffar och databasbelastning med läroboksformler – och vad dina beslut kostar.
Golv för flottan. Höjer du det startas instanser direkt – de behöver ändå starttiden innan de betjänar.
Målföljning på utnyttjande; ingen ny utskalning medan instanser fortfarande startar. Av = exakt miniminivån.
Lägre = mer marginal och högre kostnad. Uppmätt utnyttjande kan inte överstiga 100 %, så en mättad flotta växer bara steg för steg.
Längre TTL = fler träffar, men svaren kan vara äldre (medelålder ≈ TTL/2).
Laddar heta nycklar i 6 minuter (+12 % av cachen per minut) till priset av 600 extra databasfrågor/s.
Andel av de lågprioriterade 30 % (förhämtning, batch, sökrobotar) som avvisas i lastbalanseraren med "försök igen senare".
Den tunga funktionen lägger till 20 ms CPU och en databasfråga per anrop. Av = kontrollerad nedgradering.
Distribuerar den senaste fungerande versionen på en ny flotta (5 min, faktureras dubbelt) och växlar sedan över trafiken. Ett nytt tryck startar om förberedelsen; utan någon dålig version i drift kostar det bara pengar.
| Förbränningstakt (1 h) | 0,0 × |
|---|---|
| Anrop | 1125 req/s |
| Instanser som betjänar | 10 |
| Instanser som startar | 0 |
| Cacheträffandel | 77 % |
| Databasens utnyttjande | 19 % |
| Strypt trafik | 0 % |
| Flottans kostnad | 4,00 $/h |
| Kostnad hittills | 0,00 $ |
| Medelålder på cachade svar | 30 s |
| Trafik på det dåliga bygget | 0 % |
| Rekommendationer tillgängliga | 100 % |
Ett nytt bygge går ut kl. 09:10. Månaden har redan varit tuff: bara 20 % av felbudgeten återstår. Några minuter efter driftsättningen går larmet för förbränningstakt. Skydda budgeten.
En länk till tjänsten sprids snabbt och en trafiktopp väntas någon gång i morse – ingen vet när eller hur stor. Nya instanser behöver 8 minuter för att starta idag. När den kommer: håll fel och latens nere utan att bränna pengar på overksam kapacitet.
Vid lunchtoppen rensar ett underhållsskript hela cachen. Varje anrop går nu till databasen, som dimensionerades för de vanliga 85 % träffarna. Få tillbaka tjänsten utan att överbelasta databasen.
Varje samband simulatorn använder, med källa. Konstanter markerade som antaganden är illustrativa kalibreringar.
λ(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]Antagande: antal arbetare, servicetider, databaskapacitet, cachestorlek, påfyllningshastighet, priser och det dåliga byggets felfrekvens är illustrativa värden för en medelstor webbtjänst.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]Approximation: att addera tjänste- och väntekvantilerna ger inte exakt p99 för deras summa (den kan bli något hög eller låg); kön behandlas som stationär inom varje minut eftersom förfrågningar 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]Antagande: antal arbetare, servicetider, databaskapacitet, cachestorlek, påfyllningshastighet, priser och det dåliga byggets felfrekvens är illustrativa värden för en medelstor webbtjänst.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]Antagande: antal arbetare, servicetider, databaskapacitet, cachestorlek, påfyllningshastighet, priser och det dåliga byggets felfrekvens är illustrativa värden för en medelstor webbtjänst.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 instancesAntagande: antal arbetare, servicetider, databaskapacitet, cachestorlek, påfyllningshastighet, priser och det dåliga byggets felfrekvens är illustrativa värden för en medelstor webbtjänst.Slumpmässighet: en seedad mulberry32-generator; fördelningar som används – likformig, exponentiell (invers CDF), normal (Box–Muller), Poisson (Knuth). Seeden visas och kan delas.
Pedagogisk modell – inte för operativa beslut. Verkliga anläggningar kalibrerar varje konstant efter sin egen utrustning och sina egna data.