Comprendre le cycle de vie de l'environnement d'exécution Lambda

Lambda invoque 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.

Phase d’initialisation

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

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 de la première invocation de fonction avec le délai d’attente de fonction configuré.

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’environnement d’exécution avant le point de contrôle, le code s’exécute alors à la fin de la phase Init.

Lorsque vous utilisez la simultanéité provisionnée, Lambda initialise l’environnement d’exécution lorsque vous configurez les paramètres du PC pour une fonction. Lambda garantit également que les environnements d’exécution initialisés sont toujours disponibles avant les invocations. Vous pouvez constater des écarts entre les phases d’initialisation et d’invocation de votre fonction. En fonction de la configuration d’environnement d’exécution et de mémoire de votre fonction, vous pouvez également constater une variabilité de latence est possible lors de la première invocation dans un environnement d’exécution initialisé.

Pour les fonctions utilisant la simultanéité à la demande, Lambda peut occasionnellement initialiser les environnements d’exécution avant les demandes d’invocation. Lorsque cela se produit, vous pouvez également observer un intervalle de temps inattendu entre les phases d’initialisation et d’invocation de votre fonction. Nous vous recommandons de ne pas dépendre de ce comportement.

Échecs pendant la phase d’initialisation

Si une fonction se bloque ou expire pendant la phase Init, Lambda émet des informations d’erreur dans le journal INIT_REPORT.

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Si la Init phase est réussie, Lambda n'émet le INIT_REPORT journal que si la simultanéité SnapStartprovisionnée est activée. SnapStart et les fonctions de simultanéité provisionnées émettent toujours. INIT_REPORT Pour de plus amples informations, veuillez consulter Surveillance pour Lambda SnapStart.

Phase de restauration (Lambda uniquement SnapStart )

Lorsque vous appelez une SnapStartfonction pour la première fois et que celle-ci évolue, 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 disposez d'un hook d'exécution après restauration, le code s'exécute à la fin de la Restore phase. Vous êtes facturé pour la durée des hooks d'exécution après la restauration. Le runtime doit se charger et les hooks d'exécution après restauration doivent être terminés dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException. Lorsque la phase Restore se termine, Lambda invoque le gestionnaire de fonction (Phase d’invocation).

Échecs pendant la phase de restauration

Si la phase Restore échoue, Lambda émet des informations d’erreur dans le journal RESTORE_REPORT.

RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout

RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Pour plus d’informations sur le journal RESTORE_REPORT, consultez Surveillance pour Lambda SnapStart.

Phase d’invocation

Quand une fonction Lambda est invoqué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-invocation indépendante. La durée correspond à la somme de tous les temps d’invocation (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’invocation prend fin lorsque l’exécution et toutes les extensions signalent qu’ils ont terminé en envoyant une demande d’API Next.

Échecs pendant la phase d’invocation

Si la fonction Lambda se bloque ou expire pendant la phase Invoke, Lambda réinitialise l’environnement d’exécution. Le diagramme suivant illustre le comportement de l’environnement d’exécution Lambda en cas d’échec de l’invocation :

Dans le diagramme précédent :

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’une autre invocation de fonction. Cependant, Lambda met fin aux environnements d’exécution toutes les quelques heures pour permettre les mises à jour et la maintenance de l’environnement d’exécution, même pour les fonctions invoquées en continu. Vous ne devez pas partir du principe que l’environnement d’exécution sera conservé indéfiniment. Pour de plus amples informations, veuillez consulter Intégrer l'apatridie dans les fonctions.

Lorsque la fonction est invoqué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 :

Démarrages à froid et latence

Lorsque Lambda reçoit une demande pour exécuter une fonction via l'API Lambda, le service prépare d'abord un environnement d'exécution. Au cours de cette phase d'initialisation, le service télécharge votre code, démarre l'environnement et exécute tout code d'initialisation en dehors du gestionnaire principal. Enfin, Lambda exécute le code du gestionnaire.

Dans ce schéma, les deux premières étapes du téléchargement du code et de la configuration de l'environnement sont souvent appelées « démarrage à froid ». Ce délai ne vous est pas facturé, mais cela ajoute de la latence à la durée globale de votre invocation.

Une fois l'invocation terminée, l'environnement d'exécution est gelé. Pour améliorer la gestion des ressources et les performances, Lambda conserve l'environnement d'exécution pendant un certain temps. Pendant ce temps, si une autre demande arrive pour la même fonction, Lambda peut réutiliser l'environnement. Cette deuxième demande se termine généralement plus rapidement, car l'environnement d'exécution est déjà entièrement configuré. C’est ce qu’on appelle un « démarrage à chaud ».

Les démarrages à froid se produisent généralement dans moins de 1 % des invocations. La durée d’un démarrage à froid varie de moins de 100 ms à plus d’une seconde. En général, les démarrages à froid sont plus courants dans les fonctions de développement et de test que dans les charges de travail de production. Cela est dû au fait que les fonctions de développement et de test sont généralement invoquées moins fréquemment.

Réduction des démarrages à froid avec la simultanéité provisionnée

Si vous avez besoin d'heures de démarrage des fonctions prévisibles pour votre charge de travail, la simultanéité provisionnée est la solution recommandée pour garantir la latence la plus faible possible. Cette fonctionnalité pré-initialise les environnements d'exécution, réduisant ainsi les démarrages à froid.

Par exemple, une fonction avec une simultanéité provisionnée de 6 possède 6 environnements d'exécution préchauffés.

Optimisation de l’initialisation statique

L’initialisation statique se produit avant que le code du gestionnaire ne commence à s’exécuter dans une fonction. Il s'agit du code d'initialisation que vous fournissez, qui se trouve en dehors du gestionnaire principal. Ce code est souvent utilisé pour importer des bibliothèques et des dépendances, configurer des configurations et initialiser des connexions à d'autres services.

L'exemple Python suivant montre l'importation et la configuration de modules, ainsi que la création du client Amazon S3 pendant la phase d'initialisation, avant que la lambda_handler fonction ne s'exécute pendant l'appel.

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

Le principal facteur de latence avant l'exécution d'une fonction provient du code d'initialisation. Ce code s'exécute lorsqu'un nouvel environnement d'exécution est créé pour la première fois. Le code d’initialisation n’est pas exécuté à nouveau si une invocation utilise un environnement d’exécution chaud. Les facteurs qui influent sur la latence du code d'initialisation sont notamment les suivants :

Les développeurs peuvent prendre un certain nombre de mesures pour optimiser la latence d'initialisation statique. Si une fonction comporte de nombreux objets et connexions, vous pouvez peut-être réarchitecturer une seule fonction en plusieurs fonctions spécialisées, Ils sont individuellement plus petits et contiennent chacun moins de code d'initialisation.

Il est important que les fonctions n’importent que les bibliothèques et les dépendances dont elles ont besoin. Par exemple, si vous utilisez Amazon DynamoDB uniquement dans AWS le SDK, vous pouvez avoir besoin d'un service individuel au lieu du SDK complet. Voici trois exemples de comparaison :

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

L'initialisation statique est également souvent le meilleur endroit pour ouvrir des connexions à des bases de données afin de permettre à une fonction de réutiliser les connexions via plusieurs invocations dans le même environnement d'exécution. Cependant, il se peut que vous disposiez d’un grand nombre d’objets qui ne sont utilisés que dans certains chemins d’exécution de votre fonction. Dans ce cas, vous pouvez charger de manière différée des variables dans la portée globale afin de réduire la durée d’initialisation statique.

Évitez les variables globales pour obtenir des informations spécifiques au contexte. Si votre fonction possède une variable globale qui n’est utilisée que pendant la durée de vie d’une seule invocation et qui est réinitialisée pour la prochaine invocation, utilisez une portée de variable locale au gestionnaire. Cela permet non seulement d’éviter les fuites de variables globales lors des invocations, mais également d’améliorer les performances d’initialisation statique.