標準化の途上にあるグリッド。すべてがつながるには技術仕様の標準化とそれに基づいた実装が欠かせない。夢はすべてが自動化された仮想化世界。ただ「人の判断が付加価値を生む」。そのことに変わりはない。
2002年2月18日。カナダのトロントで開催されていたグリッドの国際会議「第4回Global Grid Forum（GGF）」に集った参加者の間に衝撃が走った。グリッド構築用のミドルウェアとして事実上の標準となっていたソフトウェア「Globus」の研究開発チームが，米IBM社と共同で「OGSA（Open Grid Services Architecture）」を発表したからだ。これまでのGlobusは，グリッドの実現に最低限必要なコンポーネントを提供するツールキットだったが，一気に「グリッドとはかくあるべき」というアーキテクチャを提示してきたのだ（図1[拡大表示]）。
第3回GGFが同時多発テロの影響で極端に参加者が減少したこともあり，OGSA構想の発表を目の当たりにした参加者は口々に「うっかり目を離しているうちに何が起こったのだろうか」と語った。しかしOGSA構想によって，寄木細工のようなグリッドの構成から，整然とした共通設計図のあるグリッドへの道が開かれたのは確かだった。
2002年までのグリッドが科学技術分野をターゲットとしてきたのに対し，OGSAはWebサービスの技術を取り入れ，ビジネス分野での利用も想定しているのが特徴だ。この点が科学技術計算を主な用途としてきたグリッド陣営にとっては画期的な出来事であった。
一方Webサービスにとって，サービスを構築するミドルウェアの分散・協調を実現するOGSA /OGSI（Open Grid Services Infrastructure）のような技術の登場は必然と言える（OGSIについては後述）。Webサービスに携わる企業や団体によって，独自のグリッド技術としていずれ提案されていたかもしれない。逆に言えば，OGSA/OGSIの発表がなければ「グリッド」という言葉が今のようにビジネスシーンで語られることはなかっただろう。
二転三転する標準化
OGSAは，グリッド・コンピューティングにおける標準的なサービスを提供するための基盤アーキテクチャとして策定された。GGFが公開するドキュメントの「GFD.30（The Open Grid Services Architecture, Version 1.0）」に詳細がある。異機種混合の分散環境においてシステム構築の複雑さを減らし，エンド・ツー・エンドでサービスの性能を保証できる形で，拡張可能なグリッドを構築する技術の標準を目指すものだ。OGSAが登場するまでは，それぞれの研究グループが独自にグリッドのアーキテクチャを構想しており，直接コンピュータ資源に触れるものあり，OSが独自のものありと，千差万別だった。当然，上位層のAPIもバラバラである。グリッドの命とも言える相互接続性の点で極めて危うい状況にあった。そこで，グリッドとして提供されるサービスは基本的にOGSAサービスとしてとらえ，その上にアプリケーションを構築しようというのが，Globus Toolkit研究開発チームの考えだ。
OGSAは非常に大きな仕様となることが分かっていたため，基本的なサービス，特にコンピュータ資源にかかわる仕様を分割して定義した。これがOGSIである。OGSIが規定するグリッド・サービスは，Webサービスの標準であるWSDL（Web Services Definition Language）にグリッド固有の拡張を施している。なぜなら一般的なグリッドではサービスの生成と消滅が動的かつ一時的なケースが多い。このためサービスの状態とライフサイクル管理を行う必要がある。このほかにも，グリッド・サービスの名前付けの規則，通信の通知などの機能がOGSIで規定されている。
Webサービスへの歩み寄りで実を取る
OGSIはWebサービスを実現している技術を基盤とするはずだった。しかしWebサービスの標準化は「OASIS（Organization for the Advancement of Structured Information Standards）」で行われている。GGFとOASISの関係を気にしつつ迎えた2004年2月。米国サンフランシスコで開催された Globus Worldにおいて，誰もがOGSIのリファレンス実装となる新Globus Toolkitの登場を待っていた。
ところが参加者を待ち受けていたのは，同僚の中田秀基氏の言葉を借りれば「ちゃぶ台返し」そのものだった。GlobusチームはOGSIの採用をやめ，「WSRF（WS-Resource Framework）」という新たなフレームワークを構想（図2[拡大表示]）。Webサービスで培われた技術に立脚した枠組みでグリッドを構築することを宣言した。
OGSIを捨ててWSRFになると，どのようなアーキテクチャに変化するのか。参加者は開発中の技術の行く末を案じたに違いない。OGSIでは，利用時にサービスそのものが毎回生成されていた。サービス自体が状態を管理する分散オブジェクト的な考え方だ。WSRFにおいては，状態を「リソース」としてサービスから分離する。複数の状態を表現する場合、OGSIではサービス自身が複数必要となるが，WSRFではサービス本体は共有されリソースのみが複製される。状態を持つサービスは，サービスへの参照（URL）とリソースのハンドラのペアで表現される。サービスを利用する際には，ハンドラによって計算の対象となるリソースを指定する。
WSRFはOGSIのアーキテクチャ自体に大きな変更を加えたものではない。ただ状態管理や名前付けの規則などはWebサービスの内部構造に合わせた形になっている。OGSA/OGSIの登場からわずか2年。このころからGlobusチームに対する不信感が芽生え始めてきたのも事実である。誰もが，OGSA/OGSIを前提として2年間さまざまなグリッドの再設計を行ってきたのに，その努力が報われないのだから仕方がない。OGSA/OGSIに始まったグリッドとWebサービスの統合は，2年の期間を経て双方が歩み寄った規格を作ると言うよりも，むしろグリッド側がどっぷりとWebサービスに取り込まれてしまったというほうが正解だろう（図3[拡大表示]）。
どうして，デファクト・スタンダードに振り回されてしまうのだろうか。それはグリッドの価値はつながるサービスの数で決まるため，少しでも多くのサービスを提供するためには枠組みの標準化が必須だからである。
それぞれが個別に技術を整備していけばいいではないかという考えもある。特にグリッドの黎明期から科学技術への応用を考えていたグループには，一連の動きに不快感を持つものもあった。性能と機能はトレードオフであり，機能が豊富になるほど性能面では不利となる。特にGlobus Toolkit 3.0は極めて不安定であり，また科学技術応用では利用する必然性がないものが含まれていたから，デメリットばかりが目立っていた。それでも多くの人々は，コンピュータ資源を糾合する枠組みを与えてくれる標準化作業に期待を寄せ，ある部分では我慢をしていた。その結果，今では標準化に携わる技術者の調整力によって，GGFおよびOASISでのグリッド技術の標準化は順調に進んでいる（別掲記事「グリッド標準化における日本の存在感」）。
ビジネスとの接点を持ち始めたグリッド
標準化の枠組みがWSRFに一本化されたことで，グリッドには本格的なビジネス展開の道が開かれた。ビジネスとしての展開が先行していたWebサービスの枠組みを取り入れたからだ。
確かに，グリッドが扱っていた「コンピュータ資源」「セキュリティ」「データ」などの枠組みは，それぞれが「計算をしてくれるサービス」「セキュリティの認証結果を返してくれるサービス」「データを預かってくれるサービス」といったWebサービスとして統一的に扱うことができる。
この際，どこのコンピュータで実行するか，どのようなマイクロプロセッサを使っているか，どのようなアルゴリズムで計算するか，といった差異は基本的に考慮の対象ではない。ただ単に，「この入力データに対してこれこれの計算を実行して結果を返して欲しい」という要求を満足してくれるWebサービスがあればよい。これは前編でも触れたように，最初に我々がグリッドという考えに至ったシナリオそのものである。
直接的なサービスだけではなくて背後のインフラが提供するサービスまで同一基盤で実現できる。この道筋が示されたことで，Webサービスとグリッドに投下される人・モノ・カネの分散がなくなり，グリッドの実用化に対する見通しがついた。
例えば，ホテル予約の手配や中古自動車販売など，さまざまなサービスをエンドユーザーが直接利用できる。さらに，それらサービスを提供する企業内や企業間では，コールセンターやサプライチェーン・マネジメント，リスク・マネジメントなどのASP（Application Service Provider）サービスを利用する。それらのバックエンドとして，コンピュータ資源を提供するグリッド・サービス事業者が存在するといった形態だ＊。
グリッドが創造するビジネス・チャンス
グリッドとビジネスのかかわり方は大きく二つある。「ビジネスにおけるグリッド（の適用例）」と「グリッドにおけるビジネス（の展開）」である。両者は混同されている場面が見受けられるので，これについて順に述べていこう。
まず，ビジネスにおけるグリッド。ビジネスにおけるグリッドは，業務システムの運用コストを最小限に抑えるための現実的な解である。科学技術計算で培われたグリッド技術をビジネス分野に向けて転用することで，コンピュータやネットワークを効率的に管理・運用する。
具体的には，グリッド技術を用いることにより，利用可能なコンピュータ資源を仮想化して予備のリソースとして配置しておく（リソースプール）。コンピュータ資源の管理を自動化することで，資源が不足した場合にはプールから新たにリソースを追加し，余剰になった場合にはプールに戻す。これを動的に繰り返すことで，コンピュータ資源の利用効率を上げる。
例えば，現在は企業内または企業グループ内で個々に業務システムを導入している。それぞれのアプリケーションや業務分野，管理部門ごとに個別にコンピュータ・システムを抱えており，それらは相互に融通することができない。そのためハードウェアとソフトウェアの両面で重複が起きている。基幹業務では欠かせないシステムの2重化がその重複に輪をかける。
グリッドによって仮想化されたリソースプールを用意することで，バックアップ・システムの動的な構築や企業内でのリソースの共有が可能になる。さらにはグループ企業でのリソース共有による全体最適の実現や個々のシステムの稼働率の向上などが見込める。
一方グリッドにおけるビジネスには，グリッド関連のハードウェア/ソフトウェアの開発・販売，グリッドのASPサービスやコンサルティング・サービスなどがある（図4[拡大表示]）。費用削減や利益率向上が叫ばれる中，システム部門の切り離しが進みつつある。データセンターへの情報システムのハウジングやホスティングに始まり，さらにはシステム部門のすべてをアウトソースする企業が増えている。情報システムを所有する時代から，必要な機能・サービスだけを買う・借りる時代へと変わり始めている。Webサービス，サービス指向アーキテクチャ（SOA）などを実現する情報基盤技術の一つとして，グリッドは多くのエンドユーザーにとって「作る」ものから「買う」ものに変わっていくはずだ。
すぐにでも商業化できるのは，グリッド技術に支えられたASPサービスであろう。またユーザーからの要求に応じて必要なサービスを探し出してくるという，リソース・ブローカのようなグリッド独自のビジネスの登場が待たれている。
10年後のグリッドと夢
前編・後編を通して，グリッドにまつわる話題を記してきた。技術の渦が出来上がり，社会を巻き込んでいく様子を，渦の中から見ることができたという貴重な機会を得られたのは幸せである。
我々の産業技術総合研究所グリッド研究センターは6年9カ月の期限が設定されている。情報技術の流れは速い。約7年間の研究期間が終了するころには，誰でもが「グリッド」という言葉を知っていて，子供たちの日常会話に出てくるようになるのではないかと設定当時に思った。既に欧州では，運用に必要な技術を見極める実証実験が始まろうとしている。また，この5月11日から開催されたGrid World 2005は約3000人もの参加者を集めた。ビジネスの広がりへの期待が実感された出来事として印象に残っている。冗談めいてはいるが，研究期間終了時の一つの目標は「えっ，まだグリッドを研究テーマにしているの？」と言われることだ。それくらい，成熟することを期待している（図5[拡大表示]）。
グリッドという概念が社会的認知を得ていないころは，企業へ講演に出向いても「えっ，そんなことができるのですか？」「何の役に立つのですか？」といったつれない声をよく聞いた。そんな企業も今では，グリッドを重要な戦略の一つとして位置づけている。誰もが知る技術となってしまっては，黎明期に渦を作ったということなど何の役にも立たない。過去の実績ではなく，それによって培った実力が技術革新の原動力となる。今，その瞬間の舵取りが重要である。
これからの10年。グリッドを取り巻く環境はどうなるのだろうか。何から何まで，思ったものが思ったところに，思っただけ得られる。そんなグリッドはいつまでも目標である。
夢のようなグリッドでは，グリッドがコンピュータやネットワークの状態をすべて監視し，次に実行されるアプリケーションの要望や実行時間を予測し，必要なサービスレベルを満足しながらコンピュータ資源を必要なところに割り当てる。その上でさまざまなプログラムが動作可能となったり，コンピュータ資源が回収されたりする。一連の動作はすべて自動的に行われる。
しかし本当にコンピュータだけをグリッドでつないでおけば，すべてのことがうまく進むのだろうか。そうは思わない。パソコンのOSと同じように，常に管理者（＝ユーザー）が間に入って判断をする必要があるだろう。グリッドの最適化の最後のひとさじは人間の判断だ。それが，仮想化されたのっぺりとしたグリッドの世界に価値創造を生みだす。このような泥臭い場面は，コンピュータによる完全な自動化が決してできないところである。完全自動化という夢よりも，むしろ人間（＝価値創造者）とコンピュータが対話し，コンピュータは適切なツールを提供するとともに求められる情報を即座に差し出し，最終的な判断は人間に任せるというモデルが正しいのではないだろうか。人間の判断力を最大限活用する。その見極めが今後のグリッドの成否を握っているとも言える。
科学技術計算に携わる者として見るもう一つの夢は，科学技術におけるあらゆる場面での応用だ。科学技術はますます高度・複雑なものとなっていくだろう。一方でエンドユーザーは複雑さを意識せず，自分のアクセスしたいものすべてを自分の端末やWebブラウザの中に取り込める世界がやってくる。昼間に世界中の天文台のデータを覗いたり，衛星データで撮った詳細な画像で仮想旅行を楽しんだり，脳細胞の美しい画像に見入ったり。プロから素人まで科学に触れることができるようになる。その時はもちろん，「グリッド」などという言葉は意識下にない。そう信じている。
グリッド標準化における日本の存在感国際的な標準化が進むグリッドだが，日本の存在感はかなりのものと自負している。GGFは，2001年3月に米国の「Grid Forum」，欧州における「European Grid Forum」，アジア太平洋地域の「ApGrid」などの活動を統一して，国際的な標準化の舞台を設定した。 この結成当初から，早稲田大学の村岡洋一教授が諮問委員会の委員として，東京工業大学の松岡聡教授と私が運営委員会の委員として参画できた。これは，松岡教授のコミュニケーション能力によるところもあるが，グリッドの概念がまだ定まらない早い段階から技術開発を主導してきたという実績が裏付けとなっていることは間違いない。 初回のGGF会議における日本からの参加は10人くらいで，多くは産業技術総合研究所グリッド研究センターにおけるグリッド・ミドルウェアである「Ninf」プロジェクトの関係者だった。今では企業からの熱心な参加者も増え，毎回100人近い参加者を数えている。 GGFの歴史は既に5年目に突入し，国際会議の開催も13回を数えた。GGFがアジア太平洋地域を含めて積極的な国際化を図ろうとしてきたことと運営委員会レベルでの発言力が強かったことから，2003年の第7回GGF会合は東京で開催できた。また，グリッド協議会をGGFの地域フランチャイズとして運用するというモデルの実現など，日本からは多くのアイデアを提案している。 標準化は，結局のところ人と人との調整である。調整を取り仕切る議長に対する雑感を記しておきたい。 初代の議長は米国アルゴンヌ国立研究所のCharlie Catlett氏だ。Catlett氏はこうした国際的活動に当たって非常に多くの要求を聞きつつ，困難を伴うなか，組織を立ち上げて軌道に乗せた。このことは高く評価されている。しかし，学術研究機関の出身であったこととほかにも多くのプロジェクトを抱えていたこともあり，一部の企業からは不評だった。 氏の後任として議長に就任したのは，米Hewlett-Packard社のMark Linesch氏である。HPでのマネジメントの実績を最大限に生かし，ビジネスライクにGGFの改革を進めている。特に，標準化ドキュメントの迅速な策定に力点を置き，そのために必要な内部組織と運営モデルの改革を進めている。 |
関口 智嗣 Sekiguchi Satoshi産業技術総合研究所グリッド研究センター センター長 |
