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.
Comprendre l'environnement d'exécution des instances gérées Lambda
Les instances gérées Lambda fournissent un modèle de déploiement alternatif qui exécute votre code de fonction sur les instances Amazon EC2 appartenant au client, tandis que Lambda gère les aspects opérationnels. L'environnement d'exécution des instances gérées présente plusieurs différences importantes par rapport aux fonctions Lambda (par défaut), notamment en ce qui concerne la façon dont il gère les appels simultanés et les cycles de vie des conteneurs.
Remarque : Pour plus d'informations sur l'environnement d'exécution Lambda (par défaut), voir Comprendre le cycle de vie de l'environnement d'exécution Lambda.
Cycle de vie des environnements d'exécution
Le cycle de vie d'un environnement d'exécution de fonctions Lambda Managed Instances diffère de celui de Lambda (par défaut) de plusieurs manières principales :
Phase d’initialisation
Pendant la phase d'initialisation, Lambda exécute les étapes suivantes :
-
Initialisez et enregistrez toutes les extensions
-
Bootstrap le point d'entrée d'exécution. L'exécution génère le nombre configuré de travailleurs d'exécution (la mise en œuvre dépend de l'exécution)
-
Exécuter le code d'initialisation de la fonction (code en dehors du gestionnaire)
-
Attendez qu'au moins un agent d'exécution signale qu'il est prêt en appelant
/runtime/invocation/next
La phase d'initialisation est considérée comme terminée lorsque les extensions sont initialisées et qu'au moins un agent d'exécution a appelé. /runtime/invocation/next La fonction est alors prête à traiter les invocations.
Note
Pour les fonctions Lambda Managed Instances, l'initialisation peut prendre jusqu'à 15 minutes. Le délai d'attente est de 130 secondes au maximum ou du délai d'expiration de la fonction configurée (jusqu'à 900 secondes).
Phase d’invocation
La phase d'appel pour les fonctions Lambda Managed Instances présente plusieurs caractéristiques uniques :
Fonctionnement en continu Contrairement à Lambda (par défaut), l'environnement d'exécution reste actif en permanence, traitant les appels au fur et à mesure qu'ils arrivent sans se figer entre les appels.
Traitement en parallèle. Plusieurs invocations peuvent être exécutées simultanément dans le même environnement d'exécution, chacune étant gérée par un agent d'exécution différent.
Délais d'attente indépendants. Le délai d'expiration configuré pour la fonction s'applique à chaque appel individuel. Lorsqu'un appel expire, Lambda marque cet appel spécifique comme ayant échoué, mais n'interrompt pas les autres appels en cours et ne met pas fin à l'environnement d'exécution.
Gestion de la contre-pression. Si tous les travailleurs d'exécution sont occupés à traiter les invocations, les nouvelles demandes d'invocation sont rejetées jusqu'à ce qu'un travailleur soit disponible.
Gestion des erreurs et restauration
La gestion des erreurs dans les environnements d'exécution des fonctions des instances gérées Lambda diffère de celle de Lambda (par défaut) :
Pannes du Runtime Worker. Si un processus d'exécution tombe en panne, l'environnement d'exécution continue de fonctionner avec les autres travailleurs sains.
L'extension se bloque. Si un processus d'extension se bloque pendant l'initialisation ou le fonctionnement, l'ensemble de l'environnement d'exécution est marqué comme défectueux et est arrêté. Lambda crée un nouvel environnement d'exécution pour le remplacer.
Non reset/repair Contrairement à Lambda (par défaut), les instances gérées ne tentent pas de réinitialiser et de réinitialiser l'environnement d'exécution après des erreurs. Au lieu de cela, les contenants insalubres sont retirés et remplacés par de nouveaux.
Invoquer des délais
Lorsqu'une invocation individuelle expire, Lambda renvoie une Task timed out after <timeout> seconds erreur avec un statut d'erreur de fonction à l'appelant. Toutefois, les instances gérées Lambda ne mettent pas fin de force à votre code : il continue de s'exécuter dans l'environnement d'exécution. En tant que développeur de fonctions, vous êtes responsable de la détection et de la gestion du délai d'attente.
L'objet de contexte indique le temps restant pour l'invocation. Une valeur nulle ou négative indique que le délai d'invocation a expiré. Les autres appels simultanés dans l'environnement d'exécution continuent à être traités normalement.
Comportement de nouvelle tentative
Lorsqu'une invocation expire :
-
Invocations synchrones : l'appelant reçoit l'erreur de temporisation et est chargé de réessayer.
-
Invocations asynchrones : Lambda réessaie en fonction de la politique de nouvelle tentative de votre fonction (par défaut : 2 tentatives). Une fois toutes les tentatives épuisées, l'événement est envoyé vers la file d'attente de lettres mortes configurée ou vers la destination en cas d'échec, le cas échéant.
-
Mappages de sources d'événements : le comportement des nouvelles tentatives dépend de la configuration de la source d'événements (par exemple, taille du lot, bissection en cas d'erreur, nombre maximum de tentatives). Le lot peut être réessayé ou envoyé vers une destination en cas d'échec en fonction de vos politiques en matière de nouvelles tentatives.
Que se passe-t-il si vous ne gérez pas le délai d'attente
Si votre code ne vérifie pas le temps restant et arrête l'exécution :
-
L'invocation est déjà marquée comme ayant échoué. Lambda a déjà renvoyé une erreur de temporisation à l'appelant : tout travail effectué par votre code après le délai est effectivement perdu du point de vue de l'appelant.
-
Les ressources restent consommées. Votre code continue d'occuper un emplacement de travail d'exécution, ce qui réduit la simultanéité disponible pour les nouvelles invocations sur cette instance.
-
Comportement non déterministe. Votre code ne s'arrête pas lorsque le timeout se déclenche : il continue de s'exécuter en arrière-plan. Cela signifie que des effets secondaires peuvent encore survenir même si Lambda a déjà informé l'appelant que l'appel avait échoué.
Par exemple, votre gestionnaire écrit un enregistrement dans DynamoDB, puis le délai d'attente se déclenche et Lambda renvoie une erreur de temporisation à l'appelant, mais votre code est toujours en cours d'exécution et envoie une notification SNS. L'appelant tente à nouveau l'invocation, qui écrit à nouveau l'enregistrement et envoie à nouveau la notification. Vous avez maintenant des données dupliquées et des notifications dupliquées, et il n'est pas facile de savoir lesquelles provenaient de l'appel « échoué » qui était toujours en cours d'exécution en arrière-plan.
Gestion des délais d'attente dans votre code
Utilisez l'objet de contexte pour vérifier le temps restant et arrêter le traitement avant le délai imparti. Configurez une mémoire tampon en fonction de la durée prévue de votre prochaine unité de travail. Par exemple, si le traitement de chaque élément prend environ 500 ms, réglez la mémoire tampon sur au moins 500 ms plus la marge.
Pour des exemples de gestion du délai d'attente spécifiques à la langue, consultez la section sur le contexte de la demande de chaque page d'exécution :
