API gateway vs. penyeimbang beban: Perbedaan utama dan contoh penggunaan

Ilustrasinya adalah terminal bandara dan pengontrol lalu lintas udara. API gateway bertindak seperti terminal, di mana penumpang (permintaan klien) tiba, check-in, melewati keamanan, dan diarahkan ke gerbang yang benar berdasarkan tujuan mereka. Sebagai titik masuk frontend, API gateway menangani autentikasi, perutean permintaan, terjemahan protokol, dan aturan apa pun yang menentukan ke mana permintaan harus diteruskan. Gateway ini memutuskan cara merutekan lalu lintas dan permintaan rute ke layanan backend yang sesuai.

Di sisi lain, penyeimbang beban adalah pengontrol lalu lintas udara yang memastikan bahwa begitu pesawat siap lepas landas, ia diberi landasan pacu dengan cara yang menjaga lalu lintas mengalir dengan aman dan efisien. Penyeimbang beban mendistribusikan beban kerja masuk ke beberapa server backend atau instance dari layanan yang sama (dalam banyak kasus).

Bekerja bersama, API gateway menentukan apa yang dibutuhkan setiap permintaan dan layanan mana yang harus menanganinya, sementara penyeimbang beban memastikan bahwa instance layanan yang dipilih tidak kelebihan beban. Memahami peran yang berbeda ini dan bagaimana mereka saling melengkapi membantu tim merancang arsitektur yang lebih jelas, lebih tangguh, lebih dapat diskalakan, dan lebih selaras dengan kebutuhan spesifik sistem mereka.

Untuk memahami bagaimana API Gateway dan penyeimbang beban beroperasi dalam sistem terdistribusi, ada baiknya memulai dengan model Interkoneksi Sistem Terbuka (OSI). Model OSI adalah kerangka kerja konseptual tujuh lapis yang menstandarkan bagaimana komunikasi jaringan diatur, dari transmisi fisik bit hingga interaksi aplikasi yang menghasilkan respons yang dapat dibaca pengguna.

Dalam model ini, API Gateway terutama beroperasi di Lapisan 7 (aplikasi), di mana mereka menafsirkan permintaan dan menerapkan kebijakan yang sesuai aplikasi seperti autentikasi, aturan perutean, dan terjemahan protokol. Penyeimbang beban dapat berfungsi di Lapisan 4 (transpor), membuat keputusan berdasarkan IP dan port, atau di Lapisan 7 untuk membuat pilihan perutean berbasis konten.

Dengan mempertimbangkan peran ini, API Gateway dan penyeimbang beban bertanggung jawab atas berbagai tahapan mengarahkan dan memproses lalu lintas masuk saat lalu lintas berpindah dari klien ke layanan backend. Mengingat bahwa peran ini dapat tumpang tindih dalam beberapa cara, terutama karena gateway yang lebih baru menambahkan fitur perutean atau distribusi ringan, komponen-komponen ini muncul dalam pengaturan arsitektur yang berbeda tergantung pada bagaimana sistem terstruktur. Beberapa pola umum meliputi:

Bersama-sama: Dalam arsitektur layanan mikro, API gateway dapat mengautentikasi permintaan, menerapkan batas kecepatan dan menormalkan protokol, kemudian meneruskan ke titik akhir layanan yang dilapisi oleh penyeimbang beban—sering kali penyeimbang beban aplikasi (ALB)—yang memilih server yang tersedia. Dalam pengaturan ini, gateway menyediakan kontrol yang sesuai aplikasi dan penyeimbang mengoptimalkan distribusi dan ketahanan. Layanan mikro hanyalah salah satu contoh; API gateway juga digunakan dalam lingkungan monolitik, multi-aplikasi, dan hybrid untuk mengoordinasikan lalu lintas API masuk di berbagai sistem. 

Secara independen (hanya penyeimbang beban): Untuk tingkatan web stateless yang seragam, tim dapat menempatkan penyeimbang beban langsung di depan server yang identik untuk mengurangi lonjakan dan mempertahankan waktu aktif tanpa orkestrasi tingkat API. Selain itu, penyeimbang beban dapat beroperasi secara independen dalam skenario seperti mengarahkan lalu lintas di antara replika database read-only, memindahkan beban di seluruh titik akhir yang terdistribusi secara geografis, menangani failover dalam penerapan multi-wilayah, atau menyeimbangkan permintaan ke sistem lama yang tidak memerlukan logika tingkat gateway. 

Secara independen (hanya gateway): Di beberapa platform terkelola, gateway dapat menghentikan lalu lintas klien, menerapkan kebijakan, dan mengarahkan langsung ke layanan yang sudah memiliki distribusi bawaan, sehingga mempertahankan kebijakan dan manfaat pengalaman pengembang tanpa lapisan penyeimbang terpisah.

Banyak gateway modern juga dapat melakukan fungsi penyeimbangan beban tertentu, seperti perutean tertimbang, round-robin, atau berbasis jalur, tetapi tim mungkin masih menempatkan penyeimbang beban khusus Lapisan 4 di depan untuk penanganan koneksi atau untuk menghilangkan masalah lapisan transportasi throughput tinggi.

Observabilitas pada lapisan API gateway biasanya mencakup metrik seperti volume permintaan, distribusi latensi, evaluasi kebijakan, hasil autentikasi, dan tingkat kesalahan yang terkait dengan rute atau konsumen tertentu. Gateway juga menghasilkan log terperinci yang menangkap karakteristik payload permintaan dan respons, transformasi header, dan peristiwa keamanan seperti validasi token yang gagal atau pemicu batas laju. Pelacakan pada lapisan ini sering menyoroti bagaimana permintaan bergerak melalui aturan perutean, transformasi, agregasi respons, dan panggilan backend, sehingga lebih mudah untuk mendiagnosis masalah dalam perilaku API atau penegakan kontrak.

Penyeimbang beban menampilkan metrik operasional yang berfokus pada jumlah koneksi, pemeriksaan kesehatan target, waktu respons dari instance backend, dan perilaku algoritma perutean, bersama dengan log yang menunjukkan keputusan distribusi lalu lintas dan peristiwa failover. Ketika dianalisis bersama, insight tingkat gateway dan penyeimbang beban mengungkapkan pandangan yang lebih lengkap tentang bagaimana lalu lintas mengalir melalui sistem dan di mana masalah mungkin muncul.

Sebagai contoh, latensi gateway yang tinggi dapat berkorelasi dengan ketidakseimbangan hilir atau target yang gagal pada lapisan penyeimbang beban, sementara lonjakan kegagalan penyeimbang beban dapat ditelusuri kembali ke permintaan yang tidak normal atau sangat berat yang hanya terlihat di gateway.

Organisasi dengan praktik pengamatan yang matang sering menggabungkan sudut pandang ini ke dalam dasbor terpadu atau pelacakan yang memungkinkan tim mengikuti permintaan dari boundary klien melalui logika perutean dan ke dalam perilaku instance backend. Tim yang kurang matang mungkin memeriksa setiap lapisan secara terpisah, tetapi bahkan korelasi log dan metrik yang sederhana dapat membantu membedakan antara masalah terkait kebijakan di gateway dan masalah kinerja atau ketersediaan di balik penyeimbang beban. Seiring waktu, mengintegrasikan insight di kedua lapisan dapat menghasilkan pemecahan masalah yang lebih cepat, batas kepemilikan yang lebih jelas, dan pemahaman yang lebih dalam tentang kesehatan sistem secara keseluruhan.

Dari posisi mereka di dalam platform, tanggung jawab API gateway dan penyeimbang beban bergeser di Kubernetes, antara pengontrol API Ingress atau Gateway dan penyeimbangan beban layanan, berdasarkan cara lalu lintas diterima, diamankan, dan didistribusikan.

• Cara objek Ingress, API Gateway, atau Service memetakan ke peran tipe gateway dan penyeimbang beban
  
  Di Kubernetes, Ingress dan API Gateway yang lebih baru menyediakan bidang kontrol seperti gateway untuk perutean host atau path, konfigurasi transport layer security (TLS), dan lampiran kebijakan di lapisan aplikasi. Banyak pengontrol yang mengimplementasikan spesifikasi ini (Envoy/nginx/Traefik) adalah proyek sumber terbuka yang banyak digunakan yang juga beroperasi sebagai proxy terbalik, menangani pembentukan lalu lintas dan transformasi sebelum merutekan ke klaster.
  
  Komponen-komponen ini sering berfungsi sebagai hop berdasarkan aplikasi pertama untuk aplikasi web, yang melakukan tugas-tugas seperti validasi JSON Web Token (JWT) atau penulisan ulang header sebelum meneruskan permintaan ke layanan backend.
  
  Sebaliknya, Kubernetes Service tipe LoadBalancer (atau NodePort yang dipasangkan dengan penyeimbang beban eksternal) mengekspos beban kerja dan mendistribusikan lalu lintas di seluruh pod yang mendasarinya (melalui node). Lapisan ini berperilaku mirip dengan penyeimbang beban tradisional yang digunakan di depan armada server web, memilih instance yang sehat untuk memastikan pengiriman yang lancar. Dalam praktiknya, gateway memutuskan bagaimana permintaan harus ditangani dan backend mana yang akan ditargetkan, sementara Layanan dan mesin penyeimbang beban memutuskan instance mana yang benar-benar menerima permintaan.

• Variasi pengontrol dan platform
  
  Pembagian tanggung jawab yang tepat tergantung pada pengontrol dan platform. Pengontrol dari satu vendor mungkin menggabungkan lebih banyak fitur gateway (autentikasi, integrasi Firewall Aplikasi Web (WAF)), sementara yang lain mendelegasikannya ke sidecar atau layanan eksternal. Beberapa lingkungan sangat bergantung pada API gateway untuk pernyataan kebijakan, sementara yang lain masih menggunakan Ingress klasik plus definisi sumber daya khusus untuk perutean lanjutan.
  
  Penyedia cloud juga dapat menanamkan kemampuan penyeimbangan beban eksklusif seperti VIP anycast global (IP tunggal yang diiklankan secara global yang mengarahkan pengguna ke titik akhir sehat terdekat) dan failover lintas zona (secara otomatis mengalihkan lalu lintas ke zona ketersediaan lain ketika salah satu titik akhir menjadi terganggu) yang bergeser di tempat tugas tertentu berada. Akibatnya, tim harus mengantisipasi perbedaan dalam platform konfigurasi, fitur yang didukung, dan observabilitas di seluruh distribusi.

• Di mana mesh berakhir dan edge dimulai
  
  Mesh layanan membantu mengelola bagaimana layanan berkomunikasi satu sama lain di dalam suatu sistem. Mesh memastikan koneksi tersebut aman, andal, dan disesuaikan secara otomatis ketika masalah terjadi. Gateway ingress atau edge sering berada di boundary mesh, bertindak seperti proxy terbalik yang sesuai kebijakan, menghentikan koneksi eksternal dan menerapkan aturan tingkat API sebelum menyerahkan lalu lintas ke layanan internal. Di hulu proses itu, penyeimbang beban atau pengelola lalu lintas global dapat mendistribusikan koneksi masuk ke seluruh instance gateway atau wilayah geografis.
  
  
• Bagaimana organisasi mengatur gateway dan penyeimbang beban
  
  Beberapa organisasi menyimpan API Gateway di luar mesh untuk meminimalkan ketergantungan, sementara yang lain menjalankan API Gateway sesuai jaringan sehingga kebijakan dan telemetri menjadi seragam. Tim tertentu menempatkan penyeimbang beban global di depan beberapa gateway regional untuk perutean geografis; tim lainnya mengandalkan pengarahan berbasis DNS atau logika edge CDN. Komposisi yang benar sering mencerminkan kendala seperti anggaran latensi, zona kepatuhan, dan keahlian operasional daripada praktik terbaik universal. Yang penting adalah bahwa setiap lapisan memiliki tujuan yang jelas dan tidak menduplikasi tanggung jawab di seluruh tumpukan.

• Pertimbangan untuk gRPC, WebSockets, aliran peristiwa, atau koneksi berumur panjang
  
  gRPC (HTTP/2) cenderung bekerja lebih efektif ketika komponen sistem yang menanganinya dapat sepenuhnya mendukung gaya komunikasi berbasis streaming, yang berarti mereka mempertahankan manfaat HTTP/2, menafsirkan metadata dengan benar dan menghindari peralihan kembali ke protokol yang lebih lama. Oleh karena itu, gateway atau penyeimbang beban L7 harus dapat mengelola lalu lintas streaming dengan lancar, termasuk menangani batas waktu dan tekanan ketika data mengalir dengan cepat di kedua arah.
  
  WebSockets dan peristiwa yang dikirim server sering melibatkan koneksi berumur panjang, yang dapat sensitif terhadap faktor-faktor seperti batas waktu idle, perilaku tetap hidup, dan batas koneksi, terutama ketika banyak klien tetap terhubung untuk waktu yang lama. Dalam kasus aliran peristiwa, seperti API streaming gaya Kafka atau kustom, sistem dapat mengalami muatan besar, kegagalan intermiten, atau kebutuhan untuk menguras dan merehidrasi koneksi selama penerapan.
  
  Di seluruh jenis protokol yang sudah berjalan lama ini, pilihan arsitektur seputar autentikasi, pengamatan, dan bagaimana koneksi tetap melekat pada backend tertentu dapat memengaruhi keandalan secara keseluruhan dan membantu menghindari masalah seperti pemblokiran head of line atau gangguan sesi yang tidak terduga.

Tim sering menemukan API gateway dan penyeimbang beban pada berbagai tahap perjalanan arsitektur mereka, tetapi urutannya tidak tetap. Komponen mana yang muncul pertama kali (dan apakah keduanya diperlukan) tergantung pada apa yang dibutuhkan aplikasi atau lingkungan TI yang lebih luas, serta prinsip-prinsip desain sistem yang memandu lingkungan itu.

Penyeimbang beban mungkin digunakan lebih awal untuk meningkatkan ketersediaan dan mendistribusikan lalu lintas di beberapa instance server, tetapi tidak menyediakan otorisasi, penegakan kebijakan, atau kontrol tingkat API yang diperlukan beberapa sistem sejak awal. Kebutuhan ini biasanya termasuk dalam cakupan manajemen API yang lebih luas .

Demikian juga, beberapa lingkungan menggunakan API gateway terlebih dahulu karena kebutuhan awal berpusat pada autentikasi, perutean permintaan, batas tarif, atau mengelola katalog API yang berkembang. Ketika lalu lintas tumbuh dan sistem berkembang, baik ekspansi itu terjadi dalam satu aplikasi atau di banyak aplikasi di perusahaan, API gateway sering menjadi lebih penting.

Gateway menyediakan lapisan terstruktur untuk mengelola bagaimana API diakses, diamankan, dan diatur. Di beberapa organisasi, gateway berfungsi sebagai “pintu depan” terpadu untuk berbagai aplikasi internal dan eksternal, sementara di organisasi yang lain gateway mungkin berfungsi sebagai lapisan perutean dan kebijakan untuk layanan mikro dalam satu produk.

Singkatnya, ketika lalu lintas API meningkat dan lingkungan TI menjadi lebih kompleks, API gateway dan penyeimbang beban memainkan peran yang lebih penting. Fungsi penting mereka meningkat karena keduanya mengatasi dimensi skala, keandalan, keamanan, dan kejelasan operasional yang berbeda.