Belajar Redis - Redis Cluster (Horizontal Scalability & Sharding)

#Pendahuluan

Sentinel di episode 12 menjaga ketersediaan, tapi ada batas lain: kapasitas. Satu master hanya mampu menyimpan data yang muat di satu memori dan menangani write sebatas satu proses. Episode 13 ini membahas Redis Cluster — jawaban Redis untuk horizontal scalability.

Redis Cluster membagi data ke banyak node via sharding, tetap memberikan redundancy lewat replica, dan menangani failover sendiri tanpa Sentinel terpisah. Ini arsitektur yang dipakai saat dataset melampaui satu node atau write throughput melebihi kapasitas single master. Mari bedah cara kerjanya.

#Kapan Membutuhkan Redis Cluster

#Dua Sinyal Utama

Cluster bukan keputusan pertama — ada biaya operasional dan kompleksitas nyata. Kalian butuh cluster ketika salah satu kondisi berikut terjadi:

Dataset tidak muat di satu node: data melebihi kapasitas RAM sebuah master, atau maxmemory terpaksa sangat tinggi.
Write throughput melebihi single master: satu proses single-threaded tidak lagi mencukupi beban write.

Jika kebutuhan hanya read scaling dan availability, Sentinel + replicas (episode 12) lebih sederhana. Cluster layak dipilih saat data atau write yang menjadi bottleneck.

Info

Mulailah selalu dari single instance, lalu Sentinel, dan naik ke Cluster hanya saat benar-benar terpaksa. Complexitas cluster tidak gratis — ia menuntut disiplin pada operasi multi-key yang akan kita bahas sebentar lagi.

#Arsitektur Redis Cluster

#16.384 Hash Slots

Cluster membagi keyspace menjadi 16.384 hash slots. Setiap key dipetakan ke slot berdasarkan hash-nya:

Pemetaan key ke hash slot

slot = CRC16(key) mod 16384
 
cluster node 1: slot 0 - 5460
cluster node 2: slot 5461 - 10922
cluster node 3: slot 10923 - 16383

Setiap master memiliki satu atau lebih replica untuk failover. Jika satu master mati, cluster otomatis mempromosikan replicanya — tanpa Sentinel, karena cluster punya consensus internal sendiri.

#Client dan Cluster

Ketika client memanggil key di node yang salah, node menjawab dengan MOVED berisi slot dan alamat node yang benar. Client cluster-aware mengikuti redirect ini transparan. Library modern (ioredis, redis-py, go-redis) mendukung mode cluster secara native.

#Setup Redis Cluster 6 Node

#Konfigurasi Tiap Node

Setiap node butuh cluster-enabled yes:

redis-cluster.conf

port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes

cluster-enabled yes menyalakan mode cluster. Ulangi konfigurasi ini untuk port 7000-7005 (tiga master dan tiga replica).

#Membuat Cluster

Dengan redis-cli --cluster create, satu perintah merakit semuanya:

Buat cluster 6 node

redis-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

redis-cli --cluster create mengatur tiga node pertama (7000-7002) sebagai master dan tiga berikutnya (7003-7005) sebagai replica — flag --cluster-replicas 1 berarti satu replica per master. Slot dibagi otomatis merata.

#Verifikasi Cluster

Cek status cluster

redis-cli -p 7000 CLUSTER INFO
redis-cli -p 7000 CLUSTER NODES

CLUSTER INFO menampilkan status cluster_state:ok dan distribusi slot. CLUSTER NODES mendaftar semua node dengan peran, alamat, dan slot yang dipegangnya. Ini dua perintah diagnostik pertama yang harus kalian hafal untuk cluster.

#Hash Tags

#Menyatukan Key yang Terkait

Di cluster, operasi multi-key (misal MSET a b, SINTER, atau transaksi antar dua key) hanya valid jika semua key berada di slot yang sama. Hash tags menjamin ini: hanya bagian key di dalam kurung kurawal yang dipakai menghitung slot.

Hash tag mengunci slot yang sama

slot(CRC16("{user:1}:profile")) == slot(CRC16("{user:1}:orders"))

Key {user:1}:profile dan {user:1}:orders dipetakan ke slot yang sama karena CRC16 hanya dihitung atas user:1. Dengan begitu, operasi yang melibatkan kedua key bisa dijalankan:

Multi-key ops aman dengan hash tag

redis-cli MSET "{user:1}:profile" "Arman" "{user:1}:orders" "3"
redis-cli GET "{user:1}:profile"

MSET "{user:1}:profile" "Arman" "{user:1}:orders" "3" menulis dua key ke slot yang sama — legal di cluster karena keduanya satu slot. Tanpa hash tag, perintah ini error CROSSSLOT Keys in request don't hash to the same slot.

Danger

Hash tag adalah pisau bermata dua. Menggunakan hash tag yang sama (misal selalu {user:1}) untuk ratusan key memusatkan data pada satu slot — membunuh manfaat distribusi. Pakai secukupnya untuk data yang benar-benar dioperasikan bersama.

#Operasional Cluster

Beberapa hal yang perlu kalian ingat:

Resharding: pindahkan slot antar node dengan redis-cli --cluster reshard — bisa dilakukan tanpa downtime.
Rebalancing: redis-cli --cluster rebalance meratakan slot jika ada node baru.
Multi-key constraint: perintah lintas slot gagal dengan CROSSSLOT — disain key dengan hash tag sejak awal.
Failover: saat master mati, replica dipromosikan otomatis; perlu penanganan cluster-require-full-coverage (default: cluster menolak query jika ada slot tanpa pemilik).

#Penutup

Episode 13 membekali kalian Redis Cluster untuk horizontal scalability: pembagian 16.384 hash slots ke master nodes, arsitektur 6 node dengan 3 master + 3 replica, kapan harus naik ke cluster, serta hash tags untuk operasi multi-key.

Inti yang harus dibawa pulang:

Naik ke cluster saat dataset atau write throughput melampaui satu master.
Keyspace dibagi ke 16.384 hash slots via CRC16(key) mod 16384.
redis-cli --cluster create ... --cluster-replicas 1 merakit cluster 6 node.
CLUSTER INFO dan CLUSTER NODES adalah diagnostik pertama.
Hash tag {user:1}:... menyatukan key terkait ke satu slot.
Operasi lintas slot gagal dengan CROSSSLOT — disain key sejak awal.
Resharding bisa dilakukan online; cluster memilih replicanya sendiri tanpa Sentinel.

Di episode 14 selanjutnya kita beralih ke Security: Authentication, ACL & Encryption — mengamankan Redis dari akses tak sah. Kalian akan belajar requirepass, Access Control Lists user granular, TLS in-transit, serta hardening protected-mode dan rename-command. Siap mengunci server kalian?