レベル: 中級 James W. Penney (penney@us.ibm.com), Portfolio Chief Engineer, IBM
Mahi R. Inampudi (inampudi@us.ibm.com), Lead IT Architect, IBM
Moon J. Kim (moonkim@us.ibm.com), Chief Architect, Strategic System Initiatives, IBM
2005年 10月 18日 IBM のアプリケーション開発者は、グリッド・システムに接続しなくてもグリッド対応アプリケーションを構築できるような方法を求めていました。そしてその解決策となったのが、IBM Global Account (IGA) グリッド・アーキテクチャーと呼ばれるグリッド・フレームワークを構築することでした。ここでは、この作業に当たった著者がグリッド・フレームワークのアーキテクチャーと各コンポーネント、および展開モデルについて説明します。
アプリケーション開発者向けのグリッド・アーキテクチャーを構築した理由
この記事では、アプリケーションのグリッド対応化を進める IBM 社内開発者を支援するためのツール、すなわち「IBM Global Account (IGA) グリッド・アーキテクチャー」について、その技術概要を示します。IGA グリッド・アーキテクチャーの目標は、グリッド開発者が、複雑なグリッド・システムを開発作業時に使用しなくても、グリッド・フレームワークのアプリケーションを設計したり、さまざまな開発フェーズでグリッド・コンピューティング設計の威力を体験したりできるようにすることです。
IGA グリッドでは、現在利用可能なテクノロジーによって、ホスト環境のグリッド・ソリューションに対する差し迫った要求に応えようとするものです。このアーキテクチャーでは、社内のさまざまなロケーションに展開された個々のメインフレーム・サーバーから、グリッド・インフラストラクチャーを作り出します。つまり、各メインフレーム・サーバーの未使用のリソースを活用することによってサーバー統合を行い、総所有コスト (TCO) を削減するのです。このアーキテクチャーは、現在利用できるほとんどのグリッド・フレームワークとの連携が可能です。アプリケーションには、グリッド・コントローラーからのリモート呼び出しをオフにして LocalGridFacade を使用するようなスイッチを設定できます。この記事では、この種のシステムの基本要件について論じるとともに、システムのコンポーネントとアーキテクチャーについて説明します。
また、IBM の IGA グリッド・フレームワークのアーキテクチャーを示し、その展開モデルについて概説します。自社の開発チームに適したグリッド・フレームワーク環境を構築したいとお考えの皆様にとって、ここで提示するモデルがお役に立てば幸いです。
最初に、グリッドがもたらすメリットを再確認しましょう。
グリッドの目的
グリッド・コンピューティングは、サーバー・プールの使用効率を改善します。最も単純な形態のグリッド・コンピューティングでは、サーバー資源、ストレージ・システム、ネットワークなどが 1 つの大規模なシステム内に組み込まれます。同時に、特定の目的を持つ単一のユーザー環境の場合よりも高いスループットが提供されます。
グリッドの主目的は、資源を仮想化して問題を解決することです。グリッド・コンピューティングでは、以下の主要資源に対するアクセスが提供されます。
- コンピューティング能力と処理能力
- データ・ストレージとネットワーク化されたファイル・システム
- 通信手段と帯域幅
- アプリケーション・ソフトウェア
図 1 は、従来型のグリッド・アーキテクチャーを図解したものです。
図 1. 従来型のグリッド・アーキテクチャー
現在、「アプリケーションによるグリッド・テクノロジーの利用」を可能にするアプリケーション・フレームワークは数多く存在しており、IBM でも複数構築しています。そういったグリッド・モデルのアーキテクチャーのほとんどは、互いに似通っています。すなわち、ほとんどのモデルでは、要求に応じてグリッド・ノード (サーバー資源) を動的にタスクに追加し、スループットを改善できるのです。
資源利用率の低さが原因で、膨大な量のコンピューティング能力が無駄になっています。一般に、コンピューティング要件のプランニングとサイジングはピーク時の需要に基づいて行われるため、統計上、実際の利用率は 60 パーセント程度にとどまります。未使用のコンピューティング能力の有効活用は (これは IGA のもう 1 つの目標でもありますが)、メインフレーム・サーバーを多数保有する組織にとって、直接的な経済的メリットをもたらすことでしょう。
IGA グリッド・アーキテクチャー
現在 IBM で使用している IGA グリッド・アーキテクチャーは、Globus Toolkit 3.0 (GT3) を使用して構築されたものです。近い将来には、GT4 を使用するバージョンの構築作業が行われる予定です。
一般的な GT3 環境では、グリッド・タスク間の分離性は、プラットフォームとなるオペレーティング・システムが使用する分離メカニズムに基づいています。通常、グリッド・タスクはオペレーティング・システム内部の個別プロセスとして実行されるため、オペレーティング・システムによって制御される資源は、グリッド・タスク間で共有されます。このような状況では、意図的または偶発的な形で、あるタスクのデータ漏れやデータ破損が別のタスクにより引き起こされる可能性があります。
IGA グリッドは、グリッド・ジョブ間の独立性を高めることによって、グリッド環境のプライバシーとセキュリティーを強化します。IGA デザインでは、IBM では、GT3 の分離メカニズムを別のモデルに置き換えました。具体的には、同一の Linux® インスタンス内で複数の User Hosting Environment (UHE) インスタンスが実行されるのではなく、個々の UHE インスタンスがそれぞれ独自の Linux インスタンス内で実行されるようになりました。その結果、別々のユーザーに属するジョブ間で資源が共有されることは一切なくなりました。
図 2 は、世界各地に地理的に分散されたさまざまなデータ・センターのトポロジーを示したものです。
図 2. IGA グリッド・アーキテクチャー
 |
GT3 における UHE
GT3 の Globus Resource Allocation Manager (GRAM) は、User Hosting Environment (UHE) および Master Hosting Environment (MHE) という、2 つのサービス・コンテナーで構成されています。UHE は、送信側のクライアントに対してジョブのステータスを通知するとともに、FSS を使用してジョブの出力 (例えば、stdout および stderr) をクライアントにリダイレクトします。このアーキテクチャーでは、「プロセスを root として実行する」といったセキュリティー上の問題点が防止され、ユーザー・アカウント内で構成済みの UHE のみを起動できる setuid プログラムが使用されます。
|
|
グリッド・ユーザーとシステムとの情報のやりとりは、グリッド管理センターを介して行われます。グリッド管理サービスには、1 つのジョブ管理サービスと、一般的なアドミニストレーション・サービスおよびユーザー管理サービスが含まれています。各データ・センターには、zSeries® または S/390® のノードが 1 つ以上設置されています。このインフラストラクチャー内では、AIX® ノードの接続も予定されています。また、データ・センターのノードは、ホモジュアスの場合もあれば、ヘテロジュアスの場合もあります。図 2 では、各データ・センターが世代の異なるマシンの組み合わせを有しています。
メインフレームのノードは、論理パーティショニングによって分割されます (個々の論理パーティションは LPAR と呼ばれます)。個々の LPAR は、それぞれが独自のホスト・オペレーティング・システムと 1 つ以上のアプリケーションを持つ、独立したシステムとして動作します。一般にデータ・センターで定常的にホストされているアプリケーションに対しては、1 つ以上の LPAR が専用に割り振られます。
しかし、空白部分を使用すれば、グリッド・インフラストラクチャー用の特別なパーティションを作成できます。このパーティションは Grid LPAR と呼ばれ、他の LPAR よりも低い優先順位で、他のパーティションとの間で仮想プロセッサーを共有します。そのため、このノードをグリッドで使用しても、メインフレームの通常の動作が妨げられることはありません。Grid LPAR が使用するのは、メインフレームの処理能力の余剰部分のみです。
2 つのフレームワーク・プログラミング・モデル
図 1 に示されているように、従来型のグリッド・アーキテクチャーは以下の設計に従っています。
- アプリケーション・クライアントがグリッド API を使用してジョブを呼び出し、グリッド・コントローラーがグリッド・サーバー上にジョブをスケジュールします。
- グリッド・コントローラーがタスクを複数のサブタスクに分割し、グリッド内のいくつかのグリッド・ノードにそのサブタスクを割り当てます。
- グリッド・コントローラーが呼び出すグリッド・ノードの個数は、その性質上、動的に変動します。
- 個々のグリッド・ノードで得られた結果が、結果コレクターによって収集されます。
- 結果コレクターが、呼び出されたジョブの結果をグリッド・コントローラーへ返します。
- グリッド・コントローラーが、結果をアプリケーション・クライアントへ返します。
図 3 は、IBM 社内で使用されているもう 1 つのグリッド・フレームワーク、intraGrid のアーキテクチャーを示したものです。intraGrid はグリッド・アプリケーションをサポートしています。intraGrid では、アプリケーション・クライアントが intraGrid API を使用してジョブをスケジュールし、グリッド・コントローラーが複数のグリッド・ノードにわたってサブタスクを呼び出します。これにより、ジョブ実行時のスループットが向上します。
図 3. intraGrid プログラミング・モデル
次に、IGA 設計の重要コンポーネントである LocalGridFacade に注目してみましょう。
LocalGridFacade モデル
LocalGridFacade は、単一サーバー上での資源利用率を向上させるシンプルなグリッド・フレームワークです。このフレームワークを使用することにより、開発者は、あらゆるグリッド・フレームワークに適合したアプリケーションをこのローカルの開発環境で構築できます。図 4 は、この設計を図解したものです。
図 4. LocalGridFacade の設計
複数に分割して分散サーバー上で並列実行することが可能な大規模タスクには、コンピューティング・グリッドが使用されます。スループットの向上がその目標ですが、以下に示すように、この種のアプリケーションにおけるパフォーマンスの定義は、Web トランザクション・アプリケーションにおけるパフォーマンス定義とは異なります。
-
スループットの向上 -- LocalGridFacade を使用して開発したアプリケーションでは、スループットが大幅に向上します。「ローカルのグリッド・ノード数が多いほどスループットは向上する」という点に注意してください。LocalGridFacade を使用すれば、ローカル・サーバー上での資源利用率が向上する可能性があります。
-
開発フレームワーク -- すべてのアプリケーションがグリッド・システムに適しているわけではありません。グリッド・フレームワークに適したアプリケーションを構築するには、複雑なシステム・アーキテクチャーに取り組み、フレームワークとグリッド・ノードとの対話方法について理解する必要があります。LocalGridFacade では、それを簡単にします。アプリケーション開発者は、並列処理用の複数の作業単位にタスクを分割してアプリケーションを構築し、そのインプリメンテーションをローカルでテストできるようになるからです。これにより、実際のグリッド・フレームワークがなくても、ローカルの開発環境上でグリッド・フレームワークの感覚が得られます。
-
シンプルな展開 -- LocalGridFacade によってジョブはサブジョブに分割されています。そのため、展開構造を容易に理解できます。
それでは、いくつかのコンポーネントについて簡単に見てみましょう。
グリッド・コントローラー
グリッド・コントローラーは、LocalGridFacade のクライアント・インターフェース部分です。グリッド・コントローラーは、プロパティー・ファイルで指定されたパラメーターに基づいて、LocalGridFacade を使用すべきか、リモートのグリッド・フレームワークを呼び出すべきかを決定します。グリッド・コントローラーがローカル・グリッドを使用するように設定されている場合は、指定された数のローカル・グリッド・ノードが呼び出され、グリッド・コントローラーがそれぞれのグリッド・ノードにサブジョブを割り当てます。
グリッド・ノード
コンピューティング・グリッドとデータ・グリッドはいずれも、「グリッド・ノード」と呼ばれる、同種構成の比較的小さなコンポーネント群 (またはサーバー群) を伴います。
結果コレクター
コンピューティング・グリッド上またはデータ・グリッド上でアクティブなグリッド・ノード・コンポーネントはすべて、サブジョブまたはサブタスクの処理結果を、結果コレクターに送信します。結果コレクターは、すべてのアクティブなグリッド・ノードから結果を収集し、その結果を集計した上で、スケジュールされたタスクの完了時にグリッド・コントローラーに結果を返します。グリッド・コントローラーは、その結果をアプリケーション・クライアントへ返します。
アプリケーション・クライアント
「アプリケーション・クライアント」は、グリッド API を使用して、グリッド・コントローラーとジョブをスケジュールします。通常、グリッド・コントローラーには通知機能が備わっているため、グリッド処理が完了した時点で、グリッド・コントローラーからアプリケーション・クライアントに対して「完了」を通知できます。
展開モデル
図 5 は、LocalGridFacade タイプのシステムの典型的な展開モデルを示したものです。
図 5. 展開モデル
展開モデルの観点から見ると、グリッド・アプリケーションのプロセスの流れは、他のアプリケーション開発の流れととてもよく似ています。まず、プロジェクト責任者がビジネス要件を提示します。その要件を IT アーキテクトが分析し、アプリケーションのアーキテクチャー内でグリッド・コンピューティングを使用した場合のビジネス・メリットについて評価した上で、グリッド・コンポーネントの必要性を判定します。さらに IT アーキテクトは、グリッド対応アプリケーションの構築に使用するツールや製品を決定し、「スループットがそのアーキテクチャーにとって最も重要な課題かどうか」を判定します。こういった作業を経てようやく、開発者は、グリッド・アーキテクチャーの複雑さを意識することなく、LocalGridFacade でアプリケーションを構築したり、統合開発環境 (WebSphere® Studio Application Developer や Rational® Application Developer など) のもとでアプリケーションを開発したりできるようになるのです。アプリケーションの開発が完了すれば、ビルド担当者とグリッド管理者がそのアプリケーションを構成し、グリッド・コンピューティング・アーキテクチャー上に展開できるようになります。
図 6 は、技術的観点から見たシステムを示したものです。
図 6. 展開モデル
技術設計の観点から言えば、LocalGridFacade の作業単位は、グリッド・クラスター内の個々のグリッド・ノード上で実行されます (すべて単位 1 つ分ごとに制御されます)。intraGrid Management Service が個々のグリッド・ノードの結果を統合し、クライアント上で稼働している Globus Tookit NotificationListener を使用して、アプリケーション・クライアントにそれらの結果を渡します。
アプリケーション開発後、LocalGridFacade は、実際のアプリケーションと IGA グリッド・フレームワークとの間に位置する単なる追加層として機能します。1 つのグリッド上の資源使用量を増加させるためと、必要なグリッド・ノード数をグリッド・ポータルで動的に制御させるために、グリッド・アプリケーションが localGrid の連結を必要とするかどうかはアプリケーション設計者の判断に任されます。このモデルにより、IGA へのグリッド・アプリケーションの展開はシンプルになります。
まとめ
IGA グリッド・アーキテクチャーというメカニズムでは、アプリケーション開発者は、実際にグリッド・システムに接続しなくてもグリッド対応アプリケーションを構築できます。この記事では、IBM で使用されているこのアーキテクチャーの技術概要について、以下の項目に絞って概説しました。
- 開発者がグリッド・システムの根底にある複雑性 (および従来型のグリッドと IGA 版との違い) を理解することの必要性
- IGA システムの基本要件
- このシステム内のコンポーネントの詳細
- アーキテクチャーの概要
- この種のシステムの展開モデルの概略
参考文献 学ぶために
製品や技術を入手するために
- Download the Globus Toolkit from Globus.org.
-
alphaWorks is a repository for downloadable software, including ZetaGrid (designed to solve large compute-intensive problems) and the Grid Application Framework for Java (for abstracting grid semantics from application logic).
著者について | 
| | James W. Penney is an IBM-certified executive IT architect responsible for the development of a wide range of solutions that support IBM internally. He is the chief engineer for a subset of the IBM portfolio, including IBM Global Services, IBM Global Financing, HR, and Finance. In addition to implementing grid technologies in the application space, his interests include continuous improvement in application development methods and agile programming methodologies. |
| 
| | Mahi R. Inampudi is the lead IT architect for IBM's On Demand Workplace expertise location system (BluePages). Other responsibilities include the architecture and solution design for several of IBM's internal offerings and collaborating with the CIO office and IBM Research helping design applications using the latest SOA methods. Recent interests include leveraging newer technologies, such as WebSphere Extended Deployment, the Rational product suite, and IBM's intraGrid architecture. |
| 
| | Moon J. Kim is an IBM senior technical staff member responsible for the development of strategic infrastructures, including grid computing. He has developed such system solutions as the Advanced Web System and the Broadband Interactive System, and was a key architect and developer of the S/390 family and MPP systems. He is an IBM master inventor and has published numerous technical papers and books. |
記事の評価
| 
