Comment résoudre les erreurs relatives au délai d'expiration d'appels de fonctions Lambda ?

Lecture de 9 minute(s)
0

Ma fonction Lambda AWS expire par intermittence, même si je n'ai déployé aucune modification de code. Comment résoudre et prévenir les problèmes relatifs au délai d'expiration d'appels de fonctions Lambda ?

Résolution

Les fonctions Lambda peuvent expirer pour diverses raisons. Pour résoudre le problème de délai d'expiration de fonctions Lambda, commencez par en déterminer la cause, en utilisant l'un des services et fonctions AWS répertoriés dans cet article. Résolvez ensuite le problème en fonction de votre cas d'utilisation.

Pour empêcher l'expiration de délai de votre fonction Lambda, consultez la section Bonnes pratiques pour empêcher l'expiration de délai des fonctions Lambda de cet article.

Vérifier que le délai de votre fonction Lambda arrive à expiration

Récupérez les ID de requêtes de tout appel ayant expiré en recherchant dans le groupe de journaux Amazon CloudWatch de la fonction le message Task timed out (Délai d'attente de la tâche expiré). Utilisez ensuite les ID de requêtes des appels associés à une expiration pour récupérer les journaux complets pour chaque expiration d'appel.

Pour obtenir les instructions, consultez Comment puis-je déterminer si ma fonction Lambda expire ?

Identifier la cause du délai d'expiration de votre fonction Lambda

Utilisez une ou plusieurs des méthodes suivantes pour identifier le point de défaillance à l'origine de l'expiration du délai de votre fonction :

Consulter vos journaux CloudWatch Logs pour Lambda

Vous pouvez utiliser Amazon CloudWatch pour afficher tous les journaux générés par le code de votre fonction et identifier les problèmes potentiels. Pour obtenir des instructions, consultez Accès aux journaux Amazon CloudWatch Logs pour AWS Lambda.

Si votre fonction renvoie une trace de pile, le message d'erreur dans la trace de pile spécifie l'origine de l'erreur.

Important : Lambda génère automatiquement trois lignes de journal pour chaque appel (START, END et REPORT). Ces trois lignes sont les seules qui apparaissent dans les journaux CloudWatch de votre fonction, si l'une des conditions suivantes est vraie :

  • Aucune autre journalisation explicite n'est configurée dans le code personnalisé de la fonction Lambda.
  • La limite de durée de la fonction est atteinte avant que Lambda puisse exécuter le code de la fonction qui génère les journaux.

Si vous ne parvenez pas à déterminer la cause de l'expiration de délai après avoir consulté les journaux, essayez une ou plusieurs des solutions suivantes :

Pour ajouter d'autres sorties de journalisation au code de votre fonction, consultez la documentation suivante relative à l'exécution Lambda que vous utilisez :

Utiliser AWS X-Ray pour identifier les goulots d'étranglement des performances du code

Si votre fonction Lambda utilise des ressources, des microservices, des bases de données AWS en aval ou des API web HTTP, vous pouvez utiliser AWS X-Ray pour vous aider à résoudre les problèmes de performances du code.

Pour plus d'informations, consultez Utilisation d'AWS Lambda avec AWS X-Ray.

Utilisez Lambda Insights pour collecter les métriques au niveau du système pour votre fonction

Lambda Insights collecte les métriques au niveau du système, notamment les métriques de temps de processeur, de mémoire, de disque et de réseau. La fonction collecte également les informations de diagnostic, notamment les démarrages à froid et les arrêts de travail Lambda, pour vous aider à isoler les problèmes liés à vos fonctions Lambda.

Pour plus d'informations, consultez Utilisation de Lambda Insights.

Remarque : l'utilisation de Lambda Insights entraîne des frais sur votre compte AWS. Vous êtes facturé pour le temps d'appel consommé par l'extension Lambda par incréments de 1 ms.

Utiliser VPC Flow Logs pour déterminer pourquoi une requête d'appel spécifique a été refusée ou n'a pas été acheminée

VPC Flow Logs vous permet de voir tout le trafic réseau routé vers et depuis un Amazon Virtual Private Cloud (Amazon VPC).

Pour plus d'informations, consultez Résoudre les problèmes réseau dans Lambda.

Remarque : gardez à l'esprit les points suivants si vous choisissez de configurer VPC Flow Logs :

  • Les frais d'ingestion et d'archivage des données pour les journaux payants s'appliquent lorsque vous publiez les journaux de flux sur l'un des éléments ci-dessous :
  • CloudWatch Logs
  • Amazon Simple Storage Service (Amazon S3)

Utiliser les traces de fils HTTP pour la journalisation détaillée des requêtes réseau générées par le code de la fonction lors d'un appel

Pour plus d'informations, reportez-vous à Journalisation des traces de fils HTTP.

Bonnes pratiques pour empêcher les délais d'expiration des fonctions Lambda

Vérifier que votre fonction Lambda est idempotente

Les appels d'API peuvent prendre plus de temps que prévu en raison de problèmes réseau transitoires. Les problèmes de réseau peuvent également entraîner de nouvelles tentatives ainsi que des requêtes d'API en double. Pour vous préparer à ces éventualités, assurez-vous que votre fonction Lambda est idempotente.

Pour plus d'informations, voir Comment rendre ma fonction Lambda idempotente ?

Initialiser la logique statique de votre fonction en dehors du gestionnaire de fonction

Lorsque vous initialisez une fonction Lambda, Lambda alloue jusqu'à 10 secondes pour que la phase d'initialisation de l'appel se termine. En raison de cette contrainte de temps, il est recommandé d'effectuer les opérations suivantes en dehors du gestionnaire de fonction dans le code d'initialisation :

  • Importer des bibliothèques et des dépendances
  • Configurer la configuration initiale
  • Initialiser les connexions à d'autres services et ressources en aval

Cette initialisation statique permet d'initialiser ces ressources une fois par environnement de test (sandbox), puis de les réutiliser pour tous les appels futurs dans le même environnement d'exécution.

Pour plus d'informations, consultez Optimisation de l'initialisation statique. Consultez également les sections Indisponibilité en aval du guide de l'opérateur Lambda, et Code de fonction du guide du développeur Lambda.

Remarque : Lambda supprime les connexions inactives aux ressources en aval. Pour permettre à votre fonction de maintenir une connexion persistante, utilisez la variable tcp_keepalive associée à l'exécution Lambda que vous utilisez.

Vérifier que le nombre de nouvelles tentatives et les paramètres de délai d'expiration du kit SDK AWS que vous utilisez autorisent suffisamment de temps pour que votre fonction s'initialise

Si vous effectuez un appel d'API à l'aide d'un kit SDK AWS et que l'appel échoue, le kit SDK AWS retente automatiquement l'appel. Le nombre de tentatives du kit SDK AWS et leur durée sont déterminés par des paramètres qui varient d'un kit SDK AWS à l'autre. L'initialisation de votre fonction peut nécessiter plus de temps que ne le permettent les paramètres par défaut du kit SDK AWS.

Pour obtenir plus d'informations, consultez la section Comment résoudre les problèmes de nouvelles tentatives et de délai d'expiration lors de l'appel d'une fonction Lambda en utilisant un kit SDK AWS ?

(Facultatif) Configurer la simultanéité allouée pour votre fonction Lambda

La simultanéité allouée initialise un nombre requis d'environnements d'exécution afin qu'ils soient prêts à répondre immédiatement aux appels de votre fonction. Pour configurer la simultanéité allouée pour votre fonction, suivez les instructions contenues dans Configuration de la simultanéité allouée.

Remarque : la configuration de la simultanéité allouée entraîne des frais sur votre compte AWS. Vous pouvez configurer la simultanéité allouée sur une version d'une fonction ou sur un alias de fonction Lambda.

Vérifier que votre fonction Lambda dispose de suffisamment de ressources système

La quantité de bande passante réseau et de CPU allouée à un appel de fonction Lambda est déterminée par la configuration de mémoire de la fonction.

Pour plus d'informations, reportez-vous à la section Mémoire et puissance de calcul du guide de l'opérateur Lambda.

Vérifier que tous les processus en arrière-plan utilisés par votre fonction Lambda sont complets avant que le gestionnaire de fonction ne renvoie une chaîne

Pour plus d'informations, consultez Comprendre la réutilisation des conteneurs dans AWS Lambda.

Vérifier que votre fonction Lambda est configurée pour fonctionner dans les paramètres de délai d'expiration maximums de tous les services AWS intégrés

Même si le délai d'expiration d'appel maximal d'une fonction Lambda est de 15 minutes, d'autres services AWS peuvent avoir des limites de délai d'expiration différentes.

Par exemple, Amazon API Gateway attend au maximum 29 secondes pour qu'un appel de proxy de fonction Lambda se termine. Pour plus d'informations, voir Comment résoudre les erreurs que je reçois lorsque j'intègre API Gateway à une fonction Lambda ? Vous pouvez également consulter Utilisation d'AWS Lambda avec d'autres services.

Vérifier qu'il existe un chemin réseau valide vers le point de terminaison que votre fonction tente d'atteindre

Pour vérifier vos paramètres réseau, suivez les instructions contenues dans Comment résoudre les problèmes de délai d'expiration liés à une fonction Lambda située dans un Amazon VPC ?


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an