View a markdown version of this page

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

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 observer ce schéma dans les CloudWatch statistiques de la fonction :

CloudWatch métriques montrant des exécutions simultanées atteignant 100 et des accélérations augmentant à mesure que la fonction atteint sa limite.

CloudWatch les métriques de la fonction n'indiquent 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 limitation à l'aide d' CloudWatch alarmes et définir une alarme chaque fois que la métrique d'étranglement 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 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 CloudWatch indiquent un problème lié au traitement des files d'attente :

CloudWatch Les mesures SQS indiquent l'âge du message le plus ancien et les messages visibles augmentent 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 d'erreurs croissant avec une simultanéité réduite et aucune limitation, ce qui indique l'arrêt de la mise à l'échelle.

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 informations 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 que le traitement est rétabli :

CloudWatch Les métriques Lambda indiquent 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 d' CloudWatch 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 :

  • Demandez une augmentation de la simultanéité dans la région concernée auprès du AWS support.

  • Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation.