News | 2003年2月27日 00:22 AM 更新 |
デモでは、システムの負荷、レスポンスタイム、稼動サーバ台数の時系列変化をグラフ表示していたが、オートノミック機能オフで8秒だった高負荷時のレスポンスタイムが、オートノミック機能オンで1秒未満と激減していた。時系列変化のグラフを見ると、実際に負荷が高まる2秒前には負荷予測が行われ、Webサーバも負荷が高まる前に稼動台数が増加(デモでは1台だったのが3台まで稼動している)している。
フォーキャスターで行う負荷予測は、負荷の時系列変化を波動関数に置き換えるアルゴリズムで行っている。時分秒単位の短期予想も、月週日単位の長期予報も同じアルゴリズムで処理され、長期予想の場合、短期変化はノイズとして平滑化されている。
今回のデモでは、10秒スレッドで負荷情報を取得し、6点変化(すなわち1分間の変化)から将来予測を行っているが、これはあくまでもデモのための設定。実際の運用では、もう少し負荷のかからない分単位スレッドで取得する程度で、十分精度の高い予測が可能としている。
負荷に合わせたリソースを算出するHVWSシミュレータには、システムを構成するサーバごとのパフォーマンスデータと、そのパフォーマンスで処理できる負荷の高さを対比させた巨大なテーブルが収録されている。予想される負荷の高さをこのテーブルに照らし合わせて、必要とされるパフォーマンスとサーバの台数を出力を求めるようになっているのだ。
求められる開発プロトコルのデファクト化
ハードウェア的には現行のレベルで十分対応できるオートノミックスだが、実用化までに解決しなければならない問題はまだ多い。
デモでは優先トランザクションの選択や、グリッドコンピュータとリンクさせてワークロードの負荷分散などを次の開発ステップの目標として掲げているが、関係者によると、もう1つの課題として「モジュール間の通信プロトコル」の問題が上げられる。
現在のHotRodではモジュール間通信にSNPを採用しているが、実用化を考えた場合、SNPでは機能不足になると予想している。IBMでは、高機能の新しい通信プロトコルの開発を現在進めているが、「IBMのオートノミックコンピューティング」を普及させるためには、新しいプロトコルがデファクトスタンダードとして広く認識される必要があるわけだ。
グリッド最大の課題は「具体的な利用提案」
先日の日本IBM決算発表で大歳卓麻社長がアピールしていたグリッドコンピューティングの展示も行われ、高解像度画像を9分割し、分割した各画像の処理をグリッドで結合している3台のサーバに割り振って行わせるデモや、スプレッドシートの複数のセルに行わせる5万回ループ計算をセルごとにグリッド接続のサーバに分散して処理をさせるデモが注目を集めていた。
IBMのグリッドコンピューティングは、現在ミドルウェアにGlobus Toolkit Ver.2を採用している。接続しているマシンのリソース情報の取得、動作状況の把握、負荷に合わせたタスクアサインなど、グリッドコンピューティングに必要な機能はこの現行のToolkitで実現できるということなので、自然科学計算の特定用途ならばグリッドコンピュータは十分実用化が可能な状況にあると言ってもよい。
さらに、2003年末にリリース予定のGlobus Toolskit Ver.3では、Webサービスインタフェースモジュールが実装される。これによって、これまで難しかったインタフェース周りの開発や、Webサイトとの接続が容易になり、商用ベースのグリッドコンピューティングの利用が進むことが予想されている。
こうなると2004年はグリッドコンピューティング元年か、と思いたくなるが、しかし、なかなかそうはいかない事情がある。
まず問題なのがパフォーマンス。オープンソースの壮大な合体であるGlobus Toolkitに含まれるライブラリは、それぞれのオーバーヘッドが大きく、パフォーマンス向上の足かせとなっている。ただ、この問題はソフトウェアのチューニングが進むことで解決は可能とIBMは考えている。
より大きな問題は「ビジネスクライアントに対して具体的な利用提案ができない」ことだ。グリッドコンピュータはその構成上の特性から、膨大な単純計算の繰り返しでは威力を発揮するが、ビジネス利用で求められるバッチ処理など、多数ステップによる順次処理には向いていない。
いわばグリッドは「素晴らしいモノが出来そうだが、その使い道がまだわからない」状態なのだ。その解決――グリッドならではの使い道の発見が、グリッドコンピューティングの普及にとって、最大の鍵となりそうだ。
関連リンク
[長浜和也, ITmedia]
Copyright © ITmedia, Inc. All Rights Reserved.
前のページ | 2/2 | 最初のページ