Bagaimana jika kita bisa membangun ulang Kafka dari nol?

• Diskusi tentang Kafka yang dioptimalkan untuk cloud menjadi semakin aktif melalui KIP-1150 (Kafka tanpa disk) dan proyek fork Kafka dari AutoMQ
• Jika Kafka dibangun ulang, diusulkan untuk menghapus struktur partisi yang ada dan memakai pendekatan berpusat pada key
• Ada kebutuhan akan fitur kontrol konkurensi dan dukungan skema di sisi broker
• Juga ditekankan perlunya mengintegrasikan karakteristik sistem modern seperti skalabilitas, snapshot, dan multi-tenancy
• Sebuah bayangan tentang sistem event log cloud-native yang sesungguhnya yang melampaui keterbatasan Kafka saat ini, dengan Kafka sebagai titik awal

---

Jika Kafka dibangun ulang?

• Baru-baru ini KIP-1150 (Kafka tanpa disk) dan fork Kafka dari AutoMQ diumumkan, dengan tujuan mengintegrasikan Kafka dengan object storage seperti S3 untuk meningkatkan elastisitas dan menurunkan biaya di lingkungan cloud
• Artikel ini membayangkan sistem event log cloud-native yang melampaui keterbatasan Kafka saat ini dan mengusulkan berbagai perbaikan

Usulan arsitektur tanpa partisi

• Karena object storage cloud dapat berfungsi seperti storage tak terbatas, kebutuhan akan partisi topik menjadi berkurang
• Dalam banyak kasus, yang penting hanyalah urutan pesan global atau urutan pesan dengan key yang sama
• Konsep partisi bisa disembunyikan dari pengguna untuk memberikan pengalaman pakai yang lebih sederhana

Pendekatan berpusat pada key

• Diusulkan desain yang memungkinkan akses cepat dan replay terhadap semua pesan untuk key tertentu, bukan pemindaian partisi
• Dapat mendukung stream setingkat entitas dalam jumlah jutaan sehingga jumlah konsumen bisa diskalakan secara dinamis sesuai permintaan
• Karena kegagalan terisolasi pada level key, efisiensi pemrosesan seluruh sistem dapat meningkat
• Ini adalah struktur yang ideal untuk event sourcing atau sistem actor model

Dukungan hierarki topik

• Seperti sistem seperti Solace, sebagian payload pesan perlu dipromosikan menjadi identifier topik berbentuk jalur terstruktur agar memungkinkan subscription berbasis pola
• Broker dapat mendukung filtering subscription secara efisien tanpa harus mem-parsing seluruh pesan

Fitur kontrol konkurensi

• Kafka saat ini tidak memiliki cara untuk mencegah konflik konkurensi saat penulisan
• Jika mendukung optimistic locking per key, sistem bisa memverifikasi apakah pesan ditulis setelah melihat state terbaru
• Ini dapat mencegah masalah lost update

Dukungan skema di sisi broker

• Kafka saat ini memperlakukan pesan hanya sebagai array byte sederhana sehingga bergantung pada schema registry eksternal
• Diusulkan perlunya dukungan bawaan pada level broker untuk informasi skema seperti metadata AsyncAPI guna memastikan konsistensi skema
• Dengan begitu, integrasi dengan open table format seperti Apache Iceberg juga menjadi lebih mudah

Skalabilitas dan struktur plugin

• Diusulkan arsitektur dengan skalabilitas dan kemampuan plugin seperti Postgres dan Kubernetes
• Filter atau transformasi di level broker harus mudah diimplementasikan tanpa proxy yang memahami protokol seperti Kroxylicious
• Fitur seperti rate limiting, enkripsi topik, dan dukungan backend berbasis tabel Iceberg harus bisa diimplementasikan sebagai plugin

Callback commit sinkron

• Kafka saat ini hanya menjamin eventual consistency
• Diusulkan perlunya struktur yang memungkinkan produser segera memverifikasi apakah data turunan terkait sudah diperbarui setelah pesan dikirim
• Dengan dukungan read-your-own-writes guarantee, Kafka bisa digunakan sebagai log database yang sesungguhnya

Fitur snapshot

• Compaction Kafka saat ini hanya menyisakan pesan terakhir, yang hanya efektif bila pesan tersebut memuat seluruh state
• Jika yang dicatat hanya perubahan, semua event per key tetap harus di-replay sehingga waktu pemrosesan bertambah
• Diperlukan fitur kompaksi logis yang merangkum event per key menjadi snapshot

Dukungan bawaan multi-tenancy

• Semua sistem data modern harus mempertimbangkan multi-tenancy sebagai kemampuan bawaan
• Lingkungan tenant baru harus bisa dibuat dengan murah dan seketika, sambil memisahkan resource, keamanan, dan kontrol akses secara ketat

Catatan lain

• Beberapa fitur sudah didukung oleh sistem seperti S2 (stream dengan kardinalitas tinggi), Waltz (optimistic locking), dan Apache Pulsar (multi-tenancy)
• Namun, belum ada sistem open source yang mendukung semua fitur yang diusulkan sekaligus
• Artikel ini adalah pandangan pribadi penulis yang bekerja di Confluent dan bukan posisi resmi perusahaan
• Disebutkan bahwa secara teoretis arsitektur berbasis LSM tree kemungkinan akan menjadi pilihan yang kuat

[kaydash]

Kami sudah menyebutnya Redis.

[GN⁺]

Komentar Hacker News

• Setuju. Untuk kasus penggunaan tertentu, ini layak untuk menyelesaikan masalah head-of-line

  • Namun, semua sistem streaming saat ini (atau solusi akalnya) menimbulkan biaya O(n^2) untuk acknowledgment per kunci pesan
  • Sistem seperti Pulsar sering digunakan untuk fitur ini
  • Kompleksitas ini mungkin tidak muncul setiap hari, tetapi saat muncul, Anda harus menunggunya
  • Setelah lama meneliti masalah ini bersama rekan-rekan, kami sampai pada kesimpulan bahwa perubahan arsitektur yang mendasar diperlukan untuk mendukung acknowledgment per kunci pesan yang dapat diskalakan
  • Arsitekturnya memerlukan indeks terurut, yang berarti memproses n pesan dalam O(n log n)
  • Saya ingin menulis blog tentang topik ini, tetapi belum sempat
  • Jika Anda ingin bergantung pada acknowledgment per kunci pesan, perkirakan akan ada gangguan atau latensi sesekali

• NATS.io lebih mudah digunakan daripada Kafka, dan sudah menyelesaikan beberapa hal seperti penghapusan partisi, dukungan stream berbasis kunci, dan hierarki topik yang fleksibel

• Perjalanan saya dengan Kafka sebagian besar serupa

  • Awalnya saya berpikir, "Oh, append-only log yang bisa diskalakan, bagus dan sederhana"
  • Tetapi setelah dipakai, Anda akan sadar bahwa ini sangat kompleks

• Untuk kasus penggunaan tertentu, akan berguna jika kita bisa menjamin bahwa saat permintaan create di-acknowledge, derived data view juga sudah diperbarui

  • Jangan gunakan Kafka, tulis langsung ke data store di bawahnya
  • Dengan begitu Anda tahu datanya sudah di-commit, dan Anda punya database yang bisa di-query

• Saya mengajukan pertanyaan ini 6 tahun lalu

  • Bagaimana kalau ditulis dengan Rust dan memanfaatkan WASM
  • Selama 6 tahun terakhir saya telah mengerjakan ini
  • Selama 2 tahun terakhir saya telah membangun Flink dengan Rust dan WASM

• Object storage untuk Kafka? Itu akan meningkatkan latensi dan biaya 10x

  • Kafka adalah korban dari kesuksesannya sendiri
  • Desainnya sederhana dan elegan, sehingga dipakai untuk berbagai kegunaan yang awalnya tidak dirancang untuknya
  • Tentu saja ini tidak sempurna untuk kasus-kasus penggunaan tersebut

• Soal "penghapusan partisi" dan "stream tingkat kunci"

  • Saat backend storage bergantung pada partisi fisik, itu pada dasarnya hanya mengganti nama partisi menjadi kunci, dan kunci menjadi event

• Northguard perlu diperhatikan

  • Ini adalah nama penulisan ulang Kafka milik LinkedIn, dan dipresentasikan sekitar seminggu lalu di pertemuan stream processing

• Saya penasaran, seberapa banyak masalah Apache Kafka yang bisa diselesaikan dengan beralih ke Apache Pulsar

  • Saya melewati proses belajar Kafka dan langsung memakai Pulsar
  • Sangat cocok untuk kasus penggunaan kami
  • Tidak ada keluhan
  • Tetapi saya penasaran mengapa begitu sedikit orang yang menggunakannya

• Ini eksperimen pemikiran yang berguna

  • Jawaban-jawaban yang menyiratkan kesimpulan bahwa Kafka harus diganti dengan sesuatu yang baru cenderung sunyi
  • Kekuatan terbesar Kafka adalah ekosistem luas dan berguna yang dibangun di atasnya
  • Itu juga merupakan kelemahannya
  • Beberapa keputusan desain tetap harus dipertahankan meski hari ini kita tidak akan membuatnya jika mulai dari nol
  • Atau kita harus melepaskan kompatibilitas mundur, lalu membangun ulang ekosistem yang sudah dimiliki