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.
# Fonctionnement de Lambda
Les fonctions Lambda sont les blocs de construction de base que vous utilisez pour créer des applications Lambda. Pour écrire des fonctions, il est essentiel de comprendre les concepts et composants fondamentaux du modèle de programmation Lambda. Cette section vous guidera à travers les éléments fondamentaux que vous devez connaître pour commencer à créer des applications sans serveur avec Lambda.
+ **[Fonctions Lambda et gestionnaires de fonctions](#gettingstarted-concepts-function)**- Une fonction Lambda est un petit bloc de code qui s'exécute en réponse à des événements. Les fonctions peuvent être standard (jusqu'à 15 minutes) ou [durables](durable-functions.md) (jusqu'à un an). Les fonctions sont les éléments de base que vous utilisez pour créer des applications. Les gestionnaires de fonctions constituent le point d’entrée pour les objets d’événements traités par le code de votre fonction Lambda.
+ **[Environnement d’exécution et exécutions Lambda](#gettingstarted-concepts-runtime)** : les environnements d’exécution Lambda gèrent les ressources nécessaires à l’exécution de votre fonction. Pour des [fonctions durables](durable-functions.md), l'environnement d'exécution inclut des fonctionnalités de gestion automatique de l'état et de point de contrôle. Les environnements d'exécution sont les environnements spécifiques au langage dans lesquels vos fonctions s'exécutent.
+ **[Événements et déclencheurs](#gettingstarted-concepts-event)**- D'autres Services AWS peuvent invoquer vos fonctions en réponse à des événements spécifiques. Pour des fonctions durables, les événements peuvent également déclencher la reprise des flux de travail interrompus.
+ **[Autorisations et rôles Lambda](#gettingstarted-concepts-permissions)**- Contrôlez qui peut accéder à vos fonctions et avec quelles autres Services AWS fonctions peuvent interagir. Les fonctions durables nécessitent des autorisations supplémentaires pour la gestion des états et une exécution prolongée.
**Astuce**
Si vous souhaitez commencer par comprendre le développement sans serveur de manière plus générale, consultez la section [Comprendre la différence entre le développement traditionnel et le développement sans serveur](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html) dans le *Guide du développeur AWS sans serveur*.
## Fonctions Lambda et gestionnaires de fonctions
Dans Lambda, les **fonctions** sont les blocs de construction fondamentaux que vous utilisez pour créer des applications. Une fonction Lambda est un élément de code qui s’exécute en réponse à des événements, par exemple lorsqu’un utilisateur clique sur un bouton d’un site Web ou qu’un fichier est chargé dans un compartiment Amazon Simple Storage Service (Amazon S3). Grâce à des fonctions durables, votre code peut suspendre l'exécution entre les étapes, en maintenant automatiquement l'état, ce qui le rend idéal pour les flux de travail de longue durée tels que le traitement des commandes ou la modération du contenu. Vous pouvez considérer une fonction comme une sorte de programme autonome possédant les propriétés suivantes.
Un **gestionnaire de fonction** Lambda est la méthode dans le code de votre fonction qui traite les événements. Lorsqu’une fonction s’exécute en réponse à un événement, Lambda exécute le gestionnaire de fonction. Les données relatives à l’événement à l’origine de l’exécution de la fonction sont transmises directement au gestionnaire. Là où le code d’une fonction Lambda peut contenir plusieurs méthodes ou fonctions, les fonctions Lambda ne peuvent avoir qu’un seul gestionnaire.
Pour créer une fonction Lambda, vous groupez le code de votre fonction et ses dépendances dans un package de déploiement. Lambda prend en charge deux types de packages de déploiement : les [archives de fichier .zip](configuration-function-zip.md) et les [images conteneurs](images-create.md).
+ Une fonction a une tâche ou un objectif spécifique
+ Elle ne s’exécute que lorsque cela est nécessaire en réponse à des événements spécifiques
+ Elle s’arrête automatiquement lorsqu’elle a terminé
## Environnement d’exécution et exécutions Lambda
Les fonctions Lambda s’exécutent dans un *[environnement d’exécution](lambda-runtime-environment.md)* sécurisé et isolé que Lambda gère pour vous. Pour des [fonctions durables](durable-functions.md), l'environnement d'exécution inclut des composants supplémentaires pour la gestion des états et la coordination du flux de travail. L'environnement d'exécution gère les processus et les ressources nécessaires à l'exécution de votre fonction. Lorsqu’une fonction est invoquée pour la première fois, Lambda crée un nouvel environnement d’exécution dans lequel la fonction doit s’exécuter. Une fois l’exécution de la fonction terminée, Lambda n’arrête pas immédiatement l’environnement d’exécution ; si la fonction est à nouveau invoquée, Lambda peut réutiliser l’environnement d’exécution existant.
L’environnement d’exécution Lambda contient également un *environnement d’exécution spécifique au langage (runtime)*, qui relaie les informations d’un événement et les réponses entre Lambda et votre fonction. Lambda fournit un certain nombre d’[environnements d’exécution gérés](lambda-runtimes.md#runtimes-supported) pour les langages de programmation les plus courants, ou vous pouvez créer les vôtres.
Pour les environnements d’exécution gérés, Lambda applique automatiquement les mises à jour de sécurité et correctifs aux fonctions lors de l’exécution.
## Événements et déclencheurs
Vous pouvez également appeler une fonction Lambda directement à l'aide de la console Lambda ou de l'un des kits de [développement AWS logiciel](https://aws.amazon.com/developer/tools/) (). [AWS CLI](https://aws.amazon.com/cli/)SDKs Dans une application de production, il est plus courant que votre fonction soit invoquée par une autre Service AWS en réponse à un événement particulier. Par exemple, vous souhaiterez peut-être qu’une fonction s’exécute chaque fois qu’un élément est ajouté à une table Amazon DynamoDB.
Pour que votre fonction réagisse aux événements, vous devez configurer un **déclencheur**. Un déclencheur connecte votre fonction à une source d’événements, et votre fonction peut avoir plusieurs déclencheurs. Lorsqu’un événement se produit, Lambda reçoit les données de l’événement sous forme de document JSON et les convertit en un objet que votre code peut traiter. Vous pouvez définir le format JSON suivant pour votre événement, et l’environnement d’exécution Lambda convertit ce JSON en objet avant de le transmettre au gestionnaire de votre fonction.
**Example événement lambda personnalisé**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Les services de streaming et de file d'attente tels qu'Amazon Kinesis ou Amazon SQS utilisent [un mappage des sources d'événements au lieu d'un](invocation-eventsourcemapping.md) déclencheur standard. Les mappages des sources d’événements interrogent la source à la recherche de nouvelles données, regroupent les enregistrements, puis invoquent votre fonction avec les événements par lots. Pour de plus amples informations, veuillez consulter [Différence entre les mappages de sources d’événements et les déclencheurs directs](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Pour comprendre le fonctionnement d’un déclencheur, commencez par suivre le didacticiel [Utiliser un déclencheur Amazon S3](with-s3-example.md) ou, pour obtenir une présentation générale de l’utilisation des déclencheurs et des instructions sur la création d’un déclencheur à l’aide de la console Lambda, consultez [Intégration d’autres services](lambda-services.md).
## Autorisations et rôles Lambda
Pour Lambda, il existe deux principaux types d’[autorisations](permissions-granting-access.md) que vous devez configurer :
+ Autorisations dont votre fonction a besoin pour accéder à d'autres Services AWS
+ Autorisations dont les autres utilisateurs Services AWS ont besoin pour accéder à votre fonction
Les sections suivantes décrivent ces deux types d’autorisations et décrivent les meilleures pratiques pour appliquer les autorisations de moindre privilège.
### Autorisations permettant aux fonctions d'accéder à d'autres AWS ressources
Les fonctions Lambda ont souvent besoin d'accéder à d'autres AWS ressources et d'effectuer des actions sur celles-ci. Par exemple, une fonction peut lire des éléments d’une table DynamoDB, stocker un objet dans un compartiment S3 ou écrire dans une file d’attente Amazon SQS. Pour donner aux fonctions les autorisations dont elles ont besoin pour effectuer ces actions, vous utilisez un *[rôle d’exécution](lambda-intro-execution-role.md)*.
*Un rôle d'exécution Lambda est un type spécial de [rôle Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) (IAM), une identité que vous créez dans votre compte et à laquelle des autorisations spécifiques sont associées, définies dans une politique.*
Chaque fonction Lambda doit avoir un rôle d’exécution, et un même rôle peut être utilisé par plusieurs fonctions. Lorsqu’une fonction est invoquée, Lambda assume le rôle d’exécution de la fonction et est autorisé à effectuer les actions définies dans la politique du rôle.
Lorsque vous créez une fonction dans la console Lambda, Lambda crée automatiquement un rôle d’exécution pour votre fonction. La politique du rôle donne à votre fonction les autorisations de base pour écrire les sorties de journal dans Amazon CloudWatch Logs. Pour autoriser votre fonction à effectuer des actions sur d'autres AWS ressources, vous devez modifier le rôle afin d'ajouter les autorisations supplémentaires. Le moyen le plus simple d'ajouter des autorisations consiste à utiliser une [politique AWS gérée](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies). Les politiques gérées sont créées et administrées par de nombreux cas d'utilisation courants AWS et fournissent des autorisations pour de nombreux cas d'utilisation courants. Par exemple, si votre fonction effectue des opérations CRUD sur une table DynamoDB, vous pouvez ajouter [AmazonDynamoDBFullla](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) politique d'accès à votre rôle.
### Autorisations permettant à d’autres utilisateurs et ressources d’accéder à votre fonction
Pour accorder d'autres Service AWS autorisations d'accès à votre fonction Lambda, vous devez utiliser une politique basée sur les *[ressources](access-control-resource-based.md)*. Dans IAM, les politiques basées sur les ressources sont attachées à une ressource (dans ce cas, votre fonction Lambda) et définissent qui peut accéder à la ressource et quelles actions peuvent être effectuées.
Pour Service AWS qu'une autre personne invoque votre fonction via un déclencheur, la politique basée sur les ressources de votre fonction doit autoriser ce service à utiliser l'`lambda:InvokeFunction`action. Si vous créez le déclencheur à l’aide de la console, Lambda ajoute automatiquement cette autorisation pour vous.
Pour autoriser d'autres AWS utilisateurs à accéder à votre fonction, vous pouvez le définir dans la politique basée sur les ressources de votre fonction exactement de la même manière que pour une autre fonction Service AWS ou ressource. Vous pouvez également utiliser une *[politique basée sur l’identité](access-control-identity-based.md)* associée à l’utilisateur.
### Bonnes pratiques relatives aux autorisations Lambda
Lorsque vous définissez des autorisations avec des stratégies IAM, la [bonne pratique de sécurité](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) est d’accorder uniquement les autorisations nécessaires à l’exécution d’une seule tâche. C’est ce que l’on appelle le principe du *moindre privilège*. Pour commencer à accorder des autorisations pour votre fonction, vous pouvez choisir d'utiliser une politique AWS gérée. Les politiques gérées peuvent être le moyen le plus rapide et le plus simple d’accorder des autorisations pour effectuer une tâche, mais elles peuvent également inclure d’autres autorisations dont vous n’avez pas besoin. À mesure que vous passez du stade initial du développement aux tests et à la production, nous vous recommandons de limiter les autorisations aux seules autorisations nécessaires en définissant vos propres [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies).
Le même principe s’applique lorsque vous accordez des autorisations d’accès à votre fonction à l’aide d’une politique basée sur les ressources. Par exemple, si vous souhaitez autoriser Amazon S3 à appeler votre fonction, la meilleure pratique consiste à limiter l'accès à des compartiments individuels, ou à des compartiments en particulier Comptes AWS, plutôt que d'accorder des autorisations générales au service S3.
# Exécution de code avec Lambda
Lorsque vous écrivez une fonction Lambda, vous créez du code qui s’exécute dans un environnement sans serveur unique. Comprendre comment Lambda exécute réellement votre code implique deux aspects essentiels : le modèle de programmation, qui définit la façon dont votre code interagit avec Lambda, et le cycle de vie de l’environnement d’exécution, qui détermine la manière dont Lambda gère l’environnement d’exécution de votre code.
## Le modèle de programmation Lambda
Le modèle de programmation fonctionne comme un ensemble de règles communes régissant la façon dont Lambda fonctionne avec votre code, que vous écriviez en Python, en Java ou dans tout autre langage pris en charge. Le modèle de programmation inclut votre environnement d’exécution et votre gestionnaire.
**Pour les fonctions standard :**
1. Lambda reçoit un événement.
1. Lambda utilise le runtime pour préparer l'événement dans un format que votre code peut utiliser.
1. L’environnement d’exécution envoie l’événement formaté à votre gestionnaire.
1. Votre gestionnaire traite l'événement en utilisant le code que vous avez écrit.
**Pour des fonctions durables :**
1. Lambda reçoit un événement
1. Le runtime prépare à la fois l'événement et DurableContext
1. Votre gestionnaire peut :
+ Étapes du processus avec point de contrôle automatique
+ Interrompre l'exécution sans consommer de ressources
+ CV du dernier point de contrôle réussi
+ Maintenir l'état entre les étapes
Le *gestionnaire*, auquel Lambda envoie des événements à traiter par votre code, est essentiel à ce modèle. Considérez-le comme le point d’entrée de votre code. Lorsque Lambda reçoit un événement, il le transmet à votre gestionnaire avec certaines informations contextuelles. Le gestionnaire exécute ensuite votre code pour traiter ces événements. Par exemple, il peut lire un fichier lorsqu’il est chargé sur Amazon S3, analyser une image ou mettre à jour une base de données. Une fois que votre code a fini de traiter un événement, le gestionnaire est prêt à traiter le suivant.
## Le modèle d’exécution Lambda
Alors que le modèle de programmation définit la manière dont Lambda interagit avec votre code, l'environnement d'exécution est l'endroit où Lambda exécute réellement votre fonction. Il s'agit d'un espace de calcul sécurisé et isolé créé spécifiquement pour votre fonction.
**Chaque environnement suit un cycle de vie qui varie entre des fonctions standard et durables :**
**Fonctions standard (jusqu'à 15 minutes) :**
1. **Initialisation :** configuration de l'environnement et chargement du code
1. **Invocation :** exécution unique du code de fonction
1. **Arrêt :** nettoyage de l'environnement
**Fonctions durables (jusqu'à 1 an) :**
1. **Initialisation : configuration** de l'environnement et de l'état durable
1. **Invocation :** plusieurs étapes avec point de contrôle automatique
1. **États d'attente :** pause de l'exécution sans consommation de ressources
1. **Reprise :** Redémarrer depuis le dernier point de contrôle
1. **Arrêt :** nettoyage de l'état durable
Cet environnement gère les aspects importants de l’exécution de votre fonction. Il fournit à votre fonction de la mémoire et un répertoire `/tmp` pour le stockage temporaire. **Pour les fonctions durables, il gère également :**
+ Persistance automatique de l'état entre les étapes
+ Stockage et restauration aux points de contrôle
+ Coordination de l'état d'attente
+ Suivi des progrès réalisés dans le cadre des exécutions de longue durée
# Présentation du modèle de programmation Lambda
Lambda propose deux modèles de programmation : les fonctions standard qui s'exécutent jusqu'à 15 minutes et les fonctions durables qui peuvent fonctionner jusqu'à un an. Bien que les deux partagent des concepts fondamentaux, les fonctions durables ajoutent des fonctionnalités pour des flux de travail dynamiques et de longue durée.
Lambda fournit un modèle de programmation commun à tous les runtimes. Le modèle de programmation définit l'interface entre votre code et le système Lambda. Vous indiquez à Lambda le point d'entrée de votre fonction en définissant un *gestionnaire* dans la configuration de la fonction. Le runtime transmet les objets au gestionnaire qui contiennent *l'événement* d'invocation et le *contexte*, tels que le nom de la fonction et l'ID de la demande.
**Pour Durable Functions, le gestionnaire reçoit également un DurableContext objet qui fournit :**
+ Capacités de point de contrôle via step ()
+ Gestion de l'état d'attente via wait () et waitForCallback ()
+ Persistance automatique de l'état entre les invocations
Lorsque le gestionnaire termine le traitement du premier événement, le runtime lui en envoie un autre. Pour les fonctions durables, le gestionnaire peut suspendre l'exécution entre les étapes, et Lambda enregistrera et rétablira automatiquement l'état lorsque la fonction reprendra. La classe de la fonction reste en mémoire, de sorte que les clients et variables déclarés en dehors de la méthode du gestionnaire dans le *code d'initialisation* peuvent être réutilisés. Pour économiser du temps de traitement sur les événements suivants, créez des ressources réutilisables telles que des clients AWS SDK lors de l'initialisation. Une fois initialisée, chaque instance de votre fonction peut traiter des milliers de demandes.
Votre fonction a également accès au stockage local dans le répertoire `/tmp`, un cache temporaire qui peut servir à plusieurs appels. Pour de plus amples informations, veuillez consulter [Environnement d’exécution](lambda-runtime-environment.md).
Lorsque le [suivi AWS X-Ray](services-xray.md) est activé, le runtime enregistre des sous-segments distincts pour l'initialisation et l'exécution.
Le moteur d'exécution capture les résultats de journalisation de votre fonction et les envoie à Amazon CloudWatch Logs. En plus de consigner la sortie de votre fonction, le runtime consigne également les entrées lorsque la fonction d’invocation démarre et se termine. Cela inclut un journal de rapport avec l'ID de demande, la durée facturée, la durée d'initialisation et d'autres détails. Si votre fonction génère une erreur, le runtime renvoie cette erreur au mécanisme d'appel.
**Note**
La journalisation est soumise à des [quotas de CloudWatch journalisation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html). Les données des journaux peuvent être perdues en raison de la limitation ou, dans certains cas, lorsqu'une instance de votre fonction est arrêtée.
**Principales différences en matière de fonctions durables :**
+ L'état est automatiquement conservé entre les étapes
+ Les fonctions peuvent suspendre l'exécution sans consommer de ressources
+ Les étapes sont automatiquement réessayées en cas d'échec
+ Les progrès sont suivis par le biais de points de contrôle
Lambda met à l'échelle votre fonction en exécutant des instances supplémentaires à mesure que la demande augmente et en arrêtant des instances à mesure que la demande diminue. Ce modèle entraîne des variations dans l'architecture des applications, telles que :
+ Sauf indication contraire, les demandes entrantes peuvent être traitées dans le désordre ou simultanément.
+ Ne comptez pas sur la longévité des instances de votre fonction, stockez plutôt l'état de votre application ailleurs.
+ Utilisez le stockage local et les objets de niveau classe afin d'améliorer les performances, mais réduisez au minimum la taille de votre package de déploiement et la quantité de données que vous transférez vers l'environnement d'exécution.
Pour une introduction pratique au modèle de programmation dans le langage de programmation de votre choix, consultez les sections suivantes.
+ [Création de fonctions Lambda avec Node.js](lambda-nodejs.md)
+ [Création de fonctions Lambda avec Python](lambda-python.md)
+ [Création de fonctions Lambda avec Ruby](lambda-ruby.md)
+ [Création de fonctions Lambda avec Java](lambda-java.md)
+ [Création de fonctions Lambda avec Go](lambda-golang.md)
+ [Création de fonctions Lambda avec C\$1](lambda-csharp.md)
+ [Création de fonctions Lambda avec PowerShell](lambda-powershell.md)
# Comprendre le cycle de vie de l’environnement d’exécution Lambda
Les environnements d'exécution Lambda prennent en charge à la fois les fonctions standard (jusqu'à 15 minutes) et les fonctions durables (jusqu'à un an). Bien que les deux aient le même cycle de vie de base, les fonctions durables ajoutent des fonctionnalités de gestion des états pour les flux de travail de longue durée.
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](lambda-extensions.md) associées à votre fonction.
**Pour Durable Functions, l'environnement d'exécution inclut des composants supplémentaires pour :**
+ Persistance de l'état entre les étapes
+ Gestion des points de contrôle
+ Coordination de l'état d'attente
+ Suivi des progrès
**Environnement d'exécution des instances gérées Lambda**
Si vous utilisez des [instances gérées Lambda](lambda-managed-instances-execution-environment.md), l'environnement d'exécution présente des différences importantes par rapport aux fonctions Lambda (par défaut). Les instances gérées prennent en charge les appels simultanés, utilisent un modèle de cycle de vie différent et s'exécutent sur une infrastructure appartenant au client. Pour des informations détaillées sur l'environnement d'exécution des instances gérées, consultez[Comprendre l'environnement d'exécution des instances gérées Lambda](lambda-managed-instances-execution-environment.md).
L’exécution de la fonction communique avec Lambda à l’aide de l’[API d’exécution](runtimes-api.md). Les extensions communiquent avec Lambda à l’aide de l’[API d’extensions](runtimes-extensions-api.md). 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](telemetry-api.md).
![\[Diagramme d’architecture de l’environnement d’exécution.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
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.
**Topics**
+ [
## Cycle de vie d’un environnement d’exécution Lambda
](#runtimes-lifecycle)
+ [
## Démarrages à froid et latence
](#cold-start-latency)
+ [
## Réduction des démarrages à froid avec la simultanéité provisionnée
](#cold-starts-pc)
+ [
## Optimisation de l’initialisation statique
](#static-initialization)
## Cycle de vie d’un environnement d’exécution Lambda
![\[Phases du cycle de vie Lambda : Init, Invoke, Shutdown\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Overview-Successful-Invokes.png)
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.
**Les phases du cycle de vie de Durable Functions incluent :**
+ **Init :** initialisation standard et configuration d'état durable
+ **Invoke :** peut inclure des exécutions en plusieurs étapes avec pointage automatique
+ **Attendre :** la fonction peut suspendre l'exécution sans consommer de ressources
+ **Reprise :** la fonction redémarre depuis le dernier point de contrôle
+ **Arrêt :** nettoyage de l'état durable et des ressources
**Topics**
+ [
### Phase d’initialisation
](#runtimes-lifecycle-ib)
+ [
### Échecs pendant la phase d’initialisation
](#runtimes-lifecycle-init-errors)
+ [
### Phase de restauration (Lambda uniquement SnapStart )
](#runtimes-lifecycle-restore)
+ [
### Phase d’invocation
](#runtimes-lifecycle-invoke)
+ [
### Échecs pendant la phase d’invocation
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Phase d’arrêt
](#runtimes-lifecycle-shutdown)
### 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écutez tous les hooks d'[exécution avant le point de contrôle (Lambda uniquement)](snapstart-runtime-hooks.md) SnapStart
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](snapstart.md) 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](snapstart-runtime-hooks.md) avant le point de contrôle, le code s’exécute alors à la fin de la phase `Init`.
**Note**
Le délai d'expiration de 10 secondes ne s'applique pas aux fonctions qui utilisent la simultanéité provisionnée SnapStart ou les instances gérées Lambda. Pour les fonctions de simultanéité provisionnée et d'instances gérées, votre code d'initialisation peut s'exécuter pendant 15 minutes maximum. SnapStart 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.
Lorsque vous utilisez la [simultanéité provisionnée](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), 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`.
**Example — Journal INIT\$1REPORT pour le délai d’expiration**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example — Journal INIT\$1REPORT en cas d’échec de l’extension**
```
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é [SnapStart](snapstart.md)[provisionnée](provisioned-concurrency.md) 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](snapstart-monitoring.md).
### Phase de restauration (Lambda uniquement SnapStart )
Lorsque vous appelez une [SnapStart](snapstart.md)fonction 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 avez un [hook d’exécution](snapstart-runtime-hooks.md) après restauration, le code s’exécute à la fin de la phase `Restore`. Vous êtes facturé pour la durée des hooks d’exécution après restauration. L’exécution doit se charger et les hooks d’exécution après restauration doivent se terminer 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](#runtimes-lifecycle-invoke)).
#### Échecs pendant la phase de restauration
Si la phase `Restore` échoue, Lambda émet des informations d’erreur dans le journal `RESTORE_REPORT`.
**Example — Journal RESTORE\$1REPORT pour le délai d’expiration**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example — Journal RESTORE\$1REPORT en cas d’échec du hook d’exécution**
```
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](snapstart-monitoring.md).
### 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 \$1 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 :
![\[Exemple d’environnement d’exécution : Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Dans le diagramme précédent :
+ La première phase est la phase **INIT**, qui s’exécute sans erreur.
+ La deuxième phase est la phase **INVOKE**, qui s’exécute sans erreur.
+ Supposons qu’à un moment donné, votre fonction rencontre un échec d’invocation (les causes courantes incluent les expirations de délai des fonctions, les erreurs d’exécution, l’épuisement de la mémoire, les problèmes de connectivité VPC, les erreurs d’autorisation, les limites de simultanéité et divers problèmes de configuration). Pour connaître la liste complète des échecs d’invocation possibles, consultez [Résoudre les problèmes d’invocation dans Lambda](troubleshooting-invocation.md). La troisième phase, intitulée **INVOKE WITH ERROR**, illustre ce scénario. Lorsque cela se produit, le service Lambda effectue une réinitialisation. La réinitialisation se comporte comme un événement `Shutdown`. Lambda commence par arrêter l’exécution, puis envoie un événement `Shutdown` à chaque extension externe enregistrée. L’événement comprend le motif de l’arrêt. Si cet environnement est utilisé pour une nouvelle invocation, Lambda réinitialise l’extension et l’exécution en même temps que l’invocation suivante.
Veuillez noter que la réinitialisation Lambda n’efface pas le contenu du répertoire `/tmp` avant la phase d’initialisation suivante. Ce comportement est cohérent avec la phase d’arrêt normale.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
Si la configuration du journal système de votre fonction est définie sur du texte brut, cette modification affecte les messages de journal capturés dans CloudWatch les journaux lorsque votre fonction rencontre un échec d'appel. Les exemples suivants montrent les sorties des journaux dans les anciens et les nouveaux formats.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
**Example CloudWatch Journalise la sortie du journal (exécution ou crash de l'extension) - ancien style**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example CloudWatch Enregistre la sortie du journal (délai d'expiration de la fonction) - ancien style**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
Le nouveau format des CloudWatch journaux inclut un `status` champ supplémentaire dans la `REPORT` ligne. Dans le cas d’un incident d’exécution ou d’extension, la ligne `REPORT` inclut également un champ `ErrorType`.
**Example CloudWatch Journalise la sortie du journal (exécution ou crash de l'extension) - nouveau style**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example CloudWatch Enregistre la sortie du journal (délai d'expiration de la fonction) - nouveau style**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ La quatrième phase représente la phase **INVOKE** qui suit immédiatement un échec de l’invocation. Ici, Lambda initialise à nouveau l’environnement en relançant la phase **INIT**. Cela s’appelle une *init supprimée*. Lorsque des initialisations supprimées se produisent, Lambda ne signale pas explicitement une phase d'initialisation **supplémentaire** dans Logs. CloudWatch Au lieu de cela, vous pouvez remarquer que la durée dans la ligne REPORT inclut une durée **INIT** supplémentaire \$1 la durée **INVOKE**. Supposons, par exemple, que les connexions suivantes s'affichent CloudWatch :
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
Dans cet exemple, la différence entre les horodatages REPORT et START est de 2,5 secondes. Cela ne correspond pas à la durée rapportée de 3022,91 millisecondes, car cela ne prend pas en compte l’**INIT** supplémentaire (init supprimé) que Lambda a effectué. Dans cet exemple, vous pouvez en déduire que la phase **INVOKE** réelle a duré 2,5 secondes.
Pour plus d’informations sur ce comportement, vous pouvez utiliser la [Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie](telemetry-api.md). L’API de télémétrie émet des événements `INIT_START`, `INIT_RUNTIME_DONE` et `INIT_REPORT` avec `phase=invoke` chaque fois que des inits supprimés se produisent entre les phases d’invocation.
+ La cinquième phase représente la phase **SHUTDOWN**, qui s’exécute sans erreur.
### 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 `Next`demande d’API.
**Limite de durée** : la durée maximale de la phase `Shutdown` dépend de la configuration des extensions enregistrées :
+ 0 ms : fonction sans extension enregistrée
+ 500 ms : fonction avec une extension interne enregistrée.
+ 2 000 ms : fonction avec une ou plusieurs extensions externes enregistrées.
Si l’environnement d’exécution ou une extension ne répondent pas à l’événement `Shutdown` dans cette limite de temps, Lambda met fin au processus à l’aide d’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 [Implémenter l’absence d’état dans les fonctions](concepts-application-design.md#statelessness-functions).
Lorsque la fonction est à nouveau invoquée, Lambda décongèle l'environnement pour le réutiliser. 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 invoqué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 invocations suivantes. 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 invocations. 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 LambdaQuotas Lambda](gettingstarted-limits.md).
+ 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.
## Démarrages à froid et latence
Lorsque Lambda reçoit une demande d’exécution d’une fonction via l’API Lambda, il 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.
![\[figure d’optimisation des perf 1\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/perf-optimize-figure-1.png)
Dans ce schéma, les deux premières étapes de téléchargement du code et de configuration de l’environnement sont souvent appelées « démarrage à froid ». [Cette durée vous est facturée](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/), et 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 retient l’environnement d’exécution pendant une période. 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, étant donné que 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 concernent moins de 1 % des invocations. La durée d’un démarrage à froid varie de moins de 100 ms à plus d’une seconde. Les démarrages à froid concernent plus souvent les fonctions de développement et de test que 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](provisioned-concurrency.md) 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 dispose de 6 environnements d’exécution préparés.
![\[figure d’optimisation des perf 4\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/perf-optimize-figure-4.png)
## 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 ; il se trouve en dehors du gestionnaire principal. Ce code est souvent utilisé pour importer des bibliothèques et des dépendances, définir les configurations et initialiser les 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 fonction `lambda_handler` ne s’exécute pendant l’invocation.
```
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 :
+ la taille du package de fonctions, en termes de bibliothèques et de dépendances importées, et de couches Lambda ;
+ la quantité de code et la tâche d’initialisation ;
+ la performance des bibliothèques et des autres services lors de la configuration de connexions et d’autres ressources.
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, chacune plus petite et contenant 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 de l'intégralité du SDK. 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 aussi souvent le meilleur moment pour ouvrir des connexions à une base 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 les 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.
# Création d’architectures guidées par les événements avec Lambda
Un événement est tout ce qui déclenche l’exécution d’une fonction Lambda. Les événements peuvent déclencher une fonction Lambda de deux manières : par invocation directe (push) et par mappage des sources d'événements (pull).
De nombreux AWS services peuvent appeler directement vos fonctions Lambda. Ces services *transmettent (push)* des événements à votre fonction Lambda. Les événements qui déclenchent des fonctions peuvent être pratiquement n'importe quoi, qu'il s'agisse d'une requête HTTP via API Gateway, d'un calendrier géré par une EventBridge règle, d'un AWS IoT événement ou d'un événement Amazon S3. Grâce au mappage des sources d’événements, Lambda récupère (*pull*) activement les événements d’une file d’attente ou d’un flux. Vous configurez Lambda pour vérifier les événements provenant d’un service pris en charge, et Lambda gère l’interrogation et l’invocation de votre fonction.
Lorsqu’ils sont transmis à votre fonction, les événements sont structurés au format JSON. La structure JSON varie en fonction du service qui la génère et du type d’événement. Alors que les appels de fonctions Lambda standard peuvent durer jusqu'à 15 minutes (ou jusqu'à un an avec des fonctions [durables)](durable-functions.md), Lambda convient parfaitement aux appels courts d'une seconde ou moins. Cela est particulièrement vrai pour les architectures axées sur les événements, où chaque fonction Lambda est traitée comme un microservice chargé d’exécuter un ensemble restreint d’instructions spécifiques.
**Note**
Les architectures guidées par les événements communiquent entre différents systèmes à l’aide de réseaux, ce qui introduit une latence variable. Pour les charges de travail nécessitant une très faible latence, telles que les systèmes de trading en temps réel, cette conception n'est peut-être pas le meilleur choix. Toutefois, pour les charges de travail hautement évolutives et disponibles, ou celles dont les modèles de trafic sont imprévisibles, les architectures guidées par les événements peuvent constituer un moyen efficace de répondre à ces demandes.
**Topics**
+ [
## Avantages des architectures guidées par les événements
](#event-driven-benefits)
+ [
## Compromis des architectures guidées par les événements
](#event-driven-tradeoffs)
+ [
## Anti-modèles dans les applications pilotées par les événements basées sur Lambda
](#event-driven-anti-patterns)
## Avantages des architectures guidées par les événements
Lambda prend en charge deux méthodes d’invocation dans les architectures pilotées par les événements :
1. Invocation directe (méthode push) : les AWS services déclenchent directement les fonctions Lambda. Par exemple :
+ Amazon S3 déclenche une fonction lorsqu’un fichier est chargé
+ API Gateway déclenche une fonction lors de la réception d’une requête HTTP
1. Mappage des sources d’événements (méthode pull) : Lambda récupère les événements et invoque des fonctions. Par exemple :
+ Lambda récupère les messages d’une file d’attente Amazon SQS et invoque une fonction
+ Lambda lit les enregistrements d’un flux DynamoDB et invoque une fonction
Les deux méthodes contribuent aux avantages des architectures guidées par les événements, comme décrit ci-dessous.
### Remplacement des interrogations et des webhooks par des événements
De nombreuses architectures traditionnelles utilisent des mécanismes d’interrogation et de webhook pour communiquer l’état entre différents composants. L’interrogation peut s’avérer très inefficace pour récupérer les mises à jour, car il existe un décalage entre la mise à disposition des nouvelles données et la synchronisation avec les services en aval. Les webhooks ne sont pas toujours pris en charge par les autres microservices auxquels vous souhaitez vous intégrer. Ils peuvent également nécessiter des configurations d'autorisation et d'authentification personnalisées. Dans les deux cas, il est difficile de mettre à l’échelle ces méthodes d’intégration à la demande sans travail supplémentaire de la part des équipes de développement.
![\[architectures guidées par les événements (illustration 7)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Ces deux mécanismes peuvent être remplacés par des événements, qui peuvent être filtrés, acheminés et redirigés en aval vers les microservices consommateurs. Cette approche peut entraîner une réduction de la consommation de bande passante, de l’utilisation du processeur et potentiellement une baisse des coûts. Ces architectures peuvent également réduire la complexité, étant donné que chaque unité fonctionnelle est plus petite et qu’il y a souvent moins de code.
![\[architectures guidées par les événements (illustration 8)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
Les architectures axées sur les événements peuvent également faciliter la conception de near-real-time systèmes, aidant ainsi les entreprises à s'éloigner du traitement par lots. Les événements sont générés au moment où l’état de l’application change. Le code personnalisé d’un microservice doit donc être conçu pour gérer le traitement d’un seul événement. La mise à l’échelle étant gérée par le service Lambda, cette architecture peut gérer des augmentations significatives du trafic sans modifier le code personnalisé. Au fur et à mesure que les événements augmentent verticalement, la couche de calcul qui les traite augmente également.
### Réduction de la complexité
Les microservices permettent aux développeurs et aux architectes de simplifier les flux de travail complexes. Par exemple, un monolithe de commerce électronique peut être divisé en processus d'acceptation des commandes et de paiement avec des services d'inventaire, d'exécution et de comptabilité distincts. Ce qui peut s'avérer complexe à gérer et à orchestrer dans un monolithe devient une série de services découplés qui communiquent de manière asynchrone avec les événements.
![\[architectures guidées par les événements (illustration 9)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Cette approche permet également d’assembler des services qui traitent les données à des rythmes différents. Dans ce cas, un microservice d'acceptation des commandes peut stocker de gros volumes de commandes entrantes en mettant les messages en mémoire tampon dans une file d'attente Amazon SQS.
Un service de traitement des paiements, qui est généralement plus lent en raison de la complexité du traitement des paiements, peut recevoir un flux constant de messages provenant de la file d'attente Amazon SQS. Il peut orchestrer une logique complexe de gestion des nouvelles tentatives et des erreurs en utilisant AWS Step Functions et en coordonnant les flux de paiement actifs pour des centaines de milliers de commandes.
**Approche alternative :** pour l'orchestration à l'aide de langages de programmation standard, vous pouvez utiliser les fonctions [durables Lambda](durable-functions.md). Des fonctions durables vous permettent d'écrire la logique d'acceptation des commandes, de traitement des paiements et de notification dans un code avec pointage automatique et nouvelle tentative. Cette approche fonctionne bien lorsque le flux de travail implique principalement des fonctions Lambda et que vous préférez conserver la logique d'orchestration dans le code.
### Amélioration de la capacité de mise à l’échelle et de l’extensibilité
Les microservices génèrent des événements qui sont généralement publiés sur des services de messagerie tels qu’Amazon SNS et Amazon SQS. Ils se comportent comme une mémoire tampon élastique entre les microservices et aident à gérer la mise à l’échelle lorsque le trafic augmente. Des services tels qu'Amazon EventBridge peuvent ensuite filtrer et acheminer les messages en fonction du contenu de l'événement, tel que défini dans les règles. Par conséquent, les applications basées sur les événements peuvent être plus évolutives et offrir une meilleure redondance que les applications monolithiques.
Ce système est également très extensible, ce qui permet aux autres équipes d’étendre les fonctionnalités et d’en ajouter sans affecter les microservices de traitement des commandes et des paiements. En publiant des événements à l'aide de cette application EventBridge, elle s'intègre aux systèmes existants, tels que le microservice d'inventaire, mais permet également à toute future application de s'intégrer en tant que consommateur d'événements. Les producteurs d’événements ne connaissent pas les consommateurs d’événements, ce qui peut contribuer à simplifier la logique des microservices.
## Compromis des architectures guidées par les événements
### Latence variable
Contrairement aux applications monolithiques, qui peuvent tout traiter dans le même espace mémoire sur un seul appareil, les applications pilotées par les événements communiquent sur les réseaux. Cette conception introduit une latence variable. Bien qu’il soit possible de concevoir des applications pour réduire la latence, les applications monolithiques peuvent presque toujours être optimisées pour réduire la latence au détriment de la capacité de mise à l’échelle et de la disponibilité.
Les charges de travail qui nécessitent des performances constantes à faible latence, telles que les applications de négociation à haute fréquence dans les banques ou l’automatisation robotique en moins d’une milliseconde dans les entrepôts, ne sont pas de bonnes candidates pour une architecture guidée par les événements.
### Cohérence à terme
Un événement représente un changement d’état, et comme de nombreux événements transitent par différents services d’une architecture à un moment donné, ces charges de travail sont souvent [cohérentes à terme](https://en.wikipedia.org/wiki/Eventual_consistency). Cela complique le traitement des transactions, la gestion des doublons ou la détermination de l’état global exact d’un système.
Certaines charges de travail contiennent une combinaison d’exigences qui sont cohérentes à terme (par exemple, le nombre total de commandes dans l’heure en cours) ou fortement cohérentes (par exemple, l’inventaire actuel). Pour les charges de travail nécessitant une forte cohérence des données, il existe des modèles d’architecture adaptés. Par exemple :
+ DynamoDB peut fournir des [lectures fortement cohérentes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html), parfois avec une latence plus élevée, consommant un débit supérieur à celui du mode par défaut. DynamoDB peut également [prendre en charge les transactions](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html) afin de garantir la cohérence des données.
+ Vous pouvez utiliser Amazon RDS pour les fonctionnalités nécessitant des [propriétés ACID](https://en.wikipedia.org/wiki/ACID), bien que les bases de données relationnelles aient généralement une moins bonne capacité de mise à l’échelle qu’une base de données NoSQL comme DynamoDB. Le [Proxy Amazon RDS](https://aws.amazon.com/rds/proxy/) peut aider à gérer le regroupement et la mise à l’échelle des connexions à partir de clients éphémères tels que les fonctions Lambda.
Les architectures basées sur les événements sont généralement conçues en fonction d’événements individuels plutôt que de grands lots de données. En général, les flux de travail sont conçus pour gérer les étapes d’un événement ou d’un flux d’exécution individuel au lieu de traiter plusieurs événements simultanément. En mode sans serveur, le traitement des événements en temps réel est préféré au traitement par lots : les lots doivent être remplacés par de nombreuses mises à jour incrémentales plus petites. Cela peut rendre les charges de travail plus disponibles et évolutives, mais il est également plus difficile pour les événements d’avoir connaissance des autres événements.
### Renvoi des valeurs aux appelants
Dans de nombreux cas, les applications basées sur des événements sont asynchrones. Cela signifie que les services des appelants n’attendent pas les requêtes des autres services pour poursuivre d’autres tâches. Il s’agit d’une caractéristique fondamentale des architectures guidées par les événements qui permet la capacité de mise à l’échelle et la flexibilité. Cela signifie que la transmission des valeurs de retour ou du résultat d’un flux de travail est plus complexe que dans les flux d’exécution synchrones.
La plupart des invocations Lambda dans les systèmes de production sont [asynchrones](invocation-async.md) et répondent à des événements provenant de services tels qu’Amazon S3 ou Amazon SQS. Dans ces cas, le succès ou l’échec du traitement d’un événement est souvent plus important que le renvoi d’une valeur. Des fonctionnalités telles que les [files d'attente de lettres mortes](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQs) dans Lambda sont fournies pour vous permettre d'identifier et de réessayer les événements ayant échoué, sans avoir à en informer l'appelant.
### Débogage entre les services et les fonctions
Le débogage de systèmes guidés par des événements est également différent par rapport à une application monolithique. Lorsque différents systèmes et services transmettent des événements, il est impossible d’enregistrer et de reproduire l’état exact de plusieurs services en cas d’erreur. Étant donné que chaque invocation de service et de fonction comporte des fichiers journaux distincts, il peut être plus compliqué de déterminer ce qu’il est advenu d’un événement spécifique à l’origine d’une erreur.
Trois conditions importantes sont requises pour élaborer une approche de débogage réussie dans les systèmes guidés par les événements. Tout d'abord, un système de journalisation robuste est essentiel, fourni par l'ensemble AWS des services et intégré aux fonctions Lambda par Amazon. CloudWatch Deuxièmement, dans ces systèmes, il est important de s’assurer que chaque événement possède un identifiant de transaction journalisé à chaque étape de la transaction, afin de faciliter la recherche de journaux.
Enfin, il est fortement recommandé d’automatiser l’analyse des journaux à l’aide d’un service de débogage et de surveillance tel qu’ AWS X-Ray. Cela peut consommer les journaux de plusieurs invocations et services Lambda, ce qui permet d’identifier plus facilement la cause racine des problèmes. Consultez la [Procédure de dépannage](lambda-troubleshooting.md) pour une présentation détaillée de l’utilisation de X-Ray à des fins de résolution des problèmes.
## Anti-modèles dans les applications pilotées par les événements basées sur Lambda
Lorsque vous créez des architectures pilotées par des événements avec Lambda, évitez les anti-modèles courants suivants. Ces modèles fonctionnent mais peuvent augmenter les coûts et la complexité.
### Le monolithe Lambda
Dans de nombreuses applications migrées à partir de serveurs traditionnels, comme les instances Amazon EC2 ou d’applications Elastic Beanstalk, les développeurs réalisent un « lift-and-shift » du code existant. Cela se traduit souvent par une seule fonction Lambda qui contient toute la logique d’application déclenchée pour tous les événements. Pour une application Web de base, une fonction Lambda monolithique gérerait toutes les routes API Gateway et s’intégrerait à toutes les ressources en aval nécessaires.
![\[architectures guidées par les événements (illustration 13)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Cette approche présente plusieurs inconvénients :
+ **Taille du package** — La fonction Lambda peut être beaucoup plus importante car elle contient tout le code possible pour tous les chemins, ce qui ralentit l'exécution du service Lambda.
+ **Moindre privilège difficile à appliquer** : le [rôle d’exécution](lambda-intro-execution-role.md) de la fonction doit accorder des autorisations à toutes les ressources nécessaires pour tous les chemins, ce qui rend les autorisations très étendues. Il s’agit d’un problème de sécurité. De nombreux chemins du monolithe fonctionnel n’ont pas besoin de toutes les autorisations accordées.
+ **Mise à niveau plus difficile** : dans un système de production, toute mise à niveau d’une seule fonction est plus risquée et peut entraîner l’arrêt du fonctionnement de l’application dans son ensemble. La mise à niveau d’un seul chemin dans la fonction Lambda est une mise à niveau de l’ensemble de la fonction.
+ **Maintenance plus difficile** : il est plus difficile d’avoir plusieurs développeurs travaillant sur le service puisqu’il s’agit d’un référentiel de code monolithique. Cela alourdit également la charge cognitive des développeurs et complique la création d’une couverture de test appropriée pour le code.
+ **Réutilisation du code plus difficile** : il est plus difficile de séparer les bibliothèques réutilisables des monolithes, ce qui complique la réutilisation du code. Au fur et à mesure que vous développez et soutenez de plus en plus de projets, il peut être plus difficile de soutenir le code et de mettre à l’échelle la vitesse de votre équipe.
+ **Tests plus difficiles** : à mesure que le nombre de lignes de code augmente, il devient plus difficile d’effectuer des tests unitaires pour toutes les combinaisons possibles d’entrées et de points d’entrée dans la base de code. Il est généralement plus facile de mettre en œuvre des tests unitaires pour les petits services avec moins de code.
L'alternative préférée consiste à décomposer la fonction Lambda monolithique en microservices individuels, en mappant une seule fonction Lambda à une seule tâche bien définie. Dans cette application Web simple dotée de quelques points de terminaison d’API, l’architecture basée sur les microservices qui en résulte peut être basée sur les routes API Gateway.
![\[architectures guidées par les événements (illustration 14)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Modèles récursifs qui provoquent des fonctions Lambda incontrôlables
AWS les services génèrent des événements qui invoquent des fonctions Lambda, et les fonctions Lambda peuvent envoyer des messages aux services. AWS En général, le service ou la ressource qui invoque une fonction Lambda doit être différent du service ou de la ressource vers lequel la fonction émet des sorties. Si vous ne parvenez pas à gérer cela, vous risquez de créer des boucles infinies.
Par exemple, une fonction Lambda écrit un objet dans un objet Amazon S3, qui à son tour invoque la même fonction Lambda via un événement put. L’invocation entraîne l’écriture d’un deuxième objet dans le compartiment, qui invoque la même fonction Lambda :
![\[architectures guidées par les événements (illustration 15)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Bien que le potentiel de boucles infinies existe dans la plupart des langages de programmation, cet anti-modèle est susceptible de consommer davantage de ressources dans les applications sans serveur. Lambda et Amazon S3 évoluent automatiquement en fonction du trafic, de sorte que la boucle peut amener Lambda à évoluer pour utiliser toute la simultanéité disponible et Amazon S3 continuera à écrire des objets et à générer davantage d'événements pour Lambda.
Cet exemple utilise S3, mais le risque de boucles récursives existe également dans Amazon SNS, Amazon SQS, DynamoDB et d’autres services. Vous pouvez utiliser la [détection de boucle récursive](invocation-recursion.md) pour détecter et éviter cet anti-modèle.
### Fonctions Lambda appelant des fonctions Lambda
Les fonctions permettent l’encapsulation et la réutilisation du code. La plupart des langages de programmation prennent en charge le concept d’appel synchrone de fonctions au sein d’une base de code. Dans ce cas, l’appelant attend la réponse de la fonction.
**Note**
Bien que les fonctions Lambda appelant directement d'autres fonctions Lambda constituent généralement un anti-modèle en raison de problèmes de coût et de complexité, cela ne s'applique pas aux [fonctions durables](durable-functions.md), qui sont spécifiquement conçues pour orchestrer des flux de travail en plusieurs étapes en invoquant d'autres fonctions.
Lorsque cela se produit sur un serveur traditionnel ou une instance virtuelle, le planificateur du système d’exploitation passe à d’autres tâches disponibles. Le fait que le processeur fonctionne à 0 % ou à 100 % n’a aucune incidence sur le coût global de l’application, puisque vous payez le coût fixe lié à la possession et à l’exploitation d’un serveur.
Ce modèle ne s’adapte souvent pas bien au développement sans serveur. Prenons l’exemple d’une simple application de commerce électronique composée de trois fonctions Lambda qui traitent une commande :
![\[architectures guidées par les événements (illustration 16)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
Dans ce cas, la fonction *Créer une commande* appelle la fonction *Traiter le paiement*, qui à son tour appelle la fonction *Créer une facture*. Bien que ce flux synchrone puisse fonctionner au sein d'une seule application sur un serveur, il introduit plusieurs problèmes évitables dans une architecture sans serveur distribuée :
+ **Coût** : avec Lambda, vous payez pour la durée d’une invocation. Dans cet exemple, pendant que les fonctions *Créer une facture* s’exécutent, deux autres fonctions sont également exécutées en attente, comme indiqué en rouge sur le diagramme.
+ **Gestion des erreurs** : dans les invocations imbriquées, la gestion des erreurs peut devenir beaucoup plus complexe. Par exemple, une erreur dans *Créer une facture* peut nécessiter que la fonction de *traitement du paiement* annule le débit, ou qu'elle réessaie le processus de *création de facture*.
+ **Couplage fort** : le traitement d’un paiement prend généralement plus de temps que la création d’une facture. Dans ce modèle, la disponibilité de l’ensemble du flux de travail est limitée par la fonction la plus lente.
+ **Mise à l’échelle** : la [simultanéité](lambda-concurrency.md) des trois fonctions doit être égale. Dans un système occupé, cela utilise plus de simultanéité que ce qui serait nécessaire autrement.
Dans les applications sans serveur, il existe deux approches courantes pour éviter ce schéma. Tout d’abord, utilisez une file d’attente Amazon SQS entre les fonctions Lambda. Si un processus en aval est plus lent qu’un processus en amont, la file d’attente conserve les messages de manière durable et dissocie les deux fonctions. Dans cet exemple, la fonction *Create order* publierait un message dans une file d'attente Amazon SQS, et la fonction *Process payment* consomme les messages de la file d'attente.
La deuxième approche consiste à utiliser AWS Step Functions. Pour les processus complexes présentant plusieurs types d’échec et une logique de nouvelle tentative, Step Functions peut aider à réduire la quantité de code personnalisé nécessaire pour orchestrer le flux de travail. Par conséquent, Step Functions orchestre les tâches et gère efficacement les erreurs et les nouvelles tentatives, et les fonctions Lambda ne contiennent que de la logique métier.
### Attente synchrone au sein d’une seule fonction Lambda
Assurez-vous que les activités potentiellement simultanées ne sont pas planifiées de manière synchrone au sein d'une seule fonction Lambda. Par exemple, une fonction Lambda peut écrire dans un compartiment S3, puis dans une table DynamoDB :
![\[architectures guidées par les événements (illustration 17)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
Dans cette conception, les temps d’attente sont cumulés, car les activités sont séquentielles. Dans les cas où la deuxième tâche dépend de l’achèvement de la première, vous pouvez peut-être réduire le temps d’attente total et le coût d’exécution en ayant deux fonctions Lambda distinctes :
![\[architectures guidées par les événements (illustration 19)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
Dans cette conception, la première fonction Lambda répond immédiatement après avoir placé l’objet dans le compartiment Amazon S3. Le service S3 invoque la deuxième fonction Lambda, qui écrit ensuite des données dans la table DynamoDB. Cette approche réduit le temps d’attente total lors des exécutions de fonctions Lambda.
# Conception d’applications Lambda
Une application événementielle bien conçue utilise une combinaison de AWS services et de code personnalisé pour traiter et gérer les demandes et les données. Ce chapitre se concentre sur les sujets spécifiques à Lambda en matière de conception d’applications. Les architectes sans serveur doivent tenir compte de nombreuses considérations importantes lorsqu’ils conçoivent des applications pour des systèmes de production très sollicités.
Bon nombre des pratiques exemplaires applicables au développement de logiciels et aux systèmes distribués s’appliquent également au développement d’applications sans serveur. L’objectif global est de développer des charges de travail qui sont :
+ **Fiables** : offrez à vos utilisateurs finaux un haut niveau de disponibilité. Les services AWS sans serveur sont fiables, car ils sont également conçus pour résister aux défaillances.
+ **Durables** : offrez des options de stockage qui répondent aux besoins de durabilité de votre charge de travail.
+ **Sécurisées** : suivez les pratiques exemplaires et utilisez les outils fournis pour sécuriser l’accès aux charges de travail et limiter le rayon d’impact.
+ **Performantes** : utilisez les ressources informatiques avec efficacité et répondez aux besoins de performance de vos utilisateurs finaux.
+ **Rentables :** concevez des architectures qui évitent les coûts inutiles, qui peuvent se mettre à l’échelle sans dépenses excessives, et également être mises hors service sans frais généraux importants.
Les principes de conception suivants peuvent vous aider à créer des charges de travail répondant à ces objectifs. Tous les principes ne s’appliquent pas à toutes les architectures, mais ils devraient vous guider dans vos décisions générales en matière d’architecture.
**Topics**
+ [
## Utilisation de services plutôt que de code personnalisé
](#services-custom-code)
+ [
## Présentation des niveaux d’abstraction Lambda
](#level-abstraction)
+ [
## Implémenter l’absence d’état dans les fonctions
](#statelessness-functions)
+ [
## Minimiser le couplage
](#minimize-coupling)
+ [
## Générer des données à la demande plutôt que pour des lots
](#on-demand-batches)
+ [
## Choisissez une option d'orchestration pour les flux de travail complexes
](#orchestration)
+ [
## Implémenter l’idempotence
](#retries-failures)
+ [
## Utiliser plusieurs AWS comptes pour gérer les quotas
](#multiple-accounts)
## Utilisation de services plutôt que de code personnalisé
Les applications sans serveur comprennent généralement plusieurs AWS services, intégrés à du code personnalisé exécuté dans les fonctions Lambda. Lambda peut être intégré à la plupart des AWS services, mais les services les plus couramment utilisés dans les applications sans serveur sont les suivants :
| Catégorie | AWS service |
| --- | --- |
| Calcul | AWS Lambda |
| Stockage de données | Amazon S3 Amazon DynamoDB Amazon RDS |
| API | Amazon API Gateway |
| Intégration d’applications | Amazon EventBridge Amazon SNS Amazon SQS |
| Orchestration | Fonctions durables Lambda AWS Step Functions |
| Données de streaming et analytique | Amazon Data Firehose |
**Note**
De nombreux services sans serveur fournissent la réplication et la prise en charge de plusieurs régions, notamment DynamoDB et Amazon S3. Les fonctions Lambda peuvent être déployées dans plusieurs régions dans le cadre d’un pipeline de déploiement, et API Gateway peut être configurée pour prendre en charge cette configuration. Consultez cet [exemple d’architecture](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) qui montre comment cela peut être réalisé.
Il existe de nombreux modèles courants bien établis dans les architectures distribuées que vous pouvez créer vous-même ou implémenter à l'aide de AWS services. Pour la plupart des clients, le développement de ces modèles à partir de zéro présente peu d’intérêt commercial. Lorsque votre application a besoin de l'un de ces modèles, utilisez le AWS service correspondant :
| Modèle | AWS service |
| --- | --- |
| File d’attente | Amazon SQS |
| Bus d’événement | Amazon EventBridge |
| Publication-abonnement (diffusion en éventail) | Amazon SNS |
| Orchestration | Fonctions durables Lambda AWS Step Functions |
| API | Amazon API Gateway |
| Flux d’événement | Amazon Kinesis |
Ces services sont conçus pour s’intégrer à Lambda et vous pouvez utiliser l’infrastructure en tant que code (IaC) pour créer et supprimer des ressources dans les services. Vous pouvez utiliser n’importe lequel de ces services via le [kit SDK AWS](https://aws.amazon.com/tools/) sans avoir à installer d’applications ou à configurer des serveurs. Maîtriser l’utilisation de ces services via le code dans vos fonctions Lambda est une étape importante pour produire des applications sans serveur bien conçues.
## Présentation des niveaux d’abstraction Lambda
Le service Lambda limite votre accès aux systèmes d’exploitation, aux hyperviseurs et au matériel sous-jacents qui exécutent vos fonctions Lambda. Le service améliore et modifie continuellement l’infrastructure afin d’ajouter des fonctionnalités, de réduire les coûts et de rendre le service plus performant. Votre code ne doit émettre aucune hypothèse quant à l’architecture de Lambda et à l’affinité matérielle.
De même, les intégrations de Lambda avec d'autres services sont gérées par AWS, et seul un petit nombre d'options de configuration vous sont proposées. Par exemple, quand API Gateway et Lambda interagissent, il n’y a aucun concept d’équilibrage de charge, puisqu’il est entièrement géré par les services. Vous n’avez également aucun contrôle direct sur les [zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) utilisées par les services lorsqu’ils invoquent des fonctions à tout moment, ni sur la manière dont Lambda détermine quand réduire ou augmenter verticalement le nombre d’environnements d’exécution.
Cette abstraction vous aide à vous concentrer sur les aspects d’intégration de votre application, le flux de données et la logique métier dans laquelle votre charge de travail apporte de la valeur à vos utilisateurs finaux. En permettant aux services de gérer les mécanismes sous-jacents, vous pouvez développer des applications plus rapidement avec moins de code personnalisé à gérer.
## Implémenter l’absence d’état dans les fonctions
Pour les fonctions Lambda standard, vous devez partir du principe que l'environnement n'existe que pour un seul appel. La fonction doit initialiser tout état requis lors de son premier démarrage. Par exemple, votre fonction peut nécessiter de récupérer des données dans une table DynamoDB. Elle doit valider toute modification permanente des données sur un magasin durable tel qu’Amazon S3, DynamoDB ou Amazon SQS avant de quitter. Elle ne doit pas s’appuyer sur des structures de données ou des fichiers temporaires existants, ni sur un état interne qui serait géré par de multiples invocations.
Lorsque vous utilisez Durable Functions, l'état est automatiquement préservé entre les appels, ce qui élimine le besoin de le conserver manuellement sur le stockage externe. Cependant, vous devez toujours suivre les principes de l'apatridie pour toutes les données qui ne sont pas explicitement gérées par le biais du DurableContext.
Pour initialiser les connexions aux bases de données et les bibliothèques, ou pour initialiser l’état de chargement, vous pouvez tirer parti de l’[initialisation statique](lambda-runtime-environment.md#static-initialization). Les environnements d’exécution étant réutilisés dans la mesure du possible pour améliorer les performances, vous pouvez amortir le temps nécessaire à l’initialisation de ces ressources sur plusieurs invocations. Cependant, vous ne devez stocker aucune variable ou donnée utilisée dans la fonction dans cette portée globale.
## Minimiser le couplage
La plupart des architectures devraient préférer les fonctions plus nombreuses et plus petites aux fonctions moins nombreuses et plus grandes. Le but de chaque fonction doit être de gérer l’événement transmis à la fonction, sans aucune connaissance ni attente quant au flux de travail global ou au volume des transactions. Cela rend la fonction indépendante de la source de l’événement avec un couplage minimal avec les autres services.
Toutes les constantes de portée globale qui changent rarement doivent être implémentées en tant que variables d’environnement afin de permettre les mises à jour sans déploiement. Tous les secrets ou informations sensibles doivent être stockés dans [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) ou dans [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) et chargés par la fonction. Comme ces ressources sont propres à un compte, vous pouvez créer des pipelines de génération sur plusieurs comptes. Les pipelines chargent les secrets appropriés par environnement, sans les exposer aux développeurs ni nécessiter de modification du code.
## Générer des données à la demande plutôt que pour des lots
De nombreux systèmes traditionnels sont conçus pour fonctionner périodiquement et traiter des lots de transactions accumulés au fil du temps. Par exemple, une application bancaire peut s’exécuter toutes les heures pour traiter les transactions des guichets automatiques dans des registres centraux. Dans les applications basées sur Lambda, le traitement personnalisé doit être déclenché par chaque événement, ce qui permet au service d’augmenter verticalement la simultanéité selon les besoins, afin de fournir un traitement des transactions en temps quasi réel.
Alors que les fonctions Lambda standard sont limitées à 15 minutes d'exécution, les fonctions durables peuvent fonctionner jusqu'à un an, ce qui les rend adaptées aux besoins de traitement de longue durée. Cependant, vous devez toujours préférer le traitement piloté par les événements au traitement par lots lorsque cela est possible.
Bien que vous puissiez exécuter des tâches [cron](https://en.wikipedia.org/wiki/Cron) dans des applications sans serveur en [utilisant des expressions planifiées](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) pour les règles dans Amazon EventBridge, celles-ci doivent être utilisées avec parcimonie ou en dernier recours. Dans toute tâche planifiée qui traite un lot, il est possible que le volume de transactions augmente au-delà de ce qui peut être traité dans la limite de durée Lambda de 15 minutes. Si les limites des systèmes externes vous obligent à utiliser un planificateur, vous devez généralement planifier pour la période récurrente la plus courte possible.
Par exemple, il n’est pas recommandé d’utiliser un traitement par lots qui déclenche une fonction Lambda pour récupérer une liste de nouveaux objets Amazon S3. Cela est dû au fait que le service peut recevoir plus de nouveaux objets entre les lots que ce qui peut être traité dans le cadre d’une fonction Lambda de 15 minutes.
![\[architectures guidées par les événements (illustration 10)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
Amazon S3 doit plutôt invoquer la fonction Lambda chaque fois qu’un nouvel objet est placé dans le compartiment. Cette démarche est bien plus facile à mettre à l’échelle et fonctionne en temps quasi réel.
![\[architectures guidées par les événements (illustration 11)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Choisissez une option d'orchestration pour les flux de travail complexes
Les flux de travail qui impliquent une logique de ramification, différents types de modèles d’échec et une logique de nouvelle tentative utilisent généralement un orchestrateur pour suivre l’état de l’exécution globale. Ne créez pas d'orchestration ad hoc dans les fonctions Lambda standard. Cela se traduit par un couplage étroit, un code de routage complexe et l'absence de restauration automatique de l'état.
Utilisez plutôt l'une de ces options d'orchestration spécialement conçues :
+ **[Fonctions Lambda durables](durable-functions.md) :** orchestration centrée sur les applications à l'aide de langages de programmation standard avec point de contrôle automatique, nouvelle tentative intégrée et reprise d'exécution. Idéal pour les développeurs qui préfèrent conserver la logique du flux de travail dans le code aux côtés de la logique métier dans Lambda.
+ **[AWS Step Functions](with-step-functions.md):** orchestration visuelle du flux de travail avec intégrations natives à plus de 220 AWS services. Idéal pour la coordination multiservices, les infrastructures sans maintenance et la conception visuelle des flux de travail.
Pour savoir comment choisir entre ces options, voir [Durable functions ou Step Functions](durable-step-functions.md).
Avec [ Step Functions](https://aws.amazon.com/step-functions/), vous utilisez des machines d’état pour gérer l’orchestration. Cela extrait la logique de gestion des erreurs, de routage et de branchement de votre code, en la remplaçant par des machines d’état déclarées à l’aide de JSON. En plus de rendre les flux de travail plus robustes et observables, vous pouvez également ajouter la gestion des versions aux flux de travail et faire de la machine d’état une ressource codifiée que vous pouvez ajouter à un référentiel de code.
Il est courant que les flux de travail simples dans les fonctions Lambda se complexifient au fil du temps. Lorsque vous utilisez une application de production sans serveur, il est important d'identifier le moment où cela se produit, afin de pouvoir migrer cette logique vers une machine à états ou une fonction durable.
## Implémenter l’idempotence
AWS les services sans serveur, y compris Lambda, sont tolérants aux pannes et conçus pour gérer les défaillances. Par exemple, si un service invoque une fonction Lambda et qu’il y a une interruption de service, Lambda invoque votre fonction dans une autre zone de disponibilité. Si la fonction renvoie une erreur, Lambda relance l’invocation.
Comme le même événement peut être reçu plusieurs fois, les fonctions doivent être conçues pour être [idempotentes](https://en.wikipedia.org/wiki/Idempotence). Cela signifie que le fait de recevoir le même événement plusieurs fois ne change pas le résultat au-delà de la première réception de l’événement.
Vous pouvez implémenter l’idempotence dans les fonctions Lambda en utilisant une table DynamoDB pour suivre les identifiants récemment traités afin de déterminer si la transaction a déjà été traitée. La table DynamoDB implémente généralement une valeur de [durée de vie (TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) pour faire expirer les éléments afin de limiter l’espace de stockage utilisé.
## Utiliser plusieurs AWS comptes pour gérer les quotas
De nombreux [quotas de service](gettingstarted-limits.md) AWS sont définis au niveau du compte. Cela signifie qu’à mesure que vous ajoutez de nouvelles charges de travail, vous pouvez rapidement épuiser vos limites.
Un moyen efficace de résoudre ce problème consiste à utiliser plusieurs AWS comptes, en consacrant chaque charge de travail à son propre compte. Cela empêche le partage des quotas avec d’autres charges de travail ou des ressources non liées à la production.
Par ailleurs, grâce à [AWS Organizations](https://aws.amazon.com/organizations/), il est possible de gérer de manière centralisée la facturation, la conformité et la sécurité de ces comptes. Vous pouvez associer des politiques à des groupes de comptes pour éviter les scripts personnalisés et les processus manuels.
Une approche courante consiste à fournir un AWS compte à chaque développeur, puis à utiliser des comptes distincts pour la phase de déploiement et de production de la version bêta :
![\[conception de l’application figure 3\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/application-design-figure-3.png)
Dans ce modèle, chaque développeur a son propre ensemble de limites pour le compte, de sorte que leur utilisation n’a aucune incidence sur votre environnement de production. Cette approche permet également aux développeurs de tester les fonctions Lambda localement sur leurs machines de développement par rapport aux ressources cloud actives de leurs comptes individuels.