Zero-Downtime Migration: Memindahkan Redis Standalone ke Redis Cluster

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern berstandar enterprise, Redis telah bertransformasi dari sekadar alat simple key-value cache menjadi komponen fondasional yang krusial. Redis sering kali memikul beban terberat dalam sistem: mulai dari penyimpanan sesi (session store) untuk jutaan pengguna aktif, distributed locking, rate limiting tingkat lanjut, hingga real-time pub/sub untuk sistem websocket dan antrean instan (in-memory queues). Seiring dengan pertumbuhan eksponensial trafik aplikasi—baik itu platform e-commerce skala masif, layanan perbankan digital, maupun aplikasi SaaS global—infrastruktur Redis Standalone tunggal pasti akan menghadapi batas fisik absolut (hardware wall).

Bottleneck utama pada Redis Standalone bukan terletak pada efisiensi perangkat lunaknya, melainkan pada batasan arsitektural mendasarnya: operasi single-threaded event loop. Ketika kapasitas memori RAM dari satu node fisik atau virtual mencapai batas (misalnya 64GB atau 128GB), atau ketika jumlah permintaan per detik (QPS) melampaui kapasitas satu inti CPU (single core CPU bound), latensi akan melonjak tajam (tail latency atau p99 latency meningkat drastis). Dampaknya fatal: thread pool di lapisan backend web (seperti PHP-FPM, Node.js event loop, atau goroutine Go) akan mengalami blocking, koneksi menumpuk (connection backlog), dan akhirnya memicu cascade failure di seluruh ekosistem layanan web.

Memindahkan arsitektur dari Redis Standalone ke Redis Cluster adalah solusi mutlak untuk mendistribusikan beban data dan komputasi ke dalam bentuk sharding otomatis menggunakan konsep Hash Slots (sebanyak 16384 slot). Namun, tantangan terbesar bagi seorang Web Architect & Infrastructure Engineer bukanlah membuat kluster baru, melainkan bagaimana mengeksekusi migrasi tanpa mematikan layanan (Zero-Downtime Migration). Mematikan aplikasi web selama berjam-jam untuk melakukan dump dan restore data secara manual adalah pelanggaran berat terhadap standar SLA (Service Level Agreement) modern yang menuntut ketersediaan 99.999%.

Perbandingan Kondisi: Sebelum vs Sesudah Migrasi

2. Konsep Inti & Deep Dive Arsitektur

Untuk memahami cara kerja migrasi zero-downtime, kita harus memahami bagaimana Redis Cluster memetakan data dan bagaimana strategi sinkronisasi data langsung (live data synchronization) bekerja di balik layar. Redis Cluster tidak menggunakan consistent hashing sederhana, melainkan membagi seluruh ruang kunci (keyspace) menjadi tepat 16384 Hash Slots. Setiap kunci yang disimpan dihitung nilai slotnya menggunakan algoritma CRC16 yang dimodulasi dengan 16384:

HashSlot = CRC16(key) % 16384

Jika kunci mengandung kurung kurawal {...}, hanya string di dalam kurung kurawal tersebut yang digunakan untuk kalkulasi CRC16. Fitur ini disebut hash tags, yang sangat vital untuk memastikan kunci-kunci yang harus diakses bersamaan berada dalam hash slot dan node fisik yang sama.

Dalam proses migrasi dari Standalone ke Cluster, arsitektur sistem harus melalui tiga fase transisi yang mulus:

[Aplikasi Web (PHP/Go/Node)] 
       │
       ├───────────────────────── (Fase 1: Dual-Writing) ─────────────────────────┐
       ▼                                                                        ▼
[Redis Standalone (Legacy)]                                             [Redis Cluster (New)]
       │                                                                        ▲
       └────── (Fase 2: Background Sync via Redis-Migrate-Tool) ────────────────┘
                                                                                │
                                                       (Fase 3: DNS/Config Cutover)

1. Fase Dual-Writing (Penulisan Ganda di Lapisan Aplikasi/Proxy): Aplikasi web dikonfigurasi untuk menulis data baru ke kedua tempat (Standalone sebagai sumber utama pembacaan, dan Cluster sebagai tujuan). Operasi pembacaan (read) masih dilayani sepenuhnya oleh Standalone.
2. Fase Backfill / Bulk Synchronization: Data historis yang sudah ada di Standalone dipindahkan secara massal ke dalam Redis Cluster menggunakan utility tingkat rendah berbasis protokol replikasi Redis, seperti redis-migrate-tool atau skrip migrasi asinkron.
3. Fase Cutover & Verification: Setelah data sinkron dan lag bernilai nol, operasi pembacaan dialihkan sepenuhnya ke Redis Cluster, diikuti dengan penghentian dual-writing dan penonaktifan instance Standalone.

3. Perbandingan Komparatif / Analisis Pendekatan

Terdapat tiga metode utama untuk memindahkan data dari Redis Standalone ke Redis Cluster. Pemilihan metode sangat bergantung pada ukuran dataset, batasan waktu pemeliharaan, dan kompleksitas kode aplikasi.

[!WARNING] Jangan pernah menggunakan metode DUMP dan RESTORE manual pada produksi berkapasitas besar tanpa jendela pemeliharaan (maintenance window), karena proses enkapsulasi kunci massal akan memblokir event loop Redis dan menyebabkan timeout pada seluruh koneksi web server.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengeksekusi migrasi, pastikan seluruh infrastruktur pendukung telah memenuhi spesifikasi teknis berikut:

• OS / Kernel: Ubuntu 22.04 LTS / Debian 12 Bookworm dengan tuning kernel (vm.overcommit_memory = 1, menonaktifkan Transparent Huge Pages / THP).
• Redis Version: Minimal Redis 7.0+ pada kedua sisi (Standalone dan Cluster) untuk memastikan kompatibilitas penuh dengan struktur replikasi dan manajemen hash slots.
• Topologi Target: Minimal 3 node Master dan 3 node Replica untuk Redis Cluster (total 6 instance terpisah, idealnya disebar di zona ketersediaan / Availability Zones yang berbeda).
• Network / Firewall: Port TCP 6379 (klien) dan 16379 (bus kluster antar node) harus terbuka di antara node-node kluster dan server aplikasi web.

Verifikasi awal sistem operasi pada semua node:

# Menonaktifkan Transparent Huge Pages (THP) untuk performa Redis optimal
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Memastikan overcommit memory diatur dengan benar
sysctl vm.overcommit_memory=1
sysctl -p

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah tahapan implementasi teknis secara menyeluruh, mulai dari konfigurasi Redis Cluster, penerapan Dual-Writing pada backend web (menggunakan Go sebagai contoh performa tinggi), hingga sinkronisasi menggunakan redis-migrate-tool.

Langkah 1: Konfigurasi Redis Cluster Node (Contoh untuk Node 1)

Buat file konfigurasi /etc/redis/redis-cluster.conf pada setiap mesin node kluster:

port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no
bind 0.0.0.0
requirepass YourStrongClusterPassword123!
masterauth YourStrongClusterPassword123!
maxmemory 4gb
maxmemory-policy allkeys-lru

Jalankan Redis dengan konfigurasi tersebut:

redis-server /etc/redis/redis-cluster.conf

Setelah 6 node aktif (misalnya IP 192.168.1.11 sampai 192.168.1.16), inisialisasi kluster menggunakan redis-cli:

redis-cli --cluster create 
  192.168.1.11:6379 192.168.1.12:6379 
  192.168.1.13:6379 192.168.1.14:6379 
  192.168.1.15:6379 192.168.1.16:6379 
  --cluster-replicas 1 
  -a YourStrongClusterPassword123!

Langkah 2: Implementasi Dual-Writing pada Backend Web (Golang)

Berikut adalah implementasi pola Dual-Writing menggunakan bahasa Go untuk memastikan setiap operasi penulisan diteruskan ke Redis Standalone dan Redis Cluster secara bersamaan, sementara pembacaan tetap diarahkan ke Standalone.

package main

import (
	"context"
	"fmt"
	"log"
	"time"

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

type DualRedisManager struct {
	ctx        context.Context
	legacy     *redis.Client
	cluster    *redis.ClusterClient
	migration  bool // Flag untuk mengontrol fase migrasi
}

func NewDualRedisManager(legacyAddr, legacyPass string, clusterAddrs []string, clusterPass string) *DualRedisManager {
	ctx := context.Background()

	legacyClient := redis.NewClient(&redis.Options{
		Addr:     legacyAddr,
		Password: legacyPass,
		DB:       0,
	})

	clusterClient := redis.NewClusterClient(&redis.ClusterOptions{
		Addrs:    clusterAddrs,
		Password: clusterPass,
	})

	return &DualRedisManager{
		ctx:       ctx,
		legacy:    legacyClient,
		cluster:   clusterClient,
		migration: true,
	}
}

// Set melakukan penulisan ganda (Dual-Write) jika mode migrasi aktif
func (d *DualRedisManager) Set(key string, value interface{}, expiration time.Duration) error {
	// 1. Tulis ke Redis Standalone (Sumber Kebenaran Utama saat ini)
	err := d.legacy.Set(d.ctx, key, value, expiration).Err()
	if err != nil {
		return fmt.Errorf("failed to write to legacy redis: %v", err)
	}

	// 2. Jika dalam fase migrasi, tulis juga secara paralel ke Redis Cluster
	if d.migration {
		errCluster := d.cluster.Set(d.ctx, key, value, expiration).Err()
		if errCluster != nil {
			// Log error penulisan cluster tapi jangan gagalkan request utama (Best Effort Async/Sync)
			log.Printf("[WARN] Dual-write to Redis Cluster failed for key %s: %v", key, errCluster)
		}
	}

	return nil
}

// Get membaca data. Selama migrasi awal, baca dari Legacy. Setelah cutover, ubah ke Cluster.
func (d *DualRedisManager) Get(key string) (string, error) {
	if !d.migration {
		return d.cluster.Get(d.ctx, key).Result()
	}
	return d.legacy.Get(d.ctx, key).Result()
}

func main() {
	legacyAddr := "127.0.0.1:6379"
	legacyPass := "LegacyPassword123!"
	clusterAddrs := []string{"192.168.1.11:6379", "192.168.1.12:6379", "192.168.1.13:6379\