Нагрузка и запас прочности
Пик приходит за секунды, автомасштабирование отвечает за минуты. Отсюда следует всё остальное: запас прочности — это не абстрактная подушка «на всякий случай», а та мощность, которая держит пик в течение окна реакции. Если пик длится три минуты, а система разворачивается пять, автомасштабирование в этом инциденте не участвует вовсе.
Второе число, которое меняет разговор о ёмкости: при загрузке 80% время ответа впятеро больше времени обслуживания, при 95% — в двадцать раз. Последние десять процентов утилизации оплачиваются временем ответа по гиперболе, и правило «держать ниже 70–80%» — не суеверие, а точка, после которой кривая уходит вверх.
100 одновременных запросов — столько в работе у сервиса на 400 запросов в секунду при ответе 250 мс. Закон Литтла, одно умножение.
Около 5 минут — окно реакции автомасштабирования по официальному FAQ Cluster Autoscaler, сумма шести шагов.
0,90 — сигнальное значение допустимой доли деградации для крупного банка по Положению Банка России 850-П. Девять из десяти ожидаемых операций обязаны проходить даже в инциденте.
Что внутри
- Арифметика ёмкости: закон Литтла, формула очереди
R = S/(1−ρ)с тремя оговорками, закон Амдала и универсальный закон масштабируемости с точкой, после которой новые узлы делают хуже - Запас как время: из чего складываются минуты реакции автомасштабирования, сколько закладывать и почему Slack 4 января 2021 года упёрся не в процессоры, а в лимит открытых файлов и квоту провайдера
- Нагрузочное тестирование: четыре разных теста под одним словом, скоординированное умолчание и шесть вещей, которых тест не покажет никогда
- Российский контур: доля деградации и часы простоя в 850-П, стресс-тест риска в ГОСТ Р 57580.4-2022, мера ОДТ.7 приказа ФСТЭК России № 17 для государственных систем
- Управляемая деградация: метастабильные отказы и поддерживающая петля, квоты и классы критичности, бюджет повторов, таймаут по перцентилю и разброс запуска
- Два пика из практики: очередь Ticketmaster 15 ноября 2022 года и запись в первый класс 1 апреля, когда пик задан регламентом и известен за год
Цель надёжности назначают отдельно: методика расчёта доступности и бюджета ошибок — соседняя тема, и здесь она не выводится. Четыре золотых сигнала, USE и RED разбираются в лекции о наблюдаемости; механика одного узла, запросы и лимиты контейнера — в лекции об оркестрации; структура счёта за облако — в лекции о стоимости инфраструктуры.
Читатель — инженер эксплуатации. Половина примеров про арендованное облако, половина про своё железо в ЦОД: арифметика ёмкости от формы владения не зависит, а вот лимиты и сроки поставки мощности зависят сильно.
Закон Литтла: сколько запросов у вас в работе прямо сейчас
Начинать расчёт ёмкости надо не с нагрузочного теста, а с умножения. Джон Литтл доказал в 1961 году (Operations Research, 9(3), 383–387): среднее число заявок в системе равно интенсивности входа, умноженной на среднее время пребывания.
Ценность этого равенства в том, чего в нём нет. Оно верно без допущений о распределениях — ни про поток заявок, ни про время обслуживания ничего предполагать не надо. Требуется одна стационарность: система не должна в этот момент разгоняться или останавливаться.
Как это читается в эксплуатации
Число одновременно обрабатываемых запросов равно запросам в секунду, умноженным на время ответа.
400 × 0,25 = 100. Значит пул из 50 рабочих потоков этот поток физически не вывезет: очередь будет расти, пока не упрётся в таймаут. Обратное чтение того же равенства даёт требование к конфигурации: чтобы держать 400 запросов в секунду при 250 мс, нужно минимум 100 параллельных обработчиков плюс запас.
- Размер пула соединений к базе данных
- Глубина очереди, которую имеет смысл держать
- Объём памяти под буферы — столько запросов одновременно живут в процессе
Ни одно из этих чисел не требует стенда, генератора нагрузки и недели работы. Требуется два измерения, которые у вас уже есть.
L = λ × W было верным?Дальше нужен аккаунт
Прогресс и монеты сохранятся.