Load balancer: L4 vs L7, algoritma, health check, sticky session
Komponen yang membagi request ke banyak instance: di layer mana ia bekerja, bagaimana memilih server, dan bagaimana ia tahu server mana yang sehat
Sebelumnya, lesson 0005 membuat app server stateless supaya bisa ditambah menjadi beberapa instance. Lesson ini membahas komponen di depan instance-instance itu. Di interview, "saya taruh load balancer" saja tidak cukup; interviewer akan bertanya layer apa, algoritma apa, dan apa yang terjadi saat satu server mati.
1. L4 vs L7: melihat koneksi atau melihat request
"L4" dan "L7" merujuk ke layer model OSI, model tujuh lapis untuk jaringan: layer 4 adalah transport (TCP/UDP: alamat IP dan port), layer 7 adalah aplikasi (HTTP: URL, header, cookie). Dokumentasi AWS memakai pembagian yang sama:
- L4: Network Load Balancer "functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second." [1] Ia memilih target dengan flow hash (protokol, IP dan port sumber/tujuan, nomor urut TCP) dan mengirim setiap koneksi TCP ke satu target selama koneksi itu hidup. [3]
- L7: Application Load Balancer "functions at the application layer, the seventh layer"; ia mengevaluasi listener rule dan bisa merutekan request ke target group berbeda berdasarkan isi trafik (mis. path
/apivs/images). [2] Karena membaca HTTP, ia juga menambahkan headerX-Forwarded-Forsupaya server tahu IP client asli. [3]
Untuk membaca HTTP, load balancer L7 harus membuka enkripsinya dulu. TLS adalah protokol yang mengenkripsi koneksi HTTPS (lesson 0002). ALB memakai sertifikat server untuk "terminate the front-end connection and then decrypt requests from clients before sending them to the targets" (TLS termination). Kalau trafik harus tetap terenkripsi sampai target, AWS menyarankan load balancer L4 dengan listener TCP di port 443, yang meneruskan trafik tanpa mendekripsinya. [4]
| L4 | L7 | |
|---|---|---|
| Melihat | IP, port, koneksi TCP | URL, header, cookie |
| Bisa | Sangat cepat, protokol apa pun di atas TCP/UDP | Routing per path/host, TLS termination, sticky cookie |
| Pilih kalau | Throughput sangat tinggi, protokol bukan HTTP, TLS harus sampai server | Default untuk web/API HTTP |
Latihan 1 — L4 atau L7?
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0012.
2. Algoritma: round robin, least connections, hash
nginx mendukung tiga metode dasar, dan round robin adalah default kalau tidak dikonfigurasi apa-apa: [5]
| Algoritma | Cara memilih server | Cocok untuk |
|---|---|---|
| Round robin | Bergiliran: server 1, 2, 3, 1, 2, 3, … | Request yang biayanya mirip dan server yang setara |
| Least connections | Server dengan koneksi aktif paling sedikit | Request yang durasinya bervariasi (ada yang lama) |
| Hash | Hash dari sebuah key (IP client, user ID, URL) menentukan server | Request dengan key yang sama harus ke server yang sama, mis. cache per server |
- Round robin sederhana, tapi Google SRE Book mencatat bahwa round robin bisa menghasilkan selisih "up to 2x in CPU consumption from the least to the most loaded task", antara lain karena biaya query yang bervariasi dan mesin yang berbeda. [6]
- Least connections (
least_conndi nginx) mengatur beban "more fairly in a situation when some of the requests take longer to complete". [5] Padanannya di ALB disebut least outstanding requests: request dikirim ke target dengan request in-progress paling sedikit. [7] - Hash biasa punya kelemahan: menambah atau mengurangi satu server bisa memindahkan sebagian besar key ke server lain. Dengan
hash … consistent, nginx memakai consistent hashing (ketama) sehingga "only a few keys will be remapped"; ini menjaga cache hit ratio. [8] Consistent hashing dibahas lengkap di lesson 0010.
Semua algoritma bisa diberi bobot (weight): di nginx, weight=3 pada satu server dari tiga berarti dari setiap 5 request, 3 ke server itu. [5] Berguna saat mesin tidak setara.
3. Health check: mengeluarkan server yang mati
Ada dua cara load balancer tahu server mana yang sehat:
- Aktif: load balancer sendiri mengirim request (mis.
GET /health) secara berkala. Di ALB, interval default 30 detik (rentang 5–300); target dianggap tidak sehat setelah 2 kegagalan berturut-turut (default) dan sehat kembali setelah 5 keberhasilan (default). [9] - Pasif: nginx open source menilai dari request asli. Kalau respons gagal, server ditandai gagal dan dihindari selama
fail_timeout;max_failsdefault 1. [5]
Dua detail yang sering ditanyakan. Pertama, kalau semua target gagal health check, ALB fail open: tetap mengirim trafik ke semua target, karena mematikan semuanya pasti lebih buruk. [9] Kedua, saat deploy, server tidak langsung dimatikan: ELB berhenti mengirim request baru ke target yang sedang di-deregister dan menunggu 300 detik (default) supaya request yang sedang berjalan selesai (connection draining). [7]
4. Sticky session: kenapa sebaiknya dihindari
Sticky session (session affinity) mengikat session user ke satu target. Di ALB caranya lewat cookie: algoritma hanya dipakai untuk request pertama, dan request berikutnya dari client yang sama langsung ke target yang sama.
AWS menyebutnya berguna "for servers that maintain state information". [7]
Di nginx, ip_hash memberi efek serupa berdasarkan IP client. [5]
Masalahnya: "Stickiness limits the application's ability to scale out"; trafik user yang sangat aktif tidak bisa dibagi ke instance lain. [10] Server mati juga berarti session user di server itu hilang. Jawaban yang lebih baik di interview: buat server stateless dan simpan session di luar server (lesson 0005), lalu pakai round robin atau least connections biasa. Sticky session tetap masuk akal untuk aplikasi lama yang belum bisa diubah, sebagai langkah sementara.
Latihan 2 — Algoritma, health check, sticky session
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0012.
5. Kapan tidak perlu
Sinyal yang membenarkan load balancer. Anda sudah punya, atau butuh, lebih dari satu instance: satu server tidak cukup menurut metrik (lesson 0005), atau target availability menuntut server bisa mati atau di-deploy tanpa downtime. Dengan satu app server, load balancer hanya menambah satu hop tanpa ada yang dibagi.
Biaya dan risiko. Satu hop jaringan tambahan, biaya bulanan, dan satu komponen lagi yang bisa salah konfigurasi (health check path yang salah bisa mengeluarkan semua server). Load balancer yang Anda jalankan sendiri dalam satu mesin adalah single point of failure baru; layanan managed (ALB/NLB) menyelesaikannya dengan biaya.
Alternatif lebih murah. Untuk satu server: tidak ada load balancer, cukup scale up. Untuk pembagian kasar tanpa health check: DNS dengan beberapa record A, yang menurut SRE Book "conceptually simple and trivial to implement" tapi memberi kontrol sangat sedikit atas perilaku client. [11] Kalau load balancer memang perlu: mulai dari L7 managed dengan round robin dan satu endpoint health check. L4, consistent hashing, dan bobot baru ditambahkan kalau angka menuntut.
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai. Soal ini juga ada di bank soal dan bisa ditarik review 0012.
"Anda menaruh load balancer di depan tiga app server. Jelaskan pilihan Anda: layer, algoritma, dan apa yang terjadi kalau satu server mati." (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Load balancer ini dibenarkan karena satu server tidak cukup di jam sibuk dan target availability kita 99,9%, jadi deploy tidak boleh berarti downtime. Saya pilih L7 karena ini API HTTP: bisa routing per path dan melakukan TLS termination. L4 saya pakai kalau protokolnya bukan HTTP atau throughput-nya sangat tinggi. Algoritmanya round robin kalau request seragam; kalau ada request yang lama seperti upload, least connections. Hash saya pakai hanya kalau key yang sama harus ke server yang sama, misalnya cache per server, dan sebaiknya consistent hashing. Load balancer mengirim health check berkala; server yang gagal beberapa kali berturut-turut keluar dari rotasi, dan saat deploy saya pakai connection draining. Saya tidak pakai sticky session karena server-nya stateless dan session ada di Redis."
Checklist: apakah Anda menyebut…
- L4 atau L7, beserta alasannya (HTTP, routing per path, TLS termination)?
- algoritma yang dipilih dan kapan memakai yang lain (round robin vs least connections)?
- hash atau consistent hashing hanya kalau key yang sama harus ke server yang sama?
- health check yang mengeluarkan server gagal dari rotasi?
- menghindari sticky session karena server stateless (session di luar server)?
- membenarkan load balancer dengan angka (beban, jumlah instance, target availability)?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0007: load balancer adalah satu jenis reverse proxy. Apa lagi yang bisa dilakukan di depan server, dan kapan konten sebaiknya dilayani dari CDN?
Istilah: GLOSSARY.md (bagian "Skalabilitas") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "Kenapa round robin bisa timpang?", "Apa beda health check aktif dan pasif?"
Sumber: [1] AWS: What is a Network Load Balancer? · [2] AWS: What is an Application Load Balancer? · [3] AWS: How Elastic Load Balancing works · [4] AWS: Create an HTTPS listener for your Application Load Balancer · [5] nginx: Using nginx as HTTP load balancer · [6] Google SRE Book, bab 20 Load Balancing in the Datacenter · [7] AWS: Edit target group attributes (routing algorithm, deregistration delay, sticky sessions) · [8] nginx: Module ngx_http_upstream_module · [9] AWS: Health checks for Application Load Balancer target groups · [10] Azure Architecture Center: Design to scale out · [11] Google SRE Book, bab 19 Load Balancing at the Frontend