要約

  • PlanetLabのスライスは、各ノードで割り当てられたVMと資源の持ち分を、ネットワーク全体の一つの単位として扱う仕組みだった。統一された名前は物理マシンの所有権を含まない。
  • 中央のサービスは配置を組み立てられたが、実際に動くかどうかはノードマネージャー、空き資源、スケジューラ、ホスト組織の方針に依存した。
  • 実験の自由は、資源とセキュリティの隔離、利用量の記録、外部に見える行為を利用者へ戻せる責任の連鎖と対になっていた。

世界規模のアカウントは、世界規模の所有者を生まなかった

2000年代初頭、広域サービスを試す研究者は、各地の知人にアカウントを頼むことが多かった。数台なら動かせても、長距離の遅延、異なる負荷、別々の管理方針を含む再現可能な実験環境にはなりにくい。

PlanetLabは、その人脈依存の方法を共有施設へ変えた。研究グループは多数の拠点にサービスを置き、全体を一つの対象として扱えた。その対象がスライスである。

2004年の論文では、サービスは各ノード上のVMを通じて、CPU、メモリ、ストレージ、ネットワーク資源の一部を受け取る。分散したVM群が一つの複合体として扱われる。利用者には、世界各地に私有マシンがあるように見える。

しかし論文が述べるのは、隔離によって維持される「私有マシンのような見え方」だ。物理サーバーもキャンパス網もホスト組織のものであり続ける。グローバルな名前は、その帰属を上書きしない。

スライスの下にはローカルなsliverがある

一つのノードでVMに結び付けられた資源部分はsliverと呼ばれた。スライスは、複数ノードのsliverをネットワークとして束ねたものだった。

その上で、サービスは自分の構成を選べた。PlanetLabは全スライスに同じトンネル構造を与えず、一つの言語やランタイムも強制しなかった。研究者は既存のInternet上に独自のoverlayを作れた。

ただし、構成の自由はローカル資源を生成しない。過負荷のノードにCPU時間を作ることはできず、停止したマシンを中央の一覧だけで起動させることもできない。隔離されたVMを得ても、共有ホストのroot権限を得るわけではない。

2002年の設計ノートは、ticketとleaseでこの境界を表した。ticketにはノード、資源量、時間枠が書かれ、ノードのadmission controlが受け入れた時にleaseへ変わる。この文書は「進行中の草案」であり、全バージョンの完成仕様として扱うべきではない。それでも、中央が要求を運び、ローカルが実行可能性を決めるという線は明瞭だった。

PlanetLab Centralがあっても、各ホストには判断が残った

PlanetLabは完全な非中央集権ではない。初期構成にはPlanetLab Centralがあり、選ばれたノードのnode managerへVM作成を指示した。VMを作り、制限を適用し、最初のサービスを起動する特権的な機構も必要だった。

一方、ノードは独立した組織が提供していた。2006年の運用報告は、各組織が自分の資源利用に一定の制御を残すこと、成長のためには中央制御を小さくすることを要件として挙げている。

つまり、スライスはノードごとに権限境界を越える。中央の状態は「配置する予定」を示せても、稼働中のsliverを証明するのはローカルなnode manager、スケジューラ、容量、方針である。古い台帳は意図を表し、running codeが現在を表す。

登録ノード数と利用可能容量が同じでないのも、このためだ。VMが生きていても、資源クラスや制約まで同じとは限らない。

隔離は専有でもSLAでもない

PlanetLabには複数の隔離が必要だった。資源隔離はCPU、メモリ、ディスク、帯域の相互干渉を抑える。セキュリティ隔離は名前空間やデータを分ける。安定した実行基盤は、一つのVMが隣の基盤を書き換えないようにする。

どれか一つが他を証明するわけではない。安全に分離されたサービスでも遅延は揺れる。CPUの公平なshareはreservationではない。VM内で正しいプログラムも、ホスト側の帯域上限によって異なる観測値を出す。

運用経験は、初期のbest effortへの期待を修正した。PlanetLabは公平配分、明示的な予約、tokenを使うCPU制御を導入した。メモリ不足時には高消費VMを監視プロセスがリセットし、ホストは送信帯域を制限できた。

2006年に報告された一つの実験では、基盤の経路が74ミリ秒だったのに対し、特別なCPU設定前のoverlay RTTは76〜135ミリ秒だった。予約とリアルタイムスケジューリングで大半は狭まったが、kernel由来の揺れは残った。これはPlanetLab全体の点数ではない。グローバルなスライス名が専用ハードウェアを約束しなかった証拠である。

責任を追えることが、実験許可を支えた

実験トラフィックは実際のInternetへ出た。計測が第三者の侵入検知を作動させ、帯域試験が大学のgatewayを圧迫することもあった。研究目的が正しくても、外部への負担は消えない。

2004年の論文は、資源量だけでなく行為そのものを後からスライスへ帰属できる監査を求めた。後の設計原則はこれをchain of responsibilityと呼ぶ。外から見えるパケットを、責任を持つ利用者まで戻せなければならない。

この連鎖があれば、各ホストは全研究者と個別契約を結ばずに済む。制限を執行し、誰が送ったかを特定し、事故対応先を示せるからだ。スライスは実行空間であると同時に責任の受領書だった。

unbundled managementは唯一の権限を小さくした

PlanetLabは、ノードOSが直接提供するものをローカルな抽象へ絞ろうとした。スライス作成、資源探索、監視、ソフトウェア配布などの全体機能は上位サービスとして実装し、複数の方式が共有インターフェース上で並行して発展できるようにした。

それでも唯一の核は残る。ローカルVMを作り、制限を適用し、最初のサービスをbootする機構は必要だ。著者らはその例外を隠さなかった。目標は権限ゼロではなく、置き換え不能な権限を小さく、見える形にすることだった。

後年のHeng LuによるMinimum Initial SpecificationとRunning-Code Primacyは、この境界を読む現代的な視点になる。共通層は安全な合成に必要な最小限のローカル不変条件を持ち、グローバルサービスは交換可能であるべきだ。中央記録は、ノードが与えていない容量や権利を作れない。これは現在の編集上の比較であり、PlanetLabの著者に後世の思想を帰属させるものではない。

cloudを予見したことと、発明したことは違う

Princetonの2026年回顧によれば、PlanetLabは最大1,353ノード、717拠点、48か国に達し、2020年に正式終了した。Petersonの表現は慎重だ。PlanetLabはcloudを作ったのではなく、先取りした。

抽象資源を要求し、遠隔でソフトウェアを展開し、物理容量を複数利用者で共有する体験を早くから具体化した。同時に、今の管理画面が隠しやすい問いも見せた。どのホストが資源を許可したのか、クラスは何か、誰が拒否やリセットをできるのか、トラフィックの責任は誰が負うのか。

PlanetLabだけがVM、container、CDN、cloud orchestrationを発明したわけではない。すべてのcloudへ一本の系譜を引くこともできない。固有の成果は、異質で不足し、複数所有者を持つ実環境でグローバル抽象を試したことにある。

Larry Petersonを共同作業の中に置く

Larry Petersonは中心的な組織者、設計者、運用者であり、Princetonは現在、Robert E. Kahn Professor, Emeritus and Senior Research Scholarとして紹介している。ただしPlanetLabは一人の発明ではない。

2002年のblueprintはPeterson、Tom Anderson、David Culler、Timothy Roscoeの共著である。2004年論文にはAndy Bavier、Mic Bowman、Brent Chun、Culler、Scott Karlin、Steve Muir、Peterson、Roscoe、Tammo Spalink、Mike Wawrzoniakが名を連ねる。2006年報告はPeterson、Bavier、Marc E. Fiuczynski、Muirによる。dynamic sliceの文書はArchitecture Teamの成果で、PetersonとAmin Vahdatが編集し、複数の貢献者を記す。

単独の所有者を作らず共有基盤を成立させた歴史には、共同の著者名がふさわしい。

出典