コラム / Sun View 第17回
SunONE再考
渡邉 利和(toshi-w@tt.rim.or.jp) [著]
2002年3月21日
San FranciscoでのJavaOne開催を間近に控えた3月、Scott McNealyが来日したり、開発者向けイベントとしてSun Tech Daysが横浜で開催されたりと、Sunのメッセージを聞く機会がちょっと増えた。メッセージの中核にあるのはこのところずっと“SunONE”だが、この実態は相変わらず曖昧模糊としたものに感じられるように思う。
3月7日、Sun MicrosystemsのCEO、Scott McNealy氏が来日し、記者会見を行なった。ここで氏はSunONEを含めたSunの技術戦略について語ったのだが、その詳細はASCII24のニュースに詳しいので、そちらをご参照いただくとしてここでは繰り返すのは避ける。ここでは、この日語られた内容と、別の機会に聞いた話などを混ぜ合わせながら、現時点でSunONEに関して筆者が把握している内容を整理し、とりあえずの“SunONEの現状での意味づけ”を試みてみたい。もっとも、月末に開催されるSan FranciscoでのJavaOneでまた新しい話を聞いたりすると、筆者の考えもまたガラッと変わってしまうかもしれないが、そのときはまた改めて記事としてご報告する、ということでご容赦いただければ幸いである。
“VHS”と“BWTS”の意味
まず、Scottが記者会見の際にその場で描いて見せた説明図について検討してみよう。中央に置かれた“VHS”を上下から“SunONE”と“N1”が挟み込んでいる。この図は、現在のSunの関心領域を端的に表わしているという意味においても、またCEO直筆の図という意味においてもなかなか味わい深いものがあるが、残念ながら少々大まかすぎて理解しにくい部分がある。そこで、この図に表現された内容の詳細についてちょっと解説を加えてみよう。
 |
Scott McNealy氏の直筆図 |
まず、“VHS”だが、これはまぁご想像とおり「β対VHS」で有名なビデオ規格からの連想で使われるようになったキーワードだ。もちろん、内容としてはビデオとは何の関連もなく、“Vertical”“Horizontal”“Storage”の頭文字を集めたものだ。VerticalとHorizontalは、サーバのスケーラビリティを語る際によく使われる概念だ。垂直方向(Vertical)の拡張性とは、1台のサーバをより巨大／強力にする方向で、SunのラインナップではF15Kが代表格だ。一方、水平方向(Horizontal)とは、ある程度の処理能力を持つサーバを台数を増やす形で拡張する、という考え方で、Netraシリーズに始まる1Uラックマウントサーバなどが利用される。どちらも、全体としての処理能力の増強であることは共通するが、適用分野は異なる。単純にいうと、とても負荷の高いタスクが少数あるのか、負荷は軽いがタスク数が多い処理なのか、という違いである。前者の代表例がDBサーバであり、後者はWebサーバが典型的だ。
現在ではすっかり常識的な考え方となった「3階層モデル」に従うなら、フロントエンドのプレゼンテーションレイヤがHorizontalにスケールし、バックエンドのデータストレージレイヤがVerticalにスケールする、ということになる。そして、中間に置かれるアプリケーションサーバ、すなわちロジックレイヤは、アプリケーションロジックの実装によってこの両者のどちらか、あるいは中間的な形態を採る。そして、これらすべてのレイヤは、何らかのストレージを参照して動作する。大規模な環境になればなるほどストレージの管理もたいへんな作業となり、個々のサーバハードウェアにローカルに接続したHDD等でまかなうのは非現実的になる。そこで、Storageをサーバから独立させ、別個に管理する方向へと向かう。NAS(Network Attached Storage)やSAN(Storage Area Network)が利用されるというわけだ。
で、この状況を端的に表わす図が別に用意されている。Sun Microsystemsが過去何度となく示してきた“Service Point Architecture”の説明図である。ここでは、Sun Tech Daysで配布されたプレゼンテーション資料の中から該当する図を抜き出して紹介する(図1)。
 |
図1 Service Point Architecture |
Service Pointとは、端的に言ってしまえばインターネット上のとあるWebサイトのイメージである。インターネット上に配置されたService Pointは、インターネットを通じてアクセスしてくるユーザーに対して何らかのサービスを提供する。オンラインショッピングだとかチケット予約だとかコンテンツの閲覧とか、さまざまな種類のサービスが考えられる。
インターネットがまだ学術研究用ネットワークと見なされていた時代には、Webサイト＝Webサーバマシンで用が足りた。インターネットに接続されたサーバマシンが1台あればよかったのである。しかし、今どきこんなシンプルな構成は逆に珍しくなっていると言っても過言ではないだろう。実際の構成は何十台、何百台ものWebサーバマシンがロードバランサの背後に置かれてユーザーからのアクセスを受け付け、これまた何十台ものクラスタ構成になったアプリケーションサーバに置かれたアプリケーションロジックを起動する。さらに奥にはDBサーバが控え、重要なデータを整理／格納する。特にECサイトなどではこうした構成がむしろ当たり前だろう。
この状況は、図1を右から見るか左から見るかの違いだとも言える。ユーザーの視点は、右からだ。この場合、単一のURLに代表されるとおり、ユーザーからは「サービスが提供される1拠点」としか見えない。これが、インターネット上に配置された×印のついた四角の意味だ。一方、サービス提供者の視点は左からで、ユーザーからは単一のWebサイトとしてしか認識されない“Service Point”が実際にはどれほど複雑な構成になっているかを意識せざるを得ない。
さて、Scottの図に戻ろう。図の中央に簡単に描かれた3つの四角、“V”“H”“S”は、実際にはService Point Architectureの図に示された「サービスサイトのローカルネットワークそのもの」だと考えてよいだろう。
一方でSunは、“Service Driven Network”という概念もかなり前から唱えている。また、“Web-Tone”という概念もある。Web-Toneは「Dial Tone」、つまり電話網における発信音からの連想である。電話網はユーザーにとって見れば完全にブラックボックスとも言えるサービスであり、受話器を上げて「ツー」という発信音(Dial Tone)が聞こえることを確認すれば即利用できる。いちいち交換機の構成がどうだとか通話相手までの途中経路がどうなっているだとかいった詳細を気にすることはない。同様に、インターネットもユーザーにとって便利なサービスをその複雑な詳細を見せずに利用できるようになるべきだ、ということでWeb-Toneという表現が生まれた。
以前は、Web-Toneと表現されるのはSunのサーバハードウェアそのものだったが、インターネットの拡大とサービスの高度化によって、すでに単一サーバでどうこうできる状況ではなくなっていることは前述のとおりだ。そこで、複数のサーバが集合したローカルネットワークとしての“Service Point”を、新たな“仮想サーバ”と捉えることができる。このService Pointこそが、BWTS：Big Web-Tone Switchなのである。Scottの図の右側にあっさりと記されているBWTSという文字は、電話網における交換機(Switch)と同様に複雑で巨大でありながらユーザーからは意識されることなくサービスを提供する、Service Pointという概念を別の表現で表わしたものである。
アプリケーションプログラマとシステム管理者
中央の“VHS”の意味はお分かりいただけたと思うが、実のところService Pointという概念自体は単なる“現状整理”というべきものであり、これ自体はSunの戦略とは言えないものである。現状すでに大規模なWebサイトはService Point Architectureの図に示されたような構造になっているのである。戦略というからには、「Service Point Architectureが現実化しつつある状況を踏まえ、Sunはこれからどうするのか?」を語らなくてはなるまい。
とりあえず、ハードウェアとOSに関しては、Service Pointで利用されるに足る十分な性能と信頼性を備えた製品を今後も開発していく、というのが方針だと考えてよいだろう。つまり、垂直／水平両方向のスケーラビリティにより一層磨きをかけていく、ということだ。
ただし、それだけならたいした革新性もなく、従来やってきたことを今後も着実に実行します、というだけのことだ。これだけで終わってしまっては面白くもなんともないのだが、もちろんSunはその先の話もちゃんと用意している。それが“VHS”を上下から挟む“SunONE”と“N1”である。
この2つは、“VHS”＝“Service Point”であることを踏まえれば理解しやすい。Service Pointに求められる機能はまさに「サービスの提供」である。従って、ここでは「どうやってサービスを実装するか?」「サービスをどのように運用するか」の2つの要素が必要になる。これが、SunONEとN1に対応するのである。
まず、N1から見ていこう。N1は、“Network One”の意味だと言われている。比較的最近になって表に出てきたキーワードであり、筆者の勉強不足もあってその詳細に関しては分からないことも多いのだが、現時点での筆者の理解としては「Service Pointのシステム管理のためのフレームワーク」となる。図1に示すように、Service Pointは多数のコンピュータ／デバイス群から成る複雑なネットワークシステムである。複雑なシステムは運用も難しく、トラブルが起こる可能性も高いうえに、トラブルの復旧も簡単な作業ではない。
一方、インターネット上でのサービス、という観点からは、「ダウンしました」では済まされなくなってきている。サービスが普及し、利用者が増えてくればサービス停止の影響も大きくなる。サービス提供者には“社会的責任”も課せられるようになってくるのである。そこで、複雑なシステムを適切に管理し、運用しやすく維持することが重要になる。
もちろん、特別なアイデアを持ち出さなくても、優秀な管理者を必要なだけ用意できる組織であれば現状でも高い品質を保つ“Service Point”を運用することは可能である。しかし、複雑さが増すにつれて管理者に求められる技術や知識のレベルは超越的なものになり、人材確保がより困難になっていくことは容易に想像できる。
ここで、図1を右から見るサービスユーザーにとってService Pointがどう見えていたかを思い出していただきたい。Service Pointにアクセスするユーザーにとっては、Service Pointは単一のサイトとしか意識されず、その複雑さは完全に隠蔽されている。同様の状況を管理者に対しても提供できれば、管理が容易になることは間違いない。つまり、多数のコンピュータ群からなるネットワークシステムを、あたかも仮想的な単一の巨大コンピュータであるかのように取り扱うことができれば管理しやすい、というわけだ。N1の目指すところはここにある。
これをちょっと気取った言い方で表現すると「シングルシステムイメージの提供」となる。そして、これは“The Network is The Computer”という標語を10年以上前に掲げ、一貫して「ネットワークコンピューティングの実現」に取り組んできたSunにとってはごく初期の頃からの古いテーマでもある。Sunの技術に詳しい方なら名前を挙げるだけで十分だと思うのでここでは詳しくは触れないが、NFSやNIS+(YP／NIS)といった技術も、「シングルシステムイメージ」をそのときどきの技術水準で実現しようとしたものと見ることができるだろう。さらに現在では、SunPlexと呼ばれる分散環境のコンセプトがあり、具体的なソフトウェア製品としてSunCluster 3.0もある。その延長上、将来実現するだろうより統合されたシステムイメージを提供するための仕掛けがN1だと考えられるのである。
そしてSunONEとは……
さて、ぐるっと巡ってようやくSunONEに戻ってきたところで、Scottの描いた図を手がかりに、SunONEが「Service Pointにサービスを実装するためのプログラマ用のインターフェイス」であるという位置づけができあがったわけだ。このことはScott自身が明言していることでもあるので、とりあえずはよしとしよう。むしろ、ここで考えてみたいのは「それは本当か?」という点である。
ここで問題を複雑にしているのは、Microsoftの.Netの存在である。Sunの「分散システムへの取り組み」はそれこそ創業以来の大目標であり、Microsoftの動向にいちいち左右されるような目先の戦術の問題ではない。しかし、どれだけ真剣に取り組み、成果を上げてきたのか、ということとはまったく独立した問題として、「市場がその戦略を正しく理解しているか」という観点で見ると多少ようすが違ってくる。実際にキーワードとしての“Web Service”を市場に広く認知させたのはMicrosoftであり、Sunの分散アプリケーション環境への取り組みは、少なくともJ2EEとEJBが実用段階に達している現段階では明らかにMicrosoftよりも先行していたにもかかわらず、うまくアピールできていなかったと言うほかないだろう。この「アピールの下手さ」はSunの昔からの問題だと言ってよいと思うが、Web Serviceを分かりやすいキーワードに新しいプログラミングモデルを打ち出したMicrosoftの.Netへのマーケティングでの対抗上、SunONEの説明が過度にWeb Serviceを意識して混乱したものになった傾向は否定できないのではないだろうか。「SunONE＝SunのWeb Service」という見方はその影響だと言える。
SunONEは“Sun Open Net Environment”の略であり、“Service on Demand”を実現するための標準に基づくソフトウェアのビジョン、アーキテクチャ、プラットフォームである、と説明される。Service on DemandはWeb Serviceと同一視されるが、Web Serviceが、実態としては「コンポーネントのリモート呼び出しのためのインターフェイス仕様と周辺サービス」という極めて具体的なプログラミングに関連したものであるのに対し、Service on Demandはむしろ「インターネット環境で求められるサービスのあるべき姿」を語る抽象概念、あるいは理念のようなものである、という点が大きく異なっている。Web Serviceは、Service on Demandの一部分に対する具体的な実装技術と捉える方が正しいと思う。このほかにも、Service on Demandの実現のために利用可能な技術はさまざま存在している。たとえば、J2EE/EJBもそうだし、JXTAだってそうだろう。Web ServiceとSunONEを同列に置こうとすることが、SunONEが曖昧模糊としてつかみ所のないものという印象を生んでいると思う。そして、この点に関してはSun自身の責任も大きいと思う。
話を戻して、SunONEが“サービスを実装するプログラマのためのインターフェイス”として機能しているかというと、現状ではとてもそこまでの環境はできあがっていないと思う。少なくとも、Microsoftが.Netで新しいCLR(Common Language Runtime)というインターフェイスを用意し、その上にアプリケーションを構築すればよい、という明瞭なプログラミングインターフェイスを提供したのに比べると、SunONEは事実上何も提供していないに等しい。
しかし、ここで言いたいのは「SunONEは.Netよりも遅れている」という話ではない。むしろ、プログラミングインターフェイスとして分散環境に対応した機能をプログラマに用意する、ということに関しては.Netよりも早く、Javaによって提供されている、というのが重要なポイントである。実はこのことはSunONEの説明を聞いているとすぐに分かる。というのも、SunONEと言いつつ実はJavaの説明をしている、ということがよくあるからだ。Web Serviceに関して、現在Sunも環境整備を進めている最中であり、この進捗状況が「SunONEのロードマップ」として公開されていたりする。しかし、これは実際問題としては「Java環境へのWeb Serviceサポート機能の組み込み」の話と捉えるべきで、SunONEそのものと直接結びつけるべきではないと考えている。もちろん、Web Serviceの実装に向けた取り組みはSunONEの実現への前進であることに間違いはないのだが、Web Serviceを意識しすぎると、SunONEの全体像を見失うだろう。ここであらためてScottの図に戻ってみると、SunONEはService Pointの上に構築されるプログラマ向けのインターフェイスと位置づけられるが、実のところ実際にプログラミングインターフェイスとして機能しているのはJava(主にJ2EE)である。そして、Javaで構築されたサービスのうち、他サイトのサービスと連携する必要のあるものについては、そのためのインターフェイスを作り込む必要がある。相手がJavaならJavaの枠内で話が済むが、相手の実装アーキテクチャを問わず汎用的に使える(可能性のある)インターフェイスとして新しくWeb Serviceもサポートしましょう、というのが最近の動きである。つまり、Web Service自体はコンポーネント間の通信インターフェイスのひとつということでしかない。では、SunONEはどこにいくのかというと、概念的にはさらに上位に位置づけるべきなのだろう。
Web Serviceは、コンポーネント間の通信のための規格であり、実のところ概念としてあまり画期的なものとは言えないと思う。魅力的で便利な新機能だが、根本的なアーキテクチャの改革というわけではないハズだ。Web Serviceにこれだけの注目を集めることができたのはMicrosoftの功績であり、その存在感の大きさの故だと思うが、よく考えてみれば、.Netも別にWeb Serviceを実現するために構想されたものだというわけではなく、むしろその本質的な意味はプログラミングインターフェイスをWindows+Win32 APIという層から一レベル持ち上げ、CLRという上位レイヤを新しく作ったことにある。これがJava対抗だと考えれば、SunとMicrosoftが同じ課題に取り組んでいることもまた明らかだと言えるだろう。プログラミングインターフェイスがハードウェアに直結したアセンブラからOSとインターフェイスするCやC++といった高級言語、そしてJavaやCLRのようなさらに上位のインターフェイスへと動いているのは、プログラマが直面する課題の解として現状ほか)に手がないからだろう。そして、より上位のインターフェイスへ向かうことでハードウェアやOSに対する依存度を減らした結果、SunがLinuxを部品として取り扱うことができるようになる、ということにも繋がっている。Sunが現在取り組んでいる課題や戦略の多くに関連を持っている、という意味で、SunONEは無視できない重要な存在である。短期間での成果を求めるのではなく、長い目でSunONEの実現過程を見続けていく必要があるだろう。少なくとも、直近では月末に開催されるJavaOneでもまたSunONEに関して何かしらの情報が得られるものと思われる。
| ![ASCII24 - [Main Menu]](/images/2005/biz_menu_01.gif)
![[Menu 2]](/images/2005/biz_menu_02_blogmag.gif)
![[PR]](/images/2003/pr_icon.gif){kind=icon}
