Sesi 33 — Harga Sebuah Index (Elasticsearch, ILM, & Kibana)

1. Bayangkan Jika: Perpustakaan dengan Satu Pintu Ajaib

Bayangkan sebuah perpustakaan dengan satu juta buku, dan seorang pustakawan yang bisa menemukan buku mana pun dalam satu detik, hanya dari satu kata di dalamnya. Hebat. Sampai kamu bertanya: berapa lama waktu yang dia butuhkan untuk MENARUH satu buku baru ke rak?

Ternyata satu buku baru butuh lima menit — karena untuk setiap kata di dalamnya, dia harus menulis kartu indeks kecil dan menyelipkannya ke rak kartu yang sudah rapi. Semakin banyak kata, semakin banyak kartu.

Dan pertanyaan terakhir, yang paling tidak nyaman: berapa biaya sewa gedungnya? Karena rak kartu itu tidak gratis, dan buku yang tidak pernah dibaca pun tetap menempati ruang.

Itulah Elasticsearch. Kekuatannya (cari instan) dan bebannya (tulis mahal, simpan mahal) datang dari sumber yang sama: index.

2. Apa yang Sebenarnya Terjadi

2.1 Log Sudah Terkumpul — Sekarang Harus Bisa Dicari

Sampai Sesi 32, log sudah berhasil diangkut keluar dari pod. Tapi masih tersebar di puluhan node. Pertanyaan insiden selalu sama: "request dengan ID ini gagal di layanan mana?"

Kalau log cuma file teks di server, jawabannya butuh berjam-jam: masuk ke tiap server, grep, tunggu, ulangi. Elasticsearch mengubah ini jadi satu query.

2.2 Inverted Index: Kenapa Cari Instan, Kenapa Tulis Mahal

Buku indeks di akhir buku adalah analogi paling dekat. Alih-alih membaca seluruh isi buku untuk mencari kata "timeout", kamu buka halaman indeks: timeout — hal. 12, 45, 78.

Elasticsearch membangun struktur itu untuk setiap field di setiap dokumen. Konsekuensinya:

Operasi	Biaya	Kenapa
Cari	Sangat murah	Index langsung menunjuk ke dokumen yang cocok
Tulis	Mahal	Setiap dokumen baru harus memecah teks jadi token, membangun/memperbarui index segment
Tambah field	Sangat mahal	Setiap field baru = struktur index baru untuk seluruh dokumen

Angka praktis: menulis ke Elasticsearch bisa 10–30× lebih mahal daripada membaca. Inilah kenapa Elasticsearch bukan database transaksi, dan kenapa log volume punya konsekuensi biaya langsung.

2.3 Shard dan Replica

Satu index Elasticsearch tidak disimpan di satu tempat. Dia dipotong jadi shard — potongan-potongan yang bisa dicari secara paralel di beberapa node. Setiap shard punya replica (salinan) untuk keandalan dan untuk melayani pembacaan.

Konsekuensi yang sering dilupakan:

Jumlah shard ditentukan saat index dibuat dan tidak bisa diubah sembarangan nanti. Salah pilih di awal = harus reindex seluruh data (operasi yang bisa berjalan berhari-hari).
Terlalu banyak shard kecil lebih buruk daripada beberapa shard besar: setiap shard punya overhead (memori, file handle, biaya pencarian di koordinator). Ini penyakit over-sharding, sangat umum di instalasi yang tidak terkelola.
Terlalu sedikit shard membuat pencarian tidak bisa paralel dan satu shard jadi terlalu besar untuk dipindahkan.

2.4 Mapping Explosion — Pembunuh yang Diam

Ini kegagalan khas log, dan terjadi karena kebiasaan baik: aplikasi mengirim JSON terstruktur.

Masalahnya, kalau tidak ada batas, setiap nama field baru di JSON otomatis jadi kolom baru di index. Beberapa contoh nyata:

Log error menyertakan error.context.request.payload.user_id_12345 sebagai nama field. Setiap user = satu kolom baru.
Log audit menyertakan nama resource dinamis.
Satu penyewa (tenant) menambahkan field khusus, dan template index memakainya untuk semua.

Hasilnya: index yang seharusnya punya 40 kolom tiba-tiba punya 40.000 kolom. Node kehabisan memori hanya untuk memegang metadata. Cluster jadi tidak stabil.

Pertahanannya: - Dynamic mapping dimatikan untuk index log, atau dibatasi ke strict. - Index template dengan daftar field yang diizinkan. Field tidak dikenal masuk ke satu kolom additional bertipe teks. - Batasan di sisi aplikasi: log adalah kontrak, bukan tempat sampah JSON. Field yang tidak dibutuhkan tidak dikirim. - Mapping explosion punya batas keras (default 1000 field per index) yang, kalau tercapai, membuat dokumen ditolak — artinya log hilang, dan itu baru terasa saat insiden.

2.5 ILM: Hot, Warm, Cold, Delete

Log berumur satu jam berbeda kebutuhan dengan log berumur satu tahun. Index Lifecycle Management memindahkan index antar kelas penyimpanan seiring usianya:

Fase	Umur umum	Penyimpanan	Kenapa
Hot	0–3 hari	NVMe/SSD cepat	Sedang aktif dibaca saat insiden
Warm	3–30 hari	SSD standar / HDD cepat	Masih dicari, tapi lebih jarang
Cold	30–90 hari	HDD besar / object storage	Pencarian lambat, jarang diakses
Delete	>90 hari	Dihapus	Retensi sudah selesai

Ini bukan sekadar optimasi teknis — ini keputusan bisnis. Pertanyaan "berapa lama kita simpan log" punya jawaban berbeda untuk tim keamanan (audit), tim engineering (debug), dan tim keuangan (tagihan).

2.6 Disk Watermark → Index Read-Only

Ini kegagalan yang paling tidak intuitif dan paling menyakitkan.

Elasticsearch punya watermark disk: 85% (low), 90% (high), 95% (flood). Begitu disk melewati 90% (high watermark), cluster berhenti mengalokasikan shard baru ke node itu. Begitu melewati 95%, Elasticsearch mengubah index menjadi read-only.

Efeknya bukan "log tidak bisa dibaca". Efeknya:

Aplikasi mencoba menulis log → ditolak.
Aplikasi ikut gagal, karena sebagian aplikasi menunggu log terkirim dan menandai request itu gagal.
Pipa log (Sesi 32) menumpuk di buffer.
Buffer penuh → log dibuang diam-diam, atau memori node habis.

Jadi satu disk yang penuh di cluster log bisa berantai jadi insiden produksi total. Yang harus ada: pemantauan disk cluster sebagai alarm tingkat pertama, dan kebijakan retensi yang cukup agresif supaya watermark tidak pernah didekati.

2.7 Kibana: Jendela, Bukan Gudang

Semua ini tidak berguna tanpa tempat bertanya. Kibana adalah tempat Discover (telusuri log mentah), dashboard, visualisasi, dan saved search hidup.

Catatan penting untuk performance tester: pencarian di Kibana punya biaya. Query dengan wildcard di depan (*timeout) atau rentang waktu sangat lebar tanpa filter field akan memindai seluruh shard — dan di cluster besar, satu orang yang meninggalkan dashboard auto-refresh bisa membebani cluster log untuk semua orang. Ini pola insiden yang nyata: "Kibana lambat" hampir selalu berarti "ada yang menembakkan query mahal".

3. Bagaimana Jika Kita Coba... (Solusi Naif)

"Simpan semua log tanpa batas — storage kan murah."

Storage memang murah, tapi pencarian tidak. Index yang terus tumbuh memperbesar jumlah shard, memperbanyak node, dan menaikkan biaya RAM cluster. Retensi tanpa batas adalah cara termahal menyimpan log yang tidak akan pernah dibaca.

"Kita pakai satu index besar untuk semuanya."

Satu index besar berarti satu operasi ILM untuk semua, satu titik gagal, dan tidak bisa memindahkan kelas penyimpanan sebagian data. Elasticsearch menyarankan index per-hari atau per-ukuran (rollover) justru supaya retensi dan pemindahan bisa granular.

"Kita index semua field supaya bisa dicari apa saja."

Inilah jalan menuju mapping explosion. Index semua field = biaya terbesar untuk kemungkinan pencarian yang paling kecil. Field yang tidak pernah dipakai untuk filter sebaiknya tidak di-index.

4. Nama Resminya

Istilah	Arti praktis
Elasticsearch	Mesin pencari dan penyimpanan index berbasis Lucene
Inverted index	Struktur "kata → daftar dokumen"; sumber kecepatan pencarian dan biaya penulisan
Shard	Potongan index yang bisa dicari paralel; jumlahnya ditetapkan saat index dibuat
Replica	Salinan shard; untuk keandalan dan melayani pembacaan
Over-sharding	Terlalu banyak shard kecil; overhead memori dan pencarian
Mapping	Skema field (nama, tipe, apakah di-index)
Mapping explosion	Jumlah kolom index meledak karena field dinamis tanpa batas
Index template	Cetakan index yang menetapkan mapping dan pengaturan lebih dulu
ILM	Index Lifecycle Management: hot → warm → cold → delete
Rollover	Memindahkan penulisan ke index baru saat ukuran/umur tercapai
Disk watermark	Ambang disk (85/90/95%); melewatinya membuat index read-only
Read-only index	Index yang menolak penulisan — pemicu rantai kegagalan aplikasi
Kibana	Antarmuka pencarian, dashboard, dan visualisasi di atas Elasticsearch
ELK / EFK	Elasticsearch+Logstash/Beats+Kibana / Elasticsearch+Fluent*+Kibana

5. Di Dunia Kita

Ciri instalasi log yang matang:

Index menggunakan template dengan mapping eksplisit; dynamic mapping dimatikan.
Rollover + ILM mengatur perjalanan data dari hot sampai delete.
Retensi ditetapkan bersama pemilik bisnis, bukan default.
Alarm disk cluster adalah alarm prioritas tinggi, bukan catatan sampingan.
Ada kontrol atas query mahal (dibatasi, dijadwalkan, atau dilarang oleh kebijakan).
Jumlah shard per index dihitung, bukan dibiarkan bertambah liar.

Ciri instalasi yang rapuh: satu index bernama logs-* yang tumbuh selamanya, mapping yang berubah tiap minggu, dan tidak ada yang tahu berapa lama retensinya.

6. Lensa Performance Tester

Angka yang harus diminta ketika ada Elasticsearch di design doc:

Ingest rate — berapa dokumen/detik yang harus ditelan saat beban puncak, dan berapa kapasitas nyatanya?
Write latency vs search latency — dua angka berbeda dengan karakter berbeda; minta keduanya.
Jumlah shard dan pertumbuhannya — berapa shard per index sekarang, dan berapa tiga bulan lagi?
Ambang watermark dan waktu retensi — jam berapa disk diprediksi melewati 90%? Ini bisa dihitung dari growth rate.
Skenario uji: - Kirim log 2× volume normal selama load test, lihat apakah ingest tertinggal (lag). - Isi disk sampai mendekati watermark di lingkungan uji dan buktikan apa yang terjadi pada aplikasi — apakah memang gagal, atau degradasi. - Jalankan query Kibana yang mahal bersamaan dengan beban tinggi dan ukur dampaknya pada cluster.
Field count per index — kalau angkanya sudah ribuan dan bertambah, mapping explosion sedang berjalan.

7. Pertanyaan untuk Ronde Berikutnya

"Kita sudah tahu berapa harganya kalau merakit semuanya sendiri. Tapi ada perusahaan yang membayar sepuluh kali lipat dan mendapat jawaban akar masalah dalam sepuluh detik. Apa sebenarnya yang mereka beli — dan apa yang mereka korbankan?"

(Lanjut ke Sesi 34: Beli Mata atau Rakit Sendiri — Dynatrace vs Jalur DIY)