10 Pola Desain API Resilience Umum dengan API Gateway
November 1, 2023
Ketahanan API adalah tentang membangun API yang kuat yang dapat menghadapi berbagai tantangan, memastikan bahwa mereka terus berfungsi secara efektif. API Gateways memainkan peran kunci dalam hal ini, bertindak sebagai titik masuk untuk permintaan eksternal dan mengelola komunikasi antara berbagai layanan dengan mempertimbangkan pola ketahanan API yang umum. Salah satu API Gateway open-source populer, Apache APISIX, menyediakan berbagai fitur untuk meningkatkan ketahanan dan kekokohan API. Dalam artikel ini, kita akan menjelajahi 10 pola desain ketahanan API yang umum dan bagaimana mereka dapat diimplementasikan menggunakan APISIX.
Berikut adalah daftar dari 10 pola ketahanan API:
- Pembatasan laju (Rate limiting).
- Percobaan ulang (Retry).
- Batas waktu (Timeout).
- Cadangan (Fallback).
- Cache.
- Redundansi.
- Pemeriksaan kesehatan (Health checks).
- Pemutus sirkuit (Circuit breaker).
- Bulkhead.
- Suntikan kesalahan (Fault injection).
Apa itu Ketahanan API?
Ketahanan API mengacu pada kemampuan API untuk secara konsisten dan andal menjalankan fungsinya yang dimaksud, bahkan dalam menghadapi kesalahan, lalu lintas tinggi, atau kondisi tak terduga. Ini bukan tentang menghindari kegagalan tetapi menerima fakta bahwa kegagalan akan terjadi dan meresponsnya dengan cara yang menghindari downtime atau kehilangan data. Tujuan ketahanan adalah mengembalikan aplikasi ke keadaan berfungsi penuh setelah kegagalan. API yang tangguh dibangun untuk menangani kegagalan dengan elegan, baik kegagalan tersebut berasal dari dalam API itu sendiri, dari layanan dependen, atau karena faktor eksternal seperti masalah jaringan atau latensi, ketidakcocokan versi API, dan masalah lain yang mungkin timbul karena perubahan lingkungan atau perilaku pengguna yang tak terduga.
Mengapa Ketahanan API di API Gateway?
Banyak kerangka kerja pengembangan perangkat lunak yang ada mencakup serangkaian praktik dan pola yang dirancang untuk memastikan bahwa API tetap tersedia, responsif, dan akurat. Namun, mengimplementasikan ketahanan API di tingkat API Gateway, daripada di layanan individu atau di tempat lain dalam sistem, menawarkan beberapa keuntungan strategis.
1. Kontrol terpusat: API Gateway berfungsi sebagai titik masuk terpusat untuk semua permintaan API, memberikan kesempatan unik untuk mengelola dan menegakkan pola ketahanan di semua layanan secara terpadu. Sentralisasi ini menyederhanakan implementasi dan pemeliharaan fitur ketahanan.
2. Konsistensi: Dengan menangani ketahanan di API Gateway, Anda memastikan pendekatan yang konsisten dalam menangani kegagalan, pembatasan laju, batas waktu, dan strategi ketahanan lainnya di semua layanan. Konsistensi ini sangat penting untuk mempertahankan perilaku sistem yang andal dan dapat diprediksi.
3. Mengurangi kompleksitas: Mengimplementasikan fitur ketahanan di setiap layanan mikro dapat menyebabkan upaya yang berulang dan meningkatkan kompleksitas. API Gateway mengabstraksi masalah ini, memungkinkan pengembang layanan untuk fokus pada logika bisnis daripada menangani ketahanan.
4. Pemanfaatan sumber daya yang lebih baik: API Gateway dapat mengelola sumber daya secara efisien dan mendistribusikan lalu lintas, memastikan bahwa tidak ada layanan tunggal yang kewalahan. Penyeimbangan beban ini berkontribusi pada ketahanan keseluruhan sistem.
5. Pemantauan dan pencatatan yang lebih mudah: Memiliki satu titik di mana semua lalu lintas API mengalir memudahkan untuk memantau kesehatan layanan Anda dan mencatat masalah apa pun. Pandangan terpusat ini sangat berharga untuk mengidentifikasi dan merespons masalah dengan cepat.
6. Keamanan yang disederhanakan: Tindakan keamanan seperti autentikasi, otorisasi, dan enkripsi dapat diterapkan secara konsisten di API Gateway, memastikan bahwa semua layanan dilindungi tanpa perlu konfigurasi yang berlebihan.
7. Peningkatan kinerja: API Gateway dapat mengimplementasikan caching dan agregasi respons, mengurangi jumlah panggilan ke layanan backend dan meningkatkan kinerja keseluruhan sistem.
8. Degradasi yang elegan: Dalam kasus kegagalan layanan, API Gateway dapat mengarahkan ulang lalu lintas atau memberikan respons cadangan, memastikan bahwa sistem mengalami degradasi dengan elegan dan terus menyediakan fungsionalitas.
9. Pemulihan yang lebih cepat: Sifat terpusat dari API Gateway memungkinkan implementasi perbaikan dan pembaruan yang lebih cepat, memastikan bahwa sistem dapat segera dipulihkan ke fungsionalitas penuh setelah kegagalan.
10. Interaksi klien yang disederhanakan: Klien hanya perlu berinteraksi dengan API Gateway, yang menyediakan antarmuka yang konsisten dan andal, mengabstraksi kompleksitas layanan mikro yang mendasar.
Dari sudut pandang pengembangan, pendekatan API Gateway juga mengurangi waktu untuk mengimplementasikan pola ketahanan yang umum digunakan. Mari kita temukan setiap pola dalam contoh komunikasi API antara layanan dalam aplikasi konferensi tipikal dan memahami cara mengaktifkannya.
Postingan ini lebih fokus pada bagian teoritis dan menyediakan referensi ke dokumentasi yang relevan. Pengembang dapat mengimplementasikan pola ini dengan memeriksa setiap tautan dan melalui panduan yang disediakan. Dengan APISIX, dimungkinkan untuk mengonfigurasi pola desain ini menggunakan Admin API, file YAML statis, atau APISIX Dashboard.
1. Pembatasan Laju (Rate Limiting)
Seperti namanya, Pembatasan Laju mengontrol jumlah permintaan yang dapat dibuat oleh klien dalam periode waktu tertentu. APISIX menawarkan plugin limit-req untuk mengonfigurasi pembatasan laju. Plugin ini memungkinkan Anda untuk mendefinisikan aturan berdasarkan properti permintaan individu (terlalu banyak dari pengguna tertentu, aplikasi klien, atau lokasi) untuk membatasi permintaan, memastikan bahwa API Anda tidak kewalahan oleh terlalu banyak permintaan.
Kebijakan pembatasan laju juga dapat digunakan untuk membatasi akses ke pengguna yang tidak sah. Periksa panduan untuk melihat cara menggunakan plugin untuk pembatasan laju.
2. Percobaan Ulang (Retry)
Pola Percobaan Ulang melibatkan percobaan ulang otomatis permintaan API jika gagal. Dengan APISIX, Anda dapat mengonfigurasi mekanisme percobaan ulang untuk Upstream object untuk menentukan jumlah percobaan ulang dan kondisi di mana percobaan ulang harus dilakukan.
Dengan mengonfigurasi upstream dengan properti percobaan ulang, APISIX mengirimkan permintaan percobaan ulang otomatis ke layanan backend Attendee jika permintaan sebelumnya mengalami timeout atau gagal karena masalah jaringan.
3. Batas Waktu (Timeout)
Menetapkan batas waktu memastikan bahwa permintaan tidak menggantung tanpa batas jika layanan backend tidak responsif. APISIX memungkinkan Anda untuk mengonfigurasi batas waktu untuk API Anda dalam konfigurasi Upstream object yang sama, memastikan bahwa permintaan dihentikan jika membutuhkan waktu terlalu lama untuk merespons.
Jika layanan attendee merespons dengan lambat, APISIX dapat menerapkan pola fail-fast dan merespons permintaan aplikasi klien dengan cepat untuk meningkatkan responsivitas sistem secara keseluruhan.
4. Cadangan (Fallback)
Pola Cadangan memberikan respons default ketika layanan tidak tersedia. APISIX memungkinkan Anda untuk menentukan prioritas upstream ketika endpoint utama gagal, API Gateway dapat mengarahkan ulang lalu lintas ke layanan sekunder atau mengembalikan respons yang telah ditentukan menggunakan plugin response-rewrite dalam kasus kegagalan layanan seperti HTTP 500.
Atau Anda dapat menggunakan plugin proxy-cache untuk menyimpan respons dalam cache dan menyajikannya ketika backend down. Misalnya, aplikasi seluler menampilkan daftar peserta konferensi yang di-cache ketika layanan attendee down.
5. Cache
Menyimpan respons dalam cache dapat secara signifikan mengurangi beban pada layanan backend Anda. APISIX menawarkan plugin proxy-cache yang memungkinkan Anda untuk menyimpan respons dalam cache dan menyajikannya langsung dari API Gateway, mengurangi latensi dan meningkatkan kinerja.
Periksa tutorial Cache API responses untuk mempelajari cara menggunakan plugin proxy-cache.
6. Redundansi
Setiap API Gateway menyediakan fitur umum seperti Load Balancing yang mendistribusikan permintaan API yang masuk ke beberapa layanan backend (node atau instance). Memiliki instance redundan membuat sistem lebih kuat terhadap peristiwa yang tidak teratur. APISIX mendukung berbagai algoritma untuk load balancing seperti round-robin, least connections, dan consistent hashing.
Dalam kasus layanan Attendee, Anda dapat memulai dua instance dan jika server A down, permintaan dapat dilayani oleh server kedua.
7. Pemeriksaan Kesehatan (Health checks)
Pemeriksaan kesehatan adalah mekanisme yang menentukan apakah layanan upstream sehat atau tidak berdasarkan responsivitasnya. APISIX mengidentifikasi apakah layanan tersedia atau tidak dengan menggunakan upstream active health checks. Dengan pemeriksaan kesehatan yang diaktifkan, APISIX hanya akan meneruskan permintaan ke layanan upstream yang dianggap sehat, dan tidak meneruskan permintaan ke layanan yang dianggap tidak sehat.
Untuk memeriksa kesehatan API secara berkala, APISIX memerlukan jalur HTTP dari endpoint kesehatan layanan upstream. Jadi, Anda perlu menambahkan endpoint /health terlebih dahulu untuk layanan attendee.
8. Pemutus Sirkuit (Circuit breaker)
Pola Pemutus Sirkuit mencegah sistem melakukan panggilan ke layanan yang kemungkinan besar akan gagal, sehingga melindungi sistem dari kegagalan berantai. APISIX menyediakan dua opsi untuk mengimplementasikan fungsionalitas pemutus sirkuit: Menggunakan plugin api-breaker dalam konfigurasi Route atau mengaktifkan upstream passive health checks. Kedua cara ini menangani kegagalan dan mencegah layanan upstream dari upaya percobaan ulang yang konstan jika layanan gagal atau berkinerja lambat.
APISIX memantau jumlah kegagalan terbaru yang terjadi dan menggunakan informasi ini untuk memutuskan apakah akan mengizinkan operasi untuk dilanjutkan, atau hanya mengembalikan pengecualian segera.
9. Bulkhead
Pola Bulkhead mengisolasi elemen dalam aplikasi, memastikan bahwa jika satu bagian sistem gagal atau mengalami beban berat, bagian lain dari sistem terus berfungsi. Untuk memastikan bahwa lalu lintas berat atau masalah dalam operasi baca dari layanan Attendee tidak memengaruhi ketersediaan dan kinerja operasi tulis ke layanan Attendee, Anda dapat mengimplementasikan pola Bulkhead menggunakan APISIX.
Anda membuat endpoint rute terpisah di API Gateway untuk dua node upstream sehingga semua permintaan tulis diteruskan ke Layanan A dan semua permintaan baca ke Layanan B.
10. Pengujian Chaos (Chaos testing)
Pengujian Chaos dapat membantu memastikan bahwa API tangguh dalam lingkungan produksi. Dengan menggunakan ini, Anda dapat menilai dan memperkuat ketahanan aplikasi atau API layanan mikro Anda terhadap berbagai jenis kegagalan, meningkatkan keandalan. Metode ini memungkinkan untuk memperkenalkan penundaan secara sengaja dan menghentikan permintaan dengan kode kesalahan yang ditentukan, memfasilitasi simulasi berbagai skenario buruk termasuk gangguan layanan, permintaan layanan yang berlebihan, penundaan jaringan yang signifikan, dan segmentasi jaringan.
Plugin Fault Injection APISIX juga menawarkan mekanisme yang sama untuk mensimulasikan berbagai skenario kegagalan seperti kesalahan atau penundaan dalam layanan Attendee untuk menguji bagaimana aplikasi klien bereaksi terhadapnya.
Kesimpulan
Dalam posting blog ini, kami mengulas 10 pola desain ketahanan API yang umum, menunjukkan cara mengimplementasikannya secara efektif menggunakan APISIX. Dengan memusatkan strategi ketahanan di tingkat API Gateway, organisasi dapat mencapai manajemen lalu lintas API dan penanganan kesalahan yang konsisten, disederhanakan, dan efisien.