Belajar HAProxy - Load Balancing Algorithms & Health Checks

#Pendahuluan

Saat sebuah request masuk, bagaimana HAProxy memilih server? Jawabannya ada dua bagian: algoritma load balancing yang menentukan distribusi, dan health check yang memastikan server yang dipilih benar-benar sehat.

Episode 5 membedah keduanya secara tuntas. Kalian akan tahu kapan memakai roundrobin versus leastconn, bagaimana health check aktif dan pasif bekerja, serta cara menyiapkan backup server agar layanan tetap hidup saat server utama gagal.

#Algoritma Load Balancing

#roundrobin: Distribusi Bergantian

Ini algoritma default dan paling sederhana: setiap server dilayani secara bergantian sesuai bobotnya. Cocok untuk hampir semua kasus HTTP dengan server yang homogen.

backend web_back
    balance roundrobin
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check weight 2

Direktif balance roundrobin menyalakan rotasi bergantian, dan server web2 10.0.0.12:80 check weight 2 memberi bobot dua kali lipat sehingga web2 menerima porsi trafik lebih besar.

#leastconn: Prioritaskan Server Paling Longgar

Untuk koneksi yang berumur panjang — streaming, WebSocket, atau aplikasi yang menjaga koneksi terbuka — leastconn lebih adil:

backend ws_back
    balance leastconn
    server ws1 10.0.0.21:9000 check
    server ws2 10.0.0.22:9000 check

balance leastconn mengirim request baru ke server dengan jumlah koneksi aktif paling sedikit. Ini mencegah satu server menumpuk koneksi berdurasi panjang.

#source: Persistensi Berdasarkan IP

Algoritma source memetakan IP klien ke server secara konsisten melalui hashing. Klien yang sama selalu ke server yang sama, selama kumpulan server tidak berubah:

backend cache_back
    balance source
    hash-type consistent
    server cache1 10.0.0.31:80 check
    server cache2 10.0.0.32:80 check

hash-type consistent mengurangi lompatan pemetaan saat server ditambah atau dihapus — penting untuk cache layer.

#uri: Routing Berbasis Bagian URL

Untuk CDN atau cache konten, uri menghash bagian URI sehingga request untuk konten yang sama selalu ke server yang sama:

backend static_back
    balance uri
    hash-type consistent
    server s1 10.0.0.41:80 check
    server s2 10.0.0.42:80 check

balance uri cocok ketika cache lokal per server bisa dimanfaatkan maksimal.

#Active Health Check

#Pengertian dan Konfigurasi

Active health check adalah pemeriksaan yang diinisiasi HAProxy secara berkala ke server backend. Untuk HTTP, gunakan option httpchk untuk meminta endpoint tertentu:

backend api_back
    option httpchk GET /healthz
    http-check expect status 200
    server api1 10.0.0.51:8080 check inter 3s fall 3 rise 2

Direktif option httpchk GET /healthz memberitahu HAProxy untuk meminta path /healthz. Kata kunci check inter 3s fall 3 rise 2 berarti pengecekan tiap 3 detik, server dianggap mati setelah 3 kali gagal, dan sehat kembali setelah 2 kali sukses.

#Status Server

Urutan penandaan status pada server yang gagal health check:

• UP: server sehat dan menerima trafik.
• DOWN: server gagal dan tidak menerima trafik.
• MAINT: server dikeluarkan manual untuk maintenance.
• DRAIN: server tidak menerima trafik baru, tapi koneksi lama dilanjutkan.

Status bisa dilihat di halaman stats (episode 7) atau lewat runtime API (episode 9).

#Passive Health Check

#Mendeteksi Kegagalan dari Trafik Nyata

Passive health check tidak mengirim probe; dia menilai kegagalan dari request yang benar-benar terjadi. Direktif utama adalah maxconn per server dan fall pada level koneksi. Ketika koneksi ke server gagal, HAProxy menghitungnya sebagai kegagalan dan bisa menurunkan server.

backend api_back
    server api1 10.0.0.61:8080 maxconn 2000
    server api2 10.0.0.62:8080 maxconn 2000

Direktif server api1 10.0.0.61:8080 maxconn 2000 membatasi koneksi per server; jika server menolak koneksi tambahan, HAProxy memilih server lain. Kombinasi active dan passive check memberikan pertahanan berlapis.

#Menyesuaikan Toleransi Kegagalan

Tuning default yang umum disesuaikan:

• inter: interval antar probe.
• fall: jumlah kegagalan sebelum server dianggap DOWN.
• rise: jumlah sukses sebelum server kembali UP.
• timeout connect: batas waktu koneksi ke server.

#Failover dengan Backup Server

#Konfigurasi Backup Server

Backup server menerima trafik hanya ketika semua server utama DOWN. Ini lapisan terakhir sebelum layanan benar-benar mati:

backend web_back
    balance roundrobin
    option httpchk GET /healthz
    server web1 10.0.0.71:80 check
    server web2 10.0.0.72:80 check
    server dr 10.0.0.99:80 check backup

Server dengan kata kunci backup di server dr 10.0.0.99:80 check backup hanya aktif saat semua server utama gagal health check. Backup bisa berupa server di region lain atau kapasitas minimal.

#Menguji Failover

Untuk menguji, matikan semua server utama lalu lihat apakah trafik pindah ke backup:

sudo systemctl stop python-http-8080
curl -s http://localhost/ | head -n 1

curl -s http://localhost/ | head -n 1 menampilkan respons dari server yang melayani. Jika semua server utama mati dan backup hidup, jawaban harus berasal dari backup.

#Penutup

Episode 5 memberi kalian dua kendali inti load balancing: algoritma untuk distribusi yang tepat dan health check untuk ketersediaan yang bisa dipercaya. Kombinasi keduanya menentukan kualitas layanan di mata pengguna.

Inti yang harus dibawa pulang:

• roundrobin untuk distribusi umum; leastconn untuk koneksi panjang.
• source dan uri memakai hashing untuk persistensi berbasis IP atau URL.
• Active health check memakai probe berkala; passive memakai trafik nyata.
• Kuasai inter, fall, dan rise untuk mengatur toleransi.
• Backup server adalah jaring pengaman terakhir saat semua server utama DOWN.

Di episode 6 selanjutnya kita akan membahas HTTP routing, headers & rewrite — path-based dan host-based routing, manipulasi header request dan response, redirect, serta cookie-based persistence untuk session affinity.