要約

  • Ion Stoica は UC Berkeley の教授、Sky Computing Lab のディレクターであり、Conviva、Databricks、Anyscale の共同創業者でもある。Databricks は同氏を執行会長としている。
  • その研究は、Core-Stateless Fair Queueing と Chord から、Mesos のリソース提示、Spark のリネージ、Ray、SkyPilot に至るまで、分散状態をより単純なインターフェースの背後へ繰り返し移してきた。
  • これらのシステムは、学生、教員、エンジニア、オープンソース貢献者からなるチームによって生み出された。Stoica の役割は、共著者、助言者、研究所ディレクター、企業の共同創業者など、プロジェクトごとに異なる。
  • 抽象化はプログラミングと運用の負担を減らすが、ネットワーク、アクセラレーター、クラウド、価格、統治を均一にはしない。成功すれば、新たな制御層と依存関係が生まれる。

分散システムは、状態をどこに置くべきかという議論から始まる

分散コンピューティングは、クラスター、スケジューラー、ストレージシステム、クラウド、アクセラレーターといった仕組みから説明されることが多い。その製品群の下には、より根源的な設計上の問いがある。システムのどの部分が何を記憶し、どの構成要素が全体を見ないまま行動できるのか。

すべての状態を一か所に置けば、意思決定者が過負荷になるか利用不能になるまでは、判断を理解しやすい。状態を分散すれば規模と耐障害性を高められる一方、不整合、調整コスト、扱いにくい障害形態が生じる。問題をインターフェースの背後に隠せばプログラマーは助かるが、隠された作業が消えるわけではない。それは制御層の責任になる。

Ion Stoica の研究実績は、この緊張関係から見ると異例なほど一貫している。Core-Stateless Fair Queueing はフロー推定をネットワークの端へ移し、情報をパケットに載せることで、中核ルーターが通信ごとの表を持たずに済むようにした。Chord はノードとキーをリング上に割り当て、参加者が全体の所在一覧を維持せずにデータを探せるようにした。Internet Indirection Infrastructure はランデブー識別子を用い、通信を固定された宛先アドレスから切り離した。Mesos は一つのスケジューラーに全ワークロードを理解させるのではなく、アプリケーションフレームワークへリソースを提示した。Ray はタスクとアクターを公開し、配置と障害復旧をアプリケーションの下で管理した。

各システムは目的も成熟度も異なる。広く教えられるプロトコルにはなったが、普遍的な基盤にはならなかったものもある。オープンソースプロジェクトになったものもあり、複数は企業の技術的な源流となった。共通するのは、直接調整すれば高コストになる境界に、小さく拡張可能な取り決めを設けたことだ。

この連続性により、Stoica は現代の基盤を考えるうえで有用な視点を提供する。同時に、功績の帰属を誤る危険も生む。プロジェクトに助言した教授、アルゴリズムを形作った共著者、チームへ資金を配分した研究所ディレクター、会社設立を支援した創業者は、同じ仕事をしているわけではない。Spark は Matei Zaharia と AMPLab コミュニティから切り離せない。Ray の主要著者には Philipp Moritz、Robert Nishihara と、より広い RISELab チームが含まれる。Databricks は7人の共同創業者を掲げている。Berkeley の研究所は、誰か一人が所有するものではない学生、職員、コード、組織文化を提供した。

興味深いのは、一人の人物が成功したプラットフォームを次々と単独で生み出したという物語ではない。一つの研究計画が、複雑さが蓄積する場所を繰り返し見抜き、コミュニティが使えるほど狭く、産業が周囲に成長できるほど広い抽象化を築いた過程である。

初期の公平性研究は、状態を端へ移す代償を示した

Stoica は、それ以前にブカレストで学んだ後、2000年に Carnegie Mellon University で博士号を取得した。大学院での研究は、共有基盤を構築する人なら誰もが知る問題に向き合った。各利用者を追跡すれば公平性を実現しやすいが、全利用者の追跡はシステムの拡張を妨げかねない。

各フローについて個別のキューと速度推定を持つルーターは、きめ細かな判断ができる。混雑した中核ネットワークではフロー数が膨大になり、構成も急速に変化する。フロー単位の状態は、パケット処理を高速に保つ必要がある場所で、メモリー、処理能力、運用上の注意を消費する。

Dynamic Packet State と Core-Stateless Fair Queueing は、別の分担を探った。端の装置がフロー速度を推定して情報をパケットへ入れ、中核ルーターは完全なフロー表を維持せず、そのラベルを確率的なパケット破棄の判断に使えた。中核は文字どおり状態を持たないわけではなく、集約設定を保持してアルゴリズムを実行した。個々のフローに関して状態を持たないという意味だった。

この設計は、Stoica の経歴を通じて繰り返される型を示す。複雑さを消すのではなく、より多くの文脈や能力を持つと考えられる境界へ移す。端はトラフィックを分類し、信頼できる推定値を作らなければならない。パケットは中核が理解できる形式で情報を運ぶ必要がある。端が虚偽の情報を出したり測定を誤ったりすれば、中核の近似も誤り得る。カプセル化や暗号化は、フローの定義を難しくすることがある。

したがって抽象化は、それが責任をどう再配分するかで評価すべきだ。中核で状態を持たない公平性は、中心を単純かつ拡張しやすくする一方、端との信頼関係を生む。この交換条件は、管理された一つのネットワーク内では魅力的でも、方針や利害を共有しない組織間では難しくなる。

この研究は、公共インターネットにおける普遍的なサービス品質アーキテクチャにはならなかった。その重要性の一部は方法にある。仕組みを高コストにする状態を特定し、どこならより低コストで表現できるかを決め、移動によって失われる精度や信頼を明示するという方法だ。

後のシステムは、同じ考え方をキー、クラスターリソース、データリネージ、AI タスクへ適用した。単位は変わったが、設計上の本能は変わらなかった。

Chord は変化するピアツーピアシステムをリングへ単純化した

2000年代初頭のピアツーピア研究の隆盛は、すべての所在を把握する中央管理機構がないまま、機械が参加、離脱、故障するシステムを生んだ。その環境で特定の対象を探すことは、検索の問題であると同時に保守の問題でもあった。設計は今日の照会に答えながら、明日のために必要な情報を絶えず修復しなければならなかった。

Stoica、David Karger、Frans Kaashoek、Robert Morris、Hari Balakrishnan らのチームが SIGCOMM で2001年に発表した Chord は、意図的に簡潔な答えを示した。ノードとキーを同じ識別子空間へハッシュし、論理リング上に並べ、各キーを後続ノードに割り当てる。参加者は直後のノードに関する情報と、より遠い「フィンガー」の対数個の集合を保持した。検索は、キーを担当するノードに達するまで、徐々に近い識別子へ進んだ。

コンシステントハッシュは、参加構成が変わったときに移動させるデータ量を抑えた。安定化手順は、構成変動の後に後続ノードとフィンガーの情報を修復した。この設計は、各参加者にネットワーク全体を認識させなかった。照会を効率よく転送するのに十分な構造化された知識だけを与えた。

Chord が代表的な教材になったのは、仕組みが推論できるほど簡潔でありながら、分散システムの現実を示すだけの奥行きを持つからだ。識別子上の距離はネットワーク遅延ではない。論理的に近いノードが物理的には遠いことがある。複製、アクセス制御、ストレージ整合性、悪意ある参加者への防御は、基本検索プロトコルの外側にある。アプリケーションはなお、キーの意味と、利用不能または競合するデータの扱いを決めなければならない。

論文の影響力を、一つの実運用サービスや単独著作と混同してはならない。Chord はチームの成果であり、その後の分散ハッシュテーブルは別の構造やセキュリティ特性を発展させた。公共インターネットの大部分が、一つの Chord リングへ再編されたわけでもない。

長く残る教訓は、限定された知識についてである。オーバーレイが名前と責任の安定した関係を提供すれば、参加者は大規模で変化するシステムを移動できる。リングは、信頼性も接続状況も均一でない機械群の上に置かれた制御上の抽象化として働く。

この発想は、後にクラウドの制御層で別の形を取る。アプリケーションがすべてのホストを把握することはほとんどない。論理的な要求を現在のリソースへ対応付けるスケジューラー、メタデータサービス、所在管理機構に依存する。Chord は、分散化が主な関心事だった時代に対応付けの問題を明示した。後のシステムは、同様に狭いアプリケーションインターフェースを保ちながら、性能のために制御層の一部を集中させることになる。

Internet Indirection Infrastructure はアドレスと端点の結び付きを緩めた

通常のインターネットルーティングは、パケットを宛先アドレスへ送る。受信者が移動する場合、複数の受信者が同じデータを受け取る場合、サービスが複数の端点から選択したい場合には、このモデルは扱いにくい。Internet Indirection Infrastructure、すなわち i3 は、送信者が識別子を宛先とし、受信者がその識別子を現在位置へ結び付けるトリガーを設定する、IP より上位の層を探った。

ランデブーポイントは、アプリケーションが使う名前と、現在トラフィックを受信できるアドレスを分離した。同じ仕組みで移動性、マルチキャスト、エニーキャスト、サービス合成を表現できた。受信者は、すべての送信者に新しいアドレスを知らせる代わりに、トリガーを更新して位置を変えられた。

一つの間接化機構を複数のネットワーク機能に再利用できる点で、この抽象化は優美だった。難しさは、間接化基盤そのものが重要設備になることにあった。ノードには到達可能性、性能、悪用への防御が必要だった。識別子には認証と方針が求められた。オーバーレイ経由の転送は遅延を増やしたり、基盤ネットワークの経済性を無視する経路を作ったりし得る。

i3 は通常のインターネットルーティングを大規模に置き換えなかった。この結果は研究の失敗を意味しない。表現力の高い仕組みと、実際に展開できる制度との間に繰り返し現れる違いを示している。公共のランデブー層には、運営者、動機付け、セキュリティ、移行経路が必要だ。既存のインターネットには、アドレス割り当て、DNS、コンテンツ配信システム、アプリケーション固有の回避策がすでにあり、それぞれに利害関係者がいた。

Chord と i3 をめぐる Stoica の研究は、すべてのルーターを置き換えなくても、ネットワークの上に新たな制御点を設けられることを示した。同時に、新しい制御点には統治が必要だとも示した。ソフトウェアが識別子を分散しても、誰かがノードを運営し、悪用対策を定め、容量の費用を負担する。

この経験は、現在のマルチクラウドシステムにも重要だ。ワークロードをクラウド事業者へ割り当てる仲介機構は、ランデブー型オーバーレイとは異なるが、同じ制度上の問いに直面する。抽象化は要求を転送できる。しかし選択肢を同等にはできず、仲介者の中立性も保証できない。

Berkeley はオープンソースコミュニティを研究手法の一部にした

Stoica は University of California, Berkeley に着任し、その研究は、教員による方向付け、学生主導のシステム構築、査読研究、早期のオープンソース公開を組み合わせる研究所モデルの一部となった。研究課題の発展に伴い、研究所の名称は AMPLab、RISELab、現在の Sky Computing Lab へと変わったが、その手法は一貫して見分けられる。

研究システムには、アルゴリズムを単独で実演するだけでなく、実際のワークロードに対応することが求められた。学生は本格的な実装を築き、利用者が現れ、運用からの反応が研究所へ戻った。この経路は影響力を高め、企業設立を可能にした一方、学術的発明と商用製品の単純な区別を曖昧にした。

教員は問い、資金、指導、アーキテクチャ上の判断、組織的な継続性を提供した。学生や職員がコードを書き、実験を行い、システムを前進させる保守担当者や創業者になることも多かった。産業界の協力者はワークロード、ハードウェア、制約を提供した。オープンソース貢献者は発表後にプロジェクトを変化させた。成功した成果は、この役割の網全体に属していた。

複数のプロジェクトで目立つ Stoica の存在は、この構造を見えにくくし得る。Spark の学術史では助言者かつ共著者だったが、当初の研究を率い、技術面と会社の双方で中心人物となったのは Matei Zaharia である。Ray は Philipp Moritz、Robert Nishihara と、より広いチームの研究から生まれた。Mesos にも複数の主要設計者がいた。正確な説明は Stoica の役割を小さくするのではなく、研究所の指導者が実際に何をするのかを明らかにする。

Berkeley のモデルは、特有の企業も生み出した。Databricks と Anyscale は、プロトコルを隠してその利用権を売ることから始まったのではない。利用者がすでに自ら動かせるオープンソースシステムを中心に設立された。商機は、それらを大規模に運用、統合、支援しやすくすることにあった。

この構図は長期的な緊張を生む。オープンソースは採用を広げ、共有技術基盤を確立できる。管理サービスは技術開発の資金を生み、顧客の負担を減らせる。企業には、オープンソースの中核の周囲へ独自の制御、統合、経済性を加える動機がある。学術研究所は発表と一般性を重視し、企業は信頼性、差別化、収益を重視する。

Stoica の経歴はその接点にある。重要なのは、論文が新興企業になったことより、研究所が外部でも生き残れる抽象化を繰り返し選び、それを実運用へ運べる組織を築いたことだ。

Chord、Spark、Mesos、Ray は、コードだけでなく語彙を通じても広がった。リング、リネージ、リソース提示、タスク、アクターは、分散動作を説明する概念をエンジニアに与えた。すべての内部構成要素を先に学ばなくてもチームが推論できるシステムは、採用されやすくなる。

大学の研究はこの過程の中心にある。論文は仕組みと前提を定義する。講義とセミナーは、それらを共有された思考モデルへ変える。学生は発想を企業、オープンソースプロジェクト、後の研究へ運ぶ。したがって教授および研究所ディレクターとしての Stoica の影響は、自ら書いたコードや創業者という肩書を超える。

語彙は教条にもなり得る。整った図は、抽象化が機能する条件を利用者に忘れさせる。Chord のリングは物理的遅延を見えにくくし、Spark のリネージは再計算コストを見えにくくする。アクターは通常のオブジェクトのように見えても、メッセージは遅延し、障害は分散している。良い教育は、インターフェースと同時に、そのほころびも教える。

Stoica が2024年に National Academy of Engineering の会員へ選出されたことは、分散システムとクラウドシステムにおける累積的な実績を評価したものだ。この栄誉が協力者から功績を移すわけではない。複数の難しいシステム境界を、他者が構築できるほど理解可能にした研究者の役割を反映している。

それは最も長く残る基盤への影響かもしれない。製品名は変わり、企業は事業を広げる。明確な抽象化は、何世代ものエンジニアが利用し、批判し、前提が成立しなくなった時を認識できるため、生き残る。

Conviva は分散システム研究が動画視聴を改善できるかを試した

Stoica は、後の Berkeley 発のデータ企業や AI 企業に先立つ2006年に Conviva を共同創業した。同社は、ネットワーク、測定、アプリケーション体験を結び付ける問題に取り組んだ。ストリーミング品質は、一人の関係者では全体を見渡せない連鎖に依存する。視聴者の接続、コンテンツ配信経路、プレーヤーの動作、端末、コンテンツ提供者のすべてが、停止や再生開始時間に影響し得る。

測定プラットフォームは視聴ごとの情報を集め、サービスが配信方法を選択または調整するのを助けられる。Stoica の研究との概念的なつながりは、Chord や i3 の一つのアルゴリズムが製品になったということではない。分散した観測結果を、体験に影響を与えられる速さで制御判断へ変える必要があるという点にある。システムは不完全なデータから推論し、自ら所有しないネットワークをまたいで動かなければならない。

Conviva の設立は、学術的なシステム思考を商用サービスへ移す初期の経路を示した。顧客が購入したのは分散状態に関する論文ではない。ストリーミングを可視化し、分析し、運用上の行動へつなげる能力だった。同社は実トラフィック下でデータ処理基盤、統合機能、モデルを維持し、コンテンツと配信を担うチームへ結果を説明しなければならなかった。

ここでも功績の境界は重要だ。Conviva は多数のエンジニアと経営幹部を持つ企業であり、現在の製品を一人の創業者へ帰属させることはできない。同社の財務実績や非公開企業としての所有関係も、Stoica 個人の実績とは別である。重要なのは時間的、組織的な点だ。Spark や Ray が企業の基盤になる前から、ネットワーク規模の情報をアプリケーションサービスへ変える事業の構築を支援していた。

この経験は、後の研究全体にも見える教訓を強めたと考えられる。基盤は、顧客が管理できる単位を変えると価値を持つ。ストリーミング事業者は、すべてのパケット経路を考えたいわけではない。利用者体験を信頼できる形で把握し、改善する方法を求めている。複雑な分散動作を運用上の選択へ変えつつ、その下にある不確実性が消えたふりをしないとき、抽象化は成功する。

Mesos はスケジューリングをリソースをめぐる交渉に変えた

データセンターが多様なワークロードを共有クラスターへ集約するにつれ、中央スケジューラーは不可能な目標に直面した。すべてのフレームワークの優先順位、配置規則、実行モデルを理解しようとするか、リソースを公開して専門的なフレームワークに判断の多くを委ねるかである。

Mesos は後者を選んだ。エージェントが利用可能なリソースをマスターへ報告し、マスターがフレームワークへリソースを提示する。フレームワークは提示の一部を受け入れ、自らのスケジューラーに従ってタスクを起動する。作業の完了や割り当ての変更に伴い、リソースは戻される。

この二段階設計により、マスターはあらゆるアプリケーションを理解する頭脳ではなく、仲介者になった。Hadoop、MPI などのフレームワークは、独自のスケジューリング論理を手放さずにクラスターを共有できた。クラスター運営者は割り当て、上限、公平性の仕組みを通じて方針を維持し、フレームワークは提示されたリソースに適合するタスクを決める責任を保った。

この分離は拡張性を高め、新たな問題も生んだ。フレームワークが不適切な配置を選んだり、リソースを非効率に保持したりする可能性がある。提示によってクラスターが細切れになり、大きなジョブに合わなくなることもある。異なる種類のリソース間の公平性には方針が必要だった。マスターとエージェントにも耐障害性と信頼できる状態が必要だった。

コンテナプラットフォームなどのスケジューラーが異なる制御モデルを発展させたものの、Mesos はより広いオーケストレーション分野に影響した。その貢献は、一つの設計が勝利したという主張より、アーキテクチャ上の議論として理解しやすい。共有基盤は、リソース割り当てとアプリケーション固有のスケジューリングを分けることで拡張できる。

同じ議論は Stoica の以前の研究にも現れる。中心は共通の取り決めを強制するのに十分な状態を保持するが、すべてのフローやワークロードの詳細までは表現しない。より多くの文脈を持つ層へ判断能力が移る。層間のインターフェースが、システムの一貫性を左右する。

運営者にとって教訓は実践的だ。抽象化は方針を消さず、誰が実装するかを決める。リソース提示はフレームワークに自由を与え、その動作をクラスター効率の一部にする。運営者は中央の割り当て機構だけでなく、提示を受け入れる全フレームワークの判断も監視しなければならない。

Mesos は、クラスターが複数のプラットフォームを載せるプラットフォームになれることを確立する一助となった。Spark はデータアプリケーションに、さらに上位の抽象化を与えることで、その環境を活用した。

Mesos は割り当てを提示として表現したが、その提示は中立な資源の集合から生じたわけではない。フレームワークがリソースを見る前に、マスターが公平性、上限、優先順位を適用した。クラウドや AI クラスターでは、その選択が、どのチームに希少なアクセラレーターを与え、どの期限を遅らせるかを決める。

抽象化は共通の割り当てとワークロード固有のスケジューリングを分けるため有用だ。しかし、組織内の力を符号化している方針が、純粋に技術的なものに見えることもある。上限は予算と約束を反映する。優先度クラスは、どの作業を中断できるかを決める。予約は将来の容量を守る代わりに、現在の利用率を下げる。

現代のスケジューラーも、インターフェースが変わってなお同じ問題を受け継ぐ。自動配置は、選択を唯一効率的な答えとして示すのではなく、目的と例外を明らかにすべきだ。

Stoica に関係するシステムの歴史は、判断を境界へ移すことで拡張性が得られる場合が多いことを示す。統治には、中心に残る判断を名指すことが必要だ。誰かが依然として、提示を誰に与えるかを決めている。

Spark は失われた中間データを再実行可能な計算として扱った

Spark より前のデータ処理システムは、段階間の永続的な境界として中間結果をディスクへ書き込むことが多かった。この方法は障害復旧を支えたが、反復アルゴリズムや対話的分析を高コストにした。Spark の耐障害性分散データセット、すなわち RDD は、分割された集合を変換とリネージによって表現した。分割の一つが失われても、すべての中間結果を複製する代わりに、以前のデータから再計算できる場合が多かった。

この発想は、耐障害性をプログラミングモデルへ結び付けた。開発者は分散集合への変換を記述し、実行環境が各分割の生成過程を追跡した。作業中のデータをメモリーに保つことで、同じデータ集合を再利用するワークロードを高速化した。それでもシステムはシャッフルを行い、ストレージを読み、データの偏りに直面した。データ移動が無料になったわけではない。

Spark は、Stoica を含む多くの協力者が参加した Berkeley AMPLab コミュニティでの Matei Zaharia の研究から生まれた。その後 SQL、ストリーミング、機械学習、広範なデータプラットフォームへ発展する過程には、はるかに大きなオープンソースコミュニティが関わった。Stoica の発明と表現すれば、システムを率い、維持した人々を消してしまう。

Stoica の役割は組織の水準で重要だった。研究所はプロジェクトを支え、システム上の問いを形作り、研究を利用者へつないだ。2013年に会社が設立された際、Stoica は Databricks の7人の共同創業者の一人となった。Databricks は、運用一式を自ら組み立てずに Spark の能力を使いたい組織へ、管理された利用経路を提供した。

商用プラットフォームは後に、当初の RDD 論文をはるかに超えて拡大した。データ統治、レイクハウスアーキテクチャ、機械学習、AI サービス、セキュリティ、クラウド統合が製品の一部になった。現在の会社規模を、一つの論文や一人の創業者の貢献を正確に測る尺度にはできない。

それでも Spark は、Stoica の経歴における転換点である。抽象化の中心は、ネットワークパケットやピア検索から、プログラマーが見るデータと実行環境が見る復旧計画へ移った。リネージによって、機械の障害を決定論的な変換履歴の背後に隠せるようになった。

この移動は、新たな制御も生んだ。実行環境が配置、実行、再計算を決める。管理サービスは、バージョン、ストレージ統合、費用を決められる。プログラミングが容易になるほど、その容易さを実現する層への依存は強まった。

Alluxio はデータの所在が計算の抽象化を左右し得ることを示した

後に Alluxio と呼ばれる Tachyon は、計算フレームワーク間でデータを利用できるようにする分散ストレージ層として、Berkeley のシステム研究環境から生まれた。メモリーとリネージの発想を使ってアクセスを高速化し、アプリケーションを下位のストレージシステムへ接続した。プロジェクトと会社は独自のチームと統治の下で発展したが、研究所による制御層研究の広い物語に含まれる。

クラスターのスケジューラーは、利用可能な機械にタスクを配置できる。しかしデータが別の場所にあり、ネットワークがボトルネックになれば、その配置は不適切だ。データの抽象化は、共通の名前空間を示し、キャッシュや移動を管理することで摩擦を減らせる。すべてのストレージシステムを同一にはせず、整合性と耐久性の選択も消さない。

このプロジェクトは、一つの抽象化が別の抽象化の必要性を明らかにする様子を示す。Mesos は計算資源をフレームワーク間で共有した。Spark は分散集合をプログラム可能にした。共通データ層は、処理系とストレージの間で作業データを移すコストに対処した。構成が積み重なるにつれ、データの近接性、退避、復旧について食い違い得る制御層の数も増えた。

運営者にとって、これはリソース利用を一層ずつ最適化できないことの注意喚起である。スケジューラーが高い CPU 割り当て率を示しても、ジョブはデータを待っているかもしれない。メモリー内キャッシュが速度を高める一方で、別のワークロードに必要な容量を消費することもある。リネージは失われた分割を復旧できるが、再計算が遠隔ストレージを読み、ネットワーク負荷を急増させる可能性がある。

Stoica を Alluxio の単独の生みの親とすべきではない。ここで重要なのは概念上の関連性だ。Berkeley の一連の研究は、個別にはプログラム可能でも、組み合わせると非効率なシステム間に欠けているインターフェースを繰り返し発見した。新しい層は全体を使いやすくし、同時に、障害と方針を管理すべき新たな状態保持サービスを加えた。

Databricks はオープンソース採用を商業上の運用責任に変えた

研究論文は仕組みを説明し、選ばれたワークロードで評価できる。企業は、データ、セキュリティ要件、障害形態が論文の試験環境とは異なる何千もの顧客を支えなければならない。Databricks は、Stoica の経歴におけるこの組織的拡大の最も明確な例である。

同社は Ali Ghodsi、Matei Zaharia、Ion Stoica など Berkeley の同僚を含むグループによって設立された。現在の会社資料は Stoica を共同創業者兼執行会長としている。この職務は最高経営責任者、プロジェクト保守担当者、全製品の著者とは異なる。各サービスを運営する立場ではなく、企業統治と長期戦略を担う立場である。

Spark の商用化には、オープンソースの実行ファイルを提供する以上のものが必要だった。顧客は、クラスターの準備、更新、認証連携、データアクセス、性能診断、法令順守、予測可能な支援を必要とした。製品が広がるにつれ、会社は、価値も囲い込みも Spark だけでは説明できないプラットフォームを発展させた。

これはオープンソース基盤企業に一般的な経済構造である。共有プロジェクトは採用コストを下げ、原理上は利用者に退出経路を与える。管理サービスは運用を容易にし、別の環境へ完全には移せない機能を追加することで収益を得る。顧客は生産性を得る代わりに、サービス事業者との関係を受け入れる。

Stoica の研究テーマは、この魅力を説明する。一つの有用な抽象化により、顧客は機械ではなくアプリケーションへ集中できる。商用プラットフォームは、その約束を調達、セキュリティ、ライフサイクル管理へ広げる。隠されたシステムは大きくなり、サービス事業者の判断がもたらす影響も重要になる。

企業価値や資金調達は、技術的貢献を示す証拠としては不十分だ。数値は急速に変わり、会社に属するもので、一人の創業者に自動的に帰属しない。守り得る結論はより限定的である。Databricks は、ある組織が信頼性維持に必要な作業を引き受ければ、学術的な制御の抽象化が大規模な企業向けプラットフォームの中心になり得ることを示している。

その組織能力は、当初のソフトウェアと同じほど重要である。同時に、プラットフォームの将来が研究上の優美さだけでなく、顧客の経済性と企業の動機に従うことも意味する。

Ray はタスクとアクターを AI 実行環境の単位にした

機械学習アプリケーションは、バッチ型データ処理系には収まりにくい実行形態を生んだ。強化学習、シミュレーション、ハイパーパラメーター探索、モデル提供は、短いタスク、長期間存在する状態保持要素、細かな依存関係を組み合わせることがある。開発者には、プロジェクトごとに独自の分散システムを築かずに、この組み合わせを表現する方法が必要だった。

Ray は二つの主要なプログラミング概念を公開した。遠隔関数は分散タスクになり、クラスはアクター、すなわちメソッド呼び出しを受け取り、処理をまたいで存続する状態保持プロセスになれた。オブジェクトストアと制御要素が、そのインターフェースの下でデータとスケジューリングを管理した。アプリケーションは処理のグラフを記述し、実行環境がクラスター全体への配置と復旧を担えた。

このアーキテクチャが分散を消したわけではない。タスクを再試行できるのは、アプリケーションの意味上許される場合に限られる。アクターは、再構築が必要な状態を持ったまま故障し得る。オブジェクトはメモリーを消費し、ネットワークを移動する。スケジューリング判断は、アクセラレーター、プレースメントグループ、データの近接性と相互作用する。Python インターフェースは問題を扱いやすくしたが、無関係にはしなかった。

Ray の2018年の OSDI 論文は、Berkeley の RISELab チームの成果であり、主要著者には Philipp Moritz と Robert Nishihara が含まれる。プロジェクトはオープンソースコミュニティを獲得し、複数の貢献者が Stoica とともに Anyscale の共同創業者となった。Ray の実装と現在の計画は一人の教員助言者を大きく超えているため、功績の境界は重要だ。

Ray は、状態の置き場所に関する別の変化を示す。アプリケーションは機械ではなく、タスク、アクター、オブジェクトに名前を付ける。実行環境の全体制御要素と局所スケジューリング要素が、処理の配置と障害復旧に十分な知識を維持する。プログラマーは、より有用な構成単位を得る代わりに、ホストを直接制御する権限を手放す。

AI ではワークロードが急速に変化し、アクセラレーター群が高価なため、この交換条件は魅力的だ。同時に、実行環境が運用上の判断基盤になるため危険もある。スケジューラーの不具合、オブジェクトストアの圧迫、バージョンの非互換性は、多数のアプリケーションへ同時に影響し得る。API に記載がなくても、可観測性と更新規律がプログラミングモデルの一部になる。

したがって Ray の重要性は、分散 AI を単純にしたことではない。幅広い分散 AI アプリケーションを共通概念でプログラム可能にしつつ、難しい作業を組織が運用方法を学ぶ必要のある実行環境へ集中させたことにある。

Anyscale は Ray コミュニティそのものになることなく Ray を商用化した

Anyscale は2019年、Ray を中心とする商用企業として設立された。この関係は、以前の Spark から Databricks への経路に似ているが、組織も市場も同じではない。Ray は同社外の貢献者と利用者を持つオープンソースシステムであり続け、Anyscale は管理運用、企業向け統合、支援を提供する。

この区別は顧客にとって重要だ。プロジェクトの公開版は、保守担当者と貢献手続きによって統治される。ホステッドサービスは、製品計画、利用条件、商業上の優先順位に従う。コードは両者の間を移動し得るが、一方が他方の能力や方針を自動的に証明するわけではない。

管理された Ray は、大きな運用負担を減らせる。クラスター準備、自動拡張、イメージ管理、ログ、障害復旧には、多くのアプリケーションチームが自ら担いたくない技術作業が必要だ。サービス事業者はそれらを標準化し、多数の顧客から得た経験を適用できる。

サービスは、利用者と下位のクラウドの間に制御層も加える。実行環境の構成方法、対応機能、計測情報や更新の扱いを決める。顧客は Ray を独立して動かせる状態を保ちながらも、サービスの周囲に蓄積された管理手順、統合機能、運用知識へ依存する可能性がある。

Stoica の共同創業者という役割は、研究システムをこの商業組織へ結び付ける。ただし、現在のすべての製品判断に責任を負うことを意味せず、正確な役職は会社の最新ページに従うべきだ。安定して確認できる事実は、プロジェクトが実運用へ移る際に会社設立を支援したことである。

戦略上の問いは、商用層が保守への資金提供と採用拡大によってオープンな実行環境を強化するのか、それとも最も価値の高い運用能力が他で再現しにくくなるのかである。両方が同時に起こり得る。オープンソースコードが健全でも、顧客にとって管理プラットフォームの変更が高コストになることはある。

この緊張は Ray 固有の欠陥ではない。成功した抽象化がもたらす経済的帰結である。インターフェースが利用者を集めると、組織はその下に残る運用上の苦痛を取り除く事業を築ける。顧客は、その苦痛をどこまで忘れてよいかを決めなければならない。

Sky computing は違いが残るクラウド間で交渉する

Sky Computing Lab は、抽象化の問題を一つのクラスターやクラウド事業者の外へ広げる。理論上、クラウドアプリケーションは、価格、アクセラレーターの空き、データの所在地、耐障害性に応じて地域や事業者を選べる。実際には各クラウドのサービス、認証、ネットワーク、上限、課金方式が異なる。作業の移動には、外向き通信料金と長い転送時間がかかり得る。

SkyPilot は、この研究課題に含まれるプロジェクトの一つだ。利用者がジョブとリソース要件を記述すると、クラウドと地域の選択、リソース準備、ワークロード実行を支援する。利用可能なアクセラレーターを探し、保有する情報に基づいて費用を比較できる。クラウド事業者ごとに別の配備手順を書く必要を減らす。

このシステムは、クラウドを交換可能な商品にはできない。同じ種類のアクセラレーターでも、周囲のネットワークやストレージが異なることがある。管理データベースや認証サービスに、別の環境で直接対応するものがない場合もある。データ重力が計算料金を上回ることもある。外向き通信料金と契約上の約束は、見かけ上最も安い配置を変える。書面上の上限枠が、ジョブ開始時に利用できるとも限らない。

クラウド横断配置は、新たな信頼境界も生む。仲介機構やツールは複数環境の認証情報を必要とする。費用と可用性に関する判断の前提は見えるようにすべきだ。その障害は、本来独立している複数クラウドのワークロードを同時に止め得る。

Sky computing の主張は、一つの世界規模クラウドを約束するものではなく、交渉と可搬性の層として捉えると最も強い。検証済みの配備経路を持つ利用者は、供給不足や価格変化に対応できる。独自サービスへ依存するアプリケーションは、バッチジョブ自体を移せても制約を受け続ける。

Stoica の現在の研究上の立場は、分散検索とクラスターのスケジューリングに関する以前の研究を、この市場構造へつなぐ。割り当て単位は、別々の企業が所有するアクセラレーター群になった。制御層は CPU とメモリーだけでなく、金銭、規制、組織方針も考慮しなければならない。

この課題は、抽象化の限界を特に明確にする。ソフトウェアは共通の要求を示せるが、リソースを異なるものにしている契約、ネットワーク距離、電力制約を無効にはできない。良い制御層は、請求や障害が起きるまで違いを隠すのではなく、利用者がその違いを理解できるよう支援する。

vLLM と Chatbot Arena は研究所を AI 基盤の中心へ近づけた

Stoica の現在の Berkeley ページには、vLLM、Chatbot Arena、SkyPilot、Ray、Spark などのプロジェクトが掲載されている。この一覧は Sky Computing Lab の研究範囲の広さを示すが、ディレクターが各システムを個人的に設計したという主張として読むべきではない。

vLLM は、アクセラレーターのメモリーとスケジューリングが処理可能な要求数を左右する大規模言語モデル推論に取り組む。効率的なキー・バリューキャッシュ管理や連続バッチ処理などの技術は、利用率を改善できる。プロジェクトには独自の主要著者、保守担当者、コミュニティがある。Stoica との関連は組織上のものだ。彼が率いる研究環境と、高価な AI リソースをプログラム可能にする広い取り組みに属している。

Chatbot Arena は、人間による出力の選好比較を使ってモデルを評価する。事業者が選択的なベンチマークを公表しがちな市場で、共有できる情報を生み出す。このプラットフォームにも、標本抽出、代表性、悪用、統治の問題がある。順位は特定の集団と期間から得た観測であり、知能や安全性の恒久的な尺度ではない。

両プロジェクトは、制御層の問いがどのように広がったかを示す。実行環境は作業を配置し、推論処理系はメモリーを割り当てて要求をまとめ、評価プラットフォームは人間の注意を割り当てて比較の健全性を守らなければならない。いずれも、インターフェースを通じて希少なリソースをサービスへ変える。

ここでも研究所モデルが重要だ。プロジェクトは公開され、産業界の利用者を集め、後に企業や独立機関を支え得る。教員の指導は、著者関係を一つにまとめることなく、研究テーマと資金を結び付けられる。したがって研究所は、すべての功績をディレクターへ移すブランドではなく、システムを生み出す環境として理解すべきだ。

AI ではリソース費用が特に見えやすいため、影響は大きい。利用率のわずかな改善でも、運営者が必要とするアクセラレーター数を変え得る。スケジューリングの誤りは高価な機械を遊休させる。ベンチマークは投資の方向を変え得る。現在の抽象化は、ソフトウェアの生産性だけでなく、資本配分にも影響する。

したがって Stoica の現在の研究は、AI への突然の転換ではなく継続である。機械は変わったが、繰り返される問いは同じだ。多くの利用者が希少な分散システムを共有できるようにするインターフェースは何か。その共有方法を決める、見えない権限はどこにあるのか。

Kubernetes は Mesos や Ray を置き換えず、制御問題を分割した

現代の基盤をめぐる議論では、オーケストレーションシステムを一つの勝者を目指す競争相手として扱うことが多い。制御単位を調べるほうが比較は有用になる。Kubernetes は宣言型クラスターのモデルを通じてコンテナとサービスを配置、管理する。Mesos はフレームワークへリソースを提示した。Ray はアプリケーション水準のタスク、アクター、オブジェクトを管理し、Kubernetes がすでに準備した基盤上で動くことも多い。

これらのシステムは重なり得るが、同じ問いを立ててはいない。コンテナオーケストレーターは、Ray のヘッドノードとワーカー群が稼働している状態を保てる。それでも Ray は、アプリケーションのタスクをどこで実行し、状態を持つアクターをどう配置するかを決める。どちらかが始まる前に、クラウドのスケジューラーが地域を選ぶ場合もある。各システムは明確な置き換え関係ではなく、制御層の階層を構成する。

この階層は、各層が専門化できるため有用である。一方で、遅いタスクの原因が、アプリケーションのスケジューリング、コンテナ上限、ノード負荷、ネットワーク混雑、クラウド容量のどれなのか分かりにくくなる。複数層の自動拡張機構が同じ信号に反応し、そろって過剰拡張することもある。リソース要求は構成を下る際に、不完全に変換され得る。

Stoica の研究は、この階層構造が続く理由を説明する。一つの万能スケジューラーには、ハードウェア割り当て、サービスのライフサイクル、フレームワークの意味、アプリケーション依存関係を理解する必要がある。判断を分ければ、それぞれのシステムが発展できる代わりに、調整コストが生じる。

プラットフォームを選ぶ組織にとって、流行は適切な基準ではない。本当の問いは、どの判断をどの層が担い、競合をどう観測するかである。Ray を Kubernetes 上で動かせば、成熟した基盤管理とアプリケーション実行環境を組み合わせられる一方、チームは両方を理解する必要がある。運用負担は、スケジューラーを書くことから、スケジューラー間の境界を統治することへ移った。

AI のスケジューリングは資本配分の判断でもある

現在の AI ワークロードは、Stoica が長く追ってきた問いの経済性を変える。CPU クラスターはリソースを無駄にしても有用な作業を完了できる。大規模なアクセラレーター群は高価であり、不適切な配置、遊休メモリー、停止した集合通信が直ちに財務とエネルギーへ影響する。

Ray のような実行環境や vLLM のような推論処理系は、作業を詰め込み、状態を共有し、需要へ適応することで利用率を高められる。クラウド横断ツールは、希少なアクセラレーターを探せる。こうした判断が割り当てるのは機械時間だけではない。どのクラウド事業者が支出を受け取り、データがどこへ移り、どの電力・ネットワーク制約が使われるかも決める。

このため性能情報は、政治的にも商業的にも重要になる。特定のアクセラレーターやスケジューラーに有利なベンチマークは、調達先を変え得る。判断過程が見えない配置アルゴリズムは、組織が意図しない地域へ機密データを送る可能性がある。費用最適化機能が、時間単価は安いがネットワークの遅い機種を選び、ジョブ時間と総エネルギー消費を増やすこともある。

したがって制御層には、処理量より豊かな目的が必要だ。期限、障害許容度、データ所在地、炭素集約度、予約上の約束、中断コストを考慮する場合がある。一つの数値ではすべてを表せない。システムは、なぜ選択したのか、どの制約を緩めたのかを明らかにすべきだ。

異質なリソースに狭いインターフェースを求める Stoica の抽象化の伝統は、この環境に適している。危険なのは、管理チームが統治すべき希少性までインターフェースが隠すことだ。メモリー容量、相互接続、ソフトウェア版、供給契約が実行可能性を決める場合、単なる「アクセラレーター」という要求では足りない。

次に長く残るシステムは、要求を単純にしながら、交換条件を確認可能にするだろう。これは自動スケジューリングより難しい目標である。基盤ソフトウェアを、開発者向けの道具以上に、財務とエネルギーを統治する一部として扱う。

障害復旧は各システムに共通する隠れた取り決めである

Stoica の経歴に登場する抽象化は、構成要素が消えたときの対応が異なる。Chord はノード離脱後に転送状態を修復する。Spark は一部の失われた分割をリネージから再構築できる。Ray は、アプリケーションが定めた条件でタスクを再試行し、アクターを再作成できる。マルチクラウド起動機構は、容量がなければ別の地域を試せる。どの場合も、障害モデルが明示されて初めてインターフェースを信頼できる。

復旧は正しさと同じではない。純粋な計算の再試行は安全でも、顧客へ課金したり外部データベースを更新したりする処理の再試行は、作業を重複させ得る。リネージからデータを再構築して値を戻しても、外部への副作用は復元されない場合がある。ワークロードを別のクラウドへ移せば計算処理は復旧しても、データ所在地の規則に違反し得る。

制御層は、アプリケーションの意味をすべて推論できない。再試行、チェックポイント、複製、再起動方針といった仕組みを提供し、どの処理がそれらを許容するかの宣言を利用者へ求める。これも、より多くの文脈を持つ構成要素へ状態を移す例である。実行環境はどのワーカーが故障したかを知り、アプリケーションは作業を繰り返してよいかを知る。

運用の成熟には、この取り決めの試験が欠かせない。チームには、障害注入、冪等なインターフェース、永続的なチェックポイント、復旧時間が事業目標を満たすという裏付けが必要だ。健全な機械だけで実施したベンチマークは、主な約束が耐障害性にあるシステムについてほとんど何も示さない。

Stoica に関係するシステムは、速度や規模で称賛されることが多い。より深い共通の成果は、部分障害を例外的な謎ではなく、プログラム可能な事象にしたことだ。残る危険は、便利な復旧 API によって、アプリケーションが安全に提供できる以上のものを利用者が期待することである。

抽象化は性能、費用、セキュリティを通じてほころぶ

成功した基盤の抽象化は、詳細がボトルネックになるまで開発者がそれを無視できるようにする。Spark の利用者はデータフレームや SQL を扱えるが、データの偏り、シャッフル、ストレージがなお性能を決める。Ray の利用者はタスクを起動できるが、オブジェクト移動とアクター配置がなお遅延を決める。SkyPilot の利用者は GPU を要求できるが、上限、外向き通信料金、クラウド事業者の方針がなおジョブの経済性を決める。

このほころびは、抽象化が誤りだった証拠ではない。インターフェースが現実の境界に達した証拠である。問題は、宣伝が抽象化を、その境界がもはや重要でない証明として扱うときに始まる。

運用チームには、インターフェースの下を観測する能力が必要だ。どのリソースが割り当てられ、なぜその配置が選ばれ、データがどこへ移り、再試行が費用へどう影響したかを確認しなければならない。一つの指標を最適化する制御層は、別の指標を悪化させ得る。タスクのスケジューリングを高速化するとネットワーク競合が増えるかもしれない。失われたデータの再計算は複製費用を減らす一方、重要なジョブを長引かせる場合がある。クラウド横断配置は時間単価を下げても、転送料金を増やし得る。

統治も同じように表面へ漏れ出す。公開 API の背後に独自スケジューラーが隠れることがある。管理サービスが可搬性のあるコードを提供しつつ、適切な運用に必要な計測情報と経験を保持することもある。財団がプロジェクトを統治していても、保守担当者の多くへ資金を出す雇用主が数社だけという場合もある。利用者はやがて、誰がインターフェースを変更し、動作を廃止し、特定のワークロードを優先できるのかを知る必要がある。

Stoica に関係するシステムに価値がある理由の一つは、こうした境界を研究できるほど明示したことだ。Mesos はリソース提示とフレームワークの判断を分けた。Ray はタスクとアクターを下位のクラスターから分ける。Sky computing はワークロード要求を、それを満たすクラウド事業者から分ける。各分離は、責任を割り当てられる場所を生む。

次の技術課題は、その場所を消すことではない場合が多い。測定し、方針を公開し、利用者へ退出経路を与えることだ。抽象化は認知負荷を減らす。説明責任は、その軽減が盲目的な依存になるのを防ぐ。

抽象化により、アプリケーションはホストではなくタスク、アクター、データ集合に名前を付けられる。その結果、実行環境が認証情報、配置状態、多数の機械でコードを開始する権限を保持する。その制御層を侵害することは、一台のワーカーを侵害するより価値が高くなり得る。

Mesos のマスター、Spark の調整要素、Ray の制御要素、マルチクラウド起動機構は異なるアーキテクチャを持つが、いずれも信頼境界の一部になる。認証された通信、最小権限のクラウド認証情報、保護されたメタデータ、古い状態や偽造状態を受け入れない復旧が必要だ。

オープンソースとして見えることは検証を改善し得る。管理運用は修正と監視を一貫して適用できる。どちらも、安全な設定を保証しない。プラットフォームが安全な実行環境を公開しながら、広すぎる権限を持つサービスアカウントで動かす場合がある。利用者がワーカーを隔離しても、スケジューラーを利用者区分間の単一経路として残すこともある。

セキュリティモデルは抽象化に従うべきだ。タスクが作業単位なら、認証と方針をクラスターから無条件に継承するのではなく、タスク単位で表現できるようにすべきである。仲介機構が複数クラウドから選べるなら、その認証情報は各クラウドで無制限の権限を与えるべきではない。

Stoica の研究は、通常、拡張性とプログラム可能性から語られる。同じ状態の移動は、価値の集中した攻撃対象も作る。抽象化が分散システムの運用に優れるほど、自身の権限をより慎重に限定しなければならない。

オープンソースは著者関係を分散し、企業は運用責任を集中させる

Stoica に関係するプロジェクトは、複数の統治モデルにまたがる。Apache Spark は Apache Software Foundation のコミュニティ手続きに属する。Ray は独自の保守担当者と商用の生態系を持つオープンソースプロジェクトである。研究試作には、論文発表後に継続する組織がない場合もある。Databricks と Anyscale は、顧客、従業員、投資家に責任を負う企業である。

各モデルが解く問題は異なる。財団は中立的なプロジェクト統治と公開規律を守れるが、サービス水準の合意までは約束しない。企業は支援、セキュリティ対応、製品計画を提供できる一方、価格や機能構成を変更し、収益を生む顧客を優先できる。大学は危険を伴う発想を探り、手法を発表できるが、助成金と学生の在籍周期は長期保守を保証しない。

Stoica の経歴は三つすべてを横断する。それにより異例の影響力を持つと同時に、役割を慎重に記述する必要も生じる。創業者は株式や取締役会の役職を持っていても、オープンソースのコードを保守しているとは限らない。教授は、実装を学生が主導する研究を監督できる。執行会長は、最高経営責任者でなくても戦略へ影響を与えられる。

企業の財務的成功は、個人の貸借対照表でも、アルゴリズムが普遍的に優れている証明でもない。非公開企業の価値は変動する。収益は技術的価値だけでなく、販売、統合、市況も反映する。公開情報から確認できるのは、富を推測することではなく、会社設立と現在の役職である。

より重要な問題は、これらの組織が互いを強化するかどうかだ。商用企業のエンジニアは、実運用で学んだ修正を還元できる。オープンなコミュニティは、一社がインターフェース全体を決めるのを防げる。大学は代替案を試せる。利用者が中立性を期待するプロジェクトに企業の差別化層が依存すると、対立が生じる。

恒久的な公式はない。境界はプロジェクトごとに統治しなければならない。Stoica の実績は、研究から企業への経路が長く残る基盤を生み得る理由と、それを研究所から創業者への単純な所有権移転と見なしてはならない理由を示している。

Stoica の影響力は、他のコミュニティが築ける境界に基づく

Chord、Mesos、Spark、Ray を並べるだけでは、経歴が有名な固有名詞の一覧になってしまう。より有用なつながりはアーキテクチャにある。各システムは、分散した複雑さをより小さな取り決めで表現できる場所を見つけた。

中核で状態を持たない公平性は、中核が保持できない情報を端に運ばせた。Chord は全体の所在一覧ではなく、一貫した配置と部分的な転送状態を使った。Mesos はすべてのタスクを指示するのではなく、リソースを提示した。Spark はすべての中間結果を複製する代わりに、リネージを記録した。Ray は機械ではなく、タスクとアクターを公開した。SkyPilot はワークロード要件を表現し、その後でクラウド事業者間の選択を行う。

完全な抽象化は一つもない。協調する構成要素、正確なメタデータ、運用組織をそれぞれ前提とする。隠された層がモデルと異なる動きをすれば、どれも失敗し得る。限界があっても有用であることが、その成功を支えている。

一連の成果における Stoica の貢献はそれぞれ異なり、各チームには具体的な功績がある。長く残る彼の役割は、こうした境界をプロジェクト、研究所、企業へ変えることを支援した研究者兼組織構築者である。National Academy of Engineering は2024年、分散システムとクラウドシステムにおける広範な実績を評価して彼を会員へ選出した。栄誉は個人に属するが、システムは共同の成果であり続ける。

現代の AI 基盤では、同じ問いにかかる費用が大きくなっている。アクセラレーター、ネットワーク、電力を無造作に浪費することはできない。アプリケーションへ単純な見方を与える制御層は、利用率を改善し、開発を速められる一方、一つのクラウド事業者、スケジューラー、プラットフォームが権限を蓄積する場所にもなり得る。

Stoica の研究伝統の次世代は、抽象化がクラウドと企業の境界を越えても確認可能であり続けるかで評価されるだろう。利用者がすべての機械を知る必要がないからこそ、プログラム可能性には価値がある。耐障害性を保つには、自分に代わって判断する者が誰なのかを知り続けなければならない。