AWS Lambda environnement d’exécution

Lambda appelle votre fonction dans un environnement d’exécution, qui fournit un environnement d’exécution sécurisé et isolé. L’environnement d’exécution gère les ressources nécessaires à l’exécution de votre fonction. L’environnement d’exécution prend également en charge le cycle de vie pour l’exécution de la fonction et pour toutes les extensions externes associées à votre fonction.

L’exécution de la fonction communique avec Lambda à l’aide de l’API d’exécution. Les extensions communiquent avec Lambda à l’aide de l’API d’extensions. Les extensions peuvent également recevoir des messages de journaux de la fonction en souscrivant aux journaux à l’aide de l’API Logs.

Lorsque vous créez votre fonction Lambda, vous précisez des informations de configuration, telles que la quantité de mémoire disponible et le temps d’exécution maximum autorisé pour votre fonction. Lambda utilise ces informations pour configurer l’environnement d’exécution.

L’exécution de la fonction et chaque extension externe sont des processus qui s’exécutent dans l’environnement d’exécution. Les autorisations, les ressources, les informations d’identification et les variables d’environnement sont partagées entre la fonction et les extensions.

Rubriques

• API Extensions Lambda
• AWS LambdaAPI de runtime
• API Logs Lambda
• Partenaires des extensions AWS Lambda
• Cycle de vie d’un environnement d’exécution Lambda

Cycle de vie d’un environnement d’exécution Lambda

Le cycle de vie de l’environnement d’exécution comprend les phases suivantes :

• Init : au cours de cette phase, Lambda crée ou libère un environnement d’exécution avec les ressources configurées, télécharge le code pour la fonction et toutes les couches, initialise les extensions, initialise l’exécution et exécute le code d’initialisation de la fonction (code en dehors du gestionnaire principal). La phase Init se produit soit lors du premier appel, soit avant les appels de fonction si vous avez activé la simultanéité approvisionnée.

  La phase Init est fractionnée en trois sous-phases : Extension init, Runtime init et Function init. Ces sous-phases garantissent que toutes les extensions et l’exécution accomplissent leurs tâches de configuration avant l’exécution du code de la fonction.

• Invoke : au cours de cette phase, Lambda appelle le gestionnaire de la fonction. Une fois l’exécution de la fonction terminée, Lambda se prépare à gérer un autre appel de fonction.

• Shutdown: cette phase se déclenche si la fonction Lambda ne reçoit aucun appel pendant un certain temps. Au cours de la phase Shutdown, Lambda arrête l’exécution, alerte les extensions pour les laisser s’arrêter proprement, puis supprime l’environnement. Lambda envoie à chaque extension un événement Shutdown indiquant que l’environnement est sur le point d’être arrêté.

Chaque phase commence par un événement que Lambda envoie à l’exécution et à toutes les extensions enregistrées. L’exécution et chaque extension indiquent la fin de l’opération en envoyant une demande d’API Next. Lambda gèle l’environnement d’exécution lorsque l’exécution de chaque extension est terminée, et qu’il n’y a pas d’événement en attente.

Phase d’initialisation

Dans la phase Init, Lambda effectue trois tâches :

• Démarrage de toutes les extensions (Extension init)

• Amorçage de l’exécution (Runtime init)

• Exécution du code statique de la fonction (Function init)

La phase Init se termine lorsque l’exécution et toutes les extensions signalent qu’elles sont prêtes en envoyant une demande d’API Next. La phase Init est limitée à 10 secondes. Si les trois tâches ne se terminent pas dans les 10 secondes, Lambda relance la phase Init au moment du premier appel de fonction.

Phase d’appel

Quand une fonction Lambda est appelée en réponse à une demande d’API Next, Lambda envoie un événement Invoke à l’exécution et à chaque extension.

Le paramètre d’expiration de la fonction limite la durée de l’ensemble de la phase Invoke. Par exemple, si vous définissez le délai d’expiration de la fonction sur 360 secondes, la fonction et toutes les extensions doivent être terminées dans un délai de 360 secondes. Notez qu’il n’y a pas de phase post-appel indépendante. La durée correspond à la somme de tous les temps d’appel (exécution + extensions) et n’est calculée que lorsque l’exécution de la fonction et de toutes les extensions est terminée.

La phase d’appel prend fin lorsque l’exécution et toutes les extensions signalent qu’ils ont terminé en envoyant une demande d’API Next.

Si la fonction Lambda se bloque ou expire pendant la phase Invoke, Lambda réinitialise l’environnement d’exécution. La réinitialisation se comporte comme un événement Shutdown. Tout d’abord, Lambda arrête l’exécution. Lambda envoie ensuite un événement Shutdown à chaque extension externe enregistrée. L’événement comprend le motif de l’arrêt. Si un autre Invoke événement entraîne la réutilisation de cet environnement d’exécution, Lambda initialise l’exécution et les extensions dans le cadre de l’appel suivant.

Note

La réinitialisation Lambda n’efface pas le contenu /tmp du répertoire avant la phase d’initialisation suivante. Ce comportement est cohérent avec la phase d’arrêt normale.

Phase d’arrêt

Quand Lambda est sur le point d’arrêter l’exécution, il envoie un événement Shutdown à chaque extension externe enregistrée. Les extensions peuvent utiliser ce temps pour les tâches de nettoyage final. L’événement Shutdown est une réponse à une Nextdemande d’API.

Durée : l’ensemble de la phase Shutdown est limitée à 2 secondes. Si l’exécution ou une extension ne répondent pas, Lambda y met fin via un signal (SIGKILL).

Lorsque la fonction et toutes les extensions ont pris fin, Lambda conserve l’environnement d’exécution pendant un certain temps en prévision d’un autre appel de fonction. En effet, Lambda bloque l’environnement d’exécution. Lorsque la fonction est appelée à nouveau, Lambda réactive l’environnement pour la réutilisation. La réutilisation de l’environnement d’exécution a les conséquences suivantes :

• Les objets déclarés en dehors de la méthode de gestionnaire de la fonction restent initialisés, ce qui fournit une optimisation supplémentaire lorsque la fonction est appelée à nouveau. Par exemple, si votre fonction Lambda établit une connexion de base de données, au lieu de rétablir la connexion, la connexion d’origine est utilisée dans les appels suivants. Nous vous recommandons d’ajouter une logique dans votre code pour vérifier s’il existe une connexion avant d’en créer une nouvelle.

• Chaque environnement d’exécution fournit 512 Mo and 10 240 Mo, par incréments de 1 Mo d’espace disque dans le répertoire /tmp. Le contenu du répertoire est conservé lorsque l’environnement d’exécution est gelé, fournissant ainsi un cache temporaire qui peut servir à plusieurs appels. Vous pouvez ajouter du code pour vérifier si le cache contient les données que vous avez stockées. Pour de plus amples informations sur les limites de taille de déploiement, veuillez consulter Quotas Lambda.

• Les processus en arrière-plan ou les rappels qui ont été initiés par votre fonction Lambda et qui ne sont pas terminés à la fin de l’exécution de la fonction reprennent si Lambda réutilise l’environnement d’exécution. Assurez-vous que les processus d’arrière-plan ou les rappels dans votre code se terminent avant que l’exécution du code ne prenne fin.

Lorsque vous écrivez votre code de fonction, ne partez pas du principe que Lambda réutilise automatiquement l’environnement d’exécution pour les appels de fonction suivants. D’autres facteurs peuvent amener Lambda à créer un nouvel environnement d’exécution, ce qui peut entraîner des résultats inattendus, tels que des échecs de connexion de base de données.