Блог

У меня есть 2 лямбда-функции и промежуточная очередь SQS. Первый лямбда-код отправляет сообщения в очередь. Затем второй лямбда-код имеет триггер для этой очереди с размером пакета 250 и окном пакета 65 секунд.

Я ожидаю, что второй лямбда-код будет запускаться партиями по 250 сообщений примерно каждые 65 секунд. Во втором Lambda я вызываю сторонний API, который ограничен 250 вызовами API в минуту (я получаю 250 токенов в минуту).

Я протестировал эту настройку с добавлением в очередь 32.000 сообщений, а вторая лямбда не собирала сообщения в пакетах, как ожидалось. Сначала он был выполнен для 15 тысяч сообщений, а затем не хватило токенов, поэтому он не обрабатывал эти сообщения.

Сторонний API основан на корзине токенов со скоростью заполнения 250 в минуту и максимальной емкостью 15 000. Ему удалось обработать первые 15 000 сообщений из-за емкости корзины, а затем не хватило емкости для обработки остальных.

Я не понимаю, что пошло не так.

Недоразумение, вероятно, связано с тем, как Lambda обрабатывает масштабирование. Всякий раз, когда событий больше, чем может обработать один контекст / экземпляр выполнения Lambda, Lambda просто создает больше контекстов / экземпляров выполнения для обработки этих событий.

Вероятно, произошло то, что Lambda увидела, что в очереди есть куча сообщений, и пытается работать с ними как можно быстрее. Он создал экземпляр Lambda для обработки первого события, а затем связался с SQS и попросил дополнительной работы. Когда он получил следующий пакет сообщений, первый экземпляр все еще был занят, поэтому он масштабировался и создал второй, который параллельно работал со вторым пакетом и т.д. и т.п.

Вот так вы в конечном итоге потратили свой бюджет токенов за несколько минут.

Вы можете ограничить количество функций, которые Lambda разрешено выполнять параллельно, используя зарезервированный параллелизм — вот документы для справки. Если вы установите для зарезервированного параллелизма значение 1, распараллеливания не будет, и только один лямбда-код будет разрешен для работы с сообщениями.

Однако это открывает вам другую проблему. Если для обработки сообщений одному лямбде требуется менее 60 секунд, Lambda вызовет его снова с другим пакетом как можно скорее, и вы можете снова превысить свой бюджет.

На данный момент относительно простым подходом было бы убедиться, что ваша лямбда-функция всегда занимает около 60 секунд, добавив режим ожидания на оставшееся время в конце.