Weighted Load Balancing #

Weight memungkinkan kamu mengontrol seberapa banyak traffic yang diterima setiap server secara proporsional. Secara default semua server memiliki weight 1 — artinya distribusi merata. Dengan weight, server yang lebih kuat bisa menerima lebih banyak request.

Konfigurasi Dasar #

upstream app_servers {
    # Server pertama menerima 3x lebih banyak request dari server kedua
    server 10.0.0.1:3000 weight=3;
    server 10.0.0.2:3000 weight=1;
}

Dengan konfigurasi di atas, dari setiap 4 request:

• 3 request → Server 10.0.0.1
• 1 request → Server 10.0.0.2

Weight adalah angka relatif — yang penting perbandingannya, bukan nilainya secara absolut. weight=3 dan weight=1 menghasilkan distribusi yang sama dengan weight=6 dan weight=2.

Use Case: Server dengan Kapasitas Berbeda #

Skenario paling umum: kamu punya server lama dan server baru dengan spesifikasi berbeda, dan ingin mendistribusikan traffic secara proporsional terhadap kapasitasnya.

upstream app_servers {
    # Server baru: 16 core, 32GB RAM
    server 10.0.0.1:3000 weight=4;

    # Server lama: 4 core, 8GB RAM
    server 10.0.0.2:3000 weight=1;
}

Atau ketika menambah server baru secara bertahap ke cluster:

upstream app_servers {
    server 10.0.0.1:3000 weight=10;  # Server lama, sudah proven
    server 10.0.0.2:3000 weight=10;  # Server lama
    server 10.0.0.3:3000 weight=2;   # Server baru, baru masuk cluster
}

Canary Deployment dengan Weight #

Weight sangat berguna untuk canary deployment — teknik merilis versi baru dengan mengirimkan sebagian kecil traffic terlebih dahulu untuk memvalidasi sebelum full rollout:

upstream app_servers {
    # Versi stabil (v1) - terima 95% traffic
    server 10.0.0.1:3000 weight=95;  # v1
    server 10.0.0.2:3000 weight=95;  # v1

    # Versi canary (v2) - terima 10% traffic dulu
    server 10.0.0.3:3000 weight=10;  # v2 canary
}

Jika v2 berperilaku baik, naikkan weightnya secara bertahap:

Tahap 1: v1=95, v2=5    (5% ke v2)
Tahap 2: v1=80, v2=20   (20% ke v2)
Tahap 3: v1=50, v2=50   (50-50)
Tahap 4: v1=0,  v2=100  (full rollout)

Kombinasi dengan Algoritma Lain #

Weight bisa dikombinasikan dengan least_conn dan ip_hash:

# Weighted least connections
upstream app_servers {
    least_conn;
    server 10.0.0.1:3000 weight=3;
    server 10.0.0.2:3000 weight=1;
}

Dengan kombinasi ini, server pertama akan mendapat lebih banyak koneksi sebelum dianggap “lebih sibuk” relatif terhadap server kedua. Misalnya, server pertama dengan 12 koneksi aktif dan server kedua dengan 4 koneksi aktif dianggap “sama sibuk” (12/3 = 4/1).

# Weighted ip_hash
upstream app_servers {
    ip_hash;
    server 10.0.0.1:3000 weight=3;
    server 10.0.0.2:3000 weight=1;
}

Blue-Green Deployment #

Variasi lain dari penggunaan weight untuk deployment zero-downtime:

upstream app_servers {
    # Blue (versi lama) - siapkan untuk dimatikan
    server 10.0.0.1:3000 weight=0 backup;

    # Green (versi baru) - terima semua traffic
    server 10.0.0.2:3000 weight=1;
}

Dengan weight=0 dan backup, server lama tidak menerima traffic tapi masih ada sebagai fallback darurat. Setelah versi baru terbukti stabil, server lama bisa benar-benar dihapus dari konfigurasi.

Ringkasan #

• weight=N mengontrol proporsi traffic secara relatif — server dengan weight=3 mendapat 3x lebih banyak request dari server dengan weight=1.
• Berguna untuk server dengan kapasitas berbeda agar distribusi beban sesuai kemampuan masing-masing.
• Canary deployment: mulai dengan weight kecil untuk versi baru, naikkan bertahap setelah terbukti stabil.
• Bisa dikombinasikan dengan least_conn untuk distribusi yang memperhitungkan bobot dan beban aktual sekaligus.

← Sebelumnya: IP Hash   Berikutnya: Health Check →