Почему capacity planning ломается на реальной нагрузке
Запас ёмкости редко расходуется равномерно. В кластере часть узлов держит высокую долю запросов по процессору и памяти, а часть простаивает из-за жёстких правил размещения и антиаффинности: заявки резервируются под сервис целиком, хотя фактическое потребление в разы ниже. Поэтому capacity planning по средним цифрам показывает «половина свободна», а перегрузка кластера наступает на конкретной группе узлов. Добавьте сюда задержку горизонтального масштабирования — от момента роста метрики до готовности новой реплики проходят минуты, и всё это время пиковая нагрузка обрабатывается тем же составом.
Пик почти никогда не растёт равномерно по всем метрикам. Первым упирается одно звено: пул соединений к базе, лимит одновременных запросов на стороне внешнего сервиса, запись на диск или очередь обработки. Дальше включается каскад — повторы запросов, выросшие таймауты, заполненные буферы, — и отказ из-за нехватки ёмкости выглядит как отказ всего контура, хотя исчерпан ровно один ресурс. Найти его заранее можно только по профилю потребления каждого сервиса в отдельности, а не по сводному графику.
В Kubernetes такие вещи видны через лимиты и заявки по объектам, но интерпретировать их нужно вместе с реальным трафиком.
Ручные прикидки отстают по двум причинам. Они опираются на усреднённые значения за прошлый период и не замечают смену профиля: новый клиентский сценарий, пакетную выгрузку, сезонный всплеск. И второе — ёмкость расширяют уже после деградации, в авральном режиме, без запаса на следующий пик.
Поэтому разбор начинаем с измерений: собираем профиль по сервисам, находим узкое место инфраструктуры и считаем, какой резерв нужен на пиковых сценариях. Дальше — как это закрывается.
Что даёт capacity planning на основе метрик нагрузки
Capacity planning без метрик — это ставка на пик: запас по мощности берут «на глаз», и в одном из двух сценариев он либо простаивает, либо заканчивается в самый неудобный момент. Опасен не рост нагрузки как таковой, а отказ класса «не хватило ресурса»: очередь переполняется, время ответа растёт ступенью, и потребители получают ошибки вместо предсказуемого замедления.
Основа — регулярный съём нагрузки: запросы в секунду по типам операций, глубина очередей, насыщение процессоров и диска, утилизация соединений к базам, время ответа на 95-м и 99-м перцентилях, прирост хранилища. Ряды складываем в Prometheus с длительным сроком хранения — так видно недели и сезоны, а не последний час. Из истории выводятся два числа, которых обычно не хватает: точка насыщения по каждой метрике и скорость приближения к ней.
Запас по мощности считаем от точки насыщения, а не от среднего потребления: например, треть до порога, за которым время ответа растёт нелинейно, и горизонт прогноза на два-три месяца вперёд. Модель роста строится на исторических окнах с учётом суточной и недельной сезонности — прогноз роста нагрузки даёт конкретную дату выхода на порог вместо абстрактного «скоро станет тесно». Расширение планируем заранее, с временем на закупку и проверку на тестовом контуре.
Второй эффект — предсказуемая деградация. Когда лимиты и квоты выставлены по измеренным порогам, перегрузка выглядит как рост задержек у неприоритетных операций, а не как отказ всего сервиса: критичные запросы проходят, фоновые отчёты и пересчёты притормаживаются первыми. Снижение простоя и планирование ресурсов идут не от того, что нагрузка перестала расти, а от того, что точка отказа известна заранее.
Подходы к планированию ёмкости: сравнение режимов
Выбор режима планирования ёмкости (capacity planning) — это компромисс между точностью прогноза и стоимостью ошибки. Ручной расчёт опирается на пиковые значения прошлых периодов и заложенный запас, прогноз по метрикам — на динамику нагрузки за несколько недель, автоматическое масштабирование реагирует на текущее состояние без участия человека. Ниже — где каждый режим работает предсказуемо, а где начинает мешать.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручной расчёт ёмкости | Стабильный профиль нагрузки, редкие релизы, понятный сезонный пик | Реагирует на рост с задержкой; запас закладывается приблизительно — либо простаивает, либо не хватает при скачке |
| Прогноз по историческим метрикам | Накоплены ряды по числу запросов, времени ответа и утилизации ресурсов | Точность падает на новых сценариях и аномалиях; модель нужно регулярно перепроверять |
| Автоматическое масштабирование | Резкие, но однотипные по форме пики; сервисы без состояния | Есть задержка реакции на всплеск; при грубых порогах уходит в качели и лишние переключения |
| Гибридная схема | Базовый уровень держат статически, верхнюю границу закрывает автоматика | Сложнее настраивать и сопровождать; нужны наблюдаемость и обоснованные пороги |
Чистые режимы на практике почти не встречаются: базу фиксируют по историческим метрикам, а верхнюю границу отдают автоматике под прогноз нагрузки. Что подойдёт в конкретном случае, зависит от профиля трафика и допустимого времени деградации — поэтому сравнение начинаем с замеров и разбора инцидентов, а не с выбора инструмента.
Как мы внедряем планирование ёмкости: этапы работ
Планирование ёмкости начинается не с закупки железа, а с инвентаризации того, что система уже рассказывает о себе. При формально настроенном сборе метрик прогноз опирается на шум: средние скрывают деградацию, а фоновые задачи маскируются под пики. Поэтому начинаем с достоверности данных и лишь затем переходим к расчётам.
- Аудит метрик. Сверяем, какие счётчики собираются, с какой частотой и глубиной хранения, где разрывы между сервисами. Метки с неконтролируемой кардинальностью в расчёт не берём.
- Профиль нагрузки. Раскладываем трафик на суточные и недельные циклы, отделяем пользовательские пики от фоновых задач — переиндексации, резервного копирования, тяжёлых отчётов. Иначе запас считают под нагрузку, к пику не относящуюся.
- Проверка гипотез. Сопоставляем пики с историей деградаций и оставляем метрики, которые действительно предсказывают проблему. Неподтверждённые гипотезы из модели убираем.
- Пороговые значения. Считаем по перцентилям, а не по средним, отдельно для чтения и записи, с запасом на потерю узла или зоны. Каждый порог привязан к действию: расширить, ограничить, отключить второстепенное.
- Прогон на живом профиле. Сверяем прогноз с фактом на историческом отрезке, затем повторяем пиковый сценарий на стенде. Расхождение выше допуска отправляет модель на пересчёт.
- Встраивание и передача. Пороги превращаем в оповещения и правила автомасштабирования, фиксируем владельца метрики и триггеры пересмотра. Отдаём регламент — команда ведёт планирование сама.
Что передаём на руки: артефакты и рабочие регламенты
Проект заканчивается не отчётом, а состоянием, в котором ваша команда меняет ёмкость без нас. Поэтому в передачу входит не только конфигурация, но и правила, по которым она живёт: что делать при росте нагрузки, кто пересматривает пороги, куда смотреть в первую минуту сбоя. Ниже — комплект, который остаётся у заказчика.
- Модель ёмкости — профили нагрузки по сервисам, выявленные узкие места, запас по каждому ресурсу и точка, после которой масштабирование обязательно.
- Схемы инфраструктуры — топология сервисов, потоки трафика, границы отказоустойчивости и места разделения зон.
- Настройка оповещений — правила с порогами по задержке, насыщению и доле ошибок, с разделением на «поднять дежурного ночью» и «разобрать утром».
- Регламент пересмотра ёмкости — периодичность, владелец цифр, метрики, которые запускают пересмотр, и форма фиксации решения.
- Документация по инфраструктуре — описание сервисов, параметров конфигурации и типовых операций, достаточное, чтобы новый инженер разобрался без пересказов.
- Инструкции для дежурной смены — сценарии на типовые отказы: что проверить, что перезапустить, когда эскалировать.
- Передача знаний команде — совместные разборы, записи встреч, выданные доступы и проверка на реальных задачах, а не на словах.
Через две-три недели после передачи проводим контрольный разбор: какие оповещения сработали вхолостую, какие пороги оказались низкими, что в инструкциях не совпало с реальностью — и правим это вместе с вашими инженерами.
Кейс: убрали перегрузку кластера и простой сервисов
До: деградация в часы пик
Сервис жил в Kubernetes-кластере, а лимиты и число реплик выставляли на глаз при первом запуске. В вечерние часы пик и во время рассылок утилизация узлов доходила до 95%, очередь запросов росла быстрее, чем срабатывало автомасштабирование, и шлюз начинал отдавать ошибки. За квартал — четыре инцидента по 40–90 минут и один внеплановый простой на несколько часов.
После: метрики и управляемый запас
Собрали историю метрик за несколько месяцев: запросы в секунду, время ответа по перцентилям, утилизация процессоров и памяти, глубина очередей. По ней построили прогноз с учётом суточного профиля и сезонных всплесков, а от прогноза — пороги расширения и правила упреждающего добавления реплик.
Запас сделали управляемым: под прогнозный пик резервируется фиксированная доля ёмкости, сезонное расширение запускается планово, до прихода нагрузки, а нагрузочные прогоны проверяют, что новый потолок выдержан. Простоя по ёмкости не было ни разу, инциденты в часы пик прекратились, загрузка узлов в пик держится ниже порога деградации. Расширение перестало быть аварийной работой — это плановая процедура с известным сроком.
Чем планирование по метрикам отличается от расчёта по пикам?
Расчёт по пиковой нагрузке исходит из одной точки: берут максимальный зафиксированный всплеск, умножают на коэффициент запаса и получают конфигурацию на весь период. Логика работает, пока пик остаётся репрезентативным. На практике это часто аномалия — разовая рассылка, шторм повторов, сканирование — и она замораживает ресурсы, которые остальное время простаивают.
Планирование по метрикам (capacity planning) начинается с распределения запросов: как нагрузка меняется по часам, дням недели и сезону, где средняя, где перцентили, насколько длинны и часты всплески. Модель отвечает не на вопрос «что если случится худшее», а на вопрос «какую долю времени мы держим целевое время отклика при таком профиле». Средняя нагрузка задаёт базовый размер, разброс — величину запаса, частота пиков — требуемую скорость реакции.
Дальше распределение считают по компонентам. Узкое место обычно одно — база, очередь, внешний сервис — и оно упирается в предел раньше остальных. Поэтому коэффициент запаса задают отдельно для каждого элемента, из его разброса и времени выхода на мощность: при автоматическом масштабировании за минуты запас нужен небольшой, при ручном добавлении за часы — заметно выше.
Отсюда разные решения. Пиковый расчёт отвечает «выдержим ли худший день» и почти всегда даёт избыточную конфигурацию, которую потом никто не пересматривает. Планирование по метрикам отвечает, сколько ресурсов нужно под ожидаемый профиль и в какой момент пора масштабироваться, — поэтому избытка меньше, а решение опирается на данные.
Технические сомнения вокруг планирования ёмкости
Планирование ёмкости опирается на измеренные данные, а не на догадки: прогноз строится по историческим рядам нагрузки с запасом на сезонность и пики. Отсюда и основные сомнения — насколько прогнозу можно верить и где взять метрики, если их пока мало.
Насколько точным получается прогноз?
Считаем интервальную оценку, а не одно число: базой идёт 95-й перцентиль, поэтому редкие пики не усредняются и не теряются. Первые недели модель калибруется по факту, дальше расхождение по пиковой нагрузке держится в пределах 10–15%, а прогноз на квартал вперёд пересчитывается по скользящему окну.
У нас почти нет метрик — с чего начать?
Хватает базового набора: загрузка вычислительных ресурсов, потребление памяти, время ответа, глубина очереди запросов, число одновременных соединений. Этого достаточно, чтобы увидеть узкое место и оценить запас. Если телеметрии нет совсем, работа начинается со сбора — модель на пустых данных бессмысленна.
Совместимо ли это с нашим мониторингом?
Существующую систему сбора не заменяем, а подключаемся к ней как потребитель метрик в стандартных форматах. Дашборды и правила оповещения остаются в привычном контуре, доступы выдаются по текущей ролевой модели — дублировать агенты не нужно.
Сколько занимает внедрение?
Первый прогноз по ключевым сервисам — через две-три недели после доступа к метрикам. Полный контур с автоматическим пересчётом и порогом оповещения о приближении к пределу — обычно полтора-два месяца. Порог срабатывает раньше деградации, поэтому запас на перегрузку остаётся.
Обсудим вашу задачу и вернёмся с оценкой и планом
Чтобы разбор шёл по фактам, а не по догадкам, пришлите исходные данные по нагрузке. Достаточно выгрузки метрик за несколько недель, схемы сервисов и описания пиковых окон — этого хватает, чтобы увидеть, где запас исчерпан и какой узел упрётся в потолок первым.
- метрики нагрузки в динамике: запросы в секунду, перцентили задержек, потребление процессора и памяти по каждому сервису;
- описание пиковых окон — акции, релизы, сезонные всплески — с датами и длительностью;
- схему сервисов и зависимостей: очереди, внешние вызовы, общие базы и кэши;
- целевые показатели: какой отклик считаете нормальным и какую долю отказов допускаете на пике;
- историю инцидентов: что падало, по какой причине, сколько заняло восстановление;
- планы роста: ожидаемый прирост трафика и сроки, к которым нужно быть готовыми;
- доступы только на чтение к метрикам и конфигурациям, если готовы дать их на этапе разбора.
Дальше мы собираем модель нагрузки, находим узкие места и считаем запас до предела. В план работ входят точки отказа, целевые значения по каждому сервису, очерёдность изменений и проверка на контролируемом пике в рабочем контуре — так capacity planning подтверждается измерениями до реального наплыва.
Опишите задачу — вернёмся с оценкой и планом, назовём состав работ и порядок запуска проекта.
