View a markdown version of this page

Deployment canary Amazon ECS - Amazon Elastic Container Service
Sumber daya yang terlibat dalam penyebaran kenariPertimbangan-pertimbanganCara kerja penerapan kenari

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Deployment canary Amazon ECS

Penyebaran Canary pertama-tama merutekan persentase kecil lalu lintas ke revisi baru untuk pengujian awal, kemudian menggeser semua lalu lintas yang tersisa sekaligus setelah fase kenari selesai dengan sukses. Dengan penerapan burung kenari Amazon ECS, validasi revisi layanan baru dengan lalu lintas pengguna nyata sambil meminimalkan paparan risiko. Pendekatan ini menyediakan cara terkontrol untuk menerapkan perubahan dengan kemampuan untuk memantau kinerja dan memutar kembali dengan cepat jika masalah terdeteksi.

Sumber daya yang terlibat dalam penyebaran kenari

Berikut ini adalah sumber daya yang terlibat dalam penerapan burung kenari Amazon ECS:

  • Pergeseran lalu lintas - Proses yang digunakan Amazon ECS untuk menggeser lalu lintas produksi. Untuk penerapan burung kenari Amazon ECS, lalu lintas digeser dalam dua fase: pertama ke persentase kenari, kemudian untuk menyelesaikan penerapan.

  • Persentase Canary - Persentase lalu lintas yang dialihkan ke versi baru selama periode evaluasi.

  • Waktu memanggang kenari - Durasi untuk memantau versi kenari sebelum melanjutkan dengan penerapan penuh.

  • Waktu pemanggangan penyebaran - Waktu, dalam hitungan menit, Amazon ECS menunggu setelah mengalihkan semua lalu lintas produksi ke revisi layanan baru, sebelum menghentikan revisi layanan lama. Ini adalah durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan setelah lalu lintas produksi bergeser.

  • Tahap siklus hidup - Serangkaian peristiwa dalam operasi penerapan, seperti “setelah pergeseran lalu lintas produksi”.

  • Kait siklus hidup - Fungsi Lambda atau titik jeda pada tahap siklus hidup tertentu. Lambda hook memanggil fungsi Lambda yang telah Anda tetapkan untuk menjalankan kode khusus. Jeda kait menjeda penerapan dan tunggu Anda menelep ContinueServiceDeployment on untuk melanjutkan.

  • Kelompok target - Sumber daya Elastic Load Balancing yang digunakan untuk merutekan permintaan ke satu atau lebih target terdaftar (misalnya, instans EC2). Bila Anda membuat pendengar, Anda menentukan grup target untuk tindakan default-nya. Lalu lintas diteruskan ke grup target yang ditentukan dalam aturan pendengar.

  • Listener - Sumber daya Elastic Load Balancing yang memeriksa permintaan koneksi menggunakan protokol dan port yang Anda konfigurasikan. Aturan yang Anda tetapkan untuk pendengar menentukan bagaimana Amazon ECS merutekan permintaan ke target terdaftarnya.

  • Aturan - Sumber daya Elastic Load Balancing yang terkait dengan pendengar. Aturan mendefinisikan bagaimana permintaan dialihkan dan terdiri dari tindakan, kondisi, dan prioritas.

Pertimbangan-pertimbangan

Pertimbangkan hal berikut saat memilih jenis penerapan:

  • Penggunaan sumber daya: Penerapan Canary menjalankan set tugas asli dan kenari secara bersamaan selama periode evaluasi, meningkatkan penggunaan sumber daya.

  • Volume lalu lintas: Pastikan persentase kenari menghasilkan lalu lintas yang cukup untuk validasi yang berarti dari versi baru.

  • Kompleksitas pemantauan: Penerapan Canary memerlukan pemantauan dan perbandingan metrik antara dua versi yang berbeda secara bersamaan.

  • Kecepatan rollback: Penerapan Canary memungkinkan rollback cepat dengan mengalihkan lalu lintas kembali ke set tugas asli.

  • Mitigasi risiko: Penerapan Canary memberikan mitigasi risiko yang sangat baik dengan membatasi paparan pada sebagian kecil pengguna.

  • Durasi penerapan: Penerapan Canary mencakup periode evaluasi yang memperpanjang waktu penerapan secara keseluruhan tetapi memberikan peluang validasi.

Cara kerja penerapan kenari

Proses penyebaran Amazon ECS Canary mengikuti pendekatan terstruktur dengan enam fase berbeda yang memastikan pembaruan aplikasi yang aman dan andal. Setiap fase melayani tujuan tertentu dalam memvalidasi dan transisi aplikasi Anda dari versi saat ini (biru) ke versi baru (hijau).

  1. Tahap Persiapan: Ciptakan lingkungan hijau di samping lingkungan biru yang ada.

  2. Tahap Penyebaran: Menyebarkan revisi layanan baru ke lingkungan hijau. Amazon ECS meluncurkan tugas baru menggunakan revisi layanan yang diperbarui sementara lingkungan biru terus melayani lalu lintas produksi.

  3. Tahap Pengujian: Validasi lingkungan hijau menggunakan perutean lalu lintas uji. Application Load Balancer mengarahkan permintaan pengujian ke lingkungan hijau sementara lalu lintas produksi tetap berwarna biru.

  4. Fase Pergeseran Lalu Lintas Canary: Pergeseran persentase lalu lintas yang dikonfigurasi ke revisi layanan hijau baru selama fase kenari, diikuti dengan mengalihkan 100,0% lalu lintas ke revisi layanan Hijau

  5. Fase Pemantauan: Memantau kesehatan aplikasi, metrik kinerja, dan status alarm selama periode waktu memanggang. Operasi rollback dimulai ketika masalah terdeteksi.

  6. Tahap Penyelesaian: Selesaikan penyebaran dengan mengakhiri lingkungan biru.

Fase pergeseran lalu lintas kenari mengikuti langkah-langkah ini:

  • Awal - Penerapan dimulai dengan 100% lalu lintas yang dialihkan ke revisi layanan biru (saat ini). Revisi layanan hijau (baru) menerima lalu lintas uji tetapi tidak ada lalu lintas produksi pada awalnya.

  • Pergeseran lalu lintas Canary - Ini adalah strategi pergeseran lalu lintas dua langkah.

    • Langkah 1:10,0% ke hijau, 90,0% ke biru

    • Langkah 2:100,0% ke hijau, 0,0% ke biru

  • Waktu memanggang Canary - Menunggu durasi yang dapat dikonfigurasi (waktu memanggang burung kenari) setelah pergeseran lalu lintas kenari untuk memungkinkan pemantauan dan validasi kinerja revisi baru dengan peningkatan beban lalu lintas.

  • Pengait siklus hidup - Fungsi Lambda opsional atau kait jeda dapat dikonfigurasi pada berbagai tahap siklus hidup selama penerapan untuk melakukan validasi otomatis, pemantauan, atau logika khusus. Kait dikonfigurasi untuk PRODUCTION_TRAFFIC_SHIFT atau PRE_PRODUCTION_TRAFFIC_SHIFT dipanggil pada setiap langkah pergeseran lalu lintas produksi.

Tahap siklus hidup penerapan

Proses penyebaran burung kenari berlangsung melalui tahapan siklus hidup yang berbeda, masing-masing dengan tanggung jawab khusus dan pos pemeriksaan validasi. Memahami tahapan ini membantu Anda memantau kemajuan penerapan dan memecahkan masalah secara efektif.

Setiap tahap siklus hidup dapat berlangsung hingga 24 jam dan sebagai tambahan setiap langkah pergeseran lalu lintas di PRODUCTION_TRAFFIC_SHIFT dapat berlangsung hingga 24 jam. Kami menyarankan agar nilainya tetap di bawah tanda 24 jam. Ini karena proses asinkron membutuhkan waktu untuk memicu kait. Sistem habis waktu, gagal penerapan, dan kemudian memulai rollback setelah tahap mencapai 24 jam.

CloudFormation penerapan memiliki batasan waktu tunggu tambahan. Sementara batas tahap 24 jam tetap berlaku, CloudFormation memberlakukan batas 36 jam pada seluruh penyebaran. CloudFormation gagal penerapan, dan kemudian memulai rollback jika proses tidak selesai dalam waktu 36 jam.

Untuk kait jeda, Anda dapat mengonfigurasi batas waktu hingga 20.160 menit (14 hari). Waktu tunggu penerapan keseluruhan adalah 30 hari.

Tahapan siklus hidup
Tahapan siklus hidup Deskripsi Dukungan kait siklus hidup
REKONCILE_SERVICE Tahap ini hanya terjadi ketika Anda memulai penyebaran layanan baru dengan lebih dari 1 revisi layanan dalam status AKTIF. Ya
PRE_SCALE_UP Revisi layanan hijau belum dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. Ya
SCALE_UP Waktu ketika revisi layanan hijau dinaikkan hingga 100% dan meluncurkan tugas baru. Revisi layanan hijau tidak melayani lalu lintas apa pun pada saat ini. Tidak
POST_SCALE_UP Revisi layanan hijau telah dimulai. Revisi layanan biru menangani 100% lalu lintas produksi. Tidak ada lalu lintas uji. Ya
PERGESERAN PERGESERAN LALU LINTAS Revisi layanan biru dan hijau sedang berjalan. Revisi layanan biru menangani 100% lalu lintas produksi. Revisi layanan hijau bermigrasi dari 0% menjadi 100% dari lalu lintas uji. Ya (hanya Lambda)
POS_TEST_TRAFIC_SHIFT Pergeseran lalu lintas uji selesai. Revisi layanan hijau menangani 100% lalu lintas uji. Ya
PERGESERAN LALU LINTAS SEBELUM PRODUKSI Terjadi sebelum setiap langkah pergeseran lalu lintas produksi. Untuk kenari, ini terjadi sebelum pergeseran lalu lintas kenari dan sebelum pergeseran lalu lintas yang tersisa. Ya
PERGESERAN LALU LINTAS PRODUKSI Lalu lintas produksi Canary dialihkan ke revisi hijau dan kait siklus hidup dipanggil dengan batas waktu 24 jam. Langkah kedua menggeser lalu lintas produksi yang tersisa ke revisi hijau. Ya (hanya Lambda)
PERGESERAN LALU LINTAS PASCA PRODUKSI Pergeseran lalu lintas produksi selesai. Ya
WAKTU MEMANGGANG Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan. Tidak
BERSIH_UP Revisi layanan biru telah sepenuhnya dikurangi menjadi 0 tugas yang sedang berjalan. Revisi layanan hijau sekarang menjadi revisi layanan produksi setelah tahap ini. Tidak

Parameter konfigurasi

Penerapan Canary memerlukan parameter konfigurasi berikut:

  • Persentase Canary - Persentase lalu lintas untuk mengarahkan ke revisi layanan baru selama fase kenari. Hal ini memungkinkan pengujian dengan subset lalu lintas produksi yang terkontrol.

  • Waktu memanggang Canary - Durasi menunggu selama fase kenari sebelum mengalihkan lalu lintas yang tersisa ke revisi layanan baru. Ini memberikan waktu untuk memantau dan memvalidasi versi baru.

Manajemen lalu lintas

Penerapan Canary menggunakan kelompok target penyeimbang beban untuk mengelola distribusi lalu lintas:

  • Kelompok target asli - Berisi tugas dari versi stabil saat ini dan menerima sebagian besar lalu lintas.

  • Kelompok target Canary - Berisi tugas dari versi baru dan menerima persentase kecil lalu lintas untuk pengujian.

  • Perutean tertimbang - Penyeimbang beban menggunakan aturan routing tertimbang untuk mendistribusikan lalu lintas antara kelompok target berdasarkan persentase kenari yang dikonfigurasi.

Pemantauan dan validasi

Penyebaran kenari yang efektif bergantung pada pemantauan komprehensif:

  • Pemeriksaan kesehatan - Kedua set tugas harus lulus pemeriksaan kesehatan sebelum menerima lalu lintas.

  • Perbandingan metrik - Bandingkan indikator kinerja utama antara versi asli dan canary, seperti waktu respons, tingkat kesalahan, dan throughput.

  • Rollback otomatis - Konfigurasikan CloudWatch alarm untuk secara otomatis memicu rollback jika versi kenari menunjukkan kinerja yang menurun.

  • Validasi manual - Gunakan periode evaluasi untuk meninjau log, metrik, dan umpan balik pengguna secara manual sebelum melanjutkan.

Praktik terbaik untuk penerapan burung kenari

Ikuti praktik terbaik ini untuk memastikan penerapan kenari yang berhasil dengan layanan.

Pilih persentase lalu lintas yang sesuai

Pertimbangkan faktor-faktor ini saat memilih persentase lalu lintas kenari:

  • Mulai dari yang kecil - Mulailah dengan 5-10% lalu lintas untuk meminimalkan dampak jika masalah terjadi.

  • Pertimbangkan kekritisan aplikasi - Gunakan persentase yang lebih kecil untuk aplikasi kritis misi dan persentase yang lebih besar untuk layanan yang kurang penting.

  • Akun volume lalu lintas - Pastikan persentase kenari menghasilkan lalu lintas yang cukup untuk validasi yang berarti.

Tetapkan periode evaluasi yang sesuai

Konfigurasikan periode evaluasi berdasarkan pertimbangan berikut:

  • Berikan waktu yang cukup - Tetapkan periode evaluasi yang cukup lama untuk menangkap data kinerja yang berarti, biasanya 10-30 menit.

  • Pertimbangkan pola lalu lintas - Perhitungkan pola lalu lintas aplikasi Anda dan waktu penggunaan puncak.

  • Keseimbangan kecepatan dan keamanan - Periode evaluasi yang lebih lama memberikan lebih banyak data tetapi kecepatan penerapan lambat.

Menerapkan pemantauan komprehensif

Siapkan pemantauan untuk melacak kinerja penerapan burung kenari:

  • Metrik utama - Pantau waktu respons, tingkat kesalahan, throughput, dan pemanfaatan sumber daya untuk kedua set tugas.

  • Alarm-based rollback - Konfigurasikan CloudWatch alarm untuk secara otomatis memicu rollback saat metrik melebihi ambang batas.

  • Analisis komparatif - Siapkan dasbor untuk membandingkan metrik antara versi asli dan canary secara berdampingan.

  • Metrik bisnis - Sertakan metrik khusus bisnis seperti tingkat konversi atau keterlibatan pengguna di samping metrik teknis.

Rencanakan strategi rollback

Bersiaplah untuk skenario rollback potensial dengan strategi ini:

  • Rollback otomatis - Konfigurasikan pemicu rollback otomatis berdasarkan pemeriksaan kesehatan dan metrik kinerja.

  • Prosedur rollback manual - Dokumentasikan prosedur yang jelas untuk rollback manual saat pemicu otomatis tidak menangkap semua masalah.

  • Pengujian rollback - Uji prosedur rollback secara teratur untuk memastikannya bekerja dengan benar saat diperlukan.

Validasi secara menyeluruh sebelum penerapan

Pastikan validasi menyeluruh sebelum melanjutkan dengan penerapan kenari:

  • Pre-deployment pengujian - Uji perubahan secara menyeluruh di lingkungan pementasan sebelum penerapan kenari.

  • Konfigurasi pemeriksaan kesehatan - Pastikan pemeriksaan kesehatan secara akurat mencerminkan kesiapan dan fungsionalitas aplikasi.

  • Validasi ketergantungan - Verifikasi bahwa versi baru kompatibel dengan layanan hilir dan hulu.

  • Konsistensi data - Pastikan perubahan skema database dan migrasi data kompatibel ke belakang.

Mengkoordinasikan keterlibatan tim

Pastikan koordinasi tim yang efektif selama penerapan burung kenari:

  • Jendela penerapan - Jadwalkan penerapan burung kenari selama jam kerja saat tim tersedia untuk memantau dan merespons.

  • Saluran komunikasi - Menetapkan saluran komunikasi yang jelas untuk status penyebaran dan eskalasi masalah.

  • Penugasan peran - Tentukan peran dan tanggung jawab untuk pemantauan, pengambilan keputusan, dan eksekusi rollback.