Kafka Fundamental

Apa itu Apache Kafka?

Belajar tentang Apache Kafka dan ekosistemnya dalam 20 menit

Dalam dunia data event streaming, Apache Kafka adalah standar de facto. Apache Kafka adalah sistem terdistribusi open-source yang terdiri dari server (broker) dan klien. Kafka digunakan terutama untuk membangun pipeline data streaming secara real-time.

Apache Kafka digunakan oleh ribuan organisasi terkemuka di dunia untuk data pipeline berkinerja tinggi, analitik streaming, integrasi data, dan berbagai aplikasi penting lainnya. Dalam seri pengenalan tiga bagian ini, Anda akan mempelajari:

  • Apa itu Apache Kafka dan asal-usulnya.

  • Komponen utama Apache Kafka.

  • Apa itu ekosistem Apache Kafka.

Pada akhir seri ini, Anda akan memahami dengan percaya diri Apache Kafka dan perannya dalam dunia data streaming.

Ingin memulai dengan cepat? Platform Conduktor adalah cara terbaik untuk mempelajari Apache Kafka. Cobalah sekarang secara gratis dan temukan betapa mudahnya menggunakan Kafka.

Bagian 1: Tantangan Integrasi Data

Konteks

Sebuah organisasi biasanya memiliki berbagai sumber data dengan format yang berbeda-beda. Integrasi data melibatkan penggabungan data dari berbagai sumber ini menjadi satu pandangan terpadu tentang bisnis mereka. Bisnis umumnya mengumpulkan data melalui berbagai aplikasi, seperti akuntansi, penagihan, CRM, situs web, dan lainnya. Setiap aplikasi memiliki proses sendiri untuk input dan pembaruan data. Untuk mendapatkan pandangan terpadu, insinyur harus mengembangkan integrasi khusus (bespoke integrations) antar aplikasi ini.

Integrasi langsung ini sering kali menghasilkan solusi yang rumit, seperti yang ditunjukkan pada diagram (disesuaikan dengan penjelasan teks). Setiap integrasi memiliki tantangan, seperti:

  • Protokol: Cara data diangkut (TCP, HTTP, REST, FTP, JDBC, dll.).

  • Format Data: Cara data diuraikan (Binary, CSV, JSON, Avro, dll.).

  • Skema dan Evolusi Data: Bagaimana data disusun dan dapat berubah seiring waktu.

Apache Kafka sebagai Solusi

Memisahkan Sistem Data yang Berbeda (Decoupling) Apache Kafka memungkinkan kita untuk memisahkan (decouple) aliran data dan sistem. Dengan Kafka sebagai lapisan integrasi data, sumber data akan mempublikasikan data ke Kafka, dan sistem target akan mengambil data dari Kafka. Pendekatan ini menyederhanakan integrasi data, seperti yang ditunjukkan pada diagram (disesuaikan dengan penjelasan teks).

Apa itu Aliran Data (Data Stream) dalam Apache Kafka?

Aliran data adalah urutan data yang berpotensi tidak terbatas (unbounded sequence). Istilah streaming digunakan karena data tersedia segera setelah diproduksi. Setiap aplikasi dalam organisasi yang menghasilkan data adalah pencipta aliran data potensial. Data dalam aliran biasanya berukuran kecil, tetapi throughput datanya sangat bervariasi: beberapa aliran menerima puluhan ribu rekaman per detik, sementara yang lain hanya satu atau dua rekaman per jam.

Apache Kafka digunakan untuk menyimpan aliran data ini (juga disebut topik), yang memungkinkan sistem melakukan stream processing—yaitu, melakukan perhitungan terus-menerus pada sumber data yang berpotensi tak terbatas dan terus berkembang. Setelah aliran diproses dan disimpan di Kafka, data dapat ditransfer ke sistem lain, seperti basis data.

Contoh Aliran Data Berikut adalah beberapa contoh aliran data di dunia nyata yang diproses oleh perusahaan:

  • Analisis Log: Aplikasi modern terdiri dari puluhan hingga ribuan microservices, yang semuanya menghasilkan log secara terus-menerus. Log ini berisi informasi yang dapat digunakan untuk intelijen bisnis, prediksi kegagalan, dan debugging. Tantangannya adalah memproses volume log yang besar ini. Perusahaan memasukkan data log ke aliran data untuk melakukan stream processing.

  • Analitik Web: Aplikasi web modern mengukur hampir setiap aktivitas pengguna, seperti klik tombol atau tampilan halaman. Data ini menumpuk dengan cepat, dan stream processing memungkinkan perusahaan memproses data saat dihasilkan, bukan berjam-jam kemudian.

Mengapa Perusahaan Harus Menggunakan Apache Kafka?

Ketika sebuah perusahaan memiliki kebutuhan data streaming secara real-time, platform streaming harus diterapkan. Apache Kafka adalah salah satu platform pemrosesan data streaming paling populer saat ini, digunakan oleh lebih dari 80% perusahaan Fortune 100. Kafka menyediakan antarmuka message queue sederhana di atas media penyimpanan berstruktur log (append-only log-structured storage). Kafka menyimpan log peristiwa, mendistribusikan data ke beberapa node, serta sangat skalabel dan tahan terhadap kehilangan node (fault-tolerant).

Kafka telah diterapkan dalam berbagai skala, mulai dari satu node hingga ribuan node, dan digunakan secara luas dalam beban kerja produksi oleh perusahaan seperti Netflix, Apple, Uber, Airbnb, dan LinkedIn. Pencipta Kafka meninggalkan LinkedIn untuk mendirikan Confluent, sebuah perusahaan yang fokus pada pengembangan Kafka dan ekosistemnya. Kini, Apache Kafka adalah proyek open-source yang dikelola oleh Confluent dengan kontribusi dari perusahaan lain seperti IBM, Yelp, dan Netflix.

Sejarah Apache Kafka

Kafka diciptakan di LinkedIn untuk memenuhi kebutuhan pemrosesan aliran data internal yang tidak dapat ditangani oleh sistem antrian pesan tradisional. Versi pertamanya dirilis pada Januari 2011. Kafka dengan cepat mendapatkan popularitas dan menjadi salah satu proyek paling terkenal di Apache Foundation.

Kasus Penggunaan Apache Kafka

Apache Kafka memiliki banyak kasus penggunaan, termasuk:

  • Sistem pesan (messaging systems).

  • Pelacakan aktivitas (activity tracking).

  • Pengumpulan metrik dari berbagai lokasi, seperti perangkat IoT.

  • Analisis log aplikasi.

  • Pemisahan ketergantungan sistem (decoupling).

  • Integrasi dengan teknologi big data seperti Spark, Flink, Storm, dan Hadoop.

  • Penyimpanan untuk event sourcing.

Daftar lengkap kasus penggunaan dapat ditemukan di https://kafka.apache.org/uses.

Kapan Apache Kafka Tidak Cocok?

Meskipun Kafka sangat cocok untuk kasus penggunaan di atas, ada beberapa situasi di mana penggunaan Kafka tidak memungkinkan atau tidak disarankan:

  • Proksi untuk Jutaan Klien (Aplikasi Seluler atau IoT): Protokol Kafka tidak dirancang untuk menangani jutaan klien secara langsung, meskipun beberapa proksi dapat digunakan untuk menjembatani kebutuhan ini.

  • Basis Data dengan Indeks: Kafka adalah log streaming peristiwa tanpa kemampuan analitik bawaan atau model kueri kompleks.

  • Teknologi Real-time Tertanam untuk IoT: Ada alternatif yang lebih ringan untuk sistem tertanam.

  • Antrian Kerja (Work Queues): Kafka menggunakan topik, bukan antrian seperti RabbitMQ, ActiveMQ, atau SQS. Antrian dirancang untuk mendukung jutaan konsumer dan menghapus pesan setelah diproses, sedangkan Kafka tidak menghapus data setelah diproses dan konsumer tidak dapat diskalakan melebihi jumlah partisi dalam topik.

  • Kafka sebagai Blockchain: Topik Kafka memiliki beberapa karakteristik blockchain (data ditambahkan dalam log dan dapat bersifat immutable), tetapi tidak memiliki properti utama blockchain seperti verifikasi kriptografis dan pelestarian riwayat penuh.

Penggunaan Nyata Apache Kafka di Industri

Apache Kafka digunakan secara luas di berbagai industri. Beberapa contoh penggunaan meliputi:

  • Uber: Kafka menjadi tulang punggung pipeline penentuan harga real-time. Kafka memungkinkan Uber untuk menyesuaikan model harga berdasarkan peristiwa yang terus berubah, seperti jumlah pengemudi yang tersedia, posisi pengguna, cuaca, atau acara lainnya, untuk mengelola penawaran dan permintaan secara akurat.

  • Netflix: Kafka adalah komponen inti dari Keystone data pipeline Netflix, menangani miliaran peristiwa setiap hari, dengan sekitar 500 miliar peristiwa dan 1,3 petabyte data per hari.

Kafka juga digunakan oleh perusahaan seperti Airbnb, LinkedIn, Apple, dan Walmart, yang mendukung banyak layanan yang kita gunakan setiap hari.

Bagian 2: Definisi Konsep Inti Apache Kafka

Setelah memahami gambaran umum tentang Apache Kafka, mari kita pelajari cara menggunakan alat ini. Bagian ini mencakup dasar-dasar topik Kafka, produser, dan konsumer.

Apa itu Topik Kafka?

Topik Kafka digunakan untuk mengatur peristiwa yang terkait. Misalnya, topik bernama logs dapat berisi log dari aplikasi. Topik Kafka mirip dengan tabel SQL, tetapi berbeda karena topik tidak dapat di-query secara langsung. Untuk memanfaatkan data, kita harus membuat produser dan konsumer Kafka. Data dalam topik disimpan dalam format kunci-nilai (key-value) dalam bentuk biner.

Baca lebih lanjut di bagian Topik, Partisi, dan Offset Kafka.

Apa itu Produser Kafka?

Setelah topik dibuat, langkah berikutnya adalah mengirim data ke topik tersebut. Aplikasi yang mengirim data ke topik disebut produser Kafka. Ada banyak cara untuk menghasilkan peristiwa ke Kafka, tetapi aplikasi biasanya mengintegrasikan pustaka klien Kafka dalam bahasa seperti Java, Python, Go, dan lainnya. Produser Kafka dijalankan di luar Kafka dan hanya berinteraksi dengan Kafka dengan mengirim data langsung ke topik.

Baca lebih lanjut di bagian Produser Kafka.

Apa itu Konsumer Kafka?

Setelah topik dibuat dan data diproduksi ke dalamnya, aplikasi dapat memanfaatkan aliran data tersebut. Aplikasi yang mengambil data peristiwa dari satu atau lebih topik Kafka disebut konsumer Kafka. Konsumer biasanya menggunakan pustaka klien Kafka dalam bahasa seperti Java, Python, Go, dan lainnya. Secara default, konsumer hanya mengonsumsi data yang diproduksi setelah konsumer pertama kali terhubung ke topik.

Baca lebih lanjut di bagian Konsumer Kafka.

Bagian 3: Ekosistem Kafka

Sejumlah alat dan pustaka tambahan telah dikembangkan untuk Kafka selama bertahun-tahun untuk memperluas fungsionalitasnya. Bagian ini akan membahas beberapa bagian paling populer dari ekosistem Kafka yang lebih luas.

Apa itu Kafka Streams?

Setelah data dari sistem eksternal diproduksi ke Kafka, kita mungkin ingin memprosesnya menggunakan aplikasi pemrosesan aliran (stream processing). Aplikasi ini memanfaatkan penyimpanan data streaming seperti Kafka untuk menyediakan analitik real-time.

Sebagai contoh, misalkan kita memiliki topik Kafka bernama twitter_tweets yang berisi aliran data semua tweet di Twitter. Dari topik ini, kita mungkin ingin:

  • Memfilter tweet yang memiliki lebih dari 10 suka atau balasan untuk menangkap tweet penting.

  • Menghitung jumlah tweet untuk setiap hashtag setiap 1 menit.

  • Menggabungkan keduanya untuk mendapatkan topik dan hashtag yang sedang tren secara real-time.

Untuk melakukan transformasi pada level topik dalam Kafka, kita dapat menggunakan pustaka streaming seperti Kafka Streams, sebuah kerangka kerja pemrosesan aliran yang dirilis bersama Apache Kafka. Alternatif lain untuk Kafka Streams adalah Apache Spark atau Apache Flink.

Apa itu Kafka Connect?

Untuk memasukkan data ke Kafka, kita perlu menggunakan produser Kafka. Seiring waktu, banyak perusahaan memiliki jenis sumber data yang sama (basis data, sistem, dll.), sehingga kode open-source standar dapat membantu. Pemikiran yang sama berlaku untuk konsumer Kafka.

Kafka Connect adalah alat yang memungkinkan integrasi sistem populer dengan Kafka. Kafka Connect memungkinkan penggunaan kembali komponen yang ada untuk memasukkan data ke Kafka (source) dan mengeluarkan data dari Kafka ke penyimpanan data lain (sink).

Contoh Konektor Kafka Populer:

  • Konektor Source (Produser): Basis data (melalui konektor Debezium), JDBC, Couchbase, GoldenGate, SAP HANA, Blockchain, Cassandra, DynamoDB, FTP, IoT, MongoDB, MQTT, RethinkDB, Salesforce, Solr, SQS, Twitter, dll.

  • Konektor Sink (Konsumer): S3, ElasticSearch, HDFS, JDBC, SAP HANA, DocumentDB, Cassandra, DynamoDB, HBase, MongoDB, Redis, Solr, Splunk, Twitter.

Apa itu Schema Registry?

Schema Registry membantu mendaftarkan skema data dalam Apache Kafka dan memastikan bahwa produser dan konsumer kompatibel satu sama lain selama evolusi skema. Schema Registry mendukung format data seperti Apache Avro, Protobuf, dan JSON-Schema.

Skema Data Skema data menentukan bidang yang diharapkan, nama mereka, dan tipe nilai untuk data Anda. Tanpa Schema Registry, perubahan pada skema data dapat menyebabkan kegagalan produser atau konsumer. Schema Registry memastikan kompatibilitas dan mendukung evolusi skema tanpa mengganggu aplikasi yang berjalan.

Penambahan Penjelasan

Untuk memperjelas, Apache Kafka adalah platform streaming yang dirancang untuk menangani data dalam skala besar dengan latensi rendah dan ketahanan tinggi. Salah satu keunggulan utama Kafka adalah kemampuannya untuk memisahkan sistem sumber dan target, sehingga mengurangi kompleksitas integrasi data. Dalam praktiknya, Kafka sering digunakan bersama alat seperti Kafka Streams untuk analitik real-time atau Kafka Connect untuk integrasi dengan sistem eksternal, seperti basis data atau penyimpanan cloud.

Penting untuk dicatat bahwa Kafka bukan solusi untuk semua masalah data. Untuk aplikasi yang memerlukan kueri kompleks atau penyimpanan data permanen dengan indeks, basis data seperti PostgreSQL atau Elasticsearch mungkin lebih cocok. Namun, untuk kasus penggunaan yang melibatkan aliran data real-time dengan volume tinggi, Kafka adalah pilihan yang sangat kuat.

Ekosistem Kafka, termasuk Kafka Streams, Kafka Connect, dan Schema Registry, memungkinkan pengembang untuk membangun solusi yang fleksibel dan skalabel. Misalnya, Kafka Connect menyederhanakan integrasi dengan sistem eksternal tanpa perlu menulis kode produser atau konsumer dari awal, sementara Schema Registry memastikan konsistensi data dalam lingkungan yang dinamis. Untuk lingkungan produksi, penting untuk memantau performa klaster Kafka menggunakan alat seperti Kafka Manager atau metrik bawaan untuk memastikan operasi yang stabil.

Topik, Partisi, dan Offset Kafka

Apa itu Topik Kafka?

Sama seperti basis data menggunakan tabel untuk mengatur dan memisahkan kumpulan data, Kafka menggunakan konsep topik untuk mengatur pesan-pesan yang terkait.

Topik diidentifikasi dengan namanya. Misalnya, kita dapat memiliki topik bernama logs yang berisi pesan log dari aplikasi kita, dan topik lain bernama purchases yang berisi data pembelian dari aplikasi saat transaksi terjadi.

Topik Kafka dapat berisi berbagai jenis pesan dalam format apa pun, dan urutan semua pesan ini disebut aliran data (data stream).

Peringatan tentang Topik Kafka

Berbeda dengan tabel basis data, topik Kafka tidak dapat di-query. Sebagai gantinya, kita perlu membuat produser Kafka untuk mengirim data ke topik dan konsumer Kafka untuk membaca data dari topik secara berurutan.

Data dalam topik Kafka dihapus secara default setelah satu minggu (dikenal sebagai periode retensi pesan default), dan nilai ini dapat dikonfigurasi. Mekanisme penghapusan data lama ini memastikan klaster Kafka tidak kehabisan ruang disk dengan mendaur ulang topik dari waktu ke waktu.

Apa itu Partisi Kafka?

Topik dibagi menjadi beberapa partisi. Satu topik dapat memiliki lebih dari satu partisi, dan sering kali topik memiliki hingga 100 partisi.

Jumlah partisi sebuah topik ditentukan saat topik dibuat. Partisi diberi nomor mulai dari 0 hingga N-1, di mana N adalah jumlah partisi. Gambar berikut menunjukkan sebuah topik dengan tiga partisi, dengan pesan-pesan ditambahkan ke akhir masing-masing partisi.

Partisi digunakan untuk meningkatkan toleransi kesalahan (fault tolerance). Setiap partisi menyimpan sebagian dari data topik, memungkinkan pemrosesan paralel dan distribusi data di seluruh klaster Kafka.

Offset dalam Partisi

Offset adalah nilai bilangan bulat yang ditambahkan Kafka ke setiap pesan saat pesan ditulis ke dalam partisi. Setiap pesan dalam partisi tertentu memiliki offset yang unik.

Sifat Imutabel Topik Kafka

Topik Kafka bersifat imutabel: setelah data ditulis ke partisi, data tersebut tidak dapat diubah. Hal ini memastikan integritas data dalam aliran Kafka.

Contoh Penggunaan Topik Kafka

Apache Kafka memiliki banyak aplikasi dunia nyata. Salah satu contohnya adalah penggunaan Kafka untuk pelacakan armada di industri transportasi.

Studi Kasus: Pelacakan Armada dengan Apache Kafka

Sebuah perusahaan transportasi ingin melacak armada truknya. Setiap truk dilengkapi dengan pelacak GPS yang melaporkan posisinya ke Kafka. Kita dapat membuat topik bernama trucks_gps di mana truk-truk mengirimkan posisi mereka. Setiap truk dapat mengirim pesan ke Kafka setiap 20 detik, dengan setiap pesan berisi ID truk dan posisi truk (latitude dan longitude). Topik ini dapat dibagi menjadi jumlah partisi yang sesuai, misalnya 10 partisi.

Berbagai konsumer dapat menggunakan topik ini. Misalnya:

  • Aplikasi yang menampilkan lokasi truk pada dashboard secara real-time.

  • Aplikasi lain yang mengirim notifikasi jika terjadi peristiwa penting, seperti truk memasuki area tertentu.

Apa itu Offset Kafka?

Offset Kafka menunjukkan posisi sebuah pesan dalam partisi Kafka. Penomoran offset untuk setiap partisi dimulai dari 0 dan bertambah untuk setiap pesan yang dikirim ke partisi tertentu. Ini berarti offset hanya memiliki makna dalam konteks partisi tertentu; misalnya, offset 3 di partisi 0 tidak mewakili data yang sama dengan offset 3 di partisi 1.

Urutan Offset Kafka

Jika sebuah topik memiliki lebih dari satu partisi, Kafka menjamin urutan pesan dalam setiap partisi, tetapi tidak ada jaminan urutan antar partisi. Dengan kata lain, pesan dalam partisi yang sama akan selalu diproses secara berurutan, tetapi pesan dari partisi yang berbeda dapat diproses tanpa urutan tertentu.

Meskipun pesan dalam topik Kafka dihapus setelah periode retensi (seperti dijelaskan di atas), offset tidak digunakan kembali. Offset terus bertambah dalam urutan yang tidak pernah berakhir, memastikan bahwa setiap pesan baru memiliki offset yang unik.

Catatan Tambahan

Untuk memahami topik Kafka secara mendalam, penting untuk mengetahui bahwa topik dan partisi memungkinkan Kafka untuk menangani data dalam skala besar dengan cara yang terdistribusi. Pemilihan jumlah partisi harus mempertimbangkan kebutuhan throughput, latensi, dan kemampuan klaster untuk menangani beban. Selain itu, konfigurasi seperti replikasi partisi (untuk keandalan) dan faktor replikasi juga memainkan peran penting dalam menjaga ketersediaan dan ketahanan sistem Kafka.

Produser Kafka, Kunci Pesan, Offset Pesan, dan Serializer

Apa itu Produser Kafka?

Setelah topik dibuat dalam Apache Kafka, langkah selanjutnya adalah mengirim data ke topik tersebut. Di sinilah peran Kafka Producer menjadi penting. Produser Kafka adalah aplikasi yang mengirimkan data ke topik Kafka. Aplikasi ini biasanya mengintegrasikan pustaka klien Kafka (Kafka client library) untuk menulis data ke Apache Kafka. Pustaka klien ini tersedia untuk hampir semua bahasa pemrograman populer, seperti Python, Java, Go, dan lainnya.

Produser Kafka mengirimkan pesan ke topik, dan pesan-pesan ini didistribusikan ke partisi berdasarkan mekanisme tertentu, seperti key hashing (akan dijelaskan lebih lanjut di bawah). Untuk memastikan pesan berhasil ditulis ke topik, produser harus menentukan tingkat pengakuan (acknowledgment atau acks). Topik ini akan dibahas secara mendalam pada bagian replikasi topik.

Kunci Pesan (Message Keys)

Setiap pesan dalam Kafka dapat memiliki kunci (key) opsional dan nilai (value).

  • Jika kunci tidak ditentukan (key=null): Pesan akan didistribusikan secara merata ke seluruh partisi dalam topik menggunakan metode round-robin. Artinya, pesan akan dikirim secara bergantian ke partisi p0, p1, p2, dan seterusnya, lalu kembali ke p0.

  • Jika kunci ditentukan (key!=null): Semua pesan dengan kunci yang sama akan selalu dikirim dan disimpan di partisi yang sama. Kunci dapat berupa apa saja, seperti string, angka, atau nilai biner, yang digunakan untuk mengidentifikasi pesan.

Kunci pesan sering digunakan ketika urutan pesan harus dipertahankan untuk semua pesan yang memiliki nilai kunci yang sama. Sebagai contoh, dalam skenario pelacakan armada truk, kita ingin data dari setiap truk diurutkan berdasarkan truk individu. Dalam hal ini, kita dapat menggunakan truck_id sebagai kunci. Misalnya, semua data dari truk dengan ID truck_id_123 akan selalu masuk ke partisi p0, seperti yang ditunjukkan pada diagram (disesuaikan dengan penjelasan teks).

Anatomi Pesan Kafka

Pesan Kafka dibuat oleh produser dan terdiri dari beberapa elemen berikut:

  • Kunci (Key): Kunci bersifat opsional dan dapat bernilai null. Kunci dapat berupa string, angka, atau objek lain yang kemudian diserialisasi ke format biner.

  • Nilai (Value): Nilai adalah konten utama pesan dan juga dapat bernilai null. Format nilai bersifat bebas dan akan diserialisasi ke format biner.

  • Tipe Kompresi (Compression Type): Pesan Kafka dapat dikompresi untuk menghemat ruang. Tipe kompresi yang tersedia meliputi none, gzip, lz4, snappy, dan zstd.

  • Header: Header adalah daftar pasangan kunci-nilai opsional yang digunakan untuk menyimpan metadata tentang pesan, sering kali untuk keperluan pelacakan (tracing).

  • Partisi + Offset: Setelah pesan dikirim ke topik, pesan tersebut diberi nomor partisi dan ID offset. Kombinasi topik + partisi + offset mengidentifikasi pesan secara unik dalam sistem Kafka.

  • Timestamp: Timestamp ditambahkan ke pesan, baik oleh pengguna maupun oleh sistem, untuk menandai waktu pembuatan atau pengiriman pesan.

Serializer Pesan Kafka

Dalam banyak bahasa pemrograman, kunci dan nilai pesan direpresentasikan sebagai objek untuk meningkatkan keterbacaan kode. Namun, broker Kafka hanya menerima array byte sebagai kunci dan nilai pesan. Proses mengubah representasi objek dalam kode menjadi format biner disebut serialisasi pesan.

Sebagai contoh, jika sebuah pesan memiliki kunci bertipe Integer dan nilai bertipe String, kita perlu menggunakan IntegerSerializer untuk mengubah kunci menjadi array byte, dan StringSerializer untuk nilai. Dalam Java Client SDK untuk Apache Kafka, beberapa serializer bawaan tersedia, seperti untuk tipe string, integer, dan float. Untuk format seperti JSON-Schema, Apache Avro, atau Protobuf, serializer tambahan tersedia melalui Confluent Schema Registry.

Catatan untuk Non-JVM: Jika Anda menggunakan bahasa pemrograman di luar ekosistem JVM untuk serialisasi dan deserialisasi, pastikan pustaka klien Kafka yang Anda gunakan mendukung format data yang dibutuhkan.

Penjelasan Tambahan: Key Hashing dalam Kafka

Key hashing adalah proses menentukan pemetaan kunci ke partisi tertentu. Dalam Kafka, partitioner adalah logika kode yang menentukan ke partisi mana sebuah pesan akan dikirim.

Default Partitioner Default partitioner Kafka menggunakan algoritma murmur2 untuk menghitung hash kunci, dengan formula berikut:

targetPartition = Math.abs(Utils.murmur2(keyBytes)) % (numPartitions - 1)

Formula ini memastikan bahwa pesan dengan kunci yang sama selalu dikirim ke partisi yang sama.

Meskipun dimungkinkan untuk mengganti default partitioner melalui properti produser partitioner.class, hal ini tidak disarankan kecuali Anda benar-benar memahami implikasinya, karena dapat memengaruhi distribusi data dan performa sistem.

Penambahan Penjelasan Serialisasi sangat penting untuk memastikan kompatibilitas data antara produser, broker, dan konsumer. Penggunaan format seperti Avro atau Protobuf melalui Confluent Schema Registry memungkinkan validasi skema dan evolusi skema yang lebih baik, sehingga meminimalkan risiko kesalahan data saat aplikasi diperbarui. Selain itu, pemilihan tipe kompresi seperti zstd dapat meningkatkan efisiensi penyimpanan dan transfer data, terutama untuk topik dengan volume pesan yang besar.

Konsumer Kafka dan Deserializer Pesan

Apa itu Konsumer Kafka?

Setelah topik dibuat dalam Apache Kafka dan data telah dimasukkan ke dalam topik tersebut, kita dapat mulai membangun aplikasi yang memanfaatkan aliran data (data stream) ini. Aplikasi yang mengambil data peristiwa (event data) dari satu atau lebih topik Kafka dikenal sebagai Konsumer Kafka.

Konsumer Kafka adalah aplikasi yang membaca data dari topik Kafka. Aplikasi ini mengintegrasikan pustaka klien Kafka (Kafka client library) untuk membaca data dari Apache Kafka. Pustaka klien yang andal tersedia untuk hampir semua bahasa pemrograman populer saat ini, seperti Python, Java, Go, dan lainnya.

Konsumer dapat membaca data dari satu atau lebih partisi dalam Kafka, dan data dibaca secara berurutan dalam setiap partisi, seperti yang ditunjukkan pada diagram (disesuaikan dengan penjelasan teks). Konsumer selalu membaca data dari offset yang lebih rendah ke offset yang lebih tinggi dan tidak dapat membaca data secara mundur karena cara implementasi Apache Kafka dan kliennya.

Jika konsumer membaca data dari lebih dari satu partisi, urutan pesan tidak dijamin antar-partisi karena data dari beberapa partisi dikonsumsi secara bersamaan. Namun, urutan pembacaan pesan tetap dijamin dalam setiap partisi secara individual.

Secara default, konsumer Kafka hanya akan mengonsumsi data yang diproduksi setelah konsumer pertama kali terhubung ke Kafka. Untuk membaca data historis, kita perlu menentukan parameter tertentu dalam perintah, yang akan dibahas lebih lanjut pada bagian praktik.

Model Pull pada Konsumer Kafka Konsumer Kafka menerapkan model pull, yang berarti konsumer harus secara aktif meminta data dari broker Kafka untuk mendapatkannya, bukan menerima data yang dikirim secara terus-menerus oleh broker (push model). Implementasi ini memungkinkan konsumer untuk mengontrol kecepatan konsumsi data dari topik, sehingga mencegah kelebihan beban pada aplikasi konsumer.

Deserializer Pesan Kafka

Serialisasi dan Deserialisasi Data yang dikonsumsi harus dideserialisasi dalam format yang sama seperti saat diserialisasi.

Seperti yang telah dijelaskan sebelumnya, data yang dikirim oleh produser Kafka diserialisasi ke dalam format biner. Oleh karena itu, data yang diterima oleh konsumer Kafka harus dideserialisasi dengan benar agar dapat digunakan dalam aplikasi. Format deserialisasi harus sesuai dengan format serialisasi yang digunakan oleh produser. Contohnya:

  • Jika produser menggunakan StringSerializer untuk menserialisasi data bertipe String, konsumer harus menggunakan StringDeserializer untuk mendeserialisasinya.

  • Jika produser menggunakan IntegerSerializer untuk menserialisasi data bertipe Integer, konsumer harus menggunakan IntegerDeserializer.

Pentingnya Konsistensi Format Format serialisasi dan deserialisasi sebuah topik tidak boleh berubah selama siklus hidup topik. Jika Anda berencana mengubah format data topik (misalnya, dari JSON ke Avro), praktik terbaik adalah membuat topik baru dan memigrasikan aplikasi Anda untuk menggunakan topik tersebut. Hal ini mencegah masalah kompatibilitas dan memastikan kelancaran pemrosesan data.

Poison Pills Pesan yang dikirim ke topik Kafka tetapi tidak sesuai dengan format serialisasi yang disepakati disebut poison pills. Pesan ini dapat menyebabkan masalah serius, seperti kegagalan deserialisasi yang mengakibatkan crash aplikasi atau data yang tidak konsisten pada aplikasi pemrosesan lanjutan (downstream). Debugging masalah ini bisa sangat sulit, sehingga penting untuk mempertimbangkan format serialisasi dengan cermat sejak awal pengembangan kode.

Penambahan Penjelasan

Untuk memperjelas, penggunaan Confluent Schema Registry sangat disarankan dalam lingkungan produksi untuk mengelola skema serialisasi (seperti Avro atau Protobuf). Schema Registry membantu memastikan bahwa produser dan konsumer menggunakan format data yang kompatibel dan mendukung evolusi skema tanpa mengganggu aplikasi yang sudah berjalan. Selain itu, model pull pada konsumer Kafka memungkinkan skalabilitas yang lebih baik, karena beberapa konsumer dalam consumer group dapat membaca partisi yang berbeda secara paralel, meningkatkan throughput sistem.

Penting juga untuk memahami bahwa konsumer dapat dikonfigurasi untuk memulai pembacaan dari offset tertentu, seperti offset paling awal (earliest), offset terbaru (latest), atau offset spesifik. Konfigurasi ini memberikan fleksibilitas dalam menangani kebutuhan aplikasi, misalnya untuk memproses ulang data historis atau hanya memproses data baru.

Grup Konsumer Kafka dan Offset Konsumer

Apa itu Grup Konsumer Kafka?

Konsumer Kafka dapat membaca data dari partisi topik secara individual, tetapi untuk tujuan skalabilitas horizontal, disarankan untuk mengonsumsi topik Kafka sebagai sebuah grup. Konsumer yang merupakan bagian dari aplikasi yang sama dan melakukan "pekerjaan logis" yang sama dapat dikelompokkan ke dalam Grup Konsumer Kafka.

Topik Kafka biasanya terdiri dari beberapa partisi, yang menjadi unit paralelisme bagi konsumer. Manfaat dari penggunaan grup konsumer adalah bahwa konsumer dalam grup akan berkoordinasi untuk membagi tugas membaca data dari partisi yang berbeda, sehingga meningkatkan efisiensi dan skalabilitas.

ID Grup Konsumer Untuk menunjukkan bahwa konsumer merupakan bagian dari grup tertentu, kita harus menentukan pengaturan sisi konsumer yaitu group.id. Konsumer Kafka secara otomatis menggunakan GroupCoordinator dan ConsumerCoordinator untuk menetapkan konsumer ke partisi tertentu dan memastikan keseimbangan beban (load balancing) tercapai di antara semua konsumer dalam grup yang sama.

Penting untuk dicatat bahwa setiap partisi topik hanya ditetapkan ke satu konsumer dalam grup konsumer, tetapi satu konsumer dalam grup dapat ditetapkan ke beberapa partisi. Sebagai contoh, dalam sebuah grup konsumer bernama consumer-group-application-1:

  • Konsumer 1 ditetapkan ke Partisi 0 dan Partisi 1.

  • Konsumer 2 ditetapkan ke Partisi 2 dan Partisi 3.

  • Konsumer 3 ditetapkan ke Partisi 4.

Hanya Konsumer 1 yang menerima pesan dari Partisi 0 dan 1, Konsumer 2 dari Partisi 2 dan 3, dan Konsumer 3 dari Partisi 4.

Setiap aplikasi yang membaca dari topik Kafka (yang mungkin terdiri dari banyak konsumer) harus memiliki group.id yang berbeda. Ini memungkinkan beberapa aplikasi (grup konsumer) untuk mengonsumsi data dari topik yang sama secara bersamaan.

Konsumer Lebih Banyak dari Partisi Jika jumlah konsumer dalam grup melebihi jumlah partisi topik, beberapa konsumer akan tetap tidak aktif. Biasanya, jumlah konsumer dalam grup konsumer disesuaikan dengan jumlah partisi. Jika diperlukan lebih banyak konsumer untuk meningkatkan throughput, jumlah partisi harus ditambah saat topik dibuat. Jika tidak, beberapa konsumer mungkin tidak mendapatkan tugas dan tetap tidak aktif.

Offset Konsumer Kafka

Broker Kafka menggunakan topik internal bernama __consumer_offsets untuk melacak pesan terakhir yang berhasil diproses oleh grup konsumer tertentu. Seperti yang telah kita ketahui, setiap pesan dalam topik Kafka memiliki ID partisi dan ID offset.

Untuk mencatat sejauh mana konsumer telah membaca data dalam partisi topik, konsumer secara berkala akan commit (merekam) offset terbaru dari pesan yang telah diproses, yang dikenal sebagai offset konsumer. Misalnya, jika konsumer dari grup konsumer telah mengonsumsi pesan hingga offset 4262, maka offset konsumer akan diatur ke 4262.

Sebagian besar pustaka klien Kafka secara otomatis melakukan commit offset secara berkala ke Kafka, dan broker Kafka yang bertanggung jawab akan memastikan penulisan ke topik __consumer_offsets (konsumer tidak menulis langsung ke topik ini). Proses commit offset tidak dilakukan untuk setiap pesan yang dikonsumsi karena ini akan tidak efisien, melainkan dilakukan secara berkala.

Ketika sebuah offset dikomit, semua pesan sebelumnya dengan offset yang lebih rendah juga dianggap telah dikomit.

Mengapa Offset Konsumer Penting? Offset konsumer sangat penting untuk banyak aplikasi. Jika klien Kafka mengalami kegagalan (crash), terjadi rebalance dalam grup konsumer, dan offset terbaru yang telah dikomit membantu konsumer yang tersisa untuk mengetahui dari mana harus melanjutkan membaca dan memproses pesan. Jika konsumer baru ditambahkan ke grup, rebalance grup konsumer akan terjadi, dan offset konsumer kembali digunakan untuk memberi tahu konsumer dari mana harus mulai membaca data.

Oleh karena itu, offset konsumer harus dikomit secara teratur untuk memastikan kelangsungan pemrosesan data.

Semantik Pengiriman untuk Konsumer

Secara default, konsumer Java secara otomatis melakukan commit offset (dengan properti enable.auto.commit=true) setiap auto.commit.interval.ms (default 5 detik) saat metode .poll() dipanggil. Detail mekanisme ini dibahas dalam Semantik Pengiriman untuk Konsumer.

Konsumer dapat memilih untuk melakukan commit offset secara manual (dengan enable.auto.commit=false). Tergantung pada kapan offset dikomit, terdapat tiga semantik pengiriman yang tersedia untuk konsumer:

  • At Most Once (Paling Banyak Sekali): Offset dikomit segera setelah pesan diterima. Jika pemrosesan gagal, pesan tersebut akan hilang dan tidak akan dibaca lagi.

  • At Least Once (Setidaknya Sekali, Biasanya Dipilih): Offset dikomit setelah pesan selesai diproses. Jika pemrosesan gagal, pesan akan dibaca ulang, yang dapat menyebabkan pemrosesan duplikat. Oleh karena itu, praktik terbaik adalah memastikan pemrosesan data bersifat idempotent (yaitu, memproses pesan yang sama dua kali tidak menghasilkan efek yang tidak diinginkan).

  • Exactly Once (Tepat Sekali): Semantik ini hanya dapat dicapai untuk alur kerja dari topik Kafka ke topik Kafka menggunakan Transactions API. Kafka Streams API menyederhanakan penggunaan API ini dengan pengaturan processing.guarantee=exactly_once_v2 (atau exactly_once untuk Kafka versi < 2.5). Untuk alur kerja dari topik Kafka ke sistem eksternal, exactly once dapat dicapai secara efektif dengan menggunakan konsumer yang bersifat idempotent.

Dalam praktiknya, semantik at least once dengan pemrosesan idempotent adalah mekanisme yang paling diinginkan dan banyak diimplementasikan untuk konsumer Kafka.

Penambahan Penjelasan

Untuk memperjelas, penggunaan grup konsumer memungkinkan distribusi beban yang efisien di antara konsumer, sehingga meningkatkan skalabilitas dan ketahanan sistem. Rebalance dalam grup konsumer terjadi ketika konsumer baru ditambahkan, konsumer keluar, atau saat topik mengalami perubahan (misalnya, penambahan partisi). Selama rebalance, GroupCoordinator memastikan bahwa partisi didistribusikan ulang secara adil di antara konsumer yang tersedia.

Selain itu, penting untuk memahami bahwa topik __consumer_offsets adalah topik internal yang dikelola oleh Kafka dan tidak boleh dimodifikasi secara manual. Pengaturan seperti offset.retention.minutes dapat digunakan untuk mengontrol berapa lama offset disimpan, yang berguna untuk mencegah kehilangan data saat konsumer offline untuk waktu yang lama.

Semantik exactly once sangat penting untuk aplikasi yang tidak boleh kehilangan data atau memproses data duplikat, seperti sistem keuangan. Namun, implementasinya lebih kompleks dan memerlukan konfigurasi tambahan, seperti penggunaan Transactions API atau sistem eksternal yang mendukung idempotency.

Broker Kafka

Apa itu Broker Kafka?

Broker Kafka adalah sebuah server tunggal yang menjalankan program Apache Kafka. Program ini berjalan di atas Java Virtual Machine (JVM, versi Java 11 atau lebih tinggi). Biasanya, server yang ditujukan sebagai broker Kafka hanya menjalankan program Kafka tanpa aplikasi lain untuk memastikan performa optimal.

Apa itu Klaster Kafka?

Kumpulan beberapa broker Kafka yang bekerja bersama disebut Klaster Kafka. Sebuah klaster dapat terdiri dari hanya satu broker, tiga broker, atau bahkan ratusan broker, tergantung pada kebutuhan aplikasi. Perusahaan besar seperti Netflix dan Uber mengoperasikan ratusan hingga ribuan broker Kafka untuk menangani volume data yang sangat besar.

Setiap broker dalam klaster diidentifikasi dengan ID numerik yang unik. Sebagai contoh, sebuah klaster Kafka dapat terdiri dari tiga broker, seperti yang ditunjukkan pada diagram (disesuaikan dengan penjelasan teks).

Broker Kafka dan Topik

Broker Kafka menyimpan data dalam direktori pada disk server tempat mereka berjalan. Setiap partisi topik memiliki sub-direktori sendiri yang dinamai sesuai nama topik. Detail teknis tentang cara Kafka menyimpan data dibahas lebih lanjut pada bagian Kafka Topics Internals: Segments and Indexes.

Untuk mencapai throughput tinggi dan skalabilitas, topik Kafka dipartisi. Jika terdapat beberapa broker dalam klaster, partisi untuk topik tertentu akan didistribusikan secara merata di antara broker yang tersedia untuk mencapai keseimbangan beban (load balancing) dan skalabilitas.

Distribusi Partisi Sebagai contoh, sebuah topik bernama Topic-A dengan tiga partisi akan didistribusikan secara merata di antara tiga broker dalam klaster. Sebaliknya, Topic-B dengan hanya dua partisi mungkin hanya tersimpan di dua broker, sehingga broker ketiga tidak memiliki partisi dari Topic-B. Tidak ada hubungan langsung antara ID broker dan ID partisi; Kafka secara otomatis mendistribusikan partisi secara merata di antara broker yang tersedia.

Jika klaster menjadi tidak seimbang karena beban berlebih pada broker tertentu, administrator Kafka dapat melakukan rebalance klaster untuk memindahkan partisi antar broker, memastikan distribusi beban yang optimal.

Catatan tentang Replikasi Penempatan partisi pada broker saat topik direplikasi akan dibahas lebih lanjut pada bagian berikutnya.

Bagaimana Klien Terhubung ke Klaster Kafka (Bootstrap Server)?

Klien yang ingin mengirim atau menerima pesan dari klaster Kafka dapat terhubung ke salah satu broker dalam klaster. Setiap broker dalam klaster memiliki metadata tentang semua broker lain dan akan membantu klien untuk terhubung ke broker yang sesuai. Oleh karena itu, setiap broker dalam klaster juga disebut bootstrap server.

Bootstrap server akan mengembalikan metadata ke klien, yang berisi daftar semua broker dalam klaster. Dengan informasi ini, klien dapat mengetahui broker mana yang harus dihubungi untuk mengirim atau menerima data, serta menemukan broker yang menyimpan partisi topik yang relevan.

Praktik Terbaik untuk Koneksi Dalam praktiknya, klien Kafka biasanya merujuk setidaknya dua bootstrap server dalam URL koneksi mereka. Hal ini dilakukan untuk mengantisipasi jika salah satu server tidak tersedia, server lain masih dapat menanggapi permintaan koneksi. Dengan demikian, klien Kafka (dan pengembang atau tim DevOps) tidak perlu mengetahui nama host setiap broker dalam klaster, tetapi hanya perlu merujuk dua atau tiga bootstrap server dalam string koneksi.

Penambahan Penjelasan

Untuk memperjelas, distribusi partisi antar broker tidak hanya bertujuan untuk keseimbangan beban, tetapi juga untuk meningkatkan ketahanan sistem (fault tolerance). Jika sebuah broker gagal, partisi yang direplikasi pada broker lain dapat mengambil alih, memastikan data tetap tersedia. Metadata yang disediakan oleh bootstrap server juga mencakup informasi tentang replika partisi, yang memungkinkan klien untuk secara otomatis beralih ke broker lain jika terjadi kegagalan.

Selain itu, pengaturan jumlah broker dalam klaster harus mempertimbangkan kebutuhan aplikasi, seperti volume data, throughput, dan latensi. Untuk klaster besar, alat seperti Kafka Controller digunakan untuk mengelola metadata dan koordinasi antar broker, memastikan operasi klaster berjalan lancar. Penting juga untuk memastikan bahwa server yang menjalankan broker Kafka memiliki sumber daya yang memadai (CPU, memori, dan disk) untuk menangani beban kerja yang diharapkan.

Replikasi Topik Kafka

Apa itu Replikasi Topik Kafka?

Salah satu alasan utama popularitas Apache Kafka adalah ketahanannya terhadap kegagalan broker. Kegagalan mesin tidak dapat selalu diprediksi atau dicegah, tetapi Kafka dirancang dengan replikasi sebagai fitur inti untuk menangani kegagalan ini sambil menjaga waktu aktif (uptime) dan akurasi data.

Faktor Replikasi Topik Kafka Replikasi data membantu mencegah kehilangan data dengan menulis data yang sama ke lebih dari satu broker. Dalam Kafka, replikasi berarti data tidak hanya ditulis ke satu broker, tetapi ke beberapa broker. Faktor replikasi adalah pengaturan topik yang ditentukan saat topik dibuat:

  • Faktor replikasi 1: Tidak ada replikasi. Ini biasanya digunakan untuk keperluan pengembangan dan sebaiknya dihindari di lingkungan pengujian atau produksi.

  • Faktor replikasi 3: Merupakan pilihan yang umum digunakan karena memberikan keseimbangan antara ketahanan terhadap kehilangan broker dan overhead replikasi.

Sebagai contoh, dalam klaster dengan tiga broker dan faktor replikasi 2, ketika pesan ditulis ke Partisi 0 dari Topic-A di Broker 101, pesan tersebut juga ditulis ke Broker 102 yang memiliki replika Partisi 0. Dengan faktor replikasi 2, klaster dapat menahan kegagalan satu broker tanpa kehilangan data. Jika Broker 102 gagal, Broker 101 dan 103 masih memiliki data yang tersedia.

Pemimpin Partisi dan Replika

Untuk setiap partisi topik, satu broker Kafka ditunjuk oleh klaster sebagai penanggung jawab untuk mengirim dan menerima data dari klien. Broker ini disebut pemimpin (leader) untuk partisi tersebut. Broker lain yang menyimpan data replika untuk partisi tersebut disebut replika. Dengan demikian, setiap partisi memiliki satu pemimpin dan beberapa replika.

Replika Sinkron (In-Sync Replicas atau ISR) ISR adalah replika yang selalu sinkron dengan pemimpin untuk sebuah partisi. Replika yang tidak sinkron dengan pemimpin dianggap out-of-sync. Jika broker pemimpin gagal, salah satu replika ISR akan dipilih sebagai pemimpin baru melalui proses pemilihan (election).

Pengaturan Acks Produser Kafka

Produser Kafka hanya menulis data ke broker pemimpin saat ini untuk sebuah partisi. Produser juga harus menentukan tingkat pengakuan (acknowledgment atau acks) untuk menentukan apakah pesan dianggap berhasil ditulis berdasarkan jumlah replika yang mengonfirmasi penulisan.

Nilai Default Acks pada Kafka v3.0 Nilai default acks telah berubah mulai Kafka versi 3.0:

  • Untuk Kafka < v3.0: acks=1

  • Untuk Kafka ≥ v3.0: acks=all

Berikut adalah penjelasan untuk setiap opsi acks:

  • acks=0: Produser menganggap pesan "berhasil ditulis" segera setelah pesan dikirim, tanpa menunggu konfirmasi dari broker. Jika broker tidak aktif atau terjadi pengecualian, data akan hilang tanpa sepengetahuan produser. Opsi ini cocok untuk data yang boleh hilang, seperti pengumpulan metrik, dan memberikan throughput tertinggi karena overhead jaringan minimal.

  • acks=1: Produser menganggap pesan "berhasil ditulis" ketika pesan dikonfirmasi oleh pemimpin saja. Replikasi dilakukan di latar belakang dan tidak dijamin. Jika pemimpin gagal sebelum replika menyalin data, data dapat hilang. Jika konfirmasi tidak diterima, produser dapat mencoba ulang.

  • acks=all: Produser menganggap pesan "berhasil ditulis" ketika pesan diterima oleh semua replika sinkron (ISR). Pemimpin memeriksa apakah ada cukup ISR untuk menulis pesan dengan aman, yang dikontrol oleh pengaturan broker min.insync.replicas. Pesan dianggap committed ketika ditulis ke semua ISR sesuai dengan nilai min.insync.replicas.

Pengaturan min.insync.replicas Pengaturan min.insync.replicas dapat dikonfigurasi pada level topik atau broker. Misalnya, nilai 2 berarti setidaknya dua broker ISR (termasuk pemimpin) harus mengonfirmasi bahwa mereka memiliki data. Jika sebuah topik memiliki tiga replika dan min.insync.replicas diatur ke 2, penulisan hanya dapat dilakukan jika setidaknya dua dari tiga replika sinkron. Jika dua replika tidak tersedia, produser akan menerima pengecualian NotEnoughReplicasException.

Ketahanan dan Ketersediaan Data Topik

Ketahanan Data (Durability) Untuk faktor replikasi N, klaster dapat menahan kehilangan hingga N-1 broker tanpa kehilangan data. Misalnya, dengan faktor replikasi 3, klaster dapat menahan kehilangan dua broker.

Ketersediaan (Availability) Ketersediaan bergantung pada pengaturan acks dan min.insync.replicas. Untuk faktor replikasi 3:

  • Pembacaan (Reads): Selama satu partisi masih aktif dan dianggap ISR, topik tetap tersedia untuk dibaca.

  • Penulisan (Writes):

    • acks=0 atau acks=1: Selama satu partisi aktif dan dianggap ISR, topik tetap tersedia untuk penulisan.

    • acks=all:

      • min.insync.replicas=1 (default): Topik memerlukan setidaknya satu ISR aktif (termasuk pemimpin), sehingga dapat menahan dua broker mati.

      • min.insync.replicas=2: Topik memerlukan setidaknya dua ISR aktif, sehingga hanya dapat menahan satu broker mati, dengan jaminan data ditulis setidaknya dua kali.

      • min.insync.replicas=3: Tidak praktis untuk faktor replikasi 3 karena tidak dapat menahan kegagalan broker.

      • Secara umum, dengan acks=all, faktor replikasi N, dan min.insync.replicas=M, klaster dapat menahan N-M broker mati untuk tujuan ketersediaan topik.

Pengaturan Populer Kombinasi acks=all dan min.insync.replicas=2 adalah pilihan paling populer untuk ketahanan dan ketersediaan data, memungkinkan klaster menahan kehilangan satu broker Kafka.

Pembacaan Konsumer dari Replika

Secara default, konsumer Kafka membaca dari pemimpin partisi. Namun, sejak Apache Kafka versi 2.4, konsumer dapat dikonfigurasi untuk membaca dari replika sinkron (ISR) terdekat. Membaca dari ISR terdekat dapat meningkatkan latensi permintaan dan mengurangi biaya jaringan, terutama di lingkungan cloud di mana permintaan lintas-pusat data sering dikenakan biaya.

Pemimpin Pilihan (Preferred Leader) dan Pemilihan Pemimpin

Pemimpin pilihan (preferred leader) adalah broker yang ditunjuk sebagai pemimpin untuk sebuah partisi saat topik dibuat (berbeda dengan replika). Proses penentuan pemimpin saat pembuatan topik disebut pemilihan pemimpin pilihan (preferred leader election).

Jika pemimpin pilihan gagal, partisi yang merupakan ISR dapat dipilih sebagai pemimpin baru (tetapi bukan pemimpin pilihan). Ketika pemimpin pilihan pulih dan data partisinya kembali sinkron, pemimpin pilihan akan mengambil kembali peran kepemimpinan untuk partisi tersebut.

Penambahan Penjelasan

Untuk memperjelas, replikasi di Kafka tidak hanya tentang ketahanan data, tetapi juga tentang keseimbangan antara performa dan keandalan. Pengaturan seperti min.insync.replicas memungkinkan administrator untuk menyesuaikan tingkat keandalan dengan kebutuhan aplikasi. Namun, nilai yang terlalu tinggi dapat mengurangi ketersediaan jika banyak replika tidak sinkron.

Pemilihan pemimpin dikoordinasikan oleh Kafka Controller, sebuah komponen dalam klaster yang mengelola metadata dan memastikan konsistensi. Dalam lingkungan produksi, penting untuk memantau kesehatan ISR menggunakan alat seperti Kafka AdminClient atau metrik yang disediakan oleh Kafka untuk mendeteksi replika yang out-of-sync dan mencegah potensi masalah.

Selain itu, membaca dari ISR terdekat (fitur sejak Kafka 2.4) sangat berguna di klaster yang tersebar secara geografis, tetapi memerlukan konfigurasi tambahan seperti pengaturan rack awareness untuk memastikan konsumer terhubung ke replika yang optimal berdasarkan lokasi.

Peran Zookeeper dalam Klaster Kafka

Apa itu Zookeeper dalam Kafka?

Zookeeper adalah komponen yang digunakan dalam Apache Kafka untuk mengelola metadata dan status klaster. Zookeeper bertugas melacak informasi penting seperti keanggotaan klaster, kepemimpinan (leadership), dan konfigurasi sistem. Dengan kata lain, Zookeeper membantu menjaga koordinasi dan konsistensi dalam klaster Kafka.

Apa yang Dilakukan Zookeeper dalam Kafka?

Jika sebuah klaster Kafka memiliki lebih dari satu broker, bagaimana broker dan klien Kafka melacak semua broker tersebut? Tim Kafka memilih Zookeeper untuk menangani tugas ini. Berikut adalah beberapa fungsi utama Zookeeper dalam Kafka:

  • Melacak Broker dalam Klaster: Zookeeper mencatat broker mana saja yang menjadi bagian dari klaster Kafka.

  • Pemilihan Pemimpin Partisi: Zookeeper digunakan oleh broker Kafka untuk menentukan broker mana yang menjadi pemimpin (leader) untuk topik dan partisi tertentu, serta melakukan pemilihan pemimpin (leader election) jika diperlukan.

  • Penyimpanan Konfigurasi: Zookeeper menyimpan konfigurasi untuk topik (seperti faktor replikasi atau retensi data) dan izin akses (permissions).

  • Notifikasi Perubahan: Zookeeper mengirimkan pemberitahuan ke Kafka ketika terjadi perubahan, seperti pembuatan topik baru, broker mati, broker kembali aktif, atau penghapusan topik.

Catatan tentang Offset Konsumer: Sejak Kafka versi 0.10, offset konsumer tidak lagi disimpan di Zookeeper. Sebaliknya, offset disimpan dalam topik internal Kafka bernama __consumer_offsets. Konsumer tidak perlu terhubung langsung ke Zookeeper, dan opsi untuk melakukannya telah ditandai sebagai usang (deprecated).

Klaster Zookeeper (Ensemble)

Klaster Zookeeper disebut ensemble. Disarankan untuk mengoperasikan ensemble dengan jumlah server ganjil, seperti 3, 5, atau 7. Hal ini karena Zookeeper memerlukan mayoritas ketat (quorum) dari anggota ensemble untuk dapat menanggapi permintaan. Dalam ensemble, satu server bertindak sebagai pemimpin (leader) untuk menangani operasi tulis (write), sementara server lainnya bertindak sebagai pengikut (follower) untuk menangani operasi baca (read).

Penghapusan Zookeeper dari Kafka

Informasi Penting tentang Zookeeper dan Kafka:

  1. Kafka versi 0.x, 1.x, dan 2.x harus menggunakan Zookeeper.

  2. Kafka versi 3.x mendukung operasi tanpa Zookeeper melalui KIP-500 (Kafka Improvement Proposal 500), tetapi belum siap untuk lingkungan produksi.

  3. Kafka versi 4.x tidak akan menggunakan Zookeeper sama sekali.

Penghapusan Zookeeper dari Kafka bertujuan untuk menyederhanakan arsitektur, meningkatkan skalabilitas, dan mengurangi ketergantungan pada sistem eksternal.

Haruskah Zookeeper Digunakan dengan Broker Kafka?

Selama Kafka tanpa Zookeeper belum siap untuk produksi (seperti pada Kafka 3.x), Anda harus menggunakan Zookeeper dalam penerapan produksi untuk Apache Kafka. Zookeeper masih diperlukan untuk mengelola metadata dan koordinasi klaster dengan andal.

Haruskah Zookeeper Digunakan dengan Klien Kafka?

Seiring waktu, klien Kafka dan perintah CLI (Command Line Interface) telah dimigrasikan untuk menggunakan broker Kafka sebagai titik koneksi, bukan Zookeeper. Berikut adalah beberapa poin penting:

  • Sejak Kafka 0.10: Konsumer menyimpan offset di topik __consumer_offsets di Kafka, bukan di Zookeeper. Koneksi langsung konsumer ke Zookeeper telah usang.

  • Sejak Kafka 2.2: Perintah CLI seperti kafka-topics.sh menggunakan broker Kafka untuk mengelola topik (pembuatan, penghapusan, dll.), dan argumen CLI untuk Zookeeper telah usang.

  • Semua API dan perintah yang sebelumnya bergantung pada Zookeeper telah dimigrasikan untuk menggunakan Kafka, sehingga perubahan ke klaster tanpa Zookeeper tidak terlihat oleh klien.

  • Keamanan: Zookeeper kurang aman dibandingkan Kafka. Oleh karena itu, port Zookeeper hanya boleh dibuka untuk lalu lintas dari broker Kafka, bukan dari klien Kafka.

Praktik Terbaik untuk Pengembang Kafka Modern: Jangan pernah menggunakan Zookeeper sebagai konfigurasi dalam klien Kafka atau program lain yang terhubung ke Kafka. Sebaliknya, selalu gunakan broker Kafka sebagai titik koneksi untuk memastikan kompatibilitas dengan versi Kafka mendatang yang tidak lagi menggunakan Zookeeper.

Penambahan Penjelasan

Untuk memperjelas, Zookeeper berperan sebagai "otak" koordinasi dalam klaster Kafka pada versi yang masih membutuhkannya. Namun, ketergantungan pada Zookeeper memiliki kelemahan, seperti kompleksitas tambahan dalam pengelolaan dan potensi titik kegagalan jika ensemble Zookeeper tidak dikonfigurasi dengan benar. Inilah mengapa KIP-500 diperkenalkan untuk menggantikan Zookeeper dengan mekanisme pengelolaan metadata internal berbasis Raft (disebut KRaft) pada Kafka.

Dalam lingkungan produksi, ensemble Zookeeper harus dipantau dengan cermat untuk memastikan ketersediaan dan performa. Alat seperti ZooNavigator atau metrik Zookeeper dapat membantu administrator memantau kesehatan ensemble. Selain itu, pengaturan seperti waktu tick dan syncLimit pada Zookeeper perlu dioptimalkan untuk memastikan respons yang cepat terhadap perubahan dalam klaster Kafka.

Saat bermigrasi ke Kafka tanpa Zookeeper (misalnya, pada Kafka 4.x), penting untuk memastikan bahwa semua klien dan alat sudah menggunakan broker sebagai titik koneksi untuk menghindari masalah kompatibilitas. Penggunaan KRaft di masa depan akan membuat pengelolaan klaster Kafka lebih sederhana dan lebih terintegrasi, mengurangi kebutuhan untuk mengelola sistem eksternal seperti Zookeeper.

Mode KRaft Kafka: Apache Kafka Tanpa Zookeeper

Pengenalan Mode KRaft

Proyek Apache Kafka mengalami salah satu perubahan terbesarnya dengan diperkenalkannya Kafka Improvement Proposal (KIP-500) pada 1 Agustus 2019, yang bertujuan untuk menghapus ketergantungan pada Zookeeper dalam menjalankan Apache Kafka. Perubahan ini menandai langkah besar untuk meningkatkan skalabilitas, stabilitas, dan kemudahan pengelolaan klaster Kafka.

Mengapa Menghapus Zookeeper dari Kafka?

Ketergantungan Kafka pada Zookeeper telah menciptakan beberapa keterbatasan yang menghambat performa dan skalabilitas sistem. Berikut adalah beberapa masalah utama yang dihadapi Kafka saat menggunakan Zookeeper:

  • Batasan Jumlah Partisi: Klaster Kafka hanya mendukung hingga 200.000 partisi, yang menjadi hambatan untuk aplikasi dengan kebutuhan data besar.

  • Pemilihan Pemimpin (Leader Election): Ketika broker Kafka bergabung atau keluar dari klaster, banyak pemilihan pemimpin harus dilakukan, yang dapat membebani Zookeeper dan memperlambat klaster sementara.

  • Kompleksitas Pengaturan: Pengaturan klaster Kafka bergantung pada komponen eksternal (Zookeeper), yang meningkatkan kompleksitas penerapan.

  • Metadata Tidak Sinkron: Metadata klaster Kafka terkadang tidak sinkron dengan Zookeeper, menyebabkan inkonsistensi.

  • Keamanan Zookeeper: Keamanan Zookeeper tertinggal dibandingkan dengan keamanan Kafka, menciptakan potensi kerentanan.

Apa itu Mode KRaft Kafka?

KIP-500 mencatat bahwa metadata Kafka pada dasarnya adalah log, dan broker Kafka seharusnya dapat mengonsumsi log metadata ini sebagai topik metadata internal. Dengan kata lain, Kafka memanfaatkan dirinya sendiri untuk mengelola metadata, menghilangkan kebutuhan akan Zookeeper.

Untuk tetap berfungsi sebagai quorum dalam melakukan pemilihan pengontrol (controller election), broker Kafka mengimplementasikan protokol Raft (Reliable, Replicated, Redundant, And Fault-Tolerant). Implementasi ini dinamakan KRaft (Kafka Raft), yang merujuk pada mode Kafka Metadata Quorum baru.

Manfaat Mode KRaft Dengan menghapus Zookeeper, Kafka di mode KRaft menawarkan sejumlah keunggulan berikut:

  • Skalabilitas Lebih Tinggi: Mendukung jutaan partisi, memudahkan pemeliharaan dan pengaturan klaster.

  • Stabilitas yang Lebih Baik: Lebih mudah dipantau, didukung, dan dikelola.

  • Proses Tunggal: Kafka dapat dijalankan sebagai satu proses, menyederhanakan penerapan.

  • Model Keamanan Terpadu: Satu model keamanan untuk seluruh sistem, mengurangi kerumitan.

  • Pemulihan Lebih Cepat: Waktu shutdown dan pemulihan pengontrol lebih cepat.

Status dan Ketersediaan KRaft

Mode KRaft resmi dirilis pada Kafka versi 3.3 dan kini telah siap untuk lingkungan produksi. Informasi lebih lanjut tentang perubahan ini dapat ditemukan di dokumentasi resmi Kafka atau blog Confluent yang menjelaskan manfaat KRaft. Tutorial awal untuk menjalankan KRaft tersedia untuk platform Windows, Mac, dan Linux.

Penambahan Penjelasan

Untuk memperjelas, mode KRaft menggantikan peran Zookeeper dengan mengintegrasikan pengelolaan metadata langsung ke dalam broker Kafka. Protokol Raft memastikan konsensus yang andal di antara broker, memungkinkan klaster untuk tetap beroperasi bahkan jika beberapa broker gagal, selama quorum (mayoritas broker) tetap tersedia.

Dalam mode KRaft, broker Kafka dibagi menjadi dua peran: controller dan broker. Controller bertanggung jawab atas pengelolaan metadata, seperti pemilihan pemimpin partisi dan koordinasi klaster, sementara broker menangani penyimpanan dan pemrosesan data. Beberapa broker dapat dikonfigurasi sebagai controller-eligible, memungkinkan pemilihan controller baru jika controller saat ini gagal.

Transisi ke KRaft Bagi pengguna yang bermigrasi dari klaster Kafka berbasis Zookeeper ke KRaft, penting untuk memperhatikan kompatibilitas. Kafka versi 3.x mendukung mode transisi yang memungkinkan klaster berjalan dengan Zookeeper sambil mempersiapkan migrasi ke KRaft. Namun, mulai Kafka versi 4.x, Zookeeper akan dihapus sepenuhnya, sehingga semua klaster harus menggunakan KRaft.

Pertimbangan Produksi Meskipun KRaft telah siap produksi sejak Kafka 3.3, pengujian menyeluruh di lingkungan non-produksi sangat disarankan sebelum diterapkan di lingkungan kritis. Pemantauan metrik seperti latensi controller dan kesehatan quorum penting untuk memastikan stabilitas klaster. Selain itu, karena KRaft menghilangkan ketergantungan pada sistem eksternal, administrasi klaster menjadi lebih sederhana, tetapi memerlukan pemahaman tentang konfigurasi baru seperti controller.quorum.voters untuk menentukan broker yang berpartisipasi dalam quorum.

Mode KRaft menandai langkah besar menuju Kafka yang lebih modern, efisien, dan mandiri, memungkinkan organisasi untuk menangani beban kerja data yang lebih besar dengan pengelolaan yang lebih mudah.

Apa itu In-Sync Replica (ISR) di Apache Kafka?

Dalam Apache Kafka, In-Sync Replica (ISR) adalah sekumpulan replika partisi yang selalu sinkron dengan pemimpin (leader) partisi tersebut. Pemimpin adalah broker yang bertanggung jawab untuk menangani operasi baca dan tulis untuk partisi tertentu, sementara replika adalah salinan data partisi yang disimpan di broker lain untuk memastikan ketahanan data (durability) dan ketersediaan (availability).

Penjelasan Detail

  • Sinkron dengan Pemimpin: Sebuah replika dianggap in-sync jika replika tersebut telah menyalin semua pesan hingga offset terbaru dari pemimpin dengan jeda waktu yang dapat diterima (dikonfigurasi oleh pengaturan seperti replica.lag.time.max.ms). Jika replika tertinggal terlalu jauh atau tidak dapat berkomunikasi dengan pemimpin, replika tersebut dianggap out-of-sync dan dikeluarkan dari daftar ISR.

  • Peran ISR: ISR memastikan bahwa data ditulis ke beberapa broker sebelum dianggap committed, tergantung pada pengaturan acks produser dan min.insync.replicas. Ini meningkatkan ketahanan data terhadap kegagalan broker.

    • Misalnya, jika acks=all dan min.insync.replicas=2, pesan hanya dianggap berhasil ditulis jika dikonfirmasi oleh pemimpin dan setidaknya satu replika ISR lainnya.

  • Pemilihan Pemimpin Baru: Jika broker pemimpin gagal, salah satu replika dalam ISR akan dipilih sebagai pemimpin baru melalui proses pemilihan (leader election). Hanya replika ISR yang memenuhi syarat untuk menjadi pemimpin, karena mereka memiliki data terbaru.

  • Keseimbangan Ketahanan dan Ketersediaan: ISR memungkinkan Kafka menyeimbangkan antara ketahanan data dan ketersediaan. Dengan menjaga replika yang sinkron, Kafka dapat menahan kegagalan broker tanpa kehilangan data, selama setidaknya satu ISR tetap aktif.

Contoh

Misalkan sebuah topik memiliki faktor replikasi 3, dengan satu pemimpin dan dua replika. Jika semua replika sinkron dengan pemimpin, maka ISR berisi ketiga broker tersebut. Jika salah satu replika tertinggal (misalnya, karena masalah jaringan), replika tersebut dikeluarkan dari ISR, sehingga ISR hanya berisi pemimpin dan satu replika yang masih sinkron. Jika pemimpin gagal, Kafka akan memilih pemimpin baru dari ISR yang tersisa.

Pengaturan Terkait ISR

  • min.insync.replicas: Menentukan jumlah minimum replika ISR (termasuk pemimpin) yang harus mengonfirmasi penulisan agar pesan dianggap berhasil. Misalnya, jika diatur ke 2, setidaknya dua broker harus sinkron untuk penulisan dengan acks=all.

  • replica.lag.time.max.ms: Batas waktu maksimum replika dianggap sinkron. Jika replika tidak mengejar offset pemimpin dalam waktu ini, replika tersebut dianggap out-of-sync.

  • acks (Produser):

    • acks=all: Memastikan pesan ditulis ke semua replika ISR sebelum dianggap berhasil.

    • acks=1: Hanya memerlukan konfirmasi dari pemimpin, tidak menjamin replika ISR.

    • acks=0: Tidak memerlukan konfirmasi, sehingga tidak melibatkan ISR.

Mengapa ISR Penting?

  • Ketahanan Data: ISR memastikan bahwa data tetap tersedia meskipun beberapa broker gagal, selama setidaknya satu ISR aktif.

  • Kinerja: Dengan hanya melibatkan replika yang sinkron, Kafka menghindari latensi yang disebabkan oleh replika yang lambat atau tidak responsif.

  • Ketersediaan: ISR memungkinkan Kafka untuk tetap beroperasi dengan replika yang sehat, bahkan jika beberapa replika out-of-sync.

Penambahan Penjelasan

Sejak Kafka 2.4, konsumer dapat dikonfigurasi untuk membaca dari replika ISR terdekat (bukan hanya pemimpin) untuk mengurangi latensi dan biaya jaringan, terutama di lingkungan cloud dengan klaster yang tersebar secara geografis. Selain itu, penting untuk memantau kesehatan ISR menggunakan metrik Kafka (misalnya, UnderReplicatedPartitions atau OfflinePartitions) untuk mendeteksi masalah seperti replika yang sering out-of-sync, yang dapat menunjukkan masalah jaringan atau performa broker.

Dalam mode KRaft (Kafka tanpa Zookeeper, mulai versi 3.3), pengelolaan ISR tetap dilakukan oleh controller Kafka, tetapi tanpa ketergantungan pada Zookeeper, sehingga prosesnya lebih terintegrasi dan efisien.

Penjelasan tentang "Danger: Increasing Partitions" dalam Apache Kafka

Peringatan ini merujuk pada risiko yang terkait dengan peningkatan jumlah partisi dalam topik Kafka, terutama jika aplikasi Anda bergantung pada pengurutan berbasis kunci (key-based ordering). Berikut adalah penjelasan rinci tentang maksud peringatan tersebut dan mengapa operasi ini dianggap berbahaya:

Latar Belakang

Dalam Apache Kafka, topik dibagi menjadi beberapa partisi untuk mendukung skalabilitas dan paralelisme. Setiap pesan dalam topik memiliki kunci (key) opsional yang digunakan untuk menentukan partisi tujuan melalui proses key hashing (biasanya menggunakan algoritma murmur2). Kafka menjamin urutan pesan hanya dalam satu partisi, bukan antar-partisi. Artinya, semua pesan dengan kunci yang sama akan selalu masuk ke partisi yang sama, sehingga urutan pesan untuk kunci tersebut terjaga.

Mengapa Meningkatkan Jumlah Partisi Berbahaya?

Ketika Anda meningkatkan jumlah partisi dalam sebuah topik (misalnya, dari 3 partisi menjadi 5 partisi), Kafka tidak secara otomatis mendistribusikan ulang data yang sudah ada di partisi sebelumnya. Data yang sudah ada akan tetap berada di partisi aslinya, tetapi pesan baru dengan kunci yang sama mungkin dialokasikan ke partisi yang berbeda karena perubahan jumlah partisi memengaruhi hasil key hashing. Hal ini menyebabkan masalah berikut:

  1. Gangguan pada Pengurutan Berbasis Kunci (Key-Based Ordering):

    • Jika aplikasi Anda bergantung pada urutan pesan untuk kunci tertentu (misalnya, memastikan semua pesan untuk truck_id_123 diproses secara berurutan), peningkatan jumlah partisi dapat menyebabkan pesan baru dengan kunci yang sama masuk ke partisi baru. Akibatnya, urutan pesan untuk kunci tersebut menjadi tidak konsisten, karena konsumer mungkin membaca dari partisi yang berbeda tanpa jaminan urutan antar-partisi.

    • Contoh: Jika awalnya topik memiliki 3 partisi dan semua pesan untuk truck_id_123 masuk ke Partisi 0, setelah menambah partisi menjadi 5, pesan baru untuk truck_id_123 mungkin masuk ke Partisi 4. Hal ini merusak urutan yang diharapkan oleh aplikasi.

  2. Inkonsistensi untuk Konsumer:

    • Konsumer yang bergantung pada pengurutan kunci akan melihat data lama di partisi asli (misalnya, Partisi 0) dan data baru di partisi baru (misalnya, Partisi 4). Ini dapat menyebabkan pemrosesan data yang salah atau duplikasi logika pemrosesan di sisi aplikasi.

  3. Tidak Ada Redistribusi Data Otomatis:

    • Kafka tidak memindahkan data yang sudah ada ke partisi baru saat jumlah partisi ditambah. Data lama tetap di partisi asli, yang dapat menyebabkan distribusi data tidak merata dan memengaruhi performa klaster.

Solusi yang Disarankan: Buat Topik Baru

Alih-alih meningkatkan jumlah partisi pada topik yang sudah ada, peringatan ini menyarankan untuk:

  1. Membuat Topik Baru: Buat topik baru dengan jumlah partisi yang diinginkan (misalnya, 5 partisi).

  2. Menyalin Data dari Topik Lama: Salin semua data dari topik lama ke topik baru menggunakan alat seperti Kafka Connect, MirrorMaker, atau aplikasi kustom yang membaca dari topik lama dan menulis ke topik baru.

  3. Mendistribusikan Ulang Kunci: Saat menyalin data, pastikan kunci pesan didistribusikan ulang ke partisi baru berdasarkan jumlah partisi yang baru. Ini memastikan bahwa pesan dengan kunci yang sama tetap berada di partisi yang sama di topik baru, menjaga pengurutan berbasis kunci.

  4. Migrasi Aplikasi: Perbarui produser dan konsumer untuk menggunakan topik baru setelah migrasi selesai.

Mengapa Membuat Topik Baru Lebih Aman?

  • Menjaga Pengurutan Kunci: Dengan membuat topik baru, Anda dapat memastikan bahwa semua pesan, baik lama maupun baru, didistribusikan ke partisi berdasarkan jumlah partisi yang baru, sehingga pengurutan berbasis kunci tetap terjaga.

  • Konsistensi Data: Menyalin data memungkinkan Anda untuk memverifikasi bahwa semua pesan telah dipindahkan dengan benar sebelum beralih ke topik baru.

  • Minimalkan Gangguan: Anda dapat melakukan migrasi secara bertahap, memungkinkan produser dan konsumer untuk beralih ke topik baru tanpa mengganggu operasi aplikasi yang sedang berjalan.

Kapan Peningkatan Partisi Aman?

Meningkatkan jumlah partisi mungkin aman jika aplikasi Anda tidak bergantung pada pengurutan berbasis kunci. Misalnya:

  • Jika pesan tidak memiliki kunci (key=null), sehingga didistribusikan secara round-robin.

  • Jika aplikasi Anda tidak memerlukan urutan pesan yang ketat dan hanya memproses pesan secara independen.

Namun, bahkan dalam kasus ini, Anda harus berhati-hati karena peningkatan partisi dapat memengaruhi distribusi beban di klaster dan performa konsumer.

Penambahan Penjelasan

Untuk melakukan migrasi ke topik baru, Anda dapat menggunakan alat seperti Kafka Connect dengan konektor sumber (source connector) dan konektor tujuan (sink connector) untuk menyalin data. Alternatifnya, Anda dapat menulis aplikasi sederhana menggunakan Kafka Consumer dan Kafka Producer untuk membaca dari topik lama dan menulis ke topik baru. Pastikan untuk mengatur Schema Registry (jika digunakan) agar skema data tetap konsisten selama migrasi.

Selain itu, saat meningkatkan jumlah partisi, pertimbangkan dampaknya pada grup konsumer. Karena setiap partisi hanya dapat dikonsumsi oleh satu konsumer dalam grup, menambah partisi dapat meningkatkan paralelisme, tetapi juga memerlukan lebih banyak konsumer untuk memanfaatkan partisi baru. Jika jumlah konsumer tidak bertambah, beberapa partisi baru mungkin tetap tidak aktif.

Praktik Terbaik:

  • Selalu uji peningkatan partisi di lingkungan non-produksi terlebih dahulu.

  • Gunakan alat seperti Kafka AdminClient untuk memantau distribusi partisi dan kesehatan klaster setelah perubahan.

  • Dokumentasikan ketergantungan aplikasi pada pengurutan kunci sebelum melakukan perubahan pada topik.

Apa Itu Retensi (Log Retention) di Kafka?

Retensi di Kafka adalah aturan yang menentukan berapa lama pesan akan disimpan di broker sebelum dihapus secara otomatis. Pesan-pesan ini disimpan di dalam file-file yang disebut segmen log. Ketika sebuah segmen log sudah tidak diperlukan lagi (karena sudah melewati batas retensi), Kafka akan menghapusnya untuk menghemat ruang disk.

Konsep ini sangat penting karena:

  1. Menghemat Ruang Disk: Tanpa retensi, data di Kafka akan terus menumpuk dan memenuhi seluruh penyimpanan broker.

  2. Menjamin Data Tersedia: Retensi memastikan pesan tersedia untuk konsumer dalam jangka waktu tertentu. Jika konsumer offline, ia bisa kembali online dan membaca pesan yang tertinggal selama pesan tersebut masih berada dalam periode retensi.

Ada dua cara utama untuk menentukan retensi pesan di Kafka, dan Anda bisa menggunakan keduanya secara bersamaan.

Ilustrasi Retensi Berdasarkan Waktu (Time-based Retention)

Ini adalah metode retensi yang paling umum. Kafka akan menghapus segmen log yang usianya sudah lebih tua dari batas waktu yang ditentukan.

Parameter: log.retention.hours, log.retention.minutes, atau log.retention.ms.

Ilustrasi:

Bayangkan log partisi Kafka adalah sebuah buku harian yang dibagi per hari.

  • Pengaturan: log.retention.hours = 72 (72 jam atau 3 hari).

  • Keadaan Normal: Setiap hari, Kafka membuat segmen log baru dan menambahkan pesan ke dalamnya.

    • Hari 1: Segmen log untuk Hari 1

    • Hari 2: Segmen log untuk Hari 2

    • Hari 3: Segmen log untuk Hari 3

  • Aksi Retensi: Ketika masuk Hari ke-4, Kafka akan memeriksa segmen log Hari 1. Karena usianya sudah lebih dari 72 jam, Kafka akan menghapus segmen log Hari 1.

[Ilustrasi Visual]

                         (Waktu Berjalan)
     (Hari 1)           (Hari 2)           (Hari 3)           (Hari 4)
+------------------+------------------+------------------+------------------+
|  Log Segmen Hari 1|  Log Segmen Hari 2|  Log Segmen Hari 3|  Log Segmen Hari 4|
+------------------+------------------+------------------+------------------+
↑
Batas Retensi: 72 jam
(Log segmen yang lebih tua dari batas ini akan dihapus)

Saat memasuki Hari ke-4, Log Segmen Hari 1 sudah lebih tua dari 72 jam, maka segmen ini akan dihapus.

Poin Penting:

  • Anda bisa menggunakan log.retention.hours (jam), log.retention.minutes (menit), atau log.retention.ms (milidetik).

  • Jika Anda menentukan lebih dari satu parameter, Kafka akan menggunakan parameter dengan unit terkecil (misalnya ms).

Ilustrasi Retensi Berdasarkan Ukuran (Size-based Retention)

Metode ini menghapus segmen log ketika total ukuran log partisi sudah mencapai batas tertentu. Ini sangat berguna untuk memastikan log tidak pernah melebihi ukuran disk yang tersedia.

Parameter: log.retention.bytes

Ilustrasi:

Bayangkan log partisi Kafka adalah sebuah keranjang belanja yang memiliki batas berat maksimum.

  • Pengaturan: log.retention.bytes = 500MB (500 Megabytes per partisi).

  • Keadaan Normal: Kafka terus menambahkan pesan ke log hingga ukurannya mendekati 500MB.

  • Aksi Retensi: Ketika total ukuran log partisi mencapai 500MB, Kafka akan mulai menghapus segmen log tertua hingga total ukurannya kembali di bawah 500MB.

[Ilustrasi Visual]

                        (Pesanan Masuk Terus Menerus)
+-------------------------------------------------------------+
|                                                             |
|   |Sg 1: 100MB| |Sg 2: 150MB| |Sg 3: 120MB| |Sg 4: 130MB|   |  Total: 500MB
|   |   (tua)   | |   (tua)   | |  (baru)   | |   (baru)  |   |
+-------------------------------------------------------------+
↑
Batas Retensi: 500MB

Ketika ada pesan baru masuk dan membuat total ukuran melebihi 500MB:

+-------------------------------------------------------------+
|             | |Sg 2: 150MB| |Sg 3: 120MB| |Sg 4: 130MB| |Sg 5: 50MB|
| (Sg 1 dihapus)| |   (tua)   | |  (baru)   | |   (baru)  | |  (baru)  |
+-------------------------------------------------------------+
Total: 450MB (kembali di bawah 500MB)

Poin Penting:

  • Nilai default untuk log.retention.bytes adalah -1, yang berarti tidak ada batasan ukuran.

  • Retensi ini dihitung per partisi, bukan per topik secara keseluruhan.

Menggabungkan Keduanya (Waktu & Ukuran)

Ini adalah skenario yang paling fleksibel. Anda dapat mengonfigurasi kedua parameter log.retention.bytes dan log.retention.ms.

Aturan: Segmen log akan dihapus ketika salah satu kriteria terpenuhi (log terlalu tua ATAU log terlalu besar).

Contoh Kasus:

  • Tujuan: Simpan data minimal 1 minggu, tetapi tidak lebih dari 500MB per partisi.

  • Pengaturan:

    • retention.ms = 604800000 (7 hari)

    • retention.bytes = 524288000 (500MB)

Dengan pengaturan ini, jika sebuah partisi mencapai 500MB dalam waktu 3 hari, Kafka akan langsung menghapus segmen log tertua, meskipun belum mencapai batas 7 hari. Sebaliknya, jika partisi hanya berisi 100MB setelah 7 hari, Kafka tetap akan menghapus segmen log tertua karena sudah melewati batas waktu.

Ini memungkinkan Anda untuk memiliki kontrol yang sangat granular terhadap penggunaan disk dan ketersediaan data.

PreviousMy Daily UsesNextKafka Topic Advanced: Konfigurasi Topik Kafka: Minimum In-Sync Replicas

Last updated