Cluster #

Di dalam arsitektur komputasi modern, sebuah sistem tidak boleh bergantung pada kinerja satu server tunggal karena server fisik rentan mengalami kerusakan hardware, pemadaman listrik, atau gangguan jaringan. Apache Kafka memecahkan tantangan ini dengan menyatukan beberapa broker server ke dalam satu kesatuan sistem terdistribusi yang disebut Cluster (kluster). Kluster Kafka dirancang sejak awal untuk menyediakan ketersediaan tinggi (high availability), skalabilitas tanpa batas, dan toleransi kegagalan (fault tolerance) yang tangguh. Memahami bagaimana komponen kluster berkoordinasi, bagaimana metadata dikelola menggunakan KRaft, serta cara merancang arsitektur kluster lintas rak fisik adalah hal fundamental untuk memastikan kelangsungan pipa data bisnis kita tanpa hambatan.

Konsep Dasar: Sistem Terdistribusi Kluster Kafka #

Secara sederhana, sebuah kluster Kafka adalah sekelompok broker (server) yang bekerja sama untuk mengelola topik dan partisi secara kolektif. Bagi aplikasi produsen dan konsumen, kluster Kafka terlihat seperti satu entitas server tunggal yang sangat besar. Aplikasi klien tidak perlu memedulikan detail di mana sebuah pesan disimpan secara fisik; mereka cukup berinteraksi dengan kluster, dan kluster akan mengatur pembagian beban kerja secara internal.

Ada tiga pilar utama yang mendasari desain kluster Kafka:

Skalabilitas Horizontal: Kita dapat meningkatkan kapasitas penyimpanan dan kemampuan pemrosesan data kluster secara instan dengan menambahkan broker baru ke dalam kluster tanpa perlu mematikan sistem yang sedang berjalan (zero-downtime scaling).
Redundansi Data (Replikasi): Setiap data yang masuk akan disalin ke beberapa broker berbeda di dalam kluster. Jika salah satu server mengalami kerusakan disk total, data kita tetap aman dan dapat diakses dari server cadangan.
No Single Point of Failure (NSPoF): Kluster dirancang sedemikian rupa sehingga tidak memiliki satu titik kegagalan tunggal. Jika salah satu broker mati (bahkan jika broker tersebut bertindak sebagai pemimpin kluster), perannya akan segera diambil alih oleh broker lain secara otomatis dalam hitungan milidetik.

Topologi Cluster: Broker, ZooKeeper, dan KRaft #

Untuk memastikan semua broker di dalam kluster bekerja secara harmonis, kluster membutuhkan sistem pengelolaan status dan metadata (seperti daftar topik aktif, jumlah partisi, status broker, dan lokasi kepemimpinan partisi).

Dalam sejarah perkembangannya, Apache Kafka mengadopsi dua metode koordinasi kluster yang berbeda:

1. Era Klasik: Apache ZooKeeper #

Pada versi Kafka 2.x ke bawah, kluster Kafka sangat bergantung pada Apache ZooKeeper untuk mengelola metadata kluster. ZooKeeper berjalan sebagai kluster terpisah di luar broker Kafka.

Masalah: Arsitektur ini sangat rumit karena kita harus mengelola dan memantau dua sistem terdistribusi yang berbeda secara bersamaan. Selain itu, terdapat hambatan kinerja (bottleneck) ketika jumlah partisi di dalam kluster mencapai puluhan ribu; koordinasi pembaruan metadata dari ZooKeeper ke broker Kafka menjadi sangat lambat dan rentan memicu ketidaksinkronan data saat terjadi kegagalan kluster berskala besar.

2. Era Modern: KRaft (Kafka Raft Metadata Mode) #

Mulai versi 3.x dan menjadi standar resmi di versi 4.x, Kafka membuang ZooKeeper sepenuhnya dan menggantinya dengan KRaft. KRaft mengadopsi protokol konsensus Raft yang diintegrasikan langsung di dalam broker Kafka. Metadata kini disimpan dan dikelola sebagai topik internal rahasia bernama @metadata yang direplikasi di antara broker-broker terpilih yang bertindak sebagai Controller Quorum.

Mari kita pelajari topologi koordinasi terdistribusi kluster Kafka modern yang menggunakan mode KRaft:

flowchart TD
    subgraph ControllerQuorum ["Controller Quorum (Metadata Leader & Followers)"]
        direction LR
        Ctrl1["Controller 1 <br/> (Follower)"]
        Ctrl2["Controller 2 <br/> (Leader / Active Metadata Store)"]
        Ctrl3["Controller 3 <br/> (Follower)"]
    end

    subgraph BrokerData ["Data Brokers (Broker Pekerja)"]
        direction LR
        B1["Broker 4"]
        B2["Broker 5"]
        B3["Broker 6"]
    end

    Ctrl1 -. Replikasi Raft .-> Ctrl2
    Ctrl3 -. Replikasi Raft .-> Ctrl2

    B1 -->|Minta Metadata & Update Status| Ctrl2
    B2 -->|Minta Metadata & Update Status| Ctrl2
    B3 -->|Minta Metadata & Update Status| Ctrl2

Dengan KRaft, proses penyebaran perubahan metadata ke seluruh broker pekerja menjadi sangat instan. Kluster Kafka modern mampu mendukung hingga jutaan partisi aktif tanpa mengalami degradasi performa, serta waktu pemulihan kluster (failover time) saat terjadi kegagalan server terpangkas dari hitungan menit menjadi hanya beberapa milidetik.

Cara Kerja Konsensus KRaft Quorum #

Protokol KRaft membagi tanggung jawab penanganan metadata di dalam Controller Quorum secara terstruktur:

Controller Leader (Active Controller): Satu Controller terpilih yang bertindak sebagai pemimpin aktif. Ia bertugas menerima seluruh perubahan metadata dari broker pekerja (misalnya saat ada topik baru dibuat) dan menuliskan perubahan tersebut ke dalam log metadata internal.
Controller Followers (Standby Controllers): Controller lainnya bertindak sebagai pengikut. Mereka menduplikasi perubahan log metadata dari Leader secara aktif untuk memastikan data mereka sinkron.
Epoch Numbers (Mencegah Split-Brain): Setiap siklus kepemimpinan Controller Leader ditandai dengan nomor unik yang disebut Epoch Number. Jika terjadi gangguan jaringan (network partition) yang membuat Leader lama terisolasi, anggota kuorum lainnya akan mendeteksi dan memilih Leader baru dengan Epoch Number yang lebih tinggi. Ketika broker yang terisolasi tersebut kembali terhubung, ia akan menyadari bahwa Epoch Number-nya sudah kedaluwarsa dan langsung menyerahkan kepemimpinannya secara aman, menghindari kondisi dual-leader (split-brain).

Mekanisme Koneksi Klien: Bootstrap Servers #

Saat kita mengonfigurasi produsen atau konsumen Kafka, kita menyuplai parameter konfigurasi bootstrap.servers berupa daftar beberapa broker (misalnya bootstrap.servers=broker1:9092,broker2:9092). Banyak pengembang mengira klien akan mengirimkan seluruh data melewati seluruh server bootstrap tersebut.

Sebenarnya, koneksi bootstrap hanya digunakan untuk koneksi awal. Klien akan memilih salah satu broker sehat secara acak dari daftar tersebut untuk meminta Metadata Kluster. Broker tersebut akan merespon dengan daftar seluruh broker aktif di kluster beserta partisi-partisi yang dipimpinnya. Setelah metadata diterima, klien akan langsung membuka koneksi soket TCP baru ke broker fisik yang bertindak sebagai Leader partisi tujuan, melewati perantara server bootstrap awal. Ini menjamin pengiriman data langsung (direct path) dengan latensi minimal.

Pengelolaan Konfigurasi Dinamis (Dynamic Configurations) #

Dalam operasional kluster produksi, kita sering kali perlu mengubah parameter konfigurasi tanpa mematikan dan memulai ulang (restart) broker. Hal ini sangat penting untuk menjaga ketersediaan sistem tetap 100% saat tim administrator (SRE) melakukan optimasi atau pemecahan masalah darurat. Kafka membagi konfigurasinya menjadi dua:

Static Configurations: Konfigurasi dasar yang wajib ditulis di file server.properties dan membutuhkan restart broker untuk diterapkan (seperti alamat port listeners atau direktori penyimpanan log.dirs).
Dynamic Configurations: Konfigurasi tingkat topik atau broker yang dapat diubah saat sistem sedang aktif secara real-time menggunakan API incrementalAlterConfigs.

Di era KRaft, ketika kita menjalankan perintah perubahan konfigurasi dinamis (misalnya mengubah kebijakan retensi atau menaikkan batasan ukuran pesan max.message.bytes pada topik tertentu), perintah tersebut akan diterima oleh Controller Leader, ditulis sebagai entri log metadata baru di log @metadata, dan secara otomatis disinkronkan ke seluruh broker pekerja dalam hitungan milidetik. Broker pekerja kemudian akan langsung menerapkan perubahan konfigurasi tersebut ke dalam memori secara dinamis tanpa interupsi pada koneksi produsen atau konsumen yang sedang berjalan.

Mekanisme Toleransi Kegagalan (Fault Tolerance & Failover) #

Salah satu kehebatan utama dari kluster Kafka adalah kemampuannya mendeteksi kegagalan secara otomatis dan melakukan pemulihan (failover) secara mandiri tanpa memerlukan campur tangan manusia (self-healing cluster).

Mari kita pelajari alur kerja penanganan kegagalan ketika salah satu broker di dalam kluster mati mendadak:

sequenceDiagram
    participant B4 as Broker 4 (Leader Partisi 0)
    participant Ctrl as KRaft Controller (Leader)
    participant B5 as Broker 5 (Follower Partisi 0 / ISR)
    participant Client as Producer / Consumer

    Note over B4: Server Broker 4 mengalami mati mendadak (Crash/mati daya)
    Note over Ctrl: Controller mendeteksi detak jantung (Heartbeat) Broker 4 hilang
    Ctrl->>Ctrl: 1. Deklarasikan Broker 4 Offline
    Ctrl->>Ctrl: 2. Cari replika sehat di ISR Partisi 0 (Ketemu Broker 5)
    Ctrl->>Ctrl: 3. Pilih Broker 5 sebagai LEADER BARU Partisi 0
    Ctrl->>B5: 4. Perbarui status Broker 5 menjadi Leader
    Ctrl->>Client: 5. Publikasikan Metadata Baru ke seluruh Klien
    Client->>B5: 6. Alihkan koneksi tulis/baca langsung ke Broker 5
    Note over Client: Pengiriman data berlanjut dengan mulus!

Penjelasan Langkah Failover: #

Deteksi Hilangnya Detak Jantung: Setiap broker pekerja wajib mengirimkan sinyal detak jantung (heartbeat) secara periodik ke broker Controller. Jika Controller tidak menerima detak jantung dari Broker 4 melebihi batas waktu zookeeper.connection.timeout.ms (pada era lama) atau parameter detak jantung KRaft, Controller akan mendeklarasikan bahwa Broker 4 telah keluar dari kluster (offline).
Pemilihan Leader Darurat: Controller memeriksa daftar partisi yang dipimpin oleh Broker 4. Untuk setiap partisi tersebut, Controller mencari replika pengikut (Follower) yang status datanya sinkron dan terdaftar di dalam In-Sync Replicas (ISR) pada broker lain (dalam contoh di atas, Broker 5).
Promosi Pemimpin Baru: Controller mempromosikan Broker 5 menjadi Leader baru untuk partisi tersebut dan menuliskan perubahan ini ke log metadata.
Pembaruan Metadata Klien: Controller menyebarkan informasi metadata terbaru ini ke seluruh broker aktif dan aplikasi klien. Produsen dan konsumen yang terhubung akan secara otomatis memperbarui rute koneksi soket TCP mereka ke Broker 5 secara transparan tanpa perlu memutus jalannya aplikasi bisnis kita.

Merancang Kluster yang Sangat Andal (High Availability Cluster Design) #

Menjalankan beberapa broker Kafka di dalam satu rak server fisik yang sama atau di dalam satu pusat data (Data Center) yang sama masih memiliki risiko kegagalan yang tinggi. Jika saklar jaringan rak tersebut rusak atau terjadi pemadaman listrik total di pusat data tersebut, seluruh kluster Kafka kita akan mati seketika.

Untuk merancang kluster tingkat produksi yang benar-benar andal, kita harus menerapkan strategi Rack Awareness dan penyebaran lintas Availability Zone (AZ).

1. Rack Awareness (Kesadaran Lokasi Rak) #

Kita wajib mengonfigurasi parameter broker.rack pada setiap file konfigurasi broker untuk memberi tahu Kafka di rak fisik atau Availability Zone mana broker tersebut berada:

broker.rack=us-east-1a (untuk Broker 1)
broker.rack=us-east-1b (untuk Broker 2)
broker.rack=us-east-1c (untuk Broker 3)

Dengan mengaktifkan konfigurasi ini, saat kita membuat topik baru dengan Replication Factor = 3, Kafka akan menjamin secara geografis bahwa replika partisi akan didistribusikan ke tiga rak atau zona yang berbeda. Data tidak akan pernah ditempatkan menumpuk di rak yang sama.

2. Parameter Keandalan Data Lintas Zona #

Penyebaran lintas zona harus disandingkan dengan parameter penulisan data yang aman pada aplikasi produsen dan topik kita:

replication.factor (Minimal 3): Menjamin data disalin di 3 broker berbeda yang berada di zona berbeda.
min.insync.replicas (Minimal 2): Menjamin bahwa setiap penulisan data harus sukses dicatat di minimal 2 broker yang sinkron sebelum dianggap sukses.
acks = all di sisi Produsen: Memaksa produsen untuk menunggu konfirmasi dari minimal jumlah broker yang ditentukan oleh min.insync.replicas.

Dengan kombinasi tiga parameter di atas, jika salah satu Availability Zone mengalami bencana alam atau mati total, kluster Kafka kita di zona lain akan tetap hidup, kepemimpinan partisi langsung dialihkan secara otomatis, dan tidak ada satu byte data pun yang hilang.

Kesalahan Umum (Anti-pattern) dalam Pengelolaan Kluster #

Berikut adalah beberapa kesalahan fatal dalam merancang dan mengoperasikan kluster Kafka di lingkungan produksi:

1. Menjalankan Seluruh Broker Kluster di Satu Rak / Availability Zone yang Sama #

Menginstal 3 broker Kafka pada 3 VM (Virtual Machine) yang berbeda, namun ketiga VM tersebut berjalan di atas satu server fisik hypervisor yang sama atau berada di satu rak hardware yang sama.

Konsekuensi Kegagalan: Memiliki 3 broker memberikan ilusi ketersediaan tinggi. Namun, jika server fisik hypervisor tersebut mengalami crash memori atau rak tersebut kehilangan aliran listrik, ketiga broker akan mati secara bersamaan. Kluster Kafka akan mengalami kegagalan kuorum total dan data tidak dapat diakses. Selalu distribusikan broker fisik kluster secara merata di lintas perangkat keras dan lintas zona geografis.

flowchart TD
    subgraph AntiPattern ["ANTI-PATTERN"]
        direction TB
        B1["Broker 1 (VM A)"] --> X1["Fisik Server X (Zone A)"]
        B2["Broker 2 (VM B)"] --> X1
        B3["Broker 3 (VM C)"] --> X1
    end
    
    subgraph Correct ["Solusi yang BENAR (Rack Awareness)"]
        direction TB
        RB1["Broker 1 (VM A)"] --> RX["Fisik Server X (Zone A)"] --> R1["broker.rack=zone-a"]
        RB2["Broker 2 (VM B)"] --> RY["Fisik Server Y (Zone B)"] --> R2["broker.rack=zone-b"]
        RB3["Broker 3 (VM C)"] --> RZ["Fisik Server Z (Zone C)"] --> R3["broker.rack=zone-c"]
    end

2. Menyetel `min.insync.replicas` Sama dengan Jumlah `replication.factor` #

Mengonfigurasi topik dengan replication.factor = 3 dan menyetel aturan min.insync.replicas = 3 dengan alasan keamanan data maksimum.

Konsekuensi Kegagalan: Konfigurasi ini adalah jebakan fatal bagi ketersediaan kluster (availability). Jika salah satu dari 3 broker mengalami pemeliharaan rutin (maintenance) atau mati sementara, jumlah replika aktif yang sinkron (ISR) akan turun menjadi 2. Karena min.insync.replicas menuntut konfirmasi dari 3 broker, produsen yang mengirim data dengan parameter acks=all akan langsung menerima error NotEnoughReplicasException. Kluster kita akan menolak seluruh aktivitas penulisan data baru, membuat sistem aplikasi mogok total. Selalu beri ruang toleransi kegagalan minimal 1 server dengan formula:

$$\text{min.insync.replicas} = \text{replication.factor} - 1$$

Ringkasan #

Definisi Cluster — Kluster Kafka adalah sekumpulan broker server terdistribusi yang bekerja sama untuk membagi beban penyimpanan, pemrosesan data, dan menyediakan toleransi kegagalan yang tinggi bagi aplikasi klien.

KRaft Mode — Kluster Kafka modern menggunakan mode KRaft untuk mengelola metadata kluster secara internal melalui protokol konsensus Raft, menggantikan ketergantungan eksternal pada Apache ZooKeeper.

Proses Failover — Ketika broker Leader partisi mati, Controller akan mendeteksi hilangnya detak jantung dan segera mempromosikan salah satu Follower sehat di dalam kelompok ISR menjadi Leader baru secara otomatis.

Rack Awareness — Konfigurasi wajib menggunakan parameter broker.rack untuk memastikan replika partisi disebar ke rak atau Availability Zone fisik yang berbeda demi keandalan geografis.

Toleransi Kegagalan — Atur konfigurasi kluster produksi secara aman dengan menyetel replication.factor minimal 3, min.insync.replicas minimal 2, dan menyandingkannya dengan parameter pengiriman produsen acks=all.

Hindari Batasan Ketat — Jangan menyetel min.insync.replicas sama dengan nilai replication.factor karena akan menghilangkan toleransi kegagalan kluster dan memicu kemacetan tulis jika ada satu server yang sedang di-maintenance.

← Sebelumnya: Broker Berikutnya: Distributed Commit Log →