Belajar Nginx - Load Balancing Algorithms & Upstream Management

#Pendahuluan

Satu backend tidak pernah cukup di produksi. Ketika aplikasi harus melayani ribuan request per detik atau bertahan saat satu server down, kalian butuh load balancing. Episode 7 ini membahas cara NGINX mendistribusikan trafik ke beberapa backend.

Kalian akan mendefinisikan cluster backend dengan block upstream, memilih algoritma load balancing yang tepat sesuai kebutuhan, memahami perbedaan weighted round robin, least connections, IP hash, dan generic hash, serta memanfaatkan parameter max_fails, fail_timeout, backup, dan down.

#Mendefinisikan Backend Cluster

#Block upstream

Block upstream menggabungkan beberapa server backend menjadi satu pool logis:

upstream backend_app {
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
    server 10.0.1.13:3000;
}
 
server {
    listen 80;
    server_name app.example.com;
 
    location / {
        proxy_pass http://backend_app;
    }
}

Nama backend_app dipakai sebagai target proxy_pass. NGINX membagi request ke tiga backend berdasarkan algoritma yang dipilih.

#Server dengan Parameter

Setiap entry server dalam upstream bisa memakai parameter tambahan:

upstream backend_app {
    server 10.0.1.11:3000 weight=3;
    server 10.0.1.12:3000 max_fails=2 fail_timeout=30s;
    server 10.0.1.13:3000 backup;
    server 10.0.1.14:3000 down;
}

• weight=3 — backend menerima proporsi trafik tiga kali lipat.
• max_fails dan fail_timeout — pengaturan health check pasif.
• backup — hanya dipakai jika semua server utama tidak tersedia.
• down — backend dimatikan tanpa menghapus konfigurasi.

#Algoritma Load Balancing NGINX

#Round Robin (Default)

Tanpa pengaturan apa pun, NGINX memakai round robin: request dibagi rata secara bergiliran ke setiap backend. Sederhana dan adil selama semua backend homogen.

upstream backend_app {
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
}

#Weighted Round Robin

Dengan weight, backend yang lebih besar mendapat porsi lebih besar:

upstream backend_app {
    server 10.0.1.11:3000 weight=3;
    server 10.0.1.12:3000 weight=1;
}

#Least Connections

Directive least_conn mengirim request ke backend dengan jumlah koneksi aktif paling sedikit:

upstream backend_app {
    least_conn;
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
}

Cocok untuk request yang durasinya tidak seragam, seperti upload file atau long polling.

#IP Hash

ip_hash mengikat klien ke backend yang sama berdasarkan hash IP-nya. Ini memberikan session persistence tanpa konfigurasi sticky di aplikasi:

upstream backend_app {
    ip_hash;
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
}

Client yang sama selalu diarahkan ke backend yang sama, asalkan backend tersebut sehat.

#Generic Hash

hash memakai nilai yang kita tentukan, misalnya URI request, untuk memilih backend:

upstream backend_app {
    hash $request_uri consistent;
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
}

Parameter consistent membuat mapping tetap stabil ketika daftar backend berubah — teknik ketogen hash yang mengurangi cache miss besar-besaran.

#Passive Health Checks dan Server States

#Konsep Dasar

NGINX open source melakukan passive health check: backend dianggap gagal setelah gagal melayani beberapa request dalam periode tertentu:

upstream backend_app {
    server 10.0.1.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:3000 max_fails=3 fail_timeout=30s;
}

Setelah 3 kegagalan dalam 30 detik, backend ditandai tidak sehat dan tidak menerima trafik selama fail_timeout. Setelah periode itu, NGINX mencoba mengirim request lagi — jika sukses, backend kembali aktif secara otomatis. Inilah resilience yang membuat NGINX populer.

#Memantau Hasil Load Balancing

Lihat log error untuk melihat event upstream:

sudo tail -f /var/log/nginx/error.log

tail -f menampilkan kejadian backend naik dan turun. Kombinasikan dengan curl -I berulang untuk menguji distribusi trafik ke semua backend.

#Penutup

Episode 7 menuntaskan load balancing: kalian bisa menggabungkan backend dalam block upstream, memilih algoritma yang sesuai, dan menerapkan health check pasif dengan max_fails, fail_timeout, backup, serta down.

Inti yang harus dibawa pulang:

• Block upstream mengelompokkan backend menjadi satu pool logis.
• Round robin default; weight untuk backend dengan kapasitas berbeda.
• least_conn untuk request berdurasi tidak seragam.
• ip_hash memberi session persistence; hash ... consistent stabil saat cluster berubah.
• Health check pasif memakai max_fails dan fail_timeout.
• backup menyiapkan cadangan, down menonaktifkan backend.

Di episode 8 selanjutnya kita akan membahas HTTP caching dan microcaching — menyiapkan proxy_cache_path, mengaktifkan cache dengan proxy_cache, membaca status cache lewat X-Cache-Status, serta strategi microcaching untuk menahan lonjakan trafik mendadak.