- Kafka berhasil sebagai log terdistribusi di era data center, tetapi di public cloud biaya jaringan antar-AZ dan beban operasional disk lokal menjadi besar
- WarpStream adalah platform streaming tanpa disk yang kompatibel dengan protokol Apache Kafka, berjalan di atas object storage seperti S3 tanpa disk lokal dan tanpa rebalancing broker
- Klaster Kafka 3 availability zone menimbulkan biaya transfer antar-AZ sekitar $0.053 per 1GiB streaming bahkan dalam skenario terbaik, lebih tinggi daripada biaya penyimpanan S3 1GiB selama satu bulan sebesar $0.021
- WarpStream memisahkan storage–compute serta data–metadata dengan Agent berupa biner Go tanpa state dan metadata store terpisah, sementara data tetap berada di object storage dalam akun cloud pengguna
- Biaya dapat ditekan 5–10 kali pada sebagian besar workload Kafka, tetapi implementasi saat ini menuntut latensi sekitar P99 400ms untuk permintaan Produce dan sekitar P99 1 detik end-to-end dari producer ke consumer
Struktur dasar Kafka yang menjadi mahal di cloud
- Apache Kafka dirilis sebagai open source pada 2011 dan sejak itu menjadi infrastruktur dasar bagi arsitektur streaming
- Masalahnya bukan pada Kafka itu sendiri, melainkan pada desainnya yang dibuat untuk data center LinkedIn tahun 2011 sehingga kurang cocok dengan workload cloud modern
- Biaya dan beban operasional sangat menonjol
- Ekonomi cloud: metode replikasi Kafka dapat membuat biaya bandwidth antar-AZ sangat besar
- Beban operasional: menjalankan klaster Kafka sendiri membutuhkan tim khusus dan alat yang dikustomisasi
- Sistem serupa yang menyimpan data di disk lokal juga dapat mengalami masalah biaya dan operasional yang sama
Kafka-nomics: biaya transfer antar-AZ
- Dalam klaster Kafka 3 availability zone yang umum, data yang diproduksi memiliki probabilitas 2/3 untuk ditulis lintas zona karena lokasi partition leader, lalu leader mereplikasi data ke follower di dua zona lainnya
- Saat 1GiB ditransfer antar-zona, biayanya dihitung sebesar $0.022
- egress dari zona asal $0.01
- ingress ke zona tujuan $0.01
- Bahkan dalam kondisi terbaik sekalipun, biaya streaming 1GiB berada di kisaran
0.02 * 2/3 + 0.02 * 2 = $0.053
- Biaya menyimpan 1GiB di S3 selama satu bulan adalah $0.021, dan biaya menyalin data dari producer ke consumer lewat Kafka cukup untuk menyimpan data yang sama di S3 selama lebih dari dua bulan
- Pada klaster Kafka dengan throughput tinggi, biaya bandwidth antar-AZ mendominasi biaya melebihi hardware, dan dapat mencapai 70–90% dari total biaya workload
- Bahkan jika throughput rendah, periode retensi yang panjang akan memperbesar kapasitas penyimpanan, dan pendekatan replikasi 3x di SSD lokal bisa 10–20 kali lebih mahal per GiB dibanding object storage seperti S3, bahkan dengan asumsi utilisasi disk 100%
Operasional klaster yang harus ditanggung developer
- Developer mengadopsi Kafka untuk menyelesaikan masalah bisnis, tetapi terlebih dahulu harus mempelajari Kafka dan ZooKeeper atau KRaft, leader election, partition, consumer group, rebalancing, tuning broker, serta tuning client
- Broker sebagai data plane Kafka dan controller·ZooKeeper sebagai control plane berbasis konsensus semuanya dioperasikan langsung di atas SSD lokal
- Klaster Kafka self-hosted memerlukan tim spesialis dan alat kustom agar tugas dasar seperti penggantian node atau ekspansi klaster dapat dilakukan dengan aman
- Alat bawaan reassign partition di Apache Kafka tidak dapat membuat rencana reassign otomatis saat broker dipensiunkan, sehingga administrator harus menulis sendiri rencana pemindahan replica partition
- Layanan hosted seperti AWS MSK juga tidak sepenuhnya menghilangkan beban operasional
- Dokumentasi rebalancing klaster MSK menaut ke dokumentasi Apache Kafka
- Prosedurnya mencakup pengeditan manual JSON untuk menentukan partition mana yang dipindahkan ke broker mana
- Cruise Control dapat mengurangi beban, tetapi menambah kebutuhan mempelajari konsep baru, deployment dan monitoring layanan, serta titik-titik operasional yang sensitif
- Cruise Control sendiri juga merupakan aplikasi JVM yang bergantung pada Apache Kafka dan ZooKeeper
Pendekatan menjalankan streaming di atas object storage
- Husky buatan Datadog adalah database kolumnar untuk data observabilitas yang berjalan langsung di atas S3, dan pada dasarnya beroperasi sebagai data lake autoscaling yang mostly stateless
- Setelah membangun Husky, klaster Kafka tampak seperti arsitektur lama jika dijadikan pembanding
- Bandwidth Kafka di Datadog diukur dalam dua digit GiB/s, dan storage broker mencapai NVMe skala PiB
- Workload penyimpanan skala besar sulit bersaing dengan ekonomi, keandalan, skalabilitas, dan elastisitas object storage di lingkungan cloud
- Teknologi big data seperti Snowflake dan Databricks juga merancang sistem mereka dengan object storage generik sebagai pusatnya
- Jika sistem mirip Kafka dibangun langsung di atas S3, dua beban bisa dikurangi sekaligus
- penurunan biaya
- pengurangan masalah operasional Kafka tradisional
- Tantangan utamanya adalah membangun infrastruktur streaming berlatensi rendah di atas media penyimpanan berlatensi tinggi seperti S3, tanpa disk lokal, sambil mempertahankan semantik protokol Kafka
Arsitektur WarpStream
- WarpStream adalah platform streaming kompatibel protokol Apache Kafka yang berjalan langsung di atas object store generik seperti AWS S3, GCP GCS, dan Azure Blob Storage
- Tidak ada biaya bandwidth antar-AZ, tidak ada disk lokal untuk dikelola, dan dapat berjalan di dalam VPC pengguna
- Sebagai pengganti broker Kafka, WarpStream menggunakan Agent
- Agent adalah biner Go tanpa state
- tidak menggunakan JVM
- berbicara dengan protokol Kafka
- Agent mana pun dapat berperan sebagai topic leader, commit offset consumer group, atau koordinator klaster
- WarpStream menggantikan struktur stateful Kafka melalui dua pemisahan
- memisahkan storage dan compute lalu meng-offload data ke S3
- memisahkan data dan metadata lalu meng-offload metadata ke metadata store kustom
- Jika semua penyimpanan dipindahkan ke object storage, maka tidak diperlukan rebalancing data saat jumlah Agent ditambah atau dikurangi mengikuti perubahan beban
- Saat terjadi gangguan, permintaan dapat segera dicoba ulang di Agent lain sehingga pemulihan lebih cepat
- Masalah hotspot saat sebagian broker Kafka menanggung beban lebih tinggi karena ketimpangan data per partition juga sangat berkurang
- Metadata untuk WarpStream Virtual Cluster disimpan di database metadata kustom
- Replikasi data, durability, dan availability ditangani oleh bucket object storage, sementara data pengguna tetap berada dalam akun cloud mereka
- Yang keluar dari akun cloud hanyalah metadata workload yang diperlukan untuk konsensus, seperti urutan batch di dalam partition
- Detail arsitektur lebih lanjut dirangkum dalam dokumentasi arsitektur WarpStream
Contoh biaya dan trade-off latensi
- Workload streaming berkelanjutan di lingkungan uji terus memproduksi data 140MiB/s, dan tiga consumer khusus mengonsumsinya sehingga menghasilkan total transfer data kontinu 560MiB/s
- Biaya jaringan antar-AZ untuk seluruh akun cloud diukur kurang dari rata-rata $15 per hari
- Jika workload yang sama dijalankan di klaster Kafka, hanya biaya jaringan antar-AZ saja dihitung mencapai $641 per hari
- rumus perhitungannya adalah
0.14GiB * $0.053/GiB * 60 * 60 * 24
- Biaya operasi API S3 untuk workload yang sama kurang dari $40 per hari
- Hardware Agent hanya memerlukan VM dengan skala 27 vCPU
- Total cost of ownership untuk sebagian besar workload Kafka dapat 5–10 kali lebih rendah dengan WarpStream
- Kekurangan terbesar adalah latensi
- P99 untuk permintaan Produce saat ini sekitar 400ms
- karena respons konfirmasi tidak diberikan sampai data tersimpan secara durable di S3 dan di-commit ke cloud control plane
- latensi P99 end-to-end dari producer ke consumer sekitar 1 detik
- Jika workload dapat mentoleransi latensi producer-ke-consumer sekitar P99 1 detik, maka biaya streaming per GiB bisa dipangkas 5–10 kali sambil hampir menghilangkan beban operasional
- Antarmukanya bukan protokol proprietari, melainkan Kafka, dan dapat berjalan di lingkungan yang menggunakan AWS S3, GCP GCS, atau Azure Blob Storage
Pengalaman developer dan cara penggunaan
- WarpStream pertama-tama menangani dua masalah utama Kafka, yakni ekonomi cloud dan beban operasional
- Kafka juga memiliki masalah developer experience, dan partition dianggap sebagai abstraksi yang terlalu rendah untuk menulis aplikasi stream processing yang kompleks
- Ke depan, mereka berencana membahas cara membuat aplikasi stream processing terasa lebih dekat dengan cara menulis aplikasi tradisional
- Demo dapat dijalankan dalam waktu kurang dari 30 detik
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream adalah pengenalan produk dari perusahaan yang menjual alternatif berbasis object storage untuk Apache Kafka, sehingga angka dan perbandingan dalam artikel ini perlu dibaca dalam konteks tersebut
1 komentar
Opini Hacker News
Pernyataan “hampir semua perusahaan teknologi memakai Kafka” tampaknya keliru
Memang tidak ada yang saling menyodorkan bukti, tetapi dari 6 perusahaan tempat saya bekerja belakangan ini, jumlah yang memakai Kafka adalah 0; di perusahaan sebelumnya saya memimpin adopsinya, tetapi kemudian kami membuangnya
LinkedIn membuat Kafka untuk menyelesaikan masalah skala sangat besar yang tidak dimiliki 99% pihak, dan meski para teknolog memang punya reputasi memakai teknologi yang tidak mereka butuhkan, menurut saya kebanyakan berhasil menghindari penggunaan Kafka
Jika itu saja yang Anda butuhkan, ia mudah dipakai seperti message broker sederhana tanpa periode retensi; jika Anda perlu melakukan hal-hal unik dengan memanfaatkan durabilitas, Anda bisa mengarah ke sana
Kalau seseorang punya perasaan negatif terhadap alat open-source yang kokoh dan banyak dipakai bahkan dalam bentuk dasarnya, biasanya saya kira itu karena beberapa fitur khusus atau kasus penggunaan tertentu
Justru ungkapan seperti ini tampak buruk bagi vendor ini. Mengkritik atau bersaing dengan Kafka berdasarkan kelebihan dan kekurangan teknis itu boleh, tetapi mendistorsi posisinya di pasar kurang baik
Saya tidak meragukan ada kasus penggunaan yang bagus, tetapi sejauh ini yang saya lihat hanya pengguna fanatik yang memaksakannya ke situasi apa pun, sehingga meninggalkan kesan buruk dan membuat saya termasuk di kubu “yang tidak suka”
Saya setuju dengan bagian “Accidental SRE”, tetapi Kafka adalah teknologi yang solid, dan karena itu juga ada banyak alat “Kafka yang lebih baik daripada Kafka” seperti Redpanda
Di bagian akhir, sepertinya argumennya melenceng. Sekalipun tidak dipakai secara luas, itu berbeda dari apakah teknologinya memicu polarisasi. Bagi orang-orang yang menyelesaikan masalah penskalaan 1% yang disebutkan, ia tetap bisa menjadi sesuatu yang disukai atau dibenci
Ini mirip mengatakan “Lamborghini memecah pendapat” itu salah karena kebanyakan orang tidak punya Lamborghini. Penulis juga secara eksplisit membatasi cakupannya dengan mengatakan “di bidang data”
Ada beberapa pertanyaan
Jadi biaya PUT S3 sebanding dengan jumlah Agent yang berjalan dan interval flush, bukan jumlah topic-partition. Kami tidak mengakui permintaan Produce sebelum data tersimpan secara durable di S3 dan control plane cloud
Menurut kami, orang seharusnya tidak perlu memilih antara keandalan dan biaya. WarpStream menyediakan keandalan dan ketersediaan setingkat berjalan di 3 availability zone dengan biaya satu availability zone
Urutan ditangani oleh database metadata kustom yang berjalan di control plane cloud
Tidak ada masalah pada pendekatan menaruh klaster Kafka di tiap availability zone lalu hanya mereplikasinya sampai nanti saat digabungkan. Namun, begitu ada sistem terdistribusi dan availability zone, para engineer—dan kebutuhan bisnis—pada umumnya akan memilih konfigurasi multi-availability-zone. Region juga sama
Karena itu, kebanyakan klaster Kafka bersifat multi-availability-zone, padahal sebenarnya dalam banyak kasus tidak harus begitu, dan tagihan biayanya kemudian disalahkan pada Kafka
Protokol Kafka sebenarnya tidak mempertahankan urutan operasi di dalam partisi Kafka. Ia mempertahankan urutan operasi dalam pasangan produser-partisi, dan itu pun hanya jika dikonfigurasi dengan cara tertentu
Implementasi standar mempertahankan urutan pesan diterima broker dari produser, tetapi dari sudut pandang sistem eksternal, maknanya lebih dekat pada: jika dikonfigurasi dengan benar, pesan untuk kunci tertentu dan produser tertentu dipertahankan sesuai urutan penerimaan
Apakah Cloud Metadata Store pada dasarnya berperan membagikan offset?
Saya Ryan Worl, salah satu pendiri sekaligus CTO WarpStream. Kami sangat senang mengumumkan developer preview dari sistem streaming yang kompatibel dengan protokol Kafka yang dibangun langsung di atas S3
Tidak ada disk/node stateful yang perlu dijalankan, tidak ada rebalancing data, tidak ada ZooKeeper, dan tidak ada biaya bandwidth antar-availability zone, sehingga 5–10 kali lebih murah
Jika ada pertanyaan tentang WarpStream, saya akan menjawabnya bersama salah satu pendiri kami, richieartoul
Salah satu alasan saya tidak membuatnya adalah karena saya merasa ada paradoks: jika skala tidak penting, bukankah pengguna lebih baik langsung memakai SQLite daripada menginginkan Kafka versi mini?
Namun mungkin ada orang yang menyukai semantik protokol Kafka, atau sudah memakai Kafka lalu menyadari skalanya tidak sebesar yang dibayangkan sehingga tidak perlu menanggung kompleksitasnya. Semoga sukses
Jika mendukung Cloudflare R2, sepertinya bagus juga untuk multi-cloud
Apakah juga menyediakan jaminan urutan seperti yang diberikan Kafka pada level partition?
Jika “5–10 kali lebih murah” sebagian besar berasal dari penghematan biaya antar-availability zone, bukankah AWS MSK juga menyediakan itu?
Satu hal sudah jelas. Menjalankan Kafka “sesuai pakem” di VM terpisah di atas penyedia cloud itu luar biasa mahal
Saya ingat pernah berdiskusi sangat sederhana dengan beberapa pelanggan tentang Kafka dan Hadoop: mengapa mereplikasi data lagi di level VM/disk, padahal disk sudah disediakan sebagai sistem redundansi yang lengkap?
Dalam kasus ini yang dipakai adalah Azure Storage, yang menyediakan penyimpanan dengan redundansi lokal, redundansi availability zone, dan redundansi global; sebagian besar di antaranya bisa digunakan untuk menjalankan managed disk
Jadi layanan terkelola Hadoop/Kafka di cloud yang dirancang dengan benar memakai storage adapter untuk memanfaatkan redundansi bawaan penyedia. Itu juga alasan beberapa penyedia cloud memiliki event broker yang kompatibel dengan Kafka
Bagian lain dari WarpStream lebih seperti bonus, tetapi saya penasaran dengan struktur internalnya dan bagaimana mereka menghindari biaya antar-availability zone
Sebagai catatan, saya bekerja di Microsoft, tetapi sebelum bergabung hampir 10 tahun lalu saya membangun cluster Hadoop/Spark/Kafka
Beberapa implementasi Raft mengizinkan node yang punya hak suara tetapi tidak bisa menjadi quorum leader. Misalnya kantor cabang yang semua trafiknya melewati tunnel VPN asimetris tidak boleh terpilih sebagai leader, tetapi tetap tahu kandidat mana yang bisa dilihatnya
Jadi biaya dasar menjalankan cluster lebih dekat ke 2,2 kali lipat, bukan 3 kali lipat hardware, dan itu membuat perbedaan besar untuk solusi kecil atau sandbox developer. Ini juga penting ketika 3 shard terasa sedikit kurang untuk beban, tetapi 5 terlalu banyak, atau bahkan pada perbedaan antara 6 dan 7 shard
Masalahnya, pada replikasi geografis, pendekatan ini tidak menyelesaikan dua masalah yang menjadi inti argumen tulisan ini. Dari sisi ekonomi cloud, strategi replikasi Kafka secara desain menciptakan biaya bandwidth antar-availability zone yang sangat besar; dari sisi beban operasional, menjalankan cluster Kafka sendiri pada praktiknya membutuhkan tim khusus dan tooling kustom yang canggih
Meski begitu, fungsi ini perlu didapatkan kembali di cloud. Terutama ketika, seperti yang selalu terjadi di masa lalu, pendulum mulai berayun lagi ke arah self-hosting
Solusi mirip EBS ada biayanya. Terutama ketika membutuhkan banyak IOPS, biayanya sangat mahal. Anda mungkin bisa menghemat biaya trafik antar-availability zone, tetapi akan membayar jumlah yang tidak masuk akal untuk storage
Jika mereplikasi sendiri, Anda bisa memakai attached storage yang jauh lebih murah
Untuk richieartoul, artikel blognya agak terlalu dibumbui
Kafka pada dasarnya tidak membutuhkan tim ahli khusus dan jutaan dolar sampai Anda mengoperasikan cluster yang sangat besar
Namun saya sepenuhnya setuju bahwa cluster yang tersebar di 3 availability zone akan menguras uang lewat biaya transfer antar-availability zone. Itulah juga cara AWS menjual MSK. Mereka bilang transfer antar-availability zone “gratis”, tetapi sebenarnya sudah dimasukkan ke dalam harga
Ini terlihat menarik, tetapi setelah membaca “Accidental SRE” saya punya dua pertanyaan
Bare metal sudah ada sejak lama, tetapi mengelola bare metal sendiri tampaknya tidak menjadi jauh lebih mudah. Kalau benar-benar mudah, pengguna akhir pasti lebih banyak mengelola hal-hal seperti ini sendiri
Jadi bagaimana layanan ini dikelola? Apakah di penyedia cloud, atau bare metal?
Kalian berdua punya banyak pengalaman dengan FoundationDB, yang biasanya dikelola sendiri. Jadi apakah metadata store-nya juga kembali memilih FoundationDB? Jika memilih atau tidak memilihnya, saya penasaran alasannya
Dengan begitu, semua data pelanggan tetap berada di akun cloud dan bucket S3 milik pelanggan, sehingga kami tidak bisa melihat atau menyentuhnya. Pelanggan memang harus menjalankan WarpStream Agent sendiri, tetapi itu hanya container stateless yang mudah dikelola
Kami mempertimbangkan FoundationDB sebagai metadata store, tetapi akhirnya tidak memakainya. Agar free tier bisa dibuat hemat biaya, kami harus membuat metadata store seefisien mungkin untuk use case khusus ini, dan untuk itu kami membutuhkan sesuatu yang lebih kustom
Meski begitu, FoundationDB adalah teknologi yang luar biasa. Itu yang terbaik di antara berbagai database terdistribusi yang pernah saya gunakan
Pernyataan “berapa banyak partisi yang harus dipakai? Tidak jelas, tetapi begitu ditetapkan tidak bisa diubah sama sekali, jadi harus memilih dengan benar” itu keliru. Jumlah partisi bisa diubah.
Dan klaim yang terus diulang bahwa “operasi Kafka membutuhkan seluruh tim engineer” juga sulit saya pahami. Berdasarkan pengalaman, itu tidak benar. Memang biaya operasionalnya mahal, tetapi di tim kami tidak membutuhkan banyak waktu engineering.
Sangat menarik. Saya juga merancang sesuatu yang mirip dan sempat ingin mengimplementasikannya dengan Zig https://github.com/fremantle-industries/transit
Sebagian besar kekuatan Kafka berasal dari API-nya, dan saya sampai pada kesimpulan serupa bahwa kompleksitas manajemen klaster pada akhirnya akan diabstraksikan lewat berbagai implementasi.
Jika persistensi Kafka bisa diimplementasikan di atas key space S3, saya pikir kita bisa memulai dengan cara mem-persist data langsung ke S3 seperti WarpStream, lalu kemudian menambahkan mekanisme tiering ke hot disk yang lebih cepat dan memori untuk menurunkan latensi end-to-end.
Saya suka arahnya. Kalau ingin berdiskusi lebih dalam, silakan hubungi saya di Twitter https://twitter.com/rupurt
Di tempat kerja lama, saya membuat sesuatu yang mungkin sangat mirip dengan produk ini. Ada traffic machine learning puluhan TB per hari, dan karena tidak membutuhkan latensi real-time, semuanya dipindahkan ke S3, menghasilkan penghematan biaya sekitar 90%.
Dibangun di atas JVM, dan untuk menjaga metadata kami masih memakai klaster Kafka 6 broker. Saat semuanya masih berada di Kafka, kemungkinan jumlah brokernya sekitar 300.
Model komputasi/penyimpanan Kafka tidak berkembang dengan baik untuk kasus penggunaan ekstrem yang bisa menoleransi latensi, dan model Apache Pulsar cenderung lebih cocok. Namun saat itu Pulsar belum cukup stabil untuk dipakai di produksi.
Salah satu kunci efisiensi biaya adalah ukuran datanya cukup besar sehingga tidak perlu menunggu lama sampai mencapai ukuran file yang ekonomis. Sulit membayangkan pipeline di bawah 10MB per detik bisa berjalan efisien dengan cara ini.
Apakah itu memq milik Pinterest, atau sesuatu yang lain?
Judul artikelnya seharusnya “Kafka is dead. Long live WarpStream.” Bagian “long live” merujuk pada penerusnya.
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!