Ügyeletes egy webszolgáltatásnál: egy terheléselosztó példányok flottája előtt, egy gyorsítótár egy adatbázis előtt, és 99,9 %-os rendelkezésre állási cél. Minden percben a modell tankönyvi képletekből számolja a sorbanállási késleltetést, az időtúllépéseket, a gyorsítótár-találatokat és az adatbázis-terhelést — és hogy mibe kerülnek a döntései.
A flotta alsó határa. Emelése azonnal indít példányokat — ezek kiszolgálás előtt még kivárják az indítási késleltetést.
Célkövetés a kihasználtságon; nincs új kiskálázás, amíg példányok még indulnak. Ki = pontosan a minimum.
Alacsonyabb = nagyobb tartalék és több költség. A mért kihasználtság nem haladhatja meg a 100 %-ot, ezért a telített flotta csak lépésenként nő.
Hosszabb TTL = több találat, de a válaszok régebbiek lehetnek (átlagos életkor ≈ TTL/2).
6 percig tölti a forró kulcsokat (percenként a gyorsítótár +12 %-a) 600 többlet adatbázis-lekérdezés/s árán.
Az alacsony prioritású 30 % (előtöltés, kötegelt, robotok) azon része, amelyet a terheléselosztó „próbálja később” üzenettel elutasít.
A nehéz funkció kérésenként 20 ms CPU-t és egy adatbázis-lekérdezést ad. Ki = kíméletes leépülés.
Újratelepíti az utolsó jó buildet egy friss flottán (5 perc, kétszer számlázva), majd átkapcsolja a forgalmat. Újbóli megnyomása újraindítja az előkészítést; ha nincs rossz build élesben, csak pénzbe kerül.
| Égési ráta (1 óra) | 0,0 × |
|---|---|
| Kérések | 1125 req/s |
| Kiszolgáló példányok | 10 |
| Induló példányok | 0 |
| Gyorsítótár-találati arány | 77 % |
| Adatbázis-kihasználtság | 19 % |
| Eldobott forgalom | 0 % |
| Flottaköltség | 4,00 $/h |
| Eddigi költség | 0,00 $ |
| A gyorsítótárazott válaszok átlagos életkora | 30 s |
| Forgalom a hibás buildön | 0 % |
| Elérhető ajánlások | 100 % |
09:10-kor új build kerül ki. A hónap már így is nehéz volt: a hibakeretből csak 20 % maradt. A telepítés után percekkel megszólal az égésiráta-riasztás. Védje a keretet.
A szolgáltatásra mutató link gyorsan terjed, és ma délelőtt valamikor forgalmi hullám várható — senki sem tudja, mikor és mekkora. Az új példányoknak ma 8 perc kell az induláshoz. Amikor megérkezik, tartsa alacsonyan a hibákat és a késleltetést anélkül, hogy pénzt égetne üresjáratú kapacitásra.
Déli csúcsban egy karbantartó szkript kiüríti a teljes gyorsítótárat. Minden kérés most az adatbázishoz megy, amelyet a szokásos 85 %-os találati arányra méreteztek. Állítsa helyre a szolgáltatást az adatbázis túlterhelése nélkül.
A szimulátor által használt minden összefüggés a forrásával. A feltevésként jelölt állandók szemléltető kalibrációk.
λ(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]Feltevés: a worker-számok, a kiszolgálási idők, az adatbázis kapacitása, a gyorsítótár mérete, a feltöltési sebesség, az árak és a hibás build hibaaránya szemléltető értékek egy közepes webszolgáltatáshoz.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]Közelítés: a kiszolgálási és várakozási kvantilisek összeadása nem az összegük pontos p99-e (kissé magas vagy alacsony lehet); a sort percenként belül állandósultnak tekintjük, mert a kérések ezredmásodpercekig tartanak.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]Feltevés: a worker-számok, a kiszolgálási idők, az adatbázis kapacitása, a gyorsítótár mérete, a feltöltési sebesség, az árak és a hibás build hibaaránya szemléltető értékek egy közepes webszolgáltatáshoz.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]Feltevés: a worker-számok, a kiszolgálási idők, az adatbázis kapacitása, a gyorsítótár mérete, a feltöltési sebesség, az árak és a hibás build hibaaránya szemléltető értékek egy közepes webszolgáltatáshoz.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 instancesFeltevés: a worker-számok, a kiszolgálási idők, az adatbázis kapacitása, a gyorsítótár mérete, a feltöltési sebesség, az árak és a hibás build hibaaránya szemléltető értékek egy közepes webszolgáltatáshoz.Véletlenszerűség: magolt mulberry32 generátor; a használt eloszlások — egyenletes, exponenciális (inverz CDF), normális (Box–Muller), Poisson (Knuth). A mag látható és megosztható.
Oktatási modell — nem működési döntésekhez. A valódi telephelyek minden állandót a saját berendezésükhöz és adataikhoz kalibrálnak.