Arsitektur High Availability dan Load Balancing Berbasis Nginx & Keepalived

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ketersediaan tinggi (High Availability / HA) bukan lagi sekadar fitur tambahan untuk aplikasi enterprise, melainkan sebuah keharusan (mandatory requirement). Bayangkan sebuah platform e-commerce skala menengah yang mengalami downtime hanya selama 15 menit saat puncak transaksi. Kerugian finansial yang ditimbulkan bisa mencapai ratusan juta rupiah, belum lagi hilangnya kepercayaan pelanggan (brand reputation loss) yang dampaknya bersifat jangka panjang.

Secara historis, kegagalan sistem web sering kali berakar pada titik tunggal kegagalan (Single Point of Failure atau SPOF). Dalam arsitektur tradisional, sebuah aplikasi web sering kali di-host di balik satu server Reverse Proxy (Nginx) yang mengarah langsung ke server backend (PHP-FPM, Node.js, Go) dan database (MySQL/MariaDB). Ketika server Nginx utama tersebut mengalami kegagalan perangkat keras (hardware failure), kernel panic, atau kegagalan jaringan (network partition), seluruh layanan web menjadi tidak dapat diakses sama sekali.

[!WARNING] Ketergantungan pada satu alamat IP publik atau satu instance Load Balancer adalah bom waktu operasional. Tanpa mekanisme failover otomatis, waktu pemulihan (Mean Time to Recovery / MTTR) akan bergantung sepenuhnya pada seberapa cepat administrator sistem menyadari gangguan dan melakukan intervensi manual.

Analisis Kondisi: Sebelum vs Sesudah Penerapan HA

2. Konsep Inti & Deep Dive Arsitektur

Untuk mengeliminasi SPOF pada lapisan Load Balancer, kita memerlukan kombinasi dua teknologi utama: Nginx sebagai mesin reverse proxy dan load balancer berkinerja tinggi, serta Keepalived yang mengimplementasikan protokol VRRP (Virtual Router Redundancy Protocol) untuk mengelola Virtual IP (VIP) bersama.

Cara Kerja di Balik Layar (Under the Hood)

1. Virtual IP (VIP) Management: Dua server load balancer (kita sebut LB1 sebagai Master dan LB2 sebagai Backup) dikonfigurasi dalam satu subnet jaringan yang sama. Keduanya memiliki alamat IP fisik masing-masing, namun mereka berbagi satu Alamat IP Virtual (VIP) yang bertindak sebagai titik akses utama bagi seluruh pengguna internet dan DNS publik.
2. VRRP Heartbeat: Server Master (LB1) secara periodik (menggunakan interval waktu tertentu, misalnya setiap detik) mengirimkan paket multicast VRRP ke jaringan lokal untuk mengabarkan bahwa dirinya masih hidup (alive).
3. Failover Otomatis: Jika LB1 mengalami kegagalan total, terputus dari jaringan, atau layanan Nginx-nya mati (dideteksi melalui script tracking), LB2 yang berstatus sebagai Backup akan berhenti mendeteksi sinyal heartbeat dari LB1. Dalam hitungan detik, LB2 akan mengambil alih kepemilikan VIP tersebut, mengumumkan dirinya sebagai Master baru menggunakan Gratuitous ARP (GARP), dan lalu lintas jaringan dialihkan sepenuhnya ke LB2 tanpa disadari oleh klien.

+-------------------------------------------------------------------------+
|                        Klien / DNS Publik                               |
+-------------------------------------------------------------------------+
                                     |
                                     v
                     +-------------------------------+ 
                     |      Virtual IP (VIP)         |
                     |        192.168.1.100          |
                     +-------------------------------+ 
                            /                 \
                           /                   \
                          v                     v
       +--------------------------+    +--------------------------+
       |    Load Balancer 1       |    |    Load Balancer 2       |
       |    (Master - VRRP)       |    |    (Backup - VRRP)       |+
       |  IP Fisik: 192.168.1.101 |    |  IP Fisik: 192.168.1.102 |+
       |     Nginx + Keepalived   |    |     Nginx + Keepalived   |
       +--------------------------+    +--------------------------+
                    \                     /
                     \                   /
                      v                 v
+-------------------------------------------------------------------------+
|                         Backend Web Clusters                            | 
|     (Node 1: PHP-FPM/Go)    (Node 2: PHP-FPM/Go)    (Node 3: Redis)     |
+-------------------------------------------------------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih arsitektur penyeimbang beban dan ketersediaan tinggi memerlukan analisis mendalam terhadap konsumsi sumber daya, kompleksitas, dan kebutuhan bisnis:

[!TIP] Kombinasi Nginx + Keepalived memberikan keseimbangan terbaik antara kontrol penuh atas infrastruktur, efisiensi biaya (Self-Hosted / Bare Metal / VPS), dan keandalan tingkat enterprise tanpa terikat oleh ekosistem vendor cloud tertentu (vendor lock-in).

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi konfigurasi, pastikan lingkungan sistem Anda memenuhi spesifikasi berikut:

• Sistem Operasi: Ubuntu Server 22.04 LTS / 24.04 LTS atau Debian 12 (Bersih dan minimal).
• Node Infrastruktur Minimal:
  • LB-Master: IP Fisik 192.168.1.101, Hostname: lb-01
  • LB-Backup: IP Fisik 192.168.1.102, Hostname: lb-02
  • Virtual IP (VIP): 192.168.1.100
• Akses Jaringan: Pastikan port multicast diizinkan di dalam jaringan lokal (atau gunakan unicast VRRP jika berada di lingkungan Cloud seperti AWS/GCP yang memblokir paket multicast).
• Hak Akses: Akses root atau sudo pada kedua node Load Balancer.

Verifikasi Awal Jaringan

Jalankan perintah berikut untuk mengecek nama interface jaringan Anda (misalnya eth0 atau ens33):

ip -c a

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Nginx dan Keepalived pada Kedua Node

Lakukan perintah ini pada kedua server (lb-01 dan lb-02):

sudo apt update && sudo apt upgrade -y
sudo apt install nginx keepalived curl -y
sudo systemctl enable nginx
sudo systemctl enable keepalived

Langkah 2: Konfigurasi Nginx sebagai Reverse Proxy dan Upstream Backend

Buat file konfigurasi upstream pada /etc/nginx/conf.d/backend_cluster.conf di kedua node Load Balancer:

upstream enterprise_backend {
    # Daftar server backend (PHP-FPM, Node.js, atau Go)
    server 192.168.1.201:8080 max_fails=3 fail_timeout=10s;
    server 192.168.1.202:8080 max_fails=3 fail_timeout=10s;
    
    # Menjaga koneksi tetap hidup untuk performa maksimal
    keepalive 32;
}

server {
    listen 80;
    server_name app.enterprise.internal;

    access_log /var/log/nginx/app_access.log;
    error_log /var/log/nginx/app_error.log;

    location / {
        proxy_pass http://enterprise_backend;
        proxy_http_version 1.1;
        
        # Meneruskan header penting ke 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 khusus untuk Health Check internal
    location /nginx-health {
        access_log off;
        return 200 "healthy\n";
        add_type text/plain;
    }
}

Uji sintaks Nginx dan mulai ulang layanan:

sudo nginx -t
sudo systemctl restart nginx

Langkah 3: Membuat Script Deteksi Kesehatan Nginx

Keepalived harus memantau apakah Nginx berjalan dengan baik. Jika Nginx mati, Keepalived harus menurunkan prioritasnya agar VIP berpindah ke node cadangan. Buat script penelusuran di /etc/keepalived/check_nginx.sh pada kedua node:

#!/bin/bash
# Script pengecekan status Nginx untuk Keepalived

if ! pgrep -x "nginx" > /dev/null; then
    # Nginx mati, coba nyalakan ulang sekali
    systemctl restart nginx
    sleep 2
    if ! pgrep -x "nginx" > /dev/null; then
        # Jika tetap gagal, keluar dengan status error agar keepalived menurunkan prioritas
        exit 1
    fi
fi
exit 0

Berikan izin eksekusi pada script tersebut:

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

Langkah 4: Konfigurasi Keepalived pada Node Master (lb-01)

Buat file konfigurasi /etc/keepalived/keepalived.conf pada node lb-01:

global_defs {
    router_id lb-01
    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_01 {
    state MASTER
    interface eth0                  # Sesuaikan dengan nama interface jaringan Anda
    virtual_router_id 51
    priority 101                    # Prioritas lebih tinggi untuk Master
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecureSecretKey123
    }

    virtual_ipaddress {
        192.168.1.100/24            # Alamat Virtual IP (VIP)
    }

    track_script {
        check_nginx
    }
}

Langkah 5: Konfigurasi Keepalived pada Node Backup (lb-02)

Buat file konfigurasi /etc/keepalived/keepalived.conf pada node lb-02:

global_defs {
    router_id lb-02
    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_01 {
    state BACKUP
    interface eth0                  # Sesuaikan dengan nama interface jaringan Anda
    virtual_router_id 51
    priority 100                    # Prioritas lebih rendah untuk Backup
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecureSecretKey123
    }

    virtual_ipaddress {
        192.168.1.100/24            # Alamat Virtual IP (VIP)
    }

    track_script {
        check_nginx
    }
}

Nyalakan dan aktifkan layanan Keepalived pada kedua node:

sudo systemctl restart keepalived

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam konfigurasi Keepalived dan Nginx di atas:

• virtual_router_id 51: ID unik yang harus sama persis antara node Master dan Backup di dalam satu segmen jaringan yang sama. Jika Anda memiliki kluster lain di jaringan yang sama, pastikan ID ini berbeda (VRID collision prevention).
• priority 101 vs priority 100: Menentukan siapa yang berhak menjadi Master. Node dengan nilai prioritas tertinggi akan memegang kendali VIP saat pertama kali aktif. Master memiliki prioritas 101, sedangkan Backup memiliki 100.
• track_script check_nginx: Bagian ini menghubungkan status kesehatan aplikasi web server (Nginx) dengan VRRP. Jika Nginx mati dan gagal dipulihkan oleh script, nilai bobot (weight 2) akan dikurangi dari prioritas node tersebut, memaksa Keepalived melepaskan VIP ke node cadangan.
• proxy_set_header Connection "": Dalam blok Nginx upstream, baris ini sangat penting untuk menonaktifkan header Connection: close bawaan HTTP/1.0, memungkinkan pemeliharaan HTTP Keep-Alive connection pooling ke server backend, yang secara drastis menurunkan latensi CPU dan memori.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!IMPORTANT] Pada lingkungan produksi berkapasitas tinggi, pastikan kernel Linux Anda telah disetel (sysnet tuning) untuk menangani ribuan koneksi konkuren (C10k problem) tanpa mengalami kehabisan port ephemeril atau file descriptor.

Tambahkan konfigurasi berikut ke /etc/sysctl.conf pada kedua node Load Balancer:

# Meningkatkan batas maksimal file descriptor
fs.file-max = 2097152

# Mengizinkan reuse socket TCP yang berada dalam status TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

# Memperluas rentang port lokal untuk koneksi keluar
net.ipv4.ip_local_port_range = 1024 65535

# Meningkatkan ukuran antrean backlog SYN untuk mencegah SYN flood / lonjakan trafik
net.ipv4.tcp_max_syn_backlog = 65536
net.core.somaxconn = 65536

Terapkan perubahan sysctl dengan perintah:

sudo sysctl -p

8. Common Pitfalls, Anti-Patterns & Solusi

1. Split-Brain Syndrome:
   • Penyebab: Terjadi ketika jaringan antara Master dan Backup terputus, namun keduanya masih merasa aktif dan sama-sama mengklaim Virtual IP.
   • Solusi: Selalu gunakan konfigurasi authentication VRRP yang kuat dan pertimbangkan implementasi STONITH (Shoot The Other Node In The Head) atau pemantauan kesehatan eksternal melalui heartbeat pihak ketiga jika menggunakan infrastruktur bare-metal kompleks.
2. Firewall Memblokir Paket Multicast VRRP:
   • Penyebab: UFW atau iptables aktif secara default dan memblokir protokol IP nomor 112 (VRRP) serta paket multicast 224.0.0.18.
   • Solusi: Izinkan lalu lintas VRRP pada firewall:

     sudo ufw allow proto vrrp
     sudo ufw allow from 192.168.1.0/24 to 224.0.0.18
     

3. Kesalahan Konfigurasi non_shared atau nopreempt:
   • Secara default, Keepalived menggunakan mode preempt, di mana node dengan prioritas lebih tinggi akan merebut kembali VIP begitu ia pulih. Ini bisa memicu flapping (bolak-balik peralihan IP yang mengganggu koneksi aktif) jika koneksi sering naik-turun. Gunakan parameter nopreempt pada node Backup jika Anda ingin mencegah pengambilalihan otomatis yang terlalu agresif.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster High Availability dan Load Balancer Nginx, kita dapat menggunakan perangkat benchmark modern seperti wrk atau k6.

Contoh pengujian beban tinggi menggunakan wrk dengan 12 thread dan 400 koneksi konkuren selama 30 detik ke Virtual IP:

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

Metrik Pemantauan Kritis yang Harus Diamati:

• CPU Utilization: Pastikan penggunaan CPU pada node Load Balancer tidak melebihi 70% pada jam sibuk.
• Active Connections: Pantau melalui stub_status module di Nginx untuk melayani metrik koneksi aktif dan handshake requests/sec.
• Failover Transition Time: Ukur waktu yang dibutuhkan VIP untuk berpindah menggunakan perintah ping 192.168.1.100 saat kabel jaringan node Master dicabut secara fisik.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan arsitektur ini ke lingkungan Production, pastikan Anda telah melewati daftar pemeriksaan berikut:

• Kedua node Load Balancer memiliki sinkronisasi waktu NTP yang akurat.
• Skrip check_nginx.sh telah diuji secara manual dengan mematikan Nginx secara paksa (systemctl stop nginx) untuk memastikan VIP berpindah secara instan.
• Aturan Firewall (UFW/iptables) sudah mengizinkan paket VRRP dan lalu lintas HTTP/HTTPS.
• Monitoring eksternal (seperti Prometheus, Grafana, atau Datadog) dikonfigurasi untuk memantau status ketersediaan Virtual IP dan penggunaan sumber daya Nginx.
• Backup konfigurasi Keepalived dan Nginx telah disimpan di repositori Git privat yang aman.

Dengan menerapkan arsitektur High Availability berbasis Nginx dan Keepalived, Anda telah berhasil membangun fondasi infrastruktur web yang tangguh, tahan terhadap kegagalan perangkat keras, dan siap melayani jutaan permintaan dengan ketersediaan penuh tanpa titik tunggal kegagalan.