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 des 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 des 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 :
-
Initialisation et enregistrement de toutes les extensions
-
Démarrez le point d'entrée du runtime. L'environnement d'exécution génère le nombre configuré de travailleurs d'exécution (l'implémentation dépend du temps d'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 indique 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 programme de travail d'exécution a été 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'expiration est de 130 secondes maximum ou le 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 invocations.
Traitement 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 exécutant 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 invocations en cours ni ne met fin à l'environnement d'exécution.
Gestion de la contre-pression. Si tous les travailleurs d'exécution sont occupés à traiter des appels, les nouvelles demandes d'appel 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 Lambda Managed Instances est différente de celle de Lambda (par défaut) :
Défaillances du Runtime Worker. Si un processus de travail d'exécution se bloque, 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'un appel individuel expire, Lambda renvoie Task timed out after <timeout> seconds une erreur avec le 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'expiration. L'objet de contexte indique le temps restant pour l'invocation. Une valeur nulle ou négative indique que le délai d'invocation est expiré. Les autres appels simultanés dans l'environnement d'exécution continuent à être traités normalement.
Comportement de nouvelle tentative
Lorsqu'une invocation arrive à expiration :
-
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 relance de votre fonction (par défaut : 2 tentatives). Une fois toutes les tentatives épuisées, l'événement est envoyé à la file d'attente des lettres mortes configurée ou à 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, division en deux en cas d'erreur, nombre maximal de tentatives). Le lot peut être réessayé ou envoyé vers une destination en cas d'échec en fonction de vos politiques de relance.
Que se passe-t-il si vous ne gérez pas le délai
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. Du point de vue de l'appelant, tout travail effectué par votre code après le délai d'expiration est effectivement perdu.
-
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 délai expire : il continue de s'exécuter en arrière-plan. Cela signifie que des effets secondaires peuvent toujours se produire une fois que Lambda a déjà indiqué à l'appelant que l'appel avait échoué. Par exemple, votre gestionnaire écrit un enregistrement dans DynamoDB, puis le délai d'expiration est déclenché 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 disposez désormais de données et de notifications dupliquées, et il n'est pas facile de savoir lesquelles proviennent de l'appel « échoué » qui était toujours en cours 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 l'expiration du délai. 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, définissez la mémoire tampon sur au moins 500 ms plus la marge.
Pour des exemples de gestion des délais d'attente spécifiques à une langue, consultez la section sur le contexte de la demande de chaque page d'exécution :
