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

Правильный ответ — настроить очередь Amazon SQS в качестве места назначения при сбое и изменить функцию Lambda для обработки сообщений в очереди. Это гарантирует, что сообщения, которые не удалось обработать функцией Lambda (например, из-за проблем с сетью), будут автоматически перенаправлены в очередь SQS. Функция Lambda может быть настроена для чтения из этой очереди SQS, что позволяет повторно обрабатывать неудачные сообщения без ручного вмешательства. Развертывание функции Lambda в нескольких зонах доступности не решит проблему сбоев обработки, вызванных проблемами с сетью, поскольку это относится к доступности самой функции, а не к обработке отдельных сообщений. Увеличение выделения CPU и памяти для функции Lambda не устранит проблемы с сетевым подключением и не гарантирует повторную обработку неудачных сообщений. Настройка стратегии повторных попыток топика SNS не является опцией, поскольку SNS не имеет встроенной стратегии повторных попыток для доставки в Lambda. SNS просто отправляет сообщение, и если Lambda не может его обработать, оно теряется, если не настроен механизм обработки ошибок.