Production Failure Scenarios: Mengatasi Kegagalan Kritis di Produksi #

Mengoperasikan Apache Kafka di skala produksi berarti kita harus siap menghadapi kenyataan bahwa kegagalan infrastruktur bukanlah masalah “jika”, melainkan “kapan”. Sebagai sistem terdistribusi stateful yang memproses data sensitif secara real-time, kluster Kafka rentan terhadap berbagai macam bencana fisik dan jaringan—mulai dari server mati mendadak, kerusakan sektor disk penyimpanan, sekat jaringan (network partition), hingga sekat parsial (flapping network) yang memicu inkonsistensi koordinasi metadata.

Ketika kegagalan kritis terjadi di tengah malam, tim operasional tidak boleh mengambil keputusan berdasarkan insting. Melakukan restart paksa pada broker leader yang sedang mengalami desinkronisasi atau memaksa pemilihan leader secara kotor (unclean leader election) dapat berakibat fatal pada hilangnya data transaksi bisnis secara permanen. Kita harus memahami dengan tepat bagaimana protokol internal Kafka merespons setiap skenario kegagalan dan langkah mitigasi yang aman untuk memulihkan layanan.

Dalam panduan ini, kita akan membedah empat skenario kegagalan produksi paling menakutkan di Apache Kafka: kematian mendadak broker (sudden crash), bencana split-brain pada quorum KRaft/ZooKeeper, kegagalan disk lokal pada JBOD, serta latensi jaringan tidak stabil (network flapping), lengkap dengan instruksi pemulihan yang aman.

Klasifikasi Kegagalan Produksi di Apache Kafka #

Sebelum kita masuk ke pembahasan teknis per skenario, mari kita petakan kegagalan di Kafka ke dalam dua kategori utama:

Kegagalan Keras (Hard Failures): Node mati total, listrik padam, disk terbakar, atau kabel jaringan terputus fisik. Kegagalan ini mudah dideteksi oleh sistem pengawas karena node langsung berhenti merespons.
Kegagalan Lunak / Parsial (Soft/Partial Failures): Disk mengalami bad sector (I/O menjadi sangat lambat tapi tidak mati), port jaringan mengalami packet loss sebesar $30%$, atau CPU mengalami overload ekstrim. Kegagalan ini jauh lebih berbahaya karena node terlihat hidup (liveness probe sukses) tetapi tidak dapat melayani trafik dengan benar, memicu efek domino bagi kestabilan kluster.

Skenario 1: Kematian Broker Mendadak (Sudden Broker Crash) #

Kematian broker secara tiba-tiba (akibat kegagalan daya, kernel panic OS, atau crash JVM OOM) memaksa kluster melakukan reorganisasi kepemimpinan partisi secara instan.

+-------------------------------------------------------------------------------+
|                       DAMPAK SUDDEN CRASH PADA LEADER PARTISI                  |
|                                                                               |
|  * KELOMPOK AWAL (Broker 1=Leader, Broker 2=Follower, Broker 3=Follower)      |
|    - Klien menulis data ke Broker 1.                                          |
|                                                                               |
|  * BROKER 1 CRASH MENDADAK:                                                   |
|    1. Controller mendeteksi hilangnya detak jantung Broker 1.                 |
|    2. Controller memilih Leader baru dari daftar ISR (misal Broker 2).        |
|    3. Klien diarahkan menulis ke Broker 2 secara transparan.                  |
|                                                                               |
|  * BAHAYA UNCLEAN LEADER ELECTION (Jika Broker 2 & 3 di luar ISR):             |
|    - Jika unclean.leader.election.enable=true  -> Broker 2 jadi leader baru   |
|      tetapi data lama yang belum ter-replikasi akan HILANG selamanya.         |
|    - Jika unclean.leader.election.enable=false -> Partisi offline (Aman).     |
+-------------------------------------------------------------------------------+

1. Bagaimana Kafka Merespons #

Ketika broker leader mati:

Controller quorum mendeteksi hilangnya detak jantung (heartbeat) dari broker tersebut.
Controller segera menghapus broker yang mati dari daftar In-Sync Replicas (ISR) untuk seluruh partisi yang dipimpinnya.
Controller memilih salah satu broker follower sehat yang tersisa di dalam daftar ISR untuk naik menjadi leader baru.
Klien produser dan konsumen menerima update metadata kluster baru dan secara otomatis mengalihkan rute koneksi mereka ke leader baru tanpa intervensi manual di tingkat aplikasi.

2. Bahaya Unclean Leader Election #

Bencana sesungguhnya terjadi jika pada saat leader mati, seluruh broker follower yang tersisa sedang tertinggal di luar daftar ISR (misalnya akibat kelambatan replikasi sebelumnya). Jika hal ini terjadi, kita dihadapkan pada dilema konfigurasi unclean.leader.election.enable:

Diset ke true: Kafka diizinkan memilih follower di luar ISR untuk menjadi leader baru. Keuntungannya, partisi tetap aktif melayani penulisan data (high availability). Kerugiannya, seluruh data yang belum sempat direplikasikan oleh leader lama ke follower tersebut akan dihapus selamanya saat leader lama hidup kembali, memicu ketidaksinkronan offset (data loss).
Diset ke false (Sangat Direkomendasikan untuk Data Finansial): Kafka melarang pemilihan leader di luar ISR. Partisi tersebut akan langsung berstatus Offline dan tidak dapat diakses untuk tulis-baca sampai leader asli yang memiliki data lengkap berhasil dihidupkan kembali. Ini menjamin durabilitas dan konsistensi data mutlak dengan mengorbankan ketersediaan sementara.

3. Mengidentifikasi Status Partisi dengan CLI `kafka-topics.sh` #

Kita dapat memverifikasi status partisi yang terkena dampak kematian broker menggunakan perintah CLI berikut:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --describe \
  --topic payment.orders

Output Contoh saat Broker 1 Mati:

Topic: payment.orders   TopicId: xF23s1   PartitionCount: 3   ReplicationFactor: 3   Configs: min.insync.replicas=2
    Topic: payment.orders   Partition: 0    Leader: 2   Replicas: 1,2,3   Isr: 2,3    OfflineReplicas: 1
    Topic: payment.orders   Partition: 1    Leader: 3   Replicas: 2,3,1   Isr: 2,3    OfflineReplicas: 1
    Topic: payment.orders   Partition: 2    Leader: 2   Replicas: 3,1,2   Isr: 2,3    OfflineReplicas: 1

Pada output di atas, broker 1 tercatat pada kolom OfflineReplicas dan otomatis terhapus dari kolom Isr, namun partisi tetap memiliki leader aktif (broker 2 dan 3) sehingga tidak terjadi downtime.

Senerio 2: Split-Brain pada Quorum Metadata (KRaft / ZooKeeper) #

Split-Brain adalah kondisi di mana terjadi sekat jaringan (network partition) yang membagi kluster Kafka menjadi dua wilayah terisolasi, dan masing-masing wilayah merasa berhak bertindak sebagai pemimpin (controller) aktif.

1. Bagaimana Protokol Kafka Mencegah Penulisan Ganda #

Untuk mencegah terjadinya penulisan data yang saling bertabrakan (split-brain writing), Kafka menggunakan mekanisme Leadership Epoch (pada broker data) dan konsep Quorum Majority (pada controller metadata).

Misalkan kita memiliki kluster metadata dengan 5 controller nodes. Berdasarkan teori sistem terdistribusi, jumlah minimum node untuk membentuk wilayah mayoritas (quorum) adalah: $$\text{Quorum Minimum} = \lfloor \frac{N}{2} \rfloor + 1 = \lfloor \frac{5}{2} \rfloor + 1 = 3 \text{ nodes}$$

Jika terjadi sekat jaringan yang membagi kluster menjadi dua wilayah: Wilayah A (2 controller) dan Wilayah B (3 controller):

Wilayah A (Minoritas): Tidak dapat membentuk quorum (hanya 2 dari 3 minimum). Wilayah ini otomatis menonaktifkan dirinya sendiri dan menolak semua request perubahan metadata dari admin.
Wilayah B (Mayoritas): Berhasil membentuk quorum (3 node). Wilayah ini tetap aktif dan dapat memilih leader controller baru jika leader lama berada di Wilayah A.

Ketika leader lama di Wilayah A mencoba mengirimkan instruksi ke broker, broker akan memeriksa nilai Controller Epoch pada instruksi tersebut. Karena Wilayah B telah menaikkan epoch saat memilih leader baru, broker akan menolak semua instruksi dari leader lama di Wilayah A karena epochnya sudah kedaluwarsa (fencing out the old leader).

Skenario 3: Kegagalan Disk Lokal (Bad Disk) pada JBOD #

Dalam deployment dengan skema JBOD, kita mendaftarkan beberapa piringan disk fisik secara independen ke properti log.dirs broker. Kegagalan disk lokal dapat berkisar dari disk mati total hingga kondisi disk I/O mengalami kemacetan (disk hang).

flowchart TD
    Start["Deteksi Aktivitas I/O Disk Data"] --> IO_Check{"Apakah operasi I/O sukses?"}
    
    IO_Check -- "Ya" --> Normal["Broker berjalan normal"]
    IO_Check -- "Tidak (Input/Output Error)" --> DiskFail["LogManager: Deteksi kegagalan direktori disk"]
    
    DiskFail --> MarkOffline["Tandai direktori tersebut sebagai OFFLINE"]
    MarkOffline --> KeepBrokerAlive["Pertahankan proses JVM Broker tetap HIDUP"]
    
    KeepBrokerAlive --> CheckPartitions{"Apakah partisi di disk rusak adalah LEADER?"}
    
    CheckPartitions -- "Ya" --> LeaderMigrate["Kirim metadata ke Controller:<br/>Pindahkan kepemimpinan partisi ke broker lain"]
    CheckPartitions -- "Tidak" --> KeepFollower["Nonaktifkan replika follower pada disk tersebut"]
    
    LeaderMigrate --> Alert["Kirim Alert SRE: 'Offline Log Directory' untuk penggantian disk"]
    KeepFollower --> Alert

1. Bagaimana Kafka Menangani Offline Log Directories #

Ketika salah satu disk fisik (misalnya /mnt/data2) mengalami kegagalan sektor tulis-baca, Kafka akan:

Mencatat error IOException pada log server.
Mengubah status direktori tersebut menjadi Offline Log Directory.
Broker tetap dipertahankan hidup. Broker tidak akan melakukan shutdown total jika masih ada disk data sehat lainnya di dalam properti log.dirs.
Untuk seluruh partisi yang memiliki leader di disk yang rusak tersebut, broker akan mengirimkan sinyal ke controller untuk memindahkan status kepemimpinan (leader election) ke broker follower sehat di server lain.
Broker hanya menolak request tulis-baca untuk partisi yang berada di disk rusak tersebut, sementara partisi di disk sehat lainnya tetap berjalan $100%$ normal.

2. Bahaya Disk Hang (I/O Blockage) #

Kasus disk hang jauh lebih berbahaya dibanding disk mati total. Pada disk hang, sistem operasi tidak langsung melemparkan error IOException. Sebaliknya, thread penulisan disk Kafka akan diblokir (blocked) selamanya menunggu konfirmasi dari kernel OS yang sedang mencoba melakukan percobaan ulang penulisan pada hardware yang rusak.

Dampak: Thread penulisan broker macet, menyebabkan antrean request bertumpuk. Broker gagal merespons detak jantung (heartbeat) dan dianggap mati oleh controller, meskipun proses JVM-nya masih terlihat aktif.
Solusi: Kita harus mengonfigurasi parameter OS disk timeout (/sys/block/sd[x]/device/timeout) ke nilai yang rendah (misalnya 10-20 detik) agar kernel OS segera melemparkan error I/O ke Kafka daripada menahannya terlalu lama di tingkat kernel.

Skenario 4: Jaringan Flapping (Network Flapping / Flapping ISR) #

Jaringan flapping adalah kegagalan jaringan di mana konektivitas antara broker sering terputus dan tersambung kembali dalam hitungan detik secara konstan (ping-pong connection).

1. Mengapa Flapping Sangat Merusak Kluster Kafka? #

Ketika koneksi jaringan antara broker follower (misalnya Broker 3) dan broker leader (Broker 1) terputus selama beberapa detik:

Broker 3 dikeluarkan dari daftar ISR oleh leader karena tertinggal.
Satu detik kemudian, koneksi tersambung kembali. Broker 3 melakukan sinkronisasi kilat dan masuk kembali ke daftar ISR.
Satu detik kemudian, koneksi terputus lagi.

Siklus keluar-masuk ISR yang berulang ini (ISR Churn) memaksakan penulisan perubahan metadata secara masif ke controller quorum setiap detik.

Proses ini membebani memori heap controller dan thread network processor.
Jika dibiarkan, kluster akan mengalami kemacetan pemrosesan metadata (metadata lag), menyebabkan koordinasi kluster terhenti sesaat dan memicu kegagalan otentikasi klien.

2. Parameter Redam Flapping (ISR Churn Dampening) #

Untuk meredam efek flapping, Kafka menyediakan parameter replica.lag.time.max.ms (default 30000 ms atau 30 detik). Parameter ini menentukan berapa lama follower boleh tertinggal di belakang leader sebelum secara resmi dinyatakan keluar dari ISR.

Tuning: Jangan menyetel parameter ini terlalu kecil (misalnya di bawah 5 detik) untuk kluster dengan jaringan multi-region yang fluktuatif, guna memberikan toleransi jeda sementara jaringan tanpa memicu proses keluar-masuk ISR yang tidak perlu.

Prosedur Pemulihan Kepemimpinan (Leader Election Recovery) #

Setelah kita memulihkan node broker yang crash atau menyelesaikan masalah jaringan, kita harus mengembalikan status kepemimpinan partisi agar tersebar merata seperti sedia kala (balanced cluster).

1. Memicu Preferred Leader Election #

Secara default, Kafka memiliki parameter auto.leader.rebalance.enable=true yang mencoba menyeimbangkan kepemimpinan secara otomatis. Namun, proses rebalance otomatis ini dapat memicu hentakan I/O. Kita disarankan memicunya secara terkontrol menggunakan CLI berikut:

kafka-leader-election.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --election-type preferred \
  --all-topic-partitions

2. Skenario Darurat: Memaksa Unclean Leader Election #

Jika terjadi insiden di mana semua follower berada di luar ISR dan kita memilih mengorbankan konsistensi demi menghidupkan kembali sistem (recovery speed), kita dapat memaksa pemilihan leader secara kotor untuk partisi tertentu:

kafka-leader-election.sh --bootstrap-server localhost:9092 \
  --command-config /etc/kafka/client.properties \
  --election-type unclean \
  --topic payment.orders \
  --partition 0

Peringatan: Perintah di atas akan menyebabkan sebagian data lama yang berada di disk leader sebelumnya terhapus permanen.

Checklist Penanganan Insiden Produksi (Incident Response Checklist) #

Ketika alarm kluster berbunyi di tengah malam, ikuti panduan tanggap darurat (incident response) berikut secara urut untuk mendiagnosis dan memulihkan kluster dengan aman:

LANGKAH DARURAT MITIGASI KEGAGALAN KAFKA:

[ LANGKAH 1: IDENTIFIKASI ]
  □ Periksa metrik UnderReplicatedPartitions dan OfflinePartitionsCount di Grafana.
  □ Jika OfflinePartitionsCount > 0, berarti ada partisi yang tidak bisa diakses sama sekali!

[ LANGKAH 2: LOKALISASI BROKER ]
  □ Jalankan kueri pencarian log server untuk menemukan kata kunci:
    - "Shrinking ISR" -> Untuk melacak broker yang terputus jaringan/GC pause.
    - "IOException" atau "offline log directory" -> Untuk melacak kerusakan disk fisik.
    - "Epoch" atau "Denied Operation" -> Untuk melacak masalah quorum/keamanan.

[ LANGKAH 3: VERIFIKASI QUORUM KRAFT / ZK ]
  □ Pastikan mayoritas node controller aktif. Jika kluster kehilangan quorum (misal 3 dari 5 controller mati), 
    JANGAN restart broker data sebelum memulihkan quorum controller terlebih dahulu!

[ LANGKAH 4: PEMULIHAN DISK KAFKA ]
  □ Jika direktori log berstatus offline:
    1. Lakukan evakuasi partisi data ke broker lain menggunakan kafka-reassign-partitions.sh.
    2. Ganti disk fisik yang rusak.
    3. Format disk baru dengan filesystem XFS dan mount dengan flag yang sesuai.
    4. Hidupkan kembali broker untuk memicu replikasi ulang secara dinamis.

Ringkasan #

Pahami Kebijakan Unclean Election — Setel unclean.leader.election.enable=false di produksi untuk mencegah hilangnya data permanen saat terjadi kegagalan kepemimpinan partisi.

Pelihara Quorum Controller — Selalu pertahankan jumlah ganjil untuk node controller ($2N+1$) guna mengantisipasi kegagalan jaringan split-brain tanpa memicu penulisan ganda.

Tuning Timeout Kernel OS — Setel batas waktu I/O disk sistem operasi ke nilai rendah guna mempercepat deteksi disk hang dan memicu transisi direktori log offline di Kafka.

Redam Flapping Jaringan — Atur nilai replica.lag.time.max.ms secara logis untuk memberikan toleransi putusnya konektivitas sesaat tanpa memicu proses keluar-masuk ISR yang membebani metadata.

← Sebelumnya: Kafka on Docker & Kubernetes Berikutnya: Broker Recovery Process →