レベル: 中級 Judith Myerson (jmyerson@bellatlantic.net), Systems Engineer and Architect
2008年 3月 06日 グリッドのタイプ、グリッド・コンピューティング、そして GIG (Global Information Grid) について学んでください。この記事では、スタンドアロンのマシンでは対処しきれないようなコンピューター処理能力が要求される場合に未使用のリソースを活用するのに伴う問題に焦点を当て、グリッド・スケールの変更の監視、グリッド結合の切り替え、さらに GIG とSOA (Service-Oriented Architecture) のテスト方法などのソリューション例を紹介します。
はじめに
developerWorks の連載「WebサービスのコンテキストにてSLAを使用する」では、複数の Web サービスをサービス・レベル・アグリーメント (SLA) の保証によりセキュアにする方法を説明しました。また、別の連載「エンタープライズ規模の SOA における Web サービスの取り扱い」では、サービスを構築するスピードとサービスの信頼性 (複数の SOA の徹底した防御) を向上するために、複数の SOA を多面的に統合する方法、そして XOP (XML-binary Optimized Packaging) によって Web サービス・アプリケーションを高速にする方法について取り上げました。同連載では、Web サービスのロード・バランシング、連邦領域で SOA を採用する際の文化的考慮事項、そして SOA における密結合の Web サービスについても検討しています。
上記の記事それぞれが明らかにしているは、複数の SOA の Web サービスを実行するためにリソースを最適化するという傾向です。SOA によるサービスをグリッド・スタイルおよびネット中心のスタイルへと移行することで、グリッド内のコンピューターの使用されていないリソースを活用して共有できるようになります。
アプリケーションとシステムを接続する Web サービスをグリッドに移行させることで、互いに連携する複数のコンピューターのリソース容量を同時に拡張することが可能になります。この方法が意味することは、スタンドアロンのマシンのリソースを 1 箇所で固定的に使用するというパラダイムから、複数のマシンのリソースをあらゆる場所で同時に、動的に共有するというパラダイムへの転換です。
この記事を読んで、グリッドのタイプ、グリッド・コンピューティングの概要、そして GIG の目的を理解してください。また、ここではグリッド・コンピューティングの概念と構造に何が欠けているかを検討し、問題に対する解決案も提供しています。
グリッドのタイプ (サービス)
サービスの観点から見たグリッド・コンピューティングは、専用グリッド、非専用グリッド、分散グリッドのうち、どのタイプのグリッドを使用するかによって異なります。以下に、この 3 つのタイプそれぞれについて詳しく説明します。
専用グリッド
専用グリッドを構成するのは、そのグリッド専用に使用するハードウェアと計算リソースです。専用グリッドではオペレーションのあらゆる側面を選択できるため、グリッド・アーキテクチャーを最大限柔軟に制御することができます。このタイプのグリッドはグリッド・コンピューティングの最も柔軟な形態で、状況に最適なトポロジーおよびネットワーク・ハードウェアを選択できるという自由が与えられます。
非専用グリッド
非専用グリッドでは、既存のコンピューティング・インフラストラクチャーのリソースと環境を使用します。例えば、デスクトップ・コンピューターやサーバー・コンピューターの大部分がアイドル状態となっているときに会社のコンピューティング・リソースを使用するグリッドは、非専用グリッドということになります。非専用グリッドでは、グリッドで使用されていないときに、マシンをサポートするためのコア構造を変えることはできないため、専用グリッドほどには環境とネットワーク構造を制御することはできません。この場合、既存のネットワークとインフラストラクチャーに依存する可能性が高く、ネットワーキングに関する決定を制御することは、ほとんどできないか、あるいは不可能です。
分散グリッド
分散グリッドは、WAN またはインターネットの内部あるいは外部のあらゆる場所に分散するマシンのリソースで構成されます。ネットワーク構造を制御することは実質的には無理ですが、分散コンポーネント同士が確実に効率的な通信ができるようにすることや、その制御を行うことは可能です。この場合に管理の重点が置かれるのは、アクセス、セキュリティー (ファイアウォールと認証を含む)、そして障害時にも接続できるようにするバックアップ・ソリューションを提供することです。
グリッド・コンピューティングの概要
IBM® が早くから提唱し、貢献してきた商用グリッド・コンピューティングは、分散コンピューティングとデータ・リソースを仮想化することにより、処理、ネットワーク帯域幅、ストレージ容量などについて、単一システムのイメージを作り出すことを目的としています。それと同時に、大量のコンピューター処理サイクルや大量のデータ・アクセスを必要とする問題には、ネットワーク内に存在する多数のコンピューターのリソースが適用されます。
グリッド・コンピューティングは大量の計算能力を必要とする問題を解決する 1 つの方法で、言うなれば、分散された大規模なクラスター・コンピューティングであり、ネットワークに分散された並列処理のようなものです。グリッド・コンピューティングは、地理的境界を超えた企業内のコンピューター・ワークステーション・ネットワークに限定することも、パブリック・ネットワークを介したコンピューター間の連携 (ピア・ツー・ピア・コンピューティングなど) にすることもできます。
共通の目標に向けた連携動作を通じて、何千というコンピューターのリソースを協調して管理することが可能になります。グリッド内では未使用のリソースによってリソース負荷の均衡がとられることから、グリッド・コンピューティングはロード･バランシングの極端な形態とも言えます。
グリッド・コンピューティングには、1 つの大規模なシステムのイメージとしてのプログラムを区分し、それぞれの部分を数千のコンピューターに委託することが可能なソフトウェアが必要となります。この場合の 1 つの懸念は、あるワークステーション上でソフトウェアのある部分が失敗した場合、そのソフトウェアの別の部分が他のワークステーションで失敗する可能性が考えられることです。この可能性があるのは、ソフトウェアのその部分のフェールオーバーが別のワークステーションにはなく、しかも 1 つ以上のグリッド・コンピューティング・タスクを達成するためにソフトウェアのその部分と別の部分に依存関係がある場合に限られます。また、もう 1 つの懸念として挙げられるのは、ワークステーションの未使用リソースが十分に活用されないことから、わずかな遅延が生じることです。
GIG (Global Information Grid)
グリッド・コンピューティングは、米国防総省 (DoD) の GIG 構想で前提とする DoD システムの多様性に適応します。GIG に関連したグリッド・コンピューティングの使用方法には以下の 3 つがあります。
-
計算グリッド: 計算主体のオペレーションを重視したグリッド
-
データ・グリッド: データを処理するデータ計算システム - 大量の分散データの共有および管理を制御
-
装置グリッド: 装置のリモート制御および生成されたデータの分析に周囲のグリッドを使用
米国防総省では、GIG Enterprise Services をデータ・グリッド・タイプとして定義しています。これはつまり、システム中心のネットワークからデータ中心のネットワークへとパラダイムが変化していることを表しています。
リアルタイムの決定
GIG は、ユーザーがグリッド内のどの位置からでもオンデマンドで情報を利用、共有、収集、処理、保管、発信、管理できる環境の必要性に対処するために発展してきました。
GIG が目的とするのは、ネットワーク中心の環境で情報の優位性を実現することです。その手段として、スタンドアロンのマシンでは対処できない問題を解決する際に、各種システムとメッセージングをベースとした Web サービスが同時に相互運用できるようにします。GIG ユーザーは、複数の自動情報システム・アプリケーションから時間が経過した情報を取得し、その情報に依存するのではなく、情報を送信および取得してリアルタイムで決定を下すことができます。
低遅延
集約的ソリューションには、例えば IBM WebSphere® MQ Low Latency Messaging が提供するような、遅延の少ない極めて高いスループットが求められます。このようなソリューションは、高速の取引環境や分析環境における金融市場でのデータ量の急増に対処します。
1 対多のマルチキャスト・メッセージングのために設計された低遅延メッセージング・ソフトウェアは、120 バイトのメッセージを Ethernet では毎秒およそ百万件、InfiniBand では 3 百万件近く配信します。それよりサイズの小さいメッセージに至っては、一般的なあらゆる x86 サーバーで毎秒 8 百万を超える配信件数です。テスト結果でも、120 バイトのメッセージを毎秒 10,000 件配信した場合、InfiniBand での遅延は 30 マイクロ秒、Ethernet での遅延は 61 マイクロ秒と非常に低い数字となっています。
グリッドに欠けているもの
GIG は、オンデマンドで情報を伝達するグリッドにおける SOA に役立ちます。これはすなわち、グリッド・コンピューティングは今や、Web サービスの主要な SOA 標準などの、オープン・スタンダードおよびオープン・プロトコルに依存するということを意味します。
Web サービスがグリッドに移行した場合、これらの Web サービスの標準ではリソースおよびパフォーマンス上の問題をグリッド・レベルで解決しきれません。この場合に必要となるのは、WS-Resource Transfer 以上にグリッド環境のさまざまな領域を網羅する標準です。要件という点では、グリッド間の監視と管理、そしてセキュリティーに関する一般的な情報を保管し、回復するための方法としてこうした標準を使用することを考える必要があります。
問題は、一般的に疎結合された Web サービスはリソースが十分であろうとなかろうと実行されるという点です。したがって、複数のワークステーションのリソースがグリッド内で無駄にされないようにする方法を見つけ出さなければなりません。そのためには、グリッドに何が欠けているかを検討してから、ソリューションを考える必要があります。
グリッド・スケールでの変更の監視
グリッド以外の環境では、リソースの量はバックグラウンドで多くなったり少なくなったりする可能性があります。Web サービスがメッセージの送信または受信を待機している間、リソースは不足していることも、そうではない場合もあります。スケールの変更が何千というワークステーションで適切に制御されていなければ、グリッド内の 1 つのシステム・イメージに影響し、リソースの過負荷という結果になりかねません。
これに対する 1 つのソリューションは、各ワークステーションの未使用リソースが他のワークステーションによってどのように利用され、共有されているかを監視するグリッド・モニターを開発することです。このシステムは、未使用のリソースが適切に活用されていないワークステーションを検出した場合には、グリッド管理者とシステム管理者がログを調べて解決できるように両管理者にアラートを送信するようなシステムでなければなりません。
グリッドの切り替え結合
SOA における密結合の Web サービスについて取り上げた記事で、私はワークステーション・レベルでの結合切り替えメカニズムを備えた Web サービスについて説明しました。このメカニズムは、対応するリソースが特定のレベルに達したこと伝えるアラートを Web サービスが受信すると、密結合から疎結合に切り替えるというものです。Web サービスで切り替えが行われるときには、特定の WS 標準を切り替える必要があります (例えば、疎結合の場合には WS-Context、密結合の場合には WS-Addressing に切り替えるなど)。
グリッド・レベルでは、このメカニズムをさらに拡張することができます。例えば、グリッド・レベルでのリソースが特定のレベルに達すると、指定のワークステーションに一部の Web サービスを疎結合から密結合に切り替えるようにアラートを送信する Web サービスが考えられます。逆に、指定したワークステーションの Web サービスに、そのワークステーション内で密結合に切り替わった他の Web サービスのリソースが特定のレベルに達したときに、グリッドに対してアラートを送信させることも可能です。
GIG および SOA のテスト方法
GIG と SOA が対象ユーザーのニーズに確実に対応できるようにするには、包括的なテストを行う必要があります。GIG および SOA エンタープライズ・サービスの複雑性から、そのテスト方法はより詳細かつ徹底したものでなければなりません。それと同時に、システム・ビルダーから期待される急な変更や短期間の開発ライフサイクルに対応するため、マシン固有の機能からグリッド・エンタープライズに至るまでのさまざまな時間スケールで行えるテストであることも必須です。
まとめ
SOA サービスをグリッドおよびネット中心のスタイルに移行させるには、開発者、テスター、そしてシステム管理者とグリッド管理者からなるチームが必要です。さらに、この移行を行う際には、SOA サービスをグリッド・レベルで開発、マイグレーション、テスト、デプロイするための要件と役割をあらかじめ計画しておかなければなりません。これらの問題を解決すれば、SOA サービスをグリッドに移行させる作業はかなり容易なものとなります。そして IBM Rational® ClearQuest®、IBM Rational Tester for SOA Quality、IBM Rational Functional Tester、そして WebSphere MQ Low Latency を使用してグリッド・レベルでのテスト時間と問題追跡時間を短縮することで、生産性は向上するはずです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。 |
記事の評価
| 
