Menerapkan Fallback dengan API Gateway

Bobur Umurzokov

Bobur Umurzokov

November 10, 2023

Technology

Ketahanan API adalah kemampuan sebuah API untuk gagal dengan cepat atau memastikan bahwa API tersebut tetap berfungsi setelah mengalami kegagalan ketika menghadapi kesalahan, lalu lintas tinggi, atau kegagalan sistem sebagian. Ini melibatkan penerapan pola desain ketahanan API umum seperti percobaan ulang, batas waktu, pemutus sirkuit, failover, dan fallback. Fallback menggunakan API Gateway adalah rencana cadangan untuk sebuah API - ketika layanan API utama gagal, API Gateway dapat mengalihkan lalu lintas ke layanan sekunder atau mengembalikan respons yang telah ditentukan. Dalam artikel ini, kita akan mengeksplorasi tantangan dengan teknik fallback yang ada dan cara mengimplementasikannya secara efisien menggunakan APISIX API Gateway.

Fallback di APISIX Gateway

Mengimplementasikan Fallback dengan APISIX

Untuk mengimplementasikan mekanisme fallback dengan APISIX, Anda dapat menggunakan fitur bawaan prioritas upstream atau menggunakan plugin response-rewrite untuk mengembalikan respons yang telah ditentukan ketika panggilan layanan gagal. Berikut adalah contoh langkah demi langkah tentang cara menyiapkan kedua metode fallback tersebut.

Prasyarat

Panduan ini mengasumsikan bahwa alat-alat berikut telah diinstal secara lokal:

  • Sebelum memulai, ada baiknya untuk memiliki pemahaman dasar tentang APISIX. Keakraban dengan API gateway, dan konsep-konsep kuncinya seperti rute, upstream, Admin API, plugin, dan protokol HTTP juga akan bermanfaat.
  • Docker digunakan untuk menginstal etcd dan APISIX yang dikontainerisasi.
  • Instal cURL untuk mengirim permintaan ke layanan untuk validasi.

Memulai Proyek Docker APISIX

Proyek ini memanfaatkan file konfigurasi Docker Compose yang telah ditentukan sebelumnya untuk menyiapkan, menerapkan, dan menjalankan APISIX, etcd, Prometheus, dan layanan lainnya dengan satu perintah. Pertama, klon repositori apisix-docker di GitHub, buka di editor favorit Anda, navigasikan ke folder example, dan mulai proyek dengan menjalankan perintah docker compose up di terminal dari folder root proyek.

Saat Anda memulai proyek, Docker akan mengunduh semua gambar yang diperlukan untuk menjalankannya. Docker juga akan menjalankan dua layanan backend contoh web1 dan web2. Anda dapat melihat daftar lengkap layanan di file docker-compose.yaml.

Fallback dengan Prioritas Upstream APISIX Diaktifkan

Anda dapat menyiapkan setiap node upstream dengan tingkat prioritas tertentu untuk diaktifkan. Ketika endpoint node dengan prioritas lebih tinggi gagal, API Gateway dapat mengalihkan lalu lintas ke node sekunder dengan prioritas lebih rendah. Prioritas default untuk semua node adalah 0, node dengan prioritas negatif dapat dikonfigurasi sebagai cadangan.

Fallback dengan prioritas upstream APISIX diaktifkan

Buat rute ke dua layanan dan konfigurasikan atribut prioritas untuk setiap node layanan upstream:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "upstream":{
      "nodes":[
         {
            "host":"web1",
            "port":80,
            "weight":1,
            "priority":0
         },
         {
            "host":"web2",
            "port":80,
            "weight":1,
            "priority":-1
         }
      ]
   }
}'
  • methods: Ini menentukan metode HTTP yang akan cocok dengan rute ini. Dalam kasus ini, diatur untuk mencocokkan permintaan GET.
  • uri: Ini adalah jalur yang akan dicocokkan oleh rute. Jadi, setiap permintaan GET ke /get akan ditangani oleh rute ini.
  • nodes: Ini adalah array dari server backend. Setiap objek dalam array mewakili server dengan host, port, dan weight. weight digunakan untuk load balancing; dalam kasus ini, kedua server memiliki bobot 1, yang biasanya berarti mereka akan berbagi lalu lintas secara merata.
  • priority: Ini adalah konfigurasi tambahan untuk dua node (web1, web2). Bidang priority digunakan untuk menentukan urutan pemilihan node. Node dengan prioritas lebih rendah (angka negatif yang lebih tinggi) akan digunakan hanya jika semua node dengan prioritas lebih tinggi (angka negatif yang lebih rendah atau angka positif) tidak tersedia.

Verifikasi apakah Anda hanya mendapatkan respons dari layanan web1 ketika Anda mengirim permintaan ke rute:

curl "http://127.0.0.1:9080/get"

Anda akan melihat respons yang mirip dengan berikut:

hello web1

Ini berarti web1 telah dieksekusi terlebih dahulu karena berfungsi. Sekarang hentikan kontainer layanan web1 untuk memverifikasi apakah APISIX fallback ke layanan web2.

docker container stop example-web1-1

Sekarang jika Anda mengirim permintaan lagi ke rute, Anda akan mendapatkan respons dari layanan fallback yang telah kami tentukan.

curl "http://127.0.0.1:9080/get"
hello web2

Secara default, dibutuhkan 60 detik sementara permintaan pertama kali menuju ke layanan satu dan fallback ke layanan dua jika tidak tersedia. Anda juga dapat mengubah waktu ini dengan mengatur atribut timeout dari objek Upstream. Strategi fallback lainnya bisa dilakukan selama rilis. Jika versi baru API bermasalah, Anda dapat mengarahkan lalu lintas ke versi lama yang sedang standby menggunakan fitur traffic split APISIX. Fallback ke versi sebelumnya jika versi baru memiliki masalah. Metode fallback ini juga bekerja baik dengan pemeriksaan kesehatan Upstream.

Fallback dengan Plugin Response Rewrite APISIX

Plugin response-rewrite APISIX memungkinkan Anda untuk memodifikasi kode status respons, body, dan header sebelum mengembalikannya ke klien. Ini bisa sangat berguna untuk mengimplementasikan mekanisme fallback dengan memberikan respons default ketika layanan upstream gagal.

Fallback dengan plugin response rewrite APISIX

Jika Anda mengikuti pendekatan pertama, jalankan kembali kontainer layanan web1 di Docker:

docker container start example-web1-1

Untuk menggunakan plugin response-rewrite untuk fallback, Anda perlu mengkonfigurasikannya dalam rute. Berikut adalah contoh cara mengaktifkan plugin menggunakan perintah curl:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "plugins":{
      "response-rewrite":{
         "status_code":200,
         "body":"{\"message\":\"This is a fallback response when the service is unavailable\"}",
         "vars":[
            [
               "status",
               "==",
               503
            ]
         ]
      }
   },
   "upstream":{
      "nodes":{
         "web1:80":1
      }
   }
}'

Dalam contoh di atas, kami mendefinisikan satu layanan backend (web1:80) di mana lalu lintas harus diarahkan ketika rute ini cocok. Jika layanan upstream (web1:80) merespons dengan status 503 Service Unavailable, plugin response-rewrite akan memodifikasi respons untuk memiliki status 200 OK dengan body JSON kustom. Ini secara efektif menciptakan respons fallback ketika layanan upstream tidak tersedia.

"vars": [["status", "==", 503]]: Kondisi ini memberi tahu plugin untuk menerapkan penulisan ulang hanya ketika kode status asli dari respons adalah 503 Service Unavailable.

Sekarang jika Anda mengirim permintaan ke rute, Anda akan mendapatkan respons yang dimodifikasi:

curl "http://127.0.0.1:9080/get"

{"message":"This is a fallback response when the service is unavailable"}

Tantangan dalam Mengimplementasikan Mekanisme Fallback

Fallback adalah komponen kritis dari desain sistem yang tangguh. Namun, mereka dapat menimbulkan lebih banyak masalah ketika diimplementasikan dengan tidak benar. Ketika membahas strategi fallback, tantangan yang dihadapi dapat berbeda antara lingkungan mesin tunggal dan sistem terdistribusi. Mari kita tinjau untuk memahaminya dengan contoh dan belajar cara menghindarinya menggunakan APISIX.

Kesulitan dalam Menguji Logika Fallback

Sulit untuk mensimulasikan kondisi kegagalan aplikasi seperti kegagalan database dalam konteks mesin tunggal. Menguji strategi fallback dalam sistem terdistribusi bahkan menjadi lebih kompleks karena melibatkan banyak mesin dan layanan, sehingga sulit untuk mereplikasi semua mode kegagalan yang mungkin terjadi. Misalnya, sebuah API di server lokal memiliki fallback ke respons yang di-cache ketika database tidak dapat diakses. Menguji skenario ini memerlukan simulasi downtime database, yang mungkin tidak termasuk dalam pengujian reguler, sehingga kode fallback tidak diuji di bawah beban produksi yang sebenarnya.

APISIX dapat dikonfigurasi untuk mengarahkan lalu lintas untuk mensimulasikan berbagai skenario, termasuk kondisi fallback. Ini memungkinkan pengujian logika fallback yang lebih realistis dalam kondisi terkontrol, memastikan bahwa layanan fallback dapat menangani lalu lintas produksi.

Fallback itu sendiri bisa gagal

Jika solusi fallback tidak sekuat yang diharapkan, itu mungkin gagal di bawah beban yang meningkat ketika dipanggil, menyebabkan kegagalan berantai. Selain itu, fallback ke layanan yang kurang efisien dapat meningkatkan waktu respons dan beban, berpotensi menyebabkan perlambatan atau gangguan sistem secara keseluruhan. Misalnya, sebuah API mungkin memiliki fallback untuk menulis log ke sistem file lokal ketika layanan logging jarak jauh tidak tersedia. Ini dapat menyebabkan kinerja yang lebih lambat karena operasi I/O file yang sinkron.

Dengan APISIX, Anda dapat memprioritaskan lalu lintas untuk memastikan bahwa permintaan kritis diproses terlebih dahulu. Ini dapat mencegah layanan fallback menjadi kewalahan dan memperburuk kinerja sistem.

Fallback memiliki risiko operasional

Mengimplementasikan fallback mungkin memperkenalkan titik kegagalan baru, seperti database sekunder yang tidak disinkronkan dengan database utama, menyebabkan ketidakkonsistenan data.

Fitur observabilitas APISIX, seperti logging, metrik, dan tracing, dapat memantau kesehatan dan kinerja layanan utama dan fallback. Pemantauan real-time ini dapat membantu mengidentifikasi dan mengurangi risiko yang terkait dengan strategi fallback.

Fallback memiliki bug laten dan yang diperkuat

Jalur kode fallback mungkin mengandung bug yang tidak aktif yang hanya muncul di bawah kondisi kegagalan tertentu, yang mungkin tidak sering terjadi dan sulit diprediksi, sehingga mungkin tidak ditemukan selama berbulan-bulan atau bertahun-tahun. Misalnya, mekanisme fallback dalam API yang beralih ke metode autentikasi yang berbeda selama gangguan layanan identitas mungkin mengandung bug yang hanya muncul ketika fallback dipicu, yang bisa menjadi peristiwa langka.

APISIX mendukung pengujian A/B dan rilis canary yang berkelanjutan, memungkinkan tim untuk menguji jalur fallback dalam produksi dengan persentase kecil lalu lintas. Paparan berkelanjutan ini dapat membantu menemukan bug laten sebelum menjadi kritis.

Fallback jarang digunakan

Mekanisme fallback jarang digunakan, sehingga ketika dipicu, mereka mungkin tidak berfungsi seperti yang diharapkan karena kurangnya pengujian dan pembaruan rutin. Misalnya, sebuah API yang menyediakan data geografis mungkin memiliki fallback ke dataset statis ketika sumber data dinamis tidak tersedia. Jika fallback ini jarang digunakan, itu mungkin menyajikan informasi yang sudah ketinggalan zaman ketika diaktifkan karena tidak diperbarui atau diuji secara teratur.

Di sisi lain, APISIX memungkinkan konfigurasi routing dinamis dan dapat digunakan untuk secara berkala mengarahkan sebagian lalu lintas ke layanan fallback. Ini memastikan bahwa jalur fallback diuji secara teratur dan tetap siap digunakan.

Kesimpulan

Fallback adalah jaring pengaman ketika ada masalah dengan API. Dengan menggunakan konfigurasi upstream APISIX atau plugin response-rewrite, pengembang dapat memberikan respons yang bijaksana dan ramah pengguna yang menjaga sistem tetap berfungsi dan mempertahankan kepercayaan pengguna. Kuncinya adalah mengantisipasi titik kegagalan potensial dan merancang fallback yang memberikan pengalaman terbaik dalam keadaan tersebut.

Sumber daya terkait

Tags:
API Resilience
API Fallback