Apa Itu API Gateway, dan Mengapa Itu Penting?

Pengantar API

Apa itu API (Application Programming Interface)? API adalah cara standar untuk bertukar data antara berbagai aplikasi dan sistem. Banyak tim pengembangan mengadopsi pendekatan API-first di mana iterasi difokuskan pada API, mulai dari perancangan, implementasi, pengujian, pengamanan, penyebaran, pemecahan masalah, dan analisis API, yang merupakan manajemen siklus hidup penuh API (APIM).

Sebelum adanya API, tidak ada cara standar untuk bertukar data. Program komputer berkomunikasi satu sama lain menggunakan berbagai protokol, seperti FTP, FTPS, SFTP, HTTPS, dll. Kurangnya standar menciptakan biaya pengembangan yang tinggi dan risiko keamanan tersembunyi dalam berbagai dimensi: kontrol izin, manajemen data, pembatasan kecepatan, audit, dll. Ini adalah "Menara Babel" dalam dunia komputer. Untuk membangun produk yang cukup kompleks, kita harus menyelesaikan masalah yang disebabkan oleh sistem yang dikembangkan dengan bahasa dan skema penyimpanan data yang berbeda.

Munculnya API telah berhasil menyelesaikan masalah "Menara Babel". Pengembang hanya perlu fokus pada API yang diekspos oleh sistem lain dan tidak perlu memahami detail implementasi yang mendasarinya.

Koneksi dan transmisi data antara perangkat klien dan server untuk aplikasi seluler, game online, streaming video langsung, konferensi jarak jauh, dan perangkat IoT semuanya tidak terlepas dari API. API memainkan peran penting dalam komunikasi mereka.

Mengapa Menggunakan API Gateway?

API Gateway adalah komponen penting dalam manajemen siklus hidup penuh API. Ini bertanggung jawab untuk konfigurasi API, rilis, rollback versi, keamanan, dan penyeimbangan beban di lingkungan produksi. Selain itu, API gateway adalah pintu masuk semua lalu lintas klien, bertanggung jawab untuk merutekan permintaan API klien ke layanan upstream yang benar untuk diproses dan kemudian mengembalikan data yang dikembalikan ke pemohon asli sambil memastikan keamanan, keandalan, dan latensi rendah dari seluruh proses.

Ketika tidak banyak API di awal, API gateway biasanya adalah komponen virtual yang digabungkan oleh server web dan layanan upstream. Fungsi sederhana seperti routing, forwarding, reverse proxy, dan load balancing dilakukan oleh Apache, NGINX, dan beberapa komponen lainnya; fungsi lain seperti autentikasi dan pembatasan kecepatan bergantung pada layanan upstream.

Mengapa Anda membutuhkan API Gateway?

Namun, seiring dengan peningkatan jumlah API, para pengembang yang "malas" menemukan masalah serius. Di berbagai bagian layanan upstream, fungsi yang sama seperti autentikasi, pembatasan kecepatan, logging, dan beberapa fungsi lainnya dikodekan berulang kali. Ini tidak hanya membuang-buang sumber daya; tetapi juga mimpi buruk dalam manajemen kode. Ketika satu bagian kode dimodifikasi atau ditingkatkan, kode di tempat lain juga perlu diperbarui. Bagaimana kita menyelesaikan masalah ini? Para pengembang yang cerdas dengan cepat menemukan solusi: abstrak (ambil) fungsi umum dan letakkan ke dalam satu komponen. Kami mengambil kode yang tidak terkait dengan logika bisnis dari layanan upstream, dan meningkatkan komponen Apache dan NGINX. Inilah evolusi API gateway generasi pertama.

Arah evolusi API gateway adalah untuk menyematkan sebanyak mungkin fungsi yang tidak terkait dengan bisnis. Untuk mempercepat iterasi produk, pengembang front-end dan back-end menuntut semakin banyak dari API gateway, tidak hanya terbatas pada fungsi tradisional seperti routing, forwarding, reverse proxy, dan load balancing, tetapi juga menuntut fungsi untuk observabilitas seperti gRPC dan GraphQL.

Peran API gateway

Untuk membuat API gateway lebih fleksibel dan efisien, pengembang API gateway melakukan banyak inovasi pada struktur dasar, seperti:

• Plugin Fungsi. Semakin banyak fungsi yang disematkan pada API gateway, bagaimana kita memisahkan setiap fungsi untuk memudahkan pengembangan? Mekanisme plugin seperti Lego akan menjadi solusi sempurna. API gateway utama semuanya menggunakan plugin. Di Apache APISIX, ini disebut "plugin". Di Envoy, ini disebut "filter". Plugin membebaskan pengembang gateway dari detail implementasi, dan lebih sedikit sumber daya pengembangan yang dibutuhkan untuk mengimplementasikan fungsi baru.
• Pemisahan Data Plane dan Control Plane. Pada API gateway generasi pertama, Data Plane dan Control Plane diimplementasikan dalam proses komputer yang sama. Ini lebih mudah bagi pengguna untuk menyebarkan dan menggunakan, tetapi menciptakan risiko keamanan yang signifikan. Data Plane menyediakan layanan langsung ke dunia luar. Jika peretas meretas Data Plane dari luar, mereka bisa mendapatkan izin kontrol dan data Control Plane (seperti sertifikat SSL), yang berpotensi menyebabkan kerusakan yang lebih dahsyat. Oleh karena itu, sebagian besar API gateway open-source sekarang menyebarkan DP dan CP secara terpisah dan menggunakan database relasional atau etcd untuk manajemen dan sinkronisasi konfigurasi.

Mengambil Apache APISIX sebagai contoh, diagram arsitektur berikut menggambarkan inovasi di atas:

Tantangan dari Cloud-Native

Perubahan teknologi terbesar dalam IT selama dekade terakhir adalah cloud-native. Docker, yang lahir pada tahun 2013, membuka tirai cloud-native. Sejak itu, bare metal dan mesin virtual telah digantikan oleh kontainer, dan arsitektur monolitik telah digantikan oleh microservices. Namun, cloud-native bukanlah revolusi teknologi yang sederhana. Kekuatan pendorong di baliknya berasal dari perkembangan pesat dan persaingan ketat produk Internet. Teknologi terkait cloud-native lahir pada waktu yang tepat dan dengan cepat menjadi populer dan menggantikan banyak arsitektur dan solusi teknis sebelumnya. Secara khusus, tantangan API gateway dalam cloud-native terutama berasal dari dua aspek berikut:

Monolitik ke Microservices

Setelah arsitektur microservice mendapatkan popularitas di kalangan pengembang, ini telah melepaskan dividen teknis yang besar. Microservices dapat ditingkatkan dan dirilis dengan kecepatan mereka sendiri tanpa khawatir tentang kopling dengan layanan lain. Iterasi produk menjadi gesit, dengan puluhan atau bahkan ratusan rilis per hari.

Namun, pengembangan microservices juga membawa beberapa efek samping, seperti:

• Jumlah API dan microservices telah berkembang dari puluhan menjadi ribuan atau bahkan puluhan ribu.
• Bagaimana kita dengan cepat menemukan API mana yang menyebabkan kesalahan?
• Bagaimana kita memastikan keamanan API?
• Bagaimana kita mencapai pemutusan layanan dan penurunan layanan?

API gateway tidak dapat menyelesaikan masalah keamanan, observabilitas, dan rilis canary sendiri. Ini perlu bekerja sama dengan banyak proyek open-source dan layanan SaaS lainnya seperti Prometheus, Zipkin, Skywalking, Datadog, Okta, dll., untuk memberikan solusi yang lebih baik bagi perusahaan.

Manajemen Dinamis dan Kluster

Tantangan pertama berasal dari ekosistem, sementara yang kedua berasal dari teknologi.

Dinamis

Popularitas kontainer dan Kubernetes telah membuat dinamika menjadi fitur standar dari semua komponen dasar cloud-native. Di lingkungan Kubernetes, kontainer terus-menerus dibuat dan dihancurkan, dan penskalaan elastis telah menjadi kebutuhan daripada pilihan.

Bayangkan sebuah skenario: sebuah perusahaan e-commerce menjalankan promosi, dan jutaan pengguna membanjiri dalam satu jam dan pergi setelah promosi selesai. Dalam skenario ini, perusahaan dengan arsitektur tradisional harus membeli sejumlah server fisik untuk menangani lalu lintas API pada saat puncak. Sebaliknya, perusahaan dengan arsitektur cloud-native dapat menggunakan sumber daya elastis di cloud publik kapan saja. Mereka dapat menyesuaikan skala jaringan, daya komputasi, database, dan sumber daya lainnya secara otomatis berdasarkan jumlah permintaan API.

Ada juga tantangan teknis yang terkait dengan penskalaan elastis kontainer:

• Layanan upstream sering mengubah alamat IP dan port.
• Pembaruan yang sering dari daftar izin dan daftar blokir IP.
• Deteksi dan penanganan pengecualian kesehatan layanan.
• Rilis reguler API.
• Ketepatan waktu pendaftaran dan penemuan layanan.
• Pembaruan panas dan rotasi otomatis sertifikat SSL.

Inti dari mengatasi tantangan teknis ini adalah dinamika.

API gateway generasi pertama yang diwakili oleh NGINX memiliki kemampuan dinamis yang lemah. Karena NGINX digerakkan oleh file konfigurasi statis lokal, setiap perubahan pada konfigurasi perlu memuat ulang layanan NGINX untuk berlaku, yang tidak dapat diterima oleh perusahaan di era cloud-native. Ini adalah titik sakit teknis pertama dari API gateway generasi pertama.

Manajemen Kluster

Titik sakit teknis kedua adalah manajemen kluster.

WPS, sebuah perusahaan perangkat lunak kantor SaaS di Cina, yang menyediakan perangkat lunak seperti Microsoft office 365. Mereka memiliki ratusan mesin fisik yang menjalankan Apache APISIX, hampir 10.000 CPU inti yang memproses permintaan API dari klien, dan memproses puluhan miliar API setiap hari.

Dalam lingkungan API gateway yang sangat besar ini, tidak mungkin bagi pengembang untuk memodifikasi konfigurasi setiap API gateway satu per satu dan kemudian memuat ulangnya. Sebaliknya, mereka menginginkan konsol terintegrasi untuk mengoperasikan seluruh kluster. Sayangnya, ketika API gateway generasi pertama lahir, tidak ada skala instans sebesar itu, sehingga pengembang API gateway generasi pertama tidak mempertimbangkan kebutuhan manajemen kluster.

API Gateway Generasi Berikutnya

Tantangan dan titik sakit di atas secara bertahap melahirkan API gateway generasi berikutnya.

Fitur API Gateway Generasi Berikutnya

Tidak seperti API gateway generasi pertama, komunitas open-source adalah kekuatan utama yang mendorong pengembangan API gateway generasi berikutnya di era cloud-native. Dengan kekuatan komunitas dan banyak kontributor open-source, API gateway ini memiliki kesempatan untuk membentuk siklus iterasi dan evolusi yang positif:

• Mampu mengumpulkan kebutuhan dan titik sakit pengembang dan pengguna dengan lebih cepat
• Mencoba menyelesaikan masalah ini dalam proyek open-source
• Proyek open-source menjadi lebih mudah digunakan, menarik lebih banyak pengembang

Dalam proses ini, API gateway generasi berikutnya melampaui posisi load balancing dan reverse proxy dari gateway tradisional dan mengambil lebih banyak tanggung jawab, seperti koneksi lalu lintas, penjadwalan, penyaringan, analisis, konversi protokol, tata kelola, dan integrasi (Lihat di bawah).

API Gateway mendukung pengembangan sekunder dengan biaya lebih rendah

Pada saat yang sama, memungkinkan pengembang untuk melakukan pengembangan kustom dengan biaya lebih rendah juga menjadi sorotan API gateway generasi berikutnya. Integrasi adalah salah satu fungsi penting dari API Gateway. Untuk downstream, ini adalah resolusi protokol dan konversi protokol, termasuk GraphQL, gRPC, Dubbo, dll.; untuk upstream, ini mengintegrasikan Okta, Keycloak, Datadog, dan Prometheus untuk layanan autentikasi dan observabilitas serta layanan sertifikasi, logging, audit, dan layanan internal perusahaan lainnya.

API gateway tidak dapat mencakup semua komponen proses integrasi. Oleh karena itu, tidak dapat dihindari bagi pengembang untuk melakukan pengembangan kustom melalui plugin untuk memenuhi kebutuhan bisnis mereka sendiri.

API gateway yang berbeda menyediakan bahasa pemrograman dan metode pengembangan yang berbeda untuk pengembangan kustom. Misalnya, Apache APISIX dan Kong keduanya dapat menggunakan Lua untuk menulis plugin asli, sementara Envoy menggunakan C++ untuk menulis plugin asli. Pada saat yang sama, Apache APISIX juga dapat menggunakan Go, Python, Node.js, Java, dan Wasm untuk mengembangkan plugin. Hampir semua pengembang menggunakan salah satu bahasa pemrograman utama ini.

Open source dan pengembangan kustom yang mudah adalah fitur terpenting dari API gateway generasi berikutnya. Mereka memberikan lebih banyak pilihan bagi pengembang. Sementara itu, pengembang dapat dengan percaya diri menggunakan API gateway di lingkungan multi-cloud atau hybrid cloud, tanpa khawatir terkunci oleh penyedia layanan cloud.

Contoh: API Gateway untuk Lalu Lintas Black Friday

Selanjutnya, mari kita jelaskan apa yang dilakukan API Gateway dengan contoh konkret.

Pada Black Friday, perusahaan e-commerce akan memiliki banyak promosi, dan volume permintaan API selama periode ini puluhan kali lebih tinggi dari biasanya. Pertama, mari kita lihat seperti apa arsitektur teknis jika tidak ada API Gateway:

Seperti yang dapat Anda lihat dari gambar di atas, fungsi autentikasi dan logging digandakan dalam layanan Order dan Payment. Layanan e-commerce umumnya terdiri dari ribuan layanan yang berbeda. Pada saat ini, banyak kode dan prosedur akan diulang.

Gambar berikut adalah diagram arsitektur setelah menambahkan API gateway:

Seperti yang dapat Anda lihat di atas, kami telah mengintegrasikan layanan umum di lapisan API gateway. Akibatnya, layanan back-end hanya perlu fokus pada bisnis mereka sendiri, memberikan lebih banyak kemungkinan untuk penskalaan elastis.

Ketika promosi dimulai, jutaan permintaan API dari klien membanjiri API gateway, dan layanan back-end perlu melakukan penskalaan elastis yang cepat. Untuk melindungi bisnis inti dari dampak lalu lintas yang tiba-tiba, kita perlu mengidentifikasi crawler jahat di API gateway dan menerapkan throttling, penurunan layanan, dan pemutusan layanan.

Kita juga dapat sementara menutup beberapa layanan, seperti evaluasi produk, pencarian pengiriman, dll. Namun, bisnis inti seperti informasi inventaris, pembelian, dan pembayaran tidak boleh gagal. Oleh karena itu, kita perlu mengelola layanan kontainer melalui K8s dan menghasilkan lebih banyak salinan layanan untuk mempertahankan operasinya yang tepat. Pada saat ini, API gateway perlu merutekan permintaan API klien ke layanan replika yang baru disalin dan secara otomatis menghapus layanan yang bermasalah, seperti yang ditunjukkan pada gambar berikut:

Ringkasan

Secara ringkas, API Gateway bukanlah middleware baru. Namun, ini semakin penting seiring dengan evolusi arsitektur teknis dan iterasi produk yang semakin cepat. Munculnya API gateway cloud-native generasi berikutnya menyelesaikan titik sakit pengguna perusahaan dalam hal manajemen kluster, dinamika, ekosistem, observabilitas, dan keamanan.

API Gateway tidak hanya dapat menangani lalu lintas API, tetapi juga lalu lintas dari Kubernetes Ingress dan service mesh, lebih memperpendek kurva belajar pengembang dan membantu perusahaan mengelola lalu lintas secara terintegrasi.

Hubungi kami untuk mempelajari lebih lanjut tentang Apache APISIX, API7 Enterprise Edition, dan produk API7 Cloud.