Strategi Rilis API dengan API Gateway

Setelah Anda berhasil memisahkan deployment dan release dengan baik, langkah selanjutnya adalah memilih mekanisme untuk mengontrol rilis fitur secara bertahap. Penting untuk memilih strategi rilis yang memungkinkan Anda mengurangi risiko di lingkungan produksi. Karena tidak peduli seberapa banyak Anda menguji versi baru API sebelum rilis, uji sebenarnya terjadi ketika Anda akhirnya menempatkannya di depan pelanggan.

Kita dapat mengurangi risiko ini dengan melakukan pengujian atau eksperimen dengan sebagian kecil lalu lintas dan memverifikasi hasilnya. Ketika hasilnya berhasil, rilis ke semua lalu lintas akan dipicu. Strategi tertentu lebih cocok untuk skenario tertentu dan memerlukan tingkat layanan dan infrastruktur tambahan yang bervariasi. Dalam posting ini, kita akan menjelajahi 3 strategi rilis API populer yang menggunakan API Gateway saat ini.

Mengapa menggunakan API gateway dalam deployment API

Salah satu manfaat beralih ke arsitektur berbasis API adalah kita dapat melakukan iterasi dengan cepat dan menerapkan perubahan baru ke layanan kita. Kami juga memiliki konsep lalu lintas dan routing yang ditetapkan dengan API Gateway untuk bagian arsitektur yang dimodernisasi. API Gateway menyediakan tahapan yang memungkinkan Anda memiliki beberapa API yang di-deploy di belakang gateway yang sama dan mampu melakukan pembaruan di tempat tanpa downtime. Menggunakan API Gateway memungkinkan Anda memanfaatkan berbagai fitur manajemen API dari layanan tersebut, seperti autentikasi, pembatasan laju, observabilitas (metrik penting untuk API), multiple API versioning, dan manajemen deployment tahapan (mendeploy API dalam beberapa tahap seperti dev, test, stage, dan prod).

API Gateway open source (Apache APISIX dan Traefik), Service Mesh (Istio dan Linkerd) solusi mampu melakukan pemisahan lalu lintas dan mengimplementasikan fungsionalitas seperti Canary Release dan Blue-Green deployment. Dengan pengujian canary, Anda dapat melakukan pemeriksaan kritis terhadap rilis baru API dengan memilih hanya sebagian kecil dari basis pengguna Anda. Kami akan membahas canary release di bagian selanjutnya.

Canary release

Canary release memperkenalkan versi baru dari API dan mengalirkan persentase kecil lalu lintas ke canary. Dalam API gateway, pemisahan lalu lintas memungkinkan untuk secara bertahap menggeser atau memigrasi lalu lintas dari satu versi layanan target ke versi lainnya. Misalnya, versi baru, v1.1, dari suatu layanan dapat di-deploy bersamaan dengan versi asli, v1.0. Pergeseran lalu lintas memungkinkan Anda untuk melakukan pengujian canary atau merilis layanan baru Anda dengan awalnya hanya merutekan persentase kecil lalu lintas pengguna, misalnya 1%, ke v1.1, kemudian menggeser semua lalu lintas Anda ke layanan baru seiring waktu.

Ini memungkinkan Anda untuk memantau layanan baru, mencari masalah teknis, seperti peningkatan latensi atau tingkat kesalahan, dan mencari dampak bisnis yang diinginkan, seperti peningkatan indikator kinerja utama seperti rasio konversi pelanggan atau nilai rata-rata checkout belanja. Pemisahan lalu lintas memungkinkan Anda menjalankan pengujian A/B atau multivariat dengan membagi lalu lintas yang ditujukan untuk layanan target antara beberapa versi layanan. Misalnya, Anda dapat membagi lalu lintas 50/50 antara v1.0 dan v1.1 dari layanan target dan melihat mana yang berkinerja lebih baik dalam periode waktu tertentu. Pelajari lebih lanjut tentang fitur pemisahan lalu lintas di Apache APISIX Ingress Controller.

Jika sesuai, canary release adalah pilihan yang sangat baik, karena persentase lalu lintas yang terpapar ke canary sangat terkontrol. Komprominya adalah sistem harus memiliki pemantauan yang baik untuk dapat dengan cepat mengidentifikasi masalah dan melakukan rollback jika diperlukan (yang dapat diotomatisasi). Panduan ini menunjukkan cara menggunakan Apache APISIX dan Flagger untuk dengan cepat mengimplementasikan solusi canary release.

Traffic mirroring

Selain menggunakan pemisahan lalu lintas untuk menjalankan eksperimen, Anda juga dapat menggunakan traffic mirroring untuk menyalin atau menduplikasi lalu lintas dan mengirimkannya ke lokasi tambahan atau serangkaian lokasi. Seringkali dengan traffic mirroring, hasil dari permintaan yang diduplikasi tidak dikembalikan ke layanan pemanggil atau pengguna akhir. Sebaliknya, respons dievaluasi secara out-of-band untuk kebenaran, seperti membandingkan hasil yang dihasilkan oleh layanan yang direfaktor dan yang ada, atau serangkaian properti operasional diamati saat versi layanan baru menangani permintaan, seperti latensi respons atau CPU yang diperlukan.

Menggunakan traffic mirroring memungkinkan Anda untuk "dark release" layanan, di mana pengguna tidak mengetahui tentang rilis baru tetapi Anda dapat mengamati secara internal untuk efek yang diinginkan.

Mengimplementasikan traffic mirroring di tepi sistem telah menjadi semakin populer selama bertahun-tahun. APISIX menawarkan plugin proxy-mirror untuk mencerminkan permintaan klien. Ini menduplikasi lalu lintas online nyata ke layanan mirroring dan memungkinkan analisis spesifik dari lalu lintas online atau konten permintaan tanpa mengganggu layanan online.

Blue-Green

Blue-green biasanya diimplementasikan pada titik dalam arsitektur yang menggunakan router, gateway, atau load balancer, di belakangnya terdapat lingkungan blue lengkap dan lingkungan green. Lingkungan blue saat ini mewakili lingkungan live saat ini, dan lingkungan green mewakili versi berikutnya dari stack. Lingkungan green diperiksa sebelum beralih ke lalu lintas live, dan saat go live, lalu lintas dialihkan dari blue ke green. Lingkungan blue sekarang "off" tetapi jika masalah terdeteksi, rollback dapat dilakukan dengan cepat. Perubahan berikutnya akan beralih dari green ke blue, berosilasi dari rilis pertama seterusnya.

Blue-green bekerja dengan baik karena kesederhanaannya dan merupakan salah satu opsi deployment yang lebih baik untuk layanan yang terhubung. Ini juga lebih mudah untuk mengelola layanan yang persisten, meskipun Anda masih perlu berhati-hati dalam hal rollback. Ini juga memerlukan dua kali lipat jumlah sumber daya untuk dapat berjalan secara paralel dengan lingkungan yang saat ini aktif.

Manajemen lalu lintas dengan Argo Rollouts

Strategi yang dibahas menambah banyak nilai, tetapi rollout itu sendiri adalah tugas yang tidak ingin Anda kelola secara manual. Di sinilah alat seperti Argo Rollouts berharga untuk menunjukkan secara praktis beberapa masalah yang dibahas.

Menggunakan Argo, dimungkinkan untuk mendefinisikan Rollout CRD (Custom Resource Definition) yang mewakili strategi yang dapat Anda ambil untuk merilis canary baru dari API Anda. CRD memungkinkan Argo untuk memperluas Kubernetes API untuk mendukung perilaku rollout. CRD adalah pola populer dengan Kubernetes, dan mereka memungkinkan pengguna untuk berinteraksi dengan satu API dengan ekstensi untuk mendukung fitur yang berbeda.

Anda dapat menggunakan Apache APISIX dan Apache APISIX Ingress Controller untuk manajemen lalu lintas dengan Argo Rollouts. Panduan ini menunjukkan cara mengintegrasikan ApisixRoute dengan Argo Rollouts menggunakan