Kafka Producer Advanced: Kafka Producer Acks Deep Dive

Kafka Producer Acks Deep Dive

Dalam Apache Kafka, parameter konfigurasi produser acks menentukan tingkat pengakuan (acknowledgment) yang diperlukan dari broker sebelum pesan dianggap berhasil ditulis. Parameter ini bekerja bersama dengan konfigurasi min.insync.replicas untuk menyeimbangkan antara ketahanan data (durability), ketersediaan (availability), dan performa. Artikel ini akan menjelaskan secara mendalam opsi acks, implikasinya terhadap operasi Kafka, hubungannya dengan replikasi dan In-Sync Replicas (ISR), serta langkah-langkah praktis untuk mengonfigurasi min.insync.replicas menggunakan alat CLI. Kami juga menyertakan contoh lengkap dan praktik terbaik untuk membantu Anda mengelola konfigurasi produser dengan tepat.

Pengenalan Parameter acks

Parameter acks pada produser Kafka menentukan jumlah broker yang harus mengakui penerimaan pesan sebelum dianggap berhasil ditulis. Produser hanya mengirim data ke broker pemimpin (leader) untuk partisi tertentu, tetapi tingkat pengakuan tergantung pada pengaturan acks. Parameter ini berinteraksi dengan min.insync.replicas, yang menentukan jumlah minimum replika dalam In-Sync Replicas (ISR) yang harus memiliki data sebelum pesan dianggap committed.

Nilai acks yang Tersedia

• Default:

  • Kafka < v3.0: acks=1

  • Kafka ≥ v3.0: acks=all

• Opsi:

  • acks=0: Tidak menunggu pengakuan dari broker.

  • acks=1: Menunggu pengakuan hanya dari pemimpin partisi.

  • acks=all: Menunggu pengakuan dari semua replika dalam ISR.

Hubungan dengan min.insync.replicas

• Parameter min.insync.replicas menentukan jumlah minimum replika ISR (termasuk pemimpin) yang harus mengakui pesan agar dianggap berhasil ditulis saat acks=all.

• Dapat dikonfigurasi pada level topik atau broker.

• Default: 1 pada level broker.

• Contoh: Dengan replication.factor=3 dan min.insync.replicas=2, setidaknya dua replika (termasuk pemimpin) harus mengakui pesan untuk dianggap committed.

Detail Opsi acks

acks=0

• Deskripsi: Produser menganggap pesan berhasil ditulis segera setelah dikirim, tanpa menunggu pengakuan dari broker.

• Keuntungan:

  • Throughput tertinggi karena tidak ada overhead jaringan untuk pengakuan.

  • Cocok untuk data yang dapat ditoleransi kehilangannya, seperti metrik atau log non-kritis.

• Kekurangan:

  • Tidak ada jaminan bahwa pesan diterima oleh broker.

  • Jika broker offline atau terjadi kesalahan, pesan akan hilang tanpa sepengetahuan produser.

• Kasus Penggunaan: Pengumpulan metrik, log sementara, atau data dengan toleransi kehilangan tinggi.

acks=1

• Deskripsi: Produser menganggap pesan berhasil ditulis setelah pemimpin partisi mengakui penerimaan pesan.

• Keuntungan:

  • Performa lebih baik dibandingkan acks=all karena hanya menunggu pengakuan dari pemimpin.

  • Produser dapat mencoba ulang (retry) jika tidak menerima pengakuan.

• Kekurangan:

  • Tidak menjamin replikasi ke replika lain, karena replikasi dilakukan di latar belakang.

  • Jika pemimpin gagal sebelum replikasi selesai, data dapat hilang.

• Kasus Penggunaan: Aplikasi yang membutuhkan keseimbangan antara performa dan ketahanan, tetapi dapat mentolerir kehilangan data sesekali.

acks=all

• Deskripsi: Produser menganggap pesan berhasil ditulis hanya setelah semua replika dalam ISR mengakui penerimaan pesan.

• Keuntungan:

  • Ketahanan data tertinggi, karena pesan dijamin ditulis ke semua replika ISR yang ditentukan oleh min.insync.replicas.

  • Cocok untuk aplikasi yang memerlukan jaminan ketahanan tinggi, seperti transaksi keuangan.

• Kekurangan:

  • Latensi lebih tinggi karena produser harus menunggu semua replika ISR mengakui.

  • Jika jumlah replika ISR di bawah min.insync.replicas, produser akan menerima NotEnoughReplicasException dan tidak dapat menulis data.

• Kasus Penggunaan: Data kritis seperti transaksi keuangan, pesanan pelanggan, atau data yang memerlukan konsistensi tinggi.

Implikasi min.insync.replicas

• Contoh:

  • Dengan replication.factor=3 dan min.insync.replicas=2, produser dengan acks=all memerlukan setidaknya dua replika (termasuk pemimpin) untuk mengakui pesan.

  • Jika hanya satu replika tersedia (misalnya, dua broker gagal), produser akan menerima NotEnoughReplicasException.

• Efek pada Ketersediaan:

  • Dengan acks=all dan min.insync.replicas=M untuk replication.factor=N, sistem dapat mentolerir hingga N-M kegagalan broker tanpa kehilangan ketersediaan penulisan.

  • Contoh: Untuk replication.factor=3 dan min.insync.replicas=2, sistem dapat mentolerir satu kegagalan broker.

Ketahanan dan Ketersediaan Topik

Ketahanan (Durability)

• Untuk replication.factor=N, Kafka dapat mentolerir hingga N-1 kegagalan broker permanen tanpa kehilangan data, karena data tersedia di replika lain.

• Contoh: Dengan replication.factor=3, sistem dapat kehilangan hingga dua broker dan masih dapat memulihkan data.

Ketersediaan (Availability)

• Pembacaan: Selama setidaknya satu replika dalam ISR tersedia, topik dapat dibaca.

• Penulisan:

  • acks=0 atau acks=1: Selama pemimpin partisi tersedia, topik dapat ditulis, meskipun replika lain offline.

  • acks=all:

    • Dengan min.insync.replicas=1: Topik tetap tersedia selama pemimpin tersedia (mentolerir N-1 kegagalan broker).

    • Dengan min.insync.replicas=2 (untuk replication.factor=3): Topik tersedia selama setidaknya dua replika ISR aktif, mentolerir satu kegagalan broker.

    • Dengan min.insync.replicas=3 (untuk replication.factor=3): Tidak dapat mentolerir kegagalan broker, karena semua replika harus aktif, sehingga tidak praktis.

Konfigurasi Populer

• acks=all dan min.insync.replicas=2 adalah kombinasi paling umum untuk menyeimbangkan ketahanan dan ketersediaan.

• Dengan replication.factor=3, konfigurasi ini memungkinkan sistem mentolerir satu kegagalan broker sambil memastikan data ditulis ke setidaknya dua replika.

Praktik Konfigurasi min.insync.replicas

Berikut adalah langkah-langkah praktis untuk mengonfigurasi min.insync.replicas pada topik dan broker, dengan contoh lengkap menggunakan alat CLI Kafka.

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.

• Klaster memiliki setidaknya tiga broker untuk mendukung replication.factor=3.

Langkah-langkah Konfigurasi

1. Buat Topik

Buat topik bernama configured-topic dengan 3 partisi dan faktor replikasi 3:

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

2. Verifikasi Konfigurasi Topik Awal

Periksa konfigurasi topik untuk memastikan tidak ada pengaturan override:

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

Contoh Keluaran:

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

Tidak ada override konfigurasi (min.insync.replicas menggunakan default broker, yaitu 1).

3. Atur min.insync.replicas pada Level Topik

Atur min.insync.replicas=2 untuk topik configured-topic:

kafka-configs.sh --bootstrap-server localhost:9092 \
--alter --entity-type topics \
--entity-name configured-topic \
--add-config min.insync.replicas=2

4. Verifikasi Perubahan Konfigurasi

Periksa kembali konfigurasi topik:

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

Contoh Keluaran:

Topic: configured-topic TopicId: CDU7SBxBQ1mzJGnuH68-cQ PartitionCount: 3 ReplicationFactor: 3 Configs: min.insync.replicas=2
Topic: configured-topic Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: configured-topic Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
Topic: configured-topic Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2

Sekarang, min.insync.replicas=2 terlihat sebagai override konfigurasi topik.

5. (Opsional) Hapus Konfigurasi Override

Jika Anda ingin menghapus override dan kembali ke default broker:

kafka-configs.sh --bootstrap-server localhost:9092 \
--alter --entity-type topics \
--entity-name configured-topic \
--delete-config min.insync.replicas

Verifikasi kembali untuk memastikan konfigurasi dihapus:

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

6. Atur min.insync.replicas pada Level Broker

a. Melalui File Konfigurasi

Buka file config/server.properties dan tambahkan:

min.insync.replicas=2

Restart broker untuk menerapkan perubahan:

kafka-server-stop.sh
kafka-server-start.sh config/server.properties

b. Melalui CLI (Konfigurasi Dinamis)

Atur min.insync.replicas=2 secara dinamis tanpa restart:

kafka-configs.sh --bootstrap-server localhost:9092 \
--alter --entity-type brokers \
--entity-default \
--add-config min.insync.replicas=2

Verifikasi konfigurasi broker:

kafka-configs.sh --bootstrap-server localhost:9092 \
--describe --entity-type brokers \
--entity-default

Contoh Keluaran:

Default configs for brokers in the cluster are: min.insync.replicas=2 sensitive=false synonyms={DYNAMIC_DEFAULT_BROKER_CONFIG:min.insync.replicas=2}

Hapus konfigurasi dinamis (opsional):

kafka-configs.sh --bootstrap-server localhost:9092 \
--alter --entity-type brokers \
--entity-default \
--delete-config min.insync.replicas

7. Uji Produser dengan acks

Jalankan produser konsol dengan pengaturan acks:

kafka-console-producer.sh --bootstrap-server localhost:9092 \
--topic configured-topic \
--producer-property acks=all

Kirim beberapa pesan:

Test message 1
Test message 2

Jalankan konsumer untuk memverifikasi:

kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic configured-topic \
--from-beginning

Jika hanya satu replika tersedia (misalnya, dua broker offline), produser dengan acks=all dan min.insync.replicas=2 akan gagal dengan NotEnoughReplicasException.

Catatan

• Konfigurasi topik menimpa konfigurasi broker. Jika min.insync.replicas diatur di level topik, nilai ini akan digunakan daripada default broker.

• Restart broker diperlukan untuk perubahan server.properties, tetapi konfigurasi dinamis melalui kafka-configs.sh lebih fleksibel untuk lingkungan produksi.

Praktik Terbaik

1. Gunakan acks=all untuk Data Kritis:

   • Untuk aplikasi yang memerlukan ketahanan tinggi (misalnya, transaksi keuangan), gunakan acks=all dengan min.insync.replicas=2 untuk memastikan data ditulis ke setidaknya dua replika.

2. Pilih min.insync.replicas yang Sesuai:

   • Untuk replication.factor=N, atur min.insync.replicas=N-1 untuk menyeimbangkan ketahanan dan ketersediaan (misalnya, replication.factor=3, min.insync.replicas=2).

3. Gunakan Konfigurasi Dinamis:

   • Gunakan kafka-configs.sh untuk mengubah min.insync.replicas secara dinamis tanpa restart broker:

     kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name configured-topic --add-config min.insync.replicas=2

4. Pantau Kesehatan Klaster:

   • Gunakan metrik JMX seperti UnderReplicatedPartitions dan NotEnoughReplicasException untuk mendeteksi masalah replikasi.

   • Periksa status ISR:

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

5. Uji di Lingkungan Non-Produksi:

   • Simulasikan kegagalan broker untuk menguji perilaku acks=all dan min.insync.replicas sebelum menerapkannya di produksi.

6. Kombinasikan dengan Faktor Replikasi:

   • Gunakan replication.factor=3 dengan min.insync.replicas=2 untuk konfigurasi standar industri yang andal.

7. Hindari acks=0 di Produksi:

   • Gunakan acks=0 hanya untuk data non-kritis dengan toleransi kehilangan tinggi, seperti metrik.

8. Dokumentasikan Konfigurasi:

   • Catat pengaturan acks dan min.insync.replicas untuk setiap topik, bersama dengan alasan pemilihannya, untuk memudahkan pemeliharaan.

Penjelasan Tambahan

Hubungan dengan ISR

• In-Sync Replicas (ISR) adalah replika yang sinkron dengan pemimpin partisi. Parameter min.insync.replicas memastikan bahwa pesan hanya dianggap committed jika ditulis ke jumlah minimum replika ISR.

• Dengan acks=all, pemimpin menahan pesan dalam buffer hingga semua replika ISR yang diperlukan mengakui, yang meningkatkan latensi tetapi menjamin ketahanan.

Mode KRaft

Dalam mode KRaft (Kafka tanpa Zookeeper, mulai versi 3.3), manajemen ISR dan pemilihan pemimpin lebih efisien karena controller Kafka menangani metadata. Namun, logika acks dan min.insync.replicas tetap sama. Uji konfigurasi ini dalam mode KRaft untuk memastikan kompatibilitas.

Pemecahan Masalah

Jika produser gagal dengan NotEnoughReplicasException:

• Periksa status ISR:

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

  Pastikan jumlah replika dalam ISR memenuhi min.insync.replicas.

• Periksa kesehatan broker:

  kafka-broker-api-versions.sh --bootstrap-server localhost:9092

• Tingkatkan min.insync.replicas atau pulihkan broker yang gagal.

Jika performa menurun:

• Tinjau latensi akibat acks=all menggunakan metrik seperti RequestLatencyAvg.

• Pertimbangkan mengurangi min.insync.replicas (misalnya, ke 1) untuk data yang kurang kritis.

Kesimpulan

Parameter acks pada produser Kafka adalah komponen kritis untuk menyeimbangkan ketahanan, ketersediaan, dan performa. Dengan acks=0, Anda mendapatkan throughput maksimum tetapi tanpa jaminan pengiriman. Dengan acks=1, Anda mendapatkan performa lebih baik tetapi risiko kehilangan data. Dengan acks=all dan min.insync.replicas yang sesuai, Anda memastikan ketahanan tinggi dengan biaya latensi. Konfigurasi populer acks=all dan min.insync.replicas=2 dengan replication.factor=3 adalah standar untuk aplikasi kritis. Dengan menggunakan alat CLI seperti kafka-configs.sh, Anda dapat mengatur min.insync.replicas secara dinamis, sementara praktik terbaik seperti pemantauan dan pengujian membantu memastikan operasi yang andal.