レベル: 中級 David Kra (dakra@us.ibm.com), Executive IT Architect, IBM
2004年 06月 08日 シリーズのパート 4 (最終回) に該当するこの記事では、アプリケーションのグリッド化に関する 6 つの戦略のうち、5 番目と 6 番目について説明します。このレベルでは、プログラムはサービス・サブルーチンの複数のインスタンスとして処理されます。クライアントは、いずれかのグリッド・ミドルウェアを通じて、これらのサブ・ルーチンを並列に呼び出すことができます。この記事では、このレベルにおけるアプリケーションの特性と、このレベルを達成して活用するためにプログラム開発者が実施すべき必須事項、推奨事項、およびオプションについて説明しています。主な目的は、アプリケーションができるだけミドルウェアを意識せずに済むようにすることです。
はじめに
シリーズの最初の記事『アプリケーションのグリッド化に関する 6 つの戦略、パート 1: 概要』 (『参考文献』のリンク参照) では、6 つの戦略に関するシリーズの概要を述べ、各戦略の特性と利点をまとめています。
2 番目の記事『アプリケーションのグリッド化に関する 6 つの戦略、パート 2: 「戦略 1: ノード非依存バッチ」と「戦略 2: 独立並行バッチ」』 (『参考文献』のリンク参照) では、この 2 つの戦略を使用してアプリケーションをグリッド化するための方法について説明しています。最初の戦略では、アプリケーションをグリッド内の任意のコンピューター上で単一ジョブとして実行できるようにします。2 番目の戦略では、アプリケーションの複数の独立インスタンスを並行して実行できるようにします。
3 番目の記事『アプリケーションのグリッド化に関する 6 つの戦略、パート 3: 「戦略 3: 並列バッチ」と「戦略 4: サービス」』 (『参考文献』のリンク参照) では、相互に排他的なこの 2 つの戦略を使用してアプリケーションをグリッド化するための方法について説明しています。「戦略 3: 並列バッチ」では、バッチ処理をグリッド・ノードに送信するためにサブジョブに分割し、後で部分的な結果を集約します。「戦略 4: サービス」は、バッチからサービス指向アーキテクチャーに移行するステップです。
アプリケーションをグリッド化する場合、必ずしも最後の 2 つの戦略まで到達する必要はありません。戦略 5 は、アプリケーションが複数のサービス・インスタンスを同時に必要とする場合にのみ、実装してください。また、既存のほとんどのプログラムでは、戦略 6 を使用する必要はなく、使用することもできません。この戦略は膨大な密結合並列処理を必要とするので、最初からそれに合わせて設計されている特殊なプログラムを対象としています。グリッド化に関するこの記事シリーズでは、パート 1 で概略を述べる以外は、戦略 6 に関する情報は取り上げません。戦略 6 に該当するアプリケーションの設計方法については、IBM Redbook、「RS/6000 SP: Practical MPI Programming」 (『参考文献』のリンク参照) を参照してください。6 つの戦略の関係については、図 1 を参照してください。
図1. 6 つの戦略の説明図
戦略 5: 並列サービス
「戦略 5: 並列サービス」がこれまでの戦略と大きく異なるのは、戦略 5 では、あるサービスの多数のインスタンスを一度に有効にして、各クライアントによって並列的に活用されるようにできる点です。戦略 5 は、ジョブの作業をサブジョブに分割する「戦略 3: 並列バッチ」の概念を、サービスに置き換えたものです。戦略 5 では、サービス要求がクライアントによって分割され、グリッド・ミドルウェアによってサービス・インスタンスに割り当てられます。戦略 5 の説明図については、図 2 を参照してください。
図2. 戦略 5 の説明図
戦略 5 の特性は次のとおりです。
- クライアントの各インスタンスが、複数のサービス・インスタンスを並列して活用する。
- サービス・インスタンスは相互に通信しない。これは、戦略 3 の、分割したバッチをベースにした「極めて並列な」パラダイムと同じです。
- サービス要求のレートはまだ中程度である。クライアント・プログラムはサーバーと疎結合しています。
「戦略 5: 並列サービス」は、「戦略 3: 並列バッチ」と「戦略 4: サービス」によるグリッド化を意味します。戦略 5 ではサービス・インスタンスである点が異なるものの、戦略 3 と同じように分割された作業を、戦略 4 の方式で並列して処理します。
「戦略 5: 並列サービス」を使用したグリッド化の利点
このように戦略 3 と 4 を結合すると、利点も複合して得られます。最初のサービス要求は通常は例外ですが、サービスを事前に初期化して並列処理を行うと、応答時間が短縮されます。また、グリッドによる並列サービスには、クライアントが次のような新しい方法でサービスを活用できるという大きな利点があります。
状態ベースの並列処理
「戦略 3: 並列バッチ」の「極めて並列的」な技法は、パラメーター以外は同一の同じサブジョブのインスタンスに、異なるパラメーターを渡すことに基づいています。この方法は、「パラメトリック並列処理」と呼ばれることもあります。「戦略 5: 並列サービス」では、パラメーターではなく状態に基づいた、新しい種類の並列処理が実現します。通常、状態に基づいた並列処理では、サービス・インスタンスはそれぞれ異なる状態または情報を持っています。
マルチキャスト
マルチキャストでは、クライアントは同じパラメーターを使ってすべてのサーバー・インスタンスを呼び出し、そのインスタンスを、各サーバーが既に持っている状態と情報に基づいて処理します。その後、サーバーは状態を変更し、適切な結果を送り返します。
数値論の分野で、素数を探す例を考えてみましょう。サーバー・サービスのインスタンスが 100 あり、各インスタンスがそれぞれの素数のリストを使用して、受け取った数値が割り切れるかどうかを調べるとします。最初のサービス・インスタンスは 1 から 1,000,000 までのすべての素数のリストを持っています。2 番目のサービス・インスタンスは 1,000,001 から 2,000,000 までのすべての素数のリストを持っています。以降、この要領で、インスタンスがリストを持つとします。100 のインスタンスのすべてに、ある大きな数値を一斉送信 (「マルチキャスト」) すると、1 つのインスタンスがすべての処理を行う場合のおよそ百分の一の時間で、100,000,000 未満の素数で割り切れるかどうかを調べることができます。
「およそ」として断言を避けるのには、いくつかの理由があります。まず、要求を処理するたびに各サービス・インスタンスが素数のリストをロードしたり、計算したりする必要がないので、作業に要する時間は「戦略 3: 並列バッチ」の場合よりも短縮されます。その一方、グリッド・ミドルウェアはサービス要求を 100 のサービス・インスタンスに分散するので、1 つのサービス・インスタンスにのみサービス要求を送る場合よりも、処理時間はわずかに長くなります。
ケース・スタディー : 戦略 5
戦略 5 のケース・スタディーは、ある数値が素数であるかどうかを判断するアプリケーションです。リスト 1 は、Primality (素数判定) サービスが提供する関数です。
リスト 1. Primality サービスが提供する関数
:
boolean TestRelativelyPrime (long n)
/* Report whether n is prime relative to whatever primes the
service instance is responsible for */
instanceID TakeResponsibility(long low, long high)
/* Take responsibility for knowing which numbers in the range
{ low .. high } are prime */
/* result is the instanceID of the service which has taken this responsibility */
boolean DropResponsibility(long low, long high)
/* Drop responsibility for knowing which numbers in the range
{ low .. high } are prime */
long [ ] [ ] ReportResponsibility()
/* Report the ranges in which the service instance is responsible for knowing
which numbers are prime */
/* result is 2 column array
low 1 high 1
low 2 high 2
low 3 high 3
low n high n
*/
|
注:グリッド・ミドルウェア製品がマルチキャスト、イーチキャスト、エニーキャスト、ユニキャストのすべてを提供するとは限りません。
新たなサービス使用モデル
前述の数値論の例では、同じパラメーターがすべてのサーバーに一度にマルチキャストされていました。ただし戦略 5 には、「イーチキャスト」、「エニーキャスト」、「ユニキャスト」の 3 つの起動モデルが新たに用意されています。
-
イーチキャスト : 「イーチキャスト」とは、クライアントがグリッド・ミドルウェアを通じて、通常は内容の異なる特定のパラメーターのセットを、各サービス・インスタンスに送信できることを意味します。マルチキャストの例では、この技法で 100 のサービス・インスタンスのそれぞれにその「担当」を通知しています。クライアントは 100 セットのパラメーター { {1, 1000000}, {1000001, 2000000}, {2000001, 3000000}, ...{99000001, 100000000}, } を持つ配列を作成しました。その後、グリッド・ミドルウェアを通じて、それらのパラメーターを Primality サービス・インスタンスの TakeResponsibility メソッドにイーチキャストします。(リスト 1 はこの部分と、Primality サービスが提供するその他の機能を示しています。)
-
エニーキャスト : 「エニーキャスト」とは、クライアントがグリッド・ミドルウェアを通じて、大量のサービス要求を、少数のサービス・インスタンスの間に配布できることを意味します。この技法は、すべてのサービス・マシンが等しく高速とは限らない場合に特に有用です。この例のクライアントが、1,000,000,000 までの間の数値が互いに素であるかどうかをチェックするように、サービスに求めるとします。クライアントは広がった数値範囲を 100 に等分し、再度イーチキャストを行って、各インスタンスに新たな処理の担当を等しく割り当てることもできます。しかし、マシンが等しく高速で、サービスに占有できると考えるのは危険です。そのため、クライアントは範囲を 900 セットのパラメーターに分け、グリッド・ミドルウェアにエニーキャストさせて、TakeResponsibility を呼び出します。処理能力の高いノードは、TakeResponsibility コールを短時間で完了すると、次のパラメーター・セットを与えられます。
ここでは、TakeResponsibility は、自動的な DropResponsibility を暗黙指定しないと想定しています。TakeResponsibility の実行のたびにインスタンスが事前に担当した数値範囲を元に実行されるので、そのインスタンスは他の範囲の素数を担当できます。
エニーキャストを処理するとき、グリッド・ミドルウェアはサービス・インスタンスの処理と同じくらい速く、呼び出しを配布します。高速なマシン上の Primality サービスは、新しく割り当てられた範囲の素数を、低速なマシンより短時間で計算します。このインスタンスには、まだ割り当てられていない別の数値の範囲が担当として割り当てられます。これは、すべての範囲が処理されるまで続きます。
-
ユニキャスト : これまでの説明では、クライアントは多くのサーバー・サービス・インスタンスにアクセスするだけでなく、インスタンスの使用時に常にすべてのインスタンスを使用していました。「ユニキャスト」では、クライアントは特定の 1 つのサービス・インスタンスに要求を送ることができます。この素数判定の例では、1,000,000,000 未満の数値を調べる作業は、クライアントによって、その数値の存在範囲を担当する特定のサービス・インスタンスに送られます。
74,000,001 から 75,000,000 までの範囲の素数を、サービス・インスタンス 75 が担当するとしましょう。74,654,321 が素数であるかどうかを調べるために、クライアントは 74,654,321 を Primality インスタンス 75 の TestRelativelyPrime メソッドにユニキャストします。インスタンス 75 は、以前計算した素数のリストに 74,654,321 があるかどうかを調べるだけで済みます。
ある範囲を担当しているサービス・インスタンスを、しかも、900 の TakeResponsibility の呼び出しを 100 のサービス・インスタンスにエニーキャストした後で、クライアントはどのように知ることができたのでしょうか。答えは、グリッド・ミドルウェアとその使用方法によって異なります。TakeResponsibility メソッドから返される結果がそのインスタンス ID であるから、というのも 1 つの可能性です。ほかにも、そのサービスが ReportResponsibilities メソッドを持っていて、クライアントがすべてのサービス・インスタンスにマルチキャストしてそれを呼び出した、ということも考えられます。
戦略 5 におけるサーバーのフォーカス
「戦略 5: 並列サービス」は、並列とサービスの戦略が結合したものです。したがって、技術的な「必須事項」と大部分の「推奨事項」および「オプション事項」については、これまでの記事で既に説明されています。ただし、前述の素数判定の例のように、戦略 5 には、非常に有用な新しい利点があります。これにより、自分のプログラムを改善して、さらに優れたものにすることができます。
これまでの提案に加えて、初期化と終了など、検討したい新しい項目もいくつかあります。
多くのサービス・インスタンスでは、初期化は 1 人のユーザーのために実行されることがほとんどで、並行して行われる可能性はあるものの、同時に行われることは通常ありません。よりローレベルな資源にプログラムがアクセスするときは、この可能性を考慮してください。前述の干渉、ロック、ホット・スポット、およびデッドロックの問題のほかに、よりローレベルな資源のキャッシングの有無によって、他のインスタンスの起動にプラスまたはマイナスの影響が出る可能性があることを念頭に置いてください。
各インスタンスが初期化情報を取得する場合、1 つの大きい (自己中心的な) 資源要求を使用するのと、100 の小さい (気配りして共有する) 資源要求を使用するのとでは、どちらがよいのでしょうか。これは状況に応じて異なります。ある状況において単一のインスタンスを最短時間で初期化できたとしても、同じ状況で 100 のインスタンスすべてを最短時間で初期化できるとは限りません。単一のインスタンスの場合のみを想定するのではなく、一般的な場合や最悪の場合に合わせて、最適な選択をしてください。
2 種類のクライアント
特に、寿命が長く、多くのクライアントによって使用されるサービスの場合は、「ユーザー」クライアントと「管理」クライアントの 2 種類を持つことがあります。クライアントの各カテゴリーには、サービスの機能の一部を使用する権限が割り当てられています。ケース・スタディーでは、ユーザー・クライアントは TestRelativelyPrime 関数と ReportResponsibility 関数を使用します。管理クライアントは、TakeResponsibility 関数と DropResponsibility 関数を使用します。ユーザーには、TakeResponsibility 関数を使用する権限が与えられている場合と、そうでない場合とがあります。その理由は、ユーザーはなんらかの機能的な目的を持ってサービスを使用しますが、管理者はサービスの起動と制御を行っているからです。
サンプルのクライアント定義とインターフェース定義の提供
サンプルのクライアント・プログラムを用意するときは、サービス、クライアント、およびミドルウェア配備を何パターンか検討する必要があります。グリッド・ミドルウェアによって提供されるサービス呼び出しパラダイムが、ユニキャスト、マルチキャスト、イーチキャスト、エニーキャストに限定される場合もあります。極端な例としては、サービスが 1 つのインスタンスでのみ実行されたり、ユニキャストしかサポートしないミドルウェアで実行されたりすることも考えられます。さらに、数千ものクライアント・インスタンスが存在し、各クライアントが 1 つ、複数、またはすべてのサーバー・サービス・インスタンスを使用する場合も想定できます。
戦略 5 は並列サービスに重点を置いていますが、マルチキャスト、イーチキャスト、エニーキャストとは無縁の、1 つのサービス・インスタンスでのみ動作する低性能サンプルを用意することをおすすめします。また、並列サービスの使用方法と、複数のクライアント・ユーザーの使用方法を示すサンプルも用意してください。
「戦略 5: 並列サービス」の要約
サーバー・アプリケーション・コードを並列サービスとしてグリッド化する作業は、わずかな追加設定で実現できます。
- 初期化と終了 : 全部のインスタンスで発生することはまずないが、多くのインスタンスが並行して起動および停止することが予想される。
- クライアントのサンプル : さまざまな状況を想定した単純なサンプルを用意する。
図3. グリッド環境におけるクライアントとサーバー
結論
6 つの戦略は次のようにまとめられます。
| 戦略 1 | ノード非依存バッチ アプリケーションを、グリッド内の任意のコンピューター上で単一ジョブとして実行できます。. | | 戦略 2 | 独立並行バッチ アプリケーションの複数の独立インスタンスを、並行して実行できます。 | | 戦略 3 | 並行バッチ バッチ・プログラムの作業が分割され、複数の独立したプログラム・インスタンスがジョブの一部を個別に並列処理できるようになります。 | | 戦略 4 | サービス プログラムは、グリッド・ミドルウェア経由でクライアントから呼び出せる、サービス・サブルーチンとして設定されます。 | | 戦略 5 | 並列サービス プログラムは、グリッド・ミドルウェア経由でクライアントから並行して呼び出せる、複数のインスタンスとして設定されます。 | | 戦略 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. |
記事の評価
| 
