Автомасштабирование, которое масштабирует счёт: где ставить потолок

MAATRIX

Автомасштабирование продают как страховку от двух зол сразу: сервис не падает под нагрузкой и не переплачивает за простаивающие ресурсы в спокойные часы. Это правда — но только наполовину. Механизм, который умеет добавлять мощности, ничего не знает о том, что «добавлять бесконечно» — это тоже отказ, только не технический, а финансовый. Без явно заданного потолка автоскейлер одинаково старательно отработает и настоящий всплеск популярности, и цикл ретраев в сломанном клиенте, и волну ботового трафика — пока кто-то не откроет биллинг и не увидит цифру, которая не лезет ни в один прогноз. Дальше — о том, где именно ставить границу масштабирования, чтобы не потерять ни эластичность, ни бюджет.

Механика автомасштабирования: почему рост ресурсов не самоограничивается

Любой автоскейлер — будь то горизонтальный контроллер в оркестраторе контейнеров, группа автомасштабирования виртуальных машин или лимит параллелизма у бессерверной платформы — работает по одному циклу: собрать метрику, сравнить с целевым значением, изменить количество ресурсов, подождать, повторить. Метрикой может быть загрузка CPU, длина очереди запросов, число активных соединений или кастомный показатель вроде «запросов в секунду на под». Логика контроллера симметрична по природе: он одинаково реагирует и на рост, и на падение нагрузки, и по умолчанию у него нет понятия «это уже слишком много ресурсов для одного сервиса».

Отдельный случай — сервисы, где сам процесс масштабирования нелинеен и медленен (например, автомасштабирование ИИ-инференса на GPU, где новый экземпляр не готов принять трафик мгновенно): там к финансовому риску добавляется риск не успеть среагировать вовремя, но принцип потолка от этого не меняется — просто ставки на каждую единицу масштабирования выше.

Контроллер автомасштабирования не проверяет, оправдан ли рост нагрузки бизнес-логикой. Он не различает «пришли реальные тысячи новых пользователей» и «клиентский код зациклился в ретраях». С точки зрения метрики это одно и то же событие — рост очереди или загрузки, — и реакция будет одна: добавить мощности. Если верхняя граница не задана явно, единственным ограничителем становится физическая ёмкость пула ресурсов провайдера или системная квота на аккаунт — а это на порядки выше того, что разумно платить за один сервис.

Отдельно стоит проговорить асимметрию последствий. Слишком низкий потолок даёт деградацию сервиса — задержки, часть отказов, недовольных пользователей. Неприятно, но заметно почти сразу и обратимо за минуты после исправления настройки. Отсутствие потолка вообще даёт рост счёта, который может оставаться незамеченным часами или сутками — до ближайшей проверки биллинга, алерта по бюджету или конца расчётного периода. Первый сценарий самоограничивается пользовательскими жалобами, второй — нет: сервис продолжает «успешно» отвечать на каждый запрос, наращивая ресурсы, и именно эта видимая работоспособность маскирует проблему. Похожий эффект — когда счёт за облако вдвое вырастает без роста нагрузки: причина не всегда в автоскейлере, но диагностика строится по той же логике «разложить и найти конкретную статью расходов».

Три сценария, которые превращают эластичность в перерасход

Неконтролируемый рост ресурсов почти всегда укладывается в один из трёх сценариев — и разные сценарии требуют разной защиты.

Баг в собственном коде. Самый частый случай — не внешняя атака, а внутренняя ошибка: клиент без экспоненциальной задержки между ретраями, фоновая задача, попавшая в бесконечный цикл, сломанный кэш, из-за которого каждый запрос стал тяжёлым вместо лёгкого. Метрика нагрузки растёт по-настоящему — автоскейлер реагирует корректно с точки зрения своей логики, но корректная реакция на аномальный источник нагрузки — не то же самое, что полезная реакция.

Атака или аномальный трафик. DDoS на уровне приложения, скан уязвимостей ботами, паразитная нагрузка от чужого скрипта, случайно нацеленного на ваш эндпоинт — всё это порождает трафик, метрически неотличимый от органического роста. Автомасштабирование в такой ситуации не защищает от атаки, а спонсирует её: чем упорнее злоумышленник или бот, тем больше ресурсов вы поднимаете ему навстречу. Потолок автомасштабирования — последний рубеж, который сработает, даже если фильтрация на входе пропустила аномалию.

Легитимный, но непредвиденный всплеск. Вирусная публикация, упоминание в крупном канале, сезонный пик, распродажа — сценарий, где рост реален и его хочется обслужить. Здесь потолок не должен полностью блокировать масштабирование, но должен быть достаточно высоким, чтобы покрыть разумный пик, и достаточно конечным, чтобы не превратиться в чек на сумму, которую бизнес не готов заплатить за один вечер трафика. Разница между вторым и третьим сценарием часто видна только постфактум — по паттерну трафика (много уникальных источников против однообразного паттерна с малого числа адресов), а не в момент срабатывания автоскейлера.

Где физически ставить потолок: три уровня защиты

Ограничение масштабирования не сводится к одной настройке — оно эффективно только как связка из нескольких независимых рубежей. Если полагаться на один уровень, его обход или неправильная настройка снимает защиту целиком.

Первый уровень — потолок в самом контроллере автомасштабирования — обязателен и должен быть явным числом, а не значением по умолчанию платформы (значение по умолчанию у многих платформ либо отсутствует, либо равно очень большому числу, которое на практике означает «без ограничений»). Пример конфигурации для контейнерного оркестратора:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 3
  maxReplicas: 25
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Важны не только minReplicas/maxReplicas, но и блок behavior: ограничение темпа роста (не более 4 подов за 60 секунд) не даёт скейлеру долететь до потолка за один цикл опроса метрики — это снижает риск ложного срабатывания на шумовой всплеск и даёт время среагировать человеку, прежде чем расход ресурсов станет заметным.

Второй уровень — бюджетные алерты — не предотвращает масштабирование, но превращает «неизвестный рост счёта» в «известное событие с меткой времени». Разумная связка — несколько порогов: ежедневный алерт на превышение обычного дневного расхода, алерт на резкий скачок за короткое окно (расход за час выше, чем обычно за сутки), и финальный порог, при превышении которого автоматика может временно ограничить масштабирование до выяснения причины.

Третий уровень — периметр — фильтрует нагрузку до того, как она попадёт в масштабируемый контур. Ограничение частоты запросов на клиента или API-ключ и предохранитель (circuit breaker) перед тяжёлыми операциями снижают саму метрику, на которую реагирует автоскейлер, — то есть решают проблему на шаг раньше, чем потолок реплик.

Как посчитать разумное значение потолка

Число в maxReplicas не должно быть ни интуитивной догадкой, ни «максимум, который вообще возможен технически». Разумный подход — рассчитать его от бизнес-контекста, а не от технических возможностей платформы.

Отправная точка — базовая нагрузка (baseline): среднее и пиковое потребление ресурсов сервисом за последние несколько недель в обычном режиме. От базового пика считается коэффициент запаса — во сколько раз сервис реально может вырасти по легитимным причинам в разумный срок. Для большинства сервисов без выраженной сезонности разумный запас укладывается в диапазон от двух до четырёх–пяти кратного роста относительно обычного пика; для сервисов с известными пиковыми событиями (распродажи, релизы, анонсы) запас стоит считать отдельно под конкретное событие.

Дальше запас переводится в деньги, а не только в количество реплик: если единица масштабирования стоит понятную сумму в час, а maxReplicas умножается на неё — получается верхняя граница часового расхода сервиса при полностью выбранном потолке. Эту цифру полезно сверить с прямым вопросом: «Готовы ли мы заплатить эту сумму за час, если весь всплеск окажется багом или атакой?» Если ответ «нет» — потолок завышен, и его стоит снизить, даже ценой риска ограничить обслуживание легитимного пика.

Для большинства сервисов, не критичных к каждой секунде простоя, разумнее начинать с более консервативного потолка и поднимать его по факту наблюдаемых легитимных пиков, чем сразу закладывать щедрый запас «на всякий случай» — цена ошибки в меньшую сторону обратима за минуты, в большую сторону не обратима вовсе.

Полезная практика — периодически пересматривать потолок, а не устанавливать его один раз при запуске. Раз в квартал стоит сверять maxReplicas с актуальной базовой нагрузкой: потолок, разумный на старте, полгода спустя может быть либо тесным, либо неоправданно щедрым.

Что происходит, когда потолок достигнут — и как к этому подготовиться

Жёсткий потолок масштабирования гарантированно означает, что рано или поздно сервис его достигнет. Вопрос не «если», а «что произойдёт в этот момент» — и это стоит спроектировать заранее, а не выяснять по факту инцидента.

Худший вариант — сервис просто перестаёт отвечать части запросов без приоритизации: кто успел, тот и получил ответ. Лучший вариант — контролируемая деградация, при которой сервис осознанно решает, какие запросы обслужить, а какие отложить или отклонить:

• Очередь с приоритетом. Некритичные операции (фоновая аналитика, необязательные уведомления) уходят в очередь и обрабатываются по мере появления мощности, вместо конкуренции за ресурсы с критичным путём пользователя.
• Отклонение с понятным кодом ответа. Явный HTTP 429 вместо зависшего запроса — клиент может корректно обработать отказ и повторить позже, вместо того чтобы наращивать ретраи и усугублять нагрузку.
• Деградация функциональности вместо отказа. Отдать закэшированный или упрощённый ответ вместо полного пересчёта — там, где это приемлемо по продукту.
• Приоритизация по источнику. Платящие пользователи обслуживаются в первую очередь, анонимный и потенциально автоматизированный трафик — во вторую, если ёмкости не хватает на всех.

Стоит заранее подготовить процедуру ручного вмешательства на случай, если потолок достигнут аномалией: кто получает алерт, как быстро можно вручную поднять или снизить лимит, и по каким признакам отличить «нужно расширить потолок» от «нужно найти и остановить источник паразитной нагрузки». Без этой процедуры даже правильно настроенный потолок превращается в мигающий алерт, на который никто не смотрит.

Алерты и мониторинг поверх потолка: не пропустить момент

Потолок масштабирования — защита от бесконечного роста, но не сигнал о том, что рост вообще происходит. Полезная связка — мониторинг не только текущего состояния (сколько реплик поднято), но и темпа изменения, и близости к потолку.

Разумный набор алертов для сервиса с настроенным потолком масштабирования:

• Приближение к потолку. Оповещение при выборке 70–80% от maxReplicas — раньше, чем сервис упрётся в границу, чтобы у дежурного было время разобраться до начала деградации.
• Аномальная скорость роста. Алерт не на абсолютное значение, а на производную — число реплик выросло в разы за короткий интервал. Это отличает резкий скачок от плавного органического роста в течение дня.
• Долгое пребывание на потолке. Если сервис держится на максимуме дольше типичного дневного пика — повод проверить, легитимна ли нагрузка, а не считать ситуацию штатной только потому, что потолок сработал как задумано.
• Расход, оторванный от бизнес-метрик. Сравнение роста расходов с ростом бизнес-показателей (активные пользователи, заказы). Если расход растёт заметно быстрее — это красный флаг независимо от близости к потолку.

Частая ошибка — считать, что раз потолок настроен, мониторинг расходов больше не нужен. Потолок ограничивает максимум ущерба за единицу времени, но не говорит, сколько времени сервис провёл вблизи этого максимума: держась на 90% потолка сутками подряд из-за незамеченного бага, сервис обходится почти так же дорого, как без потолка вообще — просто с задержкой до момента, когда аномалию заметят на дашборде. Похожая ловушка разобрана в статье про пороги для алертов, которые не бесят: слишком грубый порог реагирует поздно, слишком чувствительный тонет в шуме.

Частые вопросы