Использование S3 вместо SQS для целей интеграции

Question

люди.

Недавно я столкнулся с вопросом, который вызвал некоторые опасения и сомнения. Я создаю "почти безсерверный" микро-сервис, используя AWS. Вот его рабочий процесс: Параметры рабочих процессов

Дело в том, что входное сообщение может быть большим, но AWS SQS ограничивает размер сообщения 256 КБ. Итак, я решил использовать уведомления S3 и S3 для обработки входных данных: PUT клиента - объект; его создание вызывает лямбда-функции и так далее. Таким образом, ограничения в 256 Кбайт не имеют значения, но, с другой стороны, я использую сервис хранилища как интеграционный. Одной из проблем является обработка очереди мертвых писем, например

Возможно, кто-то сталкивался с подобными проблемами. Одна из вещей состоит в том, чтобы держать "без сервера". Есть ли хорошие решения / улучшения / советы?

Заранее спасибо.

Answer 1

Рассматривали ли вы использование Kinesis Stream, а затем присоединение своей лямбды к потоку размером 1? Вы могли бы также обработать свое мертвое письмо с осколками времени и т. Д. c.

Или, если вы можете манипулировать исходным сообщением, поместите свою метку времени в сообщение, тогда вы можете легко использовать сообщения Kinesis Firehose и Bulk Load. Ограничение на Kinesis составляет 2 МБ, поэтому вы почти в 10 раз увеличите размер сообщения на sqs, который вы можете сжать в дальнейшем.

Answer 2

Я бы рекомендовал объединить два подхода:

• Записать данные в Amazon S3
• Создать сообщение в очереди Amazon SQS, содержащее ссылку на данные в S3

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

Если все необходимые данные уже есть в файле, вы можете настроить событие Amazon S3 Event. создать сообщение SQS непосредственно в очереди. Сообщение будет содержать название корзины и ключ объекта. Таким образом, помещение файла в S3 создаст сообщение SQS и вызовет функцию AWS Lambda. Это более масштабируемо, чем прямой запуск лямбда-функции из S3.