Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes de mappage des sources d'événements dans Lambda

Dans Lambda, les problèmes liés au mappage d'une source d'événements peuvent être plus complexes car ils impliquent le débogage sur plusieurs services. De plus, le comportement de la source d'événements peut différer en fonction de la source d'événement exacte utilisée. Cette section répertorie les problèmes courants liés aux mappages de sources d'événements et fournit des conseils sur la manière de les identifier et de les résoudre.

Identification et gestion de la limitation

Dans Lambda, la régulation se produit lorsque vous atteignez la limite de simultanéité de votre fonction ou de votre compte. Prenons l'exemple suivant, où une fonction Lambda lit les messages d'une file d'attente Amazon SQS. Cette fonction Lambda simule des appels de 30 secondes et a une taille de lot de 1. Cela signifie que la fonction ne traite qu'un message toutes les 30 secondes :

const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}

Avec un temps d'invocation aussi long, les messages commencent à arriver dans la file d'attente plus rapidement qu'ils ne sont traités. Si la simultanéité non réservée de votre compte est de 100, Lambda augmente jusqu'à 100 exécutions simultanées, puis la régulation se produit. Vous pouvez voir ce schéma dans les CloudWatch métriques de la fonction :

CloudWatch les métriques de la fonction ne montrent aucune erreur, mais le graphique des exécutions simultanées indique que la simultanéité maximale de 100 est atteinte. Par conséquent, le graphique des accélérateurs indique que l'étranglement est en place.

Vous pouvez détecter la régulation à l'aide d' CloudWatch alarmes et définir une alarme chaque fois que la métrique de régulation d'une fonction est supérieure à 0. Une fois que vous avez identifié le problème de régulation, plusieurs options s'offrent à vous pour le résoudre :

Erreurs dans la fonction de traitement

Si la fonction de traitement génère des erreurs, Lambda renvoie les messages à la file d'attente SQS. Lambda empêche la mise à l'échelle de votre fonction pour éviter les erreurs d'échelle. Les métriques SQS suivantes CloudWatch indiquent un problème lié au traitement des files d'attente :

En particulier, l'âge du message le plus ancien et le nombre de messages visibles augmentent, alors qu'aucun message n'est supprimé. La file d’attente continue de croître, mais les messages ne sont pas traités. Les CloudWatch métriques de la fonction Lambda de traitement indiquent également l'existence d'un problème :

La métrique du Nombre d’erreurs est différente de zéro et augmente, tandis que les Exécutions simultanées ont diminué et que la limitation a cessé. Cela montre que Lambda a arrêté d'augmenter la taille de votre fonction en raison d'erreurs. Les CloudWatch journaux de la fonction fournissent des détails sur le type d'erreur.

Vous pouvez résoudre ce problème en identifiant la fonction à l’origine de l’erreur, puis en recherchant et en résolvant l’erreur. Après avoir corrigé l'erreur et déployé le nouveau code de fonction, les CloudWatch métriques devraient indiquer le processus de restauration :

Ici, la métrique du nombre d'erreurs tombe à zéro et la métrique du taux de réussite revient à 100 %. Lambda recommence à augmenter la taille de la fonction, comme indiqué dans le graphique Exécutions simultanées.

Identification et gestion de la contre-pression

Si un générateur d'événements génère régulièrement des messages pour une file d'attente SQS plus rapidement qu'une fonction Lambda ne peut les traiter, une contre-pression se produit. Dans ce cas, la surveillance SQS doit indiquer que l'âge du message le plus ancien augmente de façon linéaire, ainsi que le nombre approximatif de messages visibles. Vous pouvez détecter la contre-pression dans les files d'attente à l'aide CloudWatch d'alarmes.

Les étapes à suivre pour remédier à la contre-pression dépendent de votre charge de travail. Si l'objectif principal est d'augmenter la capacité de traitement et le débit par la fonction Lambda, plusieurs options s'offrent à vous :