Проблемы использования AWMS Lambda chain

Context: I have a pipeline of 6 lambda functions (chained together), triggered by an SNS notification which is generated whenever a file lands on S3. This pipeline essentially takes the file(few GBs), filters it (Spark cluster is created to run the job, then deleted at the end), and inserts it into a DB. Lambdas are orchestrating the flow.

Issues: If one Lambda fails, the chain breaks hence no effective failure handling. Secondly, we experience timeouts if a polling/computation takes longer than 5 minutes, so no effective retry. It takes a long time to test/debug an issue if a lambda fails. Also there is no visibility, say for example how many jobs failed and how many passed? we dont know. Getting a bunch of SNS notifications on email is not very effective/helpful. If the chain breaks, we cannot perform cleanup operations like deleting SPark cluster or housekeeping steps.

My Questions: Is AWS Step Functions a good choice for solving the above issues? When would you not use a Step Function service? If you cannot invoke Step Function through SNS, then what would be the best way to call it whenever a file lands on S3? Feel free to share any other approach to easily and effectively tackle this usecase.

2

2 ответы

Я использую лямбда в ответ на объекты, появляющиеся на ведрах S3. Для меня в моем конкретном случае использования есть около 600 триггеров в день. Я написал наши лямбда-функции, чтобы использовать их stdout в качестве их файла журнала, записывая все ключевые события в стандартную версию в полуструктурированном текстовом предложении, смешанном с парами ключ/значение для значений данных, а затем подавать журналы облачного просмотра в splunk.

Вот что я нашел ...

  1. Lambdas будет (иногда) срабатывать несколько раз для одного и того же объекта.
  2. Lambdas будет (иногда) работать значительно дольше, чем обычно.
  3. Чтобы увидеть/диагностировать проблемы, вызванные одновременными вызовами, которые мешают друг другу, веб-консоль AWS этого не делает. Вам нужен инструмент, похожий на splunk.

Однако имеет ли значение эта работа достаточный доход для покрытия расходов на использование ECS (Elastic Container Service) для управления процессом? Если вы можете запускать контейнер ECS, вы можете запустить lambda для создания объекта S3 для создания сообщения в очереди сообщений SQS. Ваш контейнер ECS прослушивает вашу очередь и когда приходит сообщение, обрабатывает его точно так же, как в вашей лямбда. Его выход для запуска следующего этапа - вывести сообщение в очередь SQS, обрабатывая следующую задачу.

Это позволит решить несколько проблем для вас, например, преодолеть 5-минутный максимум для Lambdas и создать простой способ повторения сбоев.

Однако он также создаст несколько новых проблем.

  • Создание и развертывание изображений докеров больше, чем редактирование lambda на консоли AWS.
  • Инфраструктурные затраты более устойчивы по своей природе, а не пропорциональны рабочей нагрузке.
1
добавлено

Я все еще попадаю в AWS Lambda, поэтому я не уверен, что это поможет вам, но я начал использовать лямбда-мониторинг производительности для моих функций, и, похоже, он работает хорошо. Я получаю сообщение, если что-то ломается через 60 секунд (+ ежедневные отчеты, но это менее важно), и это помогло мне разобраться в том, что сломалось.

Теперь я не знаю, действительно ли вы можете использовать функции Step для исправления своих проблем, но я знаю, что вы можете настроить события, которые запускают функцию Lambda, когда файл попадает на S3. Вот ссылка на s3 , которые могут помочь.

0
добавлено