View a markdown version of this page

Cycle de vie des environnements d'exécution - AWS Lambda
Phases du cycle de vieInitialisation (démarrage à froid)Scale-down et arrêtRéutilisation de l'environnementGestion des demandes simultanées

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.

Cycle de vie des environnements d'exécution

Un environnement d'exécution est une instance de calcul isolée qui exécute votre serveur HTTP. AWS Lambda crée des environnements d'exécution pour votre fonction Web Lambda lorsque le trafic arrive. Il achemine les demandes vers des environnements actifs et supprime les environnements qui ne sont plus nécessaires. Comprendre ce cycle de vie vous permet d'optimiser les performances de démarrage et d'écrire du code qui gère correctement l'initialisation et l'arrêt.

Phases du cycle de vie

Chaque environnement d'exécution passe par les phases suivantes :

Les trois phases de l'environnement d'exécution : Initialisation, Prêt et Arrêt.
Phase Que se passe-t-il Traitement des demandes
Initialisation Lambda charge votre code, prépare le runtime et démarre le processus de votre serveur HTTP. Votre serveur doit commencer à écouter l'adresse AWS_LAMBDA_HTTP_ENDPOINT dans les 10 secondes. L'environnement ne peut pas répondre aux demandes lors de l'initialisation.
Prêt Votre serveur HTTP écoute et l'environnement est disponible pour recevoir des requêtes. Lambda achemine les demandes entrantes vers cet environnement. L'environnement accepte les demandes dans la maxConcurrencyPerEnvironment limite maximale.
Arrêter Lambda arrête d'acheminer les nouvelles demandes vers l'environnement, laisse les demandes en cours de traitement se terminer au mieuxSIGTERM, envoie puis met fin à l'environnement. Aucune nouvelle demande n'est acheminée vers l'environnement. In-flight les demandes peuvent continuer, mais leur achèvement n'est pas garanti. EnsuiteSIGTERM, le processus dispose d'une seconde pour terminer le nettoyage. L'état du processus est perdu.

Initialisation (démarrage à froid)

Lorsque Lambda crée un nouvel environnement d'exécution, la phase d'initialisation inclut les étapes suivantes :

  1. Lambda charge le code depuis votre package de déploiement .zip.

  2. Lambda configure l'environnement d'exécution (y compris vos variables Node.js d'environnement).

  3. Lambda lance votre processus de candidature.

  4. Votre serveur HTTP commence à écouter sur l'hôte et le port spécifiés par la variable d'AWS_LAMBDA_HTTP_ENDPOINTenvironnement. Il doit commencer à écouter dans les 10 secondes.

  5. Lambda détecte que votre serveur écoute et marque l'environnement comme étant prêt.

Un démarrage à froid se produit lorsque Lambda doit créer un nouvel environnement pour traiter une demande car aucun environnement n'est disponible. La première demande après un démarrage à froid subit une latence supplémentaire dès la phase d'initialisation. Les demandes ultérieures adressées au même environnement n'entraînent pas ce coût.

Pour réduire l'impact du démarrage à froid :

  • Minimisez la taille de votre package de déploiement. Les petits paquets se chargent plus rapidement.

  • Réduisez le temps de démarrage du serveur. Différez les initialisations lourdes (telles que le chargement de gros fichiers de données) jusqu'à ce que le serveur commence à écouter. Lambda achemine les requêtes vers l'environnement dès que le serveur les écoute, alors obligez les gestionnaires de demandes qui dépendent du travail différé à attendre la fin de celui-ci, par exemple en attendant une promesse partagée.

  • Utilisez l'initialisation différée pour les connexions aux bases de données et les clients de services externes. Établissez des connexions à la première demande plutôt qu'au démarrage.

Scale-down et arrêt

Lambda surveille l'utilisation de l'environnement de votre point de terminaison et supprime les environnements inutiles, par exemple lorsque le trafic diminue. Avant de supprimer un environnement, Lambda utilise la séquence d'arrêt suivante :

  1. Lambda arrête d'acheminer les nouvelles demandes vers l'environnement.

  2. Lambda permet de traiter les demandes en vol dans les meilleures conditions.

  3. Lambda envoie. SIGTERM Le processus dispose d'une seconde pour terminer le nettoyage avant que Lambda ne l'arrête et ne supprime l'environnement.

Lorsqu'il n'y a pas de trafic, Lambda adapte votre fonction Web à zéro environnement. La demande suivante après une période d'échelle allant jusqu'à zéro déclenche un nouveau démarrage à froid.

Si votre application doit effectuer un nettoyage pendant l'arrêt, faites-le. SIGTERM Le nettoyage doit être terminé dans un délai d'une seconde. Ne vous fiez pas à l'exécution de rappels d'arrêt, car Lambda ne peut garantir un arrêt progressif dans tous les modes de défaillance, par exemple en cas de panne matérielle sous-jacente.

L'exemple suivant gère SIGTERM :

process.on('SIGTERM', () => {
  // Finish short cleanup, such as flushing buffered logs, within 1 second.
  process.exit(0);
});

Réutilisation de l'environnement

Lambda réutilise les environnements d'exécution pour plusieurs requêtes afin d'éviter les démarrages à froid répétés. Un environnement unique peut répondre à des milliers de demandes au cours de sa durée de vie. Autrement dit :

  • L'état global persiste : les variables, les caches et les connexions que votre serveur initialise au démarrage sont conservés dans toutes les demandes. Vous pouvez l'utiliser pour la mise en cache en mémoire ou le regroupement de connexions.

  • L'état du système de fichiers persiste : les fichiers que votre code écrit dans le système de fichiers local (tels que/tmp) sont conservés jusqu'à ce que Lambda supprime l'environnement.

  • Aucune durée de vie garantie : Lambda peut supprimer un environnement à tout moment. Ne vous fiez pas à un environnement qui dure pendant une certaine durée. Conservez les données importantes dans un magasin externe tel que DynamoDB ou Amazon S3.

Gestion des demandes simultanées

Chaque environnement d'exécution de fonction Web gère plusieurs requêtes HTTP simultanées. Le maxConcurrencyPerEnvironment paramètre de révision contrôle le nombre maximum de demandes simultanées par environnement.

Étant donné que votre serveur traite plusieurs demandes simultanément, votre code doit être sûr pour une utilisation simultanée :

  • Ne stockez pas l'état de chaque demande dans des variables globales. Utilisez plutôt des variables limitées à la demande ou un contexte d'intergiciel.

  • Protégez les états mutables partagés, tels que les caches ou les compteurs, que vous modifiez au-delà des limites. await Les demandes s'entrelacent dans la boucle d'événements. Si une séquence de lecture-modification-écriture couvre une opération asynchrone, une autre demande en cours de vol peut lire ou modifier l'état avant la fin de la séquence.

  • Sachez qu'elle Node.js utilise une boucle d'événements à thread unique. CPU-intensive les opérations synchrones bloquent toutes les demandes simultanées dans cet environnement. Utilisez le mode asynchrone I/O et évitez de bloquer la boucle d'événements.

Pour plus d'informations sur les paramètres de simultanéité et l'optimisation, consultezComportement de dimensionnement pour les fonctions Web Lambda.