Retensi, Log Compaction & Tiered Storage — Belajar Apache Kafka

Dua Kebijakan Pembersihan

cleanup.policy=delete   ← buang berdasarkan umur atau ukuran (default)
cleanup.policy=compact  ← simpan nilai terakhir untuk tiap kunci
cleanup.policy=compact,delete  ← keduanya sekaligus

Retensi Berbasis Hapus

Setelan	Default	Arti
`retention.ms`	7 hari	Umur maksimum data
`retention.bytes`	-1 (tanpa batas)	Ukuran maksimum per partisi
`segment.ms`	7 hari	Kapan segmen aktif ditutup
`segment.bytes`	1 GB	Ukuran segmen sebelum ditutup

🚫 retention.bytes berlaku PER PARTISI, bukan per topik

Menyetel retention.bytes=10737418240 (10 GB) pada topik dengan 12 partisi berarti topik itu boleh memakai 120 GB, bukan 10 GB. Kesalahan hitung ini adalah penyebab klasik disk broker penuh mendadak.

⚠️ Penghapusan bekerja pada segmen, bukan pesan

Kafka hanya bisa menghapus segmen yang sudah ditutup. Segmen aktif tidak akan pernah dihapus berapa pun umurnya. Pada topik berlalu lintas rendah dengan segment.bytes 1 GB, satu segmen bisa terbuka berminggu-minggu, sehingga data jauh melewati retention.ms tetap tersimpan. Bila retensi harus ketat — misalnya untuk kepatuhan privasi — turunkan juga segment.ms.

Log Compaction

Compaction menyimpan nilai terakhir untuk tiap kunci selamanya, dan membuang versi lama dari kunci yang sama. Topik menjadi semacam snapshot keadaan terkini yang bisa diputar ulang.

Sebelum compaction:
  [ user1=A ][ user2=X ][ user1=B ][ user3=P ][ user1=C ][ user2=Y ]

Sesudah compaction:
  [ user3=P ][ user1=C ][ user2=Y ]     ← hanya nilai terakhir tiap kunci

Ini fondasi bagi tabel keadaan Kafka Streams, topik konfigurasi Kafka Connect, dan pola event sourcing yang perlu memulihkan keadaan penuh dari awal.

🚫 Compaction tanpa kunci berarti tidak terjadi apa-apa

Compaction bekerja berdasarkan kunci pesan. Pesan tanpa kunci tidak pernah dipadatkan dan topik akan tumbuh tanpa batas meski cleanup.policy=compact sudah disetel. Selalu pastikan produser ke topik compacted menyertakan kunci.

Tombstone: Cara Menghapus Kunci

kirim(kunci="user1", nilai=null)   ← tombstone

Konsumen melihat nilai null → tanda "entitas ini dihapus"
Setelah delete.retention.ms, tombstone sendiri ikut dibersihkan

⚠️ Konsumen harus menangani nilai null

Kode yang langsung mendeserialisasi nilai tanpa memeriksa null akan melempar exception saat menemui tombstone. Pada topik compacted, tombstone bukan kasus langka melainkan bagian normal dari aliran data.

Tiered Storage

Retensi panjang dulu berarti disk broker yang mahal dan besar. Tiered storage memindahkan segmen lama ke penyimpanan objek seperti S3, sementara data terbaru tetap di disk lokal.

Disk broker:      [ segmen panas — jam/hari terakhir ]
Penyimpanan objek: [ segmen dingin — minggu/bulan sebelumnya ]

Konsumen membaca keduanya secara transparan; yang berbeda hanya latensi.

Manfaat	Konsekuensi
Retensi berbulan-bulan dengan biaya jauh lebih murah	Membaca data lama jauh lebih lambat
Broker menyimpan lebih sedikit data lokal	Ada biaya permintaan ke penyimpanan objek
Rebalance dan pemulihan broker lebih cepat	Perlu konfigurasi dan pemantauan tambahan

💡 Status kesiapan

Tiered storage sudah tersedia di Kafka open source sejak seri 3.6 sebagai fitur awal dan dinyatakan siap produksi pada 3.9 serta diteruskan di 4.x, di samping implementasi bawaan platform terkelola. Fitur ini melekat pada level topik lewat remote.storage.enable, sehingga bisa diadopsi bertahap per topik.