Мне показалось, что это простой пример использования, когда я начинал, но все оказалось намного сложнее, чем я ожидал.
Проблема
У меня есть AWS SQS, действующая как очередь заданий, которая запускает рабочую AWS Lambda. Однако, поскольку рабочие лямбды совместно используют немасштабируемые ресурсы, важно ограничить число одновременно работающих лямбд (до примера) не более 5 лямбд, работающих одновременно.
Достаточно просто, согласно Управление параллелизмом для лямбда-функции
Зарезервированный параллелизм также ограничивает максимальный параллелизм для функции и применяется к функции в целом
Однако, установка свойства Reserved concurrency в 5, по-видимому, полностью игнорируется SQS, в моем случае свойство Messages in Flight в моем случае ближе к 20-30 одновременным выполнениям в зависимости от количества сообщений, помещенных в очередь.
Вопрос
Самое близкое решение, которое я нашел, - это использовать очередь SQS FIFO и установить для MessageGroupId значение произвольного выбора или чередования. между 1-5. Однако из-за неравномерной рабочей нагрузки это не является оптимальным, так как было бы лучше распределить параллелизм по фактической рабочей нагрузке, а не случайно.
Я также попытался использовать шаговые функции AWS в качестве Map-state имеет параметр MaxConcurrency, который, кажется, хорошо работает в небольших очередях заданий, но из-за того, что каждое состояние имеет ограничение ввода / вывода 32 КБ, в моем случае использования это было невозможно.
Кто-нибудь нашел лучшее или альтернативное решение? Есть ли другие способы использования Reserved concurrency?
Похожие
Вот несколько похожих вопросов, которые я нашел, но я думаю, что мой вопрос отличается, потому что Я не заинтересован в ограничении общего количества вызовов , и (хотя я сам не пробовал), я не могу понять, почему триггеры от S3 или Kinesis Steam ведут себя иначе, чем SQS .