Belajar Apache Kafka - Tiered Storage (KIP-405)

#Pendahuluan

Selama ini, seluruh data Kafka tersimpan di disk broker. Retention jangka panjang berarti menyimpan disk mahal dan menyebar kapasitas ke banyak broker. Tiered storage (KIP-405, diperkenalkan sebagai early access di Kafka 3.6+) mengubah model ini: segmen log yang sudah tua di-offload ke object storage yang jauh lebih murah.

Konsepnya sederhana: data panas yang baru ditulis dan sering dibaca tetap di disk broker (hot tier), sementara segmen lama yang jarang diakses dipindahkan ke S3, GCS, atau Azure Blob (cold tier). Konsumen tetap bisa membaca segmen cold — broker mengambilnya dari object storage secara transparan.

Episode 11 ini akan membahas model hot dan cold tier, cara konfigurasi remote storage, retention lokal versus remote, serta manfaat dan trade-off yang harus kalian pertimbangkan.

#Konsep Tiered Storage

#Hot Tier vs Cold Tier

Sebuah partition memiliki dua lapisan penyimpanan:

• Hot tier: segmen aktif dan segmen tertutup yang masih berada di disk broker. Semua tulis terjadi di sini, dan sebagian besar pembacaan baru juga terjadi di sini.
• Cold tier: segmen tertutup yang sudah di-copy ke object storage dan dilepaskan dari disk broker. Konsumen yang membaca offset lama akan menarik data dari object storage.

Perpindahan antar tier berjalan otomatis dan asinkron. Broker tetap menjadi satu-satunya titik akses klien — aplikasi tidak perlu tahu data datang dari disk atau object storage.

#Offloading Segmen Lama

Broker menandai segmen tertutup sebagai kandidat offload berdasarkan umurnya. Proses background menyalin segmen beserta indeksnya ke object storage, lalu setelah verifikasi sukses, menghapus salinan lokal. Jika object storage belum menerima segmen, data tetap tersedia dari hot tier — tidak ada celah ketersediaan.

#Kafka sebagai Penyimpanan Jangka Panjang

Dengan tiered storage, retensi tidak lagi dibatasi biaya disk. Kalian bisa menyimpan data bertahun-tahun dengan biaya object storage yang murah, dan mereplay seluruh sejarah kapan pun dibutuhkan — sesuatu yang sebelumnya mahal atau mustahil. Inilah yang mendorong pemanfaatan Kafka sebagai system of record jangka panjang.

#Konfigurasi Remote Storage

#Remote Storage Manager

Untuk mengaktifkan tiered storage, broker membutuhkan implementasi RemoteStorageManager. Kafka menyediakan referensi implementasi untuk S3, GCS, dan Azure Blob yang dapat dikonfigurasi lewat server.properties:

remote.log.storage.system.enable=true
remote.log.storage.manager.class.name=io.kafka.shaded.glue.remote.GlueRemoteStorageManager
remote.log.storage.manager.impl.prefix=remote.storage
remote.storage.bucket.name=my-kafka-logs
remote.storage.region=ap-southeast-1

Konfigurasi di atas memakai AWS Glue storage manager yang tersedia di distribusi Confluent; untuk Kafka open-source, kalian menulis atau memakai plugin RemoteStorageManager yang mengimplementasikan antarmuka yang sama. Nilai remote.storage.bucket.name menunjuk bucket tujuan, dan region menentukan lokasi bucket.

#Retention Lokal vs Remote

Retention kini bisa dibedakan antara local dan remote:

local.retention.ms=604800000
remote.retention.ms=-1
log.retention.bytes=-1

local.retention.ms=604800000 membatasi data yang disimpan di disk broker (7 hari), sementara remote.retention.ms=-1 berarti segmen di object storage tidak pernah kedaluwarsa. Dengan kombinasi ini, broker menampung data panas seminggu di disk dan menyimpan seluruh sejarah di cloud tanpa batas waktu.

#Konfigurasi Tingkat Topic

Tiered storage juga bisa diaktifkan per topic lewat kafka-configs.sh:

bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type topics --entity-name orders \
  --add-config remote.storage.enable=true,local.retention.ms=86400000

Mengaktifkan per topic berguna jika hanya sebagian data yang butuh retensi panjang — misalnya topic audit disimpan selamanya, sementara topic metrik cukup retention satu hari di local.

#Manfaat dan Trade-Off

#Manfaat Utama

• Retensi tak terbatas: data disimpan bertahun-tahun dengan biaya murah, membuka replay dan audit jangka panjang.
• Biaya broker turun: disk broker bisa diperkecil karena hanya menampung hot data; object storage jauh lebih murah per GB.
• Skalabilitas lebih mudah: kapasitas tidak lagi dibatasi jumlah disk di broker, mengurangi kebutuhan penambahan node.
• Backup implisit: salinan di object storage menjadi lapisan proteksi tambahan terhadap kegagalan disk broker.

#Trade-Off yang Harus Dipahami

• Latensi baca: membaca segmen cold memerlukan perjalanan ke object storage, menambah latensi beberapa puluh hingga ratusan milidetik dibanding disk lokal.
• Kompleksitas ops: kalian kini mengelola kredensial cloud, kebijakan bucket, dan lifecycle tambahan.
• Biaya egress dan request: biaya operasi object storage (GET/PUT) bisa signifikan pada workload baca-replay yang besar.
• Kematangan fitur: tiered storage masih relatif baru; uji menyeluruh sebelum dipakai untuk workload mission-critical.

#Skenario Recovery

Ketika broker kehilangan disk atau perlu memuat kembali data, segmen cold tidak hilang — data masih ada di object storage. Broker yang baru dapat menarik segmen tersebut kapan dibutuhkan, sehingga recovery tidak lagi berarti kehilangan histori. Ini menjadikan tiered storage bagian penting dari strategi disaster recovery yang akan dibahas di episode 25.

#Penutup

Di episode 11 ini kalian sudah memahami model hot dan cold tier, cara mengonfigurasi remote storage manager dan retention lokal versus remote, serta manfaat biaya dan trade-off latensi dari tiered storage.

Inti yang harus dibawa pulang:

• Tiered storage memindahkan segmen lama dari disk broker ke object storage.
• Hot tier melayani tulis dan baca baru; cold tier melayani replay data lama.
• RemoteStorageManager menentukan target object storage (S3, GCS, Azure Blob).
• local.retention.ms membatasi data di disk; remote.retention.ms mengatur data di cloud.
• Tiered storage bisa diaktifkan per topic melalui kafka-configs.sh.
• Baca dari cold tier lebih lambat, jadi perhitungkan biaya latensi dan egress.

Di episode 12 selanjutnya kita akan membahas Kafka Connect — framework integrasi data untuk memindahkan data antara Kafka dan sistem lain. Kalian akan belajar arsitektur worker standalone dan distributed, source dan sink connector, converter dan SMT, serta deployment dengan REST API.