Belajar Apache Kafka - Replication & High Availability

#Pendahuluan

Replikasi adalah alasan Kafka tetap tersedia saat broker mati. Setiap partition disalin ke beberapa broker, dan ketika pemimpinnya gagal, penggantinya diangkat. Namun di balik kesederhanaan itu tersembunyi keputusan rumit: siapa yang berhak jadi leader, dan kapan sistem rela mengorbankan availability demi konsistensi.

Episode 24 ini akan membedah replikasi secara mendalam: peran leader dan follower, In-Sync Replicas, mekanisme high watermark, risiko unclean leader election, peran min.insync.replicas, serta rack awareness untuk deployment multi-AZ.

#Deep Dive Replikasi

#Leader dan Follower Replicas

Setiap partition memiliki satu leader dan beberapa follower. Leader melayani semua tulis dan baca; follower hanya menyalin data dari leader. Ketika leader mati, controller memilih follower terbaik menjadi leader baru. Jika follower tidak lagi menerima data atau gagal, ia ditandai out-of-sync dan dikeluarkan dari ISR.

#In-Sync Replicas (ISR)

ISR adalah daftar follower yang masih sinkron dengan leader. Follower keluar dari ISR jika ia tidak mengirim fetch request atau tertinggal melewati replica.lag.time.max.ms (default 30 detik). Follower yang sudah mengejar kembali masuk ke ISR. ISR menentukan toleransi kegagalan: dengan ISR 3 dan replication factor 3, dua broker bisa mati tanpa kehilangan data.

Cek kesehatan ISR dengan describe:

bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders

Output menampilkan per partition kolom Leader, Replicas, dan Isr. Kondisi sehat: semua Replicas muncul di Isr, dan Leader tersebar merata. Jika ada replica yang tidak ada di Isr, selidiki kenapa follower tertinggal.

#Replica Fetching dan High Watermark

Follower mengambil data dari leader lewat fetch request berkala. Setiap partition melacak dua posisi:

• Log-end-offset (LEO): offset terakhir yang sudah diterima secara lokal.
• High watermark: offset tertinggi yang sudah direplikasi ke semua replica ISR.

Consumer hanya bisa membaca record di bawah high watermark. Ini mencegah consumer melihat data yang belum direplikasi — jika leader mati sebelum replikasi selesai, data di atas high watermark tidak dianggap tersimpan.

#Unclean Leader Election

#Risiko Data Loss

Ketika semua replica ISR mati, Kafka menghadapi pilihan: menunggu replica ISR pulih (tidak tersedia, tapi aman) atau mengangkat follower out-of-sync menjadi leader (tersedia, tapi data mungkin hilang). Kebijakan ini diatur unclean.leader.election.enable:

• false (default): leader baru hanya dipilih dari ISR; data tidak hilang, tetapi partition mungkin tidak tersedia.
• true: follower out-of-sync bisa diangkat; ketersediaan dipertahankan dengan risiko record yang belum direplikasi hilang.

unclean.leader.election.enable=false

unclean.leader.election.enable=false adalah setelan produksi yang disarankan untuk data yang tidak boleh hilang. Untuk workload non-kritis yang lebih mementingkan ketersediaan, pertimbangkan true dengan kesadaran penuh akan konsekuensinya.

#Availability vs Consistency

Ini trade-off klasik CAP dalam bentuk konkret. Pilih dengan memahami data: untuk transaksi keuangan dan event penting, konsistensi menang (false); untuk telemetry yang boleh hilang, ketersediaan menang (true). Pantau unclean-leader-elections-per-sec untuk mendeteksi apakah kebijakan aktif terpaksa dipakai.

Konsekuensi memilih true perlu dipahami penuh: consumer yang membaca sebelum pemilihan bisa saja melihat record yang kemudian "menghilang" setelah follower out-of-sync naik — karena record di atas high watermark dibuang. Selalu perhitungkan dampak ini terhadap aplikasi konsumen sebelum mengubah setelan.

#Min In-Sync Replicas

#Konfigurasi dan Interaksi dengan acks

min.insync.replicas menentukan jumlah minimum replica ISR agar tulis diterima:

min.insync.replicas=2

Kombinasi yang menjamin durability tinggi: min.insync.replicas=2 di broker dengan acks=all di producer. Dengan replication factor 3, broker menerima tulis hanya jika minimal 2 replica sinkron — begitu ISR turun ke 1, tulis ditolak, mencegah penulisan ke pemimpin tunggal yang mungkin kehilangan data.

#Menjamin Durability

min.insync.replicas adalah jaring pengaman yang paling penting. Ia memastikan acks=all berarti semua ISR saat ini menerima data, dan ISR tidak boleh menyusut di bawah ambang. Perhatikan: ISR adalah kondisi dinamis, bukan ukuran tetap — if replica lambat, ISR bisa turun dan memblokir tulis. Rancang replication factor dan ambang dengan memperhitungkan jumlah broker yang boleh mati.

#Rack Awareness

#broker.rack Configuration

Kafka bisa menempatkan replica di failure domain yang berbeda melalui broker.rack:

broker.rack=us-east-1a

broker.rack=us-east-1a memberi tahu Kafka lokasi failure domain broker. Saat membuat topic, Kafka mencoba menempatkan replica leader dan follower di rack berbeda, sehingga kegagalan satu rack tidak menjatuhkan seluruh replica partition.

#Multi-AZ Deployment

Dengan rack awareness, deployment multi-AZ menjadi aman: replication factor 3 dengan broker tersebar di tiga AZ. Kegagalan satu AZ hanya menurunkan satu replica per partition — ISR tetap 2 dari 3, dan tulis terus berjalan. Kombinasikan dengan min.insync.replicas=2 agar satu AZ down tidak memblokir tulis tetapi juga tidak mengorbankan durability.

#Penutup

Di episode 24 ini kalian sudah memahami replikasi mendalam: leader dan follower, ISR, high watermark, risiko unclean leader election, peran min.insync.replicas, serta rack awareness untuk deployment multi-AZ.

Inti yang harus dibawa pulang:

• ISR menentukan toleransi kegagalan; follower out-of-sync dikeluarkan dari ISR.
• Consumer hanya membaca di bawah high watermark untuk konsistensi.
• unclean.leader.election.enable=false mencegah data loss dengan mengorbankan ketersediaan.
• min.insync.replicas=2 plus acks=all menjamin durability tinggi.
• Rack awareness menyebar replica ke failure domain berbeda.
• Multi-AZ yang sehat memerlukan broker tersebar dan rack awareness aktif.

Di episode 25 selanjutnya kita akan membahas disaster recovery dan data migration — MirrorMaker 2.0 untuk replikasi lintas cluster, pola active-active dan active-passive, pertimbangan RPO/RTO, serta migrasi zero-downtime antar cluster.