Configuration de la simultanéité provisionnée

Dans Lambda, la simultanéité est le nombre de demandes que votre fonction peut traiter 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 garantit le nombre maximum d’instances simultanées pour la 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é approvisionnée – La simultanéité approvisionnée initialise un nombre demandé d’environnements d’exécution de façon à ce que ceux-ci soient prêts à répondre immédiatement aux appels de votre fonction. Notez que 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. Si vous souhaitez configurer la simultanéité réservée, consultez Gestion de la simultanéité réservée Lambda.

Si Lambda alloue une instance de votre fonction, le runtime charge le code de votre fonction et exécute le code d'initialisation que vous définissez en dehors du gestionnaire. Si votre code et les dépendances sont volumineux, ou si vous créez des clients SDK pendant l'initialisation, ce processus peut prendre un certain temps. Lorsque la fonction n'a pas été utilisée depuis un certain temps, qu'elle doit être mise à l’échelle ou lorsque vous mettez à jour une fonction, Lambda crée de nouveaux environnements d'exécution. Ainsi, la partie des demandes qui sont servies par les nouvelles instances a une latence plus élevée que le reste, ce que l'on appelle un démarrage à froid.

En allouant la simultanéité provisionnée avant une augmentation des appels, vous pouvez vous assurer que toutes les demandes sont servies par des instances initialisées avec une faible latence. Les fonctions Lambda configurées avec une simultanéité provisionnée s'exécutent avec une latence de start-up cohérente, ce qui les rend idéales pour créer des backends mobiles ou Web interactifs, des microservices sensibles à la latence et des API appelées de manière synchrone.

Note

La simultanéité provisionnée compte dans les quotas de simultanéité réservée et régionales d'une fonction. 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.

Lambda s'intègre également à Application Auto Scaling, vous permettant de gérer la simultanéité provisionnée selon une planification ou en fonction de son utilisation.

Différences entre Lambda SnapStart et la simultanéité provisionnée

Lambda SnapStart est une optimisation des performances qui vous aide à améliorer jusqu'à 10 fois les performances de démarrage des applications sensibles à la latence, sans frais supplémentaires. La simultanéité provisionnée permet aux fonctions d'être initialisées et prêtes à répondre en un nombre de millisecondes à deux chiffres. La configuration de la simultanéité provisionnée entraîne des frais sur votre Compte AWS. Utilisez la simultanéité provisionnée si votre application a des exigences strictes en matière de latence de démarrage à froid. Vous ne pouvez pas utiliser à la fois SnapStart et la simultanéité provisionnée sur la même version de fonction.

Configuration de la simultanéité provisionnée

Pour gérer les paramètres de simultanéité approvisionnée pour une version ou un alias, utilisez la console Lambda. Vous pouvez configurer la simultanéité provisionnée sur une version d'une fonction ou sur un alias.

Chaque version d'une fonction ne peut avoir qu'une seule configuration de simultanéité provisionnée. Cela peut être directement sur la version elle-même ou sur un alias qui pointe vers la version. Deux alias ne peuvent pas allouer la simultanéité provisionnée pour la même version.

Si vous changez la version vers laquelle un alias pointe, Lambda désalloue la simultanéité provisionnée de l'ancienne version et l'alloue à la nouvelle version. Vous pouvez ajouter une configuration de routage à un alias doté d'une simultanéité provisionnée. Pour plus d'informations, consultez Alias des fonctions Lambda. Notez que vous ne pouvez pas gérer les paramètres de simultanéité provisionnée sur l'alias lorsque la configuration de routage est en place.

Note

La simultanéité allouée n'est pas prise en charge sur la version non publiée de la fonction ($LATEST). Assurez-vous que l’application du client ne pointe pas vers $LATEST avant de configurer la simultanéité provisionnée.

Allouer une simultanéité provisionnée à un alias ou à une version.

1. Ouvrez la page Functions (Fonctions) de la console Lambda.

2. Choisissez une fonction.

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 un alias ou une version.

6. Entrez le montant de la simultanéité provisionnée à allouer.

7. Choisissez Enregistrer.

Vous pouvez également configurer une simultanéité provisionnée à l'aide de l'API Lambda pour les opérations suivantes :

• PutProvisionedConcurrencyConfig

• GetProvisionedConcurrencyConfig

• ListProvisionedConcurrencyConfigs

• DeleteProvisionedConcurrencyConfig

Pour allouer de la simultanéité provisionnée pour une fonction, utilisez put-provisioned-concurrency-config. La commande suivante alloue une simultanéité de 100 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 la sortie suivante :

{
    "Requested ProvisionedConcurrentExecutions": 100,
    "Allocated ProvisionedConcurrentExecutions": 0,
    "Status": "IN_PROGRESS",
    "LastModified": "2019-11-21T19:32:12+0000"
}

Pour afficher les quotas de simultanéité de votre compte dans une région, utilisez get-account-settings.

aws lambda get-account-settings

Vous devriez voir la sortie suivante :

{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 174913095,
        "FunctionCount": 52
    }
}

Vous pouvez gérer la simultanéité provisionnée pour tous les alias et toutes les versions à partir de la page de configuration de la fonction. La liste des configurations de simultanéité provisionnée indique la progression de l'allocation de chaque configuration. Les paramètres de simultanéité provisionnée sont également disponibles sur la page de configuration de chaque version et de chaque alias.

Lambda émet les métriques suivantes pour la simultanéité approvisionnée :

Métriques de simultanéité provisionnée

• ProvisionedConcurrentExecutions : nombre d'instances de fonction 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 : nombre de fois que votre code de fonction est exécuté sur une simultanéité allouée.

• ProvisionedConcurrencySpilloverInvocations : nombre de fois que votre code de fonction est exécuté sur la simultanéité standard, lorsque la totalité de la simultanéité alloué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.

Pour en savoir plus, consultez Utilisation des métriques de fonction Lambda.

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

La simultanéité approvisionné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. De la même manière que les fonctions sont mises à l'échelle en fonction de la charge, jusqu'à 3 000 instances de la fonction peuvent être initialisées en même temps, selon la région. Après le lancement initial en mode rafale, les instances sont allouées à un taux constant de 500 par minute jusqu'à ce que la demande soit satisfaite. Lorsque vous demandez la simultanéité provisionnée pour plusieurs fonctions ou versions d'une fonction dans la même région, des quotas de mise à l'échelle s'appliquent à toutes les demandes.

Légende

• Instances de la fonction

• Demandes ouvertes

• Simultanéité provisionnée

• Simultanéité standard

Pour optimiser la latence, vous pouvez personnaliser le comportement d'initialisation des fonctions qui utilisent la simultanéité provisionnée. Vous pouvez exécuter le code d'initialisation pour les instances de simultanéité provisionnée sans affecter la latence, car le code d'initialisation s'exécute au moment de l'allocation. Toutefois, le code d'initialisation d'une instance à la demande affecte directement la latence du premier appel. Pour une instance à la demande, vous pouvez choisir de reporter l'initialisation d'une fonctionnalité spécifique jusqu'à ce que la fonction ait besoin de cette fonctionnalité.

Pour déterminer le type d'initialisation, vérifiez la valeur de AWS_LAMBDA_INITIALIZATION_TYPE. Lambda définit cette variable d'environnement sur provisioned-concurrency ou on-demand. La valeur de 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 le runtime .NET 3.1, vous pouvez configurer la variable d'environnement AWS_LAMBDA_DOTNET_PREJIT pour améliorer la latence des fonctions qui utilisent la 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, le premier appel d'une fonction Lambda peut prendre plus de temps que les appels suivants. Lorsque vous définissez AWS_LAMBDA_DOTNET_PREJIT surProvisionedConcurrency, Lambda effectue une compilation JIT à l'avance pour les dépendances système communes. Lambda effectue cette optimisation d'initialisation uniquement pour les instances de simultanéité approvisionnée, ce qui a pour effet d'accélérer les performances pour le premier appel. Si vous définissez la variable d'environnement sur Always, Lambda effectue une compilation JIT à l'avance pour chaque initialisation. Si vous définissez la variable d'environnement sur Never, la compilation JIT à l'avance est désactivée. La valeur par défaut pour AWS_LAMBDA_DOTNET_PREJIT est ProvisionedConcurrency.

Pour les instances de simultanéité provisionnée, le code d'initialisation de votre fonction s'exécute pendant l'allocation et à intervalle de quelques heures, car les instances de votre fonction qui s'exécutent sont recyclées. Vous pouvez consulter le temps d'initialisation dans les journaux et les traces après le traitement d'une demande par une instance. Toutefois, l'initialisation est facturée même si l'instance ne traite pas une 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'appel. Pour de plus amples informations, veuillez consulter Tarification AWS Lambda.

Pour plus d'informations sur l'optimisation des fonctions à l'aide de la simultanéité provisionnée, consultez le Guide de l'opérateur Lambda.

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

Application Auto Scaling vous permet de gérer la simultanéité provisionnée selon une planification ou en fonction de l'utilisation. Utilisez une stratégie de suivi des objectifs d’échelonnement si vous souhaitez que votre fonction maintienne un pourcentage d'utilisation spécifié et une mise à l'échelle planifiée pour augmenter la simultanéité provisionnée en prévision du trafic de pointe.

Suivi de la cible

Avec le suivi de cible, Application Auto Scaling crée et gère les alarmes CloudWatch qui déclenchent une stratégie de mise à l'échelle et calcule l'ajustement de la mise à l'échelle en fonction d'une métrique et d'une valeur cible que vous définissez. C'est idéal pour les applications qui n'ont pas de temps planifié de trafic accru, mais qui présentent certains schémas de trafic.

Pour augmenter automatiquement la simultanéité provisionnée en fonction des besoins, utilisez le RegisterScalableTarget et les PutScalingPolicy opérations de l'API Application Auto Scaling pour enregistrer une cible et créer une stratégie de mise à l'échelle.

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 voir la sortie suivante :

   {
       "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. Quand le nombre de demandes ouvertes augmente, Application Auto Scaling augmente la simultanéité approvisionnée par échelons jusqu'à ce qu'elle atteigne le maximum configuré. La fonction maintient son échelle ajustée à la simultanéité standard jusqu'à ce que l'utilisation commence à diminuer. Lorsque l'utilisation est constamment faible, Application Auto Scaling réduit la simultanéité approvisionnée par échelons périodiques plus petits.

Légende

• Instances de la fonction

• Demandes ouvertes

• Simultanéité provisionnée

• Simultanéité standard

Ces deux alarmes utilisent la statistique moyenne par défaut. Les fonctions qui présentent des schémas de trafic avec des rafales rapides peuvent ne pas déclencher la mise à l'échelle de la simultanéité provisionnée. Par exemple, si la fonction Lambda s'exécute rapidement (20 à 100 ms) et que votre schéma de trafic se déroule avec des rafales rapides, les demandes entrantes peuvent dépasser la simultanéité provisionnée pendant la rafale, mais si la rafale ne dure pas 3 minutes, la scalabilité automatique ne se déclenchera pas. De plus, si CloudWatch n'obtient pas trois points de données qui atteignent la moyenne cible, la stratégie de scalabilité automatique ne se déclenchera pas.

Pour plus d’informations sur l'utilisation des stratégies de suivi des objectifs d’échelonnement, consultez Stratégies de suivi des objectifs d’échelonnement pour Auto Scaling.

Mise à l'échelle planifiée

La mise à l'échelle basée sur une planification vous permet de 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 Planification de la simultanéité provisionnée Lambda AWS pour une utilisation de pointe récurrente.