Iggy.rs - Rustで構築するメッセージストリーミング

 (blog.iggy.rs)
3 ポイント 投稿者 GN⁺ 2024-01-06 | 1件のコメント | WhatsAppで共有

起源

  • 2023年4月、Rustの学習を決意。
  • 分散システムとメッセージングの経験をもとに、メッセージストリーミングプラットフォームの開発を決定。
  • メッセージングシステムの内部動作原理と、開発者たちのトレードオフを理解することが目的。
  • Iggy.rsの誕生、速度と軽量性を重視するメッセージストリーミングプラットフォームを目標に設定。

プロジェクト

  • 初期のIggyはQUICプロトコルを使用し、基本的なメッセージ交換機能を提供。
  • 継続的なプロトタイピングと改善を通じて、並列書き込み/読み取りと独立したストリームをサポートするサーバーを実装。
  • TCPとHTTPプロトコルのサポート追加、およびデータ同期メカニズムの最適化によって性能を向上。
  • ベンチマーキングにより高いスループットと低レイテンシを確認し、長期プロジェクトへ移行。

チーム

  • Iggyは約10人のメンバーで構成されたチームがさまざまな部分に貢献。
  • コアサーバー、SDK、Web UI、CLIなど多様なプロジェクトに参加。
  • プログラミングへの情熱を共有する、さまざまな経験を持つ開発者たちが自発的に参加。
  • 世界中からの外部コントリビューターの参加によって、プロジェクトへの自信が高まる。

機能

  • 高性能で持続可能なログベースのメッセージストリーミングサーバー。
  • 高スループット、低レイテンシ、Rustコンパイル言語による予測可能なリソース使用。
  • 複数のストリーム、トピック、パーティションのサポートと、多様な転送プロトコルのサポート。
  • RESTful API、各種言語向けクライアントSDK、バイナリデータの直接操作。
  • サーバー機能の構成が可能で、コンシューマーオフセットのサーバー保存や、メッセージポーリングのさまざまな方法をサポート。
  • メッセージ順序と水平スケーリングのためのコンシューマーグループ、メッセージ有効期限と重複排除機能。
  • すべての転送プロトコルに対するTLSサポート、オプションのデータ暗号化、およびメッセージヘッダーのサポート。
  • ストリーミングサーバー管理のための組み込みCLIとベンチマーキングアプリ、単一バイナリでの配布。

ロードマップ

  • GitHubのトレンドページに登場した後、ユーザーたちと機能追加について議論。
  • クラスタリング、低レベルI/O、コアごとのスレッドアーキテクチャによる性能と信頼性の向上を目標。
  • Raftコンセンサスメカニズムの実験、io_uringによるI/O処理の改善、monoioランタイムの使用を計画。

未来

  • 汎用的なメッセージストリーミングプラットフォームと、OSおよびハードウェアの限界に挑戦することが目標。
  • 使いやすい統合プラットフォームとして、さまざまなプログラミング言語、CLI、Web UIをサポートする計画。
  • コミュニティからのフィードバックとアイデアを通じた発展を目指す。

GN⁺の意見

  • Iggy.rsはRustベースのメッセージストリーミングプラットフォームで、高性能と低レイテンシを目指している。
  • オープンソースプロジェクトとして、世界中の開発者による自発的な参加と貢献を通じて継続的に成長中。
  • クラスタリング、低レベルI/O最適化、コアごとのスレッドアーキテクチャのような革新的技術を通じて、分散システムの性能限界を超えようとする野心的な目標が興味深く、この分野に関心のある人にとって非常に有益なプロジェクトである。

関連記事

1件のコメント

 
GN⁺ 2024-01-06
Hacker News のコメント
  • こういう話こそ、最初にソフトウェアの世界へ来るきっかけになったものだった
    それぞれ違う理由があっても、同じ目標に向かって一緒に働き、金銭的報酬だけが唯一の目的ではない姿が理想的に感じられる
    プロジェクトの成功を願っているし、ほかの選択肢との比較があれば、このプロジェクトがどこに位置づけられるのかをより理解しやすくなると思う
    • まさにそういう形で始まったし、いつかはほかのツールとのベンチマークと比較も含めてみたい
  • アイデアもブログ記事も良い
    書き手は謙虚で率直で、建設的なプロジェクトリーダーのように感じられる
    • チームは本当に素晴らしい
      みんな、楽しむことも大事にしようという気持ちでこの取り組みに参加することにした
  • QUICから始めたのは、本当に鋭く賢い選択に見える
    SCTPに似た便利なマルチストリーミングを提供するので出発点として良く、すでに利用できる優れたライブラリも多く、今後さらに良くなり最適化される可能性も大きい: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
    従来より少し良い転送プロトコルを使うだけでも大きな利益が出る自然な領域なので、これから10年のQUICが楽しみ
    • 新しいことを試してみたくてQUICから始めた
      ただし現在実装されているTCPプロトコルはQUICより少し速く、追加のチューニングが足りないせいかもしれない
      付け加えると、macOSでのQUICはLinuxと比べて遅い
  • JetStreamの直接の競合に見える？ 1年未満でここまで進んでいるのは印象的
    https://docs.nats.io/nats-concepts/jetstream
    • JetStream、Kafka、Redpanda、RabbitMQ Streams、Fluvioのように、メッセージストリーミングソリューションはかなり多い
  • Kafkaや、Rustで書かれたKafkaの競合であるFluvioとどう比べればいいのかよく分からない
    RabbitMQのようなメッセージキューにより近いのだろうか？
    https://www.fluvio.io/
    • メッセージストリームなので、Kafka、Redpanda、RabbitMQ Streamsプラグインにより近い
      Fluvioは実際の製品で、背後に会社もあるのでより成熟しているが、Iggyを競争力のあるメッセージストリーミングソリューションにするための独自のアイデアがある
    • FluvioはFlinkとKafkaの両方を置き換えることを目指しているのではないか？ 知ったばかりなので理解しようとしているところ
  • 数年前に友人とGoで似たものを作った
    https://github.com/thibauts/styx
    • かなり似ているように見える
      なぜもう作業を続けなかったのか気になる
  • いつか使ってみたい。ただ、その前にRustを学ぶ必要がありそう
    付け加えると、サイトの美的センスが気に入った
    • 複数のSDKがあり、ブログはRustのZolaエンジンを使っている
    • ブログ記事で他のプログラミング言語向けSDKに触れられているので、Rustを学ばなくても使えそう
  • この記事を見て、Fluvioの出発点をあらためて見直すことになった
    過去数十年にわたって複数のドメインのデータ中心アプリケーションと長く関わってきた小さなチームで、JavaとJVMの代わりにRustとWebAssemblyベースのデータストリーミングに期待している
    2021年6月にCTOがFluvioのビジョンをまとめた記事はこちら: https://news.ycombinator.com/item?id=38880743
    比較の質問が続いているので、Fluvio側にある資料も共有できる。長いドキュメント化作業だが、今あるものは共有できる。Iggyも本当に良い仕事をしている
  • 本当に素晴らしいアイデアとプロジェクト
    ただ、使ってみる前に2つ理解しておく必要がありそう: サーバーインスタンスを2つ以上どう実行できるのか、2つ以上実行するときサーバー間のファイルシステムの相互作用はどうなるのか
    • ブログ記事には単一ノードで実行されると書かれている。まだクラスタ対応はない
      クラスタがサポートされればKafkaと競争できると思う
  • monoioを選んだのは意外
    私の理解ではnightlyコンパイラが必要で、プロジェクトを保守するうえで良い選択ではないと思っていた
    • nightlyは必要だが、使っている機能は5つだけで、そのうち1つは外部クレートを追加すれば取り除ける
      残りもほとんどはそれほど過激な機能ではない。コードを深く見たわけではないが、すべて納得できる。例えば1つは未初期化のコンテナを作るための標準ライブラリAPIで、コピーを取り除けるようにしてくれる
      stableで動作するglommioとmonoioを比較したことはないが、興味深そう
    • Monoioが最も性能の良いランタイムに見えるし、実際に使うのも簡単
      だからbleeding edgeなアプローチを選んだ。いずれにせよio_uringや他の最適化を実装するにはさらに数か月はかかるだろうし、コア部分の一部を書き直しながら、コアごとにスレッドを持つ構造へ移行する可能性が高い