Kafka Tiered Storage: Bagaimana Cara Anda Merancang Retensi Lokal dan Jarak Jauh (Remote)?

Konteks dan cakupan

Pewawancara mungkin bertanya: “Jika sebuah topik Kafka harus menyimpan riwayat selama bertahun-tahun, bagaimana Anda akan merancang kebijakan retensi lokal dan remote pada Tiered Storage?”

Intinya bukan menghafal nama konfigurasi. Melainkan menjelaskan siklus hidup segmen log di seluruh tier lokal dan remote. KIP-405 mempertahankan tier lokal pada broker Kafka sambil mengunggah segmen log yang sudah selesai ke penyimpanan eksternal; retensi lokal dapat lebih singkat daripada retensi remote untuk mengurangi tekanan disk broker. Jawaban yang lengkap juga mencakup kegagalan object-store, latensi pembacaan data historis, kepemilikan penghapusan, dan pemulihan.

Apa yang sedang diuji oleh pewawancara

Apakah Anda memahami tiered storage sebagai penempatan panas/dingin (hot/cold placement) untuk segmen log, bukan Kafka yang berubah menjadi object store.
Apakah Anda dapat memisahkan kapabilitas kluster, remote.storage.enable di tingkat topik, dan kebijakan retensi.
Apakah Anda dapat memperkirakan kapasitas disk panas, kapasitas remote, keterlambatan unggah (upload lag), dan bandwidth pemutaran ulang (replay bandwidth).
Apakah Anda mempertimbangkan pemadaman remote, konsistensi metadata, pergerakan partisi, dan pemutaran ulang konsumen (consumer replay).
Apakah Anda menetapkan kepemilikan yang jelas untuk penghapusan remote tanpa pertumbuhan yang tidak disengaja atau tidak terbatas.

Pertanyaan klarifikasi

Topik mana yang memerlukan penyimpanan historis, dan apakah setiap topik harus diaktifkan?
Berapa target latensi pembacaan data panas dan throughput pemutaran ulang historis?
Apa saja batasan anggaran disk lokal, kelas penyimpanan remote, wilayah, dan persyaratan kepatuhan?
Selama pemadaman object-store, bagaimana produksi, konsumen real-time, dan pembaca historis mengalami degradasi?
Apakah penghapusan didorong oleh waktu, ukuran, peristiwa kepatuhan, atau kebijakan penyewa (tenant policy)?

Jawaban 30 detik

Anda dapat mengatakan:

Saya akan memperlakukan tier lokal Kafka sebagai cache panas berlatensi rendah, mengunggah segmen yang sudah selesai ke tier remote, dan menentukan retensi lokal serta remote secara terpisah. Aktifkan remote.storage.enable hanya untuk topik yang membutuhkannya; gunakan retensi lokal untuk mengontrol disk broker dan retensi remote untuk memenuhi persyaratan audit dan pemutaran ulang. Saya akan mengukur keterlambatan unggah, latensi pembacaan remote, kegagalan object-store, dan pergerakan partisi, lalu menetapkan penanggung jawab untuk pembersihan remote. Konsumen real-time tetap berada di jalur lokal; pemutaran ulang historis menerima latensi tambahan dengan throttling dan pemantauan.

Penalaran langkah demi langkah

Tetapkan siklus hidup dua tingkat (two-tier lifecycle)

Kafka masih menggunakan segmen log partisi sebagai unit dasar. Segmen aktif ditulis secara lokal; setelah rolling, komponen log remote mengunggah segmen dan informasi indeks ke penyimpanan remote yang dikonfigurasi. Klien tidak boleh berasumsi bahwa setiap byte historis tetap berada di disk broker:

text

producer -> leader broker local segment
                    | segment roll
                    v
             remote object store
consumer <---- local cache or remote fetch

Tier lokal melayani konsumsi berlatensi rendah dan tier remote menampung retensi yang lebih lama. Pertahankan jendela keamanan yang dapat diamati antara penyelesaian unggahan dan penghapusan lokal; pembuatan objek saja bukanlah bukti bahwa indeks dan metadata dapat digunakan.

Batasi cakupan fitur per topik

Dokumentasi Apache Kafka menyatakan bahwa setelah konfigurasi di sisi broker, sebuah topik tetap memilih ikut serta (opt-in) dengan remote.storage.enable. Nyatakan apakah model tata kelolanya bersifat opt-in atau aktif secara default, karena mengaktifkan setiap topik dapat melipatgandakan biaya dan potensi titik kegagalan.

Pisahkan retensi lokal dan remote

Atur retensi lokal berdasarkan waktu atau ukuran untuk mempertahankan data panas dan kapasitas baca yang diperlukan untuk penugasan ulang (reassignment); atur retensi remote untuk audit, pemutaran ulang, dan kepatuhan. Invariannya adalah bahwa satu-satunya salinan lokal tidak dihapus sampai objek remote, indeks, metadata, dan uji pemulihan diverifikasi. Penghapusan remote memerlukan audit independen dan penanganan percobaan ulang (retry).

Rancang pembacaan dan degradasi

Konsumen real-time membaca tier lokal terlebih dahulu; offset di luar jendela lokal memicu pembacaan remote. Ketika penyimpanan remote melambat, batasi (throttle) pemutaran ulang historis untuk melindungi lalu lintas langsung (live traffic). Jika tidak tersedia, nyatakan offset mana yang sementara tidak dapat dibaca, bagaimana peringatan dipicu, dan bagaimana pemulihan bekerja. Uji waktu pembangunan ulang metadata dan cache selama pergerakan partisi, pergantian pemimpin (leader changes), dan restart broker.

Contoh jawaban berkualitas tinggi

Pertama-tama saya akan mengonfirmasi jendela pembacaan data panas topik, throughput pemutaran ulang, periode retensi, dan persyaratan kepatuhan. Mengikuti KIP-405, tier lokal broker adalah cache panas dan segmen yang telah di-roll diunggah ke penyimpanan objek remote; hanya topik yang memerlukan riwayat yang mengaktifkan remote.storage.enable. Retensi lokal mengikuti anggaran disk dan kebutuhan pemutaran ulang real-time, sedangkan retensi remote mengikuti periode audit. Gerbang penghapusan adalah objek remote, indeks, dan metadata yang terverifikasi, bukan sekadar permintaan unggahan. Konsumen mempertahankan latensi rendah di dalam jendela lokal; pemutaran ulang yang lebih lama menggunakan pembacaan remote dengan throttling. Saya akan memantau keterlambatan unggah, latensi pembacaan remote, hit cache, ketidakcocokan objek/metadata, kegagalan penghapusan, dan offset yang tidak dapat dibaca, serta melatih pemulihan saat terjadi pemadaman object-store, restart broker, dan pergerakan partisi. Pembersihan remote memerlukan penanggung jawab, jejak audit, dan prosedur pemulihan; menghapus file broker tidak menghilangkan tanggung jawab tersebut.

Kesalahan umum

Mengklaim bahwa tiered storage mengalirkan setiap record Kafka langsung ke penyimpanan objek dan mengabaikan segment rolling.
Hanya memberikan sakelar kluster dan mengabaikan remote.storage.enable di tingkat topik.
Menghitung biaya objek sambil mengabaikan latensi pembacaan remote, keterlambatan unggah, dan bandwidth pemutaran ulang.
Menganggap bahwa menghapus file broker secara otomatis menghapus objek remote.
Membiarkan pemutaran ulang historis menghabiskan sumber daya yang dibutuhkan oleh lalu lintas langsung selama kegagalan remote.
Mengabaikan pemantauan dan latihan pemulihan untuk konsistensi objek, indeks, dan metadata.

Pertanyaan lanjutan dan tanggapannya

1. Bagaimana Anda memilih waktu retensi lokal?

Hitung mundur dari jendela rewind real-time terbesar, anggaran disk, waktu pemulihan penugasan ulang, dan margin keamanan periode kegagalan. Sertakan lonjakan pemutaran ulang dan jendela pemeliharaan daripada hanya rata-rata consumer lag.

2. Bagaimana jika remote object store tidak tersedia untuk sementara waktu?

Jeda atau batasi (throttle) pembacaan di luar jendela lokal, pertahankan rentang lokal yang terverifikasi, dan beri peringatan pada kegagalan unggah dan baca. Produksi dan konsumsi real-time berlanjut dalam kapasitas lokal yang divalidasi; pembacaan historis menyusul setelah pemulihan. Tampilkan status eksplisit untuk offset yang tidak dapat dibaca alih-alih mengembalikan data kosong.

3. Bagaimana Anda membuktikan bahwa penghapusan aman?

Sebelum menghapus segmen lokal, verifikasi bahwa objek remote, indeks, dan metadatanya dapat dibaca serta catat rentang segmennya. Untuk penghapusan remote, audit kebijakan retensi, lakukan uji petik pembacaan, dan jalankan latihan pemulihan; beri peringatan pada penghapusan yang gagal, objek yatim (orphan objects), dan celah metadata.