Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Siapkan penerapan rilis kenari API Gateway
Rilis Canary
Dalam penyebaran rilis kenari, total API lalu lintas dipisahkan secara acak menjadi rilis produksi dan rilis kenari dengan rasio yang telah dikonfigurasi sebelumnya. Biasanya, rilis kenari menerima persentase kecil API lalu lintas dan rilis produksi memakan sisanya. APIFitur yang diperbarui hanya terlihat oleh API lalu lintas melalui kenari. 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 Gateway API
Di API Gateway, penerapan rilis kenari menggunakan tahap penerapan untuk rilis produksi versi dasarAPI, dan melampirkan ke tahap rilis kenari untuk versi baru, relatif terhadap versi dasar, dari. API Tahap ini dikaitkan dengan penyebaran awal dan kenari dengan penyebaran berikutnya. Pada awalnya, baik panggung dan kenari menunjuk ke API versi yang sama. Kami menggunakan rilis panggung dan produksi secara bergantian dan menggunakan pelepasan kenari dan kenari secara bergantian di seluruh bagian ini.
Untuk menerapkan rilis API with a canary, Anda membuat penerapan rilis kenari dengan menambahkan pengaturan kenari ke tahap penerapan reguler. Pengaturan kenari menjelaskan pelepasan 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 API lalu lintas, antara 0,0 dan 100,0 inklusif, untuk rilis kenari.
-
Variabel tahap untuk rilis kenari yang dapat mengesampingkan variabel tahap rilis produksi.
-
Penggunaan cache panggung untuk permintaan kenari, jika useStageCachediatur dan API caching 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 pencatatan API eksekusi, rilis kenari memiliki log dan metriknya sendiri yang dihasilkan untuk semua permintaan kenari. 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 API perubahan baru dan memutuskan apakah akan menerima perubahan dan mempromosikan pelepasan kenari ke tahap produksi, atau untuk membuang perubahan dan mengembalikan pelepasan 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 () yang telah dikonfigurasi sebelumnya time-to-live. TTL
Dalam penerapan rilis kenari, rilis produksi dan rilis kenari 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.