Pourquoi les sources d'événements asynchrones mettent-elles beaucoup de temps à déclencher ma fonction Lambda ?

Brève description

Lors de l’utilisation d’invocations asynchrones avec vos fonctions Lambda, vous remarquerez peut-être que vos événements mettent plus de temps que prévu à se déclencher. Vos événements peuvent également être envoyés dans la file d'attente de lettres mortes sans être récupérés par le service Lambda pour un traitement ultérieur.

Il existe plusieurs services AWS qui invoquent des fonctions Lambda de manière asynchrone :

• Amazon Simple Storage Service (Amazon S3)
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Email Service (Amazon SES)
• AWS CloudFormation
• Amazon CloudWatch Logs
• Amazon CloudWatch Events
• AWS CodeCommit
• AWS Config

Résolution

Délais d'invocation

En général, vous pouvez constater des retards en raison de la méthode asynchrone de traitement des demandes.

• Lorsque vous faites une demande, elle est envoyée à une file d'attente asynchrone interne. Lambda récupère les demandes de la file d'attente asynchrone interne, puis envoie la demande à la fonction Lambda pour un traitement ultérieur. Il est possible que les journaux Amazon CloudWatch Logs de votre fonction soient retardés si votre fonction Lambda rencontre des erreurs. Des retards peuvent également survenir si les demandes sont limitées au niveau de la fonction.
• S'il n'y a aucune erreur ou aucun point de données d'étranglement au niveau de la fonction, vérifiez les mesures au niveau régional pour détecter les erreurs et les limites. Si d'autres fonctions sont invoquées de manière asynchrone et rencontrent ensuite des erreurs, ces fonctions sont considérablement retardées. Ainsi, même si votre fonction ne comporte pas de points de données d'erreur ou de limitation, les invocations ou demandes adressés à la fonction peuvent tout de même être retardés.
• Si d'autres fonctions situées dans la même région que votre fonction Lambda sont invoquées plusieurs fois de manière asynchrone, la file d'attente interne est encombrée. Pour résoudre le problème, augmentez la simultanéité au niveau régional.
• Pour vérifier le backlog de la file d'attente interne, activez AWS X-Ray sur votre fonction Lambda. Lorsque AWS X-Ray est activé, vous pouvez utiliser la propriété durée de temporisation. Cette propriété indique le temps total que les demandes passent dans la file d'attente interne avant que le service Lambda ne les envoie à la fonction Lambda pour traitement.
• Configurez une simultanéité par fonction, ou une simultanéité réservée, pour protéger les fonctions contre le retard dans les files d'attente.

Invocation dupliquée

Lambda est un service distribué qui garantit que votre fonction est invoquée au moins une fois. Toutefois, si la fonction est invoquée plusieurs fois, des doublons peuvent se produire. Consultez les journaux CloudWatch pour détecter ces invocations dupliquées.

• Il est recommandé de vous assurer que votre fonction peut gérer les demandes dupliquées. Pour plus d'informations, consultez Comment rendre ma fonction Lambda idempotente ?
• Consultez les journaux CloudWatch pour Lambda et vérifiez les identifiants de demande pour votre fonction. À partir des journaux, vous pouvez vérifier si les événements dupliqués ont des identifiants de demande identiques ou différents. Les identifiants de demande restent les mêmes tout au long du cycle de vie d'une invocation asynchrone concernant Lambda. Si les identifiants de demande sont identiques, vérifiez si la fonction comporte des points de données d'erreur qui ont provoqué une nouvelle tentative d'invocation et une duplication.
• Si les identifiants de demande sont différents, les invocations dupliquées se produisent côté client.

Invocations manquantes

Consultez les journaux CloudWatch pour faire la différence entre les invocations manquantes et différées. Pour les invocations différées, suivez les étapes décrites précédemment dans la section Invocations différées de cet article.

Les invocations manquantes se produisent lorsqu'il n'y a pas suffisamment de simultanéité pour traiter la demande. Si la fonction dispose d'une simultanéité réservée et qu'elle rencontre des erreurs, la demande reste longtemps dans la file d'attente asynchrone. La demande est ensuite supprimée sans être traitée par Lambda. Consultez la métrique AsyncEventsDropped pour vérifier le nombre d'événements qui ont été supprimés sans exécuter la fonction.

Si vous avez configuré la file d'attente de lettres mortes, vérifiez cette dernière ou la destination en cas d'échec correspondant à la demande. Si un événement expire dans la file d'attente interne au bout de six heures, la demande peut être envoyée dans la file d'attente de lettres mortes sans être traitée par Lambda.

Métriques pour les invocations asynchrones

Pour plus d'informations sur la révision d'autres métriques relatives à l'invocation asynchrone, consultez Présentation des nouvelles métriques d'invocation asynchrone pour AWS Lambda.

Informations connexes

Invocation asynchrone

Gestion de l'idempotence des fonctions Lambda avec AWS Lambda Powertools

Utilisation des métriques des fonctions Lambda