Mise à l'échelle de fonction Lambda

La simultanéité est le nombre de demandes en cours d'exécution que votre fonction AWS Lambda traite en même temps. 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 pour toutes les fonctions d'une région. Pour répondre aux besoins spécifiques de votre compte, vous pouvez demander une augmentation du quota 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 horizontale 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.

Sections

• Comprendre et visualiser la simultanéité
• Calcul de la simultanéité
• Simultanéité réservée et simultanéité provisionnée
• Quotas de simultanéité
• Estimation précise de la simultanéité requise
• Métriques de simultanéité
• Configuration de la simultanéité réservée
• Configuration de la simultanéité provisionnée
• Simultanéité en rafale

Comprendre et visualiser la simultanéité

Lambda appelle votre fonction dans un environnement d'exécution sécurisé et isolé. Pour traiter une demande, Lambda doit d'abord initialiser un environnement d'exécution (la phase Init), avant de l'utiliser pour appeler votre fonction (la phase Invoke) :

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.

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'est-à-dire 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 :

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 :

Comportement de Lambda pour les demandes 1 à 10
Requête	Comportement de Lambda	Raisonnement
1	Alloue un nouvel environnement A	C'est la première demande ; aucune instance d'environnement d'exécution 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 :

En figeant l'animation précédente à six points distincts dans le temps, nous obtenons le diagramme suivant :

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 3 environnements actifs servant 3 demandes simultanées. Le nombre maximum de demandes simultanées dans cette simulation se produit au moment t4, lorsqu'il y a 6 environnements actifs servant 6 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é

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 1 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 2 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, 20 ms pour s'exécuter. Pendant les pics de charge, vous observez 5 000 demandes asynchrones 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,020 seconde. En utilisant la formule de simultanéité, vous pouvez entrer les chiffres pour obtenir une simultanéité de 100 :

Concurrency = (5,000 requests/second) * (0.020 seconds/request) = 100

Autrement dit, une durée moyenne de fonction de 20 ms signifie que votre fonction peut traiter 50 demandes par seconde. Pour traiter la charge de travail de 5 000 demandes par seconde, vous avez besoin de 100 instances d'environnement d'exécution. La simultanéité est donc de 100 :

Concurrency = (5,000 requests/second) / (50 requests/second) = 100

Simultanéité réservée et simultanéité provisionnée

Par défaut, votre compte dispose d'une limite de simultanéité de 1 000 pour toutes les fonctions d'une région. Vos fonctions partagent ce groupe de 1 000 simultanéités sur une base à la demande. Votre fonction est limitée (c'est-à-dire qu'elle commence à abandonner des 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 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.

• 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 est le nombre maximum 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 :

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'appels é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 comporte 5 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 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é. 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.

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 appels de votre fonction peuvent prendre plus de temps, car Lambda doit d'abord initialiser le nouvel environnement avant de pouvoir l'utiliser pour appeler votre fonction. Lorsque l'initialisation prend plus de temps que prévu, on parle de démarrage à froid. 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.

Lorsque vous utilisez la simultanéité provisionnée, Lambda recycle toujours les environnements d'exécution en arrière-plan. 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. Ce comportement diffère de la simultanéité réservée, où 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.

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 :

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 comporte 5 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 un appel 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'appels, mais qui connaît régulièrement des pics de trafic pendant les week-ends. 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 :

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 5 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 un appel 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'est-à-dire 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. 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 sur votre compte AWS.

Note

Si la simultanéité provisionnée sur les versions et les alias d'une fonction s'ajoute à la simultanéité réservée de la fonction, tous les appels 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 automatiser la mise à l'échelle de la simultanéité provisionnée en fonction d'une planification ou de l'utilisation des applications, consultez Gestion de la simultanéité provisionnée avec Application Auto Scaling.

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.

Sujet	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'est-à-dire 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 éliminée, 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.

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 dans le Guide de l'utilisateur Service Quotas.

• Au niveau des fonctions, vous pouvez réserver jusqu'à 900 unités de simultanéité dans toutes vos fonctions par défaut. 100 unités de simultanéité sont toujours réservées pour les 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.

Pour un premier pic de trafic, la simultanéité cumulative de votre fonction dans une même région peut atteindre un niveau initial de 500 à 3 000 :

Quotas de simultanéité en rafale

• 3 000 – USA Ouest (Oregon), USA Est (Virginie du Nord), Europe (Irlande)

• 1 000 – Asie-Pacifique (Tokyo), Europe (Francfurt), USA Est (Ohio)

• 500 – Autres régions.

Si la limite de simultanéité de votre compte est inférieure à la limite de simultanéité en rafale, Lambda limite votre simultanéité en rafale en fonction de la limite de simultanéité de votre compte. Par exemple, si la limite de votre compte est de 1 000, les fonctions situées dans l'est des USA Est (Virginie du Nord) bénéficient d'une simultanéité maximale de 1 000.

Après la rafale initiale, la simultanéité de vos fonctions peut augmenter de 500 instances supplémentaires par minute. Pour plus d'informations sur la simultanéité des rafales, consultez Simultanéité en rafale.

Estimation précise de la simultanéité requise

Si votre fonction sert actuellement du trafic, vous pouvez facilement visualiser ses métriques de simultanéité à l'aide des métriques CloudWatch. Plus précisément, la métrique ConcurrentExecutions vous montre le nombre d'appels simultanés pour chaque fonction de votre compte.

D'après le graphique, cette fonction répond à une moyenne de 5 à 10 demandes simultanées et 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 que des demandes soient abandonnées, vous pouvez utiliser 20 comme paramètre de simultanéité réservé.

Rappelez-vous que vous pouvez également calculer la simultanéité à l'aide de la formule suivante :

Concurrency = (average requests per second) * (average request duration in seconds)

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 de fonction Lambda.

Note

Si vous choisissez la simultanéité provisionnée, Lambda suggère d'inclure un tampon de 10 % en plus de la quantité de simultanéité dont votre fonction a généralement besoin. Un surdimensionnement de 10 % garantit que votre fonction peut toujours traiter les demandes entrantes en utilisant la simultanéité provisionnée, même si le trafic est légèrement supérieur à celui prévu. Par exemple, si votre fonction atteint habituellement un pic de 200 demandes simultanées, vous pourriez vouloir définir votre simultanéité provisionnée à 220 (200 demandes simultanées + 10 % = 220 simultanéités provisionnées).

Métriques de simultanéité

Vous pouvez utiliser les métriques suivantes pour surveiller la simultanéité de vos fonctions Lambda.

• ConcurrentExecutions – Le nombre d'appels simultanés actuellement actifs.

• UnreservedConcurrentExecutions – Le nombre d'appels simultanés actuellement actifs qui utilisent la simultanéité non réservée.

• ProvisionedConcurrentExecutions – Le nombre d'instances d'environnement d'exécution qui traitent des événements sur une simultanéité allouée. Pour chaque appel d’alias ou de version avec une simultanéité approvisionnée, Lambda émet le nombre actuel.

• ProvisionedConcurrencyInvocations – Le nombre de fois où Lambda appelle votre code de fonction en utilisant la simultanéité provisionnée.

• ProvisionedConcurrencySpilloverInvocations – Le nombre de fois où Lambda appelle votre code de fonction sur la simultanéité standard (réservée ou non) lorsque toute la simultanéité provisionnée est utilisée.

• ProvisionedConcurrencyUtilization – Pour une version ou un alias, valeur ProvisionedConcurrentExecutions divisée par la quantité totale de simultanéité approvisionnée allouée. Par exemple, .5 indique que 50 % de la simultanéité provisionnée allouée est en cours d'utilisation.