|
| Japan Worldwide |
この雑誌の要約にある一文、
は、特にブライアンに当てはまる。と言うのも、ブライアンの発明したDTraceは、ソフトウェア・エンジニアたちが数十年にわたって苦闘してきた問題を解決するものなのだ。
DTrace機能とは Solaris 10オペレーティング・システムでは、システムやアプリケーションの性能が最適な水準に達しない理由を、従来よりもはるかに優れた方法で確認できる。Solarisに組み込まれた『DTrace(ダイナミックトレース)』は、システムの問題の原因をリアルタイムで追跡するツールである。管理者や開発者はDTraceを使用することによって、ユーザ・プログラムの挙動だけでなくオペレーティング・システム自体の動作も調べることができる。 従って、DTraceを使用すればシステムがどのように動いているかを理解したり、様々なソフトウェア層に渡る性能の問題を追跡したり、異常な動作の原因を突き止めたりすることができる。DTraceは、本稼動中のシステムでも安全に使用でき、システムやアプリケーションを再起動する必要もない。 システム運用管理者ならびにアプリケーション開発者の方々には、是非ともSolaris10のDTraceの持つ素晴らしさとメリットを体感していただきたい。
信頼してくれる人たちのために働きたい DTraceは、オペレーティング・システムと、その上で実行されるアプリケーション間が相互に作用する様子、つまり挙動を“丸見え”にする。DTraceは、ボトルネックがどこにあるかを特定したり、パフォーマンスが出ない原因を突き止めるのに最適な機能なのだ。 例えば、フィラデルフィア株式取引所の事例では、DTraceを使用して、動作の遅いアプリケーションを調査し、間もなく実行速度を3分の2に、またサーバのサイズを3分の1に短縮したという。 ブライアンは言う。 「サンには、サンを信頼してくれるお客様のために働きたいと考える人々が大勢いると思う。それは、ぼくにとって個人的に非常に重要なことなんだ。」 サンに入ったからこそ、実現できた ブライアンは1996年にDTraceのアイデアを思い付いた。ロード・アイランド州にあるブラウン大学でコンピュータ・サイエンスを学んでいた頃だった。 当時の指導教授は彼に対し、「それは不可能だよ」と言った。ブライアンは当時を振り返り、次のように話す。 「DTraceの実現方法について、ぼくはいくつかの具体的なアイデアを教授に説明したんだ。これに対する彼の反応は、『うーん、そうだね、もしこれが可能ならば、既に実現しているだろうよ』というものだった。そのときは、彼の言葉どおりに受け取ったよ。そして、実現できないのは、マイクロ・プロセッサか何か、他に関することで明らかな見落としがあるからだと思ったんだ。」
ブライアンは次のように述べている。 「ぼくはOSの開発に取り組みたくて、あらゆる企業を訪ねて回ったんだけど、サンには、他の企業の恐らく100倍のエネルギーがあった。他のコンピュータ会社はどこも、OSの開発グループには陰気な空気が漂っていた。既にOSの開発は過去のものと見なされていたんだ。」 しかし、サンは違った。 「あのとき自分がどこにいたか、正確に覚えている。あの出来事は、自分の人生の中で非常にはっきりと鮮明に記憶に残っている瞬間のひとつなんだ。ぼくたちは、国道101号線上を交差するウィロー通りを車で走行中だった。ぼくは青いミニバンの後部座席に座り、同じSolarisチームの同僚であるジェフ・ボンウィック(ZFSの発明者。前号参照。)に自分のアイデアの概略を説明しているところだった。 ぼくは彼にこう質問した。 『DTraceのアイデアは不可能かもしれない。もし可能ならとっくに誰かが実現してるだろうからね。だけど、なぜ不可能なんだろう?ぼくは何かを見落としているんだろうか?』。 そしたらジェフは、あっさりと『ぼくはうまくいくと思うよ。』と言ったんだ。」 ジェフのなにげない一言が、ブライアンの信念を確固たるものに導いた。 「そのときぼくは、サンという会社が、とりわけOSの開発において、今までに実現されていないというだけの理由で、これからも不可能だと考えるような企業ではないことが、はっきりと分かったんだ。これはとても重要なことなんだ。サンみたいなイノベーティブなカルチャーの中にいると、“頭のいい奴らが考えて答えを出せなかったんだから、まあ不可能だろう”といったような、至る所に蔓延しがちな考え方を、簡単に忘れさせてくれるんだ。」 難問が解決できたときの満足感があるからこそ、続けられた ブライアンがOS開発にこだわりつづけた理由、あるいはDTraceに対して自分の考えをあきらめられなかった理由が、彼をよく物語っている。 「ぼくはビデオ・ゲームや表計算ソフトの開発を経験し、自分は何でも開発できるのだという、奢った考えを持つようになっていた。そして、カーネルの開発に携わった。QNXというオペレーティングシステムを持つ、カナダの小さな会社だった。この会社には単一プロセッサのカーネルがあったが、ぼくは、マルチプロセッサ対応できるようにアーキテクチャを設計し、大変な目に遭ったんだ。」と彼は話す。 「実装に入ったところで、絶対に発生しないだろうと思っていたバグが見つかった。ぼくは、プログラムがおかしい場合、十分にテストすればバグは見つかると思っていたから、全く訳が分からなかった。ところが、OSのカーネル・レベルで実装を開始すると、症状はもっと厄介なもので、そういった甘い考えが通用しないことが分かる。それどころか、『作業を永久に続けても、このバグは見つからないだろう。そして、このバグのせいで出荷は無理かもしれない。』といった考えが自分を支配する。それが、OSの開発業務の怖いところなんだ。負荷テスト中にしか見つからなかったバグが、いつなんどき設計全体の欠陥となり、ソフトウェアの出荷停止なんて事態になるかなんて、全く分からないんだ。」 それが、ブライアンがOS開発をとことん追求しつづける理由なのだろうか? 「問題にぶつかって、解決できるかどうかわからないと思った時、後頭部の辺りから『最後には笑えるだろうよ』という声が聞こえたら、つまりそれは難問だということ。だけど、その種の問題を解決することで得られる満足感というのは、他では得られないものなんだ。」 業務本番環境で問題を解決できるDTrace DTraceの素晴らしさは、システムに潜在する難問を解決することだけではなく、様々な制約がある業務中の本番環境で問題解決を実現できることだ。 ブライアンは説明する。 「私たちが解決したのは主に、現場の稼動環境で一時的に不正な動作をする、あるいは一時的に動作が遅くなる問題だった。システムがクラッシュするといったソフトウェアの致命的な問題というのはいろいろな意味で解決しやすい問題なんだけど、『なぜシステムの動作が遅いのか?』といったパフォーマンスの問題を解決することは、ずっと難しいんだ。」 開発中にアプリケーションが不正な動作をする場合は、プログラマーが再コンパイルしたり、再起動して対処することができる。しかし業務の本番稼動環境では、そうは行かない。 彼は言う。 「業務処理中にOracleデータベースが不正に動作した場合、管理者にOracleを再起動するといった選択肢はありえない。Oracleを再コンパイルすることも絶対にできないんだ。では、本番稼動のマシン上では、ソフトウェアの動作をどのように確認するのか?DTraceが出来る以前は、できることはそれほど多くなかった。あるとしても基本的にはその場しのぎのツールだけだった。」 8年越しで実った夢 DTraceは全てのソフトウエア・エンジニアにとって、何よりも望まれている機能だった。 サンのSolarisチームにとっても例外ではない。稼動中のOSの挙動を知ることは、彼ら自身がSolarisのデバッグ作業のためにどうしても必要とされる機能なのだ。 ブライアンは、大学時代からの彼の友人であり、彼がサンにスカウトした、マイク・シャピロ(セルフヒーリングの発明者。前号参照。)と共に、このアイデアを繰り返し検討した。 「1999年から2000年までには、何を作りたいかのアイデアが明確になり、DTraceで解決できる問題の種類が正確にわかっていた。『今日こそ本当にDTraceが必要だったよとか、『DTraceなら今日危ないところを救ってくれただろうに』とか、存在しないものにそんなことを言うのはおかしな話だけど、ぼくらはよくそんなことを言ったものだった。ぼくたちは、さらに調子に乗って、解決できない問題を抱えている他の人たちに、『DTraceならその問題を解決できるんだけどな。』とまで言い出したんだ。」 一行のコードすらもまだ書いていなかったのに・・・・。 「最後には誰かが言ったんだと思う。『DTraceがその問題を解決してくれるなら、なぜDTraceを書かないんだい?』ってね。」 かくして、彼とマイク、そして2002年の初めに参加したアダム・レーベンサールとともに、本格的な開発に着手し、2004年11月、ついにDTraceは新生Solaris10の目玉機能のひとつとして世に出るところとなった。 ブライアンがDTrace構想を思いついた1996年から、8年もの歳月を経ていることになる。 全ての人が不可能と考えたことにも、けしてあきらめなかったひとりの青年の手で、ソフトウエアの世界の常識がまたひとつ書き換えられた。
| Sun Fun Times
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||