Не приведет ли максимальный предел размера пакета SQS к более медленной обработке через Lambdas?

Question

Мне известно, что AWS позволил SQS быть одним из отображений источника событий для Lambdas. Я рад, что теперь это возможно, так как мне бы не приходилось каждые несколько секунд опрашивать очередь через задание cron. Однако представляется, что максимально возможное значение для batchSize ограничено 10. Насколько я понимаю, batchSize - это количество сообщений, которые один Lambda-вызов получит из очереди.

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

Если batchSize ограничен только 10 сообщениями на поиск, я предвижу несколько проблем, которые могут у меня возникнуть:

1. Это может фактически занять долгое время до sh обработки сообщений в очереди.

2. Мало того, что 10 сообщений на поиск медлительны, так как сообщения очень просты в обработке, обработка только 10 сообщений за один Lambda-вызов звучит немного расточительно, потому что, учитывая простоту того, что необходимо обработать сообщения, я уверен, что он может обработать как минимум несколько тысяч сообщений за один вызов Lambda.

3. Наличие только 10 сообщений на получение может также означать, что мне нужно выполнить больше операций записи в мою базу данных, поскольку каждое из этих сообщений необходимо вставить как запись в базу данных.

Обоснованы ли мои опасения в этом случае? Если да, могу ли я что-нибудь еще сделать с SQS и Lambdas, чтобы преодолеть эти проблемы?

Answer 1

В этом случае вам нужно разрешить лямбда-функции извлекать сообщения из очереди и обрабатывать их, а не лямбда-запуск по SQS. Вероятно, есть событие наблюдения за облаком, которое может вызвать лямбду для вас в зависимости от вашего варианта использования.

Обратите внимание, что SQS имеет ограничение не более 10 сообщений в одном go, но вы можете написать код, чтобы сделать его намного более эффективным.

Один из пакетов, который очень эффективен в is squiss-ts

В этом случае вы можете позволить вашей лямбда-функции работать в течение 15 минут (максимальное время) и позволить ей обрабатывать столько сообщений, сколько возможно. Идемпотентность - это ключ, когда вы создаете приложения такого типа, поэтому в случае, если сообщение не было обработано в этом цикле, оно будет обработано в следующем цикле.

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

Answer 2

Ваше предположение о пределе 10 верно .

Lambda раскручивает больше экземпляров для параллельной работы, если доступно больше сообщений. См. Масштабирование и обработка. Это означает, что если доступно 1000 сообщений, Lambda может ускорить 100 одновременных выполнений для быстрой обработки всех сообщений.

Как только функция лямбда обработает 10 сообщений партии, она продолжает обработку других партий. Поскольку лямбда-счета с интервалом в 100 мс тратят впустую минимальное время.

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