В расчёте нагрузки использовали только средний RPS за час. Какой ключевой риск это создаёт?
Средний RPS скрывает кратковременные пики, поэтому система может быть рассчитана на нормальную нагрузку, но не справиться с реальным всплеском запросов. Это приводит к росту очередей, задержек, тайм-аутам и каскадному отказу зависимых компонентов.
Подходы к оценке нагрузки развивались из-за того, что усреднённые показатели плохо описывают работу интерактивных и распределённых систем. Для планирования ресурсов стали учитывать не только среднюю интенсивность запросов, но и пики, распределение задержек, длительность операций и ограничение пропускной способности отдельных компонентов.
Исходная проблема состоит в несовпадении между интервалом измерения и временем реакции системы. Среднее значение за час может выглядеть безопасным, хотя значительная часть запросов поступает за несколько минут.
Допустим, за час пришло 360 000 запросов. Средняя нагрузка равна 100 RPS, но если половина запросов пришла за первые пять минут, кратковременная нагрузка составила 600 RPS.
При расчёте только по среднему значению могут не хватить экземпляров приложения, соединений с базой данных, пропускной способности очереди или лимита внешнего сервиса. Запросы начинают накапливаться, время ожидания растёт, а новые запросы занимают ресурсы ещё дольше.
Нагрузку нужно описывать как временной ряд, а не одним числом. Минимальный набор включает средний RPS, пиковый RPS за выбранное окно, профиль распределения запросов по времени, доли операций разных типов и целевые показатели задержки.
Для каждой операции отдельно оценивают интенсивность и стоимость: чтение из кэша, запрос к базе данных, запись, обращение к внешнему сервису и фоновая обработка могут иметь совершенно разные ограничения. Затем проверяют самый узкий ресурс, потому что общая мощность приложения не помогает, если, например, база данных выдерживает меньше запросов.
Важно учитывать не только пропускную способность, но и конкуренцию запросов. Приближённо число одновременно выполняющихся операций связано с интенсивностью и временем их выполнения: чем выше RPS или дольше обработка, тем больше требуется активных соединений и памяти. Поэтому задержка должна рассматриваться вместе с нагрузкой, а не как независимый показатель.
Практический расчёт обычно строят для нескольких сценариев: обычная нагрузка, ожидаемый пик и стрессовый сценарий. Для каждого сценария задают запас, проверяют масштабирование и проводят нагрузочное тестирование с реалистичным распределением запросов.
Горизонтальное масштабирование снижает риск нехватки вычислительных ресурсов, но не устраняет ограничения базы данных, очередей, сетевых лимитов или внешних API. Большой запас повышает стоимость, а слишком маленький ухудшает устойчивость; поэтому запас выбирают с учётом стоимости отказа и требований к доступности.
Сервис уведомлений в среднем получал 80 RPS, поэтому команда оставила две копии приложения. Во время массовой рассылки нагрузка достигала 700 RPS в течение нескольких минут. Приложение начинало принимать запросы быстрее, чем успевало отправлять их во внешний провайдер, очередь росла, а задержки превышали допустимые значения.
Рассматривались три варианта. Постоянно держать большое число экземпляров было просто, но дорого и не решало ограничение провайдера. Увеличить только тайм-ауты было дёшево, но это лишь дольше удерживало занятые ресурсы. Добавить очередь, ограничитель скорости отправки, метрики глубины очереди и масштабирование потребителей оказалось сложнее, зато отделило приём запросов от внешнего ограничения.
Выбрали третий вариант: API быстро принимал задания, очередь сглаживала пик, а число потребителей регулировалось по её глубине и времени ожидания. Это не увеличило пропускную способность провайдера, но предотвратило перегрузку приложения и сделало задержку управляемой; для клиента отдельно зафиксировали допустимую задержку доставки.
1. Достаточно ли взять максимальный RPS за весь период наблюдений?
Нет. Единичный выброс может быть случайным измерительным артефактом или нерепрезентативным событием. Нужно определить рабочий пик, например высокий процентиль по фиксированному окну, отдельно анализировать известные события и дополнительно проверять стрессовый сценарий, который система обязана выдерживать.
Слишком длинное окно сглаживает всплески, а слишком короткое может переоценить мгновенный шум. Окно выбирают относительно времени реакции системы, периода масштабирования и длительности очереди.
2. Почему пикового RPS недостаточно для оценки базы данных?
Одинаковый RPS может создавать разную нагрузку: запросы отличаются сложностью, числом обращений к хранилищу, объёмом данных, долей записей и конфликтами блокировок. Поэтому для базы оценивают не только запросы от пользователей, но и внутренний fan-out — сколько операций хранения порождает один внешний запрос.
Например, 100 RPS к приложению могут превратиться в 1 000 запросов к базе, если один запрос выполняет десять обращений. Дополнительно проверяют соединения, CPU, диск, репликацию и задержки, иначе расчёт по внешнему RPS даст ложное ощущение запаса.
3. Как очереди меняют интерпретацию пиков нагрузки?
Очередь может временно сгладить пик, но не устранить дефицит производительности. Если средняя скорость поступления заданий во время периода выше скорости обработки, глубина очереди растёт; после пика система должна успеть её опустошить, иначе задержка будет накапливаться.
При проектировании задают максимальный размер очереди, политику переполнения, срок жизни задания и поведение при повторной обработке. Очередь повышает устойчивость к краткому всплеску, но добавляет задержку, требования к хранению сообщений и риск устаревания данных.