Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Rilis Canary
Dalam penerapan rilis kenari, total lalu lintas API dipisahkan secara acak menjadi rilis produksi dan rilis kenari dengan rasio yang telah dikonfigurasi sebelumnya. Biasanya, rilis kenari menerima sebagian kecil lalu lintas API dan rilis produksi memakan sisanya. Fitur API yang diperbarui hanya dapat dilihat oleh lalu lintas API melalui canary. Anda dapat menyesuaikan persentase lalu lintas kenari untuk mengoptimalkan cakupan atau kinerja pengujian.
Dengan menjaga lalu lintas kenari kecil dan pemilihan acak, sebagian besar pengguna tidak terpengaruh setiap saat oleh potensi bug di versi baru, dan tidak ada satu pengguna pun yang terpengaruh sepanjang waktu.
Setelah metrik pengujian memenuhi persyaratan Anda, Anda dapat mempromosikan rilis kenari ke rilis produksi dan menonaktifkan kenari dari penerapan. Ini membuat fitur-fitur baru tersedia dalam tahap produksi.
Topik
Penerapan rilis Canary di API Gateway
Di API Gateway, penerapan rilis kenari menggunakan tahap penerapan untuk rilis produksi versi dasar API, dan melampirkan ke tahap rilis kenari untuk versi baru, relatif terhadap versi dasar, API. Tahap ini dikaitkan dengan penyebaran awal dan kenari dengan penyebaran berikutnya. Pada awalnya, baik stage maupun canary menunjuk ke versi API yang sama. Kami menggunakan rilis panggung dan produksi secara bergantian dan menggunakan pelepasan kenari dan kenari secara bergantian di seluruh bagian ini.
Untuk menerapkan API dengan rilis kenari, Anda membuat penerapan rilis kenari dengan menambahkan pengaturan kenari ke tahap penerapan reguler. Pengaturan kenari menjelaskan rilis kenari yang mendasarinya dan tahapannya mewakili rilis produksi API dalam penerapan ini. Untuk menambahkan pengaturan kenari, atur canarySettings pada tahap penerapan dan tentukan yang berikut ini:
-
ID penerapan, awalnya identik dengan ID penerapan versi dasar yang ditetapkan di panggung.
-
Persentase lalu lintas API, antara 0,0 dan 100,0 inklusif, untuk rilis kenari.
-
Variabel tahap untuk rilis kenari yang dapat mengganti variabel tahap rilis produksi.
-
Penggunaan cache panggung untuk permintaan kenari, jika useStageCachedisetel dan caching API diaktifkan di atas panggung.
Setelah rilis kenari diaktifkan, tahap penerapan tidak dapat dikaitkan dengan penerapan rilis non-kenari lainnya hingga rilis kenari dinonaktifkan dan pengaturan kenari dihapus dari panggung.
Saat Anda mengaktifkan logging eksekusi API, rilis canary memiliki log dan metriknya sendiri yang dibuat untuk semua permintaan canary. Mereka dilaporkan ke grup CloudWatch log Log tahap produksi serta grup log CloudWatch Log khusus kenari. Hal yang sama berlaku untuk mengakses logging. Log khusus kenari yang terpisah sangat membantu untuk memvalidasi perubahan API baru dan memutuskan apakah akan menerima perubahan dan mempromosikan rilis kenari ke tahap produksi, atau untuk membuang perubahan dan mengembalikan rilis kenari dari tahap produksi.
Grup log eksekusi tahap produksi diberi nama API-Gateway-Execution-Logs/ dan grup log eksekusi rilis kenari diberi nama{rest-api-id}/{stage-name}API-Gateway-Execution-Logs/. Untuk akses logging, Anda harus membuat grup log baru atau memilih yang sudah ada. Nama grup log akses rilis kenari memiliki {rest-api-id}/{stage-name}/Canary/Canary akhiran yang ditambahkan ke nama grup log yang dipilih.
Rilis kenari dapat menggunakan cache panggung, jika diaktifkan, untuk menyimpan respons dan menggunakan entri yang di-cache untuk mengembalikan hasil ke permintaan kenari berikutnya, dalam periode pra-konfigurasi time-to-live (TTL).
Dalam penerapan rilis kenari, rilis produksi dan rilis canary API dapat dikaitkan dengan versi yang sama atau dengan versi yang berbeda. Ketika mereka dikaitkan dengan versi yang berbeda, respons untuk permintaan produksi dan kenari di-cache secara terpisah dan cache tahap mengembalikan hasil yang sesuai untuk permintaan produksi dan kenari. Ketika rilis produksi dan rilis kenari dikaitkan dengan penerapan yang sama, cache tahap menggunakan kunci cache tunggal untuk kedua jenis permintaan dan mengembalikan respons yang sama untuk permintaan yang sama dari rilis produksi dan rilis kenari.
