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

Правильный ответ — создание очереди недоставленных сообщений (DLQ) и настройка функции Lambda для отправки неудачных сообщений в эту DLQ. DLQ — это стандартный механизм для обработки сообщений, которые не удалось обработать, обеспечивающий низкие операционные издержки. Сообщения, которые приводят к сбоям или таймаутам Lambda, автоматически отправляются в DLQ, где их можно легко проанализировать и повторно обработать. Увеличение таймаута функции Lambda до 15 минут может лишь отсрочить проблему, но не решит ее, а просмотр CloudTrail не является эффективным способом отладки отдельных сообщений. Увеличение таймаута видимости SQS не поможет, так как проблема в обработке сообщений функцией Lambda, а не в их доступности. Запись неудачных сообщений в таблицу DynamoDB потребует дополнительной логики в функции Lambda и увеличит операционные издержки по сравнению с использованием DLQ.