Вы дежурите по веб-сервису: балансировщик нагрузки перед парком экземпляров, кэш перед базой данных и цель по доступности 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), нормальное (Бокса — Мюллера), Пуассона (Кнут). Seed показан и им можно делиться.
Образовательная модель — не для принятия эксплуатационных решений. Реальные объекты калибруют каждую константу под своё оборудование и данные.