Environnement d'exécution Lambda

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 journal et d'autres télémétries de la fonction en utilisant l'API de télémétrie.

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.

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

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.

Rubriques

• Phase d’initialisation
• Phase de restauration (Lambda SnapStart uniquement)
• Phase d’appel
• Phase d’arrêt

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)

• Exécuter n'importe quel hook d'exécution beforeCheckpoint (Lambda SnapStart uniquement)

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.

Lorsque Lambda SnapStart est activé, la phase Init se produit lorsque vous publiez une version de la fonction. Lambda enregistre un instantané de l'état de la mémoire et du disque de l'environnement d'exécution initialisé, fait persister l'instantané chiffré et le met en cache pour un accès à faible latence. Si vous avez un hook d'exécution beforeCheckpoint, le code s'exécute à la fin de la phase Init.

Note

Le délai de 10 secondes ne s'applique pas aux fonctions SnapStart. Lorsque Lambda crée un instantané, votre code d'initialisation peut s'exécuter jusqu'à 15 minutes. Le délai d'attente est de 130 secondes ou le délai d'expiration de la fonction configurée (900 secondes au maximum), la valeur la plus élevée étant retenue.

Phase de restauration (Lambda SnapStart uniquement)

Lorsque vous appelez pour la première fois une fonction SnapStart et à mesure que la fonction augmente, Lambda reprend les nouveaux environnements d'exécution à partir de l'instantané persistant au lieu d'initialiser la fonction à partir de zéro. Si vous avez un hook d'exécution afterRestore(), le code s'exécute à la fin de la phase Restore. Vous êtes facturé pour la durée des hooks d'exécution afterRestore(). L'environnement d'exécution (JVM) doit se charger et les hooks d'exécution afterRestore() doivent se terminer dans le délai imparti (2 secondes). Sinon, vous obtiendrez une SnapStartTimeoutException. Lorsque la phase Restore se termine, Lambda appelle le gestionnaire de fonction (la phase Invoke).

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 entre 512 Mo et 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.