PR
[画像のクリックで拡大表示]

■米Microsoftが2005年8月終わりにベータ1を提供した「WinFS」は,同社が長年開発してきた次世代のデータ・ストレージ・エンジンである。「Object File System(OFS)」「Storage+」「Relational File System(RFS)」と名前を変えながら開発が続いたこのソフトウエアの歴史を振り返りながら,ベータ1の概要を解説する。前編で歴史を説明し,ベータ1の概要は後編で扱いたい。



 米Microsoftは2005年8月29日,次世代のデータ・ストレージ・エンジン「WinFS」の最初の一般公開ベータ版(ベータ1)を提供して,アナリストと開発者などを驚かせた。これがなぜ驚きなのかを理解するには,少し時計の針を戻して,何度も頓挫したこの技術の開発過程を振り返る必要がある。

起源はNT時代のCairoプロジェクト
 1990年代初頭のことだ。MicrosoftのWindows NT開発チームは多くの次世代技術に取り組んでいた。このプロジェクトは「Cairo(カイロ)」と呼ばれており,同チームの目標の1つに,当時「Object File System(OFS)」と呼ばれた新しいリレーショナル・ファイル・システムがあった。

 これはコンピュータの中にローカルに存在しているファイルなどのオブジェクトと,別のコンピュータに分散して存在するオブジェクトをストレージ・システムによってまとめて管理する仕組みになるはずのものだった。

 Cairo自体は,高度かつ豊富な目標を持っており,当時のハードウエア上では載せ切れない,基礎研究の色合いの強い理想を追求していた。そして,Microsoftはこれが変化するというほうに数年間を賭けた。それは,一般には成功したアプローチだったが,Cairoの場合は致命的な失敗だった。私たちが今,毎日使っている多くの技術はCairoに起源があるが,当時計画されたようにエレガントに登場したものはほとんどない。このうちOFSに相当するものは,まだ登場もしていない。

 しかし,OFSの開発は続いた。OFSはデータのアグレゲーション(集約)機能を実現することになっていた。例えばコンピュータ上の異なるドライブの中にあるデータを一覧できる疑似的なフォルダを作成できるはずだった。これはWindows Vistaの新機能の1つ「仮想フォルダ」(関連記事)じゃないかと思うならば,その通りである。同社が最初にこの機能を口外し始めて10年を経て,ようやくWindowsに追加されるわけだ(繰り返しになるが,本来計画されたものよりも優雅さに欠ける形ではある)。

 OFSを使えば,ユーザーはデータがどこにあるかを意識する必要がなくなる。データは自分のコンピュータだろうがネットワークの接続先にあろうが関係なくなるはずだった。今日,私たちはサーバー上のファイル共有機能などでファイルやフォルダなどのオブジェクトを扱っているが,アクセスするときに物理的な場所を指示する必要がある。これに対して,OFSは場所をユーザーが理解しなくてもよいように設計されていた。つまりサーバー上の「データ」という名前の共有フォルダを指定する代わりに,単純に言えば「Paulのデータ」という名前で,サーバー上の全ドキュメントを一覧できる疑似フォルダにアクセスすればよくなる見込みだった。

それは「Storage+」という名前に変わった
 1990年代半ばにCairoプロジェクトがご破算になり,そのオブジェクト指向技術が別の製品チームに引き継がれた。そのとき,OFSはStorage+という名前のプロジェクトに統合された。Storage+はCOM+やForms+と並んでMicrosoftが1990年代半ばに推進していたCOM(コンポーネント・オブジェクト・モデル)の基礎を成す技術だ。

 COM+に関して私が1999年に書いた記事には次のような記述がある。「Storage+は,NTFSファイル・システムをお払い箱にし,SQL Server 8.0をベースにした新しいリレーショナルなオブジェクト指向のファイル・システムで置き換える技術だ。Business Windowsの次のバージョン(Windows 2000の次バージョンで2003か2004)とともに登場すると思われ,ファイル・システムをリレーショナル・データベースに変え,検索処理を高速化する。そして,そうした検索にこれまでよりも高いレベルの粒度をもたらす」。

 この記述からお分かりのように,Storage+はOFSのアップデート版だったが,ちょっとしたひねりが加わっていた。このファイル・システムは,データの保存にリレーショナル・データベースの技術を利用する予定だった。当時,MicrosoftはSQL Serverをスクラッチで書き直しており(SQL Server 7.0は,それ以前のバージョンのSybaseのコードを捨て,新しく開発したものだった),それが驚異的な性能を証明しつつあったので,素晴らしい選択に見えた。

その次は「Relational File System(RFS)」と呼ばれた
 2000年に入り,私はWindows Blackcomb(開発コード名で,当時はWindows XP/Windows Server 2003の後継OSと考えられていた)がStorage+のようなリレーショナル・データベースを基にした新しいファイル・システムを採用するだろうという記事を書いた。

 しかし予定はすでに狂っていた。2000年4月のレポートで私はこう書いている。「本来,Windowsファイル・システムの置き換えとして設計されたStorage+は,SQL Serverのリレーショナル・データベース・エンジンのパワーで実現する計画だった。そのリッチな検索と索引付けの機能によって,ありとあらゆる場所のWindowsユーザーに恩恵を与えるとされた。しかしStorage+は,さまざまな理由でMicrosoftではまだ中途半端な位置付けにある。同社はこの製品,すなわち現時点ではRelational File System(RFS)という名前のものをSQL Server 2000と一緒に出荷したいと思っていた。だが,SQL Server 2000は短い開発期間で作られており,どちらかといえばマイナーなアップデート(元々それはSQL Server 7.5と名付けられていた)である。そのため,Storage+またはRFSは,予定の期間内に実装できなかった」。

 それに複数の事情が重なった。まず米Oracleはプラットホームに依存しないInternet File System(IFS)を2000年に発表した。それはOracleのデータベース技術を基にしたリレーショナル・ファイル・システムだったが,その機能に対抗するため,Microsoftは再度仕様を変えざるを得なかった。

 最初OFSと呼ばれ,次にStorage+,RFSと名前を変えたこの製品の完成が何度も延期されたおかげで,Microsoftのほかの製品チームは,テストがより進んだ別のデータ・ストレージ技術を利用しなければならなくなった。Active Directory(AD)とExchangeのメッセージ・ストアが(引き続き)Microsoft Accessを基にしたJetを採用しなければならなかったのがいい例だ。そうしてもう一度,この新しいリレーショナル・ファイル・システムの完成は延期された。

Longhornとともに「WinFS」の名前で登場
 Longhorn(開発コード名)が,Windowsの次期版としてのBlackcombの座を奪うころには(そしてマイナーとメジャーのアップデートの間を行きつ戻りつしたころに),Microsoftはそのファイル・システム・ストレージの計画を確定した。RFSは再び変貌して今度はWinFS(当時はWindows Future Storageの略とされた)となった。これは間違って,新しいファイル・システムというレッテルを張られる。実際には,元来10年前にOFSが約束していた機能を実質的にすべて包含する,NTFS上に築かれるストレージ・エンジンであった。

 MicrosoftがいつWinFSの存在を明らかにしたかを正確に指摘するのは難しい。だが,それはOFS/Storage+/RFSの単なる延長であるといってもいいだろう。2002年の私の記事,The Road to Windows Longhornでは,まだそのストレージ・エンジンをStorage+と呼んでいた。それが2003年版では「WinFS」に変わっている。この記事の中で私は一つの事実を明らかにしていた。WinFS自身はファイル・システムではなく,NTFS上で動作するという点だ。

 「よく間違えられるのだが,SQL Serverの『Yukon』に由来する技術を内蔵する予定のWindows Future Storage(WinFS)は,ファイル・システムではない,と同社のMark Myers氏は私に言った。WinFSはNTFSの上で動作し,そしてそれを必要とする1つのサービスである。『WinFSはNTFSの上に来る』と彼は言った。それはファイル・システムの上に座るものだ。NTFSは必須になるだろう」

WinFSが最大の注目を集めたのはPDC 2003
 WinFSが最大の注目を集めたのは,PDC 2003(関連記事)でのことだ。Microsoftはそこで初めて公にこの技術の詳細を明らかにし始めた。そこで同社は,次のWindowsのメジャー・バージョンであるLonghornが,WinFS,Avalon,Indigoの3つのコア技術の上に構築されることを明らかにした(これは偶然にも以前の世代の技術であるStorage+,Forms+,COM+にそれぞれうまく対応する)。

 私はPDCのWinFSセッションに参加してその能力に非常に感銘した。大事なのはもちろんデスクトップ検索である。これは以前から常に計画の一部として取り組まれていたものだが,突然登場したインターネット・ベースの検索のおかげで有名になった。

 「なぜ私たちはインターネット上で情報をそんなにすばやく見つけられるのか,自分のPC上の情報を見つけるには永遠に思える時間がかかるのに」という表現を使ってMicrosoftはWinFSの意義を訴えた(1年後にApple ComputerのCEOであるSteve Jobs氏がMac OS X Tigerの中のSpotlight[関連記事]——を宣伝したときはこの質問をあからさまに借用していた)。

 その後数カ月が過ぎ,Longhornのビルドがいくつか公開された後で,WinFSが同製品の完成に間に合わないことがかなり明確になった。一部の予想通り,WinFSは性能の大きな問題に悩まされ,正常なビルドを泥沼に落とし入れた。Microsoftは2004年5月に提供したWinHEC 2004 LonghornビルドにWinFSを内蔵させながら,当時は驚くほどWinFSについて沈黙を守った。数ヵ月後,私たちにその理由が分かった。

 2004年8月,3カ月近い沈黙の後に,MicrosoftはLonghornの計画を大きく変更して世間を騒がした。同OSが2006年の発売に再調整されたのだ。次世代のWindowsの3つの基盤技術「Avalon」「Indigo」と,それらをサポートする「WinFX API」はWindows XP Service Pack 2(SP2)とWindows XP Professional x64 EditionとWindows Server 2003 SP1用にも移植されることになる。一番危ぶまれたLonghornのコアな特徴の1つ,WinFSはLonghornから削除され,もっと後に出荷されることになった。

WinFSがLonghornから削除される
 この大きな変更のあと,Microsoftはすばやくダメージ回復に努めた。ユーザーが勘違いしてWinFSに結びつけていた多数の特徴をLonghornが依然として備えていると指摘したのである。当時MicrosoftのGreg Sullivan氏は私にこう言った。「Longhornは今でも大変リッチな検索能力を備えている。ローカル検索がWinFSによって実現されると思うのはある種の誤解だ。それらはプラットホームの別々のコンポーネントである。だからローカル検索はやはり利用できる。そしてLonghornにも新しいシェルの能力とともに,非常に競争力のある全文検索機能を載せるつもりだ。これは『Find My Stuff(必要なファイルをすぐ見つけ出せる)』という目標を実現する。しかし,それは複数のAPIを経由した深いインテグレーションとプラットホームから直接操作できる完全なリレーショナル・ストアにはならないだろう。だが,エンドユーザーにとってはそれは同じものだ。私たちはLonghorn内部をローカル検索するための非常に魅力のあるユーザー・エクスペリエンスを提供する」。

 Microsoftはさらにそのとき,WinFSはWindows XPやWindows Server 2003用には出荷されないだろうと発表した。それで私は他の多くの人と同じように,WinFSは全然開発が進んでいないと思った。Longhornの出荷と同時ぐらいに最初のベータ・リリースができるだろうと思った(そうMicrosoftが言ったからだ)。再びWinFSは実現しそうにない状態に落とされ,完全に忘れ去られた。

(後編に続く)