Level 3 · Sistem yang Saling Bergantung
Sesi 24: Lalu Lintas Antar Layanan
1. Bayangkan jika —
Tiga puluh microservice saling memanggil. Setiap layanan punya sopir sendiri yang tahu: jalan mana sedang macet, kapan harus menyabar sebentar sebelum mencoba lagi, kapan harus berhenti sama sekali sebelum ikut terseret tenggelam, dan apakah orang yang diajak bicara memang benar-benar layanan yang sah dan bukan penyusup yang menyamar.
Tanpa sopir itu, satu layanan lambat bisa menghabisi semua yang ada di rantai atasnya — dalam hitungan detik. Ini bukan lagi soal bahasa yang dipakai (Sesi 23), tapi soal siapa yang menjaga jalur dan membuat keputusan di setiap persimpangan.
2. Apa yang Sebenarnya Terjadi
Masalah Tanpa Service Mesh
Di arsitektur microservice tanpa service mesh, setiap layanan bertanggung jawab sendiri untuk: - Retry — mencoba lagi saat downstream lambat - Timeout — berhenti menunggu setelah batas waktu tertentu - Circuit Breaker — menghentikan panggilan ke layanan yang sudah sakit - mTLS — memastikan komunikasi antar layanan terenkripsi dan terautentikasi
Artinya logika infrastruktur ini ditulis ulang di setiap bahasa, di setiap layanan, oleh setiap tim. Bug di satu implementasi tidak terditeksi sampai insiden terjadi di produksi. Dan saat insiden memang terjadi, tidak ada visibilitas terpusat tentang apa yang sebenarnya terjadi di antara layanan-layanan itu.
Envoy: Proxy yang Berpikir
Envoy adalah L7 proxy yang dirancang untuk komunikasi antar layanan. Berbeda dari Nginx yang menghadap ke pengguna akhir (north-south), Envoy duduk di east-west — di antara layanan.
Yang membuat Envoy berbeda: dia memahami HTTP/2, gRPC, dan protokol modern secara native, dan dia mengekspos semua yang terjadi lewat metrics, logs, dan traces — tanpa mengubah satu baris kode aplikasi.
Pola Sidecar: Satu Proxy per Pod
Di Kubernetes, Envoy biasa dijalankan sebagai sidecar — container tambahan yang hidup di pod yang sama dengan container aplikasi. Mereka berbagi network namespace: semua traffic yang keluar dan masuk pod melewati Envoy, bukan langsung dari aplikasi.
Hasilnya: aplikasi tidak tahu tentang retry, timeout, mTLS, circuit breaker. Semua itu menjadi tanggung jawab Envoy. Aplikasi cukup bicara HTTP biasa ke localhost, Envoy yang mengurus sisanya.
Control Plane: Yang Memberi Perintah
Envoy sendiri adalah data plane — dia yang memindahkan paket. Tapi siapa yang memberitahu dia cara bertindak? Itulah control plane.
Di Istio (service mesh paling populer), control plane adalah Istiod: dia mendistribusikan konfigurasi ke semua Envoy sidecar di cluster — menentukan routing rule, timeout policy, circuit breaker threshold, dan sertifikat mTLS yang harus dipakai.
Tanpa control plane terpusat, kamu harus mengkonfigurasi ribuan Envoy instance secara manual.
Empat Perilaku Kunci
1. Retry dengan Limit
Envoy bisa dikonfigurasi untuk mencoba ulang request yang gagal, dengan batas jumlah percobaan dan kondisi yang jelas (misalnya: hanya retry untuk 503, maksimal 3 kali). Ini mencegah retry storm yang tak terkendali.
2. Timeout Hierarkis Timeout bisa diatur di level per-request dan per-connection. Jika downstream tidak merespons dalam 200ms, Envoy memutus — tidak menunggu sampai thread aplikasi habis.
3. Circuit Breaker & Outlier Detection Envoy memantau error rate dari setiap upstream host. Jika satu host menghasilkan lebih dari X% error dalam Y detik, Envoy mengeluarkan host itu dari rotation (outlier detection) dan membuka sirkuit — menghentikan semua traffic ke host itu untuk memberinya waktu recover.
4. mTLS: Zero-Trust di East-West Setiap sidecar Envoy memegang sertifikat yang diterbitkan oleh control plane. Saat dua layanan bicara, Envoy keduanya menegosiasikan TLS — memastikan traffic terenkripsi dan identitas kedua pihak terverifikasi. Tidak ada lagi "percaya saja karena ada di cluster yang sama."
3. Bagaimana Jika Kita Coba...
"Tulis sendiri retry dan circuit breaker di tiap layanan." Ini yang terjadi tanpa service mesh — dan hasilnya tidak konsisten. Java mengimplementasikan dengan Resilience4j, Python dengan tenacity, Node.js dengan opossum. Versi berbeda, perilaku berbeda, bug berbeda. Dan saat kamu mau mengubah timeout policy cluster-wide, kamu harus mengubah kode di semua layanan.
"Pakai library yang sama di semua layanan." Lebih baik, tapi masih ada overhead: setiap bahasa punya library sendiri, setiap upgrade library memerlukan deploy ulang semua layanan, dan library tidak bisa mengontrol traffic di level TCP.
4. Nama Resminya
| Konsep | Definisi Singkat | Di Design Doc |
|---|---|---|
| Envoy | L7 proxy open-source, data plane default banyak service mesh | Kotak "Envoy Proxy" atau "Sidecar" di diagram pod |
| Sidecar | Pola deployment: satu proxy per pod, berbagi network namespace | Container tambahan di spec pod Kubernetes |
| Service Mesh | Infrastruktur communication layer antar layanan | Istio, Linkerd, Consul Connect |
| Data Plane | Layer yang memindahkan data (Envoy) | Sidecar instances |
| Control Plane | Layer yang mendistribusikan konfigurasi (Istiod) | Komponen Istio di namespace khusus |
| Circuit Breaker | Memutus koneksi ke upstream yang sakit secara otomatis | outlierDetection di DestinationRule Istio |
| Outlier Detection | Mekanisme Envoy mendeteksi dan mengeluarkan host bermasalah | consecutiveGatewayErrors, interval, baseEjectionTime |
| mTLS | Mutual TLS: kedua pihak membuktikan identitas | PeerAuthentication policy di Istio |
5. Di Dunia Kita
Di sistem microservice skala besar (100+ layanan), service mesh bukan pilihan — dia infrastruktur wajib. Tanpanya, insiden satu layanan cascades selama menit karena tidak ada yang memutus rantai.
Saat flash sale: trafik naik 40× normal. Satu layanan inventory mulai timeout. Tanpa circuit breaker: semua layanan yang memanggil inventory ikut menunggu, thread pool habis, sistem mati bersamaan. Dengan Envoy circuit breaker: setelah 3 consecutive error, Envoy membuka sirkuit, mengembalikan error 503 langsung tanpa menunggu — layanan lain masih hidup, tim mendapat alert, inventory recover dalam dua menit.
Untuk tim performa: observability yang datang bersama service mesh (Envoy metrics di Prometheus, trace di Jaeger/Tempo) adalah sumber data terpercaya untuk menjawab "di mana sebenarnya latensi itu habis?"
6. Lensa Performance Tester
Empat angka yang harus ada di konfigurasi Envoy sebelum load test:
-
Timeout per upstream call — berapa lama maksimum satu request ke downstream boleh menunggu? Target: konsisten dengan SLO layanan itu sendiri (jangan 30 detik kalau SLO-nya 500ms).
-
Retry budget — berapa total retry yang diizinkan sebagai persentase dari concurrent request? Default Envoy 20% sudah baik; jangan naikkan tanpa memikirkan cascade-nya.
-
Circuit breaker threshold —
consecutiveGatewayErrors: berapa error berturut-turut sebelum host dikeluarkan? Terlalu rendah = false positive, terlalu tinggi = lambat bereaksi. -
Envoy sidecar resource limits — setiap sidecar mengonsumsi CPU dan memory. Di 1.000 pod, 1.000 sidecar. Ukur overhead sebelum memutuskan service mesh.
Skenario uji: - Injeksi fault (Istio FaultInjection): paksa 50% request ke satu layanan return 503, verifikasi circuit breaker membuka tepat di threshold - Ukur latency tambahan dari sidecar (biasanya 1–5ms per hop di cluster yang sama) — pastikan masuk anggaran p99 - Chaos: matikan satu instance layanan secara mendadak, ukur berapa lama sebelum outlier detection mengeluarkannya dari rotation
7. Pertanyaan untuk Ronde Berikutnya
Service mesh sudah menjaga lalu lintas: retry terkontrol, circuit breaker aktif, mTLS menyala. Tapi ada skenario yang belum tertutup: bukan satu layanan yang lambat, tapi semua layanan serentak mencoba mengakses layanan yang sama pada saat yang sama — dan mereka semua retry bersamaan saat gagal.
Itulah yang dibahas di Sesi 25: Efek Domino — Cascading Failure, Retry Storm, dan Jitter.