Автомасштабирование в облаке: что это и как выбрать подход

Нагрузка на сервис меняется постоянно — по часам, дням, сезонам. Держать инфраструктуру под пиковый трафик круглосуточно дорого, а масштабировать вручную — ненадёжно. Автомасштабирование (autoscaling) — механизм, при котором облако само добавляет или убирает вычислительные ресурсы в ответ на изменение нагрузки. Autoscaling входит в Cost Optimization Pillar в AWS Well-Architected Framework и помогает бороться с этим overspend. В этом материале разберём типы масштабирования, выбор метрик и cooldown, чек-лист перед запуском в production. А во второй части этой статьи сравним AWS, VK Cloud, Yandex Cloud и Selectel.

Что такое автомасштабирование и зачем оно нужно

Без автомасштабирования инженеры вручную добавляют серверы перед пиковыми нагрузками и выключают их, когда спрос падает. Это приводит к двум типичным проблемам:

• Overprovisioning — переплата за простаивающие ресурсы.
• Underprovisioning — деградация сервиса при нехватке мощности.
• Автомасштабирование снимает обе проблемы: платформа добавляет ресурсы при росте нагрузки и освобождает их при снижении.

Автоскейлинг даёт максимальный эффект в следующих сферах:

• e-commerce с сезонными пиками и распродажами;
• SaaS с многоарендной нагрузкой;
• медиа и стриминг с выраженными суточными циклами;
• ML-инференс и batch-обработка;
• API-шлюзы и публичные веб-сервисы.

Но есть и сферы, где его польза минимальна:

• внутренние корпоративные сервисы со стабильной нагрузкой;
• фиксированные batch-задачи по расписанию;
• монолитные системы, которые не умеют горизонтально масштабироваться.

Типы автомасштабирования

По направлению изменения ресурсов

Горизонтальное (scale-out / scale-in). Патформа добавляет или убирает виртуальные машины (инстансы), а нагрузка распределяется между несколькими экземплярами через балансировщик. Подходит для stateless-приложений: веб-серверов, API-шлюзов, воркеров очередей.

Вертикальное (scale-up / scale-down). Платформа увеличивает или уменьшает ресурсы (CPU, RAM) существующего инстанса. Используется для stateful-приложений и баз данных, которые сложно распараллелить. Однако у большинства провайдеров изменение конфигурации требует перезагрузки VM.

Чаще всего оптимальной получается связка: вертикальное масштабирование для базы данных и горизонтальное — для application-серверов.

По моменту срабатывания

Реактивное масштабирование работает по пороговым метрикам: например, если CPU превысил 70%, платформа добавляет инстанс. Такой режим поддерживают все крупные облачные провайдеры. Стандартное время запуска нового инстанса — 1–3 минуты, а технологии вроде AWS Warm Pools сокращают его до 30 секунд.

Предиктивное масштабирование использует ML-модели, обученные на исторических метриках, и поднимает ресурсы заранее. Это удобно для сервисов с хорошо предсказуемыми пиками: утренний трафик, вечерние распродажи, сезонные кампании. Встроенные сервисы предиктивного масштабирования есть зарубежных облачных провайдеров, российские провайдеры пока ограничиваются реактивным подходом.

Автомасштабирование в Kubernetes

В Kubernetes автоскейлинг реализован тремя отдельными механизмами, которые работают совместно.

• Horizontal Pod Autoscaler (HPA) масштабирует количество подов по метрикам CPU, памяти и кастомным метрикам, полученным через Prometheus Adapter.
• Vertical Pod Autoscaler (VPA) подбирает оптимальные значения requests/limits для контейнеров. Обычно его используют в режиме рекомендаций или с рестартом подов.
• Cluster Autoscaler (CA) добавляет или удаляет worker-ноды, когда подам не хватает ресурсов для размещения.

Все managed Kubernetes‑сервисы у крупных провайдеров поддерживают эти механизмы, но отличаются настройками по умолчанию: интервалом сканирования, задержкой scale-down, максимальным количеством нод в кластере. Для GPU-нагрузок и ML‑задач важно наличие отдельных node group с GPU и поддержка taints/tolerations в Cluster Autoscaler.

Как выбрать метрики масштабирования

CPU utilization — самая распространённая метрика автоскейлинга, но она не всегда отражает реальную нагрузку. Для веб‑приложений часто полезнее масштабироваться по количеству запросов в секунду (RPS) или времени ответа (latency). Для обработчиков очередей более показателен размер очереди.

Базовые ориентиры:

• CPU utilization — 50–70%, чтобы оставался запас на кратковременные всплески;
• память — 60–80%, с учётом кешей и возможных утечек;
• RPS на инстанс — определяйте по результатам нагрузочного тестирования;
• latency P95 — масштабирование включайте, когда P95 выходит за границы SLO
• длина очереди — для воркеров имеет смысл добавлять инстанс, если очередь растёт несколько тактов подряд.

Метрика должна линейно зависеть от нагрузки. Если CPU upstream‑сервиса упирается в I/O или внешний API, масштабироваться по CPU бесполезно, лучше ввести кастомную метрику бизнес‑уровня: RPS, глубина очереди, количество in-flight запросов.

Как выбрать метрики масштабирования

CPU utilization — самая распространённая метрика автоскейлинга, но она не всегда отражает реальную нагрузку. Для веб-приложений часто полезнее масштабироваться по количеству запросов в секунду (RPS) или времени ответа (latency). Для обработчиков очередей более показателен размер очереди.

Базовые ориентиры:

• CPU utilization — 50–70%, чтобы оставался запас на кратковременные всплески;
• память — 60–80%, с учётом кешей и возможных утечек;
• RPS на инстанс — определяйте по результатам нагрузочного тестирования;
• latency P95 — масштабирование включайте, когда P95 выходит за границы SLO;
• длина очереди — для воркеров имеет смысл добавлять инстанс, если очередь растёт несколько тактов подряд.

Метрика должна линейно зависеть от нагрузки. Если CPU upstream-сервиса упирается в I/O или внешний API, масштабироваться по CPU бесполезно, лучше ввести кастомную метрику бизнес-уровня: RPS, глубина очереди, количество in-flight запросов.

Кулдаун и стабилизационное окно

Кулдаун (cooldown) — пауза после события масштабирования, когда платформа не принимает новых решений о расширении (scale-out) или сжатии (scale-in). Стабилизационное окно — период наблюдения перед расширением, который защищает от распиливания ресурсов при кратковременных спадах нагрузки.

Кулдаун меньше 60 секунд провоцирует осцилляции: бесконечный цикл добавления и удаления инстансов.Кулдаун более 600 секунд замедляет реакцию на пиковую нагрузку.

Как уменьшить время запуска инстанса

Чем быстрее новый инстанс готов принимать трафик, тем полезнее автомасштабирование. Если мощности подъезжают уже после пика, от них мало толку. Вот лучше практики:

• используйте заранее собранные образы (AMI, snapshots) с предустановленным приложением;
• минимизируйте скрипты инициализации и выносите максимум логики в сборку образа;
• в Kubernetes уменьшайте Docker-образы и аккуратно настраивайте readiness-пробы, чтобы под начинал принимать трафик только когда готов;
• прогревайте JIT-компиляторы и кеши до того, как балансировщик начнёт отправлять запросы.

Чек-лист настройки автомасштабирования в production

• Перед запуском стоит пройтись по списку:
• Метрики привязаны к реальной бизнес-нагрузке, а не только к CPU по умолчанию: для веб-сервисов — RPS/latency, для воркеров — длина очереди.
• Заданы минимальное и максимальное количество инстансов: минимум два для отказоустойчивости, максимум — по бюджету × 1,5.
• Cooldown настроен асимметрично: быстрый scale-out (60–120 секунд) и более медленный scale-in (300–600 секунд).
• Health checks работают корректно, балансировщик не отправляет трафик на ещё неготовые инстансы.
• Образы собираются заранее, cloud-init не выполняет долгие установки пакетов при каждом запуске.
• Проведено нагрузочное тестирование: плавный рост нагрузки, имитация отказа инстанса, проверка поведения на максимуме.
• Настроены биллинг-алерты (SMS/email) при превышении бюджета — базовая защита от runaway-сценариев.
• Ограничен верхний предел scale-out, чтобы автомасштабирование не привело к шестизначному счёту за ночь.

Типичные ошибки

• Масштабирование по «среднему CPU кластера» вместо метрик, отражающих насыщение конкретного сервиса.
• Симметричный cooldown: одинаковые задержки для scale-out и scale-in приводят либо к осцилляциям, либо к слишком медленной реакции.
• Минимум в 1 инстанс: при отказе AZ сервис падает, безопаснее держать минимум 2 инстанса в разных зонах доступности.
• Отсутствие верхнего лимита: известны кейсы шестизначных счетов после взлома или багов, создающих фантомный трафик.
• Нет корректного graceful shutdown при scale-in — обрываются активные соединения и теряются задачи в очередях.
• Слишком агрессивный scale-in: система всё время на грани, любой краткий всплеск приводит к деградации.

Что дальше

Следующий шаг — выбрать провайдера. У AWS, VK Cloud, Yandex Cloud и Selectel автомасштабирование реализовано по-разному: где-то есть встроенные Auto Scaling Groups для VM, где-то — только вариант через Managed Kubernetes и API. Конкретные цифры (минимальный scan interval, поддержка Spot/Preemptible, SLA, особенности биллинга) разберём во второй части: сравнении всех четырёх провайдеров.