Что произойдёт с горизонтальным автоскейлингом, если метрика нагрузки поступает с заметной задержкой?
Задержка метрики превращает горизонтальный автоскейлинг в запаздывающую систему управления: он начинает реагировать на уже прошедшую нагрузку. В результате сервис может временно недополучать экземпляры, а после спада нагрузки — получить лишние реплики и начать колебаться вокруг целевого состояния.
Автоскейлинг появился как способ автоматически согласовывать вычислительную ёмкость с изменяющейся нагрузкой вместо постоянного ручного увеличения и уменьшения ресурсов. Горизонтальный подход решает задачу добавлением или удалением экземпляров приложения, что особенно удобно для stateless-сервисов.
Изначально такой механизм строится как замкнутый цикл управления: система измеряет нагрузку, сравнивает её с целевым значением и изменяет число реплик. Поэтому качество результата зависит не только от алгоритма масштабирования, но и от свежести и характера метрики.
Предположим, реальная нагрузка резко выросла, но система мониторинга передаст это значение автоскейлеру только через несколько минут. До получения сигнала кластер будет работать со старым числом реплик, поэтому увеличатся задержки, очередь запросов или количество ошибок.
После добавления экземпляров задержка может сохраняться из-за времени запуска контейнеров, прогрева кэшей и подключения к зависимостям. Если автоскейлер затем увидит устаревшую высокую метрику, он способен добавить больше реплик, чем действительно требуется, а после позднего спада нагрузки — так же запоздало начать уменьшение.
Автоскейлер обычно вычисляет новое число реплик на основании наблюдаемой метрики и целевого значения. Упрощённо, если средняя загрузка выше цели, число реплик увеличивается; если ниже — уменьшается. При задержке измерения это решение принимается не по текущему состоянию системы, а по её прошлому состоянию.
Основной риск — рассогласование между моментом возникновения нагрузки и моментом реакции. При всплеске происходит недомасштабирование, а при быстром спаде — временное переразмещение ресурсов. Если задержка сопоставима со временем запуска реплики или интервалом опроса, система может реагировать слишком поздно и затем компенсировать ситуацию чрезмерным масштабированием.
Задержка не всегда приводит к колебаниям: это зависит от частоты измерений, периода пересмотра решения, минимального и максимального числа реплик, скорости запуска экземпляров и правил стабилизации. Однако она повышает вероятность колебаний и делает автоскейлинг менее предсказуемым.
Практические меры зависят от природы нагрузки:
У ускорения реакции есть компромисс: слишком чувствительный автоскейлер создаёт лишние экземпляры из-за кратковременных всплесков. Слишком сильное сглаживание уменьшает шум, но увеличивает время недомасштабирования. Поэтому параметры выбирают с учётом SLA, стоимости ресурсов и времени запуска приложения.
Сервис обработки изображений получает задания через очередь. Метрика средней загрузки процессора обновляется с задержкой, поэтому во время рекламного всплеска очередь быстро растёт, хотя автоскейлер ещё видит нормальную загрузку существующих экземпляров.
Рассматривались два варианта. Масштабирование по CPU было простым и не требовало изменения модели мониторинга, но отражало уже начавшуюся обработку, а не накопившуюся потребность. Масштабирование по длине очереди лучше показывало объём необработанной работы, однако требовало определить целевое число заданий на один экземпляр и учитывать время их обработки.
Выбрали метрику длины очереди с ограничением максимального шага масштабирования и минимальным запасом реплик. В результате автоскейлер реагировал на рост фактического объёма работы раньше, чем на рост средней загрузки CPU, а ограничения не позволяли кратковременным всплескам вызвать чрезмерное расширение кластера.
Нет. Более частый опрос уменьшает только часть задержки между публикацией метрики и принятием решения. Если сама метрика агрегируется за длинное окно, данные поступают через промежуточные системы или новые экземпляры запускаются медленно, основная задержка сохраняется.
Кроме того, слишком частый пересмотр может сделать систему чувствительной к шуму. Нужно анализировать всю цепочку: возникновение нагрузки, сбор и агрегацию метрики, доставку значения, вычисление решения и готовность новой реплики.
Средняя загрузка может выглядеть приемлемой, пока запросы уже ждут в очереди, упираются в ограничение внешней базы данных или блокируются на другом ресурсе. Добавление реплик в такой ситуации не обязательно увеличит пропускную способность, а иногда лишь усилит нагрузку на общую зависимость.
Для выбора метрики нужно связать её с пользовательским результатом: задержкой, глубиной очереди, числом ожидающих заданий или пропускной способностью. Метрика должна быть не только доступной, но и причинно связанной с потребностью в дополнительных экземплярах.
Даже свежая метрика не устраняет инерцию системы. Новые экземпляры могут запускаться не одновременно, их производительность может меняться во время прогрева, а удаление реплик способно снова повысить нагрузку на оставшиеся.
Колебания также возникают при слишком агрессивных порогах и отсутствии стабилизации. Поэтому нужны ограничения минимального и максимального размера, правила задержки масштабирования вниз или вверх и проверка поведения на реальных профилях нагрузки, а не только на мгновенном значении метрики.