UNDER PRESSURE

Level 1 · Menggandakan Mesin

Sesi 9: Kalau Ada Dua Server, Siapa yang Menentukan? (Load Balancer & HAProxy)

Bayangkan jika ada dua loket layanan yang sama persis, dan seorang petugas berdiri di depan pintu mengarahkan pengunjung. Bagaimana petugas itu memilih ke mana tiap orang harus pergi?

Sesi 9 / 343 menit baca

1. Masalah Utama: Ilusi Dua Server

Ketika kamu menambah server dari 1 menjadi 2 (Server A dan Server B), muncul masalah baru di pintu masuk: - User di internet hanya tahu 1 domain (misal api.tokomu.com). - Domain hanya merujuk ke 1 alamat IP publik. - Siapa yang memutuskan request mana yang masuk ke Server A dan request mana yang masuk ke Server B?

Inilah tugas Load Balancer (Reverse Dispatcher / Traffic Director) seperti HAProxy, NGINX, atau AWS ALB.

2. Empat Algoritma Pemilihan (Load Balancing Algorithms)

Petugas pengarah (Load Balancer) memiliki beberapa strategi logika:

A. Round Robin (Bergantian Polos)

  • Logika: Request 1 ke A, Request 2 ke B, Request 3 ke A, Request 4 ke B.
  • Kapan Tepat: Semua request memiliki bobot kerja yang sama persis dan semua server memiliki kapasitas identik.
  • Kapan Salah (Jebakan): Jika Server A menerima request berat (generate report PDF 10 detik) sementara Server B menerima request ringan (cek status 10 ms). Round robin akan tetap mengirim request baru ke Server A, membuat Server A kelebihan muatan (overloaded).

B. Weighted Round Robin (Beban Berbobot)

  • Logika: Server A (kapasitas 8 core) diberi bobot weight 2, Server B (4 core) diberi bobot weight 1. Server A menerima 2 request untuk tiap 1 request ke Server B.
  • Kapan Tepat: Server di dalam cluster memiliki spesifikasi hardware yang berbeda (heterogeneous fleet).

C. Least Connections (Koneksi Paling Sedikit)

  • Logika: Kirim request berikutnya ke server yang saat ini sedang melayani koneksi aktif paling sedikit.
  • Kapan Tepat: Request memiliki durasi yang bervariasi (ada yang 10 ms, ada yang 5 detik, ada streaming/WebSocket).
  • Hasil: Mencegah terjadinya penumpukan beban di satu server yang sedang tertahan query berat.

D. IP Hash / Source Hashing

  • Logika: hash(IP_Klien) % Jumlah_Server. Klien dengan IP yang sama akan selalu diarahkan ke server yang sama.
  • Kapan Tepat: Solusi sementara ketika aplikasi belum stateless (sticky session sederhana).
  • Jebakan: Jika ada 10.000 user yang mengakses lewat 1 proxy kantor / NAT yang sama, semuanya akan dilempar ke 1 server yang sama (hotspot imbalance).

3. Health Check: Mata dan Telinga Load Balancer

Load balancer tidak boleh mengirim traffic ke server yang sudah mati atau sekarat.

                  ┌──────────────┐
                  │ Load Balancer│
                  └──────┬───────┘
          Health Check   │   Health Check
         GET /healthz    │   GET /healthz
               ┌─────────┴─────────┐
               ▼                   ▼
        ┌─────────────┐     ┌─────────────┐
        │  Server A   │     │  Server B   │
        │ HTTP 200 OK │     │ HTTP 500 /  │
        │  (HEALTHY)  │     │ TIMEOUT     │
        └─────────────┘     └─────────────┘
                                   │
                             [DRAINED / OFF]

Jebakan Health Check Dangkal vs Dalam:

  1. Shallow Health Check (/ping return 200 OK statis): - Hanya membuktikan web server (Nginx) hidup. - Tidak membuktikan database pool atau worker thread aplikasi bisa memproses query. - Server yang sedang error database tetap dianggap sehat dan terus dihujani traffic.
  2. Deep Health Check (/healthz cek DB, Redis, Disk): - Memastikan server benar-benar siap melayani end-to-end. - Perhatian: Jangan sampai health check query ke DB terlalu berat setiap 2 detik, karena ratusan LB health check bisa membebani database itu sendiri (self-inflicted DoS).

4. Konsep Graceful Drain (Maintenance Tanpa Downtime)

Ketika ingin meng-update aplikasi di Server B: 1. Ubah status Server B di Load Balancer menjadi DRAIN. 2. Load Balancer berhenti mengirim koneksi baru ke Server B. 3. Request yang sedang berjalan di Server B dibiarkan selesai (diberi waktu drain timeout, misal 30 detik). 4. Setelah koneksi aktif 0, Server B di-restart/di-deploy kode baru. 5. Jalankan health check, ubah status kembali menjadi READY / UP.

5. Ringkasan Desain Arsitektur

Komponen Peran Kunci
Virtual IP (VIP) Satu titik masuk publik yang dilihat oleh DNS
HAProxy / ALB Pemilih server tujuan berdasarkan algoritma & metrik kesehatan
Backend Pool Kumpulan node worker yang siap menerima beban
Health Check Sensor deteksi otomatis untuk mengisolasi server rusak
Graceful Drain Mekanisme update aplikasi tanpa memutus transaksi pengguna

6. Istilah Kunci

  • Load Balancer (LB): Pengarah beban lalu lintas jaringan.
  • HAProxy: Standar industri load balancer TCP/HTTP berkinerja tinggi.
  • Backend Pool / Target Group: Daftar server tujuan.
  • Round Robin: Distribusi bergantian sekuensial.
  • Least Connections: Distribusi ke server dengan koneksi aktif paling sedikit.
  • Health Check: Pemeriksaan berkala status hidup server.
  • Drain: Menghentikan traffic baru secara bertahap untuk perawatan server.