レベル: 初級 John Easton (JKJ@uk.ibm.com), Senior Software Engineer, IBM Global Services
2004年 12月 14日 今回のシリーズでは、地理的に離れた多数のサイトにまたがってグリッドを実装する場合の、パフォーマンス上の課題を調べてきました。この記事はその仕上げにあたります。
第 1 部では、「グリッド・コンピューティング環境で計算を実行する際には、どのような処理に時間がかかるか」という課題を取り上げ、「ジョブを並列に実行しても、計算時間の短縮に限界があるのはなぜか」について検討しました。これを理解することにより、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントをグリッド・ノード上に最適に配置しようとする際に直面する課題を研究するための土台ができたと言えます。
第 2 部では、使用されている一般的なグリッド・ソリューションのうち、この課題にコンピューティングの面から対処しているものと、データの面から対処しているものを、それぞれ紹介しました。また、それぞれの長所と短所のほか、同一グリッド内で複数の製品を併用するとどうなるかについても簡単に説明しました。
第 3 部では、さまざまなグリッド・ミドルウェア・ソリューションを 1 つのグリッド内に混在させると、同一ノード上にコンピューティング・コンポーネントとデータ・コンポーネントが異なる意思決定に基づいて配置され、問題を引き起こす可能性がある、ということを学習しました。また、ポリシー・ルール、ワークフロー、メタスケジューラーといった取り組むべき今後の課題についても取り上げました。
この最後の記事では、すべての学習ポイントを取りまとめ、実際のお客様事例をある程度深く掘り下げます。さらに、この問題を解決するために導入された新たなデータ分散メカニズムについて見ていきます。
拡張メタスケジューラー
第 3 部では、5 か国にまたがってグリッドを実装した組織の事例を取り上げました。このグリッドには各地域のサイトごとに 1 つ、つまり事実上複数のワークロード実行依頼システムがあります。これらのシステムは、以下のように機能します。
- 実行すべきワークロードの詳細情報を取得する
- スケジューラーに配置の決定を行わせる
- 指定されたシステムに宛てて、必要なファイルとデータをネットワーク経由で転送する
ワークロードの実行のための初期化と、その出力を特定の受信システムへ送信するための初期化を行う。
各実行依頼システム上では Web ポータルが実行されており、ユーザーはこれを通じて、スケジューラーと対話したり、ワークロードのスケジューリングを要求したりすることができます。スケジューリング・アプリケーション用の情報は、スケジューラー・デーモンが提供します。最終的には、監視デーモンがグリッドとネットワークの調査を制御し、パフォーマンスとキャパシティーに関する最新データを入手します。ローカルのパフォーマンスをユーザーに提供するために、ポータルは組織全体に 1 つ実装するのではなく、サイトごとに 1 つ実装します。
1 つのロケーションで同時にアクティブになるのは、1 つのスケジューラー・デーモンと、それに関連付けられた監視デーモンだけです。これらのデーモン以外のインスタンスもアクティブになりますが、あくまでもバックアップ用であり、最新のデータがロードされることはありません。主となるスケジューラー・デーモンや監視デーモンが停止するか、通信できなくなると、バックアップ用のデーモンに切り替わります。スケジューラー・デーモンは、ネットワークで接続された複数のロケーションにワークロードを分散します。ときには、データや実行可能ファイルを十分なキャパシティーで効率的に処理できるように、大容量のデータをネットワーク上で移動させなければなりません。グリッド・ロケーションのネットワークに関する記述、グリッド・ロケーションの使用状況に関するリアルタイム情報、およびネットワークを経由してグリッドに配置するワークロードをスケジューラーに与えると、ワークロードを実行するための最適なグリッド・ノードが、サイズ/ロケーション/ユーザーなどの情報に関するスケジューラーの情報に基づいて、スケジューラーから推奨されます。これを図 1 に示します。
図1. 拡張メタスケジューラーのコンポーネント
このグリッド環境は比較的単純で、考慮すべきビジネス・ルールは 20 もありません。しかし、時間の経過とともに資源やルールが定義され、グリッドはより複雑化していきます。あらゆる状況に対する応答を複雑な環境で逐一コーディングするのは、いくつかの理由から現実的ではありません。まず、新しい動作を常に設計/コーディングしなければならないため、「特殊な場合の条件」が複雑に入り込んでしまいます。また、このような集中型のプランニングと管理には、将来のニーズに対応できる拡張性がありません。核となるルール・セットを使用するシンプルなソリューションをメタスケジューラーにコーディングすることも可能ですが、実際の現場への実装は限られます。
ルール・エンジンのパワー
ルール・エンジンは創発的な手法を用いて決定を行い、システムの全般的な動作を生成します。私たちは幸いにもルール・エンジンを利用することができました。表に出てくる動作とその根底にあるメカニズムとの因果関係がまったくないように見えるという点において、ルール・エンジンは創発的だと言えます。この動作は、それぞれが単純なルール・セットを適用した、システム内の個々のエンティティーとの対話を通じて生成されます。つまり、これらのエンティティーは「自分で考える」のです。私たちは、相関的な創発モデル、つまり、オブジェクトをリレーションシップで結びつけてグラフを形成するモデルを選択しました。直接の相互接続を持つオブジェクトは隣接オブジェクトです。オブジェクト対話用のシンプルなルールを定義しておけば、これらの隣接オブジェクトは、実行時に複雑なシステム動作を実現します。このような強い局所性により、各オブジェクトはその直近の隣接オブジェクトとしか対話しません。また、オブジェクトを増やしても、ほとんどのトランザクションの実行時間には大きな影響はありません。扱う資源の数が 100 であれ 10 万であれ、10 ミリ秒の決定応答時間を達成できます。グリッド内の計算ジョブの実行時間が一般的な値であれば、この経過時間は微々たるものです。ほとんどの変更は、エンジン自体ではなくルールにのみ影響します。したがって、小さなオブジェクト・エンジンと動作ルールのセットを実装すれば、システムの保守性が大幅に向上します。
基本的な配置アルゴリズムは、対象となる各ロケーションの重み値に依存します。これは、そのジョブを実行する可能性のあるノードごとに重み値を計算することを意味します。配置アルゴリズムはしきい値を参照します。重み値を持つノードのうち、このしきい値を超えるものはすべてそのジョブを実行できることになります。つまり、ノード D3 の重み値が 500、ノード D4 の重み値が 495、ノード B3 の重み値が 0 である場合、しきい値を 500 に設定すれば、D3 だけがそれを実行します。D3 が失敗した場合は、しきい値を 495 に下げれば、D4 が実行を開始します。B3 は最後まで重み値が 0 という特殊ケースであったため、ジョブを実行することはありません。固定の配置アルゴリズムを使用して最も重み値の高いノードを選択する場合は、重み値の計算が必要になります。デフォルトのシステムには、資源に基づいて重み値を計算するための固定ルールが多数用意されています。また、カスタム定義のルールを利用することもできます。適切な重み値を設定すれば固定ルールとユーザー定義ルールの間でバランスをとって定義できます。従って、コスト、応答時間、ネットワーク・データ転送といったビジネス関連指標に基づいて各種のデフォルト要素を重み付けできるようになります。
ルール・エンジンに対するユーザー・インターフェース
スケジューラーに対するユーザー・インターフェースは、グリッド・オブジェクトを定義するキーワード・ベースのエントリーが記述された、単純なテキスト・ファイルです。私たちが定義したオブジェクトは以下の通りです。
-
Grid: 作業が実行される場所を表すオブジェクト。Grid は資源を提供しますが、この場合の「資源」とは、「あるサイト上のすべてのコンピューター」と同義です。
-
Portal、User: ネットワークへの接続ポイント (データの出発点と到着点) を表すオブジェクト。これらのオブジェクトには他の属性はありません。
-
Link: Grid、Portal、User の間の接続を表す、ネットワークを記述するオブジェクト。Link は双方向で、起点と終点があり、「最大のキャパシティー」を備えていると仮定されます。「最大のキャパシティー」とは理論上の最大値であり、「実際のキャパシティー」とは監視デーモンからの入力に基づく値です。
-
SAN: 複数の Grid を共通のストレージ・プールに接続する、ストレージ・エリア・ネットワークを表すオブジェクト。
-
SR: 特殊資源 (アプリケーションやライセンスなど) と、それを入手できるロケーションとを定義するオブジェクト。SR の名前は、Family 定義の Proximity ステートメントで指定された名前と一致している必要があります。ロケーションとしては Grid、User、Portal のいずれもが可能で、そのロケーションにできるだけ近づくように、配置が偏移されます。
-
Family: 要件と制限を共有するワークロードのグループを定義するオブジェクト。これらは、Grid のProvides タグに対応する Family の Requires 属性と、特殊資源 (SR) に対応する Proximity 属性を通じて実装されます。後者は、Grid 記述の一部またはワークロード・プロファイルの一部として定義されるものです。Provides タグには、他のパラメーター (前述の重み値やしきい値など) もあります。Requires ステートメントは、指名された資源を最も高いレベルで提供できるグリッドに向かって、配置を偏移させます。Proximity ステートメントは、特殊資源を持っていないグリッドや、特殊資源を提供するユーザー/ポータルに隣接していないグリッドにワークロードがスケジューリングされるのを防ぎます。
以下に示す例は、1 つのネットワークで 2 つのロケーションを結合しているグリッドのための、簡単なユーザー・ポリシー構成ファイルです。
ユーザー・ポリシー構成ファイルの例
# Gridの定義
GRID A
Provides app1 100
Provides app2 100
Provides location/ASIA 100
GRID B
Provides app1 100
Provides app3 100
Provides location/EUROPE 100
# Linkの定義
LINK GRID/A GRID/B 400 400
# Familyの定義
FAMILY one
Requires app1
FAMILY two
Requires app1
Requires app3
FAMILY three
Requires app3
Requires location/EUROPE
|
この例に記述されているのは、ユーザーによる大幅なカスタマイズが可能な、グリッド・ネットワークとワークロード・ファミリーに関する比較的シンプルな定義です。グリッドに割り当てられている重み値を変更すれば、ワークロードをいずれかの場所に偏移させることができます。この例では、重み値が同じなので、ワークロードはいずれかのロケーションに均等にディスパッチされます。FAMILY one のジョブはどのロケーションにもディスパッチ可能ですが、FAMILY two は app3 を必要とするため、Grid B にしかジョブをスケジューリングできません。これに加えて SR ルールを使用すると、アプリケーションのライセンスや特定のハードウェア・コンポーネント (ベクトル・プロセッサーなど) を表すこともできます。Proximity ステートメントを使用すれば、アプリケーションの動作をさらに微調整できます。
この記述ファイルによってグリッドの内部表現が作成され、ルール・エンジンの効率的な実行が可能になります。事前にコンパイルされたルールと、そのルールを使用するジョブ資源が、起動時にエンジンに読み込まれます。ジョブの実行依頼が出されたときや、グリッドのトポロジーが変わったときは、これらのルールが必ず評価されます。監視デーモンはグリッド内の各ロケーションを定期的にポーリングし、そのコンタクト可能性と稼働状況を確認します。そのため、変更が発生した場合、例えば、ノードやサイトで過負荷が発生したり、ユーザーがノードやサイトの重み値を変更した場合は、読み込まれたルールはすばやく再評価され、ワークロードの一部が再配布されます。ルールが追加されていくにつれて、ジョブに対する重み値の計算も複雑化していきます。必要に応じて事前評価を実行しておくと、すべてのジョブをあらゆるルールで評価する必要がなくなり、意思決定プロセスを改善できます。
ユーザーは、適切なサイトとノードを最終的に抽出できるように、重み値の最初の相対値を設定する必要があります。エンジンは、成功したジョブ配置決定の結果を使用して、次第に意思決定プロセスを改善していきます。ルール定義とエンジンの命令の間には、固定されたマッピングが存在します。例えば、when、then、else などのステートメントは相関関係になります。Setup ステートメントはトリガー設定アクションに分類されます。Imports ステートメントはリレーションシップによる相関関係になります。Calculate は 1 つまたは 2 つの相関関係になります。
最後に作成するのは、エンジンにトリガーとして存在する、独立したポリシー・セットです。job 属性の policy キーワードは、そのジョブにどのポリシーを使用するかを指定します。この指定は、ジョブ実行依頼時に行われます。ジョブにポリシーが指定されていない場合でも、グリッド内のロケーションごとにデフォルトのポリシーが用意されています。新しいポリシー・ルールはいつでも作成可能です。ユーザーは構成ファイルの編集、コンパイル、有効化を行います。構成ファイルが有効化されると、旧バージョンのポリシー構成ファイルを使用している既存ジョブに、新しいポリシー・ルールが自動的に適用されます。
拡張メタスケジューラーの実装結果
ルール・エンジンの効果を見てみましょう。ここでは、3 つのジョブで 3 つのアプリケーションを呼び出すことにより、ビジネス・ルールに応じてジョブ配置を決定することの効果をテストしました。この 3 つのサンプル・ジョブの主な相違点は、正しく機能するのに必要なデータ・セットのサイズです。データ・セットは製品開発ライフ・サイクルのさまざまな段階に対応しており、それぞれ 66 MB、121 MB、260 MB です。ジョブの実行依頼はグリッド内の各ロケーションから複数回行われ、ジョブ完了時間はすべて記録されました。わかりやすくするために、以下を合計したものをジョブ完了時間と見なします。
- 決定時間: ジョブやデータの計算をどこで実行するかを決定するのに要する時間
- データ転送時間: 入力データを、処理用ロケーションへ転送するのに要する時間
- 実行ファイル転送時間: 実行ファイルやその他の前提ファイルを、処理用ロケーションへ転送するのに要する時間
- 結果転送時間: 結果を処理用ロケーションから実行依頼ユーザーへ返送するのに要する時間
このグリッドには高レイテンシー、低帯域幅のネットワークが複数存在しているため、合計ジョブ完了時間は、主として実行可能ファイル、入力データ、結果データなどのデータ転送時間に左右されます。
図 2 のグラフに、3 つのサンプル用ジョブの合計ジョブ完了時間に対するルール・エンジンの効果を示します。
図2. 拡張メタスケジューラーを使用した場合の、データ・セットのサイズとジョブ完了時間の関係
凡例
■ ルール・エンジンを利用しなかった場合のジョブ完了時間
□ ルール・エンジンを利用した場合のジョブ完了時間
いずれのケースでも、ルール・エンジンの使用は完了時間の短縮につながっています。ルール・エンジンがアクティブな場合の最大ジョブ完了時間は、ほとんどのケースで、エンジンを無効にしたときの平均完了時間と同程度です。また、いずれのケースでも、「どこで計算が実行されるか」に応じてジョブ完了時間が変動しています。計算ロケーションが実行依頼者に近いほど、またそのリンクの帯域幅が広いほど、ジョブ完了時間が高速化していくのは当然です。どのサンプル用ジョブでも、ルール・エンジンを使用すれば、完了時間のばらつきが小さくなります。潜在的な処理用ロケーションの数を、他のジョブ実行依頼メカニズムよりも絞り込めるからです。この結果は、複数の国のサイトにまたがってグリッドを配置する際に考慮すべき重要な学習ポイントをいくつか明らかにしてくれました。
私たちは、物理的なルール (ファイル、ネットワーク、ユーザー属性など) に基づいた実装から、ビジネスの属性に焦点を当てた論理的なルールに基づいた、より複雑な配列の実装へと移行しました。ここで本当に難しいのは、「ルール・ファイルで表現できる形式」でルールを記述することです。
私たちは後日、製品開発の優先順位付けなどを含むルールをこのプロジェクトに追加しました。これは、一般向けの販売/出荷日に関連するものです。そのためには、生産スケジュールに照らした出荷日、システム・クロックから取得される実際の日付、出荷日が近づくにつれてそれぞれの重み値を修正するための方法などを、把握しておく必要があります。また、製品ファミリーの「実際の開発」を行っているユーザーを「研究」や「理論的な開発」を行っているユーザー (つまり特定の製品に結び付けることのできないユーザー) よりも優先させる、という優先順位付けルールもあります。そのほか、セキュリティーの指標を追加する機能や、新しいサイト、製品ファミリー、アプリケーションなどを追加する機能も追加しました。
まとめ
このシリーズの記事では、地理的に分散したグリッドにおいてコンピューティングとデータを整合させる場合の課題を見てきました。第 1 部 では、グリッド・コンピューティング環境で計算を実行する際にはどのような処理に時間がかかるのかを説明しました。第 2 部, では、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントを一般的なミドルウェア・ソリューションを使用して同一グリッド・ノード上に配置しようとする際の、課題について調べました。また、ミドルウェア・ソリューションの長所と短所のほか、同一グリッド内で複数の製品を併用するとどうなるかについても検討しました。第 3 部では、この課題の解決過程におけるデータ・サービスと、それに伴う課題について取り上げました。最後に、実際のお客様事例を掘り下げ、グリッド・インフラストラクチャーの新しいデータ分散メカニズムについて見ていきました。
この演習での重要な学習ポイントは、「コンピューティングとデータを最も効果的に整合させることは、極めて難しい」ということです。グリッドは、単一のサイト内や単一の LAN 上で実行したときは非常に効率的に機能します。しかし、別のサイト内のシステムと接続するようになると、ことは単純ではなくなります。ではなぜそれほど難しいのでしょうか。なぜなら、グリッド・ソリューションは LAN 中心の観点から開発されてきたためです。
IBM や各 ISV のグリッド・ミドルウェア・オファリングは、そのほとんどが何らかのオペレーション最適化機能を備えています。こういった製品では、それぞれ異なる情報を使用して意思決定が行われるのが一般的なため、結果が競合する可能性があります。このような競合を解決するには、さらに高いレベルの意思決定機能、すなわち、私たちがメタスケジューラーとして実装している機能が必要となります。私たちは、「データ・サービスは当初考えられていたような万能の解決策ではない」ということを理解しています。データ・サービスはこのような高レベルのエンティティーとしては機能できません。ユーザーが Web サービスに魅力を感じるのは「ロケーションの中立性」があるからですが、それこそが、データの移動を妨げる要因となっているのです。
メタスケジューラーはグリッド・ネットワークに関する知識に基づいてパフォーマンスを改善しますが、その真の利点は、IT 中心の単純なポリシー・ルールを超えたルールに従ってシステム管理を担当できるという点です。私たちの次なる大きな挑戦は、メタスケジューラーのルール・エンジンが理解できるような形式でこれらのビジネス・ルールを表現する方法を探すことなのです。
参考文献
-
Web services on developerWorks offers valuable information.
- The Open Grid Services Architecture Data Access and Integration project (OGSA-DAI) is concerned with constructing middleware to assist with access and integration of data from separate data sources via the grid.
- Download the IBM Grid Toolbox for an integrated tool kit to explore Web and data services in grid environments.
- A basic introduction to emergent behaviour
- "Emergence" by Steven Johnson offers an introduction.
- Read Part 1 of this Geographically Dispersed Grid series: Aligning computation and data.
- Read Part 2 of this Geographically Dispersed Grid series: Some common solutions.
- Read Part 3 of this Geographically Dispersed Grid series: Using policy rules.
著者について  | 
| | John Easton has worked for IBM for 18 years in a variety of UNIX technical roles. He worked in Distributed Filesystems development in Austin during the development of the RS/6000 and holds several patents pertaining to security and distributed systems. From 1990 to 2002, he focused on high availability and clustering, becoming the worldwide technical support leader for these areas and part of the Poughkeepsie lab team responsible for architecting and developing the HACMP and HAGEO products. He designed carrier-grade Linux solutions for several major telecommunications companies and represented IBM to the Service Availability Forum. Since 2002, he has been part of IBM's Grid Computing organization and the senior grid architect for EMEA. He is responsible for designing and implementing grid solutions for major companies across Europe. He brings expertise from his previous role, designing mission-critical grid solutions and influencing IBM product strategy in these areas. |
記事の評価
| 
