Membangun Cluster Redis High Availability dengan Redis Sentinel

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, caching layer memegang peranan krusial untuk menjaga latensi tetap rendah (sub-millisecond) dan melindungi relational database (seperti MySQL atau PostgreSQL) dari lonjakan traffic (thundering herd problem). Redis telah menjadi standar industri sebagai in-memory data store untuk cache, session store, real-time messaging, dan rate-limiting. Namun, menjalankan Redis dalam konfigurasi standalone (tunggal) di lingkungan produksi berisiko tinggi. Kegagalan node tunggal akibat masalah hardware, kernel panic, kehabisan memori (OOM Killer), atau kegagalan jaringan akan berakibat fatal: seluruh cache layer runtuh, traffic langsung menghantam database utama, menyebabkan database locks, exhaustion connection pool, dan berujung pada downtime total aplikasi.

Bottleneck Performa & Masalah Keamanan Umum

1. Single Point of Failure (SPOF): Ketergantungan pada satu instance Redis membuat aplikasi rentan. Ketika Redis mati, aplikasi backend (Node.js, PHP, Go) akan gagal melakukan koneksi, memicu pengecualian (exceptions) yang tidak tertangani.
2. Ketiadaan Otomasi Failover: Secara manual mempromosikan replika menjadi master membutuhkan intervensi manusia, yang memakan waktu (MTTR - Mean Time to Recovery) hingga puluhan menit.
3. Masalah Konfigurasi Jaringan & Timeout: Konfigurasi timeout dan tcp-keepalive yang tidak optimal sering menyebabkan koneksi menggantung (hanging) saat terjadi gangguan jaringan mikro.
4. Isu Keamanan Otentikasi: Sering kali Redis dijalankan tanpa parameter requirepass dan rename-command untuk melindungi perintah berbahaya seperti FLUSHALL atau CONFIG dari akses eksternal yang tidak sah.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Untuk memahami cara kerja Redis High Availability, kita harus membedah dua komponen utama: Redis Master-Replica Replication dan Redis Sentinel.

Alur Kerja Replikasi Master-Replica

Redis menggunakan replikasi asinkron (secara default) atau semi-sinkron. Ketika node replika terhubung ke master, replika mengirimkan perintah PSYNC. Master kemudian melakukan bgsave (background saving) untuk menghasilkan snapshot RDB, mengirimkannya ke replika, lalu meneruskan replication buffer dari perintah tulis (write commands) yang masuk selama proses snapshot berlangsung.

+-------------------+              +--------------------+
|    Redis Master   | ------------ |   Redis Replica 1  |
|  (Read & Write)   |              |    (Read-Only)     |
+-------------------+              +--------------------+
          |
          +------------------------+
                                   |
                                   v
                            +--------------------+
                            |   Redis Replica 2  |
                            |    (Read-Only)     |
                            +--------------------+

Peran dan Mekanisme Redis Sentinel

Redis Sentinel adalah sistem terdistribusi yang memantau, memberitahu, dan melakukan failover otomatis pada instance Redis. Sentinel bekerja secara independen dalam kuorum.

1. Monitoring: Sentinel secara berkala mengirimkan perintah PING ke master, replika, dan sesama Sentinel.
2. Notification: Sentinel dapat memberi tahu sistem lain (melalui API pub/sub atau skrip eksternal) jika ada instance Redis yang mengalami kegagalan.
3. Automatic Failover: Jika sebuah master tidak merespons dalam waktu tertentu (down-after-milliseconds), Sentinel akan memulai proses pemilihan master baru (Leader Election) melalui mekanisme kuorum.
4. Configuration Provider: Klien aplikasi tidak langsung terhubung ke IP master secara statis, melainkan bertanya kepada Sentinel tentang siapa master saat ini (get-master-addr-by-name).

+-------------------------------------------------------------+
|                        Redis Sentinel                       |
|  +----------------+  +----------------+  +----------------+ |
|  |   Sentinel 1   |  |   Sentinel 2   |  |   Sentinel 3   | |
|  +----------------+  +----------------+  +----------------+ |
+-------------------------------------------------------------+
         |                     |                     |
         +---------------------+---------------------+
                               |
                               v
+-------------------+                         +--------------------+
|    Redis Master   | <=====================> |   Redis Replica    |
|     (Port 6379)   |   Replikasi Data        |     (Port 6379)    |
+-------------------+                         +--------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih arsitektur caching yang tepat memerlukan analisis trade-off yang cermat antara kompleksitas operasional, konsistensi data, dan biaya infrastruktur.

[!TIP] Gunakan Redis Sentinel jika kebutuhan memori Anda masih muat dalam satu node fisik (RAM < 64GB) namun Anda membutuhkan jaminan High Availability. Gunakan Redis Cluster hanya jika ukuran data melebihi kapasitas RAM satu mesin dan memerlukan sharding data secara horizontal.

4. Prasyarat Sistem & Persiapan Lingkungan

Untuk implementasi produksi yang andal, kita memerlukan minimal 3 Virtual Machine (VM) atau server terpisah untuk memastikan kuorum Sentinel tidak mengalami split-brain akibat kegagalan jaringan satu sisi.

Spesifikasi Minimum Environment

• OS: Ubuntu Server 22.04 LTS / Debian 12 / AlmaLinux 9
• Node 1 (Redis Master + Sentinel): IP 192.168.1.10
• Node 2 (Redis Replica + Sentinel): IP 192.168.1.11
• Node 3 (Redis Replica + Sentinel): IP 192.168.1.12
• Koneksi Jaringan: Internal network berkecepatan tinggi (Gigabit LAN)

Persiapan Kernel & Sistem Operasi (Diterapkan di Semua Node)

Jalankan perintah berikut untuk mengoptimalkan kernel Linux untuk Redis:

# Menonaktifkan Overcommit Memori Linux
sudo sysctl -w vm.overcommit_memory=1
echo "vm.overcommit_memory = 1" | sudo tee -a /etc/sysctl.conf

# Menonaktifkan Transparent Huge Pages (THP) untuk menghindari latensi tinggi
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' | sudo tee -a /etc/rc.local

# Mengatur ukuran backlog TCP
sudo sysctl -w net.core.somaxconn=1024
echo "net.core.somaxconn = 1024" | sudo tee -a /etc/sysctl.conf

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Redis Server

Install Redis di semua node (10, 11, 12):

sudo apt update
sudo apt install redis-server -y

Langkah 2: Konfigurasi Redis Master (Node 1 - 192.168.1.10)

Edit file /etc/redis/redis.conf. Pastikan parameter berikut disesuaikan:

# /etc/redis/redis.conf (Master Node)
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize no
supervised systemd
pidfile /var/run/redis/redis-server.pid
loglevel notice
logfile /var/log/redis/redis-server.log
databases 16
always-show-logo yes

# Persistence
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /var/lib/redis

# Keamanan
requirepass "StrongMasterPassword123!"
masterauth "StrongMasterPassword123!"

# Limit Memori
maxmemory 2gb
maxmemory-policy allkeys-lru

Langkah 3: Konfigurasi Redis Replica (Node 2 & 3)

Edit file /etc/redis/redis.conf pada Node 2 (192.168.1.11) dan Node 3 (192.168.1.12):

# /etc/redis/redis.conf (Replica Node)
bind 0.0.0.0
port 6379
daemonize no
supervised systemd
pidfile /var/run/redis/redis-server.pid

requirepass "StrongMasterPassword123!"
masterauth "StrongMasterPassword123!"

# Menunjuk ke Master
replicaof 192.168.1.10 6379
replica-read-only yes

maxmemory 2gb
maxmemory-policy allkeys-lru

Restart layanan Redis di semua node:

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

Langkah 4: Konfigurasi Redis Sentinel (Di Ketiga Node)

Edit file /etc/redis/sentinel.conf di semua node. Hapus isi file dan masukkan konfigurasi berikut:

# /etc/redis/sentinel.conf
port 26379
daemonize noupidfile /var/run/redis/redis-sentinel.pid
logfile /var/log/redis/sentinel.log
dir /var/lib/redis

# Memantau master dengan kuorum 2 (dari 3 sentinel)
sentinel monitor mymaster 192.168.1.10 6379 2

# Waktu tunggu sebelum master dianggap down (dalam milidetik)
sentinel down-after-milliseconds mymaster 5000

# Password untuk otentikasi master
sentinel auth-pass mymaster StrongMasterPassword123!

# Batas waktu failover sebelum dibatalkan
sentinel failover-timeout mymaster 60000

# Jumlah replika yang dapat melakukan re-config secara bersamaan
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

Mari kita bedah parameter penting dalam konfigurasi Sentinel dan Redis:

• sentinel monitor mymaster 192.168.1.10 6379 2:

  • mymaster: Nama logical dari cluster Redis yang dipantau.
  • 192.168.1.10 6379: IP dan port master awal.
  • 2: Quorum. Menentukan berapa banyak Sentinel yang harus setuju bahwa master sedang down sebelum proses failover benar-benar dieksekusi. Karena total ada 3 Sentinel, kuorum 2 mencegah split-brain jika terjadi partisi jaringan.

• sentinel down-after-milliseconds mymaster 5000:

  • Menetapkan batas waktu 5 detik. Jika sebuah Sentinel gagal menerima balasan PONG dari master selama waktu ini, maka Sentinel tersebut menandai master sebagai s_down (Subjectively Down).

• replica-read-only yes:

  • Memastikan node replika menolak semua perintah tulis dari klien, menjaga integritas replikasi agar data tidak bercabang.

• maxmemory-policy allkeys-lru:

  • Algoritma Least Recently Used (LRU). Ketika memori mencapai batas maxmemory (2GB), Redis secara otomatis menghapus kunci yang paling sedikit digunakan untuk menghemat ruang.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Skenario: Kegagalan Node Master secara Mendadak

1. T+00.00: Node 1 (Master) mengalami kegagalan daya total (hard crash).
2. T+05.00: Sentinel 2 dan Sentinel 3 mendeteksi bahwa Node 1 tidak merespons (down-after-milliseconds). Keduanya mengubah status master menjadi s_down.
3. T+05.02: Sentinel 2 dan Sentinel 3 mencapai konsensus dan mengubah status master menjadi o_down (Objectively Down).
4. T+05.03: Salah satu Sentinel terpilih sebagai leader untuk melakukan failover.
5. T+05.05: Node 2 (192.168.1.11) dipromosikan menjadi Master baru melalui perintah SLAVEOF NO ONE.
6. T+05.10: Sentinel memperbarui konfigurasi internal dan memberi tahu aplikasi klien melalui Pub/Sub bahwa master telah berpindah ke 192.168.1.11.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Menggunakan Jumlah Sentinel Genap (Misal: 2 atau 4):

   • Anti-Pattern: Menggunakan 2 Sentinel. Jika terjadi partisi jaringan 1-1, kuorum 2 tidak akan pernah tercapai karena dibutuhkan mayoritas (misal: 2 dari 2, atau 2 dari 3).
   • Solusi: Selalu gunakan jumlah Sentinel ganjil (minimal 3 atau 5) yang disebar di availability zone atau server terpisah.

2. Aplikasi Menggunakan Koneksi Hardcoded IP Master:

   • Anti-Pattern: Aplikasi Node.js/PHP langsung melakukan koneksi ke 192.168.1.10:6379. Ketika failover terjadi, aplikasi akan mengalami error koneksi secara permanen.
   • Solusi: Gunakan driver/client Redis yang mendukung Sentinel (Redis Sentinel-aware client).

3. Lupa Mengatur maxmemory dan Kebijakan Eviksi:

   • Anti-Pattern: Redis berjalan tanpa batasan memori hingga RAM fisik habis, memicu Linux OOM Killer mematikan proses Redis.
   • Solusi: Selalu set parameter maxmemory dan maxmemory-policy secara bijak.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa dapat dilakukan menggunakan redis-benchmark untuk mengukur Throughput (QPS - Queries Per Second) dan Latensi.

# Melakukan benchmark dengan 50 koneksi simultan dan total 100.000 request
redis-benchmark -h 192.168.1.10 -p 6379 -a 'StrongMasterPassword123!' -c 50 -n 100000 -t set,get -q

Interpretasi Hasil & Tuning Lanjutan

• Jika latensi rata-rata di atas 2ms, periksa konfigurasi jaringan atau pastikan Transparent Huge Pages (THP) benar-benar dinonaktifkan.
• Gunakan perintah INFO stats dan INFO memory secara berkala untuk memantau rasio hit/miss cache (keyspace_hits vs keyspace_misses).

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan cluster Redis High Availability ke lingkungan produksi live, pastikan checklist berikut terpenuhi:

• Jumlah node Redis Master-Replica minimal 2 (1 Master, 1+ Replika).
• Jumlah node Redis Sentinel minimal 3 dan diletakkan di instance terpisah.
• Konfigurasi requirepass dan masterauth aktif dengan password yang kuat.
• Parameter kernel Linux (vm.overcommit_memory=1 & THP dinonaktifkan) sudah diterapkan.
• Aplikasi backend menggunakan driver yang mendukung Sentinel.
• Monitoring eksternal (Prometheus + Grafana dengan Redis Exporter) telah dikonfigurasi untuk memantau status replikasi.

Dengan menerapkan arsitektur Redis Master-Replica yang dikawal oleh Redis Sentinel, Anda telah berhasil mengeliminasi Single Point of Failure pada caching layer, menjamin ketersediaan sistem hingga 99.99%, dan melindungi database relasional utama dari lonjakan beban yang merusak.