Iggy.rs - Membangun message streaming dengan Rust

Asal mula

• Pada April 2023, diputuskan untuk mempelajari Rust.
• Berdasarkan pengalaman dalam sistem terdistribusi dan messaging, diputuskan untuk mengembangkan platform message streaming.
• Tujuannya adalah memahami cara kerja internal sistem messaging dan trade-off yang dihadapi para developer.
• Lahirnya Iggy.rs, dengan penetapan tujuan sebagai platform message streaming yang menekankan kecepatan dan bobot ringan.

Proyek

• Iggy versi awal menggunakan protokol QUIC untuk menyediakan fungsi dasar pertukaran pesan.
• Melalui prototyping dan perbaikan berkelanjutan, dibangun server yang mendukung penulisan/pembacaan paralel serta stream yang independen.
• Dukungan untuk protokol TCP dan HTTP ditambahkan, dan performa ditingkatkan melalui optimasi mekanisme sinkronisasi data.
• Melalui benchmarking, terkonfirmasi throughput tinggi dan latensi rendah, lalu proyek ini diubah menjadi proyek jangka panjang.

Tim

• Iggy dikerjakan oleh tim beranggotakan sekitar 10 orang yang berkontribusi di berbagai bagian.
• Mereka terlibat dalam beragam proyek seperti core server, SDK, web UI, dan CLI.
• Developer dengan latar pengalaman yang beragam berpartisipasi secara sukarela karena berbagi semangat terhadap pemrograman.
• Partisipasi para kontributor eksternal dari seluruh dunia meningkatkan keyakinan terhadap proyek ini.

Fitur

• Server message streaming berbasis log yang berperforma tinggi dan berkelanjutan.
• Throughput tinggi, latensi rendah, serta penggunaan resource yang dapat diprediksi berkat bahasa terkompilasi Rust.
• Dukungan untuk banyak stream, topic, partisi, dan berbagai protokol transport.
• RESTful API, client SDK untuk berbagai bahasa, serta kemampuan bekerja langsung dengan data biner.
• Fitur server dapat dikonfigurasi, offset konsumen disimpan di server, dan mendukung berbagai metode polling pesan.
• Consumer group untuk urutan pesan dan skalabilitas horizontal, serta fitur kedaluwarsa pesan dan deduplikasi.
• Dukungan TLS untuk semua protokol transport, enkripsi data opsional, dan dukungan message header.
• CLI bawaan dan aplikasi benchmarking untuk mengelola server streaming, dengan deployment sebagai binary tunggal.

Roadmap

• Setelah muncul di halaman trending GitHub, mulai ada diskusi dengan pengguna mengenai penambahan fitur.
• Menargetkan peningkatan performa dan keandalan melalui clustering, low-level I/O, dan arsitektur thread per core.
• Bereksperimen dengan mekanisme konsensus Raft, meningkatkan pekerjaan I/O melalui io_uring, dan berencana menggunakan runtime monoio.

Masa depan

• Menargetkan platform message streaming serbaguna serta menantang batasan OS dan hardware.
• Berencana mendukung berbagai bahasa pemrograman, CLI, dan web UI melalui platform terintegrasi yang mudah digunakan.
• Menargetkan perkembangan melalui feedback dan ide dari komunitas.

GN⁺ berpendapat

• Iggy.rs adalah platform message streaming berbasis Rust yang menargetkan performa tinggi dan latensi rendah.
• Sebagai proyek open source, proyek ini terus berkembang melalui partisipasi dan kontribusi sukarela dari developer di seluruh dunia.
• Target ambisiusnya untuk melampaui batas performa sistem terdistribusi melalui teknologi inovatif seperti clustering, optimasi low-level I/O, dan arsitektur thread per core sangat menarik, serta menjadikannya proyek yang sangat bermanfaat bagi orang-orang yang tertarik pada bidang ini.

[GN⁺]

Komentar Hacker News

• Kisah-kisah seperti ini adalah alasan awal saya masuk ke dunia software
  Meski masing-masing punya alasan berbeda, rasanya ideal melihat orang-orang bekerja bersama menuju tujuan yang sama, dan kompensasi finansial bukan satu-satunya tujuan
  Semoga proyek ini sukses, dan kalau ada perbandingan dengan alternatif lain, sepertinya akan lebih mudah memahami posisi proyek ini
  • Memang dimulai dengan cara seperti itu, dan suatu hari nanti kami juga ingin memasukkan benchmark dan perbandingan dengan tool lain
• Idenya bagus dan tulisan blognya juga bagus
  Penulisnya terasa rendah hati, jujur, dan seperti pemimpin proyek yang konstruktif
  • Timnya benar-benar luar biasa
    Semua memutuskan ikut dalam upaya ini dengan niat untuk juga menikmatinya
• Memulai dengan QUIC terlihat seperti pilihan yang benar-benar tajam dan cerdas
  QUIC menyediakan multi-streaming berguna yang mirip SCTP sehingga bagus sebagai titik awal, sudah ada banyak library bagus yang bisa dimanfaatkan, dan kemungkinan akan makin baik serta makin optimal ke depannya: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
  Ini adalah area alami di mana memakai protokol transport yang sedikit lebih baik dari yang sudah ada saja bisa memberi keuntungan besar, jadi saya menantikan QUIC dalam 10 tahun ke depan
  • Kami memulai dengan QUIC karena ingin mencoba sesuatu yang baru
    Namun protokol TCP yang saat ini diimplementasikan sedikit lebih cepat daripada QUIC, mungkin karena tuning tambahannya masih kurang
    Selain itu, QUIC di MacOS lebih lambat dibandingkan Linux
• Sepertinya pesaing langsung JetStream? Perkembangannya sejauh ini dalam waktu kurang dari setahun mengesankan
  https://docs.nats.io/nats-concepts/jetstream
  • Ada cukup banyak solusi streaming pesan seperti JetStream, Kafka, Redpanda, RabbitMQ Streams, dan Fluvio
• Saya belum begitu paham bagaimana perbandingannya dengan Kafka dan Fluvio, pesaing Kafka yang ditulis dengan Rust
  Apakah ini lebih dekat ke message queue seperti RabbitMQ?
  https://www.fluvio.io/
  • Karena ini message stream, lebih dekat ke Kafka, Redpanda, dan plugin RabbitMQ Streams
    Fluvio adalah produk nyata dan ada perusahaan di belakangnya, jadi lebih matang, tetapi kami punya ide sendiri untuk menjadikan Iggy solusi streaming pesan yang kompetitif
  • Bukankah Fluvio bertujuan menggantikan Flink sekaligus Kafka? Saya baru mengetahuinya dan sedang mencoba memahaminya
• Beberapa tahun lalu saya membuat sesuatu yang mirip dengan seorang teman menggunakan Go
  https://github.com/thibauts/styx
  • Kelihatannya cukup mirip
    Saya penasaran kenapa pengerjaannya tidak dilanjutkan lagi
• Suatu hari nanti saya ingin mencobanya. Tapi sepertinya harus belajar Rust dulu
  Selain itu, saya suka estetika situsnya
  • Ada beberapa SDK, dan blognya memakai engine Rust Zola
  • Tulisan blognya menyebutkan SDK untuk bahasa pemrograman lain, jadi sepertinya bisa digunakan tanpa belajar Rust
• Tulisan ini membuat saya kembali membuka titik awal Fluvio
  Ini adalah tim kecil yang selama beberapa dekade punya hubungan panjang dengan aplikasi data-sentris di berbagai domain, dan mereka bertaruh pada streaming data berbasis Rust dan WebAssembly alih-alih Java dan JVM
  Pada Juni 2021, CTO menulis visi Fluvio di sini: https://news.ycombinator.com/item?id=38880743
  Karena pertanyaan perbandingan terus muncul, saya juga bisa membagikan materi yang ada di pihak Fluvio. Dokumentasinya panjang, tetapi saya bisa membagikan yang kami punya saat ini. Iggy juga benar-benar hasil kerja yang bagus
• Ide dan proyek yang sangat keren
  Namun sebelum mencobanya, sepertinya saya perlu memahami dua hal: bagaimana menjalankan lebih dari satu instance server, dan saat menjalankan lebih dari satu, bagaimana interaksi filesystem antar-servernya
  • Di tulisan blog disebutkan berjalan sebagai node tunggal. Belum ada dukungan cluster
    Kalau cluster sudah didukung, sepertinya bisa bersaing dengan Kafka
• Pilihan memakai monoio cukup mengejutkan
  Setahu saya itu membutuhkan compiler nightly, dan menurut saya bukan pilihan bagus untuk memelihara proyek
  • Memang membutuhkan nightly, tetapi hanya memakai lima fitur, dan salah satunya bisa dihapus dengan menambahkan crate eksternal
    Sisanya juga sebagian besar bukan fitur yang terlalu ekstrem. Saya belum melihat kodenya secara mendalam, tetapi semuanya masuk akal. Misalnya, salah satunya adalah API standard library untuk membuat container yang belum diinisialisasi sehingga bisa menghilangkan penyalinan
    Saya belum membandingkan glommio, yang berjalan di stable, dengan monoio, tetapi sepertinya menarik
  • Monoio terlihat seperti runtime dengan performa terbaik dan dalam praktiknya juga mudah digunakan
    Jadi kami memilih pendekatan bleeding edge. Bagaimanapun, implementasi io_uring dan optimasi lain masih akan memakan waktu beberapa bulan lagi, dan kemungkinan kami akan menulis ulang sebagian bagian inti sambil berpindah ke struktur thread per core