Máte pohotovost u webové služby: load balancer před flotilou instancí, cache před databází a cíl dostupnosti 99,9 %. Každou minutu model z učebnicových vzorců počítá zpoždění ve frontě, vypršení časových limitů, zásahy cache a zátěž databáze a také to, co vás vaše rozhodnutí stojí.
Spodní hranice flotily. Zvýšení spustí instance hned, ale před obsluhou stále potřebují dobu startu.
Sledování cílového vytížení; dokud se instance ještě spouštějí, nepřidává se další. Vypnuto = přesně minimum.
Nižší = větší rezerva a vyšší náklady. Naměřené vytížení nemůže přesáhnout 100 %, takže nasycená flotila roste jen krok za krokem.
Delší TTL = více zásahů, ale odpovědi mohou být starší (střední stáří ≈ TTL/2).
Načítá často používané klíče 6 minut (+12 % cache za minutu) za cenu 600 dalších databázových dotazů za sekundu.
Podíl z 30 % provozu s nízkou prioritou (předběžné načítání, dávky, crawlery) odmítnutý na load balanceru hláškou „zkuste to později”.
Náročná funkce přidává 20 ms CPU a jeden databázový dotaz na požadavek. Vypnuto = řízená degradace.
Znovu nasadí poslední dobrou verzi na novou flotilu (5 min, účtuje se dvakrát) a pak přepne provoz. Opětovné stisknutí přípravu spustí znovu; pokud neběží žádná špatná verze, jen to stojí peníze.
| Rychlost spotřeby (1 h) | 0,0 × |
|---|---|
| Požadavky | 1125 req/s |
| Instance obsluhující provoz | 10 |
| Instance se spouštějí | 0 |
| Míra zásahů cache | 77 % |
| Vytížení databáze | 19 % |
| Zahozený provoz | 0 % |
| Náklady flotily | 4,00 $/h |
| Dosavadní náklady | 0,00 $ |
| Střední stáří odpovědí v cache | 30 s |
| Provoz na špatném buildu | 0 % |
| Doporučení dostupná | 100 % |
V 09:10 jde ven nový build. Měsíc už byl těžký: zbývá jen 20 % rozpočtu chyb. Pár minut po nasazení se spustí výstraha rychlosti spotřeby. Chraňte rozpočet.
Odkaz na službu se rychle šíří a někdy dnes dopoledne se čeká nápor provozu — nikdo neví kdy ani jak velký. Nové instance dnes potřebují 8 minut na start. Až přijde, držte chyby a latenci nízko, aniž byste plýtvali penězi na nevyužitou kapacitu.
V polední špičce skript údržby vyprázdní celou cache. Každý požadavek teď jde do databáze, která byla dimenzována na obvyklých 85 % zásahů. Obnovte službu, aniž byste databázi přetížili.
Každý vztah, který simulátor používá, se zdrojem. Konstanty označené jako předpoklady jsou ilustrativní kalibrace.
λ(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]Předpoklad: počty workerů, doby obsluhy, kapacita databáze, velikost cache, rychlost plnění, ceny a míra chyb špatného buildu jsou ilustrativní hodnoty pro středně velkou webovou službu.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]Aproximace: sečtení kvantilů obsluhy a čekání není přesné p99 jejich součtu (může vyjít o něco vyšší nebo nižší); fronta se v rámci každé minuty bere jako ustálená, protože požadavky trvají milisekundy.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]Předpoklad: počty workerů, doby obsluhy, kapacita databáze, velikost cache, rychlost plnění, ceny a míra chyb špatného buildu jsou ilustrativní hodnoty pro středně velkou webovou službu.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]Předpoklad: počty workerů, doby obsluhy, kapacita databáze, velikost cache, rychlost plnění, ceny a míra chyb špatného buildu jsou ilustrativní hodnoty pro středně velkou webovou službu.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 instancesPředpoklad: počty workerů, doby obsluhy, kapacita databáze, velikost cache, rychlost plnění, ceny a míra chyb špatného buildu jsou ilustrativní hodnoty pro středně velkou webovou službu.Náhodnost: generátor mulberry32 se seedem; použitá rozdělení — rovnoměrné, exponenciální (inverzní CDF), normální (Box–Muller), Poissonovo (Knuth). Seed je zobrazen a lze ho sdílet.
Vzdělávací model — nepoužívat pro provozní rozhodnutí. Skutečná zařízení kalibrují každou konstantu podle vlastního vybavení a dat.