刺激的な１日

今日はなかなか刺激的な一日でした。午前中は、森下研のLeoさんとデータベースについてディスカッションし、夜は、Venture Beatプロジェクトの会合に参加させていただき、アスピレーションの人見さんと分散についてディスカッションしました。なかなか最近はこういう機会がないので、非常に頭が活性化しました。

PFIでは、かなり基盤技術といわれる類の技術開発を重点的に行っています。Web2.0という単語が登場して久しくなりますが、今更なぜユーザーサイドのサービスを作っていくわけではなく、基盤技術に力をいれているのか、というのには、理由があります。

データベースにおいても、コンピュータそのものにおいても、アーキテクチャの変化が求められているのは確実だと思います。たとえば、現在普及しているRDBMSにしても、マイクロプロセッサにしても、８０年代、９０年代に求められていた典型的なコンピューティングタスクに対して、汎用的に設計されているわけです。たとえば、RDBMSには、勘定系のトランザクション処理を確実に行えるという要件が求められていたわけですし、マイクロプロセッサは、多くのユーザーが使いたいプログラムをなるべく早く実行するために設計されていたわけです。

で、コンピュータの性能はムーアの法則に従って向上してきたわけではあるけれども、現状の、シリコンの上に回路を載せる、という方法では、そろそろ物理的な限界が来たわけです。逐次的実行を意図されたプログラムをいかに早く動かすかが、マイクロプロセッサの課題であったわけですが、そろそろ逐次的プログラムを早く動かす限界がきそうだ、ということです。マイクロアーキテクチャが変化することにより、逐次的な実行の高速化もなされてはいくでしょうが、ＩＰＣ（クロックあたりの命令実行数）の向上は、ムーアの法則にしたがっているとは言えません。

私は、大学生の時にGRAPE-DRのコンパイラの開発にちょっとだけ着手させていただいていたこともあり、いわゆる専用計算機の登場を間近で見ていたわけですが、以前、IBMの東京基礎研究所の丸山所長の話をうかがったときに、アーキテクチャの変化が必須であるということを、より鮮明に実感しました（http://japan.cnet.com/blog/maruyama/2008/07/21/entry_27012396/ ）。アーキテクチャの変化は、コンピュータのみならず、データベースにも求められているものではないかと思います。

そもそも、今、ACIDという単語を聞いてそれが何を意味しているかわかるWebエンジニアは、少ないのではないかと思います。それが悪いことだとは思っていなくて、むしろ、データベースに必要とされている要件が時代とともに変化していることを顕著に表わしているのではないかと考えます。トランザクションのベンチマークは、TPC-A/B（口座からの入出金をモデルにしたベンチマーク）からTPC-C（受注システムをモデルにしたベンチマーク）になったとき、より複雑なトランザクションを扱うアプリケーションを対象にしていったわけですが、Webアプリケーションでは、複雑なトランザクションから、より単純なトランザクションにもどり、そして、スループットが出せれば、多少のデータロスは許されるようなモデルに変化してきています。80年代、90年代にデータベースに求められていた要件とは、明らかに性質が異なってきています。

計算処理にしても同様で、Webアプリケーションにおいては、シーケンシャルな処理をできるだけ早くできることが最大の要件ではなくなってきています。複雑な計算をこなす必要もありません。整数系の演算だけができればほとんどの場合オッケーで、なおかつ、処理１つ１つは、単純になってきています。それらの処理を、単位時間あたりに並列にどれだけ多くこなせるか、ということが求められてきています。

そして、Webアプリケーションにおいては、データにおいても、計算においても、直交性がかなり高いです。つまるところ、問題の分割は、それほど難しくないです。もちろん、中央集約的に処理しなければならない部分もありますが、大部分が、問題を比較的容易に分割することが可能です。ユーザーグループごとにストレージを分けてディスクアクセスの負荷を分散したり、そもそも計算処理は単純なものが多く、また、各処理が依存しあうということも少ないので、容易に並列に実行することができます。そうなると、SunのCoolThreadsのようなアーキテクチャや、Cellのようなスクラッチパッドがそれぞれのコアにぶらさがっているようなアーキテクチャが生きてきます。Webアプリケーションではないですが、画像処理なんかもそうです。

となると、丸山さんのブログに書いてあるような、「解くべき問題によってアーキテクチャを選ぶ」ということが、より本質的な解決手段になってくると思います。処理の汎用化によって、量的な向上が生じ、それが、アプリケーションの多様化という質的な向上を生み出しました。その質的な向上によって、一見終焉を迎えたかに見える量的な向上が再び可能になるのだと思います。

ひとつ、専用アーキテクチャや、専用データベースには、コストという問題があります。いままで、何にでもつかえるＣＰＵや、何にでもつかえるデータベースがあるおかげで、ベンダー側とすれば、どれか市場に流通している製品の中で１つを選べば（各製品には、これまでも、アプリケーションによって使いやすさ・性能の差は多少なりともあったわけですが、どの製品でもそこそこ動くという意味で）よかったわけです。しかしながら、専用化がすすむと、専用アーキテクチャを設計・実装するコストを、アプリケーションごとに負担しなければならなくなります。また、「選ぶ」という行為には、専用アーキテクチャをよく理解した人が問題解決のための選択をしなければならない、という問題もあります。金銭的なコストのみならず、そもそも理解している人があまりいない状況だと、技術の普及という点においてスケーラビリティの限界があります。

その問題を解決する手段の一つが、クラウドコンピューティングをはじめとする、分散プラットフォームであると僕は考えています。汎用的な製品を複数のベンダーが展開するのではなく、１つのベンダーは一つの専用アーキテクチャを提供し、複数ベンダーで様々なアーキテクチャを提供していくという形です。そして、それを実現可能にするのが、分散プラットフォームの概念です。ひとつのサービスを展開するとき、そのすべての機能を一つのアーキテクチャを用いて実現するのではなく、いろいろなアーキテクチャを分散環境として利用し、システムを構成するという構図です。

Amazon,Googleはじめとして、ようやく、このようなプラットフォームを展開する企業が出現してきました。まだまだ、実現できてないことや、対象としていないアプリケーションは様々です。そして、そのようなプラットフォームを提供するためには、理論的な基盤・高い実装力が必要不可欠です。実装には、かなり大きなコストが必要となります。ただ、プラットフォームの実現から運用までを中央集約的にしてしまうことにより、専用アーキテクチャや専用データベースでも、結果的にはリーズナブルに構成することができるのではないかと思います。そして、大規模化することにより、プラットフォームに関するユーザーの理解も深まり、どのようなシチュエーションでそのプラットフォームを利用すべきかを、コミュニティが提案・普及させていけるようになります。プラットフォーム化の概念は今に始まったことではありませんが、技術的な背景として、今かなり潜在的需要が高いと我々は考えています。

基盤ソフトウェアや基盤サービスを作るのは、一見地味に見えるかもしれません。しかしながら、そのようなソフトウェア・サービス、研究・技術を最も広く活かせる場所であり、非常にエキサイティングです。そして、その上に様々なアプリケーションが構築される様は、十分に華やかなのではないかと思います。

追記：

Leoさんに本日のことをブログに取り上げていただいております！http://leoclock.blogspot.com/2008/08/pfi.html

ちょっと論文よみたい衝動にかられる今日このごろです。