Сколько холодных стартов в минуту выдержит сервис: замер вместо веры в автоскейл

MAATRIX

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

Что на самом деле происходит при холодном старте

«Холодный старт» — это не запуск процесса per se, а последовательность шагов, каждый из которых стоит времени:

1. Планировщик находит место. Kubernetes или другой оркестратор должен решить, на какую ноду поставить новый под — если свободных ресурсов нет, сначала запускается масштабирование самого кластера нод (это отдельный и куда более медленный холодный старт, о нём ниже).
2. Тянется образ. Если слоя образа нет в локальном кэше ноды — например, нода новая или образ обновился — docker/containerd качает его из registry. Размер образа и скорость до registry напрямую определяют эту фазу.
3. Стартует контейнер и рантайм. JVM, Node.js, Python с тяжёлыми импортами (pandas, torch) — у каждого рантайма своя цена инициализации: JIT-прогрев, загрузка байткода, импорт модулей.
4. Приложение инициализируется. Открываются пулы соединений к БД, поднимаются health-check эндпоинты, иногда подгружаются конфиги из внешнего сервиса (Vault, Consul) — с ретраями, если сеть не сразу доступна.
5. Прогреваются кэши. Локальный in-memory кэш пуст, первые запросы идут «мимо» него в БД или в апстрим, что дополнительно нагружает бэкенд именно в момент, когда он и так под давлением.
6. Проходит readiness-проверка. Оркестратор не пускает трафик на под, пока readinessProbe не отработает нужное число раз подряд — это дополнительные секунды сверх фактической готовности.

Каждый шаг добавляет задержку, и они не параллелятся полностью — конкретные интервалы у ретраев и readiness-проверок вы задаёте сами, но сама последовательность шагов не переставляется. Итоговое время «от команды scale up до реального приёма трафика» у лёгкого stateless-сервиса на голом Go может укладываться в единицы секунд, а у сервиса с тяжёлой инициализацией (прогрев модели, JVM с большим classpath, множество миграций при старте) счёт может идти на десятки секунд и больше — конкретную цифру даёт только замер на вашем образе, здесь она у каждого своя.

Отдельно стоит холодный старт узла, если автоскейлер масштабирует не только поды, но и сами виртуальные машины (cluster autoscaler, node groups). Тогда к времени старта контейнера добавляется время создания VM, её загрузки, подключения к сети и вступления в кластер — это может быть на порядок дольше, чем старт пода на уже готовой ноде. Если у вас managed Kubernetes с автоскейлом нод — почитайте, во что это обходится по сравнению со своим k3s, холодный старт узла — часть этой цены.

Почему автоскейл не спасает от деградации при резком всплеске

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

Формализуем это простым неравенством. Пусть:

• λ(t) — скорость роста нагрузки (запросов в секунду в секунду);
• T_detect — время от начала роста до срабатывания правила автоскейла (зависит от периода опроса метрик и порога, например averageUtilization: 70 с окном в 60 секунд у HPA);
• T_cold — время холодного старта одного экземпляра до готовности принимать трафик;
• C_existing — запас мощности, который ещё держат текущие реплики на момент начала всплеска.

Если запас C_existing исчерпывается раньше, чем T_detect + T_cold истекут и новые реплики выйдут на readiness, — деградация неизбежна вне зависимости от того, сколько реплик в итоге поднимется. Автоскейл в этом случае отработает правильно с точки зрения конечного состояния (нужное число реплик появится), но с опозданием, которое пользователи уже почувствуют как 5хх и таймауты.

Практический вывод: скорость нарастания трафика важнее его абсолютного пика. Плавный рост за 10 минут в 5 раз автоскейл переживёт легко. Всплеск в 5 раз за 15 секунд — тот же прирост, но с точки зрения T_detect + T_cold это принципиально другая задача, и решается она не тюнингом порогов HPA, а держанием запаса тёплых экземпляров заранее.

Как измерить свой реальный T_cold

Не берите цифры холодного старта из блога вендора рантайма или из документации оркестратора — там измеряли на других образах, других нодах и других сетях до registry. Меряйте сами, на проде или на его точной копии:

# 1. Форсируем холодный старт: удаляем под и смотрим на события
kubectl delete pod <pod-name>
kubectl get events --sort-by=.lastTimestamp -w

# 2. Считаем разницу между Scheduled и Ready
kubectl get pod <new-pod-name> -o json | jq '.status.conditions'

Интересуют временные метки условий PodScheduled, Initialized, ContainersReady, Ready — разница между первым и последним и есть ваш T_cold для случая, когда образ уже в кэше ноды. Отдельно замерьте случай «холодной ноды» (без кэша образа) — удалите образ с ноды или заставьте scheduler выбрать свежую ноду в автоскейлируемой группе, разница между двумя сценариями обычно значительна.

Для нагрузочной части используйте инструмент, который умеет резко ступенчато поднимать RPS (не линейную рампу), — иначе вы не воспроизведёте именно тот сценарий, который ломает автоскейл:

# k6: скачок нагрузки со ступенями, а не плавная рампа
k6 run --stage 10s:50,10s:500,60s:500 loadtest.js

// loadtest.js — резкий скачок с 50 до 500 RPS за 10 секунд
export const options = {
  stages: [
    { duration: '10s', target: 50 },
    { duration: '10s', target: 500 }, // скачок — здесь и ломается автоскейл
    { duration: '60s', target: 500 },
  ],
};

Во время теста смотрите не на RPS и не на CPU агрегатов — смотрите на распределение латентности (p50/p95/p99) и на долю ошибок в окне холодного старта. Если у вас уже есть методика поиска реального порога отказа именно таким пошаговым нагружением — она пригодится здесь почти без изменений, я подробно писал про неё в статье про поиск порога отказа под нагрузкой.

Ключевая метрика, которую стоит вывести на дашборд по итогам таких тестов, — не «сколько реплик поднялось», а «сколько холодных стартов в минуту система способна поглотить без роста p99 и без ошибок». Это число зависит от T_cold конкретного образа, от throughput вашего registry (если стартует сразу десяток подов и все тянут образ параллельно — сеть до registry может стать узким местом сама по себе) и от того, насколько параллельно ваш планировщик готов запускать новые поды.

Теоретическая эластичность против практической

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

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

Pre-warming и минимальный пул тёплых экземпляров

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

• Минимальные реплики выше нуля. minReplicas в HPA или аналогичный параметр у serverless-платформы — самый простой рычаг. Если вы знаете, что трафик никогда не падает ниже условных 3 реплик, а minReplicas: 1 — вы каждый раз при малейшем росте выше базовой линии заново проходите холодный старт для второй и третьей реплики.
• Provisioned concurrency / pre-warmed pool — там, где платформа это поддерживает (AWS Lambda Provisioned Concurrency, аналоги у других serverless-провайдеров), вы платите за простаивающие тёплые экземпляры, чтобы не платить латентностью в момент всплеска. Это прямой обмен денег на предсказуемость — расчёт того, сколько стоит держать резерв, у меня разобран подробно и с цифрами по трём вариантам в статье про холодный, тёплый и горячий резерв.
• Расписание вместо реакции. Если пики предсказуемы (утро буднего дня, начало продаж, время рассылки) — поднимайте реплики заранее по cron/расписанию, а не ждите, пока метрика перейдёт порог. Реактивный автоскейл всегда будет опаздывать на T_detect + T_cold; проактивный — не опаздывает вообще, потому что стартует до события, а не после.
• Буфер выше среднего, а не впритык. Если базовая линия реплик держит нагрузку впритык к своему лимиту, у неё нет запаса C_existing на время реакции автоскейла — даже небольшой скачок сразу уходит в деградацию. Держите базовую линию с запасом 20–40% (ориентир, у вас будет своё число по итогам замеров), а не по факту «минимально достаточно для среднего трафика».
• Разделение холодных и горячих путей. Если часть функциональности (тяжёлая аналитика, экспорт отчётов) можно вынести в отдельный пул с более мягкими SLA по латентности — не держите её реплики тёплыми постоянно, экономьте именно там, а не на пути, где живёт основной пользовательский трафик.

Если вы понимаете, сколько ядер и памяти реально нужно под пиковую нагрузку — легче посчитать, сколько тёплых реплик держать постоянно; методика расчёта конфигурации под нагрузку разобрана отдельно в статье про расчёт конфигурации сервера под нагрузку.

Что сокращает T_cold без изменения архитектуры

Если резерв тёплых экземпляров по бюджету не вариант или недостаточен сам по себе, есть набор технических мер, которые уменьшают время самого холодного старта:

• Меньше образ — быстрее pull. Multi-stage build, минимальный base-образ (distroless/alpine вместо полного дистрибутива), удаление dev-зависимостей из финального слоя. Каждый лишний слой и каждый лишний мегабайт — это время скачивания образа на новую ноду.
• Локальный registry-кэш рядом с нодами или pull-through cache сокращают время фазы скачивания образа, особенно если ваш registry географически далеко от кластера.
• Ленивая инициализация тяжёлых зависимостей. Если приложение при старте синхронно грузит ML-модель, прогревает весь кэш или устанавливает соединения со всеми внешними сервисами разом — часть этого можно сделать асинхронно после того, как под уже прошёл readiness по базовым проверкам, а не блокировать старт полностью.
• Уменьшение окна readiness-проверки, если оно избыточно консервативное — но здесь важно не перегнуть в другую сторону и не пустить трафик на под, который ещё не готов по факту.
• Более быстрый рантайм или AOT-компиляция там, где это применимо — JIT-разогрев JVM или интерпретация Python при холодном старте стоят заметно дороже, чем запуск уже скомпилированного бинарника.

Каждая мера даёт вклад в секундах или их долях — не ждите, что сумма этих оптимизаций сама по себе закроет разрыв между скоростью роста трафика и скоростью реакции автоскейла при действительно резком всплеске. Это дополнение к резерву тёплых экземпляров, а не замена ему.

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