マイクロカーネル

出典: フリー百科事典『ウィキペディア（Wikipedia）』

マイクロカーネルの概念図

マイクロカーネルとはオペレーティングシステムの設計思想の一つ、及びそのような思想に基づいて実装されたOSのカーネル部の名称である。OSが担う各種機能のうち、必要最小限のみをカーネルに残し、資源の抽象化を行うことで OS 全体の設計が簡素化できると共に、マルチプロセッサなど最新技術への対応を容易に果たすことで、結果的に性能も向上できるという考え方。カーネル自身はカーネル空間に残し、多くのOSサービスをユーザーレベルに移すことが可能になるため、安定性・堅牢性も期待できる。

カーネル本体が小規模な機能に限定されるので「マイクロカーネル」と呼ばれるが、必ずしも小さなOSを構成するとは限らない。また、小さなカーネルと動的モジュールの組み合わせを指す訳でもない。

マイクロカーネルの出現に伴い、従来型のOSを「モノリシックカーネル(一枚岩のカーネルという意)」と呼ぶようになった。

[編集] 特徴

純粋なマイクロカーネルでは、まずカーネル空間で提供される機能を、メモリ空間の仮想化、プロセス制御、プロセス間通信に限定し、割り込みなども全て通信にマップする。その上でファイルシステムやデバイスドライバといった準カーネル機能をそれらのアプリケーションとして実装し、ユーザー空間で動作させる。場合によってはそれらの機能セットをサーバと呼ばれる単位で複数動作させる。

このような形態を持つ事のメリットは、

アーキテクチャーに依存しないサービスの設計
OSやアプリケーションの並列性の最大限の活用
ネットワークへの透過的なアクセス手段の提供

などであり、副次的には

OS開発効率の向上（機能拡張、デバッグなどを容易に行える）
システム全体を止めずにカーネル以外のOSのアップデートを行うことができる
必要な機能のみを提供するアプリケーションに特化したOSを構築することが容易になる

なども上げられる。

また一般にマイクロカーネルでは資源の抽象度が高く、マルチプロセッサ対応やネットワーク透過の通信が自然に実装できるため、大規模な資源利用には有利である。

反面あらゆる場所でプロセス間通信を利用する為、機能相互のオーバーヘッドが大きく、モノリシックカーネルと同等の機能を実装した場合、数パーセントから数倍のロスが出る場合がある。特にコンテキストスイッチのコストを避けるため、必要な機能をカーネル空間に移し、見た目上モノリシックカーネルのように動作させる場合もある(co-location)。このようにパフォーマンスの問題からサービスをカーネル空間に置くという試みは古くはOSF/1 でも行われているが、抽象化した小型カーネル上にサービスを構築するという面からはマイクロカーネルであり、実装上の問題に過ぎない。

[編集] 歴史

マイクロカーネルは「UNIXの再設計」という観点から始まっている。

UNIXはファイルという概念でリソースを統一し、ファイルを扱う小さなプロセスをパイプでつないで相互通信させることにより、コンパクトかつ高機能なOS設計に成功した。しかし、利用環境の変化に伴い、必ずしもファイルとして扱えないリソースが増加している。例えばネットワーク通信はソケットという概念で行われるが、ソケットはファイルではない。結果的に、後付けで似て非なるコードがOSを肥大化させるという事態が発生した。

OSがたくさんのコードから成る事の直接的問題は、

カーネル自体が占めるメモリ領域（カーネル空間のフットプリント）が大きくなる
移植性やメンテナンスに不利

といったものである。さらに、計算機資源の増大に伴いマルチプロセッサや仮想メモリといった、UNIX開発時に想定していなかった実装が出現しており、それらを含めたOS概念のリファインが必要と考えられた。

そこで、「大規模な資源」と「高速な通信」を念頭において「相互通信するプロセスによる協調動作」というUNIXの発展理念に至ったのがマイクロカーネルである。UNIXではファイルを中心概念としていたが、マイクロカーネルではプロセスと通信に主眼を移し、割り込みやI/Oといったあらゆる資源が徹底的に抽象化されている。なお、この時、古くなった計算機の再利用も考慮された。つまり、移植性が高くコンパクトなOSを使えば、旧式システムであってもネットワーク上に接続して資源として活用する事ができるという考えである。

実際に実装されたMachでは、当初の予想通りコード量の削減には成功した。抽象度が高く、見通しの良いマイクロカーネルはトレンドとしては妥当であり、この時は将来有望な物と見なされていた。しかし、問題は、マイクロカーネルのパフォーマンス問題が予想以上に大きかった事である。初期のMachは純粋なマイクロカーネルでなく、BSDサーバとの複合カーネルだったが、それでも25%のロスがあり、これを完全なマイクロカーネルに移行した場合、機能によっては数倍遅くなるという結果となった。この問題はその後、L4プロジェクトでのプロセス間通信のチューニングなど、マイクロカーネル高速化技法の進展により解決に向かったが、マイクロカーネルにより簡略化されるはずが、高速化のために実装がより複雑になるというトレードオフも生み出した。

これらの問題は、マルチプロセッサが浸透するという技術予測が外れた事も大きい。またオーバーヘッドによるパフォーマンス上の問題も当初から予測されてはいたが、OSサーバとして旧来の BSD のコードが流用されていたため、並列度の向上によるメリットよりも、コンテキストスイッチの増大というデメリットが（予測よりも）大きくなったことも考慮する必要がある。一方、メンテナンスの面では、モノリシックカーネル実装であるLinuxの成功により、カーネル開発が適切に管理さえされれば、その大きさはメンテナンスの面からは大きな問題でない事が明らかになった。

こうして、一時は「全てのOSはマイクロカーネルに移行する」と考えられたが、90年代中ごろに、そのような見方は下火になっている。しかし、マイクロカーネルに利点がないわけではない。NeXTSTEP/Mac OS XやBeOS、NTなどはマルチプロセッサ対応やCPU移行時の高い移植性など、マイクロカーネルOSである利点を活かしている。また、Linuxのモジュール機構はマイクロカーネル的な概念であり、マイクロカーネルとモノリシックカーネルの利点を互いにとりいれる傾向があるといえる。

Windows NT も当初は純然としたマイクロカーネル的な実装が行われており、抽象度の高い設計を活かして様々なプロセッサへの移植も行われていた。4.0 を堺に、パフォーマンスに大きく影響する一部のサブシステムやデバイスドライバでカーネルとメモリ空間を共有する実利的な実装となっており、いわば「マイクロカーネルから出発したハイブリッドカーネル」といった趣ではあるが^[1]、マイクロカーネルとしての構造は依然残されている。また一時後退したものとされていたパフォーマンスを優先した反マイクロカーネル的な実装も、Windows Vista では実行環境の処理能力の向上やシステムの安定性・堅牢性等に対する要請から再びユーザー空間に切り離されるという「先祖返り」を起こしている。

[編集] 代表的な実装例とその特徴

Mach: 1985年からカーネギーメロン大学によってもっとも初期に開発され、マイクロカーネルの代名詞ともなったもの。このMachから派生したMac OS XやNEXTSTEP、MkLinux等は正しくMachの末裔と呼べるものではあるが、これらは実効パフォーマンスに対する配慮から一部のサブシステムをカーネル空間に同居させる実装を行っており、OSサーバをユーザー空間に置くという純粋な(理想的な)マイクロカーネルの実装ではない。
L4: 「Machは中途半端に大きなマイクロカーネルであり、徹底的にカーネルは小さくする方が性能が出る」という考えで作られたマイクロカーネル。モノリシックカーネルの置き換えを目指した初期のマイクロカーネルに対し、マイクロカーネルらしさを追求したことから第二世代マイクロカーネルと呼ばれる。L4には、Hazelnut, Pistachio, Fiasco, Embeddedといった複数の種類が存在する。高速メッセージ通信の実装によって、マイクロカーネルの欠点と言われた「メッセージ通信の多さによる非効率性」に対処することを目的にあげ、各種の工夫によってモノリシックカーネルに遜色ないパフォーマンスを出している。
Hurd: GNU によって UNIX 代替をめざし開発された、Mach上で動作するサーバ群。トレンドにあわせ設計がたびたび変更されたため、アナウンス以来長らく登場が待望されていたが、近年動作可能なものが発表された
BeOS: 独自のマイクロカーネル実装。優れたマルチプロセッササポートや、PowerPCからx86への移植の早さはマイクロカーネルの当初の理想を体現した物といえる。現在各種のフリー実装が進んでいるが、ここでもマイクロカーネルの利点が発揮されている。
Symbian OS: 独自のマイクロカーネルを実装した、イギリスのSymbian社が開発しているOS。主に組み込み用途で使われ、FOMAの903シリーズでもいくつかの携帯ベンダーで採用されている。