IP Hash #

IP hash adalah algoritma load balancing yang memastikan request dari IP address yang sama selalu diarahkan ke server yang sama. Ini adalah salah satu cara mengimplementasikan session persistence — kemampuan agar satu user terus terhubung ke server yang sama sepanjang sesi mereka.

Mengapa Session Persistence Dibutuhkan #

Tidak semua aplikasi membutuhkan session persistence, tapi ada kasus di mana ini penting:

Aplikasi dengan session berbasis memori lokal. Jika aplikasi menyimpan state user di memori server (bukan di database atau Redis), request dari user yang sama harus selalu ke server yang sama, karena hanya server itu yang punya data sesinya.

Upload file multi-part. Jika user mengupload file besar dalam beberapa bagian (chunk), semua bagian harus ke server yang sama agar bisa digabungkan dengan benar.

Proses multi-langkah. Wizard atau proses checkout multi-step yang menyimpan state di antara request.

Konfigurasi ip_hash #

upstream app_servers {
    ip_hash;   # Aktifkan session persistence berbasis IP

    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    location / {
        proxy_pass http://app_servers;
    }
}

Nginx menghitung hash dari IP address klien dan menggunakannya untuk menentukan server tujuan. Karena hash dari IP yang sama selalu menghasilkan nilai yang sama, request dari IP yang sama akan selalu ke server yang sama — selama konfigurasi upstream tidak berubah.

Mengeluarkan Server dari Rotasi dengan ip_hash #

Ketika menggunakan ip_hash, kamu tidak bisa begitu saja menghapus server dari upstream — ini akan mengubah pemetaan hash dan memutus sesi semua user. Gunakan parameter down untuk menandai server sementara tidak tersedia tanpa mengubah pemetaan:

upstream app_servers {
    ip_hash;

    server 10.0.0.1:3000;
    server 10.0.0.2:3000 down;   # Tandai down tapi tetap di hitungan hash
    server 10.0.0.3:3000;
}

Dengan down, Nginx tetap menghitung server itu dalam mapping hash (sehingga tidak mengacak distribusi), tapi tidak mengirim request ke sana.

Keterbatasan IP Hash #

IP hash punya beberapa keterbatasan yang penting dipahami:

Di balik NAT atau proxy bersama. Banyak pengguna yang berbagi satu IP public (misalnya semua karyawan kantor di balik NAT, atau pengguna di balik Cloudflare). Mereka semua akan diarahkan ke server yang sama, menyebabkan distribusi yang sangat tidak merata.

IPv6 dan mobile. Pengguna mobile bisa berpindah IP saat berganti jaringan (WiFi ke 4G), memutus sesi mereka meski sedang di tengah operasi.

Distribusi tidak merata. Tidak ada jaminan bahwa hash akan mendistribusikan user secara merata — tergantung pada distribusi IP yang aktif.

Untuk session persistence yang lebih andal, gunakan hash berdasarkan cookie session daripada IP:

upstream app_servers {
    hash $cookie_session_id consistent;

    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

Parameter consistent menggunakan consistent hashing (kettle hash) — ketika server ditambah atau dihapus, hanya sebagian kecil user yang berpindah server, bukan semua user di-rebalance ulang. Sangat berguna untuk cache servers atau ketika perubahan routing harus diminimalkan.

Kamu bisa menggunakan variabel apapun sebagai basis hash:

upstream app_servers {
    # Hash berdasarkan header X-User-ID yang dikirim aplikasi
    hash $http_x_user_id consistent;

    # Hash berdasarkan kombinasi IP dan User-Agent
    # (sedikit lebih baik dari IP saja untuk NAT)
    hash "$remote_addr$http_user_agent" consistent;

    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
}

Solusi yang Lebih Baik dari Session Persistence #

Sebenarnya, kebutuhan akan session persistence sering merupakan tanda bahwa arsitektur aplikasi bisa diperbaiki. Beberapa pendekatan yang menghilangkan ketergantungan pada session persistence:

Pindahkan session ke shared store. Simpan data session di Redis atau database yang bisa diakses semua server. Setiap server bisa melayani request dari user manapun karena data sesinya ada di tempat terpusat.

JWT untuk autentikasi stateless. Token JWT menyimpan semua informasi yang dibutuhkan di dalam token itu sendiri — tidak ada yang perlu disimpan di server.

Arsitektur dengan session persistence:
User → Nginx (ip_hash) → Server A (punya session user)
                       → Server B (tidak punya session user)

Arsitektur yang lebih baik:
User → Nginx (round robin) → Server A
                           → Server B
                                ↕
                           [Redis session store]
                           (semua server akses session yang sama)

Ringkasan #

ip_hash memastikan request dari IP yang sama selalu ke server yang sama — berguna untuk aplikasi dengan session berbasis memori lokal.
Gunakan parameter down (bukan hapus server) untuk menonaktifkan server sementara tanpa mengacak pemetaan hash.
Keterbatasan: pengguna di balik NAT berbagi IP → distribusi tidak merata; pengguna mobile bisa berpindah IP → sesi terputus.
hash $cookie_session_id consistent adalah alternatif yang lebih andal dari ip_hash untuk session persistence.
Solusi terbaik jangka panjang: pindahkan session ke Redis atau shared store dan buat aplikasi stateless — session persistence tidak lagi diperlukan.

← Sebelumnya: Least Connections Berikutnya: Weighted Load Balancing →