Naka-on-call ka para sa isang web service: isang load balancer sa harap ng fleet ng mga instance, isang cache sa harap ng database, at 99.9 % na availability objective. Kada minuto, kinakalkula ng modelo ang queueing delay, timeout, cache hit at load ng database mula sa mga pormula sa textbook — at kung magkano ang gastos ng iyong mga desisyon.
Sahig ng fleet. Ang pagtataas nito ay agad na naglulunsad ng mga instance — kailangan pa rin nila ng boot delay bago maglingkod.
Target tracking sa utilization; walang bagong scale-out habang nagbo-boot pa ang mga instance. Off = eksaktong minimum.
Mas mababa = mas maluwag at mas mahal. Hindi lalampas sa 100 % ang nasusukat na utilization, kaya ang saturated na fleet ay lumalaki lamang nang hakbang-hakbang.
Mas mahabang TTL = mas maraming hit, pero maaaring mas luma ang mga sagot (karaniwang edad ≈ TTL/2).
Naglo-load ng mga hot key sa loob ng 6 na minuto (+12 % ng cache kada minuto) kapalit ng 600 dagdag na database query/s.
Bahagi ng low-priority na 30 % (prefetch, batch, crawler) na tinatanggihan sa load balancer na may “subukan muli mamaya”.
Ang mabigat na feature ay nagdaragdag ng 20 ms na CPU at isang database query kada request. Off = graceful degradation.
Ide-deploy muli ang huling maayos na build sa bagong fleet (5 min, doble ang singil), pagkatapos ay ililipat ang traffic. Ang muling pagpindot ay uulit sa paghahanda; kung walang masamang build na live, pera lang ang magagastos nito.
| Burn rate (1 h) | 0.0 × |
|---|---|
| Mga request | 1125 req/s |
| Mga instance na naglilingkod | 10 |
| Mga instance na nagbo-boot | 0 |
| Cache hit rate | 77 % |
| Utilization ng database | 19 % |
| Traffic na binawasan | 0 % |
| Gastos ng fleet | 4.00 $/h |
| Gastos sa ngayon | 0.00 $ |
| Karaniwang edad ng mga naka-cache na sagot | 30 s |
| Traffic sa masamang build | 0 % |
| Available ang mga rekomendasyon | 100 % |
Lumalabas ang bagong build sa 09:10. Mabigat na ang buwan: 20 % na lang ng error budget ang natitira. Ilang minuto pagkatapos ng deploy, tumutunog ang burn-rate page. Protektahan ang budget.
Mabilis na kumakalat ang link papunta sa serbisyo at inaasahan ang traffic surge sa isang oras ngayong umaga — walang nakakaalam kung kailan, o gaano kalaki. Ngayon, 8 minuto ang kailangan ng mga bagong instance para magsimula. Pagdating nito, panatilihing mababa ang mga error at latency nang hindi sinusunog ang pera sa idle na kapasidad.
Sa rurok ng tanghali, binubura ng maintenance script ang buong cache. Pupunta na ngayon sa database ang bawat request, na idinisenyo para sa karaniwang 85 % hit rate. Ibalik ang serbisyo nang hindi ino-overload ang database.
Bawat ugnayang ginagamit ng simulator, kasama ang pinagmulan nito. Ang mga constant na minarkahang palagay ay mga halimbawang calibration.
λ(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]Palagay: ang bilang ng worker, service time, kapasidad ng database, laki ng cache, bilis ng refill, presyo at error rate ng masamang build ay mga halimbawang halaga para sa katamtamang laking web service.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]Pagtataya: ang pagdaragdag ng mga quantile ng service at paghihintay ay hindi ang eksaktong p99 ng kanilang kabuuan (maaaring bahagyang mataas o mababa); ang pila ay itinuturing na steady sa loob ng bawat minuto dahil millisecond lang ang inaabot ng mga request.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]Palagay: ang bilang ng worker, service time, kapasidad ng database, laki ng cache, bilis ng refill, presyo at error rate ng masamang build ay mga halimbawang halaga para sa katamtamang laking web service.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]Palagay: ang bilang ng worker, service time, kapasidad ng database, laki ng cache, bilis ng refill, presyo at error rate ng masamang build ay mga halimbawang halaga para sa katamtamang laking web service.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 instancesPalagay: ang bilang ng worker, service time, kapasidad ng database, laki ng cache, bilis ng refill, presyo at error rate ng masamang build ay mga halimbawang halaga para sa katamtamang laking web service.Randomness: isang seeded na mulberry32 generator; mga distribusyong ginamit — uniform, exponential (inverse CDF), normal (Box–Muller), Poisson (Knuth). Ipinapakita at maibabahagi ang seed.
Modelong pang-edukasyon — hindi para sa mga desisyon sa operasyon. Kina-calibrate ng mga tunay na site ang bawat constant sa sarili nilang kagamitan at datos.