Máte pohotovosť pri webovej službe: load balancer pred flotilou inštancií, cache pred databázou a cieľ dostupnosti 99,9 %. Každú minútu model počíta čakacie oneskorenie, timeouty, zásahy cache a záťaž databázy podľa učebnicových vzorcov — a koľko vás stoja vaše rozhodnutia.
Spodná hranica flotily. Jej zvýšenie spustí inštancie hneď — stále však potrebujú oneskorenie štartu, kým začnú obsluhovať.
Sledovanie cieľového využitia; žiadne nové škálovanie nahor, kým sa inštancie ešte spúšťajú. Vypnuté = presne minimum.
Nižšie = viac rezervy a viac nákladov. Meraná využiteľnosť nemôže prekročiť 100 %, takže nasýtená flotila rastie len krok za krokom.
Dlhšie TTL = viac zásahov, ale odpovede môžu byť staršie (priemerný vek ≈ TTL/2).
Načítava horúce kľúče 6 minút (+12 % cache za minútu) za cenu 600 ďalších databázových dotazov za sekundu.
Podiel z 30 % s nízkou prioritou (prefetch, dávky, crawlery) odmietnutý na load balanceri s „skúste neskôr“.
Náročná funkcia pridáva 20 ms CPU a jeden databázový dotaz na požiadavku. Vypnuté = kontrolovaná degradácia.
Znovu nasadí posledný dobrý build na novej flotile (5 min, účtuje sa dvakrát), potom prepne prevádzku. Opakované stlačenie reštartuje prípravu; ak nie je živý žiadny zlý build, stojí to iba peniaze.
| Miera spaľovania (1 h) | 0,0 × |
|---|---|
| Požiadavky | 1125 req/s |
| Inštancie v prevádzke | 10 |
| Inštancie sa spúšťajú | 0 |
| Miera zásahov cache | 77 % |
| Využitie databázy | 19 % |
| Zahodená prevádzka | 0 % |
| Náklady na flotilu | 4,00 $/h |
| Doterajšie náklady | 0,00 $ |
| Priemerný vek odpovedí v cache | 30 s |
| Prevádzka na zlom builde | 0 % |
| Odporúčania dostupné | 100 % |
O 09:10 sa nasadí nový build. Mesiac už bol ťažký: zostáva len 20 % rozpočtu chýb. Minúty po nasadení sa spustí upozornenie na mieru spaľovania. Chráňte rozpočet.
Odkaz na službu sa rýchlo šíri a niekedy dnes ráno sa očakáva nápor prevádzky — nikto nevie kedy ani aký veľký. Nové inštancie sa dnes spúšťajú 8 minút. Keď príde, udržte chyby a latenciu nízko bez míňania peňazí na nevyužitú kapacitu.
Pri poludňajšom vrchole skript údržby vyprázdni celú cache. Každá požiadavka teraz ide do databázy, dimenzovanej na obvyklú mieru zásahov 85 %. Vráťte službu bez preťaženia databázy.
Každý vzťah, ktorý simulátor používa, aj s jeho zdrojom. Konštanty označené ako predpoklady sú ilustračné kalibrácie.
λ(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]Predpoklad: počty workerov, servisné časy, kapacita databázy, veľkosť cache, rýchlosť dopĺňania, ceny a chybovosť zlého buildu sú ilustračné hodnoty pre webovú službu strednej veľkosti.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]Aproximácia: súčet kvantilov obsluhy a čakania nie je presné p99 ich súčtu (môže byť o niečo vyššie alebo nižšie); front sa v rámci každej minúty považuje za ustálený, pretože požiadavky 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]Predpoklad: počty workerov, servisné časy, kapacita databázy, veľkosť cache, rýchlosť dopĺňania, ceny a chybovosť zlého buildu sú ilustračné hodnoty pre webovú službu strednej veľkosti.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]Predpoklad: počty workerov, servisné časy, kapacita databázy, veľkosť cache, rýchlosť dopĺňania, ceny a chybovosť zlého buildu sú ilustračné hodnoty pre webovú službu strednej veľkosti.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 instancesPredpoklad: počty workerov, servisné časy, kapacita databázy, veľkosť cache, rýchlosť dopĺňania, ceny a chybovosť zlého buildu sú ilustračné hodnoty pre webovú službu strednej veľkosti.Náhodnosť: generátor mulberry32 so seedom; použité rozdelenia — rovnomerné, exponenciálne (inverzná CDF), normálne (Box–Muller), Poissonovo (Knuth). Seed je zobrazený a dá sa zdieľať.
Vzdelávací model — nie na prevádzkové rozhodnutia. Skutočné zariadenia kalibrujú každú konštantu podľa vlastného vybavenia a údajov.