Параллелизм, ограничение частоты и зарезервированный параллелизм

Lambda масштабируется, запуская несколько параллельных выполнений функции — по одному на каждое одновременное событие. Когда одновременно поступают 100 запросов, Lambda запускает 100 параллельных экземпляров функции. AWS автоматически управляет базовой инфраструктурой. Ограничение параллелизма на уровне учётной записи по умолчанию составляет 1 000 параллельных выполнений в каждом регионе (мягкое ограничение, которое можно увеличить, отправив запрос на изменение квоты сервиса).

Параллелизм рассчитывается так: Параллелизм = количество запросов в секунду × средняя длительность в секундах. Если функция обрабатывает 500 запросов в секунду и каждый запрос занимает 0,2 секунды, требуется 100 параллельных выполнений. Понимание этой формулы помогает определить, достаточно ли ограничений вашей учётной записи и нужно ли запросить увеличение квоты до мероприятия с высокой нагрузкой.

Когда Lambda получает больше запросов, чем позволяет ограничение параллелизма, она ограничивает скорость обработки лишних запросов. При синхронных вызовах (например, через API Gateway) ограниченные запросы немедленно получают ошибку 429 TooManyRequestsException, которую должна обработать вызывающая сторона. При асинхронных вызовах (например, для событий S3) Lambda ставит события в очередь и повторяет попытки в течение 6 часов, после чего отправляет их в очередь недоставленных сообщений.

Зарезервированный параллелизм гарантирует определённое число параллельных выполнений для конкретной функции, резервируя их из общего пула учётной записи. Он выполняет две задачи: (1) гарантирует доступную ёмкость — у функции всегда будет доступно указанное число выполнений, даже если другие функции используют квоту учётной записи; (2) ограничивает параллелизм — функция никогда не превысит зарезервированное значение, что защищает последующие зависимости от перегрузки.

Важный сценарий для экзамена: функция Lambda записывает данные в базу RDS, ограничение подключений которой равно 50. Без контроля параллелизма Lambda могла бы масштабироваться до сотен параллельных выполнений и исчерпать все подключения к базе данных, из-за чего ошибки возникали бы для каждой функции. Установка зарезервированного параллелизма на уровне 40 гарантирует, что Lambda никогда не превысит 40 одновременных подключений к базе данных, защищая экземпляр RDS. Это критически важный подход для любой функции Lambda, обращающейся к сервису с ограниченным числом подключений.

Предварительно выделенный параллелизм заранее инициализирует заданное число сред выполнения Lambda, чтобы они были готовы отвечать немедленно без холодного запуска. Это особенно важно для API, чувствительных к задержке, где даже холодный запуск длительностью 100 мс неприемлем. За предварительно выделенный параллелизм взимается почасовая плата, даже когда среды простаивают, поэтому сочетайте его с автоматическим масштабированием, чтобы изменять выделенный уровень с учётом прогнозируемых моделей нагрузки.

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

Lambda не увеличивает параллелизм до максимального значения мгновенно. Существует ограничение всплеска на уровне учётной записи (начальная скорость масштабирования), которое зависит от региона: обычно это начальный всплеск в 3 000 выполнений, затем добавляется 500 выполнений в минуту до достижения лимита. Для приложений, ожидающих внезапных значительных скачков нагрузки (вирусный трафик, кратковременные распродажи), используйте предварительно выделенный параллелизм, чтобы заранее прогреть достаточное число сред и избежать ограничения скорости во время начального всплеска.

Контролируйте параллелизм Lambda с помощью следующих ключевых метрик CloudWatch:

• ConcurrentExecutions: текущее число работающих экземпляров
• Throttles: число вызовов с ограниченной скоростью (в исправной системе должно быть равно нулю)
• UnreservedConcurrentExecutions: общий пул нераспределённого параллелизма на уровне учётной записи
• ProvisionedConcurrencyUtilization: доля используемой предварительно выделенной ёмкости

Настройте оповещения для Throttles, чтобы получать уведомления до того, как ограничение скорости повлияет на конечных пользователей.

При проектировании систем, которые вызывают Lambda синхронно (API Gateway, прямые вызовы через SDK), реализуйте экспоненциальную задержку с добавлением случайности на стороне вызывающего приложения. В SDK AWS есть встроенная логика повторных попыток, но для Lambda за API Gateway необходимо самостоятельно обрабатывать ответы 429 в клиентском приложении. Для Lambda, запускаемой SQS, повторные попытки обрабатываются самим сервисом SQS; задайте подходящее значение максимального числа получений для исходной очереди и настройте DLQ для исчерпавших попытки сообщений.

Для потоков данных Kinesis и потоков DynamoDB параллелизм Lambda ограничен числом сегментов (Kinesis) или разделов (DynamoDB). Каждый сегмент или раздел обрабатывается ровно одним параллельным выполнением Lambda. Если у Вас 10 сегментов Kinesis, Lambda запускает для этого источника не более 10 параллельных выполнений. Поэтому проблемы с ограничением скорости для источников на основе потоков обычно решаются увеличением числа сегментов, а не повышением лимитов параллелизма.

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что зарезервированный параллелизм одновременно гарантирует и ограничивает параллельные выполнения функции, защищая последующие сервисы и обеспечивая доступность; предварительно выделенный параллелизм заранее инициализирует среды, устраняя холодные запуски для рабочих нагрузок, чувствительных к задержке; а ограничение скорости проявляется в виде ошибок 429 при синхронных вызовах и повторных попыток через очередь при асинхронных вызовах — отслеживайте его с помощью метрики CloudWatch Throttles. Далее мы рассмотрим слои Lambda и пакеты развёртывания для управления большими зависимостями.