AWS Lambda, по-видимому, не очень доступен при вызове из SNS

Question

Я вызываю лямбда-обработку данных массовым образом, отправляя ~ 5k sns-запросов асинхронным способом.Это приводит к тому, что все запросы на sns попадают в очень короткое время.Что я замечаю, так это то, что моя лямбда, похоже, имеет ровно 5 тыс. Ошибок, а затем, похоже, «просыпается» и справляется с нагрузкой.

Я делаю что-то необычное в данном случае?Есть ли способ с этим бороться?

Answer 1

Я подозреваю, что это комбинация параллелизма и способа, которым лямбда соединяется с SNS.

Лямбда имеет значение только , поэтому хорош для автоматического масштабирования, чтобы справиться с скачками нагрузки.

Полную информацию можно найти здесь: (https://docs.aws.amazon.com/lambda/latest/dg/scaling.html),, но необходимо отметить, что

1. Существует лимит одновременного доступа к учетной записи, который вы можете попросить повысить. По умолчанию этонамного меньше, чем 5k, так что это ограничит возможность одновременного использования лямбды.
2. Существует жесткое ограничение масштабирования (+1000 экземпляров в минуту), что означает даже , если вам удалосьЧтобы убедить AWS разрешить ограничение параллелизма в 30 КБ, вам потребуется 30 минут постоянной нагрузки, прежде чем вы получите столько лямбд одновременно.

SNS не являетсяоснованный на потоке асинхронный вызов (https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html#supported-event-source-sns), поэтому вы видите много ошибок, так как каждый SNS пытается вызвать 5k лямбд, но только первые X (скажем, 1k) проходят, но они продолжают повторяться. Очередьзатем очищает концсрочно при вашем начальном пакете (обычно 1 Кб, в зависимости от вашего региона), + 1 Кб в минуту, пока вы не достигнете максимальной емкости.

Обратите внимание, что SNS повторяет попытки только три раза с интервалами (AWS немного схематично про интервалы,но он, вероятно, основан на retry: delay, который возвращает служба, поэтому должен быть приблизительно интеллектуальным);Я предлагаю вам настроить DLQ, чтобы убедиться, что вы не отбрасываете сообщения, потому что время для очистки очереди.

Хотя ваш шаблон не является плохим , кажется, что вы 'очень подвержены проблемам параллелизма, которые окружают лямбду.

Альтернативой является использование потокового источника событий (например, Kinesis), который обрабатывает в пакетах с установленным параллелизмом (например, 500 записей на лямбду, одновременноколичество осколков, а не 1: 1 с SNS), и ожидает обработки каждой партии перед обработкой следующей.