Une fonction Lambda de traitement des commandes consomme des messages d'une file d'attente Amazon SQS et écrit les résultats dans une table DynamoDB. La fonction Lambda s'exécute avec une concurrence réservée. Les clients signalent que la page d'historique des commandes est lente à afficher l'état du traitement. Quelles actions un ingénieur DevOps doit-il entreprendre pour diagnostiquer et corriger la latence ? (Choisissez-en deux.)

La lenteur de l'affichage de l'état de traitement indique un goulot d'étranglement. La métrique SQS ApproximateAgeOfOldestMessage révèle si les messages s'accumulent dans la file d'attente, suggérant que la fonction Lambda ne les traite pas assez rapidement. Augmenter la concurrence réservée de la fonction Lambda lui permet de traiter plus de messages simultanément, réduisant ainsi le délai de traitement. La métrique DynamoDB WriteThrottleEvents indique si les écritures vers la table sont limitées en raison d'une capacité insuffisante. Si c'est le cas, augmenter le nombre maximal d'unités de capacité d'écriture (WCUs) dans la politique d'autoscaling de la table DynamoDB permettra à la table de gérer un débit d'écriture plus élevé, évitant ainsi les ralentissements. Les autres options sont moins pertinentes : configurer une politique de nouvelle tentative (redrive policy) gère les échecs mais ne résout pas la latence de traitement. NumberOfMessagesSent indique le volume mais pas la latence. Augmenter le délai de visibilité (visibility timeout) est pour les messages qui ne sont pas traités à temps, pas pour la latence globale. Lambda Throttles est pertinent, mais augmenter le délai d'expiration (timeout) de la fonction ne résout pas la limitation si la concurrence est le problème.