AWS Lambda холодный старт как уменьшить время инициализации

[asyncmonk]

Столкнулся с проблемой холодных стартов в AWS Lambda. Функции на Node.js 20, используют TypeScript, бандл после esbuild — около 8 МБ. Среднее время холодного старта доходит до 2-3 секунд, что неприемлемо для API. Provisioned Concurrency выглядит как решение, но это плюс 30-40 долларов в месяц на каждую функцию, а их у меня штук 15. Кто как борется с этой проблемой без существенного увеличения счёта?

[vuenerd]

8 МБ бандл — это вот твоя первая проблема. esbuild должен давать 1-2 МБ для типичного API-хэндлера. Скорее всего тащишь лишние зависимости, проверь через esbuild --analyze. У меня после оптимизации импортов холодный старт упал с 2.5 до 600 мс.

[barbs]

Provisioned Concurrency не обязательно держать 24/7. Можно через EventBridge Scheduler включать только в рабочие часы — с 9 до 22 по нужному timezone. Стоимость падает раза в три. Плюс можно держать PC только для самых критичных функций, которые дёргаются первыми в цепочке.

[lost300z]

Попробуй Lambda SnapStart — для Java это официальная фича, для Node.js пока не завезли, но есть трюк с /tmp кешированием инициализированных объектов между вызовами. Если функция не scale-in нулевую реплику, повторный вызов идёт уже без инициализации. Ещё помогает держать память 512+ МБ — Lambda выделяет CPU пропорционально памяти, инициализация быстрее.

[seniorwarlock]

Если у тебя 15 функций и все нужны — возможно, стоит пересмотреть архитектуру. Часть из них, скорее всего, можно объединить или перевести на контейнер в ECS Fargate с постоянным инстансом для hot path, а Lambda оставить только для event-driven воркеров где задержка не критична.

[tiger71]

Конкретные цифры по оптимизации бандла: убери aws-sdk v2 и используй только нужные клиенты из @aws-sdk v3 (они tree-shakeable). Например, import { DynamoDBClient } from '@aws-sdk/client-dynamodb' вместо import AWS from 'aws-sdk'. Это одно действие часто режет бандл вдвое. Также externalize @aws-sdk в esbuild если деплоишь без слоя — runtime уже содержит SDK.

[lorenzinoarq]

У нас похожая ситуация была. В итоге пришли к гибриду: API Gateway + Lambda для редких эндпоинтов, и отдельный маленький Express-сервер на ECS для горячих маршрутов. Звучит сложнее, но на деле в разы дешевле Provisioned Concurrency на всё подряд.

[TerraformNerd]

Из того, что у нас сработало без доплаты за Provisioned Concurrency: во-первых, ленивая инициализация — тяжёлые клиенты создаём не на top-level, а внутри веток, где они реально нужны, у половины функций холодный путь стал заметно короче. Во-вторых, прогнал все функции через Lambda Power Tuning: sweet spot оказался на 1024 МБ — холодный старт упал почти вдвое против 512, а цена за вызов почти не изменилась, потому что биллинг по времени. Ну и arm64 вместо x86 — старт не лечит, но минус 20% к счёту просто за смену архитектуры.

[grahamd]

@tiger71, с советом externalize @aws-sdk поосторожнее: SDK в рантайме обновляет сам AWS, когда считает нужным, и версия может отличаться от той, на которой ты тестировал. Мы так словили изменение поведения клиента DynamoDB вообще без деплоя с нашей стороны — отлаживать такое больно. Сейчас бандлим нужные v3-клиенты сами: плюс 300-400 КБ к бандлу, зато сборка воспроизводимая. А вот про выпил aws-sdk v2 — подписываюсь, это самое жирное одиночное улучшение.

[misha12]

@barbs, схема с расписанием рабочая, мы так и живём, но один нюанс из практики: включай PC не ровно в 9, а минут за 20-30 до пика. Сами provisioned-инстансы тоже прогреваются не мгновенно, и первые утренние запросы в 9:00 у нас стабильно ловили полный холодный старт, пока не сдвинули включение на 8:30. И вторая половина твоего совета недооценена — PC только на первую функцию в цепочке закрывает 80% жалоб пользователей за маленькую долю полной цены.