レベル: 初級 John Easton (JKJ@uk.ibm.com), Senior Software Engineer, IBM Global Services
2004年 11月 16日 どのようなグリッド・コンピューティング環境においても、データ・ノードとコンピューティング・ノードは必ず存在します。生産性を最大限に高めるためには、両者のバランスをどのように保てばよいでしょうか。データを実行ファイルに移動しますか。それとも、実行ファイルをデータに移動しますか。あるいは、データと実行ファイルの両方を第三の場所に送信して、グリッドのスループットを最大化しますか。この4部構成シリーズでは、このような誰もが直面する課題について検討します。
はじめに
グリッド・コンピューティング環境で計算を実行する際に時間がかかるのは、どのような処理でしょう。ジョブを並列に実行しても、計算時間の短縮に限界があるのはなぜでしょうか。この記事では、こういった重要度の高い疑問を取り上げます。これによって、一つのグリッド・コンピューティング環境上で、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントを最適に配置しようとした場合に直面する課題に、どう対応するべきかというフレームワークを理解できます。
第2部では、現在使用されている一般的ソリューションのうち、この課題にコンピューティングの面から対処しているものと、データの面から対処しているものを、それぞれ紹介します。また、それぞれの長所と短所のほか、同一グリッド内で複数の製品を併用した場合についても簡単に説明します。第3部では、さまざまなグリッド・ミドルウェア・ソリューションを1つのグリッド内に混在させると、同一ノード上にコンピューティング・コンポーネントとデータ・コンポーネントが異なる意思決定に基づいて配置され、問題を引き起こす可能性がある、ということを学習します。また、ポリシー・ルール、ワークフロー、メタスケジューラーといった取り組むべき今後の課題についても取り上げます。最後の記事となる第4部では、すべての学習ポイントをまとめます。実際のお客様事例をある程度深く掘り下げ、そこから浮き彫りになったグリッド・インフラストラクチャーの新しいデータ分散メカニズムについて見ていきます。
グリッド・コンピューティングの定義
始めに、グリッド・コンピューティングの一般的な定義を確認しましょう。グリッド・コンピューティングとは、「オープン・スタンダードとオープン・プロトコルを使用して分散コンピューティング資源の仮想化を実現し、地理的に分散した異種混在のIT環境全体にわたる単一のシステム・イメージを構築するもの」です。
この簡潔な定義から、この先に進む前に確認しておくべきポイントがいくつか浮かび上がってきます。
グローバル・グリッド・フォーラム (GGF) などの組織が長期目標として掲げているのは、標準ベースのグリッドを構築するために必要な仕様と規格を策定することですが、既存のグリッド・コンピューティング環境の多くは、営利組織、大学、オープン・ソース・プロジェクトなどが作成した非標準の独自テクノロジーによって構築されています。これが1つ目のポイントです。グリッド・コンピューティングの利点を実現するために、「非標準ベースでの実装」を受け入れる必要があるかもしれませんし、もしくは多大な時間と労力を費やしてそれらを最新の標準ベースの実装にすることもできるでしょう。しかし、そうやって構築されたソリューションには多数の落とし穴が存在することを覚悟しなければなりません。2つ目のポイントは、異種混在の課題です。各ハードウェア・ベンダーが採用している多種多様なオペレーティング・システムをグリッド内に混在させることは確かに可能ですが、実際は、営利組織のグリッドの大半は同一種で構成されています。異種混在のグリッド・コンピューティングが実質的に構築されているのは、大学環境のみです。これには、組織の購買ポリシー、管理上の問題、個人の好みなどさまざまな要因が考えられます。後で取り上げるお客様事例は異種混在システムですが、ロケーション単位でみると同一種のシステムです。この環境は、確固たる意思決定プロセスを経て購入したというよりも、例えば、親会社による企業買収があった場合などに発生します。
最後のポイントは、地理的な分散という概念です。「グリッドと呼べるのは、複数の組織や複数の物理的場所にまたがっている場合だけである」という主張があります。しかし実際に使用されているグリッドの多くは、単一の場所に限られています。私たちは BladeCentre シャーシ内に多数のブレードを搭載したグリッドを既に構築していますが、このクラスター・ノードの「地理的な」分散はわずか数センチです。お客様事例では、数百から数千キロ離れた場所にあるマシンを接続して使用する場合の課題について検討します。他のどの環境よりもグリッドらしい環境とは、どのようなものでしょうか。どこに視点を置くかにもよりますが、基本となる学習ポイントはどの場合でもほぼ同じです。
プロセッシング・グリッドとデータ・グリッドについて
グリッド・コンピューティングについて問われると、「プロセッシング・グリッドと情報 (データ) グリッドは別物である」と答える人が少なくありません。しかし実際には、両者は同じ課題を異なる側面から見ているにすぎません。プロセッシング・グリッドには、必ずデータ・コンポーネントが必要です。つまり、コンピューティング処理にはデータが欠かせないからです。専用サーバーのプールの場合にも、ネットワークからPCのCPUサイクルをスカベンジする環境の場合にも、当てはまります。データ・グリッドにおいても同様に、データの配信やセキュリティー証明書の検証などで、いくらかのコンピューティング処理が必要になります。この処理は、基本となるアプローチ (例えば、フェデレーション、リプリケーション、キャッシングなど) に関係なく発生します。そこで、両者は別々の課題ではなく、捉え方によって変化する課題であると考えます。つまり、データ・グリッドではデータ処理が多くなり、プロセッシング・グリッドではコンピューティング処理が多くなる、というように捉えるのです。
時間のかかる処理とは
どのようなグリッド・コンピューティング環境にもデータ・コンポーネントとコンピューティング・コンポーネントが存在すると考えた場合、グリッドで実行される計算の総所要時間は、さまざまな時間を合計したものであると言えます。ここでは、問題が複雑になるのを避けるためにシンプルに表現していますが、解決すべき根本的課題がよくわかるはずです。
計算全体を数多くのサブジョブに分けるには、そのための時間が必要です。多くの場合、これは小さなプログラムを実行する程度のものですが、計算流体力学などの分野では、大量かつ複雑な計算を実行する必要があるため、かなりの時間がかかることがあります。サブジョブに分けた後は、プールされた各システムにサブジョブをスケジューリングする時間も必要です。この意思決定プロセスは通常、ターゲット・システムを特定するアルゴリズムに基づいて、ごくわずかな時間で実行されます。この時間は、各グリッド・ノードの能力や種類がばらついている環境よりも、すべてのグリッド・ノードが等しい環境の方が短くなることがあります。ターゲット・ノードを特定した後は、サブジョブの実行ファイルを転送したり、ロードしたりするための時間がかかります。グリッド・ミドルウェア製品の中には、実行ファイル全体をサブジョブの一部として転送するものもあれば、ノード上にインストールされたプログラムをリモートで実行するように信号を送信するものもあります。いずれの場合でも、ネットワークでデータを転送する時間と、実行ファイルをメモリーにロードする時間が必要です。一度実行されたプログラムは次の実行時にはより短時間でロードされるため、グリッドでのロード時間はグリッドを利用しないで処理した時間と異なり一定ではありません。
ターゲット・ノードに実行ファイルを読み込むには時間がかかりますが、サブジョブ用データの転送やロードにも、同様に時間がかかります (通常は、こちらの方が時間を要します)。この処理方法は、グリッド・ミドルウェアの機能ごとに異なります。データをサブジョブの一部として物理的に転送するものもあれば、データがノード上にローカルに存在すること (共有ファイル・システムなど) を前提としているものもあります。
ターゲット・ノードがデータと実行ファイルを取得した後は、サブジョブの処理を実行するための時間がかかります。これらのサブジョブの実行にはさまざまな要因 (各ノードの現在の使用率、パフォーマンス特性、渡されるパラメーターなど) が伴うため、サブジョブの実行時間がまったく同じになることはまずありません。実行時間はばらつきますが、ここでは、個々の実行時間ではなく、最初のジョブが開始してから最後のジョブが完了するまでの合計時間に注目します。また、この間にエラーが発生した場合は、使用しているグリッド・ミドルウェア製品のエラー・リカバリー方針に応じて、サブジョブの再実行依頼が必要になることがあります。
すべての計算が完了した後は、サブジョブの結果を実行依頼元に戻すための時間がかかります。入力データをネットワーク経由でターゲット・ノードに配信した場合には、結果を返す際にも、ネットワーク経由でデータを転送する必要があります。最後に、各サブジョブの結果を統合整理するなどして、ジョブ全体の結果をまとめます。その際、何らかの追加処理 (サブジョブの結果を合計するための計算など) が必要になることもあれば 、ユーザーの意思決定を促す形で結果を表示すれば済むこともあります。いずれにせよ、この段階でも時間がかかります。
ここで、解決しようとしている課題を以下にまとめます。これらの課題は、グリッドに採用されている各種のアプローチやテクノロジーの別を問いません。つまり、単純なファイル転送メカニズムを使用して実行ファイルとデータを移動するのか、共有ファイル・システムを使用するのか、グリッド・ノードと単一リモート・データベース・サーバーに既にインストールされている実行ファイルを使用するのか、といったことにも関係なく考慮されるべきものです。
- 実行ファイルをデータに送信する必要がありますか。
- データを実行ファイルに送信する必要がありますか。
- データと実行ファイルの両方を第三の場所に送信して、グリッドのスループットを最大化しますか。
データ・セットや実行ファイルのサイズがきわめて大きい場合、これらは明確に規定されているかもしれません。しかし驚くべきことに、この明白な課題を確認し忘れていると思われるユーザーや、こうした問題の影響を検討せずに設計や実装方法を選択しているユーザーが数多く存在するのです。
グリッドのアーキテクチャー例
一般的なグリッド・コンピューティング環境のアーキテクチャーを見てみましょう。
図1. グリッドのアーキテクチャー例
図１ のグリッド環境にはいくつかのレイヤーがあります。
- ポータルなどのジョブ入力インターフェースを介して、図の左側で作業の実行依頼が行われます。
- ジョブがメタスケジューラーに送信されます。この時点で作業をどこに送信するか、すなわち、どのサービス・プールに実行を依頼するかが決定されます。
- サービス・プールは、実際の作業を実行するエンティティーです。サービス・プールはそれぞれ独自のスケジューラーを持ち、独立したエンティティーとして機能します (サービス・プールの唯一の特性は、所定の種類のサービスを実行できるようにするノードの機能です)。このことから、サービス・プールを構成するノードはすべて同じであると考えている人が少なくありません。しかしそのようなことはありません。前提となるのは、「このようなノードはその実装方法に関係なく同じサービスを提供できる」ということのみです。基本的なグリッドでは、サービス・プールが静的エンティティーである場合があります。より動的な環境では、時間の経過とともにグリッド全体のワークロード要件が変化するのに併せて、サービス・プール間でノードを再プロビジョニングする場合もあります。
- このような動的環境を機能させるための鍵となるアプローチは、図の右側にあるデータ仮想化レイヤーです。このレイヤーにより、グリッド内の各ノードが同じデータにアクセスできるようになります。一部のノードは他のノードに比べてよりデータに近いということがあり得るので、そのような場合は、結果として、各ノードのパフォーマンス特性が異なることがあるでしょう。しかし、潜在的には任意のノードが任意の役割を担うことができるようにするための鍵は、ある役割の実行に必要なデータの全てにノードがアクセスできるようにすることなのです。
では、実際のコンピューティングを担当するグリッド部分、すなわちサービス・プールについて、詳しく見ていきましょう。
図2. グリッドのサービス・プール
図2は、1つの組織が所有するという観点でサービス・プールのパターンを列挙しています。
サービス・プール1とサービス・プール2はそれぞれ異なるエンティティーです。これらは、従来のクラスターの場合もあれば、大規模なスーパーコンピューターや大量の並列マシンの場合もあります。あるいは、使用中でない CPU パワーを有効利用するデスクトップ・システムのプールの場合もあります。いずれの場合でも、サービス・プールを構成するコンピューター資源はすべて同じ組織内にあります。
サービス・プール3は他のプールとは異なり、組織内で作業を実行することも、同じサービスをサード・パーティー・プロバイダーから供給してもらうこともできます。このプロバイダーは、通常はサービス・プール 1 および 2 とは物理的に離れた別組織ですが、社内の別部門が提供するサービスであってもかまいません。その場合、作業をローカルなサービス・プールに送るのか、それとも外部のサービス・プロバイダーに送るのかは、そのスケジューラーに関するあらゆるポリシー・ルールに基づいて、メタスケジューラーが決定します。 サービス・プール4では、外部提供のサービス・プールでのみ処理を実行します。つまり、社内では処理されません。この仕組みはユーザーからは見えないようになっています。このサービスがリモートから提供されたものであるという事実を、メタスケジューラーが隠蔽するからです。サービス・プール5は、社内提供のサービス・プールの例です。利用できるリソースの量が急激に変化するような外部サービス・プロバイダーとも連携し、サービス・プールを増加させることができます。社内提供のサービス・プールでワークロードが事前に定義されたしきい値に達すると、それ以後に到着した新しいジョブは外部プロバイダーに動的に送られます。この機能は、メタスケジューラーではなく、サービス・プール内のスケジューラーが備えているのが一般的です。外部プロバイダーのリソースの使用は「従量制」であり、ユーティリティー・モデルとも呼ばれます。その後、ワークロードがしきい値を下回ると、社内のサービス・プール・コンポーネントのみが使用されるようになります。
このようにメタスケジューラーには柔軟性があるため、前述したさまざまなサービス・プール・モデルだけでなく、他のモデルにも適用できます。
まとめ
この記事では、地理的に分散したグリッドにおいてコンピューティングとデータを整合させる場合の課題を見てきました。グリッド・コンピューティング環境で計算を実行する際にはどのような処理に時間がかかるのかを説明したほか、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントを配置しようとした場合に直面する課題についても取り上げました。次の記事、第2部では、実際のグリッド・ミドルウェア・ソリューションをいくつか取り上げ、これらの課題に対処する際の長所と短所を紹介し、各ソリューションを同じグリッドで使用するとどうなるかを見ていきます。
参考文献
-
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. Also, see the two-part developerWorks article "OGSA-DAI: A look under the hood," Part 1 and Part 2.
- Download the IBM Grid Toolbox for an integrated toolkit to explore Web and data services in grid environments.
- See a basic introduction to emergent behaviour.
- "Emergence" by Steven Johnson offers an introduction.
- Read Part 2 of this Geographically Dispersed Grid series: Some common solutions.
- Read Part 3 of this Geographically Dispersed Grid series: Using policy rules.
- Read Part 4 of this Geographically Dispersed Grid series: A case study.
著者について  | 
| | 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. |
記事の評価
| 
