Déploiement et mise à jour des fonctions des instances gérées Lambda

Lorsque vous mettez à jour une fonction Lambda Managed Instances, Lambda provisionne des environnements d'exécution pour la nouvelle version de la fonction sur vos instances gérées avant de transférer le trafic vers celle-ci. Vous pouvez contrôler la vitesse et la sécurité du déploiement en sélectionnant une stratégie de déploiement. Cette rubrique décrit les stratégies de déploiement disponibles pour les fonctions Lambda Managed Instances et explique comment les définir avec l'infrastructure en tant que code (IaC).

Note

Avant de déployer une fonction, vous devez disposer d'un fournisseur de capacité. Pour plus d'informations, voir fournisseurs de capacité pour les instances gérées Lambda.

Stratégies de déploiement

Les instances gérées Lambda prennent en charge les stratégies suivantes pour publier une nouvelle version de fonction. Choisissez la stratégie qui correspond au niveau de contrôle que vous souhaitez conserver pendant le déploiement. Les mises à jour continues sont l'option la plus simple. Blue/green et les déploiements de Canary vous permettent de mieux contrôler la façon dont le trafic est transféré vers la nouvelle version.

Mises à jour continues

Pour effectuer une mise à jour continue, vous publiez vos modifications dans le $LATEST.PUBLISHED version de votre fonction. $LATEST.PUBLISHED est un type de version spécifique aux instances gérées Lambda que vous republiez avec un nouveau code ou une nouvelle configuration au lieu de conserver des versions numérotées. Lorsque vous appelez une fonction Lambda Managed Instances avec son Amazon Resource Name (ARN) non qualifié, Lambda invoque $LATEST.PUBLISHED version. Pour plus d’informations, consultez $ LATEST.PUBLISHED version dans les instances gérées Lambda.

Chaque fois que vous republiez $LATEST.PUBLISHED, Lambda remplace progressivement les environnements d'exécution de vos instances gérées par la nouvelle version, sans que vous ayez à gérer le transfert du trafic directement via un alias de fonction. Il s'agit de la stratégie la plus simple.

Utilisez les mises à jour continues lorsque vous souhaitez un transfert progressif automatique du trafic de l'ancienne version vers la nouvelle version, et que vous n'avez pas besoin de contrôler directement le pourcentage de trafic envoyé à chaque version pour gérer le déploiement ou la restauration.

Blue/green déploiements avec un alias pondéré

Dans un blue/green déploiement, vous publiez la nouvelle version en même temps que la version actuelle et vous utilisez un alias avec une configuration de routage pour envoyer un pourcentage du trafic vers la nouvelle version. Vous invoquez la fonction via l'ARN qualifié d'alias. Pour avancer le déploiement, vous augmentez le poids de la nouvelle version ; pour l'annuler, vous le reportez à la version précédente.

L'exemple suivant utilise le AWS CLI pour envoyer 10 % du trafic vers la version 2 version complète 1 continue de desservir les 90 % restants.

aws lambda update-alias \
  --function-name my-managed-instance-function \
  --name production \
  --function-version 1 \
  --routing-config AdditionalVersionWeights={"2"=0.1}

Dans cette commande :

• my-managed-instance-function est le nom de votre fonction.

• production est le nom de l'alias que vous invoquez.

• --function-version 1 est la version qui continue de recevoir le trafic restant.

• AdditionalVersionWeights={"2"=0.1} envoie 10 % du trafic à la version 2.

Pour revenir en arrière, effacez la configuration de routage afin que tout le trafic revienne à la version stable.

aws lambda update-alias \
  --function-name my-managed-instance-function \
  --name production \
  --function-version 1 \
  --routing-config '{}'

Dans cette commande, --routing-config '{}' efface la configuration de routage afin que tout le trafic revienne à la version dans --function-version, version 1.

Déploiements Canary avec AWS CodeDeploy

Pour automatiser un blue/green changement de trafic, utilisation AWS CodeDeploy. CodeDeploy déplace le trafic de la version actuelle vers la nouvelle version en fonction d'une configuration de déploiement, par exemple en envoyant 10 % du trafic vers la nouvelle version, en attendant cinq minutes, puis en déplaçant le reste. Si un CloudWatch l'alarme associée au déploiement passe en état d'alarme pendant le quart de travail, CodeDeploy annule automatiquement le déploiement.

Pour plus d'informations sur CodeDeploy configurations de déploiement pour Lambda, voir Configurations de déploiement sur une plateforme de calcul Lambda dans le AWS CodeDeploy Guide de l'utilisateur.

Choisir entre $LATEST.PUBLISHED et versions numériques avec alias

Les deux modèles de déploiement introduisent des modifications progressivement. Si vous mettez à jour $LATEST.PUBLISHED ou déplacez le trafic à l'aide d'un alias pondéré, Lambda Managed Instances remplace les environnements d'exécution de l'ancienne version par la nouvelle version par étapes, plutôt que d'un seul coup. Cette approche permet d'utiliser les instances de manière efficace pendant le déploiement. Au lieu de provisionner à l'avance un deuxième ensemble complet d'environnements d'exécution, Lambda les remplace par étapes : à chaque étape, il récupère de la capacité de l'ancienne version avant de lancer le lot suivant de la nouvelle version, de sorte que le déploiement évite d'atteindre le double de la capacité de base.

Comment $LATEST.PUBLISHED progression des déploiements

Lorsque vous publiez une mise à jour de $LATEST.PUBLISHED, Lambda commence le déploiement de la nouvelle version par étapes. À chaque étape, Lambda crée de nouveaux environnements d'exécution (jusqu'à 20 % du total de l'ancienne version) et remplace progressivement les environnements d'exécution de l'ancienne version.

Deux facteurs déterminent la durée du déploiement :

• Durée d'initialisation - Chaque étape attend l'initialisation des nouveaux environnements d'exécution avant de poursuivre. Si l'initialisation prend 10 minutes, chaque étape attend au moins 10 minutes.

• Durée d'invocation - Avant que Lambda puisse supprimer un ancien environnement d'exécution, ses appels en cours de vol doivent être terminés (drainés). Si la durée moyenne de votre appel est de 5 minutes, la vidange prend environ 5 minutes en moyenne à chaque étape.

Étant donné que les instances gérées Lambda maintiennent un taux d'utilisation élevé des instances, l'initialisation et la vidange contribuent à la durée totale du déploiement. Les fonctions dont l'initialisation est longue ou les appels de longue durée mettent plus de temps à être complètement déployées.

Comment progressent les versions numériques avec alias

Les mises à jour pondérées des alias sont progressives de la même manière. Lorsque vous modifiez les pondérations de routage sur un alias, par exemple, de 90 % en version 1 et 10 % en version 2 à 100 % en version 2, Lambda Managed Instances remplace lentement les environnements d'exécution de la version 1 par la version 2, sans provisionner de capacité d'instance excédentaire.

Utilisez des versions numériques avec un alias lorsque vous souhaitez contrôler plus étroitement le déploiement progressif et l'observabilité spécifique à la version. Chaque version étant un qualificatif distinct, vous pouvez comparer les statistiques par version pour la version Canary et la version stable avant de promouvoir une modification. Pour plus d'informations, voir affichage des métriques pour vos fonctions Lambda.

Configuration de la mise à l'échelle après un déploiement

Chaque version de fonction que vous déployez possède sa propre configuration de dimensionnement, qui contrôle le nombre minimum et maximum d'environnements d'exécution gérés par Lambda pour cette version. Définissez la configuration de dimensionnement après avoir publié une version afin que la nouvelle version puisse traiter le trafic à la capacité que vous attendez.

L'exemple suivant définit la configuration de dimensionnement pour une version spécifique. Remplacer 2 avec votre numéro de version ou avec $LATEST.PUBLISHED.

aws lambda put-function-scaling-config \
  --function-name my-managed-instance-function \
  --qualifier 2 \
  --function-scaling-config MinExecutionEnvironments=3,MaxExecutionEnvironments=20

Gestion des déploiements à l'aide de l'infrastructure sous forme de code

Vous pouvez définir et déployer les fonctions des instances gérées Lambda et leurs fournisseurs de capacité avec une infrastructure en tant que code, notamment AWS CloudFormation, le AWS Kit de développement cloud (AWS CDK) et des outils tiers tels que HashiCorp Terraforme. Modélisez votre fournisseur de capacité, votre fonction, vos versions et votre alias en tant que ressources afin que votre stratégie de déploiement soit reproductible et révisable.

Gardez les considérations suivantes à l'esprit lorsque vous gérez des déploiements d'instances gérées Lambda avec IaC :

• Publiez une version pour activer une modification. Une nouvelle version de fonction n'est active sur les instances du fournisseur de capacité qu'après sa publication. Modélisez chaque version que vous souhaitez conserver en service, par exemple, les deux côtés d'un blue/green shift, en tant que ressource propre.

• La configuration de mise à l'échelle se fait par version. Appliquez les paramètres d'environnement d'exécution minimum et maximum à chaque version ou à $LATEST.PUBLISHED. Si votre outil IaC ne modélise pas directement la configuration de mise à l'échelle, définissez-le à l'aide du put-function-scaling-config AWS Commande CLI après le déploiement.

• Les packages de déploiement doivent provenir d'Amazon S3 lorsque vous utilisez AWS API de contrôle du cloud. Le AWS L'API Cloud Control accepte le code d'une fonction uniquement en tant qu'emplacement Amazon S3 ou URI d'image de conteneur, et non en tant que fichier .zip téléchargé localement. Si votre outil IaC utilise cette API, chargez d'abord votre package de déploiement dans un compartiment S3 et référencez-le par compartiment et clé. Utilisez un bucket versionné afin de détecter les mises à jour de l'objet.

Exemple : CloudFormation modèle

Les suivants CloudFormation le modèle montre un blue/green déploiement. Il crée un fournisseur de capacité, une fonction Lambda Managed Instances, deux versions publiées (chacune avec sa propre configuration de dimensionnement des fonctions) et un alias nommé production qui achemine 90 % du trafic vers la version stable et 10 % vers la version Canary. Pour promouvoir le canari, définissez son alias FunctionVersion vers la version Canary et supprimez le RoutingConfig. Pour revenir en arrière, retirez RoutingConfig afin que tout le trafic revienne à la version stable. Remplacez le sous-réseau, le groupe de sécurité, le rôle et les valeurs Amazon S3 par les vôtres.

AWSTemplateFormatVersion: '2010-09-09'
Description: Lambda Managed Instances blue/green deployment with a weighted alias

Resources:
  MyCapacityProvider:
    Type: AWS::Lambda::CapacityProvider
    Properties:
      CapacityProviderName: my-capacity-provider
      VpcConfig:
        SubnetIds:
          - subnet-0123456789abcdef0
        SecurityGroupIds:
          - sg-0123456789abcdef0
      PermissionsConfig:
        CapacityProviderOperatorRoleArn: arn:aws:iam::111122223333:role/my-capacity-provider-operator-role
      InstanceRequirements:
        Architectures:
          - arm64

  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: my-managed-instance-function
      Role: arn:aws:iam::111122223333:role/my-function-execution-role
      Runtime: python3.13
      Handler: index.lambda_handler
      Architectures:
        - arm64
      Code:
        S3Bucket: my-deployment-bucket
        S3Key: function.zip
      CapacityProviderConfig:
        LambdaManagedInstancesCapacityProviderConfig:
          CapacityProviderArn: !GetAtt MyCapacityProvider.Arn

  # Stable version - receives the majority of traffic
  StableVersion:
    Type: AWS::Lambda::Version
    Properties:
      FunctionName: !Ref MyFunction
      FunctionScalingConfig:
        MinExecutionEnvironments: 10
        MaxExecutionEnvironments: 50

  # Canary version - receives a small percentage of traffic
  CanaryVersion:
    Type: AWS::Lambda::Version
    Properties:
      FunctionName: !Ref MyFunction
      FunctionScalingConfig:
        MinExecutionEnvironments: 3
        MaxExecutionEnvironments: 20

  ProductionAlias:
    Type: AWS::Lambda::Alias
    Properties:
      FunctionName: !Ref MyFunction
      Name: production
      FunctionVersion: !GetAtt StableVersion.Version
      RoutingConfig:
        AdditionalVersionWeights:
          - FunctionVersion: !GetAtt CanaryVersion.Version
            FunctionWeight: 0.1

Exemple : CDK

L'exemple CDK suivant (TypeScript) définit le même fournisseur de capacité et la même fonction en utilisant les constructions de niveau 1 (L1) du aws-cdk-lib/aws-lambda module. operatorRole et executionRole sont des rôles IAM définis ailleurs dans votre stack.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';

const capacityProvider = new lambda.CfnCapacityProvider(this, 'MyCapacityProvider', {
  capacityProviderName: 'my-capacity-provider',
  vpcConfig: {
    subnetIds: ['subnet-0123456789abcdef0'],
    securityGroupIds: ['sg-0123456789abcdef0'],
  },
  permissionsConfig: {
    capacityProviderOperatorRoleArn: operatorRole.roleArn,
  },
  instanceRequirements: {
    architectures: ['arm64'],
  },
});

const fn = new lambda.CfnFunction(this, 'MyFunction', {
  functionName: 'my-managed-instance-function',
  role: executionRole.roleArn,
  runtime: 'python3.13',
  handler: 'index.lambda_handler',
  architectures: ['arm64'],
  code: { s3Bucket: 'my-deployment-bucket', s3Key: 'function.zip' },
  capacityProviderConfig: {
    lambdaManagedInstancesCapacityProviderConfig: {
      capacityProviderArn: capacityProvider.attrArn,
    },
  },
  functionScalingConfig: {
    minExecutionEnvironments: 3,
    maxExecutionEnvironments: 20,
  },
  publishToLatestPublished: true,
});
fn.addDependency(capacityProvider);

Exemple : déploiement de Canary avec AWS CodeDeploy

L'exemple CDK suivant (TypeScript) utilisations AWS CodeDeploy pour transférer automatiquement le trafic vers une nouvelle version de fonction. Le LambdaDeploymentGroup envoie 10 % du trafic vers la nouvelle version pendant cinq minutes, puis déplace le reste. Si le CloudWatch l'alarme passe en état d'alarme pendant le déploiement, CodeDeploy revient à la version précédente.

fn est le L1 CfnFunction à partir de l'exemple précédent. Parce que CodeDeploys LambdaDeploymentGroup fonctionne avec l'alias de niveau 2 (L2) et les constructions de fonction, importe la fonction L1 par ARN et crée la version et l'alias à partir de celle-ci.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as codedeploy from 'aws-cdk-lib/aws-codedeploy';
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';

// Import the L1 function so that L2 constructs can reference it.
const importedFn = lambda.Function.fromFunctionArn(this, 'ImportedFunction', fn.attrArn);

// Publish the version that CodeDeploy shifts traffic to.
const canaryVersion = new lambda.CfnVersion(this, 'CanaryVersion', {
  functionName: fn.ref,
});

// Create the alias that CodeDeploy shifts traffic on.
const alias = new lambda.Alias(this, 'ProductionAlias', {
  aliasName: 'production',
  version: lambda.Version.fromVersionAttributes(this, 'CanaryVersionRef', {
    lambda: importedFn,
    version: canaryVersion.attrVersion,
  }),
});

// Roll back automatically if this alarm fires during the deployment.
const errorAlarm = new cloudwatch.Alarm(this, 'ErrorAlarm', {
  metric: importedFn.metricErrors({ period: cdk.Duration.minutes(1) }),
  threshold: 5,
  evaluationPeriods: 1,
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
});

new codedeploy.LambdaDeploymentGroup(this, 'CanaryDeployment', {
  alias,
  deploymentConfig: codedeploy.LambdaDeploymentConfig.CANARY_10PERCENT_5MINUTES,
  alarms: [errorAlarm],
  autoRollback: {
    failedDeployment: true,
    deploymentInAlarm: true,
  },
});

Étapes suivantes

• Comprenez mise à l'échelle pour les instances gérées Lambda

• En savoir plus sur fournisseurs de capacité pour les instances gérées Lambda

• Révision meilleures pratiques pour les instances gérées Lambda