Materi ini membahas dua komponen infrastruktur penting dalam arsitektur microservices: API Gateway (single entry point untuk trafik eksternal ke public API) dan Service Mesh (infrastruktur komunikasi antar service internal). Kedua topik ini sangat relevan dengan capaian mendesain layanan terdistribusi & microservices, karena keduanya adalah building block wajib saat sebuah sistem dipecah menjadi banyak service kecil.
Isu dalam Pengelolaan API
Ketika sebuah sistem terdiri dari banyak API/service, muncul dua isu utama yang perlu dikelola secara terpusat:
- Traffic management — bagaimana mengatur volume, arah, dan prioritas trafik yang masuk ke API.
- Security — bagaimana memastikan hanya pihak yang berhak yang bisa mengakses API, dan melindungi API dari penyalahgunaan.
Kedua isu ini adalah alasan utama mengapa API Gateway dan Service Mesh dibutuhkan sebagai infrastruktur, bukan diimplementasikan berulang-ulang di setiap service.
API Gateway
API Gateway menyediakan façade/proxy untuk API yang di-ekspose ke publik. Secara konsep ia adalah sebuah reverse proxy: client tidak lagi memanggil service internal secara langsung, melainkan memanggil gateway, yang kemudian meneruskan request ke internal API yang sesuai.
Manfaat utama API Gateway sebagai façade:
- Mengurangi coupling antara eksternal dan internal — perubahan pada implementasi/struktur internal API tidak perlu mengubah kontrak API publik yang dilihat client.
- Menyederhanakan akses — menggabungkan beberapa API internal menjadi 1 API call bagi client, termasuk melakukan orkestrasi concurrent call ke beberapa backend API sekaligus.
- Proteksi API dari overuse & abuse, serta threat detection & mitigation.
- Observability — memahami bagaimana API digunakan/diakses (siapa memanggil apa, seberapa sering, dsb).
- API Lifecycle Management — mengelola API sebagai produk: pengaturan versi API, pemisahan environment dev/staging vs prod.
- Monetisasi API — account management, billing, payment bagi konsumen API berbayar.
Fungsi-Fungsi API Gateway
Selain sebagai façade, API Gateway memiliki sejumlah fungsi teknis spesifik dalam menangani request:
| Fungsi | Penjelasan |
|---|---|
| Routing | Meneruskan request ke internal API yang bersesuaian. Memungkinkan perubahan pada internal API tanpa perlu mengubah public API. |
| Composition | Implementasi internal API mungkin hanya menyediakan akses low-level; API Gateway dapat mengomposisikan beberapa internal API menjadi satu higher-level API bagi client. |
| Translation | Mengubah protokol atau format dari public API ke internal API. Contoh: request REST API publik diterjemahkan menjadi pemanggilan gRPC internal, atau satu query GraphQL diterjemahkan menjadi beberapa pemanggilan REST API internal. |
Selain tiga fungsi di atas, API Gateway juga mengimplementasikan cross-cutting concern — yaitu fungsionalitas yang secara umum dibutuhkan oleh setiap API sehingga lebih efisien diimplementasikan sekali di gateway daripada diulang di tiap service:
| Cross-cutting Concern | Penjelasan |
|---|---|
| Authentication | Memverifikasi identitas pemanggil API. |
| Authorization | Memverifikasi apakah pemanggil berhak mengakses resource/operasi yang diminta. |
| Rate-limiter | Membatasi jumlah request yang diperbolehkan dalam periode waktu tertentu, mencegah overuse. |
| Timeout/retries | Mengatur batas waktu tunggu respons backend dan mekanisme percobaan ulang bila gagal. |
| Logging | Mencatat aktivitas pemanggilan API. |
| Tracing | Menelusuri jejak pemanggilan request lintas backend untuk keperluan debugging/analisis performa. |
Sejarah Teknologi API Gateway
Konsep API Gateway berkembang dari teknologi load balancing dan traffic management yang sudah ada sebelumnya:
- 1990-an — Hardware Load Balancer: perangkat seperti F5 dipakai sebagai gateway di depan web server backend.
- 2000-an — Software Load Balancer: NGINX, HAProxy menggantikan/melengkapi hardware load balancer dengan solusi berbasis software.
- Pertengahan 2000-an — Application Delivery Controllers (ADC): perangkat khusus (F5, Cisco, Citrix) yang menambahkan kemampuan compression, caching, connection multiplexing, traffic shaping, SSL offload, selain load balancing.
- Awal 2010-an — API Gateway: muncul produk khusus untuk API seperti Kong API Gateway, NGINX, WSO2 Cloud Service Gateway.
- Saat ini: AWS API Gateway, GCP Apigee, Zuul (dikembangkan Netflix), Traefik, Tyk, Ambassador, Mulesoft, dsb.
Contoh: AWS API Gateway
AWS API Gateway menyediakan endpoint yang dapat diakses publik, terintegrasi dengan monitoring (CloudWatch) dan caching, serta dapat me-route pemanggilan ke beragam backend (serverless/Lambda, data stream/Kinesis, VM/EC2, database/DynamoDB, layanan eksternal, dsb).
Beberapa konfigurasi penting pada AWS API Gateway yang menggambarkan bagaimana fungsi-fungsi di atas diimplementasikan secara konkret:
- Resource/Method mapping — incoming call dapat dipetakan berdasarkan path, parameter query, method, atau rules lain, lalu diarahkan ke integration type tertentu (Lambda Function, HTTP, Mock, AWS Service, VPC Link).
- Stage — digunakan untuk merepresentasikan environment (dev, staging, prod) atau untuk versioning API.
- Authorizer — konfigurasi terpusat untuk mekanisme otorisasi akses, bisa berupa fungsi (Lambda) yang dipanggil untuk validasi, atau terintegrasi dengan AWS Cognito.
- Gateway Response transformation — hasil/response dapat ditransformasi (misalnya mengubah status code, header, atau body sebelum dikembalikan ke client), termasuk penanganan berbagai kondisi error (Access Denied, Quota Exceeded, Invalid API Key, dsb).
- Usage Plans (rate limiting) — pengaturan trafik dapat dilakukan berdasarkan limit tetap, atau menggunakan algoritma leaky bucket yang mengizinkan trafik burst untuk volume tertentu sebelum throttling diterapkan.
- Monitoring — memantau jumlah pemanggilan (API Calls), latency total, Integration Latency (latency khusus ke backend), jumlah error 4xx/5xx, dan alerting.
- Tracing — tracing pemanggilan API ke backend beserta latency-nya menggunakan AWS X-Ray, menampilkan peta node-node service yang dipanggil beserta rata-rata waktu respons dan throughput tiap node.
Contoh: Traefik
Traefik adalah salah satu implementasi API Gateway/reverse proxy modern yang arsitekturnya terdiri dari beberapa komponen utama:
- Entrypoints — titik masuk trafik (HTTP, TLS, TCP), berupa port yang di-expose.
- Providers — sumber konfigurasi yang mendefinisikan routing (misalnya dari Docker labels, Kubernetes, file konfigurasi, dsb), memberi input ke Routers maupun Services.
- Routers — menerima inbound request dari entrypoint, terdiri dari:
- Rules — mencocokkan (match) request berdasarkan kriteria tertentu (host, path, header, dsb).
- Middlewares — mentransformasi request (misalnya menambah header, redirect, auth, rate limiting) sebelum diteruskan.
- Services — meneruskan/me-route request yang sudah lolos ke backend server yang sesuai.
Service Mesh
Berbeda dengan API Gateway yang berfokus pada trafik masuk dari luar (public API), Service Mesh berfokus pada komunikasi internal antar service. Definisinya:
A service mesh is an infrastructure layer that enables you to control the network communication of your workloads from a single control plane.
Dengan kata lain, service mesh mengatur komunikasi antar service — mencakup **routing**, **authorization**, **logging**, **traffic shaping**, dan sejenisnya — namun semuanya dikendalikan dari satu titik kendali terpusat (control plane), bukan dikonfigurasi manual di tiap service.
Service mesh menyediakan fungsionalitas yang serupa dengan API Gateway (routing, auth, logging, dsb), tetapi konteksnya berbeda: API Gateway untuk trafik eksternal-ke-internal, sedangkan service mesh untuk trafik internal antar service. Sebuah service mesh sebenarnya juga dapat menyediakan pengaturan untuk akses eksternal — pada titik itu ia berfungsi selayaknya API Gateway.
Contoh implementasi service mesh: Istio (dengan data plane Envoy), Linkerd, Consul, App Mesh (AWS), Azure Service Fabric Mesh.
Fitur Utama Service Mesh
| Fitur | Penjelasan |
|---|---|
| Observability | Menyediakan visibilitas terhadap perilaku dan kesehatan service yang sedang berjalan (metrics, trace komunikasi antar service). |
| Routing | Pengaturan bagaimana request diarahkan antar service (termasuk load balancing, canary/blue-green routing). |
| Automatic scaling | Pengaturan autoscaling service berdasarkan kondisi trafik/beban. |
| Separation of duties | Pengaturan/konfigurasi service mesh dilakukan independen terhadap development team — tim platform/infrastruktur dapat mengatur kebijakan jaringan tanpa mengubah kode aplikasi. |
| Trust | Pengaturan secure communication protocols (mis. mTLS) dan management of certificates antar service. |
| Automatic service registration and discovery | Pengaturan registrasi service secara otomatis saat deployment, sehingga service lain dapat menemukannya tanpa konfigurasi manual. |
| Resilient | Pengendalian resiliency service, misalnya melalui retry, circuit breaking, timeout pada level komunikasi antar service. |
Control Plane vs Data Plane
Inti arsitektur service mesh adalah pemisahan tegas antara Control Plane dan Data Plane, karena keduanya memiliki karakteristik kebutuhan (requirement) yang berbeda:
- Control Plane: jalur untuk mengatur konfigurasi — mendefinisikan kebijakan (policy), aturan routing, load balancing, sertifikat, dsb yang akan diterapkan di data plane. Karena sifatnya konfigurasi, trafiknya low volume, dan lebih mengutamakan konsistensi dibandingkan availability (perubahan policy harus konsisten diterapkan ke semua node, meski itu berarti sedikit delay).
- Data Plane: jalur trafik user/data yang sesungguhnya — tempat kebijakan yang sudah didefinisikan di control plane benar-benar dieksekusi pada tiap request. Karena harus melayani trafik user secara langsung, data plane mengutamakan speed, availability, dan high volume.
Umumnya jalur untuk control plane dan data plane dipisahkan secara fisik/logis agar gangguan pada satu jalur (misalnya update konfigurasi) tidak langsung mengganggu jalur satunya.
| Aspek | Control Plane | Data Plane |
|---|---|---|
| Fungsi | Mengatur/mendefinisikan konfigurasi & kebijakan (policy, routing rule, load balancing, sertifikat) | Mengeksekusi kebijakan tersebut pada trafik request/data yang sebenarnya |
| Volume trafik | Low volume | High volume |
| Prioritas | Konsistensi dikutamakan dibanding availability | Speed & availability dikutamakan |
| Letak eksekusi | Terpusat (mengatur seluruh mesh) | Tersebar, melekat pada tiap service (sidecar) |
Arsitektur Sidecar Proxy
Implementasi data plane pada service mesh umumnya menggunakan pola sidecar proxy: setiap service dijalankan berdampingan dengan sebuah proxy (sidecar) yang menangani seluruh komunikasi masuk/keluar service tersebut. Semua sidecar proxy ini menerima konfigurasi dari satu control plane yang sama, sehingga kebijakan bisa diterapkan konsisten meski service berjalan di lingkungan yang berbeda-beda (mis. Kubernetes maupun non-Kubernetes).
Dari diagram terlihat bahwa Control Plane terhubung ke setiap Sidecar Proxy yang berada satu paket dengan service-nya masing-masing (Service-A di lingkungan Kubernetes, Service-B di lingkungan non-Kubernetes) — keduanya berada pada wilayah Data Plane. Service tidak lagi berkomunikasi langsung satu sama lain, melainkan lewat sidecar proxy masing-masing, sehingga kebijakan komunikasi (routing, security, logging) dapat diterapkan secara seragam tanpa mengubah kode service itu sendiri.
Flashcard
flashcards Apa fungsi utama API Gateway sebagai façade/proxy? :: Menyediakan satu titik akses (single entry point) untuk API yang di-ekspose ke publik, mengurangi coupling antara sistem eksternal dan internal, sehingga perubahan internal API tidak memengaruhi kontrak public API. Sebutkan dan jelaskan tiga fungsi inti API Gateway (Routing, Composition, Translation). :: Routing: meneruskan request ke internal API yang sesuai tanpa mengubah public API saat internal berubah. Composition: menggabungkan beberapa internal API low-level menjadi satu higher-level API. Translation: mengubah protokol/format, misalnya REST publik menjadi gRPC internal, atau GraphQL menjadi beberapa REST call internal. Apa yang dimaksud cross-cutting concern pada API Gateway dan sebutkan contohnya. :: Fungsionalitas yang dibutuhkan oleh hampir setiap API sehingga lebih efisien diimplementasikan sekali di gateway daripada di tiap service; contohnya authentication, authorization, rate-limiter, timeout/retries, logging, dan tracing. Apa perbedaan mendasar antara API Gateway dan Service Mesh? :: API Gateway berfokus mengelola trafik eksternal (publik) yang masuk ke sistem sebagai single entry point, sedangkan Service Mesh berfokus mengatur komunikasi internal antar service, meskipun kedua-duanya menyediakan fungsi serupa (routing, auth, logging). Jelaskan perbedaan Control Plane dan Data Plane pada service mesh. :: Control Plane adalah jalur untuk mengatur konfigurasi/kebijakan (policy, routing, load balancing, sertifikat) dengan trafik low volume yang mengutamakan konsistensi; Data Plane adalah jalur trafik user/data sesungguhnya tempat kebijakan tersebut dieksekusi, dengan trafik high volume yang mengutamakan speed dan availability. Apa itu sidecar proxy dalam arsitektur service mesh? :: Proxy yang berjalan berdampingan dengan setiap service untuk menangani seluruh komunikasi masuk/keluar service tersebut; seluruh sidecar proxy menerima konfigurasi dari satu control plane yang sama sehingga kebijakan komunikasi dapat diterapkan konsisten tanpa mengubah kode service. Sebutkan fitur utama yang disediakan oleh service mesh. :: Observability, routing, automatic scaling, separation of duties, trust (secure communication & certificate management), automatic service registration and discovery, dan resilience. Bagaimana algoritma leaky bucket digunakan dalam rate limiting API Gateway? :: Leaky bucket mengizinkan trafik burst hingga volume tertentu sebelum throttling diterapkan, berbeda dengan limit tetap yang langsung menolak request begitu melewati batas rate per detik. Sebutkan contoh evolusi teknologi menuju API Gateway modern. :: Hardware Load Balancer (1990-an, mis. F5) → Software Load Balancer (2000-an, NGINX/HAProxy) → Application Delivery Controllers (pertengahan 2000-an) → API Gateway (awal 2010-an, Kong/WSO2) → solusi modern seperti AWS API Gateway, GCP Apigee, Zuul, Traefik, Tyk, Ambassador.