Отслеживание асинхронного лямбда-выполнения на AWS

Question

Я пытаюсь создать процесс, который запускает лямбда-сигнал AWS, который затем использует AWS-SNS для отправки сообщений, запускающих большее количество лямбд. Каждая такая вызванная лямбда записывает выходной файл на S3. Процесс, как показано ниже -

У меня такой вопрос: как я могу знать, что все лямбды сделаны с записью файлов? Я хочу выполнить другой процесс, который собирает все эти файлы и выполняет слияние. Я мог бы придумать два очевидных способа -

1. Постоянно отслеживайте s3 столько же выходных файлов, сколько сообщений SNS. Как только общее число достигнет, вызовите последнюю лямбду слияния.
2. Использование базы данных в качестве источника синхронизации, запись количества для этого конкретного задания / сеанса и отслеживание его до тех пор, пока число не достигнет числа сообщений SNS.

Оба решения требуют постоянного опроса, которого я хотел бы избежать. Я хочу сделать это на основе событий. Я надеялся, что Amazon SQS придет мне на помощь с каким-то «лямбда-триггером пустой очереди», но SQS поддерживает только лямбда-триггеры для новых сообщений. Есть ли какой-нибудь известный способ достичь этого в AWS? Ваши предложения / комментарии / ответы очень ценятся.

Answer 1

Заявленная проблема кажется подходящим кандидатом для Образца Сага. В основном Saga описывается как любой длительный распределенный процесс.

Как упоминалось ранее, платформа AWS позволяет использовать функции Step для реализации Saga, как описано здесь, введите

Answer 2

Лично я предпочитаю идею с «Шаговыми функциями».

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

Проверьте больше - Использование AWS Lambda с Amazon S3

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

Answer 3

Я бы предложил здесь несколько вариантов:

Шаг Функции:

Это управляемый сервис для конечных автоматов. Отлично подходит для координации рабочих процессов.

Атомный счет:

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

Обратите внимание, что DynamoDB Streams гарантирует следующее:

• Каждая запись потока появляется в потоке ровно один раз.

• Для каждого элемента, который изменяется в таблице DynamoDB, записи потока отображаются в той же последовательности, что и фактические модификации элемента.

Answer 4

Шаговые функции AWS (управляемая служба конечного автомата) были бы очевидным выбором. У AWS есть несколько примеров в качестве отправных точек. Я помню одно зацикливание, которое вы, вероятно, могли бы применить к этому варианту использования.

Еще одна идея с моей головы ...

Создайте "Orchestration Lambda", в которой есть список ваших файлов ...

1. Orchestration Lambda вызывает «File Writer Lambda» в цикле, передавая информацию о файле. InvokeAsync (запрос InvokeRequest) возвращает объект Future. Orchestration Lambda может проверить состояние будущего объекта на завершение.

2. Orchestration Lambda может сделать аналогичный вызов «File Writer Lambda», но вместо этого использовать более гибкий метод: invokeAsync (запрос InvokeRequest, AsyncHandler asyncHandler). Вы можете создать внутренний класс, который реализует этот AsyncHandler, и отслеживать его завершение в Orchestration Lambda. Это немного чище, чем все петли.

Возможно, есть много способов решить эту проблему, но есть две идеи.