Kafka Topic Advanced: Retensi Log

Konfigurasi Topik Kafka: Retensi Log

Dalam Apache Kafka, retensi log adalah mekanisme penting untuk mengelola penyimpanan data dengan menghapus segmen log lama berdasarkan waktu atau ukuran. Retensi log memastikan bahwa data yang sudah tidak relevan dihapus untuk mengosongkan ruang disk, sekaligus menjaga data tetap tersedia sesuai kebutuhan aplikasi. Artikel ini akan menjelaskan cara kerja retensi log, parameter konfigurasi yang relevan, serta langkah-langkah untuk mengatur kebijakan retensi menggunakan alat CLI Kafka. Kami juga akan membahas praktik terbaik dan pertimbangan untuk mengoptimalkan pengelolaan penyimpanan di Kafka.

Pengenalan Retensi Log

Kafka menyimpan pesan dalam segmen log, yang merupakan file data untuk setiap partisi topik (lihat artikel sebelumnya tentang Kafka Topic Internals: Segments and Indexes). Segmen aktif digunakan untuk menulis data baru, sedangkan segmen yang sudah ditutup dapat dihapus berdasarkan kebijakan retensi. Retensi log dikendalikan oleh dua jenis parameter utama:

  • Retensi Berdasarkan Waktu: Menentukan berapa lama pesan disimpan sebelum dihapus.

  • Retensi Berdasarkan Ukuran: Menentukan batas ukuran total pesan per partisi sebelum segmen lama dihapus.

Retensi dapat dikonfigurasi pada dua level:

  • Level Broker: Berlaku sebagai default untuk semua topik, dikonfigurasi dalam file server.properties dengan awalan log..

  • Level Topik: Menimpa konfigurasi default broker untuk topik tertentu, menggunakan alat CLI seperti kafka-configs.sh.

Parameter Retensi

  1. Retensi Berdasarkan Waktu:

    • log.retention.hours: Menentukan waktu retensi dalam jam. Default: 168 jam (1 minggu).

    • log.retention.minutes: Menentukan waktu retensi dalam menit.

    • log.retention.ms: Menentukan waktu retensi dalam milidetik. Default: 604800000 ms (1 minggu).

    • Catatan: Jika lebih dari satu parameter waktu ditentukan, parameter dengan unit terkecil (misalnya, log.retention.ms) akan diutamakan. Untuk konsistensi, gunakan retention.ms dalam konfigurasi topik.

  2. Retensi Berdasarkan Ukuran:

    • log.retention.bytes: Menentukan ukuran maksimum data per partisi sebelum segmen lama dihapus. Default: -1 (tanpa batas, hanya retensi waktu yang berlaku).

Kafka akan menghapus segmen log jika salah satu kriteria retensi (waktu atau ukuran) terpenuhi. Namun, segmen aktif tidak dihitung dalam batas ukuran dan tidak dapat dihapus hingga ditutup.

Pertimbangan Retensi Log

Retensi Berdasarkan Waktu

  • Mekanisme: Kafka memeriksa waktu modifikasi terakhir (last modified time) pada file segmen untuk menentukan apakah segmen memenuhi syarat untuk dihapus. Waktu ini mencerminkan timestamp pesan terakhir dalam segmen, yang ditetapkan saat segmen ditutup.

  • Dampak:

    • Nilai Tinggi (misalnya, >1 minggu): Meningkatkan penggunaan ruang disk, tetapi memastikan data tersedia lebih lama untuk konsumer.

    • Nilai Rendah (misalnya, <1 hari): Mengurangi penggunaan disk, tetapi konsumer yang tidak aktif dalam waktu lama mungkin kehilangan data.

  • Pertimbangan: Pastikan waktu retensi sesuai dengan kebutuhan konsumer. Misalnya, jika konsumer mungkin offline selama beberapa hari, atur retensi lebih lama dari periode tersebut.

Retensi Berdasarkan Ukuran

  • Mekanisme: Kafka menghitung total ukuran segmen per partisi (kecuali segmen aktif) dan menghapus segmen lama jika batas log.retention.bytes terlampaui.

  • Dampak:

    • Nilai Positif (misalnya, 500 MB): Membatasi ukuran log per partisi, berguna untuk mengelola penyimpanan pada topik dengan tingkat produksi tinggi.

    • Nilai -1: Tidak ada batas ukuran, hanya retensi waktu yang berlaku.

  • Pertimbangan: Retensi berdasarkan ukuran sangat berguna untuk mencegah pertumbuhan log yang tidak terkendali pada topik dengan volume data besar.

Kombinasi Retensi Waktu dan Ukuran

Anda dapat menggabungkan retensi waktu dan ukuran untuk memenuhi kebutuhan spesifik:

  • Contoh 1: Retensi 1 Minggu

    • Atur retention.ms=604800000 (1 minggu) dan retention.bytes=-1 (tanpa batas ukuran).

    • Ini memastikan data disimpan selama 1 minggu, terlepas dari ukuran log.

  • Contoh 2: Retensi Terbatas 500 MB

    • Atur retention.ms=-1 (tanpa batas waktu) dan retention.bytes=524288000 (500 MB).

    • Ini memastikan log per partisi tidak melebihi 500 MB, tanpa batas waktu.

Mengatur Retensi Log Menggunakan CLI

Berikut adalah langkah-langkah untuk mengatur kebijakan retensi pada topik menggunakan alat CLI kafka-configs.sh. Contoh ini menggunakan topik bernama configured-topic.

Prasyarat

  • Pastikan klaster Kafka berjalan (mode Zookeeper atau KRaft).

  • Gunakan ekstensi CLI yang sesuai: .sh untuk Linux/Mac, .bat untuk Windows.

  • Pastikan broker Kafka aktif di localhost:9092 (atau alamat lain sesuai konfigurasi Anda).

  • Topik configured-topic sudah dibuat (misalnya, dengan perintah berikut):

    kafka-topics.sh --bootstrap-server localhost:9092 --create --topic configured-topic --partitions 3 --replication-factor 1

Langkah-langkah Konfigurasi

  1. Periksa Konfigurasi Topik Saat Ini: Gunakan perintah berikut untuk memeriksa konfigurasi topik:

    kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic configured-topic

    Contoh keluaran:

    Topic: configured-topic TopicId: CDU7SBxBQ1mzJGnuH68-cQ PartitionCount: 3 ReplicationFactor: 1 Configs:
    Topic: configured-topic Partition: 0 Leader: 2 Replicas: 2 Isr: 2
    Topic: configured-topic Partition: 1 Leader: 3 Replicas: 3 Isr: 3
    Topic: configured-topic Partition: 2 Leader: 1 Replicas: 1 Isr: 1

    Keluaran ini menunjukkan bahwa belum ada konfigurasi override untuk retensi.

  2. Atur Retensi Log: Untuk mengatur retensi berdasarkan waktu (1 minggu) dan tanpa batas ukuran:

    kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --add-config retention.ms=604800000,retention.bytes=-1

    Untuk mengatur retensi berdasarkan ukuran (500 MB) dan tanpa batas waktu:

    kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --add-config retention.ms=-1,retention.bytes=524288000
  3. Verifikasi Perubahan: Periksa kembali konfigurasi topik untuk memastikan perubahan diterapkan:

    kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic configured-topic

    Contoh keluaran (untuk retensi 500 MB):

    Topic: configured-topic TopicId: CDU7SBxBQ1mzJGnuH68-cQ PartitionCount: 3 ReplicationFactor: 1 Configs: retention.ms=-1,retention.bytes=524288000
    Topic: configured-topic Partition: 0 Leader: 2 Replicas: 2 Isr: 2
    Topic: configured-topic Partition: 1 Leader: 3 Replicas: 3 Isr: 3
    Topic: configured-topic Partition: 2 Leader: 1 Replicas: 1 Isr: 1
  4. Hapus Konfigurasi Override (Opsional): Jika Anda ingin menghapus konfigurasi retensi dan kembali ke default broker:

    kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --delete-config retention.ms,retention.bytes

    Verifikasi kembali dengan kafka-topics.sh --describe untuk memastikan konfigurasi telah dihapus.

Konfigurasi pada Level Broker

Untuk mengatur retensi default untuk semua topik:

  1. Melalui File Konfigurasi:

    • Buka file config/server.properties.

    • Tambahkan parameter, misalnya:

      log.retention.ms=604800000
      log.retention.bytes=-1
    • Restart broker untuk menerapkan perubahan:

      kafka-server-stop.sh
      kafka-server-start.sh config/server.properties
  2. Melalui CLI (Konfigurasi Dinamis):

    • Atur retensi default untuk semua broker:

      kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-default --add-config log.retention.ms=604800000,log.retention.bytes=-1
    • Verifikasi perubahan:

      kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type brokers --entity-default
    • Hapus konfigurasi dinamis (opsional):

      kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-default --delete-config log.retention.ms,log.retention.bytes

Catatan: Konfigurasi level topik akan menimpa konfigurasi level broker.

Pertimbangan Retensi Log

Batas Minimum, Bukan Batas Ketat

  • Retensi Waktu: Waktu retensi dihitung berdasarkan waktu penutupan segmen (last modified time), bukan timestamp pesan individual. Jika segmen besar (misalnya, 1 GB) hanya menerima sedikit pesan per hari, retensi aktual bisa jauh lebih lama dari retention.ms.

  • Retensi Ukuran: Segmen aktif tidak dihitung dalam batas retention.bytes, sehingga ukuran log aktual bisa melebihi batas yang ditentukan hingga segmen aktif ditutup.

Dampak pada Konsumer

  • Retensi Waktu Pendek: Konsumer yang offline terlalu lama mungkin kehilangan data jika pesan sudah dihapus.

  • Retensi Ukuran Kecil: Topik dengan tingkat produksi tinggi mungkin kehilangan data lebih cepat, memengaruhi konsumer yang membaca dari offset lama.

Dampak pada Penyimpanan

  • Retensi Waktu Panjang atau Tanpa Batas Ukuran: Meningkatkan penggunaan disk, yang dapat menyebabkan disk penuh jika tidak dipantau.

  • Retensi Ukuran Kecil: Mengurangi penggunaan disk, tetapi dapat menghapus data yang masih dibutuhkan oleh konsumer.

Kombinasi Retensi

Menggabungkan retensi waktu dan ukuran memungkinkan fleksibilitas. Misalnya:

  • Retensi 1 Minggu, Tanpa Batas Ukuran: Cocok untuk aplikasi yang memerlukan data tersedia selama periode tertentu.

  • Retensi 500 MB, Tanpa Batas Waktu: Cocok untuk lingkungan dengan keterbatasan penyimpanan, tetapi memerlukan data tetap tersedia tanpa batas waktu.

Praktik Terbaik

  1. Sesuaikan Retensi dengan Kebutuhan Aplikasi:

    • Untuk topik dengan konsumer yang sering offline, gunakan retensi waktu yang lebih lama (misalnya, 2 minggu: retention.ms=1209600000).

    • Untuk topik dengan volume data tinggi, atur batas ukuran (retention.bytes) untuk mencegah pertumbuhan log yang tidak terkendali.

  2. Gunakan retention.ms untuk Konsistensi:

    • Hindari menggunakan log.retention.hours atau log.retention.minutes untuk mencegah konflik. Selalu gunakan retention.ms di CLI dan konfigurasi topik.

  3. Pantau Penggunaan Disk:

    • Gunakan alat seperti Kafka Manager atau metrik JMX untuk memantau ukuran log dan memastikan disk tidak penuh.

    • Periksa direktori log.dirs secara berkala:

      du -sh /tmp/kafka-logs/*
  4. Kombinasikan dengan Kebijakan Pembersihan Log:

    • Untuk topik yang memerlukan pemadatan (compaction), atur cleanup.policy=compact bersama dengan retensi waktu atau ukuran untuk menjaga versi terbaru dari setiap kunci.

    • Contoh:

      kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --add-config cleanup.policy=compact,retention.ms=-1
  5. Gunakan Konfigurasi Dinamis:

    • Lebih suka menggunakan kafka-configs.sh untuk perubahan dinamis agar menghindari restart broker.

    • Contoh:

      kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --add-config retention.ms=604800000
  6. Uji di Lingkungan Non-Produksi:

    • Uji perubahan retensi di lingkungan pengujian untuk memahami dampaknya pada konsumer dan penggunaan disk.

  7. Pertimbangkan Segmen Aktif:

    • Ingat bahwa segmen aktif tidak dihapus, sehingga retensi aktual bisa lebih lama atau lebih besar dari yang dikonfigurasi. Sesuaikan log.segment.bytes atau log.segment.ms (lihat artikel sebelumnya) untuk mengontrol frekuensi penutupan segmen.

Penjelasan Tambahan

Hubungan dengan Segmen

Retensi log bergantung pada segmen yang sudah ditutup. Parameter seperti log.segment.bytes dan log.segment.ms memengaruhi seberapa sering segmen ditutup, yang pada gilirannya memengaruhi kapan retensi diterapkan. Misalnya:

  • Jika log.segment.bytes besar (misalnya, 1 GB) dan tingkat produksi rendah, segmen mungkin tetap terbuka lama, menunda penghapusan meskipun retention.ms pendek.

  • Solusi: Kurangi log.segment.bytes atau log.segment.ms untuk topik dengan lalu lintas rendah.

Mode KRaft

Dalam mode KRaft (Kafka tanpa Zookeeper, mulai versi 3.3), retensi log dikelola dengan cara yang sama, tetapi metadata partisi ditangani oleh controller Kafka. Ini tidak mengubah logika retensi, tetapi meningkatkan efisiensi manajemen metadata.

Pemecahan Masalah

Jika data tidak dihapus sesuai kebijakan retensi:

  • Periksa Segmen Aktif: Gunakan perintah berikut untuk memeriksa segmen:

    ls -l /tmp/kafka-logs/configured-topic-0/

    Segmen dengan waktu modifikasi terbaru adalah segmen aktif.

  • Periksa Konfigurasi Retensi: Verifikasi konfigurasi topik:

    kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic configured-topic
  • Pantau Disk: Jika disk penuh, periksa ukuran log dan sesuaikan retention.bytes atau retention.ms.

Jika konsumer kehilangan data:

  • Periksa apakah retention.ms terlalu pendek atau retention.bytes terlalu kecil.

  • Tingkatkan nilai retensi atau pantau latensi konsumer.

Kesimpulan

Retensi log adalah komponen kunci dalam pengelolaan penyimpanan Kafka, memungkinkan Anda mengontrol berapa lama atau berapa besar data disimpan dalam topik. Dengan parameter seperti retention.ms dan retention.bytes, Anda dapat menyesuaikan kebijakan retensi untuk memenuhi kebutuhan aplikasi, menyeimbangkan antara ketersediaan data dan penggunaan disk. Menggunakan alat CLI seperti kafka-configs.sh, Anda dapat mengatur retensi secara dinamis tanpa mengganggu operasi klaster. Dengan memahami hubungan antara retensi, segmen, dan konsumer, serta menerapkan praktik terbaik, Anda dapat memastikan pengelolaan data yang efisien dan andal di Kafka.

Last updated