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 des sources 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énements exacte utilisée. Cette section répertorie les problèmes courants liés aux mappages des sources d’événements et fournit des conseils sur la manière de les identifier et de les résoudre.
Note
Cette section utilise une source d’événements Amazon SQS à titre d’illustration, mais les principes s’appliquent aux autres mappages des sources d’événements qui mettent en file d’attente des messages pour les fonctions Lambda.
Identification et gestion de la limitation
Dans Lambda, la limitation 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 seul message toutes les 30 secondes :
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))
exports.handler = async (event) => {
await doWork(30000)
}
Avec une durée d’invocation aussi longue, les messages commencent à arriver dans la file d’attente plus rapidement qu’ils sont traités. Si la simultanéité non réservée de votre compte est de 100, Lambda augmente verticalement jusqu’à 100 exécutions simultanées, puis une limitation se produit. Vous pouvez voir ce schéma dans les métriques CloudWatch relatives à la fonction :
Les métriques CloudWatch relatives à la fonction n’indiquent aucune erreur, mais le graphique Exécutions simultanées indique que la simultanéité maximale de 100 est atteinte. Par conséquent, le graphique Limitations montre la limitation en place.
Vous pouvez détecter la limitation avec les alarmes CloudWatch et en définissant une alarme chaque fois que la métrique de limitation d’une fonction est supérieure à 0. Après avoir identifié le problème de limitation, plusieurs options s’offrent à vous pour le résoudre :
-
Demander une augmentation de la simultanéité auprès d’AWS Support dans cette région.
-
Identifier les problèmes de performance de la fonction afin d’améliorer la vitesse de traitement et donc le débit.
-
Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation.
Erreurs dans la fonction de traitement
Si la fonction de traitement génère des erreurs, Lambda renvoie les messages dans la file d’attente SQS. Lambda empêche la mise à l’échelle de votre fonction afin d’éviter les erreurs à grande échelle. Les métriques SQS suivantes dans CloudWatch indiquent qu’il existe un problème de 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 métriques CloudWatch relatives à 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 cessé de se mettre à l’échelle votre fonction en raison d’erreurs. Les journaux CloudWatch de cette fonction fournissent des informations détaillées 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 métriques CloudWatch devraient indiquer que le traitement a repris :
Ici, la métrique Nombre d’erreurs tombe à zéro et la métrique Taux de réussite revient à 100 %. Lambda recommence à augmenter verticalement la fonction, comme indiqué dans le graphique Exécutions simultanées.
Identification et gestion de la contre-pression
Si un producteur d’événements génère régulièrement des messages pour une file d’attente SQS plus rapidement qu’une fonction Lambda peut le gérer, 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 des alarmes CloudWatch.
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, plus options se présentent à vous :
-
Demander une augmentation de la simultanéité dans la région concernée auprès d’AWS Support.
-
Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation.