Distribuzione e aggiornamento delle funzioni di Lambda Managed Instances

Quando si aggiorna una funzione Lambda Managed Instances, Lambda fornisce gli ambienti di esecuzione per la nuova versione della funzione sulle istanze gestite prima di indirizzare il traffico verso di esse. Puoi controllare la velocità e la sicurezza dell'implementazione selezionando una strategia di distribuzione. Questo argomento descrive le strategie di distribuzione disponibili per le funzioni di Lambda Managed Instances e come definirle con infrastructure as code (IaC).

Nota

Prima di distribuire una funzione, è necessario disporre di un fornitore di capacità. Per ulteriori informazioni, vedere fornitori di capacità per le istanze gestite Lambda.

Strategie di distribuzione

Lambda Managed Instances supporta le seguenti strategie per il rilascio di una nuova versione della funzione. Scegli la strategia che corrisponde al livello di controllo che desideri mantenere sull'implementazione. Gli aggiornamenti continui sono l'opzione più semplice. Blue/green e le implementazioni di Canary offrono un maggiore controllo sul trasferimento del traffico verso la nuova versione.

Aggiornamenti continui

Per eseguire un aggiornamento progressivo, pubblichi le modifiche nel $LATEST.PUBLISHED versione della tua funzione. $LATEST.PUBLISHED è un tipo di versione specifico per Lambda Managed Instances che puoi ripubblicare con nuovo codice o configurazione invece di mantenere versioni numerate. Quando richiami una funzione Lambda Managed Instances con il relativo Amazon Resource Name (ARN) non qualificato, Lambda richiama $LATEST.PUBLISHED versione. Per ulteriori informazioni, consulta LATEST.PUBLISHED versione $ nelle istanze gestite Lambda.

Ogni volta che ripubblichi $LATEST.PUBLISHED, Lambda sostituisce gradualmente gli ambienti di esecuzione sulle istanze gestite con la nuova versione, senza che sia necessario gestire lo spostamento del traffico direttamente tramite un alias di funzione. Questa è la strategia più semplice.

Utilizza gli aggiornamenti continui quando desideri uno spostamento graduale e automatico del traffico dalla vecchia versione alla nuova versione e non hai bisogno del controllo diretto della percentuale di traffico inviata a ciascuna versione per gestire la distribuzione o il rollback.

Blue/green distribuzioni con un alias ponderato

In un blue/green distribuzione, si pubblica la nuova versione insieme alla versione corrente e si utilizza un alias con una configurazione di routing per inviare una percentuale di traffico alla nuova versione. La funzione viene richiamata tramite l'ARN qualificato con alias. Per portare avanti la distribuzione, si aumenta il peso sulla nuova versione; per ripristinarla, si riporta il peso alla versione precedente.

L'esempio seguente utilizza AWS CLI per inviare il 10% del traffico alla versione 2 mentre la versione 1 continua a servire il restante 90 percento.

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

In questo comando:

• my-managed-instance-function è il nome della tua funzione.

• production è il nome dell'alias che richiami.

• --function-version 1 è la versione che continua a ricevere il traffico rimanente.

• AdditionalVersionWeights={"2"=0.1} invia il 10 percento del traffico alla versione 2.

Per eseguire il rollback, cancella la configurazione del routing in modo che tutto il traffico ritorni alla versione stabile.

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

In questo comando, --routing-config '{}' cancella la configurazione del routing in modo che tutto il traffico ritorni alla versione in --function-version, versione 1.

Implementazioni Canarie con AWS CodeDeploy

Per automatizzare un blue/green spostamento del traffico, usa AWS CodeDeploy. CodeDeploy sposta il traffico dalla versione corrente alla nuova versione in base a una configurazione di distribuzione, ad esempio inviando il 10% del traffico alla nuova versione, aspettando cinque minuti e quindi spostando il resto. Se un CloudWatch l'allarme associato allo schieramento entra in stato di allarme durante il turno, CodeDeploy ripristina automaticamente la distribuzione.

Per ulteriori informazioni su CodeDeploy configurazioni di distribuzione per Lambda, consulta configurazioni di distribuzione su una piattaforma di elaborazione Lambda nel AWS CodeDeploy Guida per l'utente.

Scelta tra $LATEST.PUBLISHED e versioni numeriche con alias

Entrambi i modelli di distribuzione implementano le modifiche gradualmente. Se si esegue l'aggiornamento $LATEST.PUBLISHED o sposta il traffico con un alias ponderato, Lambda Managed Instances sostituisce gli ambienti di esecuzione della vecchia versione con la nuova versione gradualmente, anziché contemporaneamente. Questo approccio mantiene efficiente l'utilizzo delle istanze durante il rollout. Invece di effettuare il provisioning di un secondo set completo di ambienti di esecuzione, Lambda li sostituisce in modo incrementale: ad ogni passaggio recupera la capacità dalla vecchia versione prima di attivare il batch successivo della nuova versione, in modo che il rollout eviti di raggiungere il doppio della capacità di base.

Come $LATEST.PUBLISHED avanzamento delle implementazioni

Quando si pubblica un aggiornamento su $LATEST.PUBLISHED, Lambda inizia a distribuire la nuova versione gradualmente. In ogni fase, Lambda crea nuovi ambienti di esecuzione, fino al 20 percento del totale della vecchia versione, e sostituisce gradualmente gli ambienti di esecuzione della vecchia versione.

Due fattori determinano la durata del rollout:

• Tempo di inizializzazione - Ogni passaggio attende l'inizializzazione dei nuovi ambienti di esecuzione prima di procedere. Se l'inizializzazione richiede 10 minuti, ogni passaggio attende almeno 10 minuti.

• Durata dell'invocazione - Prima che Lambda possa rimuovere un vecchio ambiente di esecuzione, le sue invocazioni in corso devono terminare (esaurirsi). Se la durata media delle invocazioni è di 5 minuti, il drenaggio richiede in media circa 5 minuti per ogni passaggio.

Poiché Lambda Managed Instances mantiene elevato l'utilizzo delle istanze, sia l'inizializzazione che il drenaggio contribuiscono al tempo totale di implementazione. Le funzioni con inizializzazione prolungata o invocazioni di lunga durata richiedono più tempo per essere implementate completamente.

Come progrediscono le versioni numeriche con alias

Gli aggiornamenti ponderati degli alias sono graduali allo stesso modo. Quando si modificano i pesi di routing di un alias, ad esempio passando dal 90% della versione 1 e del 10% della versione 2 al 100% della versione 2, Lambda Managed Instances sostituisce lentamente gli ambienti di esecuzione della versione 1 con la versione 2, senza fornire una capacità di istanza in eccesso.

Usa le versioni numeriche con un alias quando desideri un controllo più rigoroso sull'implementazione graduale e sull'osservabilità specifica della versione. Poiché ogni versione è un qualificatore distinto, puoi confrontare le metriche per versione per versione canaria e per la versione stabile prima di promuovere una modifica. Per ulteriori informazioni, consulta visualizzazione delle metriche per le funzioni Lambda.

Configurazione della scalabilità dopo una distribuzione

Ogni versione della funzione distribuita ha una propria configurazione di scalabilità, che controlla il numero minimo e massimo di ambienti di esecuzione gestiti da Lambda per quella versione. Imposta la configurazione di scalabilità dopo aver pubblicato una versione in modo che la nuova versione possa servire il traffico alla capacità prevista.

L'esempio seguente imposta la configurazione di ridimensionamento per una versione specifica. Sostituisci 2 con il tuo numero di versione o con $LATEST.PUBLISHED.

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

Gestione delle implementazioni con l'infrastruttura come codice

È possibile definire e distribuire le funzioni di Lambda Managed Instances e i relativi fornitori di capacità utilizzando l'infrastruttura come codice, tra cui AWS CloudFormation, il AWS Kit di sviluppo cloud (AWS CDK) e strumenti di terze parti come HashiCorp Terraform. Modella il tuo fornitore di capacità, la funzione, le versioni e gli alias come risorse in modo che la tua strategia di implementazione sia riproducibile e revisionabile.

Tieni a mente le seguenti considerazioni quando gestisci le implementazioni di Lambda Managed Instances con IaC:

• Pubblica una versione per attivare una modifica. Una nuova versione della funzione diventa attiva sulle istanze del fornitore di capacità solo dopo la pubblicazione. Modella ogni versione che desideri mantenere in servizio, ad esempio entrambi i lati di un blue/green shift, come risorsa propria.

• La configurazione del ridimensionamento è per versione. Applica le impostazioni minime e massime dell'ambiente di esecuzione a ciascuna versione o a $LATEST.PUBLISHED. Se il tuo strumento IaC non modella direttamente la configurazione di ridimensionamento, impostalo con put-function-scaling-config AWS Comando CLI dopo la distribuzione.

• I pacchetti di distribuzione devono provenire da Amazon S3 quando si utilizza AWS API Cloud Control. La AWS L'API Cloud Control accetta il codice di una funzione solo come posizione Amazon S3 o URI di immagine del contenitore, non come file .zip caricato localmente. Se il tuo strumento IaC utilizza questa API, carica prima il pacchetto di distribuzione in un bucket S3 e fai riferimento ad esso per bucket e chiave. Utilizza un bucket con versione in modo che vengano rilevati gli aggiornamenti dell'oggetto.

Esempio: CloudFormation modello

Il seguente CloudFormation il modello mostra un blue/green distribuzione. Crea un fornitore di capacità, una funzione Lambda Managed Instances, due versioni pubblicate (ognuna con la propria configurazione di scalabilità delle funzioni) e un alias denominato production che indirizza il 90 percento del traffico verso la versione stabile e il 10 percento verso la versione canaria. Per promuovere il canarino, imposta l'alias FunctionVersion alla versione canaria e rimuovi RoutingConfig. Per eseguire il rollback, rimuovere RoutingConfig in modo che tutto il traffico ritorni alla versione stabile. Sostituisci la sottorete, il gruppo di sicurezza, il ruolo e i valori di Amazon S3 con i tuoi.

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

Esempio: CDK

Il seguente esempio di CDK (TypeScript) definisce lo stesso fornitore di capacità e la stessa funzione utilizzando i costrutti di livello 1 (L1) di aws-cdk-lib/aws-lambda modulo. operatorRole e executionRole sono ruoli IAM definiti altrove nel tuo 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);

Esempio: distribuzione canaria con AWS CodeDeploy

Il seguente esempio di CDK (TypeScript) utilizza AWS CodeDeploy per spostare automaticamente il traffico verso una nuova versione della funzione. Il LambdaDeploymentGroup invia il 10 percento del traffico alla nuova versione per cinque minuti e poi sposta il resto. Se CloudWatch l'allarme entra in uno stato di allarme durante l'attivazione, CodeDeploy torna alla versione precedente.

fn è la L1 CfnFunction dall'esempio precedente. Perché CodeDeployè LambdaDeploymentGroup funziona con l'alias di livello 2 (L2) e i costrutti di funzione, importa la funzione L1 tramite ARN e ne crea la versione e l'alias.

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,
  },
});

Fasi successive

• Comprendi scalabilità per le istanze gestite Lambda

• Scopri di più fornitori di capacità per le istanze gestite Lambda

• Revisione best practice per le istanze gestite Lambda