クラウドOSについてもう一度考えてみる
SACSIS2010でNakajimaさんの講演を聞いたり、twitterでPlan 9カーネルをモジュール化できないかというつぶやきが流れていたりしたので、勢いで書いてみた。
マイクロカーネルの定義
以降、マイクロカーネルの話が出てくるので少し前置きを。マイクロカーネルかモノリシックカーネルかという議論は正直どうでもいいし、厳密な定義なんてないんじゃなかいかと思うが、ここでは、OSの機能とそれを支える機構を分離したカーネルアーキテクチャと定義したい。もう少し具体的に言うと、一般的に前者の機能部分はOSサーバ（OSパーソナリティ）というユーザランドプロセスとして実装されるが、これらのOSパーソナリティの実現基盤としてのカーネルをマイクロカーネルと呼ぶことにする。
この定義を当てはめると、Plan 9はマイクロカーネルとは言えない（「Plan9はマイクロカーネルか？」）。
クラウドOSとかマイクロカーネルにまつわる話
SACSIS2010の招待講演はJun Nakajima＠Intelによる「Hardware Technology Trends and Cloud Operating Systems: Toward the Next Generation of Distributed Systems」だった。同氏はその昔、Chorusマイクロカーネル上にSVR4サーバを実装していたりしていたそうで、関連して1992年のUSENIX Workshop on Micro-kernels and Other Kernel Architecturesでの議論を引き合いに出していた。取り上げられたOSはAmoeba、Mach、Plan 9、Chorus、Windows NTだ（後述のレポートによると、それ以外にも多くのカーネルに関する発表があったようだ）。Dave Presotto*1がPlan 9のoverviewを話したようだ。余談だがNTについてはDavid Cutlerが話をしている。Nakajimaさんはこの中で今も生きているのはMac OS XとしてのMach、組込みといったニッチな分野でのChorus*2、NTの三つだと言っていたが、Plan 9も忘れないでね！
Nakajimaさんは続いて分散OSが失敗したのは、単一のOSのコンポーネントを分散化するというアイデアがよくなかったからである。仮想化技術をベースとして複数のマシン／OS（サービス）がオーケストレーションする形の分散OS、すなわち「クラウドOS」は有望なアイデアである。と述べていた。
話は1992年のワークショップに戻る。そこでの議論はPeter Langstonによる「Report on the Workshop on Micro-kernels and Other Kernel Architectures」にまとまられているが、図1の各カーネルの比較表がよくまとまっていてわかりやすいので引用する。
| Amoeba | Mach | Plan 9 | Chorus | NT | |
|---|---|---|---|---|---|
| Architecture | Centralized processor pool | Symmetric | Centralized processor pool | Symmetric | Symmetric |
| Model | Object-based | ? (whatever) | File-based | Object-based | Object-based |
| Communication | RPC multicast | Message + RPC | Streams + file system RPCs | Message + RPC + unreliable multicast | LPC + RPC |
| Naming | Capabilities + directory service | Port rights + naming service | File name space (directories) | Capabilities | Unified name space per machine |
| Protection | Capabilities | Port rights communication based | Owner/group/other (owner can be a set of users) | Capabilities | All objects protected with ACLs |
| Light-weight processes | Yes, kernel-scheduled | Yes | No | Yes | Yes, kernel-scheduled |
| Unix support | Slow source emulation | Yes | Almost exactly Unix with library level Posix | Yes | Posix support |
| Distributed applications (across net) | Excellent support | OK | Not really | OK | Yes, RPC based |
| Multiprocessor support | Yes | Excellent | Great UMA (SMP) support | Yes | Excellent |
| Virtual memory | Segments | Paging | Paging | Paging | Paging |
| Fault tolerance | Replicated services | No explicit support | Great backups | Dynamic reconfiguration | Mirroring, striping, duplexing, & others |
OSのコンポーネント化
Nakajimaさんの講演では「OSコンポーネントの分散化」と言及されたけど、マイクロカーネルではOSをコンポーネント化する際にマルチサーバという手法を選択した（もちろんBSD Liteサーバのようにシングルサーバという実装もあり得る）。つまりプロセス管理やファイル管理という機能毎にサーバプロセスを立てるアプローチだ。一方でLinuxなどのモノリシックカーネルは機能をモジュールとして分割して、必要に応じてカーネルアドレス空間にロードするというアプローチでコンポーネント化を進めた。
Plan 9の場合は、カーネルはモジュール化されていないし、一見マイクロカーネルに近いアプローチにも見えるのだが、抽象化のレベルというか考えが違う。「Plan 9のお話」などでも書いたが、UNIXカーネルがIOの多重化装置として動作するのに対して、Plan 9カーネルはサービスの多重化装置として動作する。OSとしてのリッチな機能性はユーザランドプロセスに追い出して、カーネルは9Pメッセージの交通整理に徹して、極力小さく単純にするという考えだ。カーネルとアプリケーションの関係性を脱構築*3したとも言える。
そこでマイクロカーネルと同様に性能問題が浮かび上がってくる。実際マイクロカーネルと言われるMac OS XだってFreeBSDはカーネルに入ってしまっているし、Windows NT系だってOSサービスの多くがカーネル内で動いている。Plan 9はあまり性能をシビアに考えているようには見えないが、@80nashiさんによると、Plan 9カーネルでもrioの/dev/drawとTLSは性能問題からカーネルに組み込まれるようになった経緯があるようだ。
クラウドOSとPlan 9
ちょっと話が脱線してしまったが、もちろんサービスを提供するプロセスはリモートにいても構わない。で、ファイルベースでサービスを切り口にすると言うのは、緩やかなオーケストレーションによる分散システムとでもいうべきクラウドOSと相性がよい気もするのだが、どうでしょう？ マイグレーションを考えると、VMベースと比べてプロセスベースではカーネルとの分離が難しいという技術的な課題はあるんだけど。また、オーケストレーションの手段としてWebサービスインタフェース（REST、SOAP、WSRF、何でもよいけど）は最適なんだろうか？ Plan 9から学べるところはまだありそうだ。Ken Thompsonの考えた「クラウドOS」とはどんなものだったのか。
