Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Menyebarkan dan memperbarui fungsi Instans Terkelola Lambda Saat Anda memperbarui fungsi Instans Terkelola Lambda, Lambda menyediakan lingkungan eksekusi untuk versi fungsi baru pada instans terkelola sebelum mengalihkan lalu lintas ke sana. Anda dapat mengontrol kecepatan dan keamanan penerapan dengan memilih strategi penerapan. Topik ini menjelaskan strategi penerapan yang tersedia untuk fungsi Instans Terkelola Lambda dan cara mendefinisikannya dengan infrastruktur sebagai kode (IaC). **catatan** Sebelum Anda menerapkan fungsi, Anda harus memiliki penyedia kapasitas. Untuk informasi lebih lanjut, lihat [penyedia kapasitas untuk Instans Terkelola Lambda](lambda-managed-instances-capacity-providers.md). ## Strategi penyebaran Instans Terkelola Lambda mendukung strategi berikut untuk merilis versi fungsi baru. Pilih strategi yang sesuai dengan seberapa banyak kontrol yang ingin Anda pertahankan selama peluncuran. Pembaruan bergulir adalah opsi paling sederhana. Blue/green dan penerapan canary memberi Anda kontrol lebih besar atas bagaimana lalu lintas bergerak ke versi baru. ### Pembaruan bergulir Untuk melakukan pembaruan bergulir, Anda mempublikasikan perubahan ke `$LATEST.PUBLISHED` versi fungsi Anda. `$LATEST.PUBLISHED` adalah jenis versi khusus untuk Instans Terkelola Lambda yang Anda publikasikan ulang dengan kode atau konfigurasi baru alih-alih mempertahankan versi bernomor. Saat Anda memanggil fungsi Instans Terkelola Lambda dengan Nama Sumber Daya Amazon (ARN) yang tidak memenuhi syarat, Lambda memanggil `$LATEST.PUBLISHED` versi. Untuk informasi selengkapnya, lihat [LATEST.PUBLISHED Versi $ di Instans Terkelola Lambda](lambda-managed-instances-version-publishing.md). Setiap kali Anda menerbitkan ulang `$LATEST.PUBLISHED`, Lambda secara bertahap menggantikan lingkungan eksekusi pada instans terkelola Anda dengan versi baru, tanpa mengharuskan Anda mengelola pergeseran lalu lintas secara langsung melalui alias fungsi. Ini adalah strategi paling sederhana. Gunakan pembaruan bergulir saat Anda menginginkan pergeseran lalu lintas bertahap otomatis dari versi lama ke versi baru, dan Anda tidak memerlukan kontrol langsung atas persentase lalu lintas yang dikirim ke setiap versi untuk mengelola penerapan atau rollback. ### Blue/green penerapan dengan alias tertimbang Dalam sebuah blue/green penerapan, Anda menerbitkan versi baru bersama versi saat ini dan menggunakan [alias](configuration-aliases.md) dengan konfigurasi routing untuk mengirim persentase lalu lintas ke versi baru. Anda memanggil fungsi melalui ARN yang memenuhi syarat alias. Untuk memutar penerapan ke depan, Anda menambah bobot pada versi baru; untuk memutarnya kembali, Anda menggeser bobot kembali ke versi sebelumnya. Contoh berikut menggunakan AWS CLI untuk mengirim 10 persen lalu lintas ke versi `2` sementara versi `1` terus melayani 90 persen sisanya. ``` aws lambda update-alias \ --function-name my-managed-instance-function \ --name production \ --function-version 1 \ --routing-config AdditionalVersionWeights={"2"=0.1} ``` Dalam perintah ini: + `my-managed-instance-function` adalah nama fungsi Anda. + `production` adalah nama alias yang Anda panggil. + `--function-version 1` adalah versi yang terus menerima lalu lintas yang tersisa. + `AdditionalVersionWeights={"2"=0.1}` mengirimkan 10 persen lalu lintas ke versi `2`. Untuk memutar kembali, hapus konfigurasi routing sehingga semua lalu lintas kembali ke versi stabil. ``` aws lambda update-alias \ --function-name my-managed-instance-function \ --name production \ --function-version 1 \ --routing-config '{}' ``` Dalam perintah ini, `--routing-config '{}'` menghapus konfigurasi routing sehingga semua lalu lintas kembali ke versi di `--function-version`, versi `1`. ### Penyebaran Canary dengan AWS CodeDeploy Untuk mengotomatiskan a blue/green pergeseran lalu lintas, gunakan AWS CodeDeploy. CodeDeploy mengalihkan lalu lintas dari versi saat ini ke versi baru sesuai dengan konfigurasi penerapan—misalnya, mengirim 10 persen lalu lintas ke versi baru, menunggu lima menit, dan kemudian memindahkan sisanya. Jika a CloudWatch alarm yang terkait dengan penyebaran memasuki keadaan alarm selama shift, CodeDeploy menggulung penerapan kembali secara otomatis. Untuk informasi lebih lanjut tentang CodeDeploy konfigurasi penerapan untuk Lambda, lihat [Konfigurasi penerapan pada platform komputasi Lambda](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) di *AWS CodeDeploy Panduan Pengguna*. ## Memilih antara $LATEST.PUBLISHED dan versi numerik dengan alias Kedua model penerapan meluncurkan perubahan *bertahap*. Apakah Anda memperbarui `$LATEST.PUBLISHED` atau menggeser lalu lintas dengan alias tertimbang, Lambda Managed Instances menggantikan lingkungan eksekusi versi lama dengan versi baru secara bertahap, bukan sekaligus. Pendekatan ini membuat pemanfaatan instans tetap efisien selama peluncuran. Alih-alih menyediakan satu set lengkap lingkungan eksekusi kedua di muka, Lambda menggantinya secara bertahap: pada setiap langkah ia mengklaim kembali kapasitas dari versi lama sebelum memunculkan batch berikutnya dari versi baru, sehingga peluncuran menghindari mencapai dua kali lipat kapasitas dasar. ### Bagaimana $LATEST.PUBLISHED kemajuan peluncuran Saat Anda menerbitkan pembaruan ke `$LATEST.PUBLISHED`, Lambda mulai meluncurkan versi baru dalam langkah-langkah. Pada setiap langkah, Lambda menciptakan lingkungan eksekusi baru — hingga 20 persen dari total versi lama — dan secara bertahap menggantikan lingkungan eksekusi versi lama. Dua faktor menentukan berapa lama peluncuran berlangsung: + **Waktu inisialisasi** - Setiap langkah menunggu lingkungan eksekusi baru untuk diinisialisasi sebelum dilanjutkan. Jika inisialisasi memakan waktu 10 menit, setiap langkah menunggu setidaknya 10 menit. + **Memanggil durasi** - Sebelum Lambda dapat menghapus lingkungan eksekusi lama, pemanggilan dalam penerbangannya harus selesai (drain). Jika durasi pemanggilan rata-rata Anda adalah 5 menit, pengeringan rata-rata memakan waktu sekitar 5 menit pada setiap langkah. Karena Instans Terkelola Lambda menjaga pemanfaatan instans tetap tinggi, inisialisasi dan pengeringan berkontribusi pada total waktu penerapan. Fungsi dengan inisialisasi yang lama atau pemanggilan yang berjalan lama membutuhkan waktu lebih lama untuk diluncurkan sepenuhnya. ### Bagaimana versi numerik dengan alias berkembang Pembaruan alias tertimbang dilakukan secara bertahap dengan cara yang sama. Saat Anda mengubah bobot routing pada alias—misalnya, dari 90 persen versi 1 dan 10 persen versi 2 menjadi 100 persen versi 2— Instans Terkelola Lambda secara perlahan menggantikan lingkungan eksekusi versi 1 dengan versi 2, tanpa menyediakan kapasitas instans berlebih. Gunakan versi numerik dengan alias ketika Anda ingin kontrol yang lebih ketat atas peluncuran bertahap dan pengamatan khusus versi. Karena setiap versi adalah kualifikasi yang berbeda, Anda dapat membandingkan metrik per versi untuk burung kenari dan versi stabil sebelum Anda mempromosikan perubahan. Untuk informasi lebih lanjut, lihat [melihat metrik untuk fungsi Lambda](monitoring-metrics-view.md). ## Mengkonfigurasi penskalaan setelah penerapan Setiap versi fungsi yang Anda terapkan memiliki konfigurasi penskalaannya sendiri, yang mengontrol jumlah minimum dan maksimum lingkungan eksekusi yang dipertahankan Lambda untuk versi tersebut. Tetapkan konfigurasi penskalaan setelah Anda menerbitkan versi sehingga versi baru dapat melayani lalu lintas pada kapasitas yang Anda harapkan. Contoh berikut menetapkan konfigurasi penskalaan untuk versi tertentu. Ganti `2` dengan nomor versi Anda atau dengan `$LATEST.PUBLISHED`. ``` aws lambda put-function-scaling-config \ --function-name my-managed-instance-function \ --qualifier 2 \ --function-scaling-config MinExecutionEnvironments=3,MaxExecutionEnvironments=20 ``` ## Mengelola penerapan dengan infrastruktur sebagai kode Anda dapat menentukan dan menerapkan fungsi Instans Terkelola Lambda dan penyedia kapasitasnya dengan infrastruktur sebagai kode, termasuk AWS CloudFormation, AWS Kit Pengembangan Cloud (AWS CDK), dan alat pihak ketiga seperti HashiCorp Terraform. Model penyedia kapasitas, fungsi, versi, dan alias Anda sebagai sumber daya sehingga strategi penerapan Anda dapat direproduksi dan dapat ditinjau. Ingatlah pertimbangan berikut saat mengelola penerapan Instans Terkelola Lambda dengan IaC: + **Publikasikan versi untuk mengaktifkan perubahan.** Versi fungsi baru menjadi aktif pada instans penyedia kapasitas hanya setelah dipublikasikan. Model setiap versi yang ingin Anda pertahankan dalam layanan—misalnya, kedua sisi blue/green shift—sebagai sumber dayanya sendiri. + **Konfigurasi penskalaan adalah per versi.** Terapkan pengaturan lingkungan eksekusi minimum dan maksimum untuk setiap versi atau ke `$LATEST.PUBLISHED`. Jika alat iAC Anda tidak memodelkan konfigurasi penskalaan secara langsung, atur dengan `put-function-scaling-config` AWS Perintah CLI setelah penerapan. + **Paket penerapan harus berasal dari Amazon S3 saat Anda menggunakan AWS API Kontrol Awan.** Yang AWS Cloud Control API menerima kode fungsi hanya sebagai lokasi Amazon S3 atau URI gambar kontainer, bukan sebagai file.zip yang diunggah secara lokal. Jika alat iAC Anda menggunakan API ini, unggah paket penerapan Anda ke bucket S3 terlebih dahulu dan referensikan dengan bucket dan kunci. Gunakan bucket berversi sehingga pembaruan pada objek terdeteksi. ### Contoh: CloudFormation templat Berikut ini CloudFormation Template menunjukkan a blue/green penyebaran. Ini menciptakan penyedia kapasitas, fungsi Lambda Managed Instances, dua versi yang diterbitkan (masing-masing dengan konfigurasi penskalaan fungsinya sendiri), dan alias bernama `production` yang mengarahkan 90 persen lalu lintas ke versi stabil dan 10 persen ke versi kenari. Untuk mempromosikan kenari, atur alias `FunctionVersion` ke versi kenari dan hapus `RoutingConfig`. Untuk memutar kembali, lepaskan `RoutingConfig` sehingga semua lalu lintas kembali ke versi stabil. Ganti nilai subnet, grup keamanan, peran, dan Amazon S3 dengan nilai Anda sendiri. ``` 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 ``` ### Contoh: CDK Contoh CDK berikut (TypeScript) mendefinisikan penyedia kapasitas dan fungsi yang sama menggunakan konstruksi level 1 (L1) dari `aws-cdk-lib/aws-lambda` modul. `operatorRole` dan `executionRole` apakah peran IAM didefinisikan di tempat lain di tumpukan Anda. ``` 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); ``` ### Contoh: penyebaran kenari dengan AWS CodeDeploy Contoh CDK berikut (TypeScript) menggunakan AWS CodeDeploy untuk mengalihkan lalu lintas ke versi fungsi baru secara otomatis. Yang `LambdaDeploymentGroup` mengirimkan 10 persen lalu lintas ke versi baru selama lima menit dan kemudian menggeser sisanya. Jika CloudWatch alarm memasuki keadaan alarm selama penerapan, CodeDeploy memutar kembali ke versi sebelumnya. `fn` adalah L1 `CfnFunction` dari contoh sebelumnya. Karena CodeDeployadalah `LambdaDeploymentGroup` bekerja dengan alias level 2 (L2) dan konstruksi fungsi, impor fungsi L1 oleh ARN dan buat versi dan alias darinya. ``` 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, }, }); ``` ## Langkah selanjutnya + Memahami [penskalaan untuk Instans Terkelola Lambda](lambda-managed-instances-scaling.md) + Pelajari tentang [penyedia kapasitas untuk Instans Terkelola Lambda](lambda-managed-instances-capacity-providers.md) + Tinjauan [praktik terbaik untuk Instans Terkelola Lambda](lambda-managed-instances-best-practices.md)