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.
# Présentation de la mise à l’échelle de fonction Lambda
La **simultanéité** est le nombre de demandes en cours de vol traitées simultanément par votre AWS Lambda fonction. Pour chaque demande simultanée, Lambda fournit une instance distincte de votre environnement d’exécution. Au fur et à mesure que vos fonctions reçoivent des demandes, Lambda gère automatiquement la mise à l’échelle du nombre d’environnements d’exécution jusqu’à ce que vous atteigniez la limite de simultanéité de votre compte. Par défaut, Lambda fournit à votre compte une limite de simultanéité totale de 1 000 exécutions simultanées pour toutes les fonctions d’une Région AWS. Pour répondre aux besoins spécifiques de votre compte, vous pouvez [demander une augmentation du quota](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/) et configurer les contrôles de simultanéité au niveau des fonctions afin que vos fonctions critiques ne soient pas limitées.
Cette rubrique explique la simultanéité et la mise à l’échelle des fonctions dans Lambda. À la fin de cette rubrique, vous serez en mesure de comprendre comment calculer la simultanéité, de visualiser les deux principales options de contrôle de la simultanéité (réservée et provisionnée), d’estimer les paramètres de contrôle de la simultanéité appropriés et de visualiser les métriques pour une optimisation supplémentaire.
**Topics**
+ [
## Comprendre et visualiser la simultanéité
](#understanding-concurrency)
+ [
## Calcul de la simultanéité d’une fonction
](#calculating-concurrency)
+ [
## Présentation de la simultanéité réservée et de la simultanéité allouée
](#reserved-and-provisioned)
+ [
## Présentation de la simultanéité et des requêtes par seconde
](#concurrency-vs-requests-per-second)
+ [
## Quotas de simultanéité
](#concurrency-quotas)
+ [
# Configuration de la simultanéité réservée pour une fonction
](configuration-concurrency.md)
+ [
# Configuration de la simultanéité provisionnée pour une fonction
](provisioned-concurrency.md)
+ [
# Comportement de mise à l’échelle Lambda
](scaling-behavior.md)
+ [
# Surveillance de la simultanéité
](monitoring-concurrency.md)
## Comprendre et visualiser la simultanéité
Lambda invoque votre fonction dans un [environnement d’exécution](lambda-runtime-environment.md) sécurisé et isolé. Pour traiter une demande, Lambda doit d’abord initialiser un environnement d’exécution (la [phase Init](lambda-runtime-environment.md#runtimes-lifecycle-ib)), avant de l’utiliser pour invoquer votre fonction (la [phase Invoke](lambda-runtime-environment.md#runtimes-lifecycle-invoke)) :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-1-environment.png)
**Note**
Les durées réelles d’Init et Invoke peuvent varier en fonction de nombreux facteurs, tels que l’environnement d’exécution choisi et le code de la fonction Lambda. Le diagramme précédent n’est pas censé représenter les proportions exactes des durées des phases Init et Invoke.
Le diagramme précédent utilise un rectangle pour représenter un seul environnement d’exécution. Lorsque votre fonction reçoit sa toute première demande (représentée par le cercle jaune avec l’étiquette `1`), Lambda crée un nouvel environnement d’exécution et exécute le code en dehors de votre gestionnaire principal pendant la phase Init. Ensuite, Lambda exécute le code du gestionnaire principal de votre fonction pendant la phase Invoke. Pendant tout ce processus, cet environnement d’exécution est occupé et ne peut pas traiter d’autres demandes.
Lorsque Lambda a fini de traiter la première demande, cet environnement d’exécution peut alors traiter des demandes supplémentaires pour la même fonction. Pour les demandes suivantes, Lambda n’a pas besoin de réinitialiser l’environnement.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-2-two-requests.png)
Dans le schéma précédent, Lambda réutilise l’environnement d’exécution pour traiter la deuxième demande (représentée par le cercle jaune avec l’étiquette `2`).
Jusqu’à présent, nous nous sommes concentrés sur une seule instance de votre environnement d’exécution (c.-à-d. une simultanéité de 1). En pratique, Lambda peut avoir besoin de provisionner plusieurs instances d’environnement d’exécution en parallèle pour traiter toutes les demandes entrantes. Lorsque votre fonction reçoit une nouvelle demande, l’une des deux choses suivantes peut se produire :
+ Si une instance d’environnement d’exécution pré-initialisée est disponible, Lambda l’utilise pour traiter la demande.
+ Sinon, Lambda crée une nouvelle instance d’environnement d’exécution pour traiter la demande.
Par exemple, explorons ce qui se passe lorsque votre fonction reçoit 10 demandes :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-3-ten-requests.png)
Dans le diagramme précédent, chaque plan horizontal représente une seule instance d’environnement d’exécution (étiquetée de `A` à `F`). Voici comment Lambda traite chaque demande :
| Demande | Comportement de Lambda | Raisonnement |
| --- | --- | --- |
| 1 | Alloue un nouvel environnement **A** | C’est la première demande ; aucune instance d’environnement d’exécution n’est disponible. |
| 2 | Alloue un nouvel environnement **B** | L’instance **A** de l’environnement d’exécution existant est occupée. |
| 3 | Alloue un nouvel environnement **C** | Les instances d’environnement d’exécution existantes **A** et **B** sont toutes deux occupées. |
| 4 | Alloue un nouvel environnement **D** | Les instances d’environnement d’exécution existantes **A**, **B** et **C** sont toutes occupées. |
| 5 | Alloue un nouvel environnement **E** | Les instances **A**, **B**, **C** et **D** de l’environnement d’exécution existant sont toutes occupées. |
| 6 | Réutilise l’environnement **A** | L’instance d’environnement d’exécution **A** a fini de traiter la demande **1** et est maintenant disponible. |
| 7 | Réutilise l’environnement **B** | L’instance d’environnement d’exécution **B** a fini de traiter la demande **2** et est maintenant disponible. |
| 8 | Réutilise l’environnement **C** | L’instance d’environnement d’exécution **C** a terminé le traitement de la demande **3** et est maintenant disponible. |
| 9 | Alloue un nouvel environnement **F** | Les instances d’environnement d’exécution existantes **A**, **B**, **C**, **D** et **E** sont toutes occupées. |
| 10 | Réutilise l’environnement **D** | L’instance d’environnement d’exécution **D** a fini de traiter la demande **4** et est maintenant disponible. |
Au fur et à mesure que votre fonction reçoit des demandes simultanées, Lambda augmente le nombre d’instances d’environnement d’exécution en réponse. L’animation suivante suit le nombre de demandes simultanées dans le temps :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-4-animation.gif)
En figeant l’animation précédente à six points distincts dans le temps, nous obtenons le diagramme suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-5-animation-summary.png)
Dans le diagramme précédent, nous pouvons tracer une ligne verticale à tout moment et compter le nombre d’environnements qui croisent cette ligne. Cela nous donne le nombre de demandes simultanées à ce moment précis. Par exemple, au moment `t1`, il y a trois environnements actifs servant trois demandes simultanées. Le nombre maximum de demandes simultanées dans cette simulation se produit au moment `t4`, lorsqu’il y a six environnements actifs servant six demandes simultanées.
En résumé, la simultanéité de votre fonction est le nombre de demandes simultanées qu’elle traite en même temps. En réponse à une augmentation de la simultanéité de votre fonction, Lambda fournit plus d’instances d’environnement d’exécution pour répondre à la demande.
## Calcul de la simultanéité d’une fonction
En général, la simultanéité d’un système est la capacité de traiter plus d’une tâche simultanément. Dans Lambda, la simultanéité est le nombre de demandes en vol que votre fonction traite en même temps. Une façon rapide et pratique de mesurer la simultanéité d’une fonction Lambda est d’utiliser la formule suivante :
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
**La simultanéité diffère des demandes par seconde.** Par exemple, supposons que votre fonction reçoive 100 demandes par seconde en moyenne. Si la durée moyenne des demandes est de une seconde, il est vrai que la simultanéité est également de 100 :
```
Concurrency = (100 requests/second) * (1 second/request) = 100
```
Toutefois, si la durée moyenne des demandes est de 500 ms, la simultanéité est de 50 :
```
Concurrency = (100 requests/second) * (0.5 second/request) = 50
```
Que signifie une simultanéité de 50 dans la pratique ? Si la durée moyenne des demandes est de 500 ms, vous pouvez considérer qu’une instance de votre fonction est capable de traiter deux demandes par seconde. Ensuite, il faut 50 instances de votre fonction pour gérer une charge de 100 demandes par seconde. Une simultanéité de 50 signifie que Lambda doit fournir 50 instances d’environnement d’exécution pour gérer efficacement cette charge de travail sans être limité. Voici comment exprimer cela sous forme d’équation :
```
Concurrency = (100 requests/second) / (2 requests/second) = 50
```
Si votre fonction reçoit le double de demandes (200 demandes par seconde), mais ne nécessite que la moitié du temps pour traiter chaque demande (250 ms), la simultanéité est toujours de 50 :
```
Concurrency = (200 requests/second) * (0.25 second/request) = 50
```
### Testez de votre compréhension de la simultanéité
Supposons que vous ayez une fonction qui prend, en moyenne, 200 ms pour s’exécuter. Pendant les pics de charge, vous observez 5 000 demandes par seconde. Quelle est la simultanéité de votre fonction pendant la charge de pointe ?
#### Réponse
La durée moyenne de la fonction est de 200 ms, soit 0,20 seconde. En utilisant la formule de simultanéité, vous pouvez entrer les chiffres pour obtenir une simultanéité de 1000 :
```
Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000
```
Autrement dit, une durée moyenne de fonction de 200 ms signifie que votre fonction peut traiter 5 demandes par seconde. Pour traiter la charge de travail de 5 000 demandes par seconde, vous avez besoin de 1 000 instances d’environnement d’exécution. La simultanéité est donc de 1 000 :
```
Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000
```
## Présentation de la simultanéité réservée et de la simultanéité allouée
Par défaut, votre compte dispose d’une limite de simultanéité de 1 000 exécutions simultanées pour toutes les fonctions d’une Région. Vos fonctions partagent ce groupe de 1 000 simultanéités sur une base à la demande. Vos fonctions sont limitées (c'est-à-dire qu'elles commencent à supprimer les demandes) si vous n'avez plus de simultanéité disponible.
Certaines de vos fonctions peuvent être plus critiques que d’autres. Par conséquent, vous pouvez vouloir configurer les paramètres de simultanéité pour vous assurer que les fonctions critiques obtiennent la simultanéité dont elles ont besoin. Il existe deux types de contrôles de simultanéité : la simultanéité réservée et la simultanéité provisionnée.
+ Utilisez la **simultanéité réservée** pour définir les nombres maximal et minimal d’instances simultanées afin de réserver une partie de la simultanéité de votre compte pour une fonction. Ceci est utile si vous ne voulez pas que d’autres fonctions prennent toute la simultanéité non réservée disponible. Lorsqu’une fonction dispose de la simultanéité réservée, aucune autre fonction ne peut utiliser cette simultanéité.
+ Utilisez la **simultanéité provisionnée** pour pré-initialiser un certain nombre d’instances d’environnement pour une fonction. Ceci est utile pour réduire les latences de démarrage à froid.
### Simultanéité réservée
Si vous voulez garantir qu’une certaine quantité de simultanéité est disponible pour votre fonction à tout moment, utilisez la simultanéité réservée.
La simultanéité réservée définit les nombres maximum et minimum d’instances simultanées que vous voulez allouer à votre fonction. Lorsque vous consacrez une simultanéité réservée à une fonction, aucune autre fonction ne peut utiliser cette simultanéité. En d’autres termes, la définition de la simultanéité réservée peut avoir un impact sur le groupe de simultanéité disponible pour les autres fonctions. Les fonctions qui n’ont pas de simultanéité réservée partagent le groupe restant de simultanéité non réservée.
La configuration de la simultanéité réservée compte dans la limite globale de simultanéité de votre compte. Il n’y a pas de frais pour la configuration de la simultanéité réservée pour une fonction.
Pour mieux comprendre la simultanéité réservée, considérez le diagramme suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
Dans ce diagramme, la limite de simultanéité de votre compte pour toutes les fonctions de cette Région est à la limite par défaut de 1 000. Supposons que vous ayez deux fonctions critiques, `function-blue` et `function-orange`, qui s’attendent régulièrement à recevoir des volumes d’invocations élevés. Vous décidez d’accorder 400 unités de simultanéité réservée à `function-blue`, et 400 unités de simultanéité réservée à `function-orange`. Dans cet exemple, toutes les autres fonctions de votre compte doivent se partager les 200 unités restantes de simultanéité non réservée.
Le diagramme présente cinq points d’intérêt :
+ À `t1`, `function-orange` et `function-blue` commencent à recevoir des demandes. Chaque fonction commence à utiliser sa portion d’unités de simultanéité réservées.
+ À `t2`, `function-orange` et `function-blue` reçoivent de plus en plus de demandes. Au même moment, vous déployez d’autres fonctions Lambda, qui commencent à recevoir des demandes. Vous n’allouez pas de simultanéité réservée à ces autres fonctions. Elles commencent à utiliser les 200 unités restantes de simultanéité non réservée.
+ À `t3`, `function-orange` atteint la simultanéité maximale de 400. Bien qu’il existe une simultanéité non utilisée ailleurs dans le compte, `function-orange` ne peut pas y accéder. La ligne rouge indique que `function-orange` est limité et que Lambda peut abandonner des demandes.
+ À `t4`, `function-orange` commence à recevoir moins de demandes et n’est plus limitée. Cependant, vos autres fonctions subissent un pic de trafic et commencent à être limitées. Bien qu’il y ait de la simultanéité inutilisée ailleurs dans votre compte, ces autres fonctions ne peuvent pas y accéder. La ligne rouge indique que vos autres fonctions sont limitées.
+ À `t5`, les autres fonctions commencent à recevoir moins de demandes et ne sont plus limitées.
À partir de cet exemple, remarquez que la réservation de la simultanéité a les effets suivants :
+ **Votre fonction peut évoluer indépendamment des autres fonctions de votre compte.** Toutes les fonctions de votre compte dans la même Région qui n’ont pas de simultanéité réservée partagent le groupe de simultanéité non réservée. Sans simultanéité réservée, d’autres fonctions peuvent utiliser toute votre simultanéité disponible. Cela empêche les fonctions critiques d’augmenter d’échelle si nécessaire.
+ **Votre fonction ne peut pas monter en puissance de façon incontrôlée.** La simultanéité réservée limite la simultanéité maximale et minimale de votre fonction. Cela signifie que votre fonction ne peut pas utiliser la simultanéité réservée à d’autres fonctions, ou la simultanéité du groupe non réservé. En outre, la simultanéité réservée agit à la fois comme limite inférieure et supérieure : elle réserve la capacité spécifiée exclusivement à votre fonction tout en l’empêchant de dépasser cette limite. Vous pouvez réserver de la simultanéité pour empêcher votre fonction d’utiliser toute la simultanéité disponible dans votre compte, ou de surcharger les ressources en aval.
+ **Il se peut que vous ne puissiez pas utiliser toute la simultanéité disponible de votre compte.** La réservation de la simultanéité compte dans la limite de simultanéité de votre compte, mais cela signifie également que les autres fonctions ne peuvent pas utiliser cette partie de la simultanéité réservée. Si votre fonction n’utilise pas toute la simultanéité que vous lui réservez, vous gaspillez effectivement cette simultanéité. Ce n’est pas un problème, sauf si d’autres fonctions de votre compte peuvent bénéficier de la simultanéité gaspillée.
Pour gérer les paramètres de simultanéité réservée pour vos fonctions, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md).
### Simultanéité allouée
Vous utilisez la simultanéité réservée pour définir le nombre maximal d’environnements d’exécution réservés à une fonction Lambda. Toutefois, aucun de ces environnements n’est préinitialisé. Par conséquent, les invocations de votre fonction peuvent prendre plus de temps, car Lambda doit d’abord initialiser le nouvel environnement avant de pouvoir l’utiliser pour invoquer votre fonction. Lorsque Lambda doit initialiser un nouvel environnement pour effectuer une invocation , on parle de [démarrage à froid](lambda-runtime-environment.md#cold-start-latency). Pour atténuer les démarrages à froid, vous pouvez utiliser la simultanéité provisionnée.
La simultanéité provisionnée est le nombre d’environnements d’exécution pré-initialisés que vous voulez allouer à votre fonction. Si vous définissez la simultanéité provisionnée sur une fonction, Lambda initialise ce nombre d’environnements d’exécution afin qu’ils soient prêts à répondre immédiatement aux demandes de la fonction.
**Note**
L’utilisation de la simultanéité provisionnée entraîne des frais supplémentaires sur votre compte. Si vous travaillez avec les environnements d'exécution Java 11 ou Java 17, vous pouvez également utiliser SnapStart Lambda pour atténuer les problèmes de démarrage à froid sans frais supplémentaires. SnapStart utilise des instantanés mis en cache de votre environnement d'exécution pour améliorer de manière significative les performances de démarrage. Vous ne pouvez pas utiliser les deux SnapStart et la simultanéité provisionnée sur la même version de fonction. Pour plus d'informations sur les SnapStart fonctionnalités, les limitations et les régions prises en charge, consultez[Améliorer les performances de démarrage avec Lambda SnapStart](snapstart.md).
Lorsque vous utilisez la simultanéité provisionnée, Lambda recycle toujours les environnements d’exécution en arrière-plan. Par exemple, cela peut se produire [après un échec d’invocation](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors). Cependant, à tout moment, Lambda s’assure toujours que le nombre d’environnements pré-initialisés est égal à la valeur du paramètre de simultanéité provisionnée de votre fonction. Il est important de noter que même si vous utilisez la simultanéité provisionnée, vous pourriez toujours rencontrer un retard de démarrage à froid si Lambda doit réinitialiser l’environnement d’exécution.
En revanche, lorsque la simultanéité réservée est utilisée, Lambda peut résilier complètement un environnement après une période d’inactivité. Le diagramme suivant illustre cela en comparant le cycle de vie d’un environnement d’exécution unique lorsque vous configurez votre fonction en utilisant la simultanéité réservée par rapport à la simultanéité provisionnée.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
Le diagramme présente quatre points d’intérêt :
| Heure | Simultanéité réservée | Simultanéité allouée |
| --- | --- | --- |
| t1 | Rien ne se passe. | Lambda pré-initialise une instance d’environnement d’exécution. |
| t2 | La demande 1 arrive. Lambda doit initialiser une nouvelle instance d’environnement d’exécution. | La demande 1 arrive. Lambda utilise l’instance d’environnement pré-initialisée. |
| t3 | Après un certain temps d’inactivité, Lambda met fin à l’instance d’environnement active. | Rien ne se passe. |
| t4 | La demande 2 arrive. Lambda doit initialiser une nouvelle instance d’environnement d’exécution. | La demande 2 arrive. Lambda utilise l’instance d’environnement pré-initialisée. |
Pour mieux comprendre la simultanéité provisionnée, considérez le diagramme suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
Dans ce diagramme, vous avez une limite de simultanéité de compte de 1 000. Vous décidez d’accorder 400 unités de simultanéité provisionnée à `function-orange`. Toutes les fonctions de votre compte, *y compris* `function-orange`, peuvent utiliser les 600 unités restantes de simultanéité non réservée.
Le diagramme présente cinq points d’intérêt :
+ À `t1`, `function-orange` commence à recevoir des demandes. Puisque Lambda a pré-initialisé 400 instances d’environnement d’exécution, `function-orange` est prête pour une invocation immédiat.
+ À `t2`, `function-orange` atteint 400 demandes simultanées. Par conséquent, `function-orange` n’a plus de simultanéité provisionnée. Cependant, comme il reste de la simultanéité non réservée, Lambda peut l’utiliser pour traiter des demandes supplémentaires vers `function-orange` (il n’y a pas de limitation). Lambda doit créer de nouvelles instances pour répondre à ces demandes, et votre fonction peut subir des latences de démarrage à froid.
+ À `t3`, `function-orange` revient à 400 demandes simultanées après un bref pic de trafic. Lambda est à nouveau capable de traiter toutes les demandes sans latence de démarrage à froid.
+ À `t4`, les fonctions de votre compte subissent un pic de trafic. Cette rafale peut provenir de `function-orange` ou de toute autre fonction de votre compte. Lambda utilise la simultanéité sans réserve pour traiter ces demandes.
+ À `t5`, les fonctions de votre compte atteignent la limite maximale de simultanéité de 1 000 et sont limitées.
L’exemple précédent ne prenait en compte que la simultanéité provisionnée. En pratique, vous pouvez définir à la fois la simultanéité provisionnée et la simultanéité réservée sur une fonction. Vous pourriez le faire si vous aviez une fonction qui gère une charge constante d’invocations le week-end, mais qui connaît régulièrement des pics de trafic le week-end. Dans ce cas, vous pourriez utiliser la simultanéité provisionnée pour définir une quantité de base d’environnements pour traiter les demandes pendant les jours de la semaine, et utiliser la simultanéité réservée pour gérer les pics de trafic du week-end. Considérez le diagramme suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
Dans ce diagramme, supposons que vous configurez 200 unités de simultanéité provisionnée et 400 unités de simultanéité réservée pour `function-orange`. Parce que vous avez configuré la simultanéité réservée, `function-orange` ne peut utiliser aucune des 600 unités de simultanéité non réservée.
Ce diagramme comporte cinq points d’intérêt :
+ À `t1`, `function-orange` commence à recevoir des demandes. Puisque Lambda a pré-initialisé 200 instances d’environnement d’exécution, `function-orange` est prête pour une invocation immédiat.
+ À `t2`, `function-orange` utilise toute sa simultanéité provisionnée. `function-orange` peut continuer à servir les demandes en utilisant la simultanéité réservée, mais ces demandes peuvent subir des latences de démarrage à froid.
+ À `t3`, `function-orange` atteint 400 demandes simultanées. Par conséquent, `function-orange` utilise toute sa simultanéité réservée. Comme `function-orange` ne peut pas utiliser la simultanéité non réservée, les demandes commencent à être limitées.
+ À `t4`, `function-orange` commence à recevoir moins de demandes et ne se limite plus.
+ À `t5`, `function-orange` tombe à 200 demandes simultanées, de sorte que toutes les demandes peuvent à nouveau utiliser la simultanéité provisionnée (c.-à-d. sans latence de démarrage à froid).
La simultanéité réservée et la simultanéité provisionnée comptent toutes deux dans la limite de simultanéité de votre compte et dans les [quotas régionaux](gettingstarted-limits.md). En d’autres termes, l’allocation de la simultanéité réservée et provisionnée peut avoir un impact sur le groupe de simultanéité disponible pour les autres fonctions. La configuration de la simultanéité provisionnée entraîne des frais pour votre. Compte AWS
**Note**
Si la simultanéité provisionnée sur les versions et alias d’une fonction s’ajoute à la simultanéité réservée de la fonction, toutes les invocations s’exécutent sur la simultanéité provisionnée. Cette configuration a également pour effet de limiter la version non publiée de la fonction (`$LATEST`), ce qui empêche son exécution. Vous ne pouvez pas allouer plus de simultanéité provisionnée que de simultanéité réservée pour une fonction.
Pour gérer les paramètres de simultanéité provisionnée pour vos fonctions, consultez [Configuration de la simultanéité provisionnée pour une fonction](provisioned-concurrency.md). Pour automatiser la mise à l’échelle de la concurrence provisionnée en fonction d’une planification ou de l’utilisation de l’application, consultez [Utilisation d’Application Auto Scaling pour automatiser la gestion de la simultanéité provisionnée](provisioned-concurrency.md#managing-provisioned-concurency).
### Comment Lambda alloue la simultanéité provisionnée
La simultanéité provisionnée n’est pas mise en ligne immédiatement après la configuration. Lambda commence à allouer la simultanéité approvisionnée après une phase de préparation d’une ou deux minutes. Pour chaque fonction, Lambda peut provisionner jusqu'à 6 000 environnements d'exécution par minute, quel que soit le cas. Région AWS C’est exactement le même que le [taux de mise à l’échelle de la simultanéité](scaling-behavior.md#scaling-rate) pour les fonctions.
Lorsque vous soumettez une demande d’allocation de simultanéité provisionnée, vous ne pouvez accéder à aucun de ces environnements tant que Lambda n’a pas terminé de les allouer. Par exemple, si vous demandez 5 000 simultanéités allouées, aucune de vos requêtes ne peut utiliser la simultanéité allouée avant que Lambda termine l’allocation des 5 000 environnements d’exécution.
### Comparaison de la simultanéité réservée et de la simultanéité provisionnée
Le tableau suivant résume et compare la simultanéité réservée et provisionnée.
| Rubrique | Simultanéité réservée | Simultanéité allouée |
| --- | --- | --- |
| Définition | Nombre maximal d’instances d’environnement d’exécution pour votre fonction. | Nombre défini d’instances d’environnement d’exécution pré-provisionnées pour votre fonction. |
| Comportement de provisionnement | Lambda provisionne de nouvelles instances sur une base à la demande. | Lambda pré-provisionne les instances (c.-à-d. avant que votre fonction ne commence à recevoir des demandes). |
| Comportement de démarrage à froid | Latence de démarrage à froid possible, puisque Lambda doit créer de nouvelles instances à la demande. | Latence de démarrage à froid impossible, puisque Lambda ne doit pas créer d’instances à la demande. |
| Comportement de limitation | La fonction est limitée lorsque la limite de simultanéité réservée est atteinte. | Si la simultanéité réservée n’est pas définie : la fonction utilise la simultanéité non réservée lorsque la limite de simultanéité provisionnée est atteinte. Si la simultanéité réservée est définie : la fonction est limitée lorsque la limite de simultanéité réservée est atteinte. |
| Comportement par défaut si non défini | La fonction utilise la simultanéité non réservée disponible dans votre compte. | Lambda ne pré-provisionne pas d’instances. Au lieu de cela, si la simultanéité réservée n’est pas définie : la fonction utilise la simultanéité non réservée disponible dans votre compte. Si la simultanéité réservée est définie : la fonction utilise la simultanéité réservée. |
| Tarification | Pas de frais supplémentaires. | Entraîne des frais supplémentaires. |
## Présentation de la simultanéité et des requêtes par seconde
Comme indiqué dans la section précédente, la simultanéité diffère des demandes par seconde. Cette distinction est particulièrement importante lorsque l’on travaille avec des fonctions dont la durée moyenne des requêtes est inférieure à 100 ms.
Pour toutes les fonctions de votre compte, Lambda applique une limite de requêtes par seconde égale à 10 fois le nombre de requêtes simultanées de votre compte. Par exemple, étant donné que la limite de simultanéité par défaut est de 1 000, les fonctions de votre compte peuvent traiter un maximum de 10 000 requêtes par seconde.
Prenons l’exemple d’une fonction dont la durée moyenne des demandes est de 50 ms. À raison de 20 000 requêtes par seconde, voici la simultanéité de cette fonction :
```
Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000
```
Sur la base de ce résultat, vous pouvez vous attendre à ce que la limite de simultanéité de compte de 1 000 soit suffisante pour gérer cette charge. Toutefois, en raison de la limite de 10 000 requêtes par seconde, votre fonction ne peut traiter que 10 000 requêtes par seconde sur un total de 20 000 requêtes. Cette fonction est soumise à une limitation.
La leçon à tirer est que vous devez tenir compte à la fois de la simultanéité et des demandes par seconde lorsque vous configurez les paramètres de simultanéité pour vos fonctions. Dans ce cas, vous devez demander une augmentation de la limite de simultanéité des comptes à 2 000, car cela porterait le nombre total de requêtes par seconde à 20 000.
**Note**
Sur la base de cette limite de requêtes par seconde, il est faux de dire que chaque environnement d’exécution Lambda ne peut traiter qu’un maximum de 10 requêtes par seconde. Au lieu d’observer la charge sur un environnement d’exécution individuel, Lambda ne prend en compte que la simultanéité globale et le nombre total de requêtes par seconde lors du calcul de vos quotas.
### Testez votre compréhension de la concurrence (fonctions inférieures à 100 ms)
Supposons que vous ayez une fonction qui prend, en moyenne, 20 ms pour s’exécuter. Pendant les pics de charge, vous observez 30 000 requêtes par seconde. Quelle est la simultanéité de votre fonction pendant la charge de pointe ?
#### Réponse
La durée moyenne de la fonction est de 20 ms, soit 0,02 seconde. En utilisant la formule de simultanéité, vous pouvez entrer les chiffres pour obtenir une simultanéité de 600 :
```
Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600
```
Par défaut, la limite de simultanéité de compte de 1 000 semble suffisante pour gérer cette charge. Cependant, la limite de 10 000 requêtes par seconde n’est pas suffisante pour traiter les 30 000 requêtes entrantes par seconde. Pour répondre pleinement aux 30 000 requêtes, vous devez demander une augmentation de la limite de simultanéité des comptes à 3 000 ou plus.
La limite de requêtes par seconde s’applique à tous les quotas de Lambda impliquant une simultanéité. En d’autres termes, cela s’applique aux fonctions synchrones à la demande, aux fonctions qui utilisent la simultanéité allouée et au [comportement de mise à l’échelle de simultanéité](scaling-behavior.md). Par exemple, voici quelques scénarios dans lesquels vous devez examiner attentivement vos limites de simultanéité et de requêtes par seconde :
+ Une fonction utilisant la simultanéité à la requête peut connaître une augmentation de 500 requêtes simultanées toutes les 10 secondes, ou de 5 000 requêtes par seconde toutes les 10 secondes, selon la première éventualité.
+ Supposons que vous disposiez d’une fonction dotée d’une allocation de simultanéité allouée de 10. Cette fonction se transforme en simultanéité à la requête après 10 requêtes simultanées ou 100 requêtes par seconde, selon la première éventualité.
## Quotas de simultanéité
Lambda définit des quotas pour la quantité totale de simultanéité que vous pouvez utiliser sur toutes les fonctions d’une Région. Ces quotas existent à deux niveaux :
+ **Au niveau du compte**, vos fonctions peuvent avoir jusqu’à 1 000 unités de simultanéité par défaut. Pour augmenter cette limite, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l’utilisateur Service Quotas*.
+ **Au niveau de la fonction**, vous pouvez réserver par défaut jusqu’à 900 unités de simultanéité pour l’ensemble de vos fonctions. Quelle que soit la limite totale de simultanéité de votre compte, Lambda réserve toujours 100 unités de simultanéité à vos fonctions qui ne réservent pas explicitement la simultanéité. Par exemple, si vous avez augmenté la limite de simultanéité de votre compte à 2 000, vous pouvez réserver jusqu’à 1 900 unités de simultanéité au niveau de la fonction.
+ Au niveau du compte comme au niveau de la fonction, Lambda impose également une limite de requêtes par seconde égale à 10 fois le quota de simultanéité correspondant. [Cela s’applique par exemple à la simultanéité au niveau du compte, aux fonctions utilisant la simultanéité à la demande, aux fonctions utilisant la simultanéité allouée et au comportement de mise à l’échelle de la simultanéité.](scaling-behavior.md) Pour de plus amples informations, veuillez consulter [Présentation de la simultanéité et des requêtes par seconde](#concurrency-vs-requests-per-second).
Pour vérifier le quota de simultanéité actuel de votre compte, utilisez le AWS Command Line Interface (AWS CLI) pour exécuter la commande suivante :
```
aws lambda get-account-settings
```
Vous devriez voir une sortie semblable à la suivante :
```
{
"AccountLimit": {
"TotalCodeSize": 80530636800,
"CodeSizeUnzipped": 262144000,
"CodeSizeZipped": 52428800,
"ConcurrentExecutions": 1000,
"UnreservedConcurrentExecutions": 900
},
"AccountUsage": {
"TotalCodeSize": 410759889,
"FunctionCount": 8
}
}
```
`ConcurrentExecutions` est le quota total de simultanéité au niveau de votre compte. `UnreservedConcurrentExecutions` est la quantité de concurrence réservée que vous pouvez encore allouer à vos fonctions.
Au fur et à mesure que votre fonction reçoit des demandes, Lambda augmente automatiquement le nombre d’environnements d’exécution pour traiter ces demandes jusqu’à ce que votre compte atteigne sa limite de simultanéité. Toutefois, pour éviter une mise à l’échelle excessive en réponse à des pics de trafic soudains, Lambda limite la rapidité avec laquelle vos fonctions peuvent être mises à l’échelle. Ce **taux de mise à l’échelle de la simultanéité** est la vitesse maximale à laquelle les fonctions de votre compte peuvent se mettre à l’échelle en réponse à l’augmentation du nombre de requêtes. (C’est-à-dire la rapidité avec laquelle Lambda peut créer de nouveaux environnements d’exécution.) Le aux de mise à l’échelle de la simultanéité est différent de la limite de simultanéité au niveau du compte, qui est le montant total de simultanéité disponible pour vos fonctions.
**Dans chacune et pour chaque fonction Région AWS, votre taux de mise à l'échelle de la simultanéité est de 1 000 instances d'environnement d'exécution toutes les 10 secondes (ou 10 000 requêtes par seconde toutes les 10 secondes).** En d’autres termes, toutes les 10 secondes, Lambda peut allouer au maximum 1 000 instances d’environnement d’exécution supplémentaires, ou accueillir 10 000 requêtes supplémentaires par seconde, pour chacune de vos fonctions.
En général, il n’est pas nécessaire de se soucier de cette limitation. La vitesse de mise à l’échelle de Lambda est suffisante dans la plupart des cas d’utilisation.
Il est important de noter que le taux de mise à l’échelle de la simultanéité est une limite au niveau de la fonction. Cela signifie que chaque fonction de votre compte peut être mise à l’échelle indépendamment des autres fonctions.
Pour plus d’informations sur les comportements de mise à l’échelle, consultez [Comportement de mise à l’échelle Lambda](scaling-behavior.md).
# Configuration de la simultanéité réservée pour une fonction
Dans Lambda, la [simultanéité](lambda-concurrency.md) est le nombre de demandes en vol que votre fonction traite en même temps. Il existe deux types de contrôles de la simultanéité disponibles :
+ Simultanéité réservée : définit les nombres maximum et minimum d’instances simultanées allouées à votre fonction. Lorsqu’une fonction dispose de la simultanéité réservée, aucune autre fonction ne peut utiliser cette simultanéité. La simultanéité réservée est utile pour garantir que vos fonctions les plus critiques disposent toujours d’une simultanéité suffisante pour traiter les requêtes entrantes. En outre, la simultanéité réservée peut être utilisée pour limiter la simultanéité afin d’éviter de surcharger les ressources en aval, comme les connexions aux bases de données. La simultanéité réservée agit à la fois comme limite inférieure et supérieure : elle réserve la capacité spécifiée exclusivement à votre fonction tout en l’empêchant de dépasser cette limite. Il n’y a pas de frais supplémentaires pour la configuration de la simultanéité réservée pour une fonction.
+ La simultanéité provisionnée est le nombre d’environnements d’exécution pré-initialisés alloués à votre fonction. Ces environnements d’exécution sont prêts à répondre immédiatement aux demandes de fonctions entrantes. La simultanéité allouée est utile pour réduire les latences de démarrage à froid pour les fonctions et est conçue pour rendre les fonctions disponibles avec des temps de réponse de l’ordre de quelques dixaines de millisecondes. En général, ce sont les charges de travail interactives qui tirent le meilleur parti de cette fonctionnalité. Il s’agit des applications dont les utilisateurs lancent des requêtes, telles que les applications Web et mobiles, et qui sont les plus sensibles à la latence. Les charges de travail asynchrones, telles que les pipelines de traitement des données, sont souvent moins sensibles à la latence et ne nécessitent donc généralement pas de simultanéité allouée. La configuration de la simultanéité provisionnée entraîne des frais supplémentaires sur votre Compte AWS.
Cette rubrique explique comment gérer et configurer la simultanéité réservée. Pour une présentation conceptuelle de ces deux types de contrôles de simultanéité, consultez [Simultanéité réservée et simultanéité provisionnée](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Pour plus d’informations sur la configuration de la simultanéité provisionnée, consultez [Configuration de la simultanéité provisionnée pour une fonction](provisioned-concurrency.md).
**Note**
Les fonctions Lambda liées à un mappage des sources d'événements Amazon MQ ont une simultanéité maximale par défaut. Pour Apache Active MQ, le nombre maximum d’instances simultanées est de 5. Pour Rabbit MQ, le nombre maximum d’instances simultanées est de 1. La définition d’une simultanéité réservée ou provisionnée pour votre fonction ne modifie pas ces limites. Pour demander une augmentation de la simultanéité maximale par défaut lors de l’utilisation d’Amazon MQ, contactez Support.
**Topics**
+ [
## Configuration de la simultanéité réservée
](#configuring-concurrency-reserved)
+ [
## Estimation précise de la simultanéité réservée requise pour une fonction
](#estimating-reserved-concurrency)
## Configuration de la simultanéité réservée
Vous pouvez configurer les paramètres de simultanéité réservés pour une fonction à l’aide de la console Lambda ou de l’API Lambda.
**Réserver la simultanéité pour une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez réserver la simultanéité.
1. Sélectionnez **Configuration**, puis **Concurrency (Simultanéité)**.
1. Sous **Concurrency (Simultanéité)**, choisissez **Edit (Modifier)**.
1. Choisissez **Reserve concurrency (Réserver la simultanéité)**. Saisissez la quantité de simultanéité à réserver pour la fonction.
1. Choisissez **Enregistrer**.
Vous pouvez réserver jusqu’à la valeur de la **simultanéité du compte non réservé** moins 100. Les 100 unités de simultanéité restantes concernent les fonctions qui n’utilisent pas la simultanéité réservée. Par exemple, si votre compte a une limite de concurrence de 1 000, vous ne pouvez pas réserver les 1 000 unités de concurrence pour une seule fonction.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
Le fait de réserver la simultanéité à une fonction peut avoir des conséquences sur le groupe de simultanéité disponible pour d’autres fonctions. Par exemple, si vous réservez 100 unités de simultanéité pour `function-a`, les autres fonctions de votre compte doivent partager les 900 unités de simultanéité restantes, même si `function-a` n’utilisent pas les 100 unités de simultanéité réservées.
Pour limiter intentionnellement une fonction, définissez la simultanéité réservée à zéro. Cela empêche votre fonction de traiter des événements jusqu’à ce que vous supprimiez la limite.
Pour configurer la simultanéité réservée avec l’API Lambda, utilisez les opérations d’API suivantes.
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
Par exemple, pour configurer la simultanéité réservée avec la AWS Command Line Interface (CLI), utilisez la commande `put-function-concurrency`. La commande suivante réserve 100 unités de simultanéité pour une fonction nommée `my-function` :
```
aws lambda put-function-concurrency --function-name my-function \
--reserved-concurrent-executions 100
```
Vous devriez voir une sortie semblable à la suivante :
```
{
"ReservedConcurrentExecutions": 100
}
```
## Estimation précise de la simultanéité réservée requise pour une fonction
Si votre fonction sert actuellement du trafic, vous pouvez facilement visualiser ses métriques de simultanéité à l’aide des [métriques CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). Plus précisément, la métrique `ConcurrentExecutions` vous montre le nombre d’invocations simultanées pour chaque fonction de votre compte.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Le graphique précédent indique que cette fonction répond à une moyenne de 5 à 10 demandes simultanées à tout moment, et qu’elle atteint un pic de 20 demandes lors d’une journée typique. Supposons qu’il y ait beaucoup d’autres fonctions dans votre compte. ** Si cette fonction est essentielle à votre application et que vous ne voulez pas perdre de demandes**, utilisez un nombre supérieur ou égal à 20 comme paramètre de simultanéité réservé.
Par ailleurs, rappelez-vous que vous pouvez également [calculer la simultanéité](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) à l’aide de la formule suivante :
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
En multipliant le nombre moyen de demandes par seconde par la durée moyenne des demandes en secondes, vous obtenez une estimation approximative du niveau de simultanéité que vous devez réserver. Vous pouvez estimer les demandes moyennes par seconde à l’aide de la métrique `Invocation`, et la durée moyenne des demandes en secondes à l’aide de la métrique `Duration`. Pour plus d’informations, consultez [Utilisation des métriques CloudWatch avec Lambda](monitoring-metrics.md).
Familiarisez-vous avec vos contraintes de débit en amont et en aval. Bien que les fonctions Lambda se mettent à l’échelle parfaitement, les dépendances en amont et en aval peuvent avoir des mêmes capacités de débit différentes. Si vous devez limiter le niveau de mise à l’échelle de votre fonction, configurez la simultanéité réservée sur votre fonction.
# Configuration de la simultanéité provisionnée pour une fonction
Dans Lambda, la [simultanéité](lambda-concurrency.md) est le nombre de demandes en vol que votre fonction traite en même temps. Il existe deux types de contrôles de la simultanéité disponibles :
+ Simultanéité réservée : définit les nombres maximum et minimum d’instances simultanées allouées à votre fonction. Lorsqu’une fonction dispose de la simultanéité réservée, aucune autre fonction ne peut utiliser cette simultanéité. La simultanéité réservée est utile pour garantir que vos fonctions les plus critiques disposent toujours d’une simultanéité suffisante pour traiter les requêtes entrantes. En outre, la simultanéité réservée peut être utilisée pour limiter la simultanéité afin d’éviter de surcharger les ressources en aval, comme les connexions aux bases de données. La simultanéité réservée agit à la fois comme limite inférieure et supérieure : elle réserve la capacité spécifiée exclusivement à votre fonction tout en l’empêchant de dépasser cette limite. Il n’y a pas de frais supplémentaires pour la configuration de la simultanéité réservée pour une fonction.
+ La simultanéité provisionnée est le nombre d’environnements d’exécution pré-initialisés alloués à votre fonction. Ces environnements d’exécution sont prêts à répondre immédiatement aux demandes de fonctions entrantes. La simultanéité allouée est utile pour réduire les latences de démarrage à froid pour les fonctions et est conçue pour rendre les fonctions disponibles avec des temps de réponse de l’ordre de quelques dixaines de millisecondes. En général, ce sont les charges de travail interactives qui tirent le meilleur parti de cette fonctionnalité. Il s’agit des applications dont les utilisateurs lancent des requêtes, telles que les applications Web et mobiles, et qui sont les plus sensibles à la latence. Les charges de travail asynchrones, telles que les pipelines de traitement des données, sont souvent moins sensibles à la latence et ne nécessitent donc généralement pas de simultanéité allouée. La configuration de la simultanéité provisionnée entraîne des frais supplémentaires sur votre Compte AWS.
Cette rubrique explique comment gérer et configurer la simultanéité provisionnée. Pour une présentation conceptuelle de ces deux types de contrôles de simultanéité, consultez [Simultanéité réservée et simultanéité provisionnée](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Pour plus d’informations sur la configuration de la simultanéité réservée, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md).
**Note**
Les fonctions Lambda liées à un mappage des sources d’événements Amazon MQ ont une simultanéité maximale par défaut. Pour Apache Active MQ, le nombre maximum d’instances simultanées est de 5. Pour Rabbit MQ, le nombre maximum d’instances simultanées est de 1. La définition d’une simultanéité réservée ou provisionnée pour votre fonction ne modifie pas ces limites. Pour demander une augmentation de la simultanéité maximale par défaut lors de l’utilisation d’Amazon MQ, contactez Support.
**Topics**
+ [
## Configuration de la simultanéité provisionnée
](#configuring-provisioned-concurrency)
+ [
## Estimation précise de la simultanéité provisionnée requise pour une fonction
](#estimating-provisioned-concurrency)
+ [
## Optimisation du code de fonction lors de l’utilisation de la simultanéité provisionnée
](#optimizing-latency)
+ [
## Utilisation de variables d’environnement pour visualiser et contrôler le comportement de simultanéité provisionnée
](#pc-environment-variables)
+ [
## Comprendre le comportement de journalisation et de facturation avec la simultanéité provisionnée
](#pc-logging-behavior)
+ [
## Utilisation d’Application Auto Scaling pour automatiser la gestion de la simultanéité provisionnée
](#managing-provisioned-concurency)
## Configuration de la simultanéité provisionnée
Vous pouvez configurer les paramètres de simultanéité provisionnés pour une fonction à l’aide de la console Lambda ou de l’API Lambda.
**Pour allouer de la simultanéité provisionnée pour une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez allouer de la simultanéité provisionnée.
1. Sélectionnez **Configuration**, puis **Concurrency (Simultanéité)**.
1. Sous **Provisioned concurrency configurations (Configurations de simultanéité provisionnée)**, sélectionnez **Add configuration (Ajouter une configuration)**.
1. Choisissez le type de qualificateur, ainsi que l’alias ou la version.
**Note**
Vous ne pouvez pas utiliser la simultanéité provisionnée avec la \$1LATEST version d’une fonction.
Si votre fonction possède une source d’événement, assurez-vous que la source d’événement pointe vers le bon alias ou la bonne version de la fonction. Sinon, votre fonction n’utilisera pas les environnements de simultanéité provisionnés.
1. Saisissez un nombre sous **Simultanéité provisionnée**.
1. Choisissez **Enregistrer**.
Vous pouvez configurer jusqu’à la **simultanéité du compte non réservé** dans votre compte, moins 100. Les 100 unités de simultanéité restantes concernent les fonctions qui n’utilisent pas la simultanéité réservée. Par exemple, si votre compte a une limite de simultanéité de 1 000 et que vous n’avez pas attribué de simultanéité réservée ou provisionnée à l’une de vos autres fonctions, vous pouvez configurer un maximum de 900 unités de simultanéité provisionnées pour une seule fonction.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)
La configuration de la simultanéité provisionnée pour une fonction a des conséquences sur le groupe de simultanéité disponible pour d’autres fonctions. Par exemple, si vous configurez 100 unités de simultanéité provisionnée pour `function-a`, les autres fonctions de votre compte doivent partager les 900 unités de simultanéité restantes. Et ce même si `function-a` n’utilise pas les 100 unités.
Il est possible d’allouer à la fois de la simultanéité réservée et de la simultanéité provisionnée pour la même fonction. Dans de tels cas, la simultanéité provisionnée ne peut pas dépasser la simultanéité réservée.
Cette limite s’applique aux versions de fonctions. La simultanéité provisionnée maximale que vous pouvez allouer à une version de fonction spécifique est égale à la simultanéité réservée de la fonction moins la simultanéité provisionnée sur les autres versions de fonction.
Pour configurer la simultanéité provisionnée avec l’API Lambda, utilisez les opérations d’API suivantes.
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
Par exemple, pour configurer la simultanéité provisionnée avec le AWS Command Line Interface (CLI), utilisez la commande `put-provisioned-concurrency-config`. La commande suivante alloue 100 unités de simultanéité provisionnée pour l’alias `BLUE` d’une fonction nommée `my-function` :
```
aws lambda put-provisioned-concurrency-config --function-name my-function \
--qualifier BLUE \
--provisioned-concurrent-executions 100
```
Vous devriez voir une sortie semblable à la suivante :
```
{
"Requested ProvisionedConcurrentExecutions": 100,
"Allocated ProvisionedConcurrentExecutions": 0,
"Status": "IN_PROGRESS",
"LastModified": "2023-01-21T11:30:00+0000"
}
```
## Estimation précise de la simultanéité provisionnée requise pour une fonction
Vous pouvez consulter les métriques de simultanéité de n’importe quelle fonction active à l’aide des métriques [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). Plus précisément, la métrique `ConcurrentExecutions` vous montre le nombre d’invocations simultanées pour les fonctions de votre compte.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Le graphique précédent indique que cette fonction répond à une moyenne de 5 à 10 demandes simultanées à tout moment, et qu’elle atteint un pic de 20 demandes. Supposons qu’il y ait beaucoup d’autres fonctions dans votre compte. ** Si cette fonction est essentielle à votre application et que vous avez besoin d’une réponse à faible latence à chaque invocation**, configurez au moins 20 unités de simultanéité provisionnée.
Rappelez-vous que vous pouvez également [calculer la simultanéité](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) à l’aide de la formule suivante :
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
Pour estimer le niveau de simultanéité dont vous avez besoin, multipliez le nombre moyen de demandes par seconde par la durée moyenne des demandes en secondes. Vous pouvez estimer les demandes moyennes par seconde à l’aide de la métrique `Invocation`, et la durée moyenne des demandes en secondes à l’aide de la métrique `Duration`.
Lors de la configuration de la simultanéité provisionnée, Lambda suggère d’ajouter un tampon de 10 % en plus de la quantité de simultanéité dont votre fonction a généralement besoin. Par exemple, si votre fonction atteint habituellement un pic de 200 demandes simultanées, définissez votre simultanéité provisionnée à 220 (200 demandes simultanées \$1 10 % = 220 simultanéités provisionnées).
## Optimisation du code de fonction lors de l’utilisation de la simultanéité provisionnée
Si vous utilisez la simultanéité provisionnée, pensez à restructurer votre code de fonction pour optimiser la faible latence. Pour les fonctions utilisant la simultanéité provisionnée, Lambda exécute n’importe quel code d’initialisation (c’est-à-dire le chargement de bibliothèques et l’instanciation de clients) au moment de l’allocation. Il est donc conseillé de déplacer un maximum d’initialisation en dehors du gestionnaire de la fonction principale pour éviter d’avoir un impact sur la latence lors des invocations à la fonction. En revanche, l’initialisation de bibliothèques ou l’instanciation de clients dans le code de votre gestionnaire principal signifie que votre fonction doit l’exécuter à chaque fois qu’elle est invoquée (que vous utilisiez ou non la simultanéité provisionnée).
Pour les appels à la demande, Lambda peut avoir besoin de réexécuter votre code d’initialisation chaque fois que votre fonction démarre à froid. Pour de telles fonctions, vous pouvez choisir de différer l’initialisation d’une fonctionnalité spécifique jusqu’à ce que la fonction ait besoin d’elle. Par exemple, prenons le flux de contrôle suivant pour un gestionnaire Lambda :
```
def handler(event, context):
...
if ( some_condition ):
// Initialize CLIENT_A to perform a task
else:
// Do nothing
```
Dans l’exemple précédent, au lieu d’initialiser `CLIENT_A` en dehors du gestionnaire principal, le développeur a initialisé dans l’instruction `if`. Ainsi, Lambda n’exécute ce code que si `some_condition` est satisfaite. Si vous initialisez `CLIENT_A` en dehors du gestionnaire principal, Lambda exécute ce code à chaque démarrage à froid. Cela peut augmenter le temps de latence global.
Vous pouvez mesurer les démarrages à froid à mesure que Lambda prend de l’ampleur en ajoutant la surveillance X-Ray à votre fonction. Une fonction utilisant la simultanéité allouée ne présente pas de comportement de démarrage à froid puisque l’environnement d’exécution est préparé avant l’invocation. Cependant, la simultanéité allouée doit être appliquée à une [version ou à un alias spécifique](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) d’une fonction, et non à la version \$1LATEST. Dans les cas où le comportement de démarrage à froid persiste, assurez-vous que vous invoquez la version de l’alias pour laquelle la simultanéité allouée est configurée.
## Utilisation de variables d’environnement pour visualiser et contrôler le comportement de simultanéité provisionnée
Il est possible que votre fonction utilise la totalité de sa simultanéité provisionnée. Lambda utilise des instances à la demande pour gérer tout trafic excédentaire. Pour déterminer quel type d’initialisation Lambda a utilisé pour un environnement particulier, vérifiez la valeur de la variable d’environnement `AWS_LAMBDA_INITIALIZATION_TYPE`. Cette variable a deux valeurs possibles : `provisioned-concurrency` ou`on-demand`. La valeur de `AWS_LAMBDA_INITIALIZATION_TYPE` est immuable et reste constante pendant toute la durée de vie de l’environnement. Pour vérifier la valeur d’une variable d’environnement dans le code de votre fonction, consultez [Récupération de variables d’environnement Lambda](configuration-envvars.md#retrieve-environment-variables).
Si vous utilisez l’environnement d’exécution .NET 8, vous pouvez configurer la variable d’environnement `AWS_LAMBDA_DOTNET_PREJIT` pour améliorer la latence des fonctions, même si elles n’utilisent pas de simultanéité provisionnée. Le runtime .NET compile et initialise lentement chaque bibliothèque que votre code appelle pour la première fois. Par conséquent, la première invocation d’une fonction Lambda peut prendre plus de temps que les invocations suivantes. Pour atténuer ce problème, vous pouvez choisir l’une des trois valeurs `AWS_LAMBDA_DOTNET_PREJIT` :
+ `ProvisionedConcurrency` : Lambda effectue une compilation JIT à l’avance pour tous les environnements utilisant la simultanéité provisionnée. C’est la valeur par défaut.
+ `Always` : Lambda effectue une compilation JIT à l’avance pour chaque environnement, même si la fonction n’utilise pas la simultanéité provisionnée.
+ `Never` : Lambda désactive la compilation JIT à l’avance pour tous les environnements.
## Comprendre le comportement de journalisation et de facturation avec la simultanéité provisionnée
Pour les environnements de simultanéité provisionnée, le code d’initialisation de votre fonction s’exécute pendant l’allocation et périodiquement lorsque Lambda recycle les instances actives de votre environnement. Lambda vous facture l’initialisation même si l’instance d’environnement ne traite jamais de demande. La simultanéité provisionnée s’exécute en continu et est facturée séparément des coûts d’initialisation et d’invocation. Pour plus d’informations, consultez [Tarification AWS Lambda](https://aws.amazon.com/lambda/pricing/).
Lorsque vous configurez une fonction Lambda avec une simultanéité provisionnée, Lambda pré-initialise cet environnement d’exécution afin qu’il soit disponible avant les demandes d’invocation. Lambda enregistre le [champ Init Duration](lambda-runtime-environment.md#runtimes-lifecycle-ib) de la fonction dans un événement de journal [platform-initReport](telemetry-schema-reference.md#platform-initReport) au format de journalisation JSON chaque fois que l’environnement est initialisé. Pour voir cet événement de journal, configurez votre [Niveau de journal JSON](monitoring-cloudwatchlogs-logformat.md) sur au moins `INFO`. Vous pouvez également utiliser l’[API de télémétrie](telemetry-api-reference.md) pour consulter les événements de plateforme dans lesquels le champ Init Duration est indiqué.
## Utilisation d’Application Auto Scaling pour automatiser la gestion de la simultanéité provisionnée
Vous pouvez utiliser Application Auto Scaling pour gérer la simultanéité provisionnée selon une planification ou en fonction de l’utilisation. Si vous observez des schémas prévisibles de trafic vers votre fonction, utilisez la mise à l’échelle programmée. Si vous souhaitez que votre fonction maintienne un pourcentage d’utilisation spécifique, utilisez une politique de mise à l’échelle de suivi cible.
**Note**
Si vous utilisez Application Auto Scaling pour gérer la simultanéité provisionnée de votre fonction, assurez-vous de [configurer d’abord une valeur de simultanéité provisionnée initiale](#configuring-provisioned-concurrency). Si votre fonction ne possède pas de valeur de simultanéité provisionnée initiale, Application Auto Scaling risque de ne pas gérer correctement la mise à l’échelle des fonctions.
### Mise à l’échelle planifiée
Avec Application Auto Scaling, vous pouvez définir votre propre planification de mise à l’échelle en fonction des changements de charge prévisibles. Pour plus d’informations et d’exemples, consultez [Mise à l’échelle programmée pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) dans le Guide de l’utilisateur Application Auto Scaling, et [Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/) sur le blog AWS Compute.
### Suivi de la cible
Avec le suivi des cibles, Application Auto Scaling crée et gère un ensemble d’alarmes CloudWatch basées sur la façon dont vous définissez votre politique de mise à l’échelle. Lorsque ces alarmes sont activées, Application Auto Scaling ajuste automatiquement la quantité d’environnements alloués à l’aide de la simultanéité provisionnée. Le suivi des cibles est idéal pour les applications dont les modèles de trafic ne sont pas prévisibles.
Pour mettre à l’échelle la simultanéité provisionnée à l’aide du suivi des cibles, utilisez les opérations de l’API Application Auto Scaling `RegisterScalableTarget` et `PutScalingPolicy`. Par exemple, si vous utilisez la AWS Command Line Interface (CLI), procédez comme suit :
1. Enregistrez l’alias d’une fonction en tant que cible de mise à l’échelle. L’exemple suivant enregistre l’alias BLUE d’une fonction nommée `my-function` :
```
aws application-autoscaling register-scalable-target --service-namespace lambda \
--resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \
--scalable-dimension lambda:function:ProvisionedConcurrency
```
1. Ensuite, appliquez une stratégie de mise à l’échelle à la cible. L’exemple suivant configure Application Auto Scaling afin d’ajuster la configuration de simultanéité provisionnée pour un alias de façon à maintenir l’utilisation proche de 70 %, mais vous pouvez appliquer n’importe quelle valeur comprise entre 10 % et 90 %.
```
aws application-autoscaling put-scaling-policy \
--service-namespace lambda \
--scalable-dimension lambda:function:ProvisionedConcurrency \
--resource-id function:my-function:BLUE \
--policy-name my-policy \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'
```
Vous devriez obtenir un résultat du type suivant :
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
"Alarms": [
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
},
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
}
]
}
```
Application Auto Scaling crée deux alarmes dans CloudWatch. La première alarme se déclenche lorsque l’utilisation de la simultanéité provisionnée dépasse systématiquement 70 %. Lorsque cela se produit, Application Auto Scaling alloue davantage de simultanéité approvisionnée afin de réduire l’utilisation. La deuxième alarme se déclenche lorsque l’utilisation est constamment inférieure à 63 % (90 % de la cible de 70 %). Lorsque cela se produit, Application Auto Scaling réduit la simultanéité approvisionnée de l’alias.
**Note**
Lambda émet la métrique `ProvisionedConcurrencyUtilization` uniquement lorsque votre fonction est active et reçoit des demandes. Pendant les périodes d’inactivité, aucune métrique n’est émise et vos alarmes d’autoscaling entrent dans l’état `INSUFFICIENT_DATA`. Par conséquent, l’autoscaling d’application ne pourra pas ajuster la simultanéité allouée à votre fonction. Cela peut entraîner des frais imprévus.
Dans l’exemple suivant, une fonction adapte son échelle entre une quantité minimum et maximum de simultanéité approvisionnée en fonction de l’utilisation.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**Légende**
+ ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-scaling-provisioned.instances.png) Instances de la fonction
+ ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-scaling-provisioned.open.png) Demandes ouvertes
+ ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) Simultanéité provisionnée
+ ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-scaling-provisioned.standard.png) Simultanéité standard
Quand le nombre de demandes ouvertes augmente, Application Auto Scaling augmente la simultanéité provisionnée par échelons jusqu’à ce qu’elle atteigne le maximum configuré. Une fois le maximum atteint, la fonction peut continuer à se mettre à l’échelle en fonction de la simultanéité standard, non réservée, si votre compte n’a pas atteint sa limite de simultanéité. Lorsque l’utilisation chute et reste constamment faible, Application Auto Scaling réduit la simultanéité provisionnée par échelons périodiques plus petits.
Les deux alarmes gérées par Application Auto Scaling utilisent la statistique moyenne par défaut. Les fonctions qui subissent des rafales de trafic peuvent ne pas déclencher ces alarmes. Par exemple, supposons que votre fonction Lambda s’exécute rapidement (c’est-à-dire entre 20 et 100 ms) et que votre modèle de trafic se produise sous forme de rafales rapides. Dans ce cas, le nombre de demandes dépasse la simultanéité allouée pendant la rafale. Cependant, Application Auto Scaling nécessite que la charge en rafale soit maintenue pendant au moins 3 minutes afin de provisionner des environnements supplémentaires. De plus, les deux alarmes CloudWatch nécessitent trois points de données qui atteignent la moyenne cible avant d’activer la politique d’autoscaling. Si votre fonction connaît des pics de trafic rapides, l’utilisation de la statistique **Maximum** au lieu de la statistique **Average** peut être plus efficace pour mettre à l’échelle la simultanéité provisionnée afin de minimiser les démarrages à froid.
Pour plus d’informations sur l’utilisation des politiques de mise à l’échelle du suivi des cibles, consultez [Politiques de mise à l’échelle du suivi des cibles pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
# Comportement de mise à l’échelle Lambda
Au fur et à mesure que votre fonction reçoit des demandes, Lambda augmente automatiquement le nombre d’environnements d’exécution pour traiter ces demandes jusqu’à ce que votre compte atteigne sa limite de simultanéité. Toutefois, pour éviter une mise à l’échelle excessive en réponse à des pics de trafic soudains, Lambda limite la rapidité avec laquelle vos fonctions peuvent être mises à l’échelle. Ce **taux de mise à l’échelle de la simultanéité** est la vitesse maximale à laquelle les fonctions de votre compte peuvent se mettre à l’échelle en réponse à l’augmentation du nombre de requêtes. (C’est-à-dire la rapidité avec laquelle Lambda peut créer de nouveaux environnements d’exécution.) Le aux de mise à l’échelle de la simultanéité est différent de la limite de simultanéité au niveau du compte, qui est le montant total de simultanéité disponible pour vos fonctions.
## Taux de mise à l’échelle de la simultanéité
**Dans chaque Région AWS et pour chaque fonction, votre taux de mise à l’échelle de la simultanéité est de 1 000 instances d’environnement d’exécution toutes les 10 secondes (ou 10 000 requêtes par seconde toutes les 10 secondes).** En d’autres termes, toutes les 10 secondes, Lambda peut allouer au maximum 1 000 instances d’environnement d’exécution supplémentaires, ou accueillir 10 000 requêtes supplémentaires par seconde, pour chacune de vos fonctions.
En général, il n’est pas nécessaire de se soucier de cette limitation. La vitesse de mise à l’échelle de Lambda est suffisante dans la plupart des cas d’utilisation.
Il est important de noter que le taux de mise à l’échelle de la simultanéité est une limite au niveau de la fonction. Cela signifie que chaque fonction de votre compte peut être mise à l’échelle indépendamment des autres fonctions.
**Note**
Dans la pratique, Lambda s’efforce d’augmenter votre taux de simultanéité de manière continue au fil du temps, plutôt que de procéder à une seule recharge de 1 000 unités toutes les 10 secondes.
Lambda n’accumule pas les portions inutilisées de votre taux de mise à l’échelle de la simultanéité. Cela signifie qu’à tout moment, votre taux de mise à l’échelle est toujours de 1 000 unités simultanées au maximum. Par exemple, si vous n’utilisez aucune de vos 1 000 unités de simultanéité disponibles dans un intervalle de 10 secondes, vous n’accumulerez pas 1 000 unités supplémentaires dans le prochain intervalle de 10 secondes. Votre taux de mise à l’échelle de la simultanéité est toujours de 1 000 dans le prochain intervalle de 10 secondes.
Tant que votre fonction continue de recevoir un nombre croissant de demandes, Lambda est mis à l’échelle au rythme le plus rapide à votre disposition, jusqu’à la limite de simultanéité de votre compte. Vous pouvez limiter le niveau de simultanéité que les fonctions individuelles peuvent utiliser en [configurant la simultanéité réservée.](configuration-concurrency.md) Si l’entrée des demandes est plus rapide que la capacité de mise à l’échelle de votre fonction ou si votre fonction atteint la simultanéité maximale, des demandes supplémentaires échouent alors avec un code de limitation (code d’état 429).
# Surveillance de la simultanéité
Lambda émet des métriques CloudWatch Amazon pour vous aider à surveiller la simultanéité de vos fonctions. Cette rubrique explique ces métriques et comment les interpréter.
**Topics**
+ [
## Métriques de simultanéité générales
](#general-concurrency-metrics)
+ [
## Métriques de simultanéité provisionnée
](#provisioned-concurrency-metrics)
+ [
## Travailler avec la métrique `ClaimedAccountConcurrency`
](#claimed-account-concurrency)
## Métriques de simultanéité générales
Utilisez les métriques suivantes pour surveiller la simultanéité de vos fonctions Lambda. La granularité de chaque métrique est d'une minute.
+ `ConcurrentExecutions` : le nombre d'invocations simultanées actives à un moment donné. Lambda émet cette métrique pour toutes les fonctions, versions et alias. Pour toute fonction de la console Lambda, Lambda affiche le graphique pour `ConcurrentExecutions` nativement native dans l'onglet **Surveillance**, sous **Métriques**. Consultez cette métrique en utilisant **MAX**.
+ `UnreservedConcurrentExecutions` : le nombre d'invocations simultanées actives qui utilisent la simultanéité non réservée. Lambda émet cette métrique pour toutes les fonctions d'une région. Consultez cette métrique en utilisant **MAX**.
+ `ClaimedAccountConcurrency` – Le niveau de simultanéité qui n'est pas disponible pour les appels à la demande. `ClaimedAccountConcurrency` est égal à `UnreservedConcurrentExecutions` plus le montant de la simultanéité allouée (c'est-à-dire le total de la simultanéité réservée plus le total de la simultanéité provisionnée). Si `ClaimedAccountConcurrency` dépasse la limite de simultanéité de votre compte, vous pouvez [demander une limite de simultanéité de compte plus élevée](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/). Consultez cette métrique en utilisant **MAX**. Pour de plus amples informations, veuillez consulter [Travailler avec la métrique `ClaimedAccountConcurrency`](#claimed-account-concurrency).
## Métriques de simultanéité provisionnée
Utilisez les métriques suivantes pour surveiller les fonctions Lambda utilisant la simultanéité provisionnée. La granularité de chaque métrique est d'une minute.
+ `ProvisionedConcurrentExecutions` : le nombre d'instances d'environnement d'exécution qui traitent activement une invocation sur une simultanéité allouée. Lambda émet cette métrique pour chaque version de fonction et alias avec simultanéité provisionnée configurée. Consultez cette métrique en utilisant **MAX**.
`ProvisionedConcurrentExecutions` n'est pas le même que le nombre total de simultanéités provisionnées que vous allouez. Par exemple, supposons que vous allouiez 100 unités de simultanéité provisionnée à une version de fonction. Au cours d'une minute donnée, si au maximum 50 de ces 100 environnements d'exécution traitent des invocations simultanément, la valeur de **MAX** (`ProvisionedConcurrentExecutions`) est de 50.
+ `ProvisionedConcurrencyInvocations` – Le nombre de fois où Lambda invoque votre code de fonction en utilisant la simultanéité provisionnée. Lambda émet cette métrique pour chaque version de fonction et alias avec simultanéité provisionnée configurée. Consultez cette métrique en utilisant **SUM**.
`ProvisionedConcurrencyInvocations` diffère de `ProvisionedConcurrentExecutions`, car `ProvisionedConcurrencyInvocations` compte le nombre total d'invocations, tandis que `ProvisionedConcurrentExecutions` compte le nombre d'environnements actifs. Pour comprendre cette distinction, examinons le scénario suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
Dans cet exemple, supposons que vous receviez une invocation par minute et que chaque invocation dure deux minutes. Chaque barre horizontale orange représente une demande unique. Supposons que vous allouiez dix unités de simultanéité provisionnée à cette fonction, de sorte que chaque demande s'exécute sur la simultanéité provisionnée.
Entre les minutes 0 et 1, `Request 1` entre en jeu. **À la minute 1**, la valeur de **MAX** (`ProvisionedConcurrentExecutions`) est de un, puisqu'au maximum un environnement d'exécution a été actif au cours de la dernière minute. La valeur de **SUM** (`ProvisionedConcurrencyInvocations`) est également de un, puisqu'une nouvelle demande a été reçue au cours de la dernière minute.
Entre les minutes 1 et 2, `Request 2` entre en jeu et `Request 1` continue de fonctionner. **À la minute 2**, la valeur de **MAX** (`ProvisionedConcurrentExecutions`) est de deux, puisqu'au maximum deux environnements d'exécution ont été actifs au cours de la dernière minute. Toutefois, la valeur de **SUM** (`ProvisionedConcurrencyInvocations`) est de un, car une seule nouvelle demande a été reçue au cours de la dernière minute. Ce comportement métrique se poursuit jusqu'à la fin de l'exemple.
+ `ProvisionedConcurrencySpilloverInvocations` : le nombre de fois où Lambda invoque votre fonction sur la simultanéité standard (réservée ou non) lorsque toute la simultanéité provisionnée est utilisée. Lambda émet cette métrique pour chaque version de fonction et alias avec simultanéité provisionnée configurée. Consultez cette métrique en utilisant **SUM**. La valeur de `ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` doit être égale au nombre total d'invocations de fonctions (c'est-à-dire à la métrique `Invocations`).
`ProvisionedConcurrencyUtilization` : le pourcentage de la simultanéité provisionnée utilisée (c'est à dire la valeur de `ProvisionedConcurrentExecutions` divisée par la quantité totale de la simultanéité provisionnée allouée). Lambda émet cette métrique pour chaque version de fonction et alias avec simultanéité provisionnée configurée. Consultez cette métrique en utilisant **MAX**.
Par exemple, supposons que vous provisionniez 100 unités de simultanéité provisionnée à une version de fonction. Au cours d'une minute donnée, si au maximum 60 de ces 100 environnements d'exécution traitent des invocations simultanément, la valeur de **MAX** (`ProvisionedConcurrentExecutions`) est de 60 et la valeur de **MAX** (`ProvisionedConcurrencyUtilization`) est de 0,6.
Une valeur élevée pour `ProvisionedConcurrencySpilloverInvocations` peut indiquer que vous devez allouer un accès simultané supplémentaire à votre fonction. Vous pouvez également [configurer Application Auto Scaling pour gérer la mise à l'échelle automatique de la simultanéité provisionnée](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency) en fonction de seuils prédéfinis.
À l'inverse, des valeurs constamment faibles pour `ProvisionedConcurrencyUtilization` peuvent indiquer que vous avez trop alloué de simultanéité provisionnée pour votre fonction.
## Travailler avec la métrique `ClaimedAccountConcurrency`
Lambda utilise la métrique `ClaimedAccountConcurrency` pour déterminer le niveau de simultanéité disponible sur votre compte pour les appels à la demande. Lambda calcule `ClaimedAccountConcurrency` à l'aide de la formule suivante :
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions` correspond au nombre d'invocations simultanées actives qui utilisent la simultanéité non réservée. La simultanéité allouée est la somme des deux parties suivantes (en les remplaçant `RC` en tant que « simultanéité réservée » et `PC` en tant que « simultanéité provisionnée ») :
+ Total pour `RC` entre toutes les fonctions d'une région.
+ Total de `PC` entre toutes les fonctions d'une région qui utilisent `PC`, à l'exception des fonctions qui utilisent `RC`.
**Note**
Vous ne pouvez pas allouer plus de `PC` que ce `RC` pour une fonction. Ainsi, le `RC` d’une fonction est toujours supérieur ou égal à son `PC`. Pour calculer la contribution à la simultanéité allouée pour de telles fonctions avec `PC` et `RC`, Lambda ne prend en compte que `RC`, qui est le maximum des deux.
Lambda utilise la métrique `ClaimedAccountConcurrency` plutôt que `ConcurrentExecutions` pour déterminer le niveau de simultanéité disponible pour les appels à la demande. Bien que la métrique `ConcurrentExecutions` soit utile pour suivre le nombre d'appels simultanés actifs, elle ne reflète pas toujours votre véritable disponibilité simultanée. En effet, Lambda prend également en compte la simultanéité réservée et la simultanéité provisionnée pour déterminer la disponibilité.
Pour illustrer `ClaimedAccountConcurrency`, imaginez un scénario dans lequel vous configurez une grande partie de la simultanéité réservée et de la simultanéité provisionnée entre vos fonctions qui restent largement inutilisées. Dans l'exemple suivant, supposons que la limite de simultanéité de votre compte est de 1 000 et que votre compte comporte deux fonctions principales : `function-orange` et `function-blue`. Vous allouez 600 unités de simultanéité réservée pour `function-orange`. Vous allouez 200 unités de simultanéité provisionnée pour `function-blue`. Supposons qu'au fil du temps, vous déployiez des fonctions supplémentaires et observiez le schéma de trafic suivant :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/claimed-account-concurrency.png)
Dans le schéma précédent, les lignes noires indiquent l'utilisation simultanée réelle au fil du temps, et la ligne rouge indique la valeur de `ClaimedAccountConcurrency` au fil du temps. Dans ce scénario, `ClaimedAccountConcurrency` est égal à 800 au minimum malgré une faible utilisation réelle de la simultanéité entre vos fonctions. Cela est dû au fait que vous avez alloué 800 unités de simultanéité au total pour `function-orange` et `function-blue`. Du point de vue de Lambda, vous avez « revendiqué » cette simultanéité pour l'utiliser, il ne vous reste donc que 200 unités de simultanéité pour les autres fonctions.
Pour ce scénario, la simultanéité allouée est de 800 dans la formule `ClaimedAccountConcurrency`. Nous pouvons ensuite déduire la valeur de `ClaimedAccountConcurrency` en différents points du diagramme :
+ Au niveau de `t1`, `ClaimedAccountConcurrency` est égal à 800 (800 \$1 0 `UnreservedConcurrentExecutions`).
+ Au niveau de `t2`, `ClaimedAccountConcurrency` est égal à 900 (800 \$1 100 `UnreservedConcurrentExecutions`).
+ Au niveau de `t3`, `ClaimedAccountConcurrency` est à nouveau égal à 900 (800 \$1 100 `UnreservedConcurrentExecutions`).
### Configuration de la `ClaimedAccountConcurrency` métrique dans CloudWatch
Lambda émet la métrique en entrée. `ClaimedAccountConcurrency` CloudWatch Utilisez cette métrique avec la valeur de `SERVICE_QUOTA(ConcurrentExecutions)` pour obtenir le pourcentage d'utilisation de la simultanéité sur votre compte, comme indiqué dans la formule suivante :
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
La capture d'écran suivante montre comment vous pouvez représenter graphiquement cette formule CloudWatch. La ligne verte `claim_utilization` représente l'utilisation simultanée de ce compte, qui est d'environ 40 % :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
La capture d'écran précédente inclut également une CloudWatch alarme qui s'`ALARM`active lorsque l'utilisation simultanée dépasse 70 %. Vous pouvez utiliser la métrique `ClaimedAccountConcurrency` ainsi que des alarmes similaires pour déterminer de manière proactive le moment où vous pourriez avoir besoin de demander une limite de simultanéité de comptes plus élevée.