Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Service mesh vs API gateway: traffic north-south dan east-west, sidecar vs ambient mesh, config nginx dan Istio asli, biaya, serta kapan Anda tidak butuh keduanya.
Matthews Wong
Software Engineer
Ringkasan Utama
API gateway menangani traffic north-south: berada di edge, mengautentikasi client, membatasi rate dan merutekan request ke dalam sistem. Service mesh menangani traffic east-west: menambahkan mutual TLS, retry dan telemetry antar service lewat proxy. Tim kecil dengan satu server biasanya tidak butuh keduanya, cukup reverse proxy.
Setiap beberapa bulan ada yang bertanya apakah sistemnya perlu Istio, dan pertanyaan pertama yang jujur adalah masalah apa yang ingin diselesaikan. Keduanya sering tertukar karena sama-sama proxy yang merutekan HTTP, sama-sama bisa menegakkan policy, dan sama-sama muncul di diagram arsitektur yang sama.
Artikel ini memisahkan keduanya berdasarkan arah traffic yang ditangani, menunjukkan config gateway nginx dan YAML Istio asli, mencocokkan model sidecar dan ambient dengan dokumentasi Istio dan Linkerd, lalu ditutup dengan checklist keputusan. Sistem saya sendiri adalah ERP dan POS ala Qilap dengan NestJS, Postgres dan Redis di Docker pada satu VPS, yaitu situasi di mana jawabannya biasanya tidak perlu keduanya.
Traffic north-south melintasi batas sistem Anda: browser, aplikasi mobile atau partner memanggil dari luar. Traffic east-west tetap di dalam: service orders memanggil service catalog, worker memanggil API billing. Istilah ini jargon diagram jaringan, bukan standar formal, tetapi cocok dengan dua tool tersebut.
API gateway memegang north-south. Ia adalah pintu depan tunggal tempat TLS diakhiri, pemanggil diidentifikasi, client yang abusif dibatasi, dan backend untuk tiap path ditentukan. Service mesh memegang east-west. Ia berasumsi pemanggil sudah di dalam dan fokus membuat setiap hop internal terenkripsi, bisa diamati dan tahan gangguan tanpa mengubah kode aplikasi.
Pekerjaan gateway menyangkut orang luar: autentikasi token atau API key, rate limiting, routing berdasarkan path atau host, TLS termination, kadang response caching atau transformasi request. Bentuk paling sederhananya adalah reverse proxy. Config nginx di bawah merutekan dua prefix path ke dua grup upstream dan membatasi rate tiap alamat client, memakai directive dari dokumentasi resmi limit_req.
# /etc/nginx/conf.d/gateway.conf (north-south: the one door into the system)
# 10 requests/second per client IP on average, bursts of up to 20 extra.
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_status 429; # default is 503, which reads like an outage
upstream orders_api { server 10.0.0.11:3001; server 10.0.0.12:3001; }
upstream catalog_api { server 10.0.0.21:3002; }
server {
listen 443 ssl;
server_name api.example.com;
location /orders/ {
limit_req zone=api burst=20 nodelay; # nodelay: serve the burst now
proxy_set_header X-Request-Id $request_id;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://orders_api/;
}
location /catalog/ {
limit_req zone=api burst=20 nodelay;
proxy_pass http://catalog_api/;
}
}Hitungannya layak dicoba sekali. Rate 10r/s dengan burst=20 dan nodelay berarti client rata-rata 10 request per detik tetapi bisa mengirim 20 tambahan seketika sebelum ditolak dengan status 429; dokumentasi nginx mencatat kode penolakan default adalah 503, makanya config meng-override-nya. Autentikasi biasanya ada sebelum blok ini, bisa berupa pengecekan JWT di gateway atau subrequest nginx ke auth service. Artikel gateway pattern di akhir tulisan menunjukkan versi NestJS-nya.
Mesh memindahkan concern lintas fungsi untuk panggilan internal dari kode aplikasi ke proxy: mutual TLS antar workload, retry dan timeout, traffic splitting untuk canary release, serta metrics dan trace yang seragam. Istio menuliskannya sebagai resource Kubernetes. Policy pertama menolak traffic plaintext di satu namespace, dan yang kedua menambah timeout, retry dan canary split 90/10 untuk service orders.
# East-west: refuse any plaintext call between workloads in "shop".
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default # "default" = namespace-wide policy
namespace: shop
spec:
mtls:
mode: STRICT # PERMISSIVE accepts both; use it while migratingapiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: orders
namespace: shop
spec:
hosts:
- orders.shop.svc.cluster.local
http:
- timeout: 5s
retries:
attempts: 3 # mesh-level retries
retryOn: "connect-failure,unavailable"
route:
- destination:
host: orders.shop.svc.cluster.local
subset: v2
weight: 10 # canary: 10 / (10 + 90) of traffic
- destination:
host: orders.shop.svc.cluster.local
subset: v1
weight: 90
---
# subsets must be declared here, or the VirtualService points at nothing
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: orders
namespace: shop
spec:
host: orders.shop.svc.cluster.local
subsets:
- name: v1
labels: { version: v1 }
- name: v2
labels: { version: v2 }Nama field di atas mengikuti halaman referensi Istio untuk PeerAuthentication dan VirtualService, di mana default retry yang terdokumentasi adalah 2 attempt. Linkerd mengambil jalur lebih sempit: dokumentasinya menyebut mutual TLS aktif otomatis untuk traffic TCP antar pod yang di-mesh, dengan sertifikat terikat pada identitas ServiceAccount pod dan kedaluwarsa setelah 24 jam. Kedua pendekatan memberi panggilan internal terenkripsi dengan identitas terverifikasi tanpa menyentuh kode service.
Retry itu berlipat. Jika HTTP client Anda retry 3 kali dan mesh juga retry 3 kali, satu request user yang gagal bisa menghantam service yang rusak 9 kali, dan retry di gateway membuatnya 27. Pilih satu layer yang memegang retry, lalu pasangkan dengan timeout dan backpressure agar service yang kewalahan tidak terkubur oleh pemanggilnya sendiri.
Mesh klasik menyuntikkan proxy di samping setiap pod aplikasi. Linkerd mendokumentasikannya sebagai data plane proxy di tiap pod, dan mode sidecar Istio memakai proxy Envoy dengan cara yang sama. Mode ambient Istio menghapus proxy per pod itu dan membagi data plane menjadi dua layer, menurut ringkasan ambient Istio:
Ambient bergantung pada versi: pengumuman Istio untuk rilis 1.24 menyebut komponen intinya ditandai Stable saat itu. Halaman ringkasan tidak memberi angka overhead, hanya bahwa waypoint lebih berat daripada ztunnel saja, jadi anggap klaim persentase penghematan apa pun sebagai hal yang perlu diukur di cluster Anda sendiri, bukan fakta.
Tabel merangkum posisi dan tujuan masing-masing tool. Baca baris-barisnya sebagai pembagian kerja, bukan peringkat, karena kebanyakan sistem produksi yang memakai keduanya memakai masing-masing untuk tugas yang memang dirancang untuknya.
| Aspek | API gateway | Service mesh |
|---|---|---|
| Arah traffic | North-south, dari client ke dalam sistem | East-west, antar service internal |
| Tempat berjalan | Satu atau beberapa proxy di edge | Satu proxy per pod (sidecar) atau per node plus waypoint opsional (ambient) |
| Autentikasi | Mengidentifikasi pemanggil eksternal: token, API key | Mengidentifikasi workload: identitas mutual TLS |
| Rate limiting | Fitur inti, per client atau key | Bisa, tetapi jarang jadi alasan utama memakai mesh |
| Resilience | Timeout dan failover upstream di edge | Retry, timeout dan traffic splitting di setiap hop internal |
| Observability | Log dan metrics request di edge | Metrics dan trace seragam untuk setiap panggilan antar service |
| Biaya operasional | Rendah: satu file config bisa cukup | Tinggi: control plane, upgrade proxy dan failure mode baru |
Tumpang tindihnya nyata. Gateway bisa retry panggilan upstream dan mesh bisa membatasi rate, jadi pertanyaan yang berguna adalah layer mana yang memegang suatu concern. Taruh semua hal soal pemanggil tak tepercaya di gateway, dan semua hal soal hop internal tepercaya di mesh atau, untuk sistem kecil, di aplikasi itu sendiri.
Biayanya adalah jumlah komponen bergerak yang sekarang harus Anda operasikan. Ambil cluster hipotetis berisi 12 service dengan 3 replica masing-masing pada 4 node dalam 2 namespace. Sketsa di bawah menunjukkan berapa proxy yang diimplikasikan tiap model, dan bagaimana retry bertumpuk menggelembungkan beban. Angkanya adalah aritmetika dari asumsi, bukan benchmark.
// Hypothetical cluster: 12 services x 3 replicas on 4 nodes, 2 namespaces
pods = 12 * 3 // 36
sidecar proxies = pods // 36 (one Envoy per pod)
ambient L4 only = nodes // 4 (one ztunnel per node)
ambient + L7 = 4 + 2 // 6 (ztunnel per node + one waypoint per namespace)
// Retry stacking: client library x mesh
worst case calls per user request = 3 * 3 // 9 hits on the failing serviceMode sidecar menghasilkan 36 proxy yang harus di-upgrade dan di-restart bersama aplikasi, sedangkan ambient dengan waypoint menghasilkan 6, meski 6 itu adalah infrastruktur bersama dengan scaling sendiri. Bagaimanapun Anda tetap menjalankan control plane, mempelajari rangkaian resource baru, dan men-debug kegagalan yang disebabkan proxy, bukan kode Anda. Service discovery, yang dibahas artikel lain di seri ini, tetap dibutuhkan terlepas dari mesh.
Adopsi bertahap. Mulai dengan mutual TLS PERMISSIVE, amati traffic, lalu ubah ke STRICT per namespace. Di mode ambient Anda bisa mulai dengan ztunnel L4 saja dan menambah waypoint hanya untuk namespace yang butuh routing L7.
Biasanya tidak butuh mesh, dan sering tidak butuh gateway penuh. Satu VPS yang menjalankan API NestJS, Postgres, Redis dan beberapa worker di Docker hanya punya satu edge nyata, dan reverse proxy sudah menanganinya. Pakai checklist ini sebelum menambah salah satunya:
Jika Anda hanya menjawab ya pada pertanyaan ketiga, Anda butuh gateway. Jika jawaban pertama ya dan sisanya tidak, Anda butuh reverse proxy dan library yang baik, tidak lebih.
Bisa, dan ini susunan yang umum di sistem lebih besar. Gateway menerima request eksternal, memvalidasi pemanggil, dan meneruskannya dengan request ID. Sejak titik itu mesh mengambil alih, mengenkripsi setiap hop internal dan menerapkan policy retry dan routing. Urutan yang saya sarankan saat mengadopsinya:
Pengguna Kubernetes juga bisa memodelkan edge dengan Gateway API, yang dibahas di perbandingan terpisah dengan Ingress. Beberapa mesh bisa berperan sebagai edge gateway juga, tetapi menamai dua peran itu terpisah membuat policy lebih mudah dinalar.
Aturan yang saya pegang: pilih berdasarkan arah traffic. Pemanggil tak tepercaya yang masuk ke sistem butuh gateway. Service tepercaya yang saling bicara butuh mesh hanya setelah pekerjaan berulang antar tim lebih mahal daripada mengoperasikan proxy-nya. Sebelum itu, reverse proxy dan library yang disiplin adalah ukuran yang tepat.
Bacaan terkait