Belajar Elasticsearch - Cross-Cluster Search & Replication

#Pendahuluan

Satu cluster memang kuat, tapi organisasi besar jarang hidup dengan satu cluster saja: cluster per region, per tim, per lingkungan, atau per fungsi (misalnya cluster observability terpisah dari cluster aplikasi). Data yang tersebar menimbulkan dua kebutuhan: mencari data di semua cluster sekaligus, dan menyalin data antar cluster untuk ketahanan.

Episode 22 membahas dua fitur yang menjawab kebutuhan itu: cross-cluster search (CCS) — mencari lintas cluster tanpa menyalin data — dan cross-cluster replication (CCR) — menyalin index secara kontinu dari cluster leader ke follower untuk disaster recovery dan geo-distribution.

#Cross-Cluster Search: Konsep

CCS memungkinkan satu cluster mengeksekusi pencarian di cluster lain secara transparan. Kalian tidak perlu menyalin data — cukup menunjuk cluster jarak jauh sebagai remote cluster, lalu mencarinya seperti index lokal:

GET /remote-logs:logs-*/_search

Notasi remote-cluster:index memberi tahu Elasticsearch ke mana harus mencari. Hasilnya digabung oleh coordinating node di cluster lokal. Inilah dasar data federation: banyak sumber data, satu titik pencarian.

#Menyiapkan Remote Cluster

Remote cluster didaftarkan lewat cluster settings:

PUT /_cluster/settings

{
  "persistent": {
    "cluster.remote.remote-logs.seeds": [
      "logs-node1:9300",
      "logs-node2:9300"
    ]
  }
}

Setiap node lokal harus memiliki role remote_cluster_client untuk terhubung. Cek status koneksi:

GET /_remote/info

#Menjalankan Cross-Cluster Search

Pencarian lintas cluster memakai nama remote sebagai awalan index:

{
  "query": {
    "match": { "message": "timeout" }
  }
}

Di request body, kalian tentukan index di bagian index parameter request: POST /remote-logs:logs-*,remote-prod:app-logs-*/_search. Untuk aggregation lintas cluster, CCS mendukung aggregation penuh — data digabung di node koordinator.

Keamanan dan performa CCS perlu diperhatikan:

• CCS membutuhkan TLS (episode 16) dan kredensial antar cluster — gunakan remote_cluster_client dengan API keys.
• Setiap pencarian CCS menambah latency (hop jaringan) dan membebani cluster sumber.
• Gunakan ccs_minimize_roundtrips untuk mengurangi round-trip; hasilnya bisa lebih lambat untuk aggregation besar.

#Use Cases CCS dan Pertimbangan

Pertimbangan penting: jika cluster remote tidak terjangkau, pencarian CCS gagal total (atau sebagian sesuai setting skip_unavailable). Setel "skip_unavailable": true agar satu cluster down tidak mematikan seluruh pencarian.

#Cross-Cluster Replication: Konsep

CCR menyalin index secara kontinu antar cluster dengan model leader-follower: satu index di cluster leader, salinannya di cluster follower diperbarui terus. Ciri-cirinya:

• Satu arah (leader → follower). Untuk dua arah, buat replication terbalik juga — dengan hati-hati terhadap konflik.
• Follower index bersifat read-only — semua tulis hanya boleh di leader.
• Salinan near-real-time dengan lag yang terukur (milidetik hingga detik).

#Menyiapkan CCR

Syaratnya sama dengan CCS: remote cluster terdaftar dan TLS aktif. Lalu buat index follower di cluster target dengan nama remote sebagai sumber:

PUT /remote-logs:logs-prod/_ccr/follow

{
  "remote_cluster": "remote-logs",
  "leader_index": "logs-prod"
}

Saat ini jalan, perubahan di leader (index, update, delete) tersalin ke follower. Untuk menyamakan mapping awal, gunakan _ccr/auto_follow dengan pola index:

PUT /_ccr/auto_follow/logs-follow-pattern

{
  "remote_cluster": "remote-logs",
  "leader_index_patterns": ["logs-*"]
}

Dengan auto follow, setiap index baru logs-* di leader otomatis punya follower — sangat berguna untuk data time-series yang rollover terus-menerus.

#Use Cases CCR dan Monitoring Lag

#Monitoring Replication Lag

Replication lag — selisih waktu antara tulis di leader dan muncul di follower — adalah metrik paling penting CCR:

GET /remote-logs:logs-prod/_ccr/info

{
  "follower_indices": [
    {
      "follower_index": "logs-prod",
      "leader_index": "logs-prod",
      "remote_cluster": "remote-logs",
      "time_since_last_read_millis": 850,
      "follower_checkpoint": 4210
    }
  ]
}

time_since_last_read_millis kecil berarti lag rendah. Lag yang membesar menandakan jaringan bermasalah, follower kewalahan, atau leader yang lambat — pantau dan buat alert (episode 21). Jangan lupa menambahkan ccr metrik ke monitoring.

#Kesalahan Umum

1. Memakai CCS saat butuh salinan. CCS tanpa reduksi jaringan tidak menggantikan CCR untuk DR.

2. Lupa skip_unavailable. Satu cluster down mematikan seluruh pencarian CCS.

3. Menulis ke follower index. Follower read-only — tulis di leader, lalu tunggu sinkronisasi.

4. Mengabaikan replication lag. Lag yang membesar = bencana menunggu — pantau dan alert.

5. TLS tidak aktif antar cluster. Koneksi CCS/CCR wajib terenkripsi.

#Penutup

Di episode 22 kalian menguasai cross-cluster search dan replication: konsep CCS dengan remote clusters dan data federation, setup remote cluster dengan seed hosts, menjalankan pencarian lintas cluster beserta pertimbangan performa dan keamanannya, lalu CCR dengan model leader-follower, setup follow dan auto follow, serta monitoring replication lag.

Inti yang harus dibawa pulang:

• CCS mencari lintas cluster tanpa menyalin data; CCR menyalin data secara kontinu.
• CCS butuh skip_unavailable agar satu cluster down tidak mematikan pencarian.
• CCR bersifat satu arah, follower read-only, dengan lag terukur.
• Auto follow menjaga data time-series tetap tersinkron otomatis.
• Pantau time_since_last_read_millis sebagai indikator kesehatan replication.

Cluster yang terhubung menyediakan data besar — dan data besar bisa diolah lebih jauh. Di episode 23 kita bahas fitur machine learning Elasticsearch: anomaly detection dengan ML jobs, single vs multi-metric, population analysis; data frame analytics untuk outlier, regression, dan classification; serta fitur NLP 8.x — ELSER, semantic search, dan integrasi embeddings. Sampai jumpa!