Вы на дзяжурстве па вэб-сэрвісе: балансіроўшчык нагрузкі перад паркам экзэмпляраў, кэш перад базай даных і мэта даступнасці 99,9 %. Кожную хвіліну мадэль лічыць затрымку ў чарзе, тайм-аўты, трапленні ў кэш і нагрузку на базу па падручнікавых формулах — і што каштуюць вашы рашэнні.
Ніжняя мяжа парка. Павелічэнне запускае экзэмпляры адразу — але ім усё роўна патрэбна затрымка загрузкі, перш чым абслугоўваць.
Адсочванне мэты па загрузцы; новага павелічэння няма, пакуль экзэмпляры яшчэ загружаюцца. Выкл. = роўна мінімум.
Ніжэй = больш запасу і больш кошту. Вымераная загрузка не можа перавысіць 100 %, таму насычаны парк расце толькі крок за крокам.
Даўжэйшы TTL = больш трапленняў, але адказы могуць быць старэйшыя (сярэдні ўзрост ≈ TTL/2).
Загружае гарачыя ключы 6 хвілін (+12 % кэша за хвіліну) коштам 600 дадатковых запытаў да базы/с.
Доля нізкапрыярытэтных 30 % (папярэдняя загрузка, пакетны, краулеры), якая адхіляецца на балансіроўшчыку нагрузкі з «паўтарыце пазней».
Цяжкая функцыя дадае 20 мс CPU і адзін запыт да базы на кожны запыт. Выкл. = плаўная дэградацыя.
Паўторна разгортвае апошнюю добрую зборку на свежым парку (5 хв, аплачваецца двойчы), а потым пераключае трафік. Паўторнае націсканне перазапускае падрыхтоўку; калі дрэнная зборка не працуе, гэта каштуе толькі грошай.
| Хуткасць выгарання (1 г) | 0,0 × |
|---|---|
| Запыты | 1125 req/s |
| Экзэмпляры, што абслугоўваюць | 10 |
| Экзэмпляры загружаюцца | 0 |
| Доля трапленняў у кэш | 77 % |
| Загрузка базы даных | 19 % |
| Скінуты трафік | 0 % |
| Кошт парка | 4,00 $/h |
| Кошт на сёння | 0,00 $ |
| Сярэдні ўзрост адказаў у кэшы | 30 s |
| Трафік на дрэннай зборцы | 0 % |
| Рэкамендацыі даступныя | 100 % |
Новая зборка выходзіць у 09:10. Месяц ужо быў цяжкім: засталося толькі 20 % бюджэту памылак. Праз некалькі хвілін пасля разгортвання спрацоўвае абвестка па хуткасці выгарання. Абараніце бюджэт.
Спасылка на сервіс хутка распаўсюджваецца, і сёння раніцай у нейкі момант чакаецца ўсплёск трафіку — ніхто не ведае, калі і наколькі вялікі. Сёння новыя экзэмпляры запускаюцца 8 хвілін. Калі ўсплёск прыйдзе, трымайце памылкі і затрымку нізкімі, не марнуючы грошы на прастойную магутнасць.
У поўдзень у піку скрыпт абслугоўвання ачышчае ўвесь кэш. Цяпер кожны запыт ідзе ў базу, разлічаную на звычайную долю трапленняў 85 %. Верніце сэрвіс, не перагрузіўшы базу.
Кожнае суадносіна, якое выкарыстоўвае сімулятар, з яго крыніцай. Пастаянныя, пазначаныя як дапушчэнні, — ілюстрацыйныя каліброўкі.
λ(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]Дапушчэнне: колькасць воркераў, часы абслугоўвання, ёмістасць базы, памер кэша, хуткасць запаўнення, цэны і доля памылак дрэннай зборкі — ілюстрацыйныя значэнні для вэб-сэрвісу сярэдняга памеру.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]Набліжэнне: сума квантыляў абслугоўвання і чакання — не дакладны p99 іх сумы (ён можа быць крыху вышэйшы або ніжэйшы); чарга лічыцца ўстойлівай у межах кожнай хвіліны, бо запыты займаюць мілісекунды.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]Дапушчэнне: колькасць воркераў, часы абслугоўвання, ёмістасць базы, памер кэша, хуткасць запаўнення, цэны і доля памылак дрэннай зборкі — ілюстрацыйныя значэнні для вэб-сэрвісу сярэдняга памеру.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]Дапушчэнне: колькасць воркераў, часы абслугоўвання, ёмістасць базы, памер кэша, хуткасць запаўнення, цэны і доля памылак дрэннай зборкі — ілюстрацыйныя значэнні для вэб-сэрвісу сярэдняга памеру.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 instancesДапушчэнне: колькасць воркераў, часы абслугоўвання, ёмістасць базы, памер кэша, хуткасць запаўнення, цэны і доля памылак дрэннай зборкі — ілюстрацыйныя значэнні для вэб-сэрвісу сярэдняга памеру.Выпадковасць: генератар mulberry32 з seed; выкарыстаныя размеркаванні — раўнамернае, экспаненцыяльнае (адваротная CDF), нармальнае (Box–Muller), Пуасона (Knuth). Seed паказваецца і яго можна перадаваць.
Навучальная мадэль — не для аперацыйных рашэнняў. Рэальныя аб'екты каліброўваюць кожную пастаянную пад сваё абсталяванне і даныя.