Lambda-функция обработки заказов потребляет сообщения из очереди Amazon SQS и записывает результаты в таблицу DynamoDB. Lambda запускается с зарезервированной параллельностью. Клиенты сообщают, что страница истории заказов с задержкой отображает статус обработки. Какие действия должен предпринять DevOps-инженер для диагностики и устранения задержки? (Выберите два варианта)

Задержка в отображении статуса обработки указывает на проблемы с производительностью. Метрика ApproximateAgeOfOldestMessage в SQS показывает возраст самого старого сообщения в очереди. Высокое значение этой метрики говорит о том, что Lambda-функция не успевает обрабатывать сообщения. Увеличение лимита параллелизма Lambda позволит обрабатывать больше сообщений одновременно, сокращая задержку. Метрика WriteThrottleEvents в DynamoDB показывает количество запросов на запись, которые были отклонены из-за превышения пропускной способности. Если эта метрика высока, это означает, что DynamoDB не справляется с объемом записей от Lambda. Увеличение максимального количества единиц производительности записи (WCUs) в политике автомасштабирования таблицы DynamoDB позволит базе данных обрабатывать больше запросов, устраняя узкое место. Настройка политики повторной обработки (redrive policy) для SQS не решит проблему задержки, а лишь перенаправит необработанные сообщения. Увеличение таймаута видимости SQS не повлияет на скорость обработки. Метрика NumberOfMessagesSent показывает количество отправленных сообщений, но не их обработку. Увеличение таймаута функции Lambda не ускорит обработку, а лишь даст функции больше времени на выполнение, что может усугубить задержку.