Холодный старт в serverless: причины и как его сократить
Продвинутое3 минРедакция Innovialabs
Коротко
Холодный старт — это задержка на создание нового экземпляра функции: загрузку кода, запуск runtime и инициализацию; его сокращают лёгкие runtime, маленький бандл, ленивая инициализация, provisioned concurrency и edge-среды.
Короткий ответ
Холодный старт — это дополнительная задержка, когда платформа запускает новый экземпляр функции, потому что готового свободного нет. Происходит это после периода простоя, при резком росте трафика и после деплоя новой версии. Следующие запросы к уже «тёплому» экземпляру обрабатываются быстро.
Сократить холодный старт можно с двух сторон: сделать инициализацию легче (runtime, размер кода, зависимости) и держать экземпляры готовыми заранее (provisioned concurrency, edge-среды).
Жизненный цикл холодного старта
- Выделение окружения. Платформа создаёт изолированную среду: контейнер, microVM или изолят.
- Загрузка кода. Скачивается пакет функции или образ контейнера.
- Запуск runtime. Стартует Node.js, Python, JVM, .NET и т.д.
- Инициализация вашего кода. Выполняется всё, что вне обработчика: импорты, подключение к базе, чтение конфигурации, создание SDK-клиентов.
- Обработка запроса. Только теперь вызывается сам обработчик.
Шаги 1–4 — это и есть холодный старт. Если затем приходят новые запросы, экземпляр переиспользуется и шаги 1–4 пропускаются, пока платформа его не выгрузит.
Что влияет на длительность
| Фактор | Как влияет |
|---|---|
| Runtime | Интерпретируемые и лёгкие runtime обычно стартуют быстрее, чем JVM или .NET без специальной оптимизации |
| Размер бандла | Чем больше кода и зависимостей, тем дольше загрузка и парсинг |
| Работа при инициализации | Тяжёлые импорты, подключения к БД, загрузка секретов замедляют старт |
| Объём памяти | У многих провайдеров с памятью растёт и выделенный CPU, поэтому инициализация может идти быстрее |
| Подключение к приватной сети | В некоторых конфигурациях добавляет задержку при создании окружения |
| Образ контейнера | Большие образы загружаются дольше, чем компактные пакеты |
Как сократить холодный старт
Уменьшите бандл. Используйте бандлер с tree-shaking, импортируйте только нужные модули, а не целый SDK. Удалите лишние зависимости.
Ленивая инициализация. Создавайте тяжёлые клиенты только тогда, когда они реально нужны, и переиспользуйте их между вызовами:
let db;
async function getDb() {
if (!db) db = await connect(process.env.DATABASE_URL);
return db;
}
export async function handler(event) {
const conn = await getDb();
// ...
}
Выберите подходящий runtime. Для критичных к задержке функций лёгкий runtime часто выигрывает. Если вы на JVM, изучите технологии вроде снимков состояния после инициализации (например, SnapStart в AWS Lambda) или нативной компиляции.
Provisioned concurrency. Платформа заранее держит заданное число инициализированных экземпляров. Холодных стартов для этого объёма нет, но вы платите за готовность, даже если запросов мало. Подходит для предсказуемого трафика и важных API.
Минимальное число экземпляров. На платформах с контейнерами (например, Cloud Run) можно задать минимум постоянно работающих экземпляров — это аналогичный компромисс между задержкой и стоимостью.
Edge runtime. Edge-среды на основе V8-изолятов стартуют значительно быстрее контейнеров, но имеют ограничения: не все API Node.js доступны, лимиты по времени и памяти строже.
Пинг-прогрев. Периодические запросы держат один экземпляр тёплым, но не помогают при всплеске трафика, когда нужны новые экземпляры. Это временная мера, а не решение.
Частые ошибки
- Подключаться к базе и загружать все секреты при каждом вызове.
- Тащить весь SDK ради одного метода.
- Включать provisioned concurrency для всех функций, а не только для критичных.
- Измерять задержку только на тёплых вызовах и не видеть реальной картины.