Load Balancing #
Load balancer adalah komponen yang mendistribusikan trafik jaringan ke beberapa server atau instance di belakangnya. Tanpa load balancer, kamu tidak bisa menjalankan lebih dari satu instance untuk sebuah layanan — semua trafik hanya bisa pergi ke satu tempat. Dengan load balancer, kamu mendapat horizontal scaling, high availability, dan satu titik masuk yang aman untuk seluruh sistem. Di cloud, load balancer hampir selalu berupa managed service — kamu tidak perlu menginstall atau mengelola software load balancer sendiri.
Masalah yang Dipecahkan Load Balancer #
Tanpa Load Balancer:
Pengguna → DNS resolves ke 54.123.45.1 → [Server A]
Masalah:
✗ Server A jadi bottleneck — semua beban ada di satu tempat
✗ Jika Server A mati → layanan mati sepenuhnya
✗ Tidak bisa scale horizontal — pengguna hanya bisa ke satu IP
Dengan Load Balancer:
Pengguna → DNS resolves ke IP Load Balancer
│
▼
[Load Balancer]
│
┌───────┼───────┐
▼ ▼ ▼
Server A Server B Server C
✓ Beban terdistribusi ke semua server
✓ Jika Server B mati → trafik dialihkan ke A dan C otomatis
✓ Server baru bisa ditambahkan ke pool kapan saja
Layer 4 vs Layer 7 Load Balancer #
Load balancer beroperasi di layer yang berbeda dari OSI model, dan ini menentukan “kecerdasan” dalam membuat keputusan routing.
Layer 4 — Network Load Balancer #
Layer 4 (Transport Layer) Load Balancer:
Bekerja berdasarkan: IP address dan TCP/UDP port
Tidak melihat isi paket — hanya header jaringan
Cara kerja:
Request TCP ke port 443
→ LB pilih backend berdasarkan IP:port
→ Forward koneksi TCP langsung ke backend
Karakteristik:
✓ Sangat cepat — minimal processing overhead
✓ Cocok untuk trafik volume sangat tinggi
✓ Mendukung protokol apapun (TCP, UDP, TLS)
✓ Latensi sangat rendah
✗ Tidak bisa routing berdasarkan URL path atau HTTP header
✗ Tidak bisa terminate SSL (atau bisa, tapi tidak inspect isinya)
Cocok untuk:
→ TCP/UDP workload: game server, IoT, database proxy
→ Kasus di mana latensi sangat kritis
→ Non-HTTP protocol
Layer 7 — Application Load Balancer #
Layer 7 (Application Layer) Load Balancer:
Bekerja berdasarkan: konten request (URL, HTTP header, cookie)
Membaca dan memahami isi HTTP/HTTPS request
Cara kerja:
GET /api/users HTTP/1.1
Host: api.example.com
→ LB baca URL path: /api/users
→ Route ke backend yang menangani /api/*
Karakteristik:
✓ Routing berdasarkan URL path, header, host, method
✓ SSL termination — decrypt HTTPS di LB, HTTP ke backend
✓ HTTP/2 dan WebSocket support
✓ Request/response modification (add header, redirect)
✓ WAF integration — filter request berbahaya
✗ Lebih lambat dari L4 (tapi cukup cepat untuk hampir semua kasus)
✗ Hanya untuk HTTP/HTTPS
Cocok untuk:
→ Web application dan REST API
→ Microservices dengan routing berbasis path
→ Aplikasi yang butuh SSL termination
Content-Based Routing di Layer 7 #
Salah satu kekuatan terbesar L7 load balancer adalah kemampuan routing berdasarkan konten request.
Routing Rules Layer 7:
Semua request masuk ke satu Load Balancer:
┌─────────────────────────────────────────────────────┐
│ api.example.com │
│ │
│ Rule 1: path /api/users/* → User Service │
│ Rule 2: path /api/orders/* → Order Service │
│ Rule 3: path /api/products/* → Product Service │
│ Rule 4: header "X-Admin: true" → Admin Backend │
│ Rule 5: default → Frontend Service │
└─────────────────────────────────────────────────────┘
Manfaat:
✓ Satu domain untuk seluruh aplikasi
✓ Setiap service bisa di-scale independen
✓ Tidak perlu expose banyak port atau domain
✓ Routing logic terpusat di LB, bukan di setiap service
Host-based routing (multiple domains, satu LB):
example.com → Frontend
api.example.com → API backend
admin.example.com → Admin panel
Algoritma Distribusi Trafik #
Load balancer menggunakan berbagai algoritma untuk memutuskan ke backend mana trafik dikirim.
Round Robin (default di kebanyakan LB):
Request 1 → Backend A
Request 2 → Backend B
Request 3 → Backend C
Request 4 → Backend A (kembali dari awal)
✓ Sederhana, distribusi merata
✗ Tidak memperhitungkan beban aktual setiap backend
Least Connections:
Selalu kirim ke backend dengan koneksi aktif paling sedikit
✓ Lebih cerdas — tidak overload backend yang sedang sibuk
✓ Cocok untuk request dengan durasi yang bervariasi
IP Hash / Sticky Sessions:
IP client yang sama selalu diarahkan ke backend yang sama
✓ Berguna jika aplikasi stateful (session di server)
✗ Distribusi tidak merata jika ada IP tertentu yang sangat aktif
✗ Jika backend mati, semua user dari IP itu harus pindah
✗ Hindari ini jika bisa — buat aplikasi stateless
Health Check — Jantung Load Balancer #
Health check adalah mekanisme yang memungkinkan load balancer mendeteksi backend yang tidak sehat dan berhenti mengirim trafik ke sana secara otomatis.
Cara Kerja Health Check:
Load Balancer secara periodik:
→ Kirim request ke setiap backend (misalnya: GET /health)
→ Tunggu response dalam waktu timeout
→ Evaluasi response
Backend SEHAT jika:
✓ Menjawab dalam waktu timeout
✓ Mengembalikan HTTP 200
✓ (Opsional) response body sesuai yang diharapkan
Backend TIDAK SEHAT jika:
✗ Tidak menjawab (timeout)
✗ Mengembalikan HTTP 5xx atau 4xx yang tidak diharapkan
✗ Gagal N kali berturut-turut (threshold)
Tindakan otomatis:
Backend tidak sehat → LB berhenti kirim trafik ke sana
Backend sehat kembali → LB mulai kirim trafik lagi
Endpoint /health yang baik:
✓ Lightweight — tidak butuh database query yang berat
✓ Mencerminkan kondisi nyata — jika koneksi DB putus, return 503
✓ Tidak di-cache — harus cek kondisi real-time
✓ Terproteksi — jangan ekspos info sensitif di response
SSL Termination #
Load balancer Layer 7 biasanya melakukan SSL termination — koneksi HTTPS dari client di-decrypt di load balancer, dan trafik antara load balancer dan backend bisa berupa HTTP biasa (di jaringan privat yang terpercaya).
Tanpa SSL Termination:
Client ─── HTTPS ───→ Backend A (decrypt di setiap backend)
──→ Backend B (decrypt di setiap backend)
──→ Backend C (decrypt di setiap backend)
✗ Setiap backend harus punya sertifikat SSL
✗ Beban komputasi SSL tersebar, tidak efisien
✗ Sulit mengelola sertifikat di banyak instance
Dengan SSL Termination di Load Balancer:
Client ─── HTTPS ───→ [Load Balancer] ─── HTTP ───→ Backend A
(TLS) (decrypt di sini) (private → Backend B
satu sertifikat) network) → Backend C
✓ Sertifikat hanya di satu tempat (LB)
✓ Backend tidak perlu tahu tentang SSL
✓ Load balancer bisa melihat isi HTTP untuk L7 routing
✓ Certificate renewal hanya di satu tempat
Ringkasan #
- Load balancer adalah prerequisite horizontal scaling — tanpanya, trafik tidak bisa didistribusikan ke beberapa instance.
- L4 untuk kecepatan dan non-HTTP, L7 untuk kecerdasan routing — pilih berdasarkan kebutuhan: L4 untuk throughput tinggi, L7 untuk web app dan microservices.
- Content-based routing di L7 memungkinkan satu domain untuk seluruh aplikasi — routing berdasarkan path, header, atau host ke service yang berbeda.
- Health check adalah mekanisme auto-healing — backend yang tidak sehat otomatis dikeluarkan dari pool, tidak perlu intervensi manual.
- SSL termination di load balancer menyederhanakan manajemen sertifikat — satu sertifikat di satu tempat, backend tidak perlu tahu tentang TLS.
- Hindari sticky session jika bisa — buat aplikasi stateless agar trafik bisa terdistribusi secara merata ke semua backend.
← Sebelumnya: NAT, Firewall, Security Group Berikutnya: Object Storage →