『x86 Solarisを救った男』に続き、同じくSolarisチームの開発エピソードをお送りしたい。今回は、Solaris 10から登場した非常に画期的なファイルシステム、ZFS（Zettabyte File System）についての誕生エピソードである。どう言ったきっかけで、或いはどう言った発想からこの斬新的な考え方のファイルシステムが生まれたのか、そしてパイオニアとなった開発者の苦悩を垣間見て頂ければ幸いだ。ZFSやファイルシステムについて多少の知識がないと、ちょっと彼らの会話についていけないかもしれないが、悪しからずご了承願いたい。ZFSについて勉強したい方はこちらを参照してほしい。 【参考資料】   Solaris 10のデータ管理   ZFS概要   ZFS技術資料   SDC Solarisアップデートセミナーレポートより

データが消えた！！ 

ZFSを開発した
ビル・ムーア（左）とジェフ・ボンウィック（右）

画期的な発明やこれまでの常識を覆す様な技術革新というのは、ちょっとした偶然の出来事やたわいもない会話などがトリガーとなって生まれることが多いものだ。Solaris 10の画期的な新ファイルシステム「ZFS」の開発プロジェクトも、些細な出来事がきっかけで始まったと言えよう。

1996年、Solaris開発チームがカリフォルニア州メンロパークの新しい拠点に引っ越したばかりのある日のことである。ハードディスクをアップグレードした途端、いきなりサーバがダウンしてしまった。
「突然、チームのホームディレクトリにアクセスできなくなっちゃって、電子メールも予定表のデータも、全て消えてしまったんだ。」とジェフ・ボンウィックは回想を始める。

ジェフは現在、サンでDistinguished Engineer（サンの開発技術者の最高の位）の肩書を持ち、ストレージ部門のCTO（最高技術責任者）を務める人物である。

皆して、ああだ、こうだと言い合うばかりで、誰も何もできない状態が数時間続いた。
ジェフは、Solarisチームの同僚のティム・マーズランド（x86 Solarisの救世主）のオフィスに行って、二人で『全く、やっかいなことになっちまったよ』とか『どうしてこんなことになるんだよ？』などと愚痴を言いながら頭をひねっていた。

メモリで出来ることがなぜハードディスクでできないのか？ 

「これがメモリをマシンに追加する場合なら、こんな大げさなことにはならないんだよね。ただマシンのカバーを外して、DIMMを何枚か差して電源を入れるだけで、全て問題なく動作するのに・・・」とジェフがつぶやく。

しかし、その瞬間、ジェフは自分の一言に、閃いた。
「ハードディスクはDIMMに実に良く似ている。違うのは、ハードディスクには永続性があるがDIMMにはない点だけだ。メモリでやっていることがなぜハードディスクではできないんだろう？」

これについては、この一件のずっと後にZFSの副主任としてジェフのチームに加わったアーキテクトのビル・ムーアという男が、分かりやすい例でこんなふうに説明している。
「例えば、Firefoxを入れたら、たくさんメモリが必要になったとするよね。そこでメモリを増やすわけだ。しかし、メモリを増やしたからといって、dimmconfigを実行したり仮想DIMMを作成したりする必要はない。これはメモリが、オペレーティングシステムによって「リソース」のひとつとして管理されている為なんだ。」

2000年、ジェフにはちょうど特に担当するプロジェクトがなく、次にやりたいことを決めようとしていたところだった。その頃、サン内には新たなファイルシステムを開発する許可を得ていたグループが、名目上は3つあったが、優れたアイデアがいくつか出ていたにもかかわらず、それをまとめ上げようとするグループがなかった。
ジェフは、これまでの常識では考えられない様な画期的な方法が絶対にあるはずだと確信し、新たなファイルシステムの開発に着手することを決意した。

苦難の日々～知らないからこそ困難に立ち向かえた～ 

しかし、それが形になるまでに、4年もの歳月を費やすことになろうとは、当時のジェフには予測ができなかった。

「それがどれほど困難なことになるか少しでも分かっていたら、そんな決心はしなかっただろうな。知らないからこそ厳しい困難にも立ち向かえたんだと思う。」ことジェフは回想する。

このプロジェクトの為にジェフは、5～6人という小さなチームを要請した。ところが上司は、大胆にも彼に80人もの部下を与えたのである。ジェフは、この様に突拍子のないアイデアを持って不意に上司の元に押しかけた挙句、80人もの部下を割り当ててもらえるなんてことは予想だにしていなかった。上司は何も言わなかったが、まるで『お前ならできる。』と背中を押された様な気分であった。

一見、幸先の良いスタートに見えたプロジェクトだったが、しかしながら、世の中そんなに甘くはなかった。斬新的なプロジェクトに対する社内の抵抗や反対、政治的な駆け引きはどの企業にもつきものである。1年もの間、ジェフは技術的な問題とは関係ないことにさんざん体力を消耗することとなり、なんとかプロジェクトをうまく進めようと努力したのだが、結局、初めから仕切り直すことを決意する。

ジェフは、社内の軋轢に嫌気がさしていたのに、開発プロジェクトを諦めてしまわなかったのは、マット・アーレンズというエンジニアがこのプロジェクトに携わる為に、1年も前から雇われていたことを知ったからである。ジェフは、彼の存在を知ってプロジェクトを見限るという宣告をするわけにはいかなかった。

マットとジェフは2人きりになると、ホワイトボードの前で1日に5時間もかけて、あらゆるアイデアを検証しながら濃密な時間を過ごし、すぐさまコーディングを開始した。2001年7月のことだ。こうしてその4ヶ月後には、新しいファイルシステムの最初の基本バージョンがユーザ領域で動作するようになり、その1年後には、Solarisのカーネル内で動作するまでになったのである。

助っ人、現る。 

ビル・ムーアがこのプロジェクトに参加したのは、新しいファイルシステムが UNIX カーネルにマウントできるようになった約6ヶ月後、2003年6月のことである。

ビルは1996年に最初にサンに入社し、サーバサイドの仕事に取り組んでいたが1999年には退社して、企業向けストレージの新興企業である3PARdataを設立、ハードウェア及びソフトウェアの設計全般をはじめ、同社のあらゆる側面に関与していた。このときの経験は、彼が2003年にサンに戻ってきたときに大いに役立つことになる。

「僕はx86のパフォーマンスに取り組む為にサンに再雇用されたんだが、ジェフに会う度に『ほら、このファイルシステムを調べてみて。僕たちがここでやっていることを見てくれよ』と言われたものだ。」と、ビルはその頃のことを振り返る。「彼とは非常に親しい関係になっていたんだよね。『さあ、僕のマシンの電源を抜いて。違うよ、本当に抜くんだってば。』と言うのでその通りにしたところ、そのマシンには全てのファイルがそのままの状態で残っていたんだ。」
ビルは、ジェフは自分にZFSの仕事をさせようとしていることにうすうす気づいた。

ジェフが、マシンにZFSをインストールして試しに使い始めたところ、いくつかのファイルの書き込みを始めて直ぐにハードディスクから『ウィー、ウィー、ズズズ』と悲鳴をあげるような音がした。ジェフはストレージ機器の新興企業で働いた経験があったので、この音を聞いてパフォーマンスに問題があるのでは？と感じた。

そこに、ブライアンという同じSolarisチームの同僚が現れ、『僕が取り組んでいるこのDTraceという機能を使ってみたらどうだろう』とビルに助言してくれた。その時点では、SolarisにDTraceは組み込まれていなかったので、ビルは、ある時点のビルドを彼のホームディレクトリから取り出して自分のデスクトップマシンにDTraceをインストールして、試してみたのである。ビルはこうして5分もしないうちに、必要としていた入出力データを手に入れた。正に、Solarisエンジニア達はDTraceをSolarisのカーネルそのものの開発に役立てていたのである。

ビルは、そこで、時間に対して論理ブロックのアドレスをプロットしたところ、論理ブロックアドレスの値の小さい部分と値の大きい部分に、はっきりとした帯状の分布が浮かび上がった。これは、基本的にハードディスクのシーク操作が、この2つの帯の間において最高速度で行われている、ということを示している。ビルにはこの問題の修正方法が分かっていた。

ビルが、ジェフに『入出力スケジューリングの周辺で何かしようとしてないか？』と尋ねたところ、『いや、ハードディスクはだんだん賢くなっているからね。我々は全ての入出力データをただハードディスクに送り、処理させているだけなんだ』とのこと。
これに対してビルが、『うーん、でも実際にはハードディスクはそんなふうに動作しないよ。』と思わず言葉を返した瞬間から、彼はZFSに携わることになり、入出力スケジューラの開発を手がけることになったのである。

「心を解き放て」～今までの考え方では問題は解決しない～ 

簡単に言うと「ZFS」とは、単純な管理機能、トランザクション・セマンティクス、及びエンドツーエンドのデータ整合性を備えた、新しい種類のファイルシステムである。現在、ZFSは、Solaris 10を世界中で最も進んだオペレーティングシステムたらしめている特徴の1つとして認識されているが、ここに至るまでに、政治的にも技術的にも数々の障害が立ち塞がってきたのである。

技術者にとっての最も大きな政治的問題は、ZFSを試しに使ってみてくれる人はあっても、開発責任担当を引き受けてくれる人がなかったのだ。例えば、プロジェクトが長引くと、途中で担当役員が変わるということはよくあるが、元の役員は別の役割に就き、新しい役員は別の優先事項を抱えてやってくる、という可能性がある。そうこうするうちに、新しい担当役員が持ってきた別の優先事項に、ジェフの非常に優秀なスタッフを5～6名も持って行かれてしまうという事態に陥ってしまった。
『本当にやり遂げられるんだろうか？』という率直な疑問は、当初からジェフの脳裏から離れなかった。政治的な問題だけでなく、技術的にも検討すべきことがあまりに多かったからである。

しかし、彼の場合、新しい問題が発生した時に、“前はどうやっていたか？”などということには興味がなかった。ただ知りたかったのは、今まで、“○○は出来ない”と、多くの人が思い込んでいた制限の中には、実は単なる習慣的な思考があったりするものだ。『前からそうしていたから』『誰も出来た人がいないから』という、過去から引きずっている知識や経験が、新しい発想を邪魔するのである。

ジェフは言う。「知らないこと、そしてその無知を積極的に利用することだよ。」
「何かについて多くの専門知識を持っていることが不利になることもあるんだ。最初からその問題をある決まった方法で見ることになるからね。そもそも何かの専門家であるとは、プロである故にその過去の経験や知識で形成された固定観念に囚われがちなんだ。だからこそ僕は、非常に深い概念のレベルで破綻している問題を扱う時に、敢えて、その道の素人や初心者を参加させるんだ。」
OSの素人、それがビルだった。事実、ジェフは最初、長年UNIXに携わるベテランの同僚に相談したのだが、ハードディスクをメモリの様に振舞わせることは困難であるという理由を延々と聞かされただけだった。

「心を解き放て。」（Free Your Mind）

ビルが呟いた。「これは映画『マトリックス』の台詞だよね。心に留めておきたい言葉なんだ。ZFSに先立つテクノロジを作り上げた人々だって、全くの門外漢というわけではなかったんだ。彼らは、当時としては妥当な理由から、あらゆることをやってみた。しかし、現在の世界は15年前の世界とは違う。そこで、『そうした根拠は今でも妥当なのだろうか？』という疑問が湧いてきたんだ。」

エンドツーエンドのデータ整合性が最重要課題だ！ 

「結局、ファイルシステムがやっているのは、読み取るブロックの内容が以前書き込んだものと同じになる様に、ブロックに読み書きすること。これはシステムのストレージにとっては基本的な保証事項だけど、その通りに動作しなくなる原因はいくつも存在するんだ。」とジェフは説明する。

ハードディスクのメディアエラーが起こってビットデータの一部がおかしくなることもあれば、ハードディスクの1つが故障することもある。ハードディスクからマシンへの読み込みの途中でビット反転が起こる可能性もある。それにハードディスクに関するファームウェアの間違いで、誤ったブロックが与えられることもある。とにかく、ありとあらゆるおかしな現象が生じる可能性があるのだ。だから、将来はエンドツーエンドのデータ整合性を提供することが、もっと重要になってくると、ジェフは考えた。

「ファイルシステムの設計では、これまでずっと『bcopy（）は使うな。そのデータには触れるな』ということが最優先事項だった。」
これは、パフォーマンスの点でコストがかかりすぎるからだ、とビルは説明する。
15年前は、データの引き渡しによって実際にパフォーマンスが損なわれていたので、当時としてはこれは正しい前提だったが、しかし、今やCPUの処理速度は15年前に比べて、メモリの10倍、ハードディスクの100倍にもなっている。つまり、データを渡してチェックサムを計算しようとするときは、CPUの全体ではなくほんの一部しか使われない。それなのに、誰もが些細なCPUの使用率を問題にしているのだ。

そこでZFSでは、処理の1つとして、データのチェックサム計算を毎回行っている。
かつてのチェックサム計算は、全てのデータに問題がないか確認する為に行われており、大変負荷の高い処理だったが、今ではかつての様な厄介な負荷はない。実際問題としても、現在で既に500GB、将来は1テラバイトにもなろうかという膨大なハードディスクドライブの容量を考慮すると、他の方法を受け入れることはできないのである。ファイルシステムチェックを実行する間、何時間もシステムをダウンさせておきたいとは誰も思わないだろう。それに、正真正銘のファイルシステムエラーが発生した時にそれが検出されず、チェックサムがなかったとしたら、全てのデータを作り直さなければならなくなってしまう。とんでもない量の入力が必要になってしまうのだ。

ZFSを用いれば、エンドツーエンドのデータ整合性は、もはやエンタープライズ向けのストレージシステムだけのものではなくなる、とジェフは言う。例えば、ノートPCに内蔵されている80GBのハードディスクのうち、1GBの領域が失われても、残りの79GBは完全にアクセス可能なままである。これは、ZFSのメタデータのコピーを、ハードディスク内の物理的に十分に離れた別の場所に保存しているからなのだ。
現在、ZFS以外のどのファイルシステムでもこの処理は実現されていない。

ZFSの目玉、DMU（データ管理ユニット） 

ファイルシステム、ボリュームマネージャ、ハードディスクというストレージ・アーキテクチャの各階層間のインタフェースは、以前からきわめて単純なものだった。ブロックを読み取ってブロックを書き込む、単にそれだけである。

これには利点もあるが、欠点もある。例えば、「次の5つのブロックは一緒に書き込まれるか、1つも書き込まれないかのどちらかでなければならない」という指示ができないのだ。また、こうしたソフトウェアには、その場でパフォーマンスの最適化を行う方法がなかった。しかし、ZFSではそれが可能になっている。

「全てのファイルシステムに等しく負荷がかかっているなら、従来のモデルの方が優れているだろう。しかし、普通は負荷が急激に増減するので、5つのファイルシステムには全く負荷がかかっていないのに、1つのファイルシステムは巨大なファイルを転送している、という状況が起こり得るわけだ。」とジェフは説明する。

そこでジェフらが取りかかったのが、ZFSの最重要項目であるデータ管理ユニット（DMU）だった。

「DMUの興味深い点は、外界に対して提供しているインタフェースが、ファイルやディレクトリの類ではないことだ。オブジェクトとそれに対するトランザクションがインタフェースになっているのだ。」とビルは言う。

例えば、ファイルのリネームを行う場合、DMUでは行うべき処理を、次のように記述する。

これはもう、ランダムな書き込みのストリームではない。DMUは、こうした各トランザクションを1つのトランザクショングループとしてまとめる役目をする。このトランザクショングループ内の処理は、全て成功するか全て失敗するかのどちらかだ。正にデータベースの様なものなのである。

信念と努力が日の目を見る喜び 

ジェフとビルはどちらも頻繁に顧客に対して講演を行っているが、ZFSに対する顧客の反応には驚きと喜びを感じている。

ビル：	「実際、驚異的なことなんだ。ストレージ事業の立ち上げに携わった経験から、あらゆるデータを完全で最新の状態に維持しようと、世界中の人々が非常に苦労していることは分かっていたけど、まさかこれ程とは思っていなかったんだ。人はZFSについて話を聞くと、ほとんど例外なく、まず『わあ、今すぐにでも手に入れて使わないと。これで例の問題は解決されるはずだ』と言って、その後に抱えている問題の内容を口にするんだよ」
ジェフ：	「僕たちは皆長い間、無名のまま薄暗い部屋の中で苦労を重ねてきた。それは本当に信念に基づく活動だったんだ。古い問題に対して新しいアプローチを採用する時、そのアプローチが市場に受け入れられる保証はどこにもない。実際に市場に出すまでは、決して分からないんだ。」 「しかし僕たちは、顧客の抱える問題と私たち自身が抱えている問題には、同じものが多い、と気づいたんだ。最初にティム・マーズランドと話した時、僕たちは自分自身を技術者としてではなく、一顧客としてこの問題を見ていたからね。」

その後、ジェフとビルは、各地で「ジェフとビルによる説明会（Jeff and Bill Show）」を開催した。彼らにとって長い間の苦労が報われた最も誇らしく楽しい日々であった。「僕たちがZFSの売り込みをしなければならなかったことは一度もないんだ。ただZFSについて説明するだけでよかったから。それに、会場の雰囲気が変わっていく様子を観察するのは楽しいもんだよ。腕を組んだ大勢の人々を前にして、説明会は大抵45分の時間枠で始まるんだけど、ところが2時間経っても説明会は終わっておらず、誰もが身を乗り出し、驚いた顔で質問を投げかけているんだ。」

肩書： 米サンマイクロシステムズのストレージ部門CTO（最高技術責任者）、Distinguished Engineer。 職務： 単純な管理機能、トランザクションセマンティクス、エンドツーエンドのデータ整合性、及び普及型ハードウェアを用いての素晴しいスケーラビリティを備えた新しい種類のファイルシステムであるZFSのチーフアーキテクト。 名言： 「自分が新しい問題提起をした時に、前はどうやっていたかなんてことには興味がありません。ただ知りたいのは、今まで制限されていると人が思い込んでいたことの中で、何が基本的なことで何が排除できる習慣的なものなのか、ということです。」 学歴： デラウェア大学（University of Delaware）で数学の学士号を、スタンフォード大学（Stanford University）で統計学の修士号をそれぞれ取得。 職歴： 現在のオペレーティングシステムの大半で採用されているスラブアロケータ（slab allocator）を考案。kstatやlockstatの様な観測ツールを開発。mutexesやrwlocksを含むコアとなる多くのSolarisサービス、優先度継承、コールアウト、ファイル記述子管理、分解能の高いタイミング設定、LZJB圧縮アルゴリズム、libkvm、及び、仮想アドレス割り当ての開発に従事。 特許： 登録済み、出願済みのものと合わせて50件以上。 嫌いなもの： HTML形式のみの電子メール。「今、私に必要なのはプレインテキストを読む為のブラウザです。無駄ばかりのものより価値があります。」 あまり知られていない事実： コーヒーは豆から挽いて飲む。

肩書： ハードウェア／ソフトウェアアーキテクト。米サンマイクロシステムズのシステムグループに所属。 職務： サンの画期的なファイルシステムZFSを世に送り出したチームの副主任。 名言： 「ZFSに先立つテクノロジを作り上げた人々だって、全くの門外漢というわけではありませんでした。彼らは、しかるべき理由（当時としては妥当な理由）から、あらゆることを行いました。しかし、現在の世界は15年前の世界とは違います。そこで、この疑問が出てきました。『そうした根拠は今でも妥当なのか？』」 学歴： ミシガン工科大学（Michigan Technological University）で電子工学の学士号を、ミシガン州立大学（Michigan State University）で計算機科学の修士号をそれぞれ取得。 職歴： 1996年にサンに入社、サーバのSun Fire x800シリーズに取り組み、システムコントローラソフトウェア用のフレームワークの設計と実装に従事。Sun Fireに搭載されたUltraSPARC-IIIの主任ソフトウェア技術者。1999年にサンを退社して3PARdataという企業向けストレージの会社を設立、そこでハードウェア及びソフトウェアの全般的な設計と実装など、同社のあらゆる側面に関与。2003年にサンに復帰した後は、ストレージ業界の専門知識をZFSとサンの次世代ストレージサーバの設計に活用中。 特許： 登録済み、出願済みのものと合わせて45件程。 嫌いなもの： 「所有しているものと自分自身の違いが理解できていないように思える高学歴の人々」 あまり知られていない事実： カートが見当たらなかった為、データの入ったSun Fire X4500データサーバをキャンパスの向こう側まで手で運んだことがある。

ご意見・ご感想をお聞かせください

この記事は参考になりましたか？ 参考にならない   参考になった   非常に参考になった コメントがございましたらご記入ください

ページ先頭へ