Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mise à l'échelle des instances gérées Lambda

Les instances gérées Lambda ne sont pas évolutives lorsque les appels arrivent et ne prennent pas en charge les démarrages à froid. Au lieu de cela, il évolue de manière asynchrone à l'aide de signaux de consommation de ressources. Les instances gérées évoluent actuellement en fonction de l'utilisation des ressources du processeur et de la saturation multisimultanéité.

Principales différences :

Si votre trafic fait plus que doubler en 5 minutes, vous risquez de rencontrer des problèmes à mesure que Lambda fait évoluer les instances et les environnements d'exécution pour répondre à la demande.

Le cycle de vie du dimensionnement

Les instances gérées Lambda utilisent une architecture distribuée pour gérer la mise à l'échelle :

Composantes :

Comment ça fonctionne :

Ajustement du comportement de dimensionnement

Vous pouvez personnaliser le comportement de dimensionnement des instances gérées à l'aide de cinq contrôles :

Contrôles au niveau des fonctions

1. Mémoire de fonctions et processeurs virtuels

Choisissez la taille de la mémoire et l'allocation du processeur virtuel pour votre fonction. La plus petite taille de fonction prise en charge est de 2 Go et 1 vCPU.

Considérations :

2. Simultanéité maximum

Définissez la simultanéité maximale par environnement d'exécution.

Comportement par défaut : Lambda choisit des valeurs par défaut judicieuses qui équilibrent la consommation de ressources et le débit, ce qui convient à une grande variété d'applications.

Directives d'ajustement :

Important : étant donné que les instances gérées Lambda sont destinées à des applications multisimultanées, les environnements d'exécution présentant une très faible simultanéité peuvent rencontrer des contraintes lors de la mise à l'échelle. Lorsque les appels arrivent dans un environnement d'exécution qui a atteint sa limite de simultanéité, Lambda achemine ces appels ailleurs et développe de nouveaux environnements d'exécution pour gérer la charge. Pour identifier la contrainte de ressources à l'origine des ralentissements, surveillez les métriques des raisons de l'étranglement (ConcurrencyThrottles, CPUThrottlesMemoryThrottles, etDiskThrottles) décrites dans. Types de métriques pour les fonctions Lambda

3. Environnements d'exécution par fonction

Définissez le nombre minimum et maximum d'environnements d'exécution pour votre fonction.

Comportement par défaut : le minimum par défaut est de 3 environnements d'exécution répartis dans les zones de disponibilité, sans maximum par défaut. Vous pouvez remplacer les deux valeurs une fois la fonction créée.

Directives d'ajustement :

Exemple :

aws lambda put-function-scaling-config \
  --function-name my-lmi-function \
  --qualifier '$LATEST.PUBLISHED' \
  --function-scaling-config MinExecutionEnvironments=5,MaxExecutionEnvironments=20 \
  --region us-east-1

Remarques importantes :

Contrôles au niveau des fournisseurs de capacité

4. Utilisation des ressources cible

Choisissez votre propre objectif en matière de consommation d'utilisation du processeur.

Comportement par défaut : Lambda conserve une marge de manœuvre suffisante pour que votre trafic double en 5 minutes sans ralentissement.

Options d'optimisation :

5. Sélection du type d'instance

Définissez les types d'instances autorisés ou exclus.

Comportement par défaut : Lambda choisit les types d'instances les mieux adaptés à votre charge de travail. Il est recommandé de laisser les instances gérées Lambda choisir les types d'instance, car la limitation du nombre de types d'instances possibles peut entraîner une baisse de la disponibilité.

Configuration personnalisée :

Mise à l’échelle planifiée

Utilisez Amazon EventBridge Scheduler pour ajuster les environnements d'exécution minimum et maximum de votre fonction selon un calendrier récurrent ou ponctuel. Cela est utile pour des modèles de trafic prévisibles, tels que la mise à l'échelle avant les heures de pointe et la réduction pendant les heures creuses.

Configuration du planificateur :

Exemple 1 : évolutivité pour gérer les pics de trafic planifiés

Créez deux horaires pour augmenter l'échelle avant les heures de pointe et la réduire par la suite. Chaque calendrier cible l'PutFunctionScalingConfigAPI avec des MaxExecutionEnvironments valeurs MinExecutionEnvironments et mises à jour.

Passez à la vitesse supérieure à 8 h 00 UTC (min = 100, max = 1000) :

aws scheduler create-schedule \
  --name "ScaleUpLambdaManagedInstances" \
  --schedule-expression "cron(0 8 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 100, \"MaxExecutionEnvironments\": 1000}}"
  }'

Réduisez la taille à 18 h 00 UTC (min = 5, max = 20) :

aws scheduler create-schedule \
  --name "ScaleDownLambdaManagedInstances" \
  --schedule-expression "cron(0 18 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 5, \"MaxExecutionEnvironments\": 20}}"
  }'

Exemple 2 : désactiver en dehors des heures de pointe et réactiver

Le réglage des deux MinExecutionEnvironments et MaxExecutionEnvironments sur 0 désactive la version de la fonction sans la supprimer. Une fonction désactivée n'est pas automatiquement redimensionnée en fonction du trafic. Vous devez le réactiver explicitement en définissant des valeurs non nulles par le biais d'une autre action planifiée.

Désactiver à 22 h UTC (min = 0, max = 0) :

aws scheduler create-schedule \
  --name "DeactivateLambdaManagedInstances" \
  --schedule-expression "cron(0 22 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 0, \"MaxExecutionEnvironments\": 0}}"
  }'

Réactivez à 7 h 00 UTC (min = 10, max = 20) :

aws scheduler create-schedule \
  --name "ReactivateLambdaManagedInstances" \
  --schedule-expression "cron(0 7 * * ? *)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::<account-id>:role/eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"my-lmi-function\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 10, \"MaxExecutionEnvironments\": 20}}"
  }'

Directives d'ajustement :

Étapes suivantes