ご紹介にあずかりました、東京工業大学の千葉です。先ほど中島先生のお話は、1,000倍ぐらい今からコンピューターが速くなれば実現可能というお話と伺いましたけれど、今日これから私が話す話はどちらかというと、本日手に入る最高性能のコンピューターというよりは、もう少し一般的に購入可能なコンピューターでどういうことをするかという話で、だいぶ先ほどの話とはスケールの壮大さという意味では少し落ちていくんですが、ただ千里の道も目前の一歩から踏み出すことが大事だと思いますので、そう思って聞いてくだされば幸いです。

　これは実は、こちらの坂井先生のベースプロジェクトでやっていることの一環ですけれども、今日お話しする話は端的に言いますと普通のアプリケーション、その中でもいわゆるウェブアプリケーションと呼ばれる、今現在、非常によく普及している典型的なコンピューターソフトウエアだと思いますが、このコンピューターソフトウエアをいかに安定稼働させるか、それをディペンダブルにするかという要素技術のお話をしたいと思います。

　今日、取り上げるアプリケーションソフトウエアは、これは実は架空のシステムですけれども、河川水位監視システムと言いまして、あくまでも架空のものですが、取りあえず例えば国土交通省あたりが考えて、全国の河川の水位を彼らは持っているわけですから、これを国土交通省のサーバーからリアルタイムに収集して、情報を分かりやすい形でウェブ上に提供する、そういういわゆるインターネットサイトを取り上げます。この研究を始めるに当たりまして、通常ですと、こういうソフトウエアはまず自分たちで内製して、それからこれをディペンダブルにするにはどうしたらいいかという話を始めますが、それはなかなかリアリティーがあろうかということで、これは一般的な外部の企業の方に外注してまず作っていただきました。

　これはどうやって作ってあるかといいますと、非常に一般的なインターネットサイトの作りをしていまして、キーワードで並べましたが、Linux上で動き、それからJavaを使って書いてあり、JBossですとか、オープンソースのJ2EE serverですとか、PostgreSQLというデータベースですけど、Apache、Tomcatといった、今日非常にありがちな技術を使って作っていただきました。これを作るに当たって、こういう研究のために使うということは一応、お話ししたんですが、詳細は話さずに普通に作ってくださいということで作っていただいたものです。

　これはどういうものかといいますと、ネットワークにつながっていればこのソフトにつなぐことができるんですが。これは実はデモのビデオというか、フラッシュを撮ってきましたので、これを使って今日はお話ししたいと思います。これは研究室に検証用のシステムがあって、サーバーとそれからそれに対してリクエストを出すクライアントですね。それをラックに入ったわりと大掛かりなシステムがあるんですけれど、これを使って撮ったものであります。

　これは今、起動したところで、サーバーを起動して動かすと動き出します。これはこんなソフトウエアになりまして、画面がうまく合っていないんですけれど、要するにウェブでブラウザーからいろいろあちこちをクリックすると、関東地方を選ぶと関東地方の地図が出てきて、今、荒川は3.3メートルで、多摩川は3メートルでということが分かり、それをクリックすると直近の24時間ぐらいの水位の変化はどうなっているかというのがグラフで出ます。直近だけではなくて例えば30を選びますと、スケールを変えて表示させることができます。これは1日分ぐらいのデータを見られます。これはありがちなシステムですけれど。こういうウェブサイトを用意しています。こういうものを作りました。

　それで、普通こういうものは外注するとできてくるんですけれども、問題はこれをディペンダブルにしようというということで、どういうふうにディペンダブルにするかというと、普段はあまりこういうサイトは人気がないと思います、毎日見るようなサイトではありません。こういうサイトにみんながアクセスしたいと思うときには、例えば昨夏のような大型台風が接近してくるような場合でして、こういうことが起こると突然多くの人たちがこういうサイトにアクセスしようとするわけです。

　こういう現象は一般的にはFlash Crowdsと言って、普段はあまりリクエストがなくて、ソフトウエアのタイプとしては非常に軽いソフトウエアのところに、ある特定な外部事象によってわっとリクエストが集中して遅くなる、ダウンしてくるという現象のことを言います。

　例として考えると、このデモソフトウエアのシナリオでは、例えばカトリーナ級の台風が関東に上陸するかもしれないというニュースが出ると、皆さんが見るわけです。例えば神田川が増水すると総武線が止まると。ちょっと見ておいた方がいいのではないか、場合によってはもう帰った方がいいのではないか。あと私は多摩川の向こうに住んでいるんですが、都内にいて仕事場があって、多摩川が増水すると帰れないかもしれない。最近いろいろもうすぐ地震が起こるんじゃないかといわれているので、実はオフィスに革靴じゃない靴を置いてあったりしますが、そういうものあっても多摩川が増水してしまうと、ここを泳いで帰るべきか、それとも待つべきかなどいろいろ考えるわけです。

　一番いいのは危なそうなときは、さっさと仕事を切り上げて帰るというのがいいわけです。そうすると皆さん一斉に都内に住んでいる人たちがこういうサーバーにアクセスしますから、下手をするとダウンする可能性があります。多くのサーバーというのは現状の技術だと、たいていこのぐらいだろうという平均的なロードアベレージに対して最適化システムを組みますので、何か突発的な事件が起こって大量のアクセスが集中すると、システム全体がダウンしてしまうということがよくあります。

　具体的にどういう場合にこういうダウンが起こり得るか、内部的には何が起こるかというと、例えばこのサイトの場合ですと、そもそも台風でアクセスが殺到すると、ウェブサイトにつながりにくくなります。要するにこういうのは情報を取るためのサイトですから、肝心なときに情報が取れないとそもそも存在意義がありません。ですからこれ自体もあまりいいことではないです。しかしそれ以上に問題なのは、特にこういうシステムの場合、リアルタイムなデータを適宜流すということが大事ですが、このサイトの場合、実はバックグラウンドで河川の水位を持っているデータベースから、データをリアルタイムで取ってきて内部的に蓄積しています。

　こういう重要タスクがそのリクエストの殺到で影響を受けて、リアルタイムにちゃんと動かなくなるということが起こり得ます。そうなってしまうと、実際に出てくるデータがそもそも表示するべきデータがなくなってしまうので、仮にちゃんとそのウェブサイトにアクセスが成功したとしても、見えるデータは一部データがなかったり、あるいはそもそも変な値を見てしまうことになります。そうすると役に立たないわけです。

　昔はウェブサイトというのは半分趣味のものというか、そんなに信頼性は要求されなかったんですが、最近ではこういう河川の水位を表示するシステムのように、わりと非常なミッションクリティカルな領域ではないけれども、やはり日常生活に直結していて、大事なデータを配信するようになっていきます。ですのでこういうものでは困るわけです。これを何とかしようというのが、今日お話しする研究の目的になります。ちなみにウェブサイトというのはHTMLの集合体みたいなものですが、ああいうものがそんなに負荷がかかわらないのではないかと思われる方が、もしいらっしゃるといけないので、ここに書いてありますが一応コメントしておきます。

　普通のいわゆる静的なHTMLを表示しているようなサイトの場合には、そんなにサーバーには負荷はかからないんですが、最近の重要な仕事をしているサイトというのは、必ず中でかなり複雑なプログラムが動いていて、ユーザーからリクエストが来るたびに、何らかの提示を、実行中に訂正してそれを表示するということをしています。

　例えばこのサイトの場合典型的なこれですが、さっきいろいろメニューバーをいじって出す間隔を変えてみたり、いろいろやってみましたけれど、こういうデータは普通のウェブブラウザーから要求が来ると、その場でデータベースを検索してグラフの絵を作って、その作ったグラフの絵を画像としてブラウザーに返すということをしています。ですから処理としては結構大きな処理になっています。ですからこれが大量に要求されてくると、映像がコンピューターとしては重くて動かないということが容易に起こり得るわけです。

　次の話をする前に、さっきのデモのビデオの続きですが、ちょっと戻して再生してみます。これはどういう実験かといいますと、研究室の方にこのサイトとは別にクライアントのマシンをたくさん用意して、こちらのマシンから強制的に大量の負荷を、リクエストをサーバーに向かって投げるということをしている図です。これは下の方にグラフがありますけれど、これはJMeterというテストをするソフトウエアです。ここに赤いグラフが出ていますが、これが要するに負荷です。

　負荷をかけて1分ぐらい経過すると何が起こるかというと、これは実験にしては時間がかかり過ぎてなかなかつらいんですけど、これで負荷がだいぶかかってきたわけです。そうすると、この辺でここにバッテンが出ていますが、データを取るのに失敗したということです。一応、データが取れなかったときには取れなかったということが表示されるようにこのソフトは作ってありまして、バッテンが出るんですが、この状態でこういうグラフを見せると確か一応出ると思います。それはなぜかというと、このグラフは直近の24時間、この場合は12時間ですか。12時間の平均値を取っているので負荷がかかってデータの取りこぼしが起こった直後には、まだあまり分からないわけです。だから本当は正しいデータじゃないのに、ある種のシステムのバグで、正しくないデータを正しいもののように表示してしまうということです。

　たｄわ10分ぐらいたちますと、システムがおかしいということがちゃんと反映されてくるので、これは今、グラフを作っていますけどこれはデータが取れなかった、平均値の計算がおかしいという表示だったりします。おかしくなったらこうやって表示します。これは最初の仕様でこうなったんですが、最初1分ぐらいは、別に最初はこれで十分だと思っていたんですが、実際に作ってテストをしてみたらば、障害が起こり始めて1分後ぐらいでは平均値はちゃんと出ないので、うそのデータが表示されてしまいます。

　これはある種バグだったんですけれど、バグは後から発見してしまったわけです。発注した人が間違ったんです。ただそういうのはやってみないと分からないんですけど、このシステム、この今の問題は、実用運用してみて初めて分かるバグですが、その実用運用してバグが分かったときは、本当にそのシステムが必要とされるときだったということで、これではやはり、まずいというのが我々の問題意識です。

　ただ技術的には話は簡単で、いわゆるスケジューリングが悪いということです。つまりコンピューターの中で複数の仕事をいろいろやっていますが、それをちゃんと優先順位を付けてやらないからこういう問題が起こるのであって、ちゃんと優先順位を付けるように処理すればいいんじゃないのかというのが、我々の研究です。やったことがどういうことかといいますと、ここでアスペクト志向技術という、ちょっと新しいソフトウエアの技術を応用しまして、これでいわゆるQuality of Serviceの制御をしましたと。どういうことかというと、結局そのスケジューリングをちゃんとやればいいわけなので、そのスケジューリングをちゃんとやるという意味で、これは一般的にはQuality of Service、サービスの品質をちゃんとコントロールするといわれています。

　ちょっと技術的な詳細に入りますけれど、作ったシステムはそのソフトウエアの起動時にスケジューリングのやつに、QoSを制御するコードを自動的にソフトウエアの中に組み込みます。その組み込まれたソフトウエアは、システムが動いている途中に手にsleepを呼んで、込んでいるようであれば、CPUの資源をほかのもっと重要なタスクに譲るというようなことをしました。

　こういうことをやると、いわゆる一般ユーザーからのリクエストは、積極的にそのCPUをほかのもっと重要なデータを取ってくるような仕事に割り当てて、一番大事な仕事が邪魔されないように配慮するということをやります。そういうコードを自動的に組み込むということをしています。

　特徴は、このシステムはアプリケーションの本体とか、ミドルウエアのOSとか、いわゆるコモディティーなものの変更は一切いらないということです。最初に申し上げた通り、もともとのウェブサイトのシステムというのは外注で、こういう話を知らない人に作っていただいたので、こういうのは一切入っていないわけです。我々がやったこととはそういうまったくこういうディペンダビリティーを考えていないソフトウエアを持ってきても、もしある程度設定はいるんですけど、設定ファイルによって自動的にちゃんとディペンダブルな要素を持ったソフトウエアに書き直して、それから実行するという技術を開発して実装したということになります。

　具体的には中に2つ仕事がありまして、1つはさっきお見せしたようなグラフを作る処理です。これはユーザーからブラウザーで要求が来るたびに動きます。アクセスが殺到したときには、大量に発生してもっと下に書いてある、河川水位情報を収集するスレッドというもっと大事なスレッドの動作を妨害してしまいます。そこで我々のシステムが自動的に組み込むディペンダブルコードというのは、こういうときには負荷に応じて自発的に止まって、自分たちの並列度を抑えるという話をします。やっている処理自体は、それほど難しい処理ではないですが、そういうことをやるコードが自動的に入るというところがみそになります。

　あともう1つ大事なところは、スレッドというのはこれは一定時間に動いて、河川の水位をサーバーから取ってくるというシステムです。こちらについては何もしません。普通のシステムでは何も制御をしないと全速力で動きますので、これはこれで放っておけばいいというものです。

　こういう技術を入れると、どうしましょうね、先にデモをお見せしますか。このデモはあまり面白いデモではありませんが、先ほどはいろいろ動かすとあちこちバツが出て、どうもデータが取れていないということが分かったんですが、こちらの方は、制御ありの方ですけど。制御ありにすると、さっきと同じようにJMeterを立ち上げて負荷をわっと、実験のために人工的に別なマシンから負荷をリクエストをたくさん投げています。そうすると、結論から言ってしまうと何も起こらないです。ちゃんと普通に動いているというだけなので、デモとしては非常にインパクトがないんですけれども。1分経過ですね。

　システム系の仕事はちゃんと動いていると何も見えないという、何も変化が分からないという、なかなかつらい研究になりますが、でもこれはちゃんとデータに負荷がかかっているんですけれど、この辺のところに別にバツは付いてないです。ちょっと分かっていただけるかどうか分からないですが、これは夜間に撮っているビデオで、さっきに比べて絵の出てくるのが遅いです。それはやはり大量に負荷がかかっていて混んでいるので、スピードダウンしているからです。でもちゃんと正しいデータが見えているというものです。

　さっきは10分経過すると、出てくるグラフも異常を表示していたんですが、画面サイトは変化がないのがつらいですが、今回はちゃんとセルフコントロールを入れると問題なく動くというものです。これ以上見ていても退屈なだけですので、ちょっとやめます。

　実はこれを実現するに当たって、自動的に組み込んでいる制御のアルゴリズムは、それほど新しいアルゴリズムではありません。もちろんこれはいわゆる普通に使われている実ウェブサイトなので、組み込むのは簡単ではなくて、いろいろ実用的なリアルシステムで組み込むための、さまざまな苦労がありましたが、むしろ研究としましてはそれを組み込む技術の方に重点があります。それはアスペクト指向プログラムと言って、これは私がずっと研究していることです。これはごくごく簡単に言ってしまえば、ソフトウエアを部品化するためのプログミングパラダイムの1つです。

　あとはちょっと技術の詳細に入ってしまいますが、これについて詳しいことをお話しさせてもらいたいと思います。いろいろ最近はやっておりまして、本まで書かせていただいたんですが、ごくごく簡単に言うと、普通のオブジェクト指向言語などで作ってしまうと、コードがあちこちのクラスに散らばってしまって、うまくモジュール化、部品化できないものに、ここに書いてあるのは、新しい言語コンストラクトを導入してやることで、うまくプログラミングできるようにしようという話になっています。

　あまり細かいことはちょっと飛ばしますが、非常にコンセプトのことをお話をさせてもらうと、今までソフトウエアを部品化する技術というのはずっと研究されてきたわけです。そもそもそれを軸にしてプログラミング言語の歴史を語ることができるぐらいです。ただこれまでずっとあったある種の思い、プログラミング言語を作ってきた人たちの思いというのは、還元論がいいんだというのがあったと思います。つまりシステムは全体から部分へ、大きい方から詳細へトップダウンに分割していけば設計できますと。

　ですから、例えば先ほどお見せしたような河川の監視水位を見せるサイトを作るときには、まずあれはどういうことをするサイトなのかという要求定義をして、その要求定義に基づいて、ではどういう機能とどういう機能とどういう機能があればいいのか考える中で、水位をデータベースから取ってくる機能、それからブラウザーに日本地図を表示する機能、それから時系列でグラフを生成する機能、そうやって機能を分割していって、今度はそれぞれの機能を取り出して、グラフを生成するにはTLGの画像を作らなければいけないので、TLGの画像を作るモジュール、それからどういうグラフを出すかを考えるモジュール、それから内部のデータベースにアクセスしてデータを取ってくるモジュールとか、いろいろ細かく分割してやるわけです。

　全体としてツリーになっていて、全体から細部に分割していけばいいと。還元論の一種だと思いますですが、これを突き詰めていけば、ソフトウエアはすべからく簡単に開発できるようになるというのが思いだったと思います。

　アスペクト指向は、これは神話でしょうというところから出発していて、ちょっと大きなプログラミングの経験のある方は、皆さん分かると思うんですけれど、現実のプログラムはあんなふうに上から下に向かってトップダウンのツリーにはならないわけです。実際は例えばこの辺のモジュールは、この辺のモジュールと、この辺のモジュールの融合したような形でできています。ちょっと今日は細かいことはお話ししませんが、これをそのツリー、いわゆるクラスの階層構造だと思ってもいいですし、オブジェクトの包含関係と思ってもいいんですが、プログラムのいろいろな場面を取り上げて考えるとこういうことが言えます。実際には全体から部分へと、単純な微細化になっていると。

　これを何とかするためにいろいろな技術が開発されてきて、例えば多重継承やMixinとかあるんですけれど、これまでのいろいろな技術があったんですが、こういった技術は、ばらばらになっているものを組み合わせることはできますが、組み合わせてしまったが最後、もう離れないという欠点があります。

　どういうことかというと、設計をする段階で今回のモジュールはこの機能と機能がいるから、これとこれとこの機能を多重継承してくっ付けてこの新しい欲しいモジュールを作ろうと思って作れば作れますが、組み合わせてしまったら最後、後で仕様変更が入って、それでは困る、1回ばらしてもう1回やり直してくださいと言われたときに、にっちもさっちもいかないと。プログラムもまたあちこち書き直して、いったんばらして、それからもう1回組み立て直すということをしなければなりません。

　今日はその絵はないですけれど、例えて言うと、例えばiPodがありますけれど、あれは非常に格好よくきれいにできているんですが、開かないのでも有名です。電池が切れたらもう電池交換はできないです。あれは典型的な組み立てたら最後というものの一種で、僕が話しているそのソフトウエアの問題というのは、iPodの問題と同じです。きっとiPodも工場では部品として生産されていると思うんです。中のバッテリーは部品ですし、外側のケースも部品です。ですからラインに乗っかってばっと組み立てられてしまって、きれいな化粧箱に箱詰めされた瞬間に、もう開かないものになってしまって、後で何かしょうと思ってももうできないです。

　ソフトウエアも同じことが起こっていて、最初の工程でこういうふうに組み合わせるんだと決めたら最後、どうにもならないというのが今までのケースです。そこでアスペクト指向は何を狙っているかというと、それでは困る、いったん組み立てても、ちゃんと必要に応じて離せるようにしようというのがアスペクト指向の狙いです。

　まとめるとこんな感じです。普通のもので作ると実装が複数のモジュールにまたがってしまうので、設計段階でこことこれを組み付けると決めた瞬間に、もう離れなくなってしまうものを、ここでは独立したモジュールと書いていますけど、要するに必要に応じてくっ付けたり離したりできるようにするという技術です。こういうのは後でもうちょっとお話ししますけれど、非常に大事なことで、現実のこういうウェブサイトを作っているソフト開発の場合には、仕様というのはなかなか最初の段階では決まらなくて、作っている最中、あるいは作り終わってテスト運用になったところで仕様変更するということが、ごく普通にありますので、やはりこうやって組み立てたからもう離せません、ではやはり進まないわけで、いったん組み立ててしまっても、クライアントが見にきてこれではだめだと言われら、ぱっと離せるようにするということが、工業的にはとても大事です。

　アスペクト指向というのは、特にアスペクト指向言語というのは、そういうことをできるように言語◇プリミティブ◇を提供するというものです。我々はそういうことをずっと研究しておりまして、今回の例の河川の水位を表示するウェブサイトというのは、その技術のある種の実証実験としてやってみました。我々はGluonJという、そういうアスペクト指向のシステムを作っていますが、これを実際に応用して先ほどお見せしたデモのシステムを構築しました。

　ちょっと残った時間で、少しまたメタな話をしたいんですが、こういうアスペクト指向のような新しい技術を使うと、先ほど見せたディペンダブルなコードを開発が終わったソフトウエアに対して後から付けると、あるいは不要になれば外すということが比較的、簡単にできるようになります。ただ、本当にそれで十分なのかということを少し考えてみたいと思います。

　先ほどのご講演でコンピューターが今から1,000倍速くなる、100万倍速くなるという話がありましたけれど、純粋に技術的な面だけを考えて理論すると、先ほどお見せした河川水位監視システム、Kasendasという名前も付いていますが、あのソフトウエアはそもそもの設計が悪いのではないだろうかという疑問が当然あると思います。

　つまり、どうもそういうシステムを細かい姑息な手段を使って、何とか延命させているように見える、やはり技術屋としては、まず最初に要求定義を考えて、例えばカトリーナ級の台風が日本にも来るかもしれない。そういうときにこそ役に立つシステムなのだから、そういうときに備えてハードウエアの性能を決定すべきだと、初めの設計段階で。例えばどのぐらい用意しておけばいいかは、なかなか見込むのは難しいんですけれど、例えば1万コアのOpteronグリッドに広帯域の光ネットワークを付ければ、まあ、大丈夫だし、これ以上のハードウエアなかなか最近は手に入らないので、このぐらい用意しておいてだめだったら、それは仕方がないという開き直りもあり得ます。

　またReal timeの専門家の方でしたらば、ああいうシステムをそもそも普通のLinuxそれから普通のJavaで作る方が間違っていると。ちゃんとReal time Linuxがあるんだから、それを持ってきて使うべきだと。Real time Javaも、そんなに一般的には普及していませんけれど、一応実用的に使われ始めているので、そういうものを持ってきて作ればよいのだと。その上に載ってミドルウエア、この場合はApacheとかJ2EE serverを使っていますが、こういったものも探せばReal timeのものがあるはずだと。Real time Linuxの上でReal time Javaを動かすと、その上で走るReal time ApacheとかReal time J2EE serverというものが存在するはずだから、そういうものを使ってちゃんとシステムを作らなければいけないという意見もあると思います。

　タネ明かしをすると最初の2つは一応存在するんですけれど、下の2つは世の中に存在しないので、実現可能ではないんですけれど、態度としてはこういうものをやはり作るべきだという態度もあると思います。ただなぜこういう研究を始めたかというと、先ほどお見せしたような大量のハードウエア、大量の高性能なソフトウエアを使うというアプローチは、必ずしも現実的ではないと思っているからです。というのは、こういう今、手に入るソフトウエアでやる技術というのは。どうしても経済的な面とか、実用上のさまざまな問題を考慮しなければいけないと思うんですけれど、現実的にこういうソフトウエアを開発している人の話を聞くと、そもそもソフトウエアには開発コストというものがあると。お金を無制限にじゃぶじゃぶ投入していいというわけではないと。やはり提供するサービスに見合った予算で作らなければいけないと。

　具体的には、そもそも開発より技術力というものがReal time Javaを使ってシステムを作る、それは結構な話ですが、Real time Javaを使いこなせるエンジニアを集めてこようとするとそもそも大変ですし、その人たちの時間単価が高いので、結果として作られるソフトウエアの開発費が膨らんでしまい、これをお客さんである発注側が許すかという問題があります。またこのぐらいのシステムにあまり変なハードウエアを持ってきたくない、できれば普通に手に入るメンテナンス、例えばデルとかああいう会社から買えるソフトウエアないしハードウエアで作りたいということがあります。

　また、そもそもこういうサービスに必要なマシン性能の見積もりというのは非常に困難で、大きいシステムを用意しておけばいいかというとそうではなくて、例えば設置スペースや電源や空調の制約とかいろいろな問題があります。そもそもそういうサイトにどのぐらい人気が出るかというのは、あらかじめ事前予測が非常に難しいので大変だと。またこれもかなり本当に近い実話として伺ったんですけれど、これを発注した会社の方から聞いたんですけれど、こういうシステムだと人気が出ても、なかなかサーバーの増強予算が付かないです。

　例えば国土交通省がこういうシステムを発注して、どうも国民の人気があるようであると、よかったよかったというと、次に役人の方がおっしゃることは、では予算を付けましょうと。もっと観測できる河川を、今回は1級河川だけでしたけど、今度は全国津々浦々のもっと小さい河川もセンサーを置いて、測れるようにしましょうと話はいきますが、サーバーの予算を増強してFlash Crowdsに耐えられるようにしましょうとは、なかなか話がいかないという現実的な問題もあるそうです。

　我々はこういう問題に対してどういうふうにアプローチをしているかというと、もちろんReal time Javaとか、Real time Linuxを使えばいいですが、そういうやり方がある一方で、コモディティーのミドルウエアですとかOSを使ってやるということも大事なのではないかと、そういう道も用意しておかなければいけないと思います。我々のシステムは基本的にそのアプリケーションのレベルで制御を行いますので、LinuxでOSとか、ミドルウエアについては普通のものを使えると、普通のものを使うので普通のエンジニアの人に開発を頼めると、だから開発コストを抑えることができるという話になっています。

　またさっきご紹介したQoS制御は、設定ファイルで分離して書くので、元のコードには一切手を入れていません。もちろん中のコードを見てやっているんですけれど、私の研究室の学生の人が、中のコードを見てどこにどういうふうにやるべきかということを、ツールもあるんですけれど、ツール等で解析しながら決めていますが、取りあえず設定前の設定記述自体は元のプログラムから分離されています。

　これはどういうメリットがあるかというと、別々に開発できるというメリットがあります。これも研究室で、インハウスで少人数で作っている場合には、あまり問題ではないですが、大規模開発の場合、業務用の開発の場合は大事で、アプリケーション本体を作る部隊の横で、こういうチューニングをやる部隊を別に配置してやることが可能になります。一番ありそうなシナリオは、会社の中にアプリケーション本体を作る部隊がたくさんあって、チューニングもやる部隊が1個あります。チューニングをやる部隊というのは、それぞれのアプリケーション本体の開発が終盤にかかったところでやって来て、1つずつこういう技術を使ってチューニングをするというものです。

　あとやはりこの技術の移転は、アプリケーション本体の方には一切プログラムのコードには、見はしますけれど手は入れないということです。これもやはり大事なことで、実用ソフトの開発の場合にはちゃんとテスト工程というものが非常に大変で、ここに結構お金が掛かるわけです。ちょっと乱暴な言い方ではありますけど、性能チューニングのためであっても本体のコードに手を入れてしまうと、やはり終わった後に全体の再テストをもう1回最初から流し直さなければいけない、それは結構な工数がかかりますし、その分開発費が膨らみます。しかしこういうふうに性能もチューニングもまったく分離してやると、完全にテストしなくていいわけではありませんが、取りあえずメインロジックな部分のテストはもう完成しているわけだから、あまりやらなくてもいいだろうと。性能が本当に出ているかどうかのテストだけを、もう1回やり直せばいいのであって、テスト期間を短縮させることができます。

　実際に先ほどデモでお見せしたソフトウエアを作った会社の方に、仮にこういう技術を使わないで、一部を例えばマルチスレッド化して性能を稼ぐような改修をしたらどのくらいお金が掛かるかと聞いたところ、インフォーマルですが、最低でも10％以上は開発費が増えると思いますという返事が返ってきました。今回の開発はデモ用ということで、実はテスト工程をかなり圧縮してもらっていて、多少バグがあってもいいですという感じで作っているのでこうですが、リアルなソフトウエアの場合には、もうちょっとテスト工程が長いので、影響も大きいのではないでしょうか。

　時間ですので、まとめたいと思いますが、今日お話ししたことはディペンダブルソフトウエアの開発技術です。コモディティーなハードウエアで作られたソフトウエアに、後からそういうディペンダビリティーを担保するようなコードを埋め込むことで、新しいソフトウエア開発が可能になるのではないかという話をしました。我々としましては、それを支える技術として、アスペクト指向技術というものを使っていますが、これを実証する意味でも、最初にお見せしたような河川水位の監視システムを作って、実際にそのソフトで目標が達成できることを示しました。以上です（拍手）。

　いやいや、と思われたらそれは誤解でありまして、これは実はそういうシンプルなシステムだと、こういうことはそんなに難しくなくできるんですけれど、上にJVMが載っていて、これはApacheじゃないわけです。動いているのはTomcatで、まずだからレイヤーとしてはOSのLinuxがあって、その上にJVMが載っていて、その上にTomcatというシステムがあって、それとはまた別にJBossというシステムがあります。アプリケーションはその厚いミドルウエアのレイヤの一番上に載っているんです。

　例えばLinuxのプロセスの優先順位や、SVMの優先順位を上げるとして、さてOSがずっとあって一番上のアプリケーションレイヤーで今、データベースにアクセスして画像を作っているスレッドは、どのLinuxスレッドなのかというのは簡単には分からないし、たぶん分からないと思うんですけど。

　ですからアプリケーションのロジックとは独立にやれる話なので、一般的にそうやって後から追加したコードは、かなりロジックには影響を与えません。なので、ロジックのテストはかなり省略してもいいのではと、これはおっしゃる通りあまり正確な理論ではありませんけれど、省略してもいいのではないということが言えると思われます。

　もう1つは、アスペクトを使わなくても同じようなことができるのではないかとおっしゃる意見ですけれど、それはまったくその通りで、別にいろいろなテクノロジーはあると思います。ただ、今回こういうところへ持ってきたのは、1つには元のコードにできるだけ触らないで、別なモジュールと結合させるということが大事だと思っているからです。もちろん専用システムを作ったり、また別な意味ではやっているドメイン・スペシフィック・ランゲージという技術もあるんですが、そういうものを持ってきても同じようなことはできますけれど、我々が調べてみたかったことというのは、こういうAOPのような汎用的な技術であっても、結構十分じゃないですかということを実証したかったということがあるんですけれど。答えになっていないでしょうか。