レベル: 初級 David Kra (dakra@us.ibm.com), Executive IT Architect, IBM
2004年 4月 27日 この記事では、シリーズの第 1 回目として、アプリケーションのグリッド化に関する 6 つの戦略を定義します。また、これらの戦略に適したアプリケーションの特性と、アプリケーションの実行組織にとっての利点を説明します。後続の記事では、戦略 1 から戦略 5 を使用してできるだけ少ない労力でアプリケーションをグリッド化する方法を説明します。
グリッド化について
アプリケーションは、グリッド上で実行できる限り、グリッド対応であるといえます。しかし、グリッドの完全活用という意味であれば、仮想化されたグリッド・インフラストラクチャーを利用して、処理時間を高速化したり、コラボレーションを増強したりすることを指します。OGSA を始めとするグリッド標準規格の整備がさらに進めば、グリッド対応とは、「グリッド・インフラストラクチャーによって提供される多様なサービスをオプションで利用しながら、アプリケーションをグリッド環境内で Web サービスとして実行できること」を意味するようになるでしょう。例えば、Java 2 Platform, Enterprise Edition (J2EE) または C アプリケーションは、次期バージョンの WebSphereR Application Server のようなグリッド対応ミドルウェアの最上部で Web サービスとして実行されます。その際、ミドルウェアとグリッド・インフラストラクチャーから提供されるサービスも、オプションで利用されます。
アプリケーションをグリッド化するには、6 つの戦略があります。これらの戦略は、単にアプリケーションをグリッドで実行するという段階から、グリッドを完全に活用するという段階までをカバーします。アプリケーションをグリッドで実行できるだけでも、お客様は利益を得て、あなたはレベニューと業界リーダーシップを得ることができます。このことは非常に重要なポイントです。また、現在のオファリングに含まれる機能 (ファイルの移動やスケジューリングなど) をグリッド化できれば、コア・コンピテンシーに関係のないコードを、機能を落とすことなく減らすことができます。
このシリーズのパート 2 では、6 つの戦略の最初の 2 つを使用してアプリケーションをグリッド化する方法を説明します。これにより、単一または複数の、場所に依存しないインスタンスのバッチ・ジョブとして、アプリケーションを実行できるようになります。パート 3 では、アプリケーションをグリッド化するための 6 つの戦略のうち、第 3 と第 4 の戦略について説明します。具体的には、バッチ・プログラムの処理を分割する方法や、クライアントがグリッド・ミドルウェアを通じて呼び出せるサービス・サブルーチンとしてプログラムを設定する方法について説明します。このシリーズのパート 4 では、アプリケーションがサービスを並列で使用するときに活用できる、新しいパラダイムについて説明します。
アプリケーションをグリッド化する場合は、Web サービスとしてアクセスできることが必須要件になります。例えば、アプリケーションが Session Enterprise JavaBeans (EJB) コンポーネントを Web サービスとして公開していたり、既存のコードを呼び出せる Web サービス成果物 (ラッパー、インターフェース、ファサード、ベニヤなど) を持っていたりすることが必要です。この要件を達成するためのツールも用意されています。
Web サービス仕様へのグリッド標準規格の採用が進むにつれて、Web サービスへの対応がますます重要になります。サービス指向アーキテクチャーと Web サービスは、戦略的グリッド環境が立脚する基盤となりつつあります。
この記事で説明するグリッド化のための戦略は互いに関連していますが、それぞれの持つ利点と、それを達成するために必要な労力は異なります。このシリーズでは、6 つの戦略のうち、グリッドの並行性または並列性に関する 5 つについて説明します。
どの戦略にも価値がありますが、すべてのアプリケーションに最上位の戦略を実装する必要はありません。第 5 の戦略に到達するアプリケーションはあまりありません。また、既存のアプリケーションの中で、第 6 の戦略を必要とするものはほとんどありません。戦略 6 は、最初からそれに対応するように設計された特殊なアプリケーションを対象としており、アプリケーションを構成する多様なプログラムのための膨大な密結合並列処理を必要とします。
また、アプリケーションには、ターゲットの戦略を順番に実装する必要も、一括して実装する必要もありません。例えば、「戦略 2: 独立並行バッチ」と「戦略 5: 並列サービス」の間には「戦略 3: 並列バッチ」と「戦略 4: サービス」が用意されていますが、必ずしも両方を実装する必要はありません。6 つの戦略の関係については、図 1 を参照してください。
図1. グリッド化に関する 6 つの戦略
これから説明する記述において、下位の戦略の利点は、上位の戦略では当然得られるものとします。また、先行する戦略における技術的な属性は、アプリケーションの前提条件として達成されているものとします。
6 つの戦略と、実装のための 3 つのステージ
この記事では、次の 6 つの戦略と、各戦略をアプリケーション内で実現したときに得られる利点について、簡単に説明します。
- 戦略 1: ノード非依存バッチ
- 戦略 2: 独立並行バッチ
- 戦略 3: 並列バッチ
- 戦略 4: サービス
- 戦略 5: 並列サービス
- 戦略 6: 密結合並列プログラム
これらの戦略は、実装のための 3 つのステージに分類することができます。
-
実行 : 戦略 1 と戦略 2 、および最も単純な形の戦略 3 では、アプリケーションをグリッド内で実行する能力に焦点を当てます。
-
適合 : より複雑な形の戦略 3 、および戦略 4 と戦略 5 では、グリッド・ミドルウェアに固有の多くの変更を加えることなく、ビジネス・アプリケーションがグリッドを使用できるようにして、機能と価値の適合性を大幅に高めます。同じアプリケーションを非グリッド環境で実行できるように構造化することもできます。
-
活用 : 戦略 6 におけるアプリケーションは最初からグリッドを念頭において記述されているため、運用には、グリッドまたはクラスターのインフラストラクチャーが活用されます。戦略 6 のアプリケーションをタイムリーかつ正常に終了するには、グリッドで実行することが必要です。
アプリケーションのグリッド化のための 3 つのステージのうち、6 つの戦略がどのステージに該当するかを、図 2 に示します。
図2. グリッド化のための 3 つのステージ
この 6 つの戦略は、相互に排他的なものではなく、「導入のステージ」または「統合の種別」と考えることもできます。これらの戦略は互いに関連しており、「ノード非依存バッチ」のジョブを実行する場合のような、導入のための比較的単純な戦略から、密結合並列プログラムを実行する場合のような、より強力なグリッド化に至るまで、それぞれの足がかりとして機能します。
ある戦略は前の戦略を発展させたものであるという意味で、6 つの戦略は互いに関連しています。例えば、資源が最も集中する処理をグリッド内の適切なコンピューター上で「ノード非依存バッチ」のジョブとして実行することで、既存のアプリケーションをグリッド化することもできます (導入のための第 1 の戦略)。どのマシンに割り当てるかは、実行時にグリッドによって決定されます。
その後、並行性を妨げる因子を排除してこのアプリケーションを進化させれば、グリッド対応の部分を、同じバッチ・ジョブの「独立並行バッチ」のインスタンスとして実行できるようになります (戦略 2)。これにより、一度に 1 つのインスタンスしか実行しない場合と比較して、アプリケーション全体のスループットが大きく向上します。
次に、以下のいずれかの方法でアプリケーションを進化させることができます。
- 並行性を妨げる因子をさらに排除し、グリッド対応の部分を「並列バッチ」ジョブとして実行できるようにする (戦略 3)。ここで変わるのは作業単位の定義であり、アプリケーションではありません。この場合の作業単位は、グリッド化のための最初の 2 つの戦略を実装するときに使用した、元の作業単位の配列です。2 つのコンポーネントを追加する必要があります。1 つは作業を分割し、それをグリッドに渡すコンポーネントです。もう 1 つは、結果を集約するコンポーネントです。
- グリッド対応の部分がバッチ・ジョブの集合としてではなく「サービス」として実行されるように、アプリケーションをリエンジニアリングする (戦略 4)。
最終的にこれらの部分にさらにリエンジニアリングを加えれば、呼び出しが可能で、複数を並列実行できる、ステートフルなバックエンド・サービスとして実行できるようになります。
一般に、戦略 6 を既存のアプリケーションで達成することは不可能です。リエンジニアリングのコストがメリットよりも大きくなる場合が多いからです。最初から密結合並列プログラムの概念を取り入れた設計を使用して、やり直すことをおすすめします。
戦略 1: ノード非依存バッチ
 |
Key Messages
There are six strategies for grid application enablement that you can do in three stages (Run, Adapt, and Exploit).
- Not every application needs to implement the sixth strategy. Most can't.
- There is value in every strategy.
- You don't have to implement the target strategy in one leap.
Your business application component runs in the grid's nodes.
- It might not need to be aware of grid middleware.
- It might need to be changed very little, if at all.
- It can take advantage of the grid middleware.
- The grid's nodes can be salvaged (scavenged) client or server machines that offer resources only when otherwise idle.
Focus on the application.
- Separate the application from its integration and deployment.
- Isolate code that is specific to the middleware.
- Let the integration and deployment teams perform the middleware-specific work on their choice of any of several grid middleware bases.
Client applications that exercise your business component do exercise the grid middleware.
Applications can, could, and should grow or change to better exploit the grid.
|
|
図 3 は、ジョブに使用するノードを決定するのは (アプリケーション、クライアント、ユーザーなどではなく) グリッドであるということを示しています。また、この図は、ジョブの実行依頼を出すマシンがグリッド内のノードとは限らないことも示しています。アプリケーションの例として、任意の数 x が素数であるかどうかを調べるクエリーを考えてみます。グリッド内の複数のノードが、同じクエリーの実行依頼を出すことができます。グリッドがサブミッターに正しい結果を返します。
図3. 戦略 1: ノード非依存バッチ
この戦略の目標は、実行時のグリッド・ミドルウェアの選択に応じて、グリッド内に多数存在するノードのほぼすべてから、アプリケーションのインスタンスを実行できるようにすることです。ミドルウェアは、次回の実行時には別のノードを選択するかもしれません。この戦略では、このノードと他のノードが別のアプリケーションを並行して実行している場合以外、並行処理の局面は発生しません。
「戦略 1: ノード非依存バッチ」の主な特性は次のとおりです。
- 場所に依存せず、ジョブの単一インスタンスが複数ノードのうちの任意の 1 つで実行される。
- LAN および WAN の入出力ボリューム、タイミング、パフォーマンスが許容範囲内にある。
- プロビジョニングの負荷が適度である。
- ライセンス交付の負荷が適度である。
- セキュリティー・レベルが妥当である。
- 開始時間が許容範囲内にある。
- カレンダー、前提ジョブ、またはファイルの到着に応じて、スケジューリングが行われる。
「許容範囲である」、「負荷が適度である」、「妥当である」とは、どのようなことを指しているのでしょうか。これらの用語については、『アプリケーションのグリッド化に関する 6 つの戦略 : 「戦略 1: ノード非依存バッチ」と「戦略 2: 独立並行バッチ」』でさらに詳しく説明します。
戦略 2: 独立並行バッチ
アプリケーションをグリッド化するための戦略 2 は、並行して動作する同一アプリケーションの、複数の独立インスタンスをサポートします。最初の戦略の主な特性に加えて、「戦略 2: 独立並行バッチ」には次の特性があります。
- 複数のインスタンスが相互に干渉せず、独立して動作する。
- 独立ジョブが一般的に行われる。例えば、アカウント A のジョブ X を、アカウント B のジョブ X と並行して実行できます。
- データベースおよびその他の資源にホット・スポットやデッドロックがない。
戦略 2 では、同一ジョブ、例えば分析 A を、複数回並列して独立実行することができます。つまり、John が自分のデータを分析 A のインスタンスとして実行しているときに、Jane が自分のデータを分析 A の別インスタンスとして実行する、ということも可能です。この並行性は最初の戦略からかけ離れたものではありません。これを実現するには、ある程度の労力が必要になることもありますが、新たな利点もいくつか得られます。これについては、記事『アプリケーションのグリッド化に関する 6 つの戦略 : 「戦略 1: ノード非依存バッチ」と「戦略 2: 独立並行バッチ」』でさらに詳しく説明します。
「戦略 2: 独立並行バッチ」の主な特性には、次のものもあります。
- アプリケーションの目的の達成に十分な並行性を確保できる可能性がある。
- この並列処理の戦略で十分であり、それ以上の分割を必要としない。
図 4 は、グリッド内で実行されているアプリケーションのインスタンスを示しています。
図4. 戦略 2: 独立並行バッチ
戦略 3: 並列バッチ
「戦略 3: 並列バッチ」では、各ユーザーのバッチ処理を受け取り、それを分割して複数のノードに分散し、回収して結果を集約します。
「戦略 3: 並列バッチ」では、「クライアント」および「サーバー」という用語が出てきます。これらの用語は、最初の 2 つの戦略でのバッチ・ジョブには適用されません。最初の 2 つの戦略で取り扱うのは単一の独立並行インスタンスであり、「クライアント」に最も近い概念は、ジョブを実行依頼するリクエスター・ノードです。このノードは、Tivoli Workload Scheduler や Platform JobScheduler (『参考文献』のリンク参照) などのスケジューラーに作業の実行依頼を出します。スケジューラーは、ジョブをプロバイダー・ノード上で実行するために、グリッド・ミドルウェアに実行依頼を出します。「戦略 3: 並列バッチ」ではクライアントがリクエスターであり、作業を分割して実行依頼を出して、後で結果を集約します。戦略 3 には、サブミッターとは異なるプログラムがジョブの結果を集約できるという、新しい特性があります。
「戦略 3: 並列バッチ」の主な特性は次のとおりです。
- 並列サポートにより、作業がノード間で分割、分散される。
- プログラム機能を、1 台のクライアントと複数のサーバーのジョブに分割できる。
- クライアントは、作業を小さなサーバー・ジョブに分けて分散処理できる。
- 上述のように、サーバー・ジョブは複数の独立インスタンスとして動作する。
- クライアントは、中間結果を収集した後で、最終的な結果を取りまとめることができる。
図 5 は、ノード間でのサブジョブの分割を示しています。
図5. 戦略 3:並列バッチ
戦略 4: サービス
戦略 4、戦略5、および戦略 6 では、バッチを離れて、グリッド上のサービスを使用するジョブ処理について取り上げます。「戦略 4: サービス」では、バッチからサービス指向アーキテクチャーへの遷移に焦点を当てます。「戦略 4: サービス」は、「戦略 3: 並列バッチ」ではなく、「戦略 2: 独立並行バッチ」に続くものです。「戦略 4: サービス」では、クライアントが作業を分割して複数のサービス・インスタンスに分散させることは想定していません。
「戦略 4: サービス」の主な特性は次のとおりです。
- クライアントは、グリッド・ミドルウェアを使用してサービスを呼び出す。
- クライアントの代わりに、グリッド・ミドルウェアがサービスを呼び出す。サービスは呼び出し可能で、通常はクラス、サブルーチン・ライブラリー、DLL として構造化されます。
- クライアントとサーバーの間は疎結合である。
- サービスは独立したクライアント間で共有されることがある。
- サービスはその状態を呼び出し間で維持できる。
- サービスの実行時間が長く、1 回の実行で何度も使用され、かつ初回使用の前に開始できる場合は、サービス起動時間の長さは問題にならない。
図 6 は、「戦略 4: サービス」でサービスを呼び出すクライアントを示しています。
図6. 戦略 4: サービス
戦略 5: 並列サービス
戦略 5 は、「戦略 4: サービス」のサービス指向アーキテクチャーを、「戦略 3: 並列バッチ」の分割作業モデルと組み合わせたものです。
「戦略 5: 並列サービス」の主な特性は次のとおりです。
- 複数のサービス・インスタンスが提供される。
- 提供されたインスタンスを、クライアントに代わって並列して呼び出すことができる。
図 7 は、複数のサービス・インスタンスの並列呼び出しを示しています。
図7. 戦略 5: 並列サービス
戦略 6: 密結合並列プログラム
「戦略 6: 密結合並列プログラム」は、工学、物理学、生物学のモデル化 (有限状態解析など) で使用される特殊なアプリケーションを対象としています。
「戦略 6: 密結合並列プログラム」の主な特性は、以下の間で膨大な通信と同期が行われることです。
この特性は、IBM Redbook「RS/6000 SP: Practical MPI Programming」(『参考文献』のリンク参照) で詳しく説明されています。
「戦略 6: 密結合並列プログラム」の新たな潜在的利点としては、主に次のものがあげられます。
- より高速に結果が得られる。
- 1 つのノードでは対応できないアプリケーションや 10 年かかっても処理を完了できないようなアプリケーションをサポートできる。
図 8 は、戦略 6 におけるアプリケーションのインタラクティブ性と、その密結合の仕組みを示しています。
図8. 戦略 6: 密結合並列プログラム
アプリケーションのグリッド化のための 6 つの戦略が存在する理由
「戦略 1: ノード非依存バッチ」と「戦略 2: 独立並行バッチ」は、統合できるように思われるかもしれませんが、この 2 つを区別するのには、次の 2 つの理由があります。
-
利点 : 多くのビジネス・ケースでは、戦略 1 で時間内に作業が終了しなくても、戦略 2 では終了します。そのため、「戦略 3: 並列バッチ」を利用する必要がありません。例えば医療保険会社が多くの医療機関の処理を行う場合、病院ごとの処理が独立していれば、戦略 2 で並行性を実現し、ノード資源を効率的に利用することができます。この並行性により、各病院の場所や患者のレベルでは、並列化は不要になります。
-
労力 : 多くの場合、特にライセンス・ソフトウェアの場合は、戦略 1 から戦略 2 への移行にかなりの労力が必要となります。
一方、「戦略 6: 密結合並列プログラム」は技術的に 2 つの戦略に分けることが可能です。1 つは密結合した並列バッチの膨大な通信を処理するための戦略、もう 1 つはそれをサービスとして処理するための戦略です。ただし、この 2 つの戦略の問題は、バッチ・プログラムをサービスに変更する部分以外は非常に似ており、相違点についても「戦略 4: サービス」または「戦略 5: 並列サービス」で既に対応済みです。このことは、原子物理学の正式な「標準モデル」(『参考文献』のリンク参照) のように、あらゆる粒子タイプが他の粒子タイプと対応しているという意味ではありません。単にグリッドを使用するという意味です。
まとめ
アプリケーションのグリッド化には、3 つのステージ (実行、適合、活用) に分かれた 6 つの戦略があります。
すべてのアプリケーションに戦略 6 を実装する必要はありません。大部分のアプリケーションでは、戦略 6 の実装は不可能です。
どの戦略にも利点があります。
ターゲットとなる戦略を一括して実装する必要はありません。
ビジネス・アプリケーションのコンポーネントは、グリッドのノードで実行されます。
グリッド・ミドルウェアを意識しなくてもよい場合もあります。
変更はほとんど必要ないか、あってもごくわずかです。
グリッド・ミドルウェアを利用できます。
グリッドのノードには、アイドル状態のときにのみ資源を提供する、サルベージ (スカベンジ) したクライアントまたはサーバー・マシンを利用できます。
アプリケーションに焦点を当てます。
アプリケーションを統合および配備から切り離します。
ミドルウェア固有のコードを分離します。
統合化と配備を担当するチームは、ミドルウェア固有の作業を、チームが任意に選んだ複数のグリッド・ミドルウェアのベース上で実行します。
ビジネス・コンポーネントを動かすクライアント・アプリケーションは、グリッド・ミドルウェアをも動かします。
グリッドより活用するために、アプリケーションを任意に変更したり拡張したりできます。必要に応じて、変更または拡張を行ってください。
参考文献
著者について | 
| | David Kra is an executive IT architect in IBM's Grid Computing organization. David has spent his 27-year IBM career guiding customers' distributed computing projects from the application layer down to cabling and from requirements through deployment. His scalable, high-volume, and high-availability communicating solutions have involved several non-IBM platforms and almost every IBM platform since the 1970s. He is a member of the IBM Academy of Technology. |
記事の評価
| 
