Dir sidd op Bereetschaft fir e Webservice: e Load Balancer virun enger Flott vun Instanzen, en Cache virun enger Datebank, an en Disponibilitéitsziel vun 99,9 %. All Minutt rechent de Modell Waardeschlaangverzögerung, Timeouts, Cache-Treffer an Datebankbelaaschtung aus Léierbuchformelen aus — a wat Är Decisiounen kaschten.
Ënnergrenz fir d'Flott. Eropsetzen start Instanzen direkt — si brauche awer nach d'Boot-Verzögerung, ier se bedéngen.
Zilverfolgung vun der Auslaaschtung; keng nei Hochskaléierung, solaang Instanzen nach booten. Aus = genee de Minimum.
Méi niddreg = méi Reserv a méi Käschten. Déi gemoosse Auslaaschtung kann 100 % net iwwerschreiden, also wiisst eng gesättegt Flott nëmme Schrëtt fir Schrëtt.
Méi laang TTL = méi Treffer, awer d'Äntwerte kënne méi al sinn (mëttlert Alter ≈ TTL/2).
Lued 6 Minutten laang heefeg Schlësselen (+12 % vum Cache pro Minutt) zum Präis vun 600 zousätzlechen Datebank-Ufroen/s.
Undeel vun de 30 % mat niddregem Prioritéit (Prefetch, Batch, Crawler), déi um Load Balancer mat „méi spéit nach eng Kéier probéieren“ ofgewise ginn.
De schwéiere Feature füügt 20 ms CPU an eng Datebank-Ufro pro Ufro derbäi. Aus = graduell Degradéierung.
Deployt de leschte gudde Build op engem frëschen Fleet nei (5 min, zweemol berechent), dann schalt et den Traffic ëm. Nach eng Kéier drécken fänkt d'Virbereedung nei un; ouni e schlechte Build am Live kascht et just Geld.
| Burn-Rate (1 h) | 0,0 × |
|---|---|
| Ufroen | 1125 req/s |
| Instanzen am Service | 10 |
| Instanzen, déi booten | 0 |
| Cache-Trefferquote | 77 % |
| Datebank-Auslaaschtung | 19 % |
| Ofgewise Traffic | 0 % |
| Flottekäschten | 4,00 $/h |
| Käschte bis elo | 0,00 $ |
| Mëttlert Alter vun den Cache-Äntwerten | 30 s |
| Traffic um schlechte Build | 0 % |
| Empfehlungen disponibel | 100 % |
Um 09:10 geet e neie Build eraus. De Mount war schonn haart: et sinn nëmmen nach 20 % vum Feelerbudget iwwreg. Minutten nom Deploy geet de Burn-Rate-Alarm lass. Schützt d'Budget.
E Link zum Service verbreet sech séier, an iergendwann haut de Moien gëtt eng Verkéiersspëtzt erwaart — keen weess, wéini, nach wéi grouss. Nei Instanze brauche momentan 8 Minutten, fir ze starten. Wann et kënnt, haalt Feeler a Latenz niddreg, ouni Geld fir ongenotzt Kapazitéit ze verbrennen.
An der Mëttesspëtz läscht e Wartungsskript de ganze Cache. All Ufro geet elo an d'Datebank, déi fir déi üblech Trefferquote vun 85 % dimensionéiert war. Bréngt de Service zréck, ouni d'Datebank ze iwwerlaaschten.
All Relatioun, déi de Simulator notzt, mat hirer Quell. Konstanten, déi als Annahme markéiert sinn, si Beispillkalibréierungen.
λ(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]Annahm: Worker-Zuelen, Servicezäiten, Datebankkapazitéit, Cache-Gréisst, Opfëllgeschwindegkeet, Präisser an d'Feelerrate vum schlechte Build sinn illustrativ Wäerter fir e mëttelgrousse Webservice.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]Approximatioun: d'Quantile vu Bedéngung a Waarden ze addéieren ass net de genaue p99 vun hirer Zomm (e kann e bëssen ze héich oder ze niddreg sinn); d'Schlaang gëtt a jidder Minutt als stabil behandelt, well Ufroe Millisekonne daueren.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]Annahm: Worker-Zuelen, Servicezäiten, Datebankkapazitéit, Cache-Gréisst, Opfëllgeschwindegkeet, Präisser an d'Feelerrate vum schlechte Build sinn illustrativ Wäerter fir e mëttelgrousse Webservice.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]Annahm: Worker-Zuelen, Servicezäiten, Datebankkapazitéit, Cache-Gréisst, Opfëllgeschwindegkeet, Präisser an d'Feelerrate vum schlechte Build sinn illustrativ Wäerter fir e mëttelgrousse Webservice.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 instancesAnnahm: Worker-Zuelen, Servicezäiten, Datebankkapazitéit, Cache-Gréisst, Opfëllgeschwindegkeet, Präisser an d'Feelerrate vum schlechte Build sinn illustrativ Wäerter fir e mëttelgrousse Webservice.Zoufall: e Mulberry32-Generator mat Seed; benotzt Verdeelungen — uniform, exponentiell (invers CDF), normal (Box–Muller), Poisson (Knuth). De Seed gëtt ugewisen a kann deelt ginn.
Edukativ Modell — net fir operationell Decisiounen. Richteg Anlagen kalibréieren all Konstant op hiren eegenen Equipement an hir eege Daten.