Configuration de la simultanéité provisionnée - AWS Lambda
Configuration de la simultanéité provisionnéeEstimation précise de la simultanéité provisionnée requiseOptimisation de la latence avec la simultanéité provisionnéeGestion de la simultanéité provisionnée avec Application Auto Scaling.

Configuration de la simultanéité provisionnée

Dans Lambda, la simultanéité 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 : la simultanéité réservée est le nombre maximum d'instances simultanées que vous voulez allouer à votre fonction. Lorsqu'une fonction dispose de la simultanéité réservée, aucune autre fonction ne peut utiliser cette simultanéité. Il n'y a pas de frais pour la configuration de la simultanéité réservée pour une fonction.

  • 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. Ces environnements d'exécution sont prêts à répondre immédiatement aux demandes de fonctions entrantes. La configuration de la simultanéité provisionnée entraîne des frais 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. Pour plus d'informations sur la configuration de la simultanéité réservée, consultez Configuration de la simultanéité réservée.

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 (Fonctions) de la console Lambda.

  2. Sélectionnez la fonction pour laquelle vous souhaitez allouer de la simultanéité provisionnée.

  3. Sélectionnez Configuration, puis Concurrency (Simultanéité).

  4. Sous Provisioned concurrency configurations (Configurations de simultanéité provisionnée), sélectionnez Add configuration (Ajouter une configuration).

  5. Choisissez Reserve concurrency (Réserver la simultanéité). Saisissez la quantité de simultanéité à réserver pour la fonction.

  6. 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 $LATEST version d'une fonction.

    De plus, si vous utilisez une source d'événement avec votre fonction Lambda, assurez-vous que la source d'événement pointe vers le bon alias ou la bonne version. Sinon, votre fonction n'utilisera pas les environnements de simultanéité provisionnés.

  7. Saisissez un nombre sous Simultanéité provisionnée. Lambda fournit une estimation des coûts mensuels.

  8. 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.

Une erreur se produit si vous essayez d'allouer une simultanéité provisionnée trop importante.

La configuration de la simultanéité provisionnée pour une fonction peut avoir 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, même si function-a n'utilisent pas les 100 unités de simultanéité provisionnées.

Vous pouvez allouer à la fois de la simultanéité réservée et de la simultanéité provisionnée pour la même fonction. Dans ce cas, la quantité de simultanéité provisionnée ne peut pas dépasser la quantité de la simultanéité réservée.

Cette limite s'applique également aux versions de fonctions. La quantité maximale de simultanéité provisionnée 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.

Par exemple, pour configurer la simultanéité provisionnée avec le AWS Command Line Interface (CLI), utilisez la commande put-provisioned-function-concurrency. 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-function-concurrency --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

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'invocations simultanées pour chaque fonction de votre compte.

Graphique montrant la simultanéité pour une fonction au fil du temps.

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 avez besoin d'une réponse à faible latence à chaque invocation , utilisez un nombre supérieur ou égal à 20 comme paramètre de simultanéité provisionnée.

Par ailleurs, 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)

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

Lorsque vous travaillez avec une 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. 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 + 10 % = 220 simultanéités provisionnées).

Optimisation de la latence avec la simultanéité provisionnée

La façon dont vous structurez votre code de fonction pour optimiser la latence peut varier selon que vous optez pour une simultanéité provisionnée ou pour des environnements à la demande. Pour les fonctions exécutées en 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 judicieux de placer un maximum d'initialisation en dehors du gestionnaire de la fonction principale, car cela n'aura pas d'impact sur la latence lors des invocations à la fonction. En revanche, si vous initialisez des bibliothèques ou instanciez des clients dans le code de votre gestionnaire principal, votre fonction doit l'exécuter chaque fois que vous l'invoquez, que vous utilisiez ou non la simultanéité provisionnée.

Si vous utilisez des instances à la demande, Lambda peut avoir à exécuter à nouveau votre code d'initialisation chaque fois que votre fonction reçoit une demande (démarrage à froid). Selon les besoins de votre fonction, vous pouvez choisir de différer l'initialisation d'une capacité spécifique jusqu'à ce que la fonction ait besoin de cette capacité. 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, l'auteur de la fonction a choisi de l'initialiser dans l'instruction if. Ainsi, Lambda n'exécute ce code que si some_condition est satisfaite. Si l'auteur initialise CLIENT_A en dehors du gestionnaire principal, Lambda exécute ce code à chaque démarrage à froid, ce qui augmente la latence globale.

Il est possible que votre fonction utilise la totalité de sa simultanéité provisionnée. Pour gérer le trafic excédentaire, votre fonction doit utiliser des instances à la demande. Pour vous aider à 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 peut avoir deux valeurs possibles : provisioned-concurrency ou on-demand. La valeur d'AWS_LAMBDA_INITIALIZATION_TYPE est immuable et ne change pas au cours de la durée de vie de l'environnement d'exécution.

Si vous utilisez les exécutions .NET 6 ou .NET 7, 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. 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.

Pour les environnements de simultanéité provisionnée, le code d'initialisation de votre fonction s'exécute pendant l'allocation, et toutes les quelques heures lorsque Lambda recycle les instances actives de votre environnement. Vous pouvez consulter le temps d'initialisation dans les journaux et les traces après le traitement d'une demande par une instance d'environnement. Toutefois, 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.

Pour obtenir des conseils supplémentaires sur l'optimisation des fonctions à l'aide de la concurrence provisionnée, consultez Environnements d'exécution Lambda dans Serverless Land.

Gestion de la simultanéité provisionnée avec Application Auto Scaling.

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.

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 dans le Guide de l'utilisateur Application Auto Scaling, et 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

  2. 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 %.

    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.

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.

Mise à l'échelle automatique de la simultanéité approvisionnée avec suivi de la cible Application Auto Scaling.
Légende

  • Instances de la fonction

  • Demandes ouvertes

  • Simultanéité provisionnée

  • 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 dont les modèles de trafic se présentent sous la forme de rafales 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 peut dépasser la simultanéité allouée et provisionnée pendant la rafale, mais la charge de rafale doit être maintenue pendant au moins trois minutes pour qu'Application Auto Scaling provisionne 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 de mise à l'échelle automatique.

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.