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 sebagian 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 kenari Amazon ECS, validasi revisi layanan baru dengan lalu lintas pengguna nyata sambil meminimalkan eksposur 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 penyebaran kenari Amazon ECS:

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

  • Persentase kenari - Persentase lalu lintas yang diarahkan ke versi baru selama periode evaluasi.

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

  • Waktu pemanggangan penyebaran - Waktu, dalam hitungan menit, Amazon ECS menunggu setelah mengalihkan semua lalu lintas produksi ke revisi layanan baru, sebelum mengakhiri 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 penyebaran, seperti “setelah pergeseran lalu lintas produksi”.

  • Lifecycle hook - Fungsi Lambda yang berjalan pada tahap siklus hidup tertentu. Anda dapat membuat fungsi yang memverifikasi penerapan.

  • Grup sasaran - Sumber daya ELB yang digunakan untuk merutekan permintaan ke satu atau lebih target terdaftar (misalnya, EC2 contoh). 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 ELB yang memeriksa permintaan koneksi menggunakan protokol dan port yang Anda konfigurasikan. Aturan yang Anda tetapkan untuk pendengar menentukan cara Amazon ECS merutekan permintaan ke target terdaftarnya.

  • Aturan - Sumber daya ELB yang terkait dengan pendengar. Aturan mendefinisikan bagaimana permintaan dirutekan 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 canary 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 eksposur ke sebagian kecil pengguna.

  • Durasi penerapan: Penerapan Canary mencakup periode evaluasi yang memperpanjang waktu penerapan 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 mentransisikan aplikasi Anda dari versi saat ini (biru) ke versi baru (hijau).

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

  2. Fase Deployment: 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. Fase Pengujian: Validasi lingkungan hijau menggunakan perutean lalu lintas uji. Application Load Balancer mengarahkan permintaan pengujian ke lingkungan hijau sementara lalu lintas produksi tetap biru.

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

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

  6. Fase Penyelesaian: Selesaikan penerapan dengan mengakhiri lingkungan biru.

Fase pergeseran lalu lintas kenari mengikuti langkah-langkah ini:

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

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

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

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

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

  • Lifecycle hooks - Fungsi Lambda opsional dapat dijalankan pada berbagai tahap siklus hidup selama penerapan untuk melakukan validasi otomatis, pemantauan, atau logika kustom. Fungsi Lambda atau kait siklus hidup yang dikonfigurasi untuk PRODUCTION_TRAFFIC_SHIFT akan dipanggil pada setiap langkah pergeseran lalu lintas produksi.

Tahapan siklus hidup penerapan

Proses penyebaran 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 bertahan hingga 24 jam dan sebagai tambahan setiap langkah pergeseran lalu lintas di PRODUCTION_TRAFFIC_SHIFT dapat bertahan hingga 24 jam. Kami menyarankan agar nilainya tetap di bawah tanda 24 jam. Ini karena proses asinkron membutuhkan waktu untuk memicu kait. Waktu sistem habis, gagal penerapan, dan kemudian memulai rollback setelah tahap mencapai 24 jam.

CloudFormation penerapan memiliki batasan batas waktu 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.

Tahapan siklus hidup
Tahapan siklus hidup Deskripsi Dukungan kait siklus hidup
RECONCILE_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
SKALA_UP Waktu ketika revisi layanan hijau menskalakan 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
TEST_TRAFFIC_SHIFT Revisi layanan biru dan hijau sedang berjalan. Revisi layanan biru menangani 100% lalu lintas produksi. Revisi layanan hijau bermigrasi dari 0% ke 100% lalu lintas pengujian. Ya
POST_TEST_TRAFFIC_SHIFT Pergeseran lalu lintas uji selesai. Revisi layanan hijau menangani 100% lalu lintas pengujian. Ya
PRODUCTION_TRAFFIC_SHIFT Lalu lintas produksi kenari diarahkan 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
POST_PRODUCTION_TRAFFIC_SHIFT Pergeseran lalu lintas produksi selesai. Ya
BAKE_WAKTU Durasi ketika revisi layanan biru dan hijau berjalan secara bersamaan. Tidak
MEMBERSIHKAN_UP Revisi layanan biru telah sepenuhnya diperkecil 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 kenari - Persentase lalu lintas untuk rute ke revisi layanan baru selama fase kenari. Hal ini memungkinkan pengujian dengan subset terkontrol dari lalu lintas produksi.

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

Manajemen lalu lintas

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

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

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

  • Perutean tertimbang - Penyeimbang beban menggunakan aturan perutean tertimbang untuk mendistribusikan lalu lintas antar grup 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 versi kenari, seperti waktu respons, tingkat kesalahan, dan throughput.

  • Rollback otomatis - Konfigurasikan CloudWatch alarm untuk memicu rollback secara otomatis 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 penyebaran kenari

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

Pilih persentase lalu lintas yang sesuai

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

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

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

  • Akun untuk 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 ini:

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

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

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

Melaksanakan pemantauan komprehensif

Siapkan pemantauan untuk melacak kinerja penerapan kenari:

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

  • Rollback berbasis alarm - Konfigurasikan CloudWatch alarm untuk memicu rollback secara otomatis ketika metrik melebihi ambang batas.

  • Analisis komparatif - Siapkan dasbor untuk membandingkan metrik antara versi asli dan kenari. side-by-side

  • Metrik bisnis - Sertakan metrik khusus bisnis seperti rasio 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 memastikan mereka bekerja dengan benar saat diperlukan.

Validasi secara menyeluruh sebelum penerapan

Pastikan validasi menyeluruh sebelum melanjutkan dengan penerapan canary:

  • Pengujian pra-penerapan - Uji perubahan lingkungan pementasan secara menyeluruh sebelum penerapan canary.

  • 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 penyebaran kenari:

  • Jendela penyebaran - Jadwalkan penyebaran kenari selama jam kerja ketika tim tersedia untuk memantau dan merespons.

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

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