Две практики об одном: узнать пределы системы до того, как их найдут пользователи. Планирование ёмкости отвечает на вопрос «выдержим ли нагрузку через полгода и в чёрную пятницу», хаос-инжиниринг на вопрос «переживём ли отказ того, что обязательно когда-нибудь откажет».
Закон Литтла
L = λ × W: среднее число запросов в системе равно интенсивности поступления, умноженной на среднее время пребывания. 400 запросов в секунду по 0.25 секунды дают в среднем 100 одновременно обрабатываемых запросов. Отсюда размеры пулов потоков, соединений к базе, воркеров: если время ответа базы выросло вдвое, при том же трафике нужно вдвое больше соединений, иначе выстроится очередь.
Загрузка и задержка
Задержка растёт нелинейно с загрузкой. В простейшей модели очереди (M/M/1) время ответа равно времени обслуживания, делённому на (1 - загрузка):
| Загрузка | Во сколько раз время ответа больше времени обслуживания |
|---|---|
| 50% | 2 |
| 80% | 5 |
| 90% | 10 |
| 95% | 20 |
Реальные системы сложнее, но вывод тот же: держать ресурс на 95% «для экономии» значит получить огромные хвостовые задержки при малейшем всплеске. Поэтому цель загрузки обычно 50-70% для критичных путей.
Планирование ёмкости
- Измерить спрос: RPS, объём данных, число пользователей, сезонность (суточная, недельная, праздники, распродажи, 1 сентября, конец года).
- Измерить предложение: сколько выдерживает один экземпляр до нарушения SLO (нагрузочный тест), где узкое место (CPU, база, внешние лимиты).
- Прогноз: тренд роста плюс известные события.
predict_linearдля простых случаев, бизнес-план для запусков. - Запас: пик, а не среднее; N+1 или N+2 на отказ экземпляров; переживание отказа целой зоны (если зон три и одна упала, оставшиеся две должны выдержать пик).
- Пересмотр: раз в квартал и перед крупными событиями.
Автоскейлинг не отменяет планирования: он не масштабирует базу, лимиты внешних API, квоты облака, и ему нужно время на старт новых экземпляров.
Нагрузочное тестирование
- Load: ожидаемая пиковая нагрузка, проверка SLO.
- Stress: повышаем до отказа, ищем предел и то, как система ломается (плавно деградирует или падает каскадом).
- Soak (длительный): часы и сутки на рабочей нагрузке, ловит утечки памяти и соединений.
- Spike: резкий скачок, проверка автоскейлинга и очередей.
Инструменты: k6, Gatling, JMeter, Locust, Яндекс.Танк. Важно моделировать реальный профиль запросов и данных, а не долбить один эндпоинт.
Coordinated omission: генератор в закрытой модели (N виртуальных пользователей ждут ответа перед следующим запросом) при замедлении системы сам снижает нагрузку и не фиксирует задержки, которые испытали бы реальные пользователи. Для оценки задержек лучше открытая модель с постоянной интенсивностью (constant arrival rate в k6).
Хаос-инжиниринг
Эксперименты, которые проверяют устойчивость системы к реальным сбоям. Принципы (Principles of Chaos Engineering):
- Гипотеза о стабильном состоянии в терминах бизнес-метрик: «при отказе одного узла Redis доля успешных заказов не падает ниже 99.9%».
- Внедрять реальные события: отказ узла, задержка сети, потеря пакетов, недоступность зависимости, заполнение диска, рост нагрузки.
- Проводить в проде (когда созреете), потому что стенд не повторяет прод.
- Автоматизировать и запускать регулярно.
- Минимизировать радиус: начать с малого, иметь стоп-кран и критерии прерывания.
Начинают на стенде, затем на малой доле продового трафика. Инструменты: Chaos Mesh и LitmusChaos в Kubernetes, Toxiproxy для сетевых сбоев между сервисами, облачные сервисы внедрения сбоев. Исторический пример: Chaos Monkey в Netflix случайно выключал продовые инстансы, чтобы сервисы были готовы к этому всегда.
Game day: запланированное учение, где команда вручную проводит сбой и тренирует реакцию, раннбуки и коммуникацию.
Частые ошибки
- Планировать по средней нагрузке, а не по пику.
- Нагрузочный тест на пустой базе.
- Хаос-эксперимент без гипотезы, метрик и стоп-крана.
- Надеяться на автоскейлинг для базы данных.
- Не учитывать отказ зоны в расчёте запаса.
Что спросят на собесе
- Закон Литтла и как им пользоваться.
- Почему нельзя держать ресурсы на 95% загрузки.
- Как вы бы оценили, сколько серверов нужно на распродажу.
- Виды нагрузочного тестирования и coordinated omission.
- Принципы хаос-инжиниринга и как начать без вреда для пользователей.