View a markdown version of this page

Résoudre les problèmes de mappage des sources d’événements dans Lambda - AWS Lambda
Identification et gestion de la limitationErreurs dans la fonction de traitementIdentification et gestion de la contre-pression

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 de sources d'événements qui mettent en file d'attente des messages pour Lambda Event Functions.

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 CloudWatch métriques de la fonction :

CloudWatch métriques indiquant que le nombre d'exécutions simultanées atteint 100 et que les limitations augmentent à mesure que la fonction atteint sa limite.

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 Limitations montre la limitation 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. Après avoir identifié le problème de limitation, plusieurs options s’offrent à vous pour le résoudre :

  • Demandez une augmentation de la simultanéité auprès du AWS Support de 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 CloudWatch indiquent un problème lié au traitement des files d'attente :

CloudWatch Mesures SQS indiquant l'âge du message le plus ancien et l'augmentation du nombre de messages visibles lorsqu'aucun message n'est supprimé.

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 :

CloudWatch Les métriques Lambda indiquent un nombre croissant d'erreurs associées à une réduction de la simultanéité et à l'absence de régulation, indiquant l'arrêt du dimensionnement.

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 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. Une fois que vous avez corrigé l'erreur et déployé le nouveau code de fonction, les CloudWatch métriques devraient indiquer le processus de restauration :

CloudWatch Mesures Lambda indiquant que le nombre d'erreurs tombe à zéro et que le taux de réussite revient à 100 % après le déploiement du correctif.

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 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, plus options se présentent à vous :