異機種接続の中核技術に

 現在のグリッド事例は、同じ機種のサーバー同士を接続する使い方が中心だ。用途も、処理の分散による時間短縮やコスト削減が目的の「データ・グリッド」がほとんどである。

図1-3●ユーティリティ・コンピューティングの時代には、グリッド技術の利用方法が変わる
現在は、複雑な分析処理を複数のサーバーに分担させるのが主な目的。同機種のハードを使うのが主流だ。今後は「異機種のハード/OSをつないで論理的に一つの仮想サーバーを作るための中核技術」という位置付けになっていく

 しかし富士通研究所の岸本主管研究員は、「今すぐとはいかないが、あと3年もすれば異機種接続が実現する可能性がある」と予想し、ビジネス向けの業務アプリケーションでグリッドを使う「ビジネス・グリッド」の本格化を示唆する。グリッドは異機種間でありとあらゆるシステムを共有するのに使ってこそ、実力を発揮できるわけだ。

 ただし、グリッドで異機種サーバーを接続したり、異なるグリッド・ソフトどうしがやり取りできるようにするには、「標準化」の問題をクリアする必要がある。

 すでにIBMは、グリッド・ソフトをオープン・ソースで開発する「Globusプロジェクト」や、Webサービスとグリッドの融合技術であるOGSA(Open Grid Services Architecture)など、技術の標準化に向けた動きを積極的に推進。グリッド技術の標準化団体である「グローバル・グリッド・フォーラム(GGF)」を支援している。日本でも、経済産業省が富士通や日立製作所、NECといった国産ベンダーとともにグリッド技術のビジネスへの適用を目指した取り組みを始めている。

 ただし、標準化への取り組みは緒についたばかりだ。2010年までに標準化が進み、グリッドがさまざまなシステムで使われるようになって、異機種サーバーをつないで使う時代が訪れると予想される注1-5)図1-3[拡大表示])。

注1-5) グリッド技術の進化で、「小型コンピュータをつないで仮想サーバーを構成する分散コンピューティングにも拍車がかかる」(米IBMのナグイ・ハリム ディストリビューテッド・コンピューティング担当)。だからといって、大型サーバーが不要になるというのは早計だ。
 米IBMでeServer iSeriesのチーフ・サイエンティストを務めるフランク・ソルティス氏は、「ハードはコモディティ(大衆製品)化するわけではない」と力を込める。大型サーバーも巨大な仮想サーバーを構成する一要素として、使われていくという見方である。提供するサービスの品質によって、ベンダーの使うハードが分かれることもあり得る。

人手に替わるオートノミック

 小型化・高性能化したコンピュータをグリッド技術で大量に接続する場合、ハードの修理やエラーの発見・復旧にかかる手間も台数に比例して膨らむ。ブレード・サーバーが1万枚あれば、1枚当たりの稼働率が99.9%でも毎日10台は壊れる計算になる。100万台なら毎日1000台だ。サーバーを取り替えてリセットするだけでも一苦労。人手でこなすのは明らかに非効率的だ。

 発生し得る問題はほかにもある。接続するサーバーの台数や種類が増えることで、「システム全体の管理はより複雑になる」(日本HPの九嶋本部長)。

 そうした課題を解決して2010年のユーティリティ・コンピューティングを実現するのが、オートノミック技術だ。ここで言うオートノミックは、システムの自律的な動作を実現する技術の総称。特定ベンダーの技術戦略を指す言葉ではない。

 言い方の違いはあっても、ほとんどのベンダーがオートノミックに関連した技術開発や強化に挑んでいる。IBMが唱えるオートノミック技術を例に説明すれば、監視、分析、計画、実行といった流れでシステムが自律的に動くアーキテクチャのことを指す。

 オートノミック技術と現在の運用管理技術との違いは、トラブルが起きたケースで比較すると分かりやすい。

 例えば、生産管理システムで通信エラーが起きたとする。このとき、現在であれば運用担当者はネットワーク構成に従い、ルーターやケーブルに異常がないかを確認する。同時に、監視ツールを使ってハードウエアに不具合が発生していないか、アプリケーションが異常終了していないかといったことを、あらゆる観点から調べる。

図1-4●オートノミック技術が進化すると、システムは「業務上のポリシー」に基づき自律的に動作するようになる

 原因が見つかったら、対策をそのつど考えて適切な処置を施す。機械の故障であれば取り替える。ハードを取り替える間、アプリケーションをいったん終了させるべきかも考える。ユーザーにはシステムが臨時で使えなくなったことを速やかに通知する。

 一方オートノミック技術を実装した監視ソフトは、トラブルが発生したときに対策方法を自ら導き出し、実行する(図1-4[拡大表示])。通信エラーを検知したら、すべての通信機器やサーバーからの信号を収集して、稼働状況を確認。障害個所を発見したら、今度はシステム構成情報に基づいて最適な対策のスケジュールを検討する。過去の同様のトラブル事例から、影響が最も小さくなるような復旧方法を計算し、ユーザーへの通知も忘れない。