Ви чергуєте за веб-сервісом: балансувальник навантаження перед парком екземплярів, кеш перед базою даних і ціль доступності 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 із зерном; використані розподіли — рівномірний, експоненційний (обернена CDF), нормальний (Бокса–Мюллера), Пуассона (Кнут). Зерно показано, і ним можна ділитися.
Навчальна модель — не для оперативних рішень. Реальні об’єкти калібрують кожну константу під власне обладнання та дані.