Hydro: Rust向け分散プログラミングフレームワーク

 (hydro.run)
1 ポイント 投稿者 GN⁺ 2025-02-02 | 1件のコメント | WhatsAppで共有

  • 紹介

    • HydroはRust向けの高水準分散プログラミングフレームワーク。
    • Hydroはスケーラブルな分散サービスを迅速に作成できるよう支援し、Rustがメモリ安全性を保証するように、分散安全性を保証する。
    • テストモードやデプロイモードで分散プログラムを簡単に実行できるよう支援する。

  • Hydroの特徴

    • Hydroは高性能なシングルスレッドDFIRランタイムで動作する分散データフロー言語。
    • 従来のアクターやRPCのようなアーキテクチャとは異なり、複数の場所にまたがって計算を記述できるコレオグラフィックAPIを提供する。
    • Hydro Deployと統合されており、ローカルやクラウドで分散Hydroプログラムを簡単にデプロイして実行できる。

  • コンパイルとデプロイ

    • Hydroは2段階のコンパイルアプローチを採用している。
    • Hydroプログラムは標準的なRustプログラムであり、開発者のノートPC上でデプロイ計画を生成する。
    • この計画はDFIRへコンパイルされ、分散システムの各マシン向けの個別バイナリを生成する。
    • 生成された計画とクラウドリソースの仕様を使ってクラウドにデプロイされる。

  • 活用事例

    • Hydroは、2相コミットやPaxosのような高性能分散システムの実装に使われている。
    • こうしたプロトコルを再利用可能なコンポーネントとして提供する分散システム標準ライブラリを開発中。

  • 注意事項

    • Hydroのドキュメントはまだ作業中であり、質問やバグがある場合はHydroのGitHubリポジトリにIssueを投稿することが推奨されている.

関連記事

1件のコメント

 
GN⁺ 2025-02-02
Hacker News のコメント

  • Hydro プロジェクトを説明する良い YouTube 発表がある。主に DFIR に焦点を当てている
    https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

  • 実際にどこへ適用するとよいのか理解するには、現実的な適用例がもっと必要に見える

    • まだコード例が完全にドキュメント化されているわけではないが、Paxos のより現実的な実装はここで見られる: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
      キー・バリュー・ストアのような、より複雑なアプリケーションも作っているところ

  • 間に独自ランタイムを持つ中間言語があるなら、Rust がもたらす利点を失うのか気になる
    別々の Rust バイナリを調整して、一貫して動作する分散システムにまとめる言語だと思っていたが、接着剤レベルではなく、最初から最後まで DFIR で書くように見える

    • Hydro の作業を率いる博士課程学生の一人。DFIR は中間層 DSL に近く、高水準言語の開発者が Rust コードをベクトル化のような低レベル最適化により適した形へ再構成できるようにするもの
      DFIR の演算子（map、filter など）は Rust クロージャを受け取るため、高水準言語から最終的な Rust バイナリまでそのまま渡せる。ユーザーの立場では DFIR を直接扱うことはない
    • それを聞いているなら、DFIR は Rust で実装されている

  • 本当に興味深い。この分野に詳しい人がいれば、先行研究や似たようなフレームワークが他の言語にあったのか教えてほしい
    データフロー周りは多くの人が取り組んできており、Materialize はかなり良いと思ったし、仕事で Kafka Streams も使ったことがある。これらをひとまとめにするフレームワークには意味がありそうだと思う

    • 初見では、データサイエンス分野の取り組みと概念的にかなり似て見える。ドキュメントでも言及されている Spark や Dask が思い浮かぶ
      特に Rust ベースなので、他の言語とうまく連携できる点が強みになりそう。Spark は移植性の面では JVM が良い選択だが、多くの複雑さを持ち込むし、Dask は Python 上で動くため、すでに Python を使っている状況でなければかなり重い依存関係になる
      分散 Rust 方面では Lunatic も見たことがあり悪くなさそうだったが、Hydro が目指しているものよりはもう少し低レベルに見えた
    • アクターモデルベースで分散システムに焦点を当てた Akka（https://getakka.net/、Java 版よりエンタープライズ感が薄い）と、rx（[https://reactivex.io/](https://reactivex.io/））のようなリアクティブライブラリを混ぜたものに見える
      そのため https://doc.akka.io/libraries/akka-core/current/stream/index... が最も近い比較対象かもしれない
    • このプロジェクトは RISELab から出てきたもの
      https://rise.cs.berkeley.edu/projects/
      データ処理と分散システムの大部分は、この研究室が行ってきた研究とある程度つながりがある

  • 取り組みは好感が持てるが、いつか Rust エコシステムに akka.rs のようなものが入ってくるといい

  • データフローの観点で timely [0] とどう比較されるのか気になる。中間表現でループのような制御フローを表現できるのかも気になる
    [0] https://github.com/TimelyDataflow/timely-dataflow

    • Flo 論文を少し読んでみたところ、Timely のようにデータフローグラフを記述するが、Timely のより実行中心の背景とは異なり、意味論的データフロー系の伝統から来ているように見える
      関数型リアクティブプログラミング、合成、フローのフロー、代数的演算子、証明指向に近い。Timely とは非常に異なる「進行」の概念を持ち、潜在的に無限のストリーミング入力でも合成が生成的であることを保証する点に重点を置いている
      実際、Flo には「適時性」の概念がほとんどなく、タイムスタンプもない。Timely のようにネストした反復をサポートするが、仕組みは非常に異なる。基本代数は極めて非循環的だが、ネストしたストリーム／グラフの形式化が反復を可能にしている
      論文は DBSP とも直接比較しており、私の理解では DBSP も Timely/Naiad 系列だ。著者らは Flo が Flink、LVars、DBSP のような複数の類似システムのための統一的な意味論フレームワークになり得ると見ている
      そのため Flo の著者らは Naiad/Timely をよく知っており、ネストした反復グラフから着想を得ているが、それ以外は大きく異なると見ている
    • 最新論文 [0] では Naiad（timely dataflow）に何度か言及している。例えば「Naiad [34] の ingress/egress ノードに着想を得て、ネストしたストリームは、より大きなストリームから来たデータ片を反復処理し、反復間の状態引き渡しを支援するネストしたデータフローグラフとして処理できる」と述べている
      [0] https://hydro.run/papers/flo.pdf

  • 各「プロセス」が別個のバイナリとしてデプロイされるなら、おそらく別プロセスとして実行されるという意味だと思うが、そうなるとオーバーヘッドの増加という点で問題がありそうに見える
    高速な通信をどう実現するのか気になる。高速な共有メモリ IPC のような仕組みを使うのだろうか？
    また、async との統合についての内容も見当たらない。良くも悪くも、ネットワークを扱うコードの圧倒的多数は async に移行しており、ネットワークが必要な多くの領域では、良い非同期ではないライブラリを見つけるのは難しい

    • 「分散」というなら、完全に別々のマシンに分かれているという意味だと理解していた。であれば、各構成要素が独立プロセスとして実行される必要がある
    • 現在の Hydro はネットワークアプリケーションに焦点を当てており、並列性の大部分は単一マシン内ではなくマシン間の並列性から来ている
      そのため、単一マシンでの並列性が欲しい場合は多少の追加オーバーヘッドがある。指摘のとおり、共有メモリによって今後ぜひ解決したい部分だ
      先週の POPL 2025 で、Hydro に参加している学部生が async-await のコードブロックを Hydro のデータフローへ自動コンパイルするコンパイラを発表した。まだ作業中で文書化されていないが、ここで見られる: https://github.com/hydro-project/HydraulicLift

  • 本当に格好よく見えるし、いくつか使い道が思い浮かぶ。特にデプロイ部分が独特に見える
    ドキュメントがさらに充実するのを期待していて、特に中核に見える Streams、Singletons、Optionals の部分が気になる

  • プログラミングモデルは気に入った。アプリケーションを書き換えるときにネットワーク最適化も行うのか気になる
    ネットワークのボトルネックや輻輳処理を扱うのか知りたい

  • データパイプラインに Ballista のようなものを使う場合とどう比較されるのか気になる
    Ballista は Apache Arrow と Apache Datafusion の上に構築されている恩恵が大きい

    • Hydro を作った人の一人です。Ballista と Arrow、Parquet 周辺のエコシステムは分析クエリ処理にはるかに重点を置いており、Hydro はクエリ処理の世界の概念を分散システム実装へ持ち込もうとするものです
      目標は SQL クエリを実行することではなく、分散システムのコード（例: マイクロサービス実装）を SQL クエリのように扱うことです。Arrow と Parquet の統合もロードマップに入っています