L
High Availability & Scaling • Literally Web ID

Arsitektur High Availability & Load Balancing Menggunakan Nginx dan Keepalived

⏱️ 22 menit baca • 📅 12 Oct 2026 • 👁️ 1 views
Arsitektur High Availability & Load Balancing Menggunakan Nginx dan Keepalived

Arsitektur High Availability & Load Balancing Menggunakan Nginx dan Keepalived

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ketersediaan tinggi (High Availability / HA) bukan lagi sebuah kemewahan, melainkan fondasi mutlak yang menentukan kredibilitas bisnis digital. Kegagalan infrastruktur selama beberapa menit saja dapat mengakibatkan kerugian finansial yang masif, hilangnya kepercayaan pengguna, serta degradasi posisi SEO situs web. Tantangan terbesar dalam mengelola sistem skala besar adalah Single Point of Failure (SPOF). Ketika sebuah server web tunggal dibebani lonjakan traffic secara masif, atau mengalami kegagalan perangkat keras (hardware failure), seluruh layanan akan lumpuh total tanpa adanya mekanisme mitigasi otomatis.

Sebelum penerapan arsitektur HA berbasis Nginx dan Keepalived, banyak organisasi mengandalkan satu server monolitik yang menjalankan Nginx, PHP-FPM, dan database secara bersamaan. Pendekatan ini rentan terhadap kehabisan sumber daya (resource exhaustion), di mana lonjakan koneksi HTTP secara bersamaan akan melumpuhkan prosesor dan memori, membuat sistem tidak dapat diakses bahkan untuk health check dasar. Selain itu, manajemen traffic dilakukan secara manual melalui DNS, yang mana propagasi perubahan DNS memerlukan waktu (TTL propagation delay) hingga berjam-jam, menjadikan skenario failover manual sangat lambat dan tidak efisien.

Setelah menerapkan arsitektur High Availability dengan Load Balancing Nginx di depan dan Virtual IP (VIP) yang dikelola oleh Keepalived, infrastruktur bertransformasi menjadi sistem terdistribusi yang tangguh. Traffic didistribusikan secara merata ke beberapa node backend menggunakan algoritma pintar (Least Connections), sementara Keepalived memantau kesehatan node secara real-time menggunakan protokol VRRP (Virtual Router Redundancy Protocol). Jika node Master mengalami kegagalan, Virtual IP secara otomatis berpindah ke node Backup dalam hitungan detik tanpa intervensi manual, memastikan waktu henti nol (zero downtime) bagi pengguna akhir.

2. Konsep Inti & Deep Dive Arsitektur

Untuk memahami cara kerja kluster HA ini secara mendalam, kita harus membedah dua komponen utamanya: Nginx sebagai Layer 7 Reverse Proxy & Load Balancer dan Keepalived sebagai daemon pengelola VRRP (Virtual Router Redundancy Protocol di Layer 3).

Alur Kerja (Workflow) Sistem

  1. Klien mengirimkan permintaan HTTP/HTTPS ke Virtual IP (VIP) publik atau internal yang dibagikan oleh kluster Load Balancer.
  2. Keepalived yang berjalan pada node Master mengikat (bind) VIP tersebut ke antarmuka jaringan fisik.
  3. Nginx pada node Master menerima koneksi masuk, melakukan terminasi SSL/TLS jika diperlukan, dan meneruskan permintaan (proxy pass) ke kumpulan server backend (Node Web 1, Web 2, dst.) berdasarkan algoritma Least Connections.
  4. Daemon vrrp di Keepalived secara berkala mengirimkan paket heartbeat multicast ke node Backup.
  5. Jika node Master mati atau skrip health check gagal (misalnya proses Nginx berhenti), node Backup berhenti menerima heartbeat, mengambil alih VIP, dan langsung melayani traffic masuk secara transparan.
+-------------------------------------------------------------------------+
|                           KLIEN / PENGGUNA                              |
+-------------------------------------------------------------------------+
                                     |
                                     v
                       +---------------------------+
                       |    Virtual IP (VIP)       | 
                       |      192.168.1.100        |
                       +---------------------------+
                                     |
                  +------------------+------------------+
                  | (VRRP Heartbeat)                    |
                  v                                     v
        +-------------------+                 +-------------------+
        |  Load Balancer A  | <-------------> |  Load Balancer B  |
        |   (Active/Master) |                 |   (Passive/Backup)|
        |   Nginx + Keepalived|               |   Nginx + Keepalived|
        +-------------------+                 +-------------------+
                  |                                     |
                  +------------------+------------------+
                                     |
        +----------------------------+----------------------------+
        |                            |                            |
        v                            v                            v
+---------------+            +---------------+            +---------------+
| Backend Web 1 |            | Backend Web 2 |            | Backend Web 3 |
|  PHP-FPM/Go   |            |  PHP-FPM/Go   |            |  PHP-FPM/Go   |
+---------------+            +---------------+            +---------------+
        |                            |                            |
        +----------------------------+----------------------------+
                                     |
                                     v
                        +-------------------------+
                        |  Database Cluster (SQL) |
                        +-------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun sistem Load Balancing dan Failover, terdapat beberapa pendekatan arsitektural yang umum digunakan di industri. Tabel berikut membandingkan pendekatan Nginx + Keepalived dengan solusi alternatif.

Parameter Komparasi Nginx + Keepalived (Software-Defined) Hardware Load Balancer (F5, Citrix NetScaler) DNS Round-Robin + Health Check Eksternal HAProxy + Keepalived
Biaya Lisensi Gratis (Open Source) Sangat Mahal (Enterprise Hardware/Software) Gratis Gratis (Open Source)
Fleksibilitas & Kustomisasi Sangat Tinggi (Lua script, konfigurasi modular) Terbatas pada fitur vendor Sangat Terbatas Tinggi (Fokus pada L4/L7 routing murni)
Kompleksitas Setup Sedang (Membutuhkan pemahaman Linux networking) Rendah (Wizard berbasis GUI) Rendah Sedang
Konsumsi Sumber Daya Efisien (Rendah RAM & CPU) Didedikasikan pada perangkat keras khusus Tergantung DNS Provider Sangat Efisien (Lebih cepat untuk L4 murni)
Kecepatan Failover Cepat (1 - 3 detik via VRRP) Sangat Cepat (< 1 detik) Lambat (Tergantung TTL DNS, bisa jam/menit) Cepat (1 - 3 detik via VRRP)

[!TIP] Gunakan Nginx + Keepalived jika Anda membutuhkan fleksibilitas penuh dalam memproses Layer 7 traffic (seperti URL rewriting, header manipulation, rate limiting, dan microcaching) dengan anggaran infrastruktur yang efisien.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi teknis, pastikan environment Anda memenuhi spesifikasi minimum berikut agar eksekusi berjalan mulus tanpa kendala kompatibilitas:

  • OS: Ubuntu Server 22.04 LTS / Debian 12 (Minimum 2 Node untuk Load Balancer dan 2 Node untuk Backend Web).
  • Hak Akses: Akses root atau pengguna dengan hak istimewa sudo.
  • Konektivitas Jaringan:
    • IP Publik / Lokal yang statis untuk setiap node.
    • Satu blok IP untuk Virtual IP (VIP) yang berada dalam subnet yang sama dengan antarmuka jaringan fisik load balancer.
  • Firewall: Membuka port HTTP (80), HTTPS (443), dan mengizinkan protokol VRRP (IP Protocol 112) serta port multicast jika diperlukan oleh Keepalived.

Verifikasi antarmuka jaringan pada Node Load Balancer:

ip a

Catat nama antarmuka jaringan utama Anda (misalnya eth0 atau ens18) karena akan digunakan dalam file konfigurasi Keepalived.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Nginx dan Keepalived pada Kedua Node Load Balancer

Jalankan perintah berikut pada Load Balancer 1 (LB01 - Master) dan Load Balancer 2 (LB02 - Backup):

sudo apt update && sudo apt upgrade -y
sudo apt install nginx keepalived -y

Langkah 2: Konfigurasi Nginx Reverse Proxy dengan Least Connections

Buat file konfigurasi virtual host baru di /etc/nginx/conf.d/load-balancer.conf pada kedua node LB:

upstream backend_cluster {
    # Menggunakan algoritma Least Connections untuk distribusi beban optimal
    least_conn;
    
    # Daftar server backend
    server 192.168.1.11:80 max_fails=3 fail_timeout=10s;
    server 192.168.1.12:80 max_fails=3 fail_timeout=10s;
    
    # Keepalive connections ke backend untuk efisiensi memori dan CPU
    keepalive 32;
}

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

    access_log /var/log/nginx/lb_access.log;
    error_log /var/log/nginx/lb_error.log;

    location / {
        proxy_pass http://backend_cluster;
        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;

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

    # Halaman status kesehatan internal Nginx untuk monitoring
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        allow 192.168.1.0/24;
        deny all;
    }
}

Uji sintaks konfigurasi Nginx:

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

Langkah 3: Membuat Skrip Health Check Nginx untuk Keepalived

Buat file skrip /etc/keepalived/check_nginx.sh pada kedua node LB untuk memantau apakah proses Nginx berjalan dengan baik:

#!/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

Langkah 4: Konfigurasi Keepalived pada Node Master (LB01)

Edit file konfigurasi Keepalived di /etc/keepalived/keepalived.conf pada node LB01:

global_defs {
    router_id LBRUTER_01
    enable_script_security
    script_user root
}

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

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

Langkah 5: Konfigurasi Keepalived pada Node Backup (LB02)

Edit file konfigurasi Keepalived di /etc/keepalived/keepalived.conf pada node LB02:

global_defs {
    router_id LBRUTER_02
    enable_script_security
    script_user root
}

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

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecureSecretKey123
    }
    
    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

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dalam konfigurasi yang baru saja dibuat:

  • least_conn; (Nginx Upstream): Alih-alih menggunakan Round-Robin standar, algoritma ini mendistribusikan permintaan baru ke server backend yang saat ini memegang jumlah koneksi aktif paling sedikit. Sangat ideal jika aplikasi backend Anda memproses waktu eksekusi request yang bervariasi (misalnya kueri database berat atau pemrosesan file).
  • keepalive 32; (Nginx Upstream): Menyimpan koneksi idle ke server backend di dalam pool memori. Ini menghindari overhead TCP three-way handshake yang berulang-ulang untuk setiap request baru, meningkatkan throughput secara drastis.
  • priority 101 (Master) vs priority 100 (Backup): Menentukan bobot prioritas VRRP. Node dengan prioritas lebih tinggi akan memenangkan pemilihan (election) dan bertindak sebagai Master yang memegang VIP.
  • vrrp_script check_nginx: Mekanisme keamanan berbasis skrip. Keepalived mengecek status Nginx setiap 2 detik (interval 2). Jika Nginx mati, bobot prioritas node Master akan dikurangi (weight 2), membuatnya lebih rendah dari node Backup, sehingga VIP secara otomatis melakukan failover ke node Backup.

[!WARNING] Pastikan virtual_router_id bernilai sama pada node Master dan Backup dalam satu kluster, namun harus unik jika Anda menjalankan beberapa kluster VRRP dalam jaringan lokal yang sama untuk mencegah konflik paket multicast.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam lingkungan produksi skala besar (misalnya e-commerce saat flash sale), beban HTTP dapat mencapai puluhan ribu requests per second (RPS). Konfigurasi Nginx di atas perlu disesuaikan dengan parameter sistem operasi Linux (kernel tuning) agar mampu menangani lonjakan koneksi (C10K problem).

Tambahkan konfigurasi berikut ke dalam bagian utama file /etc/nginx/nginx.conf:

user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 10240;
    use epoll;
    multi_accept on;
}

http {
    keepalive_timeout 65;
    keepalive_requests 100;
    client_max_body_size 50M;
    
    # Mengaktifkan buffer untuk mencegah slow clients memakan resource backend
    proxy_buffering on;
    proxy_buffer_size 4k;
    proxy_buffers 8 16k;
    
    # Mengoptimalkan pengiriman data jaringan
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

Terapkan penyesuaian pada batas file descriptor sistem operasi melalui /etc/security/limits.conf:

www-data soft nofile 65535
www-data hard nofile 65535

8. Common Pitfalls, Anti-Patterns & Solusi

  1. Split-Brain Syndrome:

    • Masalah: Kedua node load balancer sama-sama mengaku sebagai Master karena masalah jaringan (misalnya packet drop pada multicast VRRP).
    • Solusi: Pastikan aturan firewall mengizinkan protokol VRRP (IP 112) dan alamat multicast 224.0.0.18. Gunakan unicast peering pada konfigurasi Keepalived jika jaringan Anda tidak mendukung multicast.
  2. IP Forwarding yang Dinonaktifkan:

    • Masalah: Node Master memegang VIP tetapi gagal meneruskan paket ke backend.
    • Solusi: Aktifkan IP forwarding pada kernel Linux dengan menambahkan baris net.ipv4.ip_forward = 1 ke dalam file /etc/sysctl.conf, lalu jalankan sysctl -p.
  3. Sticky Sessions yang Diabaikan:

    • Masalah: Aplikasi backend berbasis PHP/Node menyimpan sesi lokal di memori server, menyebabkan pengguna kehilangan sesi saat load balancer mengalihkan request ke server backend lain.
    • Solusi: Gunakan penyimpanan sesi terpusat seperti Redis atau Memcached, atau aktifkan ip_hash / sticky cookie pada modul upstream Nginx.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster HA yang telah dibangun, Anda dapat menggunakan alat pengujian beban (load testing) seperti wrk atau k6 dari mesin klien terpisah.

Contoh perintah pengujian menggunakan wrk dengan 100 koneksi bersamaan selama 30 detik:

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

Interpretasi Metrik:

  • Requests/sec (RPS): Menunjukkan kapasitas throughput Nginx dalam melayani permintaan HTTP.
  • Latency Distribution: Memastikan percentile ke-99 (p99) berada di bawah ambang batas yang dapat diterima (misalnya < 50ms).
  • Uji Failover: Saat pengujian wrk berjalan, matikan layanan Nginx atau reboot node Master (sudo systemctl stop keepalived), lalu amati apakah ada dropped connection pada terminal pengujian. Dengan setup Keepalived yang optimal, gangguan seharusnya hanya berlangsung kurang dari 2 detik.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis arsitektur ini ke lingkungan produksi yang sebenarnya, pastikan Anda telah melewati daftar pemeriksaan berikut:

  • Konfigurasi SSL/TLS yang kuat terpasang pada blok server Nginx (menggunakan sertifikat dari Let's Encrypt atau CA tepercaya).
  • Aturan firewall (UFW / iptables) dikonfigurasi dengan ketat (hanya membuka port 80, 443, dan port internal jaringan).
  • Skrip check_nginx.sh telah diuji secara manual dengan mematikan Nginx untuk memastikan Keepalived merespons perpindahan VIP dengan benar.
  • Sistem monitoring (seperti Prometheus + Grafana atau Zabbix) dikonfigurasi untuk memantau penggunaan CPU, memori, status VIP, dan metrik Nginx stub_status.
  • Manajemen log dan rotasi log (logrotate) diatur untuk mencegah disk penuh akibat access log yang masif.

Dengan menerapkan arsitektur High Availability menggunakan Nginx dan Keepalived ini, Anda telah membangun fondasi infrastruktur web yang tidak hanya cepat dan efisien dalam mendistribusikan beban, tetapi juga memiliki ketahanan tinggi terhadap kegagalan perangkat keras maupun perangkat lunak secara otomatis.

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