Kafka on Bare Metal: Mengoptimalkan Performa Infrastruktur Fisik #

Ketika kita merencanakan arsitektur Apache Kafka untuk skala data berskala petabyte dengan throughput jutaan pesan per detik, keputusan memilih infrastruktur dasar merupakan langkah krusial. Meskipun era komputasi awan dan virtualisasi menawarkan kemudahan provisioning, menjalankan Apache Kafka langsung di atas server fisik tanpa lapisan perantara (Bare Metal) tetap menjadi standar emas (gold standard) untuk kluster berkinerja tinggi dan sensitif terhadap latensi (latency-sensitive).

Menjalankan Kafka di atas Bare Metal menghilangkan semua beban overhead (hypervisor tax) yang biasa kita temukan pada mesin virtual (VM). Tanpa adanya kompetisi perebutan sumber daya hardware (resource contention), broker Kafka dapat memanipulasi piringan disk, alokasi memori page cache, dan antrean paket jaringan secara langsung dengan latensi yang konsisten. Namun, performa puncak ini tidak datang begitu saja. Kita harus mampu merancang spesifikasi hardware secara presisi, menala sistem berkas, menyusun konfigurasi JBOD, dan mengisolasi akses memori NUMA secara benar.

Dalam panduan ini, kita akan membedah perbandingan performa Bare Metal vs Virtualisasi, menyusun spesifikasi hardware minimum kluster produksi, memandu konfigurasi sistem berkas XFS yang optimal, mengeksplorasi alasan mengapa JBOD lebih unggul dibandingkan RAID untuk Kafka, serta melakukan konfigurasi BIOS dan kernel Linux untuk optimasi NUMA.

Mengapa Memilih Bare Metal untuk Kafka? #

Untuk memahami mengapa Bare Metal lebih unggul, kita harus melihat bagaimana hypervisor pada mesin virtual memengaruhi cara kerja internal Kafka. Kafka adalah sistem I/O intensif yang sangat bergantung pada performa baca-tulis disk linier dan manipulasi memori halaman (page cache) oleh sistem operasi.

Berikut adalah tiga tantangan utama virtualisasi yang dapat kita selesaikan dengan beralih ke Bare Metal:

1. CPU Steal Time dan Latency Jitter #

Pada lingkungan virtual shared, CPU fisik dibagi di antara beberapa VM. Jika VM tetangga mengalami lonjakan beban, VM broker Kafka kita dapat mengalami CPU Steal Time—kondisi di mana VM ingin mengeksekusi instruksi CPU tetapi harus mengantre karena hypervisor sedang menjadwalkan tugas untuk VM lain. Jeda antrean mikro ini memicu latency jitter yang dapat merusak detak jantung (heartbeat) pengawas KRaft/ZooKeeper dan mengganggu stabilitas ISR.

2. Perebutan Antrean Disk (Disk Queue Contention) #

Pada hypervisor, request tulis-baca disk dari guest OS harus melewati driver virtual sebelum diterjemahkan oleh hypervisor ke controller disk fisik. Jika beberapa VM menulis ke sistem penyimpanan yang sama secara acak, performa penulisan linier Kafka yang cepat akan berubah menjadi lambat akibat antrean I/O yang padat di tingkat hypervisor (IOPS bottleneck).

3. Degradasi Efisiensi Page Cache #

Kafka menggunakan panggilan sistem sendfile() (teknik Zero-Copy) untuk mengirim data dari file log langsung ke socket jaringan melalui page cache OS. Pada mesin virtual, data harus melewati lapisan abstraksi memori tambahan yang dikelola oleh hypervisor. Proses translasi alamat memori virtual berulang ini menurunkan efisiensi transfer data dan meningkatkan beban CPU.

Rekomendasi Spesifikasi Hardware Produksi #

Dalam memilih hardware fisik untuk server broker Kafka, kita harus menghindari alokasi spesifikasi yang tidak seimbang. Sebagai contoh, menyewa CPU 64-core tetapi hanya menyuplai RAM 16 GB adalah pemborosan, karena performa akan langsung tersendat akibat memori cache yang kekecilan.

Berikut adalah panduan spesifikasi hardware yang seimbang untuk setiap broker Kafka skala produksi:

1. Prosesor (CPU) #

• Rekomendasi: 16 hingga 32 Core fisik (misalnya seri AMD EPYC atau Intel Xeon Gold).
• Karakteristik: Utamakan prosesor dengan kecepatan clock per core yang tinggi dan dukungan instruksi enkripsi AES-NI terintegrasi untuk menangani enkripsi SSL/TLS transit tanpa membebani thread pemrosesan I/O.

2. Memori (RAM) #

• Rekomendasi: 64 GB hingga 256 GB ECC RAM.
• Karakteristik: Alokasikan hanya 4 GB hingga 6 GB untuk heap JVM broker Kafka. Sisanya (lebih dari $90%$ RAM) harus dibiarkan bebas untuk digunakan oleh page cache sistem operasi Linux guna menampung segmen log terpanas di memori.

3. Penyimpanan (Disk Storage) #

• Rekomendasi: Multi-disk SSD (SATA/SAS) atau NVMe (ukuran 1 TB - 4 TB per disk) yang dipasang secara independen (JBOD).
• Karakteristik: Hindari penggunaan HDD tunggal berskala besar jika kluster melayani banyak konsumen lambat yang sering membaca data historis dari disk. SSD menawarkan IOPS acak stabil yang mencegah kemacetan baca.

Arsitektur Fisik Server Bare Metal Kafka #

Berikut adalah diagram pemetaan bagaimana komponen fisik server Bare Metal berinteraksi langsung dengan sistem operasi dan proses JVM Kafka tanpa perantara hypervisor:

flowchart TD
    subgraph Hardware ["Fisik Server Bare Metal"]
        CPU["CPU: Multi-Core (Performance Mode)"]
        NUMA1["NUMA Zone 1 (RAM Lokal)"]
        NUMA2["NUMA Zone 2 (RAM Lokal)"]
        NIC["Kartu Jaringan: Dual 10 Gbps (Bonding)"]
        DiskBus["PCIe / SATA Bus Controller"]
        
        subgraph JBOD ["Konfigurasi JBOD Disk"]
            Disk1["Disk 1: NVMe SSD (/mnt/data1)"]
            Disk2["Disk 2: NVMe SSD (/mnt/data2)"]
            Disk3["Disk 3: NVMe SSD (/mnt/data3)"]
        end
    end

    subgraph OS ["Sistem Operasi Linux (XFS Filesystem)"]
        PageCache["OS Page Cache (RAM Bebas)"]
        NetStack["Linux TCP Network Stack"]
    end

    subgraph JVM ["Java Virtual Machine"]
        KafkaBroker["Proses Kafka Broker (Heap 6GB)"]
    end

    CPU --> JVM
    NUMA1 --> PageCache
    NUMA2 --> PageCache
    JVM -->|"Zero-Copy (sendfile)"| PageCache
    PageCache --> NetStack
    NetStack --> NIC
    DiskBus --> JBOD
    PageCache -->|"Asinkron Flush"| DiskBus

Konfigurasi Sistem Berkas (Filesystem) XFS #

Pemilihan dan konfigurasi sistem berkas (filesystem) pada sistem operasi Linux memiliki dampak besar terhadap seberapa cepat Kafka dapat menulis log segment ke disk fisik. Sangat direkomendasikan untuk menggunakan sistem berkas XFS alih-alih Ext4 untuk semua disk data Kafka.

Keunggulan XFS untuk Apache Kafka: #

1. Alokasi Inode Dinamis: XFS mengalokasikan inode secara dinamis di seluruh sistem berkas, berbeda dengan Ext4 yang mengalokasikan inode statis di awal format. Karena Kafka sering membuat dan menghapus file segmen berukuran besar, XFS jauh lebih efisien dalam meminimalkan fragmentasi disk.
2. Online Defragmentation: XFS mendukung proses defragmentasi file secara online saat sistem berkas sedang aktif dipasang (mounted), menjaga konsistensi latensi penulisan linier.
3. Kinerja Paralel Berkecepatan Tinggi: XFS dirancang dari awal untuk menangani multi-threaded I/O secara paralel ke satu sistem berkas, sangat cocok dengan arsitektur Kafka yang menggunakan beberapa thread I/O (num.io.threads).

Penalaan Parameter Mount (/etc/fstab) #

Untuk memaksimalkan throughput tulis disk XFS, kita wajib mematikan pencatatan waktu akses file (access time logging) dan mengoptimalkan buffer internal XFS saat memasang partisi disk.

Ubah berkas /etc/fstab kita dan tambahkan parameter mount berikut untuk setiap disk data Kafka:

# Contoh konfigurasi mount XFS untuk disk data JBOD pertama
UUID=xxxx-xxxx-xxxx    /mnt/kafka-data1    xfs    noatime,nodiratime,nobarrier,logbufs=8,logbsize=256k,largeio,inode64    0  2

Analisis Parameter Mount: #

• noatime: Mematikan pencatatan waktu akses setiap kali file dibaca. Tanpa opsi ini, setiap kali konsumen membaca log segment, sistem operasi harus menulis metadata waktu akses baru ke disk, memicu operasi tulis yang tidak perlu.
• nodiratime: Serupa dengan noatime, opsi ini mematikan pencatatan waktu akses untuk direktori.
• nobarrier: Menonaktifkan penghalang tulis (write barriers). Opsi ini membolehkan disk menulis data ke cache internalnya terlebih dahulu tanpa menunggu konfirmasi fisik piringan disk selesai ditulis. PENTING: Hanya aktifkan opsi ini jika server Bare Metal kita dilengkapi dengan kartu RAID controller atau HBA yang memiliki baterai cadangan (BBU - Battery Backed Unit) atau Flash-backed cache untuk mencegah kehilangan data saat mati lampu mendadak.
• logbufs=8 & logbsize=256k: Meningkatkan jumlah dan ukuran buffer log transaksi XFS di memori sebelum ditulis ke disk, memperlancar operasi tulis paralel.
• largeio: Menginstruksikan sistem berkas untuk melaporkan ukuran I/O optimal yang lebih besar ke sistem operasi, sangat baik untuk penulisan berukuran besar khas Kafka.

Penalaan Disk JBOD (Just a Bunch of Disks) vs RAID #

Dalam mengelola multi-disk pada server Bare Metal, pendekatan tradisional biasanya menggabungkan seluruh disk fisik ke dalam satu volume logis menggunakan perangkat keras RAID (seperti RAID 5, RAID 6, atau RAID 10). Namun, untuk Apache Kafka, desain yang paling direkomendasikan adalah JBOD (Just a Bunch of Disks).

Mengapa Menolak RAID untuk Penyimpanan Kafka? #

• RAID 5 & 6 (Parity Overhead): RAID tipe ini menghitung data parity untuk setiap operasi tulis. Setiap penulisan record Kafka akan memicu “Write Penalty” di mana controller harus membaca data lama, menghitung parity baru, dan menulis ulang data. Proses ini menghancurkan performa throughput tulis Kafka.
• RAID 10 (Overkill Cost): RAID 10 menawarkan performa bagus karena melakukan mirroring dan striping. Namun, karena Kafka sudah melakukan replikasi data di tingkat aplikasi lintas server broker (misalnya dengan Replication Factor = 3), menggunakan RAID 10 di tingkat server lokal berarti kita menduplikasi data yang sama sebanyak 6 kali! Ini adalah pemborosan anggaran storage yang luar biasa.

Mengapa Memilih JBOD? #

Dengan JBOD, setiap disk fisik diformat secara independen dan dipasang ke direktori yang berbeda (misalnya /mnt/kafka-data1, /mnt/kafka-data2, dst.). Kita kemudian mendaftarkan seluruh direktori ini ke properti log.dirs di file server.properties Kafka:

# Pendaftaran multi-path direktori JBOD pada broker
log.dirs=/mnt/kafka-data1,/mnt/kafka-data2,/mnt/kafka-data3,/mnt/kafka-data4

Keunggulan JBOD di Kafka meliputi:

1. Penyebaran Beban Tulis Otomatis: Kafka akan mendistribusikan replika partisi topik baru secara merata ke direktori yang memiliki jumlah partisi paling sedikit, membagi beban I/O disk secara adil ke seluruh disk fisik secara paralel.
2. Resiliensi Disk Gagal (Offline Log Directories): Jika salah satu disk fisik pada JBOD mengalami kegagalan sektor (bad sector atau mati total), Kafka tidak akan mematikan seluruh broker. Broker tetap hidup dan hanya menonaktifkan direktori log yang rusak tersebut (berstatus offline log directory). Partisi topik yang berada di disk sehat lainnya tetap dapat melayani klien dengan normal, sementara replika partisi pada disk yang rusak akan dialihkan secara otomatis ke broker lain oleh controller.
3. Maksimalisasi IOPS Murni: Kita mendapatkan akumulasi kecepatan I/O mentah dari seluruh disk tanpa adanya batasan bottleneck dari satu controller RAID tunggal.

Isolasi Resource dan NUMA (Non-Uniform Memory Access) Tuning #

Server Bare Metal modern berskala besar umumnya menggunakan arsitektur multi-socket CPU (misalnya satu motherboard berisi dua prosesor fisik). Arsitektur ini menggunakan desain memori NUMA (Non-Uniform Memory Access).

Dalam desain NUMA, memori RAM dibagi menjadi beberapa zona (NUMA Nodes), di mana setiap zona terhubung secara fisik ke salah satu socket CPU.

flowchart TD
    subgraph Node0 ["NUMA NODE 0"]
        CPU0["CPU Socket 0"] <--> |"Akses Lokal Cepat"| RAM0["RAM Lokal Node 0"]
    end
    
    subgraph Node1 ["NUMA NODE 1"]
        CPU1["CPU Socket 1"] <--> |"Akses Lokal Cepat"| RAM1["RAM Lokal Node 1"]
    end
    
    CPU0 <--> |"Bus Cepat"| CPU1
    RAM0 <--> |"Akses Lambat"| RAM1

Jika thread JVM Kafka yang berjalan pada CPU Socket 0 mencoba mengakses data page cache yang berada di RAM Lokal Node 1, ia harus melewati bus inter-konektor prosesor yang lambat (QPI/UPI interconnect). Latensi akses memori silang (cross-node memory access) ini jauh lebih lambat dibandingkan akses memori lokal, memicu peningkatan latensi eksekusi program.

Langkah Optimasi NUMA untuk Kafka: #

1. Setel BIOS Node Interleaving ke Disabled #

Pastikan fitur Node Interleaving (atau NUMA mode) diaktifkan di tingkat BIOS server (disetel ke Disabled atau NUMA mode aktif, bukan UMA/SPAN mode). Ini memastikan sistem operasi dapat melihat dan membagi zona memori dengan jelas.

2. Konfigurasi Zone Reclaim Mode di Linux Kernel #

Secara default, jika sebuah zona NUMA kehabisan memori bebas, Linux akan mencoba merebut halaman memori lokal secara agresif (page reclaiming) daripada mengalokasikan memori dari zona NUMA lainnya. Proses reclaiming ini memicu jeda I/O mikro yang mengganggu.

Matikan zone reclaim mode dengan menambahkan parameter berikut ke berkas /etc/sysctl.conf:

vm.zone_reclaim_mode = 0

Menyetel nilai ini ke 0 memerintahkan sistem operasi untuk mengizinkan alokasi memori lintas zona NUMA jika memori lokal sedang penuh, alih-alih memaksa pembersihan cache lokal secara agresif.

3. Jalankan Kafka dengan Kebijakan Memori Interleave #

Untuk mencegah satu zona NUMA mengalami kelangkaan memori akibat monopoli page cache Kafka yang besar, kita disarankan menyebarkan alokasi memori JVM Kafka secara merata ke seluruh zona NUMA menggunakan utilitas numactl.

Ubah skrip inisialisasi systemd service Kafka (/etc/systemd/system/kafka.service) kita:

[Service]
Type=simple
User=kafka
Group=kafka
# Jalankan Kafka dengan instruksi numactl --interleave=all
ExecStart=/usr/bin/numactl --interleave=all /opt/kafka/bin/kafka-server-start.sh /etc/kafka/server.properties
ExecStop=/opt/kafka/bin/kafka-server-stop.sh
Restart=on-failure
LimitNOFILE=100000

Kebijakan --interleave=all memaksa sistem operasi untuk mengalokasikan halaman memori JVM secara bergantian (round-robin) ke seluruh zona NUMA aktif, membagi beban memori secara merata dan menghilangkan resiko crash akibat kelangkaan alokasi pada satu zona memori lokal tertentu.

Checklist Audit Kesiapan Perangkat Keras Bare Metal #

Lakukan langkah verifikasi berikut pada server fisik kita sebelum memulai instalasi perangkat lunak Apache Kafka untuk memastikan standar kepatuhan Bare Metal terpenuhi:

Ringkasan #

• Bebas Overhead Virtualisasi — Menjalankan Kafka di atas Bare Metal menghilangkan latency jitter akibat CPU steal time dan perebutan antrean disk I/O yang umum terjadi pada hypervisor VM.
• Tuning Sistem Berkas XFS — Gunakan XFS sebagai sistem berkas data Kafka dengan menyertakan flag mount noatime dan nodiratime untuk meniadakan overhead penulisan metadata waktu akses.
• Pilih JBOD dibanding RAID — Manfaatkan JBOD untuk meningkatkan IOPS murni disk secara ekonomis dan mengaktifkan fitur penanganan kegagalan otomatis direktori offline di Kafka.
• Terapkan Interleave NUMA — Jalankan proses JVM broker menggunakan perintah numactl --interleave=all untuk membagi rata beban memori ke seluruh zona NUMA fisik dan mencegah crash memori terlokalisasi.

← Sebelumnya: Performance Tuning   Berikutnya: Kafka on VMs →