レベル: 上級 John Easton (JKJ@uk.ibm.com), Senior Software Engineer, IBM Global Services
2004年 12月 14日 地理的に離れた複数のサイトにまたがってグリッドを分散させる際には、パフォーマンスに関するいくつかの複雑な課題に取り組まなければなりません。どのようなグリッドにおいても、データ・ノードとコンピューティング・ノードは存在します。計算を実行するには、データ・コンポーネントとコンピューティング・コンポーネントを同一グリッド・ノード上に揃える必要があります。しかし、同一グリッド上に複数のグリッド・ミドルウェア・ソリューションが存在すると、その連携方法に関する決定に食い違いが生じ、パフォーマンス上の問題が発生することがあります。
第 1 部では、「グリッド・コンピューティング環境で計算を実行する際には、どのような処理に時間がかかるか」という問題と、「ジョブを並列に実行しても、計算時間の短縮に限界があるのはなぜか」という問題を取り上げました。これらを理解すれば、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントを同一グリッド・ノード上に配置しようとする際に直面する課題を研究するための土台ができたと言えます。
第 2 部では、一般的なグリッド・ソリューションのうち、この課題にコンピューティングの面から対処しているものと、データの面から対処しているものを、それぞれ紹介しました。また、それぞれの長所と短所のほか、同一グリッド内で複数の製品を併用するとどうなるかについても簡単に説明しました。
第 3 部では、このノード連携の問題と、ポリシー・ルール、ワークフロー、メタスケジューラーを使用した関連ソリューションおよび課題について検討していきます。
データ・サービス: ソリューションとしての可能性
複数のグリッド・ミドルウェア・ソリューションがデータ・コンポーネントとコンピューティング・コンポーネントを同一グリッド・ノード上に揃えるような環境では、高度な決定を行うエンティティーが 1 つ必要です。決定は、どこで計算を実行すべきかを判断するポリシー・ルールに基づいて行われます。その決定に応じて、エンティティーが、基盤となるジョブ・スケジューラーとデータ・ムーバーに必要処理を指示します。そうすれば、判定結果の食い違いは避けられるので、各コンポーネントのインテリジェンスにこの処理を任せられるようになります。
「データ・サービスがこのような高度なエンティティーとして機能すれば、こういった類の課題は解決される」というのは、1 つの考え方です。ではまず、データ・サービスがどのような機能を果たすのかについて見てみましょう。データ・サービスはグローバル・グリッド・フォーラムが定義した OSGA 仕様の一部であり、通常は、他のグリッドまたは Web サービスと組み合わせて使用されます。
Web サービスが果たす役割はきわめてシンプルです。図 1 に示されているように、Web サービスは、より従来型のシステムにおいてアプリケーションやプロセスを提供します。一般に、アプリケーションは複数のプロセスから構成されています。すなわち Web サービスは、その実装方法に応じて 1 つ以上のプロセスと同じ機能を提供していることになります。
図1. Web サービス
その一方でデータ・サービスは、図 2 に示されているように、任意数のさまざまなレベルで存在できます。データ・サービスは通常、ファイル・システム、データ管理ソリューション (データベース)、データ統合ソリューション (データ・ソースのフェデレーション) などに対するアクセスを提供します。 またデータ・サービスは、このスタック内のさまざまなレベルに現れるだけでなく、データ統合ソリューションの内部に存在する場合もあります。例えば、データ・サービスがデータ・フェデレーションへのアクセスを提供していて、そのデータ・フェデレーションがデータ・サービスで表現されているデータベースの集まりである場合などが、これに当たります。データ・サービスがロー・ディスクへのアクセスを提供する場合もありますが、それが大きな利点になることはまずありません。
図2. データ・サービス
ここでの真の課題は、「Web サービス (前述のコンピューティング・コンポーネント) とデータ・サービス (データ・コンポーネント) を組み込んだ形でワークフローを作成する場合は、データの使用方法に関するワークフロー・ビューが必要になる」ということでしょう。ユーザーから見れば、Web サービスやデータ・サービスのロケーション中立性は大きな強みですが、計算とデータを同じ場所に配置する場合の問題解決にはあまり役立ちません。
例えば、以下の 3 つのステップから構成された単純なワークフローを考えてみましょう。
- Web サービスを使用して、計算のための一連のパラメーターをユーザー入力に基づいて設定します。
- データ・サービスが、パラメーターが処理に使用するデータを取得します。
- 別の Web サービスが、計算全体の主要部分を実際に処理します。
このワークフローは単純に見えるかもしれません。しかし、データ・サービスがローカル・ノードにデータを取得したにもかかわらず、3 番目のステップがリモート・ノードで行われるような場合には、データをさらに何回か移動しなければなりません。「3 番目のステップは常にこのリモート・ノード上で実行される」ということがわかっている場合は、データ・サービスがリモート・ノードにデータを取得するようにしておく必要があります。データ・サービスに処理の指示を出すには、ワークフローでのその後のデータ処理について把握しておく必要があるのです。静的なワークフローや、Web やデータ・サービスの場所を常に把握できるワークフローであれば、これは問題にはなりません。しかし、より動的なワークフローの場合や、同一の Web サービスの複数のインスタンスが複数のロケーションから調達されているような場合、この問題の解決はさらに難しくなります。
このように、サービスのアプローチでは、一貫したインターフェースは維持され、さらにその実装は隠蔽されます。そのため、サービスは実際には期待するほどロケーションに中立的ではありません。ここまで見てきたように、グリッド・ソリューションの中には、地理的に離れたサイトにまたがったシステムに直面すると動作がおぼつかなくなるものもあります。また、Web サービスとデータ・サービスの組み合わせも、期待どおりに機能するとは限りません。この問題は通常、地理的に分散した環境で運用を開始した場合に発生します。これはLAN中心の観点で作成されたソリューションの域を出ないからです。つまり、データ・サービスのアプローチは、この課題を期待どおりに解決してくれるとは限らないのです。
メタスケジューラーの役割
では、メタスケジューラーはこの問題を解決してくれるでしょうか。メタスケジューラーは、独自のスケジューリング・ソリューションを持つ複数のクラスターやグリッドにまたがって、作業をスケジュールします。さらに、同じスケジューリング・ソリューションを利用するコンポーネントごとに、グリッドの階層を作成することもできます。また、まったく異なるスケジューラーを使用しているコンポーネントをリンクして、その違いをシステム・ユーザーから隠蔽することも可能です。しかしいずれの場合でも、メタスケジューラーは私たちが探しているエンティティーではありません。その名前が示すように、メタスケジューラーが関わるのは主に問題のスケジュール面です。言い換えれば、メタスケジューラーはコンピューティングに関する課題は把握できるものの、データに関する課題は把握できないのです。
独自のメカニズムを利用して作業の場所と方法をスケジュールするような定評あるメタスケジューラー製品オファリングであっても、これが実情です。サブグリッドやクラスターで使用される基盤テクノロジーには資源の状態に関する独自の視点がありますが、これらの独自仕様のメタスケジューラーも同様です。しかし、グローバル・グリッド・フォーラム (GGF) 標準の登場は、より標準準拠のメタスケジューリング・ソリューションの可能性に道を開くことになりました。このようなソリューションの目的は、OGSA 準拠サービスを使用してグリッド内の全資源に対する一貫性のあるビューを提供することです。標準形式で全資源の状態を把握し利用できるようになれば、ジョブ・スケジューラーとデータ・ムーバーは、同一のグリッド・ビューから決定を下せるようになります。そうすれば少なくとも理論上は、これまで述べてきた課題のほとんどは解消するはずです。しかし実際には、このような標準準拠グリッドが産業界で広く普及するまでにはかなりの時間がかかります。製品オファリングに標準が採用され、市場に普及するまでは、独自仕様のグリッド・ソリューションはやはり大きな役割を果たし、私たちもそれに付き合っていかなければならないのです。したがって、ここで解決しようとしている問題もしばらくは残ることでしょう。
私たちに本当に必要なのは、データとコンピューティングの両面から問題に対処できる拡張メタスケジューラーです。これは思うほど複雑ではありません。データやコンピューティングの問題を詳細に把握していなくても、高度な決定を 1 つ行い、指定された方法で動作するように基盤テクノロジーに指示するだけで、必要機能のほとんどが得られるからです。拡張メタスケジューラーは、問題の両面に積極的に問題に取り組まなければならないようなパッケージより、はるかに実装が簡単です。これについては後から実例で説明しましょう。
一般的なグリッド問題の項目
取り組むべき課題を詳しく把握できるように、一般的な問題に含まれる項目について見ていきましょう。
- グリッドには、地理的に分散した各サイトのさまざまな組織にまたがった、多数のコンピューティング要素が存在します。コンピューティング要素は、異機種混合の場合もあれば、同一機種の場合もあります。
- サイトは多種多様な WAN リンクによって接続されています。これらのリンクは、さまざまな理由 (サイトの相対的な局所性やローカル通信プロバイダーの能力など) に応じて、帯域幅やレイテンシーが異なります。
- グリッドにはさまざまなワークロードを多数サポートする能力が求められますが、それを前述の要件と組み合わせると、「利用可能な帯域幅とレイテンシーに比べて実行可能ファイルが大きい」という事態に陥ってしまいます。
システム全体での制約を考えれば、使用できるすべてのシステムにワークロードを分散し、使用可能システムの使用率を最大化する方法を探る必要があります。また、実行ファイルやデータの局所性を考慮し、データとコンピューティングの両方が同一物理システム上に配置されるようにしなければなりません。これは、言うほど簡単なことではありません。
地理的に分散したグリッド・ソリューションの例
問題の規模を説明するために、そのようなグリッドを 5 か国のサイトにわたって配置しようとしている、ある組織について取り上げます。図 3 に、このグリッドの実際のトポロジーを示します。
図3. 地理的分散グリッドの例
図 3 での距離は「直線距離」であって「ケーブルの敷設距離」ではありません。多くの場合、ケーブル敷設距離はこれより大幅に長くなります。この例の組織は 15 の製品ファミリーの開発を管理しています。これらの製品ファミリーには、それぞれ関連する設計データと開発データが存在します。製品ファミリーのデータの中には、5 か所すべてのサイトで処理可能なものもあれば、輸出規制や知的財産上の問題、あるいはその他の業務上の理由から、特定のサイトやグループでしか処理できないものもあります。開発行程の一環として、製品ファミリーのデータは数多くのアプリケーション (社内開発されたものや市販の製品など) を使って処理されます。各アプリケーションには前提条件となるアプリケーション、ライブラリー、サービスがあり、それぞれ、そのアプリケーションの実行ファイルと同じ場所に配置しなければなりません。多くの場合、各アプリケーションやその前提となるアプリケーション、ライブラリー、サービスなどには、ライセンス料金を支払う必要があります。アプリケーションの中には組織全体での使用に関してライセンス料を課するものもありますが、特定のロケーション内でのみライセンスが許されるアプリケーションもあります。
ワークロードは 2 つのクラス (バッチとオンライン) に分けられます。ここで言うオンライン・ワークロードとは、ユーザーがアプリケーションの応答を待ってから処理を続行するワークロードのことです。バッチ・アプリケーションでは、ユーザーは別のタスクを先に進め、アプリケーションが後から非同期的に値を返します。パフォーマンス上の理由から、オンライン・ワークロードはユーザーのローカルとして処理しなければなりませんが、バッチ・ワークロードは任意のロケーションで処理可能です。
製品ファミリーの料金は、コンピューティング資源、データ資源、ネットワーク資源の使用量に応じて決まります。そうすれば各製品ファミリーは、安価な資源を最大限活用し、高価な資源の使用を最小限に抑えることができます。計算処理に要するコストは、使用されるマシンの種類、消費されるネットワーク帯域幅、アプリケーション・ライセンスの使用料など、さまざまな要因に応じて変わります。
ここから浮かび上がってくるのは、組織内でのコンピューティング方法に影響を与える数多くのビジネス・ルールです。作業をスケジュールする際はこれらのルールを考慮して資源の効率的利用を図り、コストを最小限に抑えながら、ワークロードのスループットを最大化しなければなりません。
このような環境については、さまざまなことがわかっています。以下に例を示しましょう。
- 使用するアプリケーション実行ファイルとデータ・ファイルのサイズは判明しています。
- ネットワーク・リンクの最大帯域幅とレイテンシーは判明しています。
- 現在利用できる帯域幅を測定できるほか、ネットワーク・パフォーマンス特性もリアルタイムで把握できます。
- ユーザー、データ、実行ファイル、アプリケーション・ライセンスなどの実際の場所は判明しています。
- 「どのユーザーが実行を依頼したか」、「依頼された作業はバッチ・ジョブかインタラクティブ・ジョブか」などは判明しています。サイトの相対的局所性も判明しています。
このような情報を使用すれば、グリッド内のノードに作業の実行依頼を出す方法について、簡潔な決定を行うことができます。
まとめ
ここでは、データ・サービスについて簡単に取り上げ、コンピューティングとデータの連携に関する課題を概観しました。これらの課題を実証する例として、メタスケジューラーの手法について説明したほか、お客様側で実装される、地理的に分散したグリッド・ソリューションを紹介しました。
このシリーズ最後の記事となる次の 第 4 部 では、課題解決を探るためのこの旅を終えたいと思います。あるお客様のグリッド・インフラストラクチャー用として新たに開発されたデータ分散メカニズムを紹介し、その成果を検討しましょう。
参考文献
-
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 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. |
記事の評価
| 
