Начнём с конкретного кейса: fintech-приложение на 50 Lambda-функциях. После 30-секундного таймаута клиенты жаловались на задержки. Аудит показал init duration до 800 мс из-за монолитного бандла весом 8 MB. Мы применили tree-shaking, lazy loading и перевели AWS SDK v2 на v3. Init duration упал до 90 мс, стоимость выполнения снизилась на 20%. Как этого добиться? Разберём методы.
Почему холодный старт Lambda критичен?
Холодный старт складывается из трёх фаз: создание контейнера (100–500 мс), инициализация runtime (50–200 мс) и выполнение init-кода. Первые две фазы управляются AWS, третья — ваша ответственность. Измерить задержку можно через CloudWatch Logs: строка Init Duration в отчёте. По данным AWS, init duration может достигать нескольких секунд при большом бандле.
| Фаза | Задержка (без оптимизации) | Оптимизировано | Ответственный |
|---|---|---|---|
| Container init | 100–500 мс | Не оптимизируется | AWS |
| Runtime init | 50–200 мс | 10–20% быстрее на arm64 | AWS + архитектура |
| Function init | 300–800 мс | 50–150 мс | Вы (разработчик) |
Типичная картина: Express-приложение с aws-sdk v2 весит 8–15 MB zip. После оптимизации — 500 KB–2 MB. Init duration падает с 500 мс до 80 мс. Однажды мы оптимизировали Lambda-функцию, обрабатывающую 100 тыс. запросов в месяц. Исходный бандл весил 8 MB, init duration — 700 мс. После tree-shaking и lazy loading бандл уменьшился до 1.2 MB, cold start — до 90 мс, а ежемесячная стоимость выполнения сократилась на 25%.
Какие методы снижают холодный старт?
Уменьшение размера бандла
Используйте esbuild с external: ["@aws-sdk/*"] и минификацией. AWS SDK v3 модульный — импортируйте только нужные клиенты:
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb';
const s3 = new S3Client({ region: process.env.AWS_REGION });
const dynamo = DynamoDBDocumentClient.from(new DynamoDBClient({}));
Lazy loading тяжёлых модулей
Переносите импорты редких зависимостей внутрь handler через динамический import():
export const handler = async (event) => {
if (event.type === 'generate-pdf') {
const { PDFDocument } = await import('pdf-lib');
const pdf = await PDFDocument.create();
}
};
Инициализация вне handler
Клиенты БД, переменные окружения, настройки — всё, что не меняется между вызовами, выносите из export const handler:
import { DynamoDBDocumentClient } from '@aws-sdk/lib-dynamodb';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
const client = new DynamoDBClient({
requestHandler: { requestTimeout: 3000, httpsAgent: { keepAlive: true, maxSockets: 50 } },
});
const dynamo = DynamoDBDocumentClient.from(client);
const TABLE_NAME = process.env.TABLE_NAME!;
export const handler = async (event) => {
const result = await dynamo.send(new GetCommand({ TableName: TABLE_NAME, Key: { pk: event.userId, sk: 'profile' } }));
return result.Item;
};
Сравнение методов оптимизации
| Метод | Влияние на init duration | Сложность | Когда применять |
|---|---|---|---|
| Уменьшение бандла | 50–80% | Низкая | Всегда |
| Lazy loading | 20–40% | Средняя | Тяжёлые редкие модули |
| RDS Proxy | 30–50% | Высокая | БД-интенсивные функции |
| Provisioned Concurrency | 100% (устранение cold start) | Низкая | Критичные эндпоинты |
| arm64 | 10–20% | Низкая | Новые функции |
Как правильно настроить подключения к базе данных?
Обычный пул соединений в serverless приводит к тысячам одновременных подключений при масштабировании. Решение — RDS Proxy (AWS-managed connection pooler) или HTTP-based базы вроде Neon. RDS Proxy поддерживает до 100 000 соединений, но экономит до 80% соединений по сравнению с прямыми подключениями. Настройка проста:
import { Pool } from 'pg';
const pool = new Pool({
host: process.env.RDS_PROXY_ENDPOINT,
max: 1,
idleTimeoutMillis: 0,
});
Когда оправдана Provisioned Concurrency?
Provisioned Concurrency держит N экземпляров Lambda прогретыми. Init выполняется заранее. Цена — оплата за idle. Используем только для критических эндпоинтов с требованием <100 мс latency. Настройка через SAM или Serverless Framework проста.
Архитектура: arm64 vs x86
Переключите архитектуру на Graviton2 (arm64) — это даёт 10–20% ускорение init и 20% экономии. Единственное ограничение: нативные модули .node требуют пересборки. Остальной TS/JS код работает без изменений.
Пошаговая инструкция: как мы оптимизируем cold start
- Аудит: измеряем init duration всех функций через CloudWatch Logs и Lambda Insights.
- Анализ бандла: определяем тяжёлые зависимости и дублирование.
- Уменьшение бандла: применяем esbuild с tree-shaking, выносим AWS SDK v3.
- Lazy loading: выносим редкие модули (PDF, изображения) за пределы init.
- Настройка RDS Proxy: для функций с прямыми подключениями к БД.
- Конфигурация Provisioned Concurrency: для критических эндпоинтов.
- Тестирование: сравниваем init duration до и после.
Сколько можно сэкономить?
В нашем проекте с 50 функциями init duration снизился с 800 мс до 90 мс, что уменьшило время выполнения на 87% и сократило ежемесячные расходы на Lambda на 30% (около $400 в месяц после оптимизации). Результат зависит от профиля нагрузки.Что входит в оптимизацию
- Аудит текущих функций: измерение init duration, анализ бандла
- Уменьшение размера пакета: esbuild, tree-shaking, вынос AWS SDK
- Оптимизация инициализации: lazy loading, кеширование клиентов
- Настройка RDS Proxy или альтернативных БД
- Конфигурация Provisioned Concurrency и автоскейлинг
- Рекомендации по архитектуре (arm64, переменные окружения)
Сроки и стоимость
Аудит и базовая оптимизация — от 1 дня. Полный цикл с RDS Proxy и Provisioned Concurrency — до 1 недели. Стоимость рассчитывается индивидуально после оценки объёма. Закажите консультацию — подготовим коммерческое предложение. Свяжитесь с нами для бесплатного аудита. Получите детальный анализ cold start ваших функций уже сегодня.