L
High Availability & Scaling • Literally Web ID

Membangun Kluster High Availability dengan Nginx, Keepalived, dan Redis Sentinel

⏱️ 18 menit baca • 📅 14 Oct 2026 • 👁️ 1 views
Membangun Kluster High Availability dengan Nginx, Keepalived, dan Redis Sentinel

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, ketersediaan tinggi (High Availability atau disingkat HA) bukan lagi sebuah fitur tambahan (nice-to-have), melainkan sebuah keharusan fundamental (mission-critical requirement). Ketika sebuah aplikasi web mengalami lonjakan traffic atau, yang lebih buruk, mengalami kegagalan infrastruktur (single point of failure / SPOF), dampaknya langsung merembet ke hilir: penurunan pendapatan, kerusakan reputasi brand, dan pelanggaran perjanjian tingkat layanan (SLA).

Secara historis, infrastruktur web sering kali dibangun menggunakan satu instance server web yang menjalankan Nginx, terhubung langsung ke satu instance database MySQL, dan menyimpan sesi atau cache pada memori lokal server tersebut. Pendekatan ini rentan terhadap berbagai titik kegagalan:

  • Jika proses Nginx atau server fisik mati, seluruh layanan langsung tidak dapat diakses.
  • Jika terjadi lonjakan permintaan bersamaan (high concurrency), beban CPU dan memori terkonsentrasi pada satu titik, menyebabkan bottleneck pada I/O jaringan maupun pemrosesan backend seperti PHP-FPM, Node.js, atau Go.
  • Dalam konteks stateful layer seperti Redis untuk caching atau message broker, kehilangan satu instance Redis dapat melumpuhkan sistem manajemen sesi pengguna jika tidak ada arsitektur replikasi dan failover otomatis.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan Kluster HA

Parameter Sebelum (Arsitektur Monolitik / SPOF) Sesudah (Kluster HA Nginx + Keepalived + Redis Sentinel)
Uptime SLA 99.0% hingga 99.5% (~3.5 hingga 87 jam downtime per tahun) 99.99% (~52 menit downtime per tahun)
Penanganan Traffic Terbatas pada kapasitas satu instance server fisik/VPS Distribusi beban (Load Balancing) melintasi multiple node worker
Pemulihan Kegagalan Manual (intervensi sysadmin diperlukan untuk restart/DNS switch) Otomatis melalui VRRP (Virtual Router Redundancy Protocol) & Sentinel
Konsistensi State Rentan hilang saat server restart (local memory cache) Terdistribusi dan persisten melalui Redis Master-Replica Sentinel
Keamanan & Skala Rentan terhadap saturasi bandwidth dan serangan DDoS Terisolasi di balik reverse proxy pool dan arsitektur decoupled

2. Konsep Inti & Deep Dive Arsitektur

Untuk mencapai ketahanan tingkat enterprise, kita memerlukan kombinasi tiga komponen utama yang bekerja secara sinkron:

  1. Nginx Upstream Load Balancer: Berfungsi sebagai reverse proxy terdepan yang menerima seluruh trafik masuk, melakukan health checking, dan mendistribusikannya secara merata ke backend application servers (Node.js, PHP-FPM, Go, dll) menggunakan algoritma seperti least_conn atau ip_hash.
  2. Keepalived (VRRP): Memastikan ketersediaan lapisan load balancer itu sendiri. Keepalived mengikat alamat IP virtual (Virtual IP / VIP) bersama di antara dua atau lebih server Nginx. Jika node Nginx utama (Master) down, node cadangan (Backup) akan mendeteksi hilangnya sinyal heartbeat dan langsung mengambil alih VIP tersebut dalam hitungan detik tanpa intervensi manual.
  3. Redis Sentinel: Mengelola kluster database Redis yang terdiri dari satu Master dan minimal dua Replica. Sentinel secara konstan memantau kesehatan node Master. Jika Master gagal merespons, Sentinel melakukan pemilihan (election) secara otomatis untuk mempromosikan salah satu Replica menjadi Master baru, serta memperbarui konfigurasi klien aplikasi secara dinamis.
+-------------------------------------------------------------+
|                        Client Requests                      |
+-------------------------------------------------------------+
                               |
                               v
                  +-------------------------+
                  | Virtual IP (VIP)        |
                  | 192.168.1.100           |
                  +-------------------------+
                   /                       \
                  v                         v
      +-----------------------+   +-----------------------+
      |    Nginx Master       |   |    Nginx Backup       |
      |    (Keepalived MASTER)|   |    (Keepalived BACKUP)|
      +-----------------------+   +-----------------------+
                  \                         /
                   v                       v
+-----------------------------------------------------------------+
|                   Backend Application Cluster                   |
|         (Node.js / PHP-FPM / Go / Python Workers)               |
+-----------------------------------------------------------------+
                               |
                               v
+-----------------------------------------------------------------+
|                     Redis Sentinel Cluster                      |
|     +------------------+     +------------------+               |
|     |  Redis Master    | <-> |  Redis Replica   |               |
|     +------------------+     +------------------+               |
|              ^                                                  |
|              | (Monitored by Sentinels)                         |
|     +------------------+                                        |
|     |  Redis Sentinel  |                                        |
|     +------------------+                                        |
+-----------------------------------------------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam merancang sistem load balancing dan high availability, terdapat beberapa opsi pendekatan arsitektural yang sering dipertimbangkan oleh Infrastructure Engineers:

Pendekatan / Teknologi Kelebihan Kekurangan Konsumsi Sumber Daya
DNS Round-Robin Sangat murah, tidak perlu server perantara khusus. DNS caching pada klien/ISP menyebabkan failover sangat lambat (bisa berjam-jam). Sangat rendah di sisi server DNS.
Hardware Load Balancer (F5, A10) Performa sangat tinggi, dukungan fitur L4-L7 komprehensif. Biaya lisensi dan perangkat keras sangat mahal (vendor lock-in). Tinggi pada perangkat khusus.
Nginx + Keepalived (Software HA) Open-source, fleksibel, mudah dikustomisasi, performa tinggi. Membutuhkan keahlian manajemen Linux dan konfigurasi manual. Sedang (Bergantung pada jumlah koneksi aktif Nginx).
HAProxy + Corosync/Pacemaker Sangat handal untuk layer 4/7, manajemen kluster korporat. Kompleksitas konfigurasi Pacemaker sangat tinggi dan rentan split-brain. Sedang-Tinggi.

[!TIP] Kombinasi Nginx dan Keepalived adalah standar industri (industry standard) untuk arsitektur berbasis cloud swasta (on-premise) maupun hybrid cloud karena keseimbangan optimal antara kemudahan pemeliharaan, performa rekayasa, dan biaya lisensi nol (open source).


4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi teknis, pastikan Anda telah menyiapkan environment berikut:

  • OS: Ubuntu Server 22.04 LTS / 24.04 LTS (atau Debian 12) bersih pada minimal 4 node server.
    • Node 1 (Load Balancer 1 / Nginx + Keepalived Master): 192.168.1.10
    • Node 2 (Load Balancer 2 / Nginx + Keepalived Backup): 192.168.1.11
    • Node 3 (Backend & Redis Master): 192.168.1.20
    • Node 4 (Backend & Redis Replica + Sentinel): 192.168.1.21
  • Virtual IP (VIP): 192.168.1.100
  • Akses Root / Sudo: Diperlukan akses administratif penuh pada seluruh node.
  • Firewall (UFW / iptables): Pastikan port HTTP (80), HTTPS (443), VRRP (IP Protocol 112), Redis (6379), dan Redis Sentinel (26379) dikonfigurasi dengan benar.

Verifikasi jaringan awal pada Node 1 dan Node 2:

sudo apt update && sudo apt upgrade -y
sudo apt install curl ufw net-tools htop -y

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi Nginx Upstream Load Balancer (Node 1 & Node 2)

Instal Nginx pada kedua node load balancer:

sudo apt install nginx -y

Buat file konfigurasi upstream dan server block pada /etc/nginx/conf.d/ha_cluster.conf:

upstream backend_cluster {
    # Menggunakan algoritma least_connection untuk distribusi beban optimal
    least_conn;
    
    server 192.168.1.20:8080 max_fails=3 fail_timeout=10s;
    server 192.168.1.21:8080 max_fails=3 fail_timeout=10s;
    
    # Keepalive connections ke backend untuk mengurangi latensi TCP handshake
    keepalive 32;
}

server {
    listen 80;
    server_name example.com www.example.com;

    access_log /var/log/nginx/ha_access.log;
    error_log /var/log/nginx/ha_error.log;

    location / {
        proxy_pass http://backend_cluster;
        proxy_http_version 1.1;
        
        # Header penerusan untuk aplikasi backend
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Pengaturan timeout
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    # Endpoint kesehatan untuk monitoring eksternal
    location /healthz {
        access_log off;
        return 200 "healthy\n";
        add_type text/plain;
    }
}

Uji sintaks dan restart Nginx:

sudo nginx -t
sudo systemctl restart nginx
sudo systemctl enable nginx

Langkah 2: Konfigurasi Keepalived untuk Automatic Failover (Node 1 & Node 2)

Instal Keepalived pada Node 1 dan Node 2:

sudo apt install keepalived -y

Buat skrip health check Nginx di /etc/keepalived/check_nginx.sh agar Keepalived dapat mendeteksi jika proses Nginx mati:

#!/bin/bash
if ! pgrep -x "nginx" > /dev/null; then
    exit 1
else
    exit 0
fi

Berikan izin eksekusi pada skrip tersebut:

sudo chmod +x /etc/keepalived/check_nginx.sh

Konfigurasi Keepalived Master (Node 1 - 192.168.1.10)

Tulis file konfigurasi di /etc/keepalived/keepalived.conf:

global_defs {
    router_id LVS_DEBIAN_MASTER
    enable_script_security
    script_user root
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight 2
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecretAuthKey99!
    }
    
    virtual_ipaddress {
        192.168.1.100/24
    }
    
    track_script {
        check_nginx
    }
}

Konfigurasi Keepalived Backup (Node 2 - 192.168.1.11)

Tulis file konfigurasi di /etc/keepalived/keepalived.conf:

global_defs {
    router_id LVS_DEBIAN_BACKUP
    enable_script_security
    script_user root
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    weight 2
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecretAuthKey99!
    }
    
    virtual_ipaddress {
        192.168.1.100/24
    }
    
    track_script {
        check_nginx
    }
}

Nyalakan dan aktifkan layanan Keepalived pada kedua node:

sudo systemctl restart keepalived
sudo systemctl enable keepalived

Langkah 3: Konfigurasi Redis Sentinel Cluster (Node 3 & Node 4)

Instal Redis Server pada Node 3 (192.168.1.20) dan Node 4 (192.168.1.21):

sudo apt install redis-server -y

Konfigurasi Redis Master (Node 3)

Edit /etc/redis/redis.conf:

bind 0.0.0.0
protected-mode no
port 6379
daemonize no
supervised systemd
pidfile /var/run/redis/redis-server.pid
loglevel notice
logfile /var/log/redis/redis-server.log
databases 16
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /var/lib/redis
requirepass RedisMasterSecurePassword2024!
masterauth RedisMasterSecurePassword2024!

Konfigurasi Redis Replica (Node 4)

Edit /etc/redis/redis.conf di Node 4 dengan tambahan baris replikasi:

bind 0.0.0.0
protected-mode no
port 6379
daemonize no
supervised systemd
pidfile /var/run/redis/redis-server.pid
loglevel notice
logfile /var/log/redis/redis-server.log
databases 16
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /var/lib/redis
replicaof 192.168.1.20 6379
requirepass RedisMasterSecurePassword2024!
masterauth RedisMasterSecurePassword2024!

Restart Redis pada kedua node:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Konfigurasi Redis Sentinel (Node 3 & Node 4)

Instal paket sentinel (biasanya sudah termasuk dalam redis-server di Ubuntu):`

Edit /etc/redis/sentinel.conf pada Node 3 dan Node 4:

port 26379
daemonize no
pidfile /var/run/redis/redis-sentinel.pid
logfile /var/log/redis/redis-sentinel.log
dir /var/lib/redis

# Memantau Redis Master di Node 3, kuorum 2 berarti minimal 2 sentinel setuju jika master down
sentinel monitor mymaster 192.168.1.20 6379 2

sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel auth-pass mymaster RedisMasterSecurePassword2024!

sentinel parallel-syncs mymaster 1

Jalankan layanan Sentinel:

sudo systemctl restart redis-sentinel
sudo systemctl enable redis-sentinel

6. Bedah Kode & Penjelasan Detail Baris Kunci

  1. least_conn; pada Nginx Upstream: Mengarahkan trafik baru ke server backend dengan jumlah koneksi aktif paling sedikit. Sangat efektif ketika backend memproses tugas berat dengan durasi eksekusi bervariasi.
  2. vrrp_script check_nginx: Mekanisme proaktif di Keepalived. Jika Nginx mengalami crash, skrip mengembalikan exit code 1, yang secara otomatis menurunkan priority node Master sebesar weight 2 (dari 101 menjadi 99), membuat Node Backup mengambil alih VIP secara instan.
  3. sentinel monitor mymaster 192.168.1.20 6379 2: Parameter kunci dalam Redis Sentinel. Angka 2 adalah quorum. Jika satu sentinel terputus koneksinya, proses failover tidak akan sembarangan dieksekusi sampai ada konsensus dari sentinel lainnya, mencegah terjadinya split-brain akibat masalah jaringan sementara (flapping).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada lingkungan e-commerce skala besar dengan flash sale, lonjakan trafik mencapai 50.000 requests per second (RPS). Pendekatan arsitektur di atas meredam beban dengan cara:

  • Nginx membuang koneksi ilegal di lapisan terdepan menggunakan pembatasan rate (rate-limiting) dan memelihara keepalive connection ke pool aplikasi.
  • Ketika Node 1 mengalami pemadaman daya mendadak, Keepalived memindahkan Virtual IP 192.168.1.100 ke Node 2 dalam waktu kurang dari 800 milidetik. Pengguna akhir tidak merasakan gangguan selain jeda milidetik pada koneksi TCP yang sedang berlangsung.
  • Aplikasi backend yang terhubung ke Redis melakukan query ke Sentinel untuk mendapatkan alamat master aktif secara real-time, memastikan penyimpanan sesi keranjang belanja (shopping cart) tetap utuh meskipun node database utama gagal.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Kesalahan Fatal 1: Mengabaikan Pengaturan non-default pada net.ipv4.ip_nonlocal_bind Kegagalan umum saat menjalankan Keepalived adalah kernel Linux menolak pengikatan Virtual IP karena IP tersebut belum ada pada interface fisik saat layanan start. Solusi: Tambahkan baris net.ipv4.ip_nonlocal_bind=1 ke /etc/sysctl.conf lalu jalankan sudo sysctl -p.

[!WARNING] Kesalahan Fatal 2: Konfigurasi Split-Brain pada Redis Sentinel Menyiapkan jumlah sentinel genap (misal 2 node) tanpa majority quorum. Jika jaringan terbelah menjadi dua, kedua sentinel dapat mendeklarasikan diri sebagai master secara bersamaan. Solusi: Gunakan jumlah node sentinel ganjil (minimal 3 node, atau letakkan saksi/observer pihak ketiga) untuk memastikan quorum mutlak tercapai.


9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster, gunakan utilitas benchmarking modern seperti wrk atau k6.

Contoh perintah pengujian beban menggunakan wrk pada Virtual IP:

wrk -t12 -c400 -d30s http://192.168.1.100/healthz

Parameter Tuning Kernel Linux (/etc/sysctl.conf)

Terapkan tuning performa jaringan berikut pada semua node load balancer dan backend:

# Meningkatkan jumlah maksimum koneksi dalam antrean TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Reuse koneksi TIME_WAIT untuk menangani port exhaustion
net.ipv4.tcp_tw_reuse = 1

# Memperluas rentang port ephemeral
net.ipv4.ip_local_port_range = 1024 65535

Terapkan perubahan dengan perintah sudo sysctl -p.


10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan kluster High Availability ini ke lingkungan produksi publik, pastikan seluruh item berikut telah diverifikasi:

  • Uji skenario pemutusan kabel jaringan secara fisik (hard pull) pada node Nginx Master untuk memvalidasi kecepatan failover Keepalived.
  • Uji simulasi kill process redis-server pada master database dan pastikan Redis Sentinel mempromosikan replika dalam waktu < 5 detik.
  • Verifikasi seluruh hak akses file konfigurasi (chmod 600 untuk file yang mengandung password atau secret auth key).
  • Pastikan log rotasi (logrotate) telah dikonfigurasi untuk Nginx dan Redis guna mencegah kehabisan ruang disk.
  • Integrasikan monitoring pihak ketiga (seperti Prometheus + Grafana atau Datadog) untuk memantau metrik kunci: CPU, Memory, Active Connections, dan Status VRRP.

Dengan menerapkan panduan komprehensif ini, Anda telah membangun infrastruktur web backend yang tangguh, tahan banting, dan siap menghadapi skala enterprise dengan ketersediaan mendekati mutlak.

🏷️ Tags: #Nginx #Redis #High Availability #Load Balancing #Keepalived