Membangun High Availability Cluster dengan Go, Nginx, dan Redis Sentinel

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem modern, ketersediaan tinggi (High Availability atau HA) bukan lagi sebuah kemewahan, melainkan kebutuhan fundamental untuk menjaga kelangsungan bisnis digital. Bayangkan sebuah sistem e-commerce berskala enterprise yang mengalami downtime hanya selama lima menit akibat kegagalan basis data tunggal (Single Point of Failure / SPOF); dampaknya bisa berupa kerugian finansial yang masif, penurunan kepercayaan pelanggan, hingga rusaknya reputasi merek yang telah dibangun bertahun-tahun. Pada ekosistem backend modern, layanan berbasis bahasa Go (Golang) sering dipilih karena performa konkurensinya yang luar biasa, konsumsi memori yang efisien, dan waktu kompilasi yang cepat. Namun, sehebat apapun performa Go dalam menangani ribuan permintaan per detik, performa tersebut akan runtuh seketika jika lapisan penyimpanan data dan pengelolaan status (state management) mengalami kegagalan.

Secara historis, banyak arsitek pemula membangun aplikasi web dengan satu instans basis data atau caching store seperti Redis yang berjalan pada satu mesin fisik atau virtual. Ketika beban kerja melonjak, atau terjadi kegagalan perangkat keras (hardware failure), aplikasi langsung tidak dapat diakses. Di sinilah pentingnya penerapan klaster yang tangguh.

Perbandingan antara kondisi Sebelum dan Sesudah penerapan High Availability Cluster berbasis Go, Nginx, dan Redis Sentinel dapat diilustrasikan secara radikal:

• Sebelum (SPOF Architecture):
  • Aplikasi Go terhubung langsung ke satu alamat IP server Redis.
  • Jika server Redis mati akibat kernel panic atau pemadaman listrik, seluruh aplikasi Go gagal melakukan autentikasi, manajemen sesi (session store), maupun caching query.
  • Tidak ada mekanisme auto-failover. Administrator harus melakukan intervensi manual untuk mempromosikan replika, yang memakan waktu (RTO - Recovery Time Objective) hingga puluhan menit.
• Sesudah (HA Distributed Cluster Architecture):
  • Aplikasi Go menggunakan pustaka klien Redis yang cerdas (cluster-aware/sentinel-aware), terhubung ke jaringan Redis Sentinel yang memantau kesehatan Master dan Replica.
  • Nginx bertindak sebagai Reverse Proxy dan Load Balancer di lapisan terdepan, mendistribusikan lalu lintas HTTP secara merata ke beberapa instans aplikasi Go di balik layar.
  • Jika server Redis Master gagal, Redis Sentinel secara otomatis mendeteksi kegagalan tersebut dalam hitungan detik, melakukan quorum voting, mempromosikan salah satu Replica menjadi Master baru, dan mengalihkan lalu lintas tulis tanpa intervensi manual.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur High Availability yang handal melibatkan koordinasi sinkronisasi yang presisi antara tiga komponen utama: Nginx sebagai pintu gerbang lalu lintas web, Go Backend sebagai mesin pemroses logika bisnis, dan Redis Sentinel sebagai pengawas serta pengelola otomatisasi klaster basis data in-memory.

Alur Kerja di Balik Layar (Under the Hood)

1. Ingress & Load Balancing (Nginx): Klien (browser, aplikasi mobile, atau API consumer) mengirimkan permintaan HTTP ke Nginx. Nginx menerima koneksi tersebut, mengakhiri SSL/TLS (SSL termination), dan meneruskannya menggunakan algoritma Least Connections atau Round Robin ke sekumpulan proses aplikasi Go yang berjalan pada port berbeda di lokal atau melalui jaringan internal.
2. Application Logic & Sentinel Discovery (Go): Aplikasi Go menerima permintaan HTTP. Saat aplikasi membutuhkan data dari Redis (misalnya untuk mengambil token sesi pengguna), aplikasi tidak langsung menebak alamat IP Redis Master. Sebaliknya, pustaka klien Go (go-redis) terlebih dahulu melakukan kueri ke proses Redis Sentinel (biasanya berjalan di port 26379 pada beberapa node terpisah) untuk menanyakan: “Siapa Redis Master yang aktif saat ini?”
3. Data Replication & Failover (Redis Sentinel):
   • Redis Master secara kontinu menulis data ke memori dan mereplikasikannya secara asinkron (atau semi-sinkron) ke satu atau lebih Redis Replica.
   • Sekelompok instans Redis Sentinel (minimal 3 node untuk menghindari split-brain syndrome) memantau Master setiap detik menggunakan detak jantung (heartbeat / perintah PING).
   • Jika Master gagal merespons selama durasi down-after-milliseconds, Sentinel menyatakan Master tersebut dalam status S_DOWN (Subjectively Down).
   • Sentinel kemudian berkoordinasi dengan Sentinel lain. Jika mayoritas Sentinel (mencapai nilai quorum) sepakat bahwa Master down, status berubah menjadi O_DOWN (Objectively Down).
   • Sentinel melakukan pemilihan pemimpin (leader election) menggunakan algoritma Raft-like untuk memilih Sentinel yang akan mengeksekusi failover.
   • Sentinel terpilih mempromosikan salah satu Replica menjadi Master baru, mengubah konfigurasi replika lainnya agar mengikuti Master baru tersebut, dan memperbarui informasi topologi yang akan diambil oleh klien Go.

+-------------------------------------------------------+
|                        CLIENTS                        |
+-------------------------------------------------------+
                            |
                            v (HTTP/HTTPS)
+-------------------------------------------------------+
|                     NGINX PROXY                       |
|         (Load Balancer & SSL Termination)             |
+-------------------------------------------------------+
           /                |                \
          v                 v                 v
+------------------+ +------------------+ +------------------+|
|  Go App Node 1   | |  Go App Node 2   | |  Go App Node 3   ||
+------------------+ +------------------+ +------------------+$
          |                 |                 |
          +--------+--------+--------+--------+
                   |                   |
                   v                   v
         +-------------------+ +-------------------+
         |  Redis Sentinel   | |  Redis Sentinel   | (Quorum Monitoring)
         +-------------------+ +-------------------+
                   |                   |
                   +---------+---------+
                             |
                             v
               +---------------------------+
               |    Redis Master (RW)      |
               +---------------------------+
                             | (Async Replication)
                             v
               +---------------------------+
               |    Redis Replica (RO)     |
               +---------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa kombinasi Nginx, Go, dan Redis Sentinel menjadi standar industri yang sangat tangguh, kita perlu membandingkannya dengan pendekatan arsitektur alternatif.

[!TIP] Gunakan arsitektur Redis Sentinel berbasis Bare-Metal atau Docker Compose di VPS jika Anda mengelola sistem skala menengah dengan tim kecil, karena memberikan kontrol penuh tanpa overhead operasional Kubernetes yang kompleks.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi teknis, pastikan environment Anda memenuhi spesifikasi minimum berikut agar klaster dapat berjalan secara optimal tanpa hambatan sumber daya.

Spesifikasi Minimum Hardware & Software

• Sistem Operasi: Ubuntu Server 22.04 LTS (atau Debian 12 / AlmaLinux 9) pada minimal 3 buah Virtual Private Server (VPS) / Node untuk memastikan kuorum Sentinel terpenuhi.
• Bahasa Pemrograman: Go versi 1.21 atau lebih baru terinstal di node aplikasi.
• Web Server: Nginx versi 1.18+.
• Cache/Datastore: Redis Server versi 7.0+.
• Jaringan: Pastikan port internal berikut terbuka antar node di dalam jaringan lokal (VPC / Private Network):
  • 80 / 443: HTTP/HTTPS (Nginx)
  • 6379: Redis Server (Master/Replica)
  • 26379: Redis Sentinel

Verifikasi Awal Sistem

Jalankan perintah berikut pada setiap node untuk memastikan batas sistem operasi (file descriptors dan virtual memory) mendukung konkurensi tinggi:

# Periksa batas maksimal open files
ulimit -n

# Pastikan overcommit memory diset ke 1 untuk performa Redis optimal
sysctl vm.overcommit_memory=1

Pertahankan pengaturan ini secara permanen dengan menambahkan baris berikut ke dalam /etc/sysctl.conf:

vm.overcommit_memory = 1

5. Panduan Implementasi Langkah demi Langkah

Bagian ini akan memandu Anda membangun seluruh sistem dari nol hingga siap produksi. Kita asumsikan tiga node dengan IP internal:

• 10.0.0.11: Node 1 (Redis Master + Sentinel + Go App)
• 10.0.0.12: Node 2 (Redis Replica 1 + Sentinel + Go App)
• 10.0.0.13: Node 3 (Redis Replica 2 + Sentinel + Go App + Nginx Load Balancer)

Langkah 1: Instalasi Redis dan Konfigurasi Master-Replica

Instal Redis pada semua node:

sudo apt update && sudo apt install -y redis-server

Konfigurasi Redis Master (10.0.0.11)

Edit file /etc/redis/redis.conf:

bind 0.0.0.0
protected-mode no
port 6379
daemonize yes
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 "StrongMasterPassword123!"
masterauth "StrongMasterPassword123!"

Konfigurasi Redis Replica (10.0.0.12 & 10.0.0.13)

Edit file /etc/redis/redis.conf pada node replika, tambahkan baris replikasi di bagian bawah:

bind 0.0.0.0
protected-mode no
port 6379
daemonize yes
requirepass "StrongMasterPassword123!"
masterauth "StrongMasterPassword123!"
replicaof 10.0.0.11 6379

Langkah 2: Konfigurasi Redis Sentinel di Semua Node

Buat file konfigurasi Sentinel di /etc/redis/sentinel.conf pada ketiga node (10.0.0.11, 10.0.0.12, 10.0.0.13):

port 26379
daemonize yes
pidfile /var/run/redis/redis-sentinel.pid
logfile /var/log/redis/sentinel.log
dir /tmp

# Memantau master dengan nama 'mymaster', quorum 2 (minimal 2 sentinel sepakat)
sentinel monitor mymaster 10.0.0.11 6379 2

# Waktu milidetik sebelum master dianggap down
sentinel down-after-milliseconds mymaster 5000

# Autentikasi sandi master
sentinel auth-pass mymaster StrongMasterPassword123!

# Batas waktu kegagalan failover
sentinel failover-timeout mymaster 10000

# Jumlah replika yang dapat merefresh data secara bersamaan saat failover
sentinel parallel-syncs mymaster 1

Restart layanan Redis dan Sentinel di semua node:

sudo systemctl restart redis-server
redis-sentinel /etc/redis/sentinel.conf

Langkah 3: Implementasi Backend Go dengan Redis Sentinel Client

Buat direktori proyek Go baru, inisialisasi modul, dan pasang pustaka klien Redis (go-redis):

mkdir go-redis-ha && cd go-redis-ha
go mod init github.com/enterprise/go-redis-ha
go get github.com/redis/go-redis/v9

Buat file main.go dengan kode produksi lengkap yang tahan banting terhadap failover:

package main

(
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"time"

	"github.com/redis/go-redis/v9"
)

var (
	rdb *redis.Client
	ctx = context.Background()
)

type Response struct {
	Status    string `json:"status"`
	Message   string `json:"message"`
	Timestamp int64  `json:"timestamp"`
	Node      string `json:"node"`
}

func initRedisSentinel() {
	// Inisialisasi failover client menggunakan Redis Sentinel
	rdb = redis.NewFailoverClient(&redis.FailoverOptions{
		MasterName:    "mymaster",
		SentinelAddrs: []string{"10.0.0.11:26379", "10.0.0.12:26379", "10.0.0.13:26379\