Belajar Elasticsearch - Scaling Elasticsearch Clusters

#Pendahuluan

Data kalian tumbuh, lalu lintas pencarian naik, dan suatu hari node tunggal tidak mampu lagi. Pertanyaannya bukan apakah harus membesarkan, tapi bagaimana membesarkan tanpa downtime dan tanpa membuat performa justru lebih buruk. Scaling Elasticsearch bukan sekadar menambah mesin — ada seni dalam mengatur shard, tier, dan alokasi.

Episode 18 membahas scaling cluster: scaling horizontal dengan menambah node, strategi alokasi shard, ukuran shard ideal 10–50 GB, arsitektur hot-warm-cold (dari episode 10), kapan memilih scale up vs scale out, serta pertimbangan storage SSD vs HDD.

#Horizontal Scaling: Menambah Node

Elasticsearch dirancang untuk scale out: menambah node berarti menambah CPU, RAM, dan disk secara paralel, tanpa mengubah aplikasi. Saat node baru bergabung, Elasticsearch otomatis menyeimbangkan shard yang ada ke node baru.

GET /_cat/nodes?v

Perhatikan kolom heap.percent, ram.percent, dan cpu — sesudah menambah node, pastikan beban tersebar merata. Jika satu node tetap jadi titik panas, kemungkinan ada masalah distribusi shard (atau hot spot karena routing).

#Strategi Alokasi Shard

Alokasi shard diatur oleh allocator Elasticsearch, dengan aturan yang bisa kalian kendalikan. Beberapa setting penting:

PUT /_cluster/settings

{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "80%",
    "cluster.routing.allocation.disk.watermark.high": "85%",
    "cluster.routing.allocation.disk.watermark.flood_stage": "90%"
  }
}

Disk watermark sangat penting: ketika disk node menyentuh ambang flood_stage, Elasticsearch menolak operasi tulis pada index di node itu demi mencegah disk penuh total. Ini pengaman yang harus kalian hormati, bukan lawan.

#Ukuran Shard Ideal: 10–50 GB

Aturan praktis yang wajib diingat: satu shard sebaiknya berukuran 10–50 GB, dengan target nyaman di kisaran 20–30 GB. Alasannya:

• Shard terlalu kecil (< 10 GB) → terlalu banyak shard, overhead dan latensi pencarian naik.
• Shard terlalu besar (> 50 GB) → recovery dan rebalance lambat, satu shard jadi single point of failure yang berat.

Perhitungan sederhana: jika total data 200 GB dengan 50 GB per shard, butuh 4 primary shards. Untuk 10 juta dokumen per hari sepanjang 30 hari, ukur estimasi dengan snapshot awal — jangan menebak.

GET /_cat/shards?v&h=index,prirep,store,docs&s=store:desc

Kesalahan paling umum pemula: membuat 20 shards untuk data 2 GB, atau 2 shards untuk data 500 GB. Keduanya menyakitkan di lain waktu — ingat, jumlah primary shards tidak bisa diubah tanpa reindex.

#Arsitektur Hot-Warm-Cold

Dari episode 10 kita tahu tier membedakan biaya storage. Di episode ini kita praktikkan pembagian node berdasarkan tier:

# node hot (node1)
node.roles: [data_hot, data_content]
node.attr.data_tier: hot
 
# node warm (node2)
node.roles: [data_warm]
node.attr.data_tier: warm
 
# node cold (node3)
node.roles: [data_cold]
node.attr.data_tier: cold

Dengan node yang tersegregasi per tier dan ILM policy (episode 10) yang memindahkan index antar tier, hardware dapat dibeli sesuai kebutuhan: SSD cepat untuk hot, HDD murah untuk cold. Ini bentuk scaling yang hemat biaya tanpa menambah total data.

#Vertical Scaling: Scale Up vs Scale Out

Scale up (memperbesar satu node) dan scale out (menambah node) bukan kompetisi — keduanya punya tempat masing-masing:

Batas atas scale up nyata: heap maksimal 32 GB (episode 14), jadi di luar titik itu jalan satu-satunya adalah scale out. Strategi terbaik menggabungkan keduanya: scale up untuk kebutuhan per-node, scale out untuk kapasitas total.

#Storage: SSD vs HDD

Storage adalah keputusan paling memengaruhi performa. Aturan praktis:

• SSD untuk tier hot dan warm — indexing dan search butuh IOPS tinggi dan latency rendah.
• HDD untuk tier cold/frozen — akses jarang, kapasitas besar lebih penting.
• Hindari storage network yang latent di tier hot — seperti NFS, sering jadi sumber latency.

Satu kebenaran penting: disk yang penuh jauh lebih berbahaya daripada disk yang lambat. Disk penuh membuat shard read-only dan menghentikan tulis. Pantau disk dengan serius (episode 21) sebelum performa jadi masalah.

#Kesalahan Umum

1. Terlalu banyak shard untuk data sedikit. Overhead komunikasi naik — hitung dari 10–50 GB per shard.

2. Menambah node hanya karena "biar cepat". Jika bottleneck tidak di CPU/memori, node baru tidak membantu — ukur dulu (episode 21).

3. Semua node satu tier. Tidak ada penghematan storage — terapkan hot-warm-cold sesuai umur data.

4. Mengabaikan disk watermark. Tulis berhenti diam-diam saat flood — pantau disk dan atur alert.

5. Rebalance otomatis saat kritis. Matikan sementara alokasi saat melakukan operasi maintenance besar: cluster.routing.allocation.enable: none.

#Penutup

Di episode 18 kalian menguasai scaling cluster: horizontal scaling dengan menambah node dan rebalancing otomatis, strategi alokasi shard dengan disk watermark, ukuran shard ideal 10–50 GB, arsitektur hot-warm-cold dengan node per tier, keputusan scale up vs scale out, serta pilihan SSD vs HDD.

Inti yang harus dibawa pulang:

• Scale out dengan node baru untuk kapasitas; perhatikan bottleneck yang sebenarnya.
• Satu shard idealnya 10–50 GB — hitung sebelum membuat index.
• Hot-warm-cold memisahkan hardware sesuai umur data dan menghemat biaya.
• Disk watermark adalah pengaman tulis — hormati dan pantau.
• Scale up ada batasnya (heap 32 GB); scale out adalah jalan skala besar.

Cluster sudah besar — sekarang bagaimana membuatnya cepat dan hemat resource? Di episode 19 kita bahas performance optimization dan tuning: bulk indexing, refresh interval, translog, index sorting; optimasi search dengan caching, filter, routing; serta tuning JVM G1GC, disk I/O, dan thread pool. Sampai jumpa!