Comprendre le dimensionnement des fonctions d'événement Lambda

La simultanéité est le nombre de demandes en cours de vol traitées simultanément par votre fonction AWS Lambda événementielle. Pour chaque demande simultanée, Lambda fournit une instance distincte de votre environnement d’exécution. Au fur et à mesure que vos fonctions événementielles reçoivent de plus en plus de demandes, Lambda gère automatiquement le dimensionnement 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'événement d'un. Région AWS Pour répondre aux besoins spécifiques de votre compte, vous pouvez demander une augmentation du quota et configurer des contrôles de simultanéité au niveau des fonctions afin que vos fonctions d'événements critiques ne soient pas limitées.

Cette rubrique explique les concepts de simultanéité et le dimensionnement des fonctions d'événement 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é pour une fonction événementielle

• Présentation de la simultanéité réservée et de la simultanéité allouée

• Présentation de la simultanéité et des requêtes par seconde

• Quotas de simultanéité

• Configuration de la simultanéité réservée pour une fonction événementielle

• Configuration de la simultanéité provisionnée pour une fonction événementielle

• Comportement de dimensionnement des fonctions d'événement

• Surveillance de la simultanéité

Comprendre et visualiser la simultanéité

Lambda invoque votre fonction d'événement dans un environnement d'exécution sécurisé et isolé. Pour traiter une demande, Lambda doit d'abord initialiser un environnement d'exécution (phase d'initialisation), avant de l'utiliser pour appeler votre fonction d'événement (phase d'appel) :

Note

Les durées réelles d'initialisation et d'invocation peuvent varier en fonction de nombreux facteurs, tels que le temps d'exécution que vous choisissez et le code de la fonction d'événement 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 d'événement reçoit sa toute première requête (représentée par le cercle jaune avec étiquette1), Lambda crée un nouvel environnement d'exécution et exécute le code en dehors de votre gestionnaire principal pendant la phase d'initialisation. Lambda exécute ensuite le code du gestionnaire principal de votre fonction d'événement pendant la phase d'Invoke. Pendant tout ce processus, cet environnement d’exécution est occupé et ne peut pas traiter d’autres demandes.

Lorsque Lambda a terminé de traiter la première demande, cet environnement d'exécution peut alors traiter des demandes supplémentaires pour la même fonction d'événement. 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.-à-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 gérer toutes les demandes entrantes. Lorsque votre fonction événementielle 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, examinons ce qui se passe lorsque votre fonction événementielle reçoit 10 requêtes :

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 d'événement reçoit de plus en plus de 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 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 d'événement 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 d'événement, Lambda fournit davantage d'instances d'environnement d'exécution pour répondre à la demande de demande.

Calcul de la simultanéité pour une fonction événementielle

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 cours de vol traitées simultanément par votre fonction d'événement. Un moyen rapide et pratique de mesurer la simultanéité d'une fonction d'événement Lambda consiste à utiliser la formule suivante :

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

La simultanéité diffère des demandes par seconde. Supposons, par exemple, que votre fonction événementielle 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 événementielle reçoit le double du nombre 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 disposiez d'une fonction d'événement dont l'exécution prend en moyenne 200 ms. Pendant les pics de charge, vous observez 5 000 demandes par seconde. Quelle est la simultanéité de votre fonction événementielle en période de pointe ?

Réponse

La durée moyenne de la fonction d'événement est de 200 ms, soit 0,2 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

Par ailleurs, une durée moyenne d'une fonction d'événement de 200 ms signifie que votre fonction d'événement 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 1 000 exécutions simultanées pour toutes les fonctions événementielles d'une région. Vos fonctions événementielles partagent ce pool de 1 000 simultanés à la demande. Vos fonctions événementielles 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 événementielles peuvent être plus critiques que d'autres. Par conséquent, vous souhaiterez peut-être configurer les paramètres de simultanéité pour garantir que les fonctions événementielles 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 le nombre maximum et minimum d'instances simultanées afin de réserver une partie de la simultanéité de votre compte à une fonction événementielle. Cela est utile si vous ne souhaitez pas que d'autres fonctions événementielles utilisent toutes les fonctionnalités simultanées non réservées disponibles. Lorsqu'une fonction événementielle a réservé la simultanéité, aucune autre fonction événementielle 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 d'événement. Ceci est utile pour réduire les latences de démarrage à froid.

Simultanéité réservée

Si vous souhaitez garantir qu'un certain niveau de simultanéité est disponible pour votre fonction événementielle à tout moment, utilisez la simultanéité réservée.

La simultanéité réservée définit le nombre maximum et minimum d'instances simultanées que vous souhaitez allouer à votre fonction événementielle. Lorsque vous dédiez une simultanéité réservée à une fonction d'événement, aucune autre fonction d'événement 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 pool de simultanéité disponible pour les autres fonctions événementielles. Les fonctions événementielles qui n'ont pas de simultanéité réservée partagent le pool 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. La configuration de la simultanéité réservée pour une fonction événementielle est gratuite.

Pour mieux comprendre la simultanéité réservée, considérez le diagramme suivant :

Dans ce schéma, la limite de simultanéité de votre compte pour toutes les fonctions événementielles de cette région est fixée à la limite par défaut de 1 000. Supposons que vous disposiez de deux fonctions d'événement critiques qui s'attendent régulièrement à recevoir des volumes d'invocation élevés. function-blue function-orange 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 événementielles de votre compte doivent partager les 200 unités de simultanéité non réservées restantes.

Le diagramme présente cinq points d’intérêt :

• À t1, function-orange et function-blue commencent à recevoir des demandes. Chaque fonction événementielle commence à utiliser la portion allouée d'unités de simultanéité réservées.

• À t2, function-orange et function-blue reçoivent de plus en plus de demandes. Dans le même temps, vous déployez d'autres fonctions d'événement Lambda, qui commencent à recevoir des demandes. Vous n'attribuez pas de simultanéité réservée à ces autres fonctions événementielles. 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 qu'il function-orange y a un ralentissement et que Lambda peut abandonner les demandes.

• À t4, function-orange commence à recevoir moins de demandes et n’est plus limitée. Cependant, vos autres fonctions événementielles connaissent un pic de trafic et commencent à s'accélérer. Bien que la simultanéité ne soit pas utilisée ailleurs dans votre compte, ces autres fonctions événementielles ne peuvent pas y accéder. La ligne rouge indique que vos autres fonctions événementielles sont soumises à un ralentissement.

• Àt5, les autres fonctions événementielles 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 événementielle peut évoluer indépendamment des autres fonctions événementielles de votre compte. Toutes les fonctions événementielles de votre compte dans la même région qui ne proposent pas de simultanéité réservée partagent le pool de fonctionnalités simultanées non réservées. Sans simultanéité réservée, les autres fonctions événementielles peuvent potentiellement utiliser toute la simultanéité disponible. Cela empêche les fonctions événementielles critiques de s'étendre si nécessaire.

• Votre fonction événementielle ne peut pas évoluer de manière incontrôlable. La simultanéité réservée limite la simultanéité maximale et minimale de votre fonction événementielle. Cela signifie que votre fonction événementielle ne peut pas utiliser la simultanéité réservée aux autres fonctions événementielles, ni la simultanéité provenant du pool non réservé. En outre, la simultanéité réservée agit à la fois comme une limite inférieure et une limite supérieure : elle réserve la capacité spécifiée exclusivement à votre fonction événementielle tout en l'empêchant de dépasser cette limite. Vous pouvez réserver la simultanéité pour empêcher votre fonction événementielle d'utiliser toute la simultanéité disponible sur votre compte ou de surcharger les ressources en aval.

• Il se peut que vous ne puissiez pas utiliser toutes les fonctionnalités simultanées disponibles de votre compte. La réservation de simultanéité est prise en compte dans le calcul de la limite de simultanéité de votre compte, mais cela signifie également que les autres fonctions événementielles ne peuvent pas utiliser cette partie de la simultanéité réservée. Si votre fonction événementielle n'utilise pas toute la simultanéité que vous lui réservez, vous gaspillez cette simultanéité. Ce n'est pas un problème, sauf si d'autres fonctions événementielles de votre compte peuvent bénéficier de cette simultanéité inutile.

Pour savoir comment gérer les paramètres de simultanéité réservés pour vos fonctions événementielles, consultezConfiguration de la simultanéité réservée pour une fonction événementielle.

Simultanéité allouée

Vous utilisez la simultanéité réservée pour définir le nombre maximum d'environnements d'exécution réservés à une fonction d'événement Lambda. Toutefois, aucun de ces environnements n’est préinitialisé. Par conséquent, vos appels de fonction d'événement peuvent prendre plus de temps car Lambda doit d'abord initialiser le nouvel environnement avant de pouvoir l'utiliser pour appeler votre fonction d'événement. Lorsque Lambda doit initialiser un nouvel environnement pour effectuer un appel, cela s'appelle un 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 souhaitez allouer à votre fonction événementielle. Si vous définissez la simultanéité provisionnée pour une fonction d'événement, Lambda initialise ce nombre d'environnements d'exécution afin qu'ils soient prêts à répondre immédiatement aux demandes de fonction d'événement.

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 Event Function. Pour plus d'informations sur les SnapStart fonctionnalités, les limitations et les régions prises en charge, consultezAméliorer les performances de démarrage avec Lambda SnapStart.

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. 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é de votre fonction d'événement. 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, lors de l'utilisation de la simultanéité réservée, Lambda peut complètement mettre fin à un environnement après une période d'inactivité. Le schéma suivant illustre cela en comparant le cycle de vie d'un environnement d'exécution unique lorsque vous configurez votre fonction d'événement 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 événementielles de votre compte, y comprisfunction-orange, peuvent utiliser les 600 unités de simultanéité non réservées restantes.

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 d'événement peut rencontrer 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.

• Chezt4, les fonctions événementielles de votre compte connaissent une augmentation du trafic. Cette rafale peut provenir de votre compte function-orange ou de toute autre fonction événementielle. Lambda utilise la simultanéité sans réserve pour traiter ces demandes.

• Àt5, les fonctions événementielles de votre compte atteignent la limite maximale de 1 000 simultanées et l'expérience est limitée.

L’exemple précédent ne prenait en compte que la simultanéité provisionnée. Dans la pratique, vous pouvez définir à la fois la simultanéité provisionnée et la simultanéité réservée sur une fonction événementielle. Vous pourriez le faire si vous disposiez d'une fonction événementielle qui gère un nombre constant d'appels en semaine, mais qui enregistre 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 :

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.

• Att2, function-orange utilise toute sa simultanéité provisionnée. function-orangepeut continuer à traiter les demandes en utilisant la simultanéité réservée, mais ces demandes peuvent être confrontées à 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. En d'autres termes, l'allocation d'une simultanéité réservée et provisionnée peut avoir un impact sur le pool de simultanéité disponible pour les autres fonctions événementielles. La configuration de la simultanéité provisionnée entraîne des frais pour votre. Compte AWS

Note

Si le niveau de simultanéité provisionné sur les versions et les alias d'une fonction événementielle s'ajoute à la simultanéité réservée de la fonction événementielle, toutes les invocations sont exécutées sur la base de la simultanéité provisionnée. Cette configuration a également pour effet de limiter la version non publiée de la fonction d'événement ($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 événementielle.

Pour gérer les paramètres de simultanéité configurés pour vos fonctions événementielles, consultez. Configuration de la simultanéité provisionnée pour une fonction événementielle 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.

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 événementielle, 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é pour les fonctions événementielles.

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 maximum d'instances d'environnement d'exécution pour votre fonction événementielle.	Définissez le nombre d'instances d'environnement d'exécution préprovisionnées pour votre fonction événementielle.
Comportement de provisionnement	Lambda provisionne de nouvelles instances sur une base à la demande.	Lambda préapprovisionne les instances (c'est-à-dire avant que votre fonction d'événement 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 d'événement 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 : Event Function utilise la simultanéité non réservée lorsque la limite de simultanéité allouée est atteinte. Si la simultanéité réservée est définie : la fonction d'événement est limitée lorsque la limite de simultanéité réservée est atteinte.
Comportement par défaut si non défini	Event Function utilise la simultanéité non réservée disponible sur votre compte.	Lambda ne pré-provisionne pas d’instances. En revanche, si la simultanéité réservée n'est pas définie : Event Function utilise la simultanéité non réservée disponible sur votre compte. Si la simultanéité réservée est définie : Event Function 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. Il s'agit d'une distinction particulièrement importante à faire lorsque vous travaillez avec des fonctions d'événement dont la durée moyenne des requêtes est inférieure à 100 ms.

Pour toutes les fonctions événementielles de votre compte, Lambda applique une limite de demandes par seconde égale à 10 fois le nombre de demandes simultanées de votre compte. Par exemple, étant donné que la limite de simultanéité par défaut est de 1 000, les fonctions d'événement de votre compte peuvent traiter un maximum de 10 000 demandes par seconde.

Prenons l'exemple d'une fonction d'événement dont la durée de requête moyenne est de 50 ms. À 20 000 requêtes par seconde, voici la simultanéité de cette fonction d'événement :

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 demandes par seconde, votre fonction événementielle ne peut traiter que 10 000 demandes par seconde sur un total de 20 000 demandes. Cette fonction événementielle subit un ralentissement.

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 événementielles. 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 simultanéité (fonctions d'événement inférieures à 100 ms)

Supposons que vous disposiez d'une fonction d'événement dont l'exécution prend en moyenne 20 ms. Pendant les pics de charge, vous observez 30 000 requêtes par seconde. Quelle est la simultanéité de votre fonction événementielle en période de pointe ?

Réponse

La durée moyenne de la fonction d'événement 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 d'événement synchrones à la demande, aux fonctions d'événement qui utilisent la simultanéité provisionnée et au comportement de dimensionnement de la simultanéité. 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 événementielle utilisant la simultanéité à la demande peut connaître une augmentation rapide de 500 demandes toutes les 10 secondes, ou de 5 000 demandes par seconde toutes les 10 secondes, selon la première éventualité.

• Supposons que vous disposiez d'une fonction événementielle dotée d'une allocation de simultanéité provisionnée de 10. Cette fonction événementielle se transforme en simultanéité à la demande après 10 demandes simultanées ou 100 demandes par seconde, selon la première éventualité.

Quotas de simultanéité

Lambda définit des quotas pour le niveau total de simultanéité que vous pouvez utiliser pour toutes les fonctions événementielles d'une région. Ces quotas existent à deux niveaux :

• Au niveau du compte, vos fonctions événementielles 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é pour toutes vos fonctions événementielles par défaut. Quelle que soit la limite totale de simultanéité de votre compte, Lambda réserve toujours 100 unités de simultanéité pour vos fonctions événementielles 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 d'événement utilisant la simultanéité à la demande, aux fonctions d'événement utilisant la simultanéité prévue et au comportement de dimensionnement de la simultanéité. Pour plus d’informations, consultez Présentation de la simultanéité et des requêtes par seconde.

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
    }
}

ConcurrentExecutionsest votre quota de simultanéité total au niveau du compte. UnreservedConcurrentExecutionsest le montant de simultanéité réservé que vous pouvez toujours allouer à vos fonctions événementielles.

Au fur et à mesure que votre fonction événementielle reçoit de nouvelles demandes, Lambda augmente automatiquement le nombre d'environnements d'exécution pour traiter ces demandes jusqu'à ce que votre compte atteigne son quota 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 simultanée est le taux maximal auquel les fonctions événementielles de votre compte peuvent évoluer en réponse à l'augmentation des demandes. (C’est-à-dire la rapidité avec laquelle Lambda peut créer de nouveaux environnements d’exécution.) Le taux d'échelonnement de la simultanéité diffère de la limite de simultanéité au niveau du compte, qui est le montant total de simultanéité disponible pour vos fonctions événementielles.

Dans chaque fonction événementielle 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 événementielle de votre compte peut évoluer indépendamment des autres fonctions événementielles.

Pour plus d’informations sur les comportements de mise à l’échelle, consultez Comportement de dimensionnement des fonctions d'événement.