レベル: 初級 John Easton (JKJ@uk.ibm.com), Senior Software Engineer, IBM Global Services
2004年 12月 07日 どのようなグリッド・コンピューティング環境においても、データ・ノードとコンピューティング・ノードは存在します。パフォーマンスは重要です。グリッドのコンピューティング機能をサポートするテクノロジーは、どのように選択すればよいでしょうか。データ仮想化レイヤーに関するテクノロジーは、どのような方法で選択すべきでしょうか。この 4 部構成シリーズの第 2 部では、高度な決定基準を示すとともに、グリッド関連製品の組み合わせの長所と短所を検討します。
第 1 部 では、「グリッド・コンピューティング環境で計算を実行する際には、どのような処理に時間がかかるか」という課題を取り上げ、「ジョブを並列に実行しても、計算時間の短縮に限界があるのはなぜか」について検討しました。これを理解することにより、ジョブのデータ・コンポーネントとコンピューティング・コンポーネントをグリッド・ノード上に最適に配置しようとする際に直面する課題を研究するための土台ができたと言えます。
ここでは、現在使用されている一般的なグリッド・ソリューションのうち、この課題にコンピューティングの面から対処しているものと、データの面から対処しているものを、それぞれ紹介します。また、それぞれの長所と短所のほか、同一グリッド内で複数の製品を併用するとどうなるかについても簡単に説明します。第 3 部 では、この課題の解決過程におけるデータ・サービスと、それに伴う課題について検討します。最後の記事となる 第 4 部 では、すべての学習ポイントをまとめます。実際のお客様事例をある程度深く掘り下げ、そこから浮き彫りになったグリッド・インフラストラクチャーの新しいデータ分散メカニズムについて見ていきます。
プロセッシング・グリッドに関するテクノロジー -- 高度な要件
グリッドのコンピューティング機能をサポートするテクノロジーを、どのように選択すればよいでしょうか。その選択方法は、個々の環境や具体的な要件に応じた、さまざまな要因によって決定されます。
異種混合性：サービス・プール内で使用されるスケジューリング・ソフトウェアは、異種混合のコンピューティング・ノードをサポートできなければなりません。たとえ現在の実装には不要だとしても、将来的な成長と拡張に備える意味では必要でしょう。サービス・プール内のノードに関して重要なのは、「すべてのノードが同一のサービスまたはサービス・セットをサポートできる」という点です。すべてのノードが同じタイプである必要はありませんが、そのプラットフォーム上での実装方法にかかわらず、すべてのノードが同一サービスをサポートできる必要があります。
セキュリティー：スケジューリング・ソフトウェアは、本来の目的に必要なレベルのセキュリティーを備えていなければなりません。グリッドの多くは、複数の組織にまたがる環境に求められるセキュリティーほどは厳しくない要件の単一の企業内に実装されます。多くのグリッドでは、グリッド・ノードの基本オペレーティング・システムで提供される以上のセキュリティーが追加されることはほとんどありません。すべてのグリッドはファイアウォールの内側に収まっているため、会社のネットワーク上に存在する他のシステムと同程度に、セキュリティーは確保されています。多くの企業では、「セキュリティーを強化するとインフラの反応が極端に遅くなる」、あるいは「たとえ侵入者がグリッド内のノードをハッキングしたとしても、データの断片から全体は理解できないので、処理中のデータがどうこうされるわけではない」と信じているため、追加のセキュリティーを実装する必要性を認めていません。
信頼性：スケジューリング・ソフトウェアには、耐障害性を確保できるレベルの信頼性が必要です。例えば、計算を実行するサービス・プール・ノードの障害や、サービス・プール・ノードを相互接続しているネットワーク内の障害などに対処することが求められます。しかしここでも、決まった正解はありません。テクノロジーは、ユーザーに適している必要があります。例えば、「計算が最終的に完了するかどうか」のみが問題とされるような環境では、何らかの方法でジョブの実行依頼をやり直すことができれば十分かもしれません。ノード、ネットワーク、ソフトウェアなどの障害が原因で、あるサブジョブの実行に失敗した場合は、どこか別の場所にそのサブジョブの実行依頼が送られます。この方式でもある程度の耐障害性は提供されますが、ジョブ応答時間への配慮は皆無であり、サブジョブの再実行依頼が繰り返されるたびに応答時間は長くなっていきます。環境によっては、応答時間がきわめて重視される場合もあります。その一例は、商品取引や証券取引を行う金融機関です。この場合、スケジューリング・ソリューションには、障害発生時にも応答時間を維持することが求められます。この種のソリューションでは通常、サブジョブの複数のコピーを、グリッド内の異なるノードで実行します。そのため、障害が発生した場合でも、応答時間に影響が出るリスクを最小限に抑えられます。信頼性について言えば、このアプローチにはもう 1 つ利点があります。すなわち、異なるアーキテクチャーの複数のマシンにサブジョブのコピーを送信すれば、チップのアーキテクチャー、オペレーティング・システム、コンパイラーなどに起因する潜在的エラーを防ぐことができるのです。
選択したサービス・プール・スケジューラーでは、基本レベルの機能しか提供されないかもしれませんが、理想を言えば、スケジューラーには基本的なスケジューリング機能以上のものが必要です。高度な定義が可能なスケジューリング・ポリシーを複数持つことができたり、優先度の高いサービス要求を受信したときにそのタスクを先に実行できたりすれば、サービス・プールの柔軟性は向上し、それ自体が強力なエンティティーとして機能するようになります。
スケジューリング製品の選択
スケジューリング製品に関しては、多数の選択肢が存在します。まず、グリッド・スケジューラーに求められる第 1 の機能とは何でしょうか。システム (通常はデスクトップ PC ですが、必ずしもそれに限定されません) のプールから未使用の CPU サイクルをスカベンジすることでしょうか 。それとも、システムのプールをグリッド専用にすることでしょうか。後者の環境を選択した場合は、商用オファリングとオープン・ソースの両方からさらに多くの選択肢があります。これらの選択肢はプロバイダーによって完全にサポートされ、あるコミュニティーのユーザーや学術分野のユーザーに提供されるのです。前者の環境を選択した場合、多くのCPU サイクル・スカベンジング・オファリングは商用ベンダーから入手可能ですが、いずれのテクノロジーにも、環境から何かを排除するという性質は備わっていません。つまり、やはり選択の問題になります。見落とされがちな要因の 1 つに、「ユーザーにとっての応答時間の重要性」があります。一般に、応答時間の要件に対応できる可能性が高いのは、CPU サイクル・スカベンジング環境ではなく、専用システムのプールです。デスクトップ・スカベンジング環境では、変数が増えるにつれて、保証している応答時間を達成することが (不可能ではないにしても) 難しくなります。膨大な数のシステムを持つようなスカベンジング環境では、変数の増加を相殺してしまうことがよくあります。これは応答時間を達成するために必要な数のシステム (またはそれと同等の仮想システム) が検出される可能性が高くなるからです。
データ仮想化に関するテクノロジー -- 高度な要件
図 1 のアーキテクチャーのコンピューティング・レイヤーは実際にはさらに複雑ですが、データ仮想化レイヤーも外見より複雑です。図 1 で示されているように、データ仮想化レイヤーには、あらゆる組織内によく見られるさまざまなデータ・ソースをサポートすることが求められます。
図1. さまざまなデータ・ソースを持つグリッド
図 1 に示されているように、グリッド内のデータベースには、構造化データ、非構造化データ、フラット・ファイルなどのほか、ファイル・システム内に保存されているさまざまなオブジェクトが含まれる可能性があります。また、グリッドには組織外のデータ・ソースをサポートできることも必要です。これらの外部データ・ソースの形式は多種多様です。Web ページやインターネット・リポジトリーのように、誰でもアクセスできるものもあれば、購読契約したユーザーのみがアクセスできるものもあります。業界コンソーシアムの一環として共同作業している複数の企業間でデータを共有する場合もあれば、合同プロジェクトでのコラボレーションにおいて、企業と大学がデータを共有する場合もあります。データ・ソースの中には、能動的なクエリーと受動的なクエリーの両方をサポートできるものもあります。一方、ロイターやブルームバーグのような組織からのデータ・フィードでは、データの受信順序をユーザーが制御することはできません。
データ仮想化を行うと、ユーザーがデータの所在や形式を意識することはなくなります。必要であれば、このレイヤーの下に障害回復メカニズムを配置し、障害回復ポイントやリモートのバックアップ拠点からデータを供給できるようにすることが可能です。
グリッドに関するデータ・テクノロジーは、どのように選択すればよいでしょうか。その選択はさまざまな要因によって決定され、各要因の相対的重要性は、個々の環境や具体的な要件に応じて変動します。グリッド環境内での使用に適したファイル・システム・テクノロジーには、数の制限はありません。クラスター・ファイル・システム、ネットワーク・ファイル・システム、分散ファイル・システムなどは、いずれもそれぞれの役割を持っています。また、集合データベース、フェデレーテッド・データベース、複製データベースが必要となる可能性もあります。多くの企業では、ハイブリッド型のソリューション、つまり上記のテクノロジーを 1 つ以上組み合わせたソリューションを実装しています。また、既製のソリューションの組み合わせや、「自家製」のソリューションを実装している場合も多々あります。
クラスター・ファイル・システムはクラスター・ノードの分離レベルに影響されることが多いため、単一サイト内のみで使用する場合に適しています。したがって、複数サイト間で処理を行う場合には、クラスター・ファイル・システムの適用可能性はかなり低くなります。同様に、ネットワーク・ファイル・システムの多くも、(歴史的な理由から) 単一サイト環境または単一キャンパス環境向けに作られています。いずれのソリューションにもネットワーキング・テクノロジーの進化が反映されていますが、その主な目的は、より多くのマルチサイト機能を搭載することにあります。真の分散ファイル・システムは最初から複数拠点への対応を念頭に設計されており、通常はマルチサイト・グリッドの基盤を形成します。データベース (あるいはさらに構造化された記憶機構) 内に大量のデータが格納されている場合は、ファイル・システムはさほど役にたたず、フェデレーテッド・データベースや集合データベースが大きな役割を果たします。
集合データベースで試みられているのは、多様なシステムから供給されるあらゆる形式のデータを単一の並列データベースに統合することです。これは拡張性のあるアプローチですが、単一サイトでの実装向けであることに変わりありません。フェデレーション製品の目的は、複数のサイトにデータを分散したままで、統一インターフェース (基盤となる実装やデータ・ソースをユーザーに意識させないようなインターフェース) を提供することです。
フェデレーテッド・データベースは集合データベースより柔軟ですが、データ・ソースがユーザーから見てリモートにある場合にパフォーマンス特性が不安定になるという潜在的な課題が存在します。ここから、「ユーザーにとってローカルな場所にデータ・ソースを複製しておくと便利だ」という考え方が出てきます。このデータ複製も、フェデレーション・レイヤーの下で、ユーザーに意識されない形で行われます。ほとんどの企業ではファイル・システムとデータベースからのデータを利用するため、この領域では通常、グリッドはファイル・システム・ソリューションとデータベース・ソリューションの両方を必要とします。
どのようなデータ仮想化ソリューションを選択した場合でも、データのソーシングやアクセスなどのプラットフォームに関しても、あるいはデータ保存に利用するテクノロジーやテクニックなどに関しても、異種のデータ・ソースをサポートできることが必要です。大多数の組織にとっては、一貫したデータ・コピーを 1 つだけ管理する方が管理しやすく、理想的です。しかし、その単一コピーがユーザーから見てリモートにある場合は、パフォーマンス低下とのバランスを取らなければなりません。レプリカの管理方法に精通しているのであれば、このようなケースでは、レプリカを使用する方法が適している可能性があります。
何よりも避けるべきなのは、「データにアクセスするためにユーザーがアプリケーションや作業方法に何らかの措置を講じなければならない」といった事態です。グリッド実装前に、ポイント・アンド・クリック方式のインターフェース、SQL クエリー、コマンドラインなどでデータにアクセスしていたユーザーの場合は、グリッド実装後も同じ方法を利用できるようにすべきでしょう。ユーザー・インターフェースの大幅な変更が許容されるのは、それによって著しい機能追加を図れる場合に限られます。データ仮想化スキームの成否は、ユーザーに対する透過性をどれほど効果的に維持しているかということから判定できます。
高度な分散化の可能性を秘めたこの環境においては、「プロバイダーとユーザーを保護しながら、全体としてのデータ保全性も確保する」という、標準的なデータ・セキュリティー課題に対処しなければなりません。その上で、バックアップ、アーカイブ、バージョン管理、経年処理などといった日常のデータ管理タスクを維持しなければならないのです。
コンピューティングとデータの整合
豊富なテクノロジーと製品を利用できるという前提の下に、根本的な問題に立ち戻りましょう。すなわち、グリッドの同一ノード上でコンピューティングとデータを整合させるという問題です。これは簡単に解決できる問題であると思われるかもしれませんが、克服すべき障害が 1 つあります。一般に、前述の各テクノロジーは、問題解決の決定方法に関して独自のインテリジェンスを備えています。ここで問題なのは、これらのインテリジェンスがそれぞれ独立した状態で決定を行っているということ、つまり、他のコンポーネントに関する正確な知識や理解がないままに、個々の視点からグリッドの状態を見て判断しているということです。
結論が明白な場合には、ジョブ・スケジューラー (コンピューティング・コンポーネントをノードへ移動させるエンティティー) の決定とデータ・ムーバー (データ・コンポーネントをノードへ移動させるエンティティー) の決定が整合するため、同一ノード上にコンピューティング・コンポーネントとデータ・コンポーネントが揃います。この場合、意図したとおりの計算が行われます。ところが、グリッドの複雑性が増してくると、特に地理的に分散したサイトやノードでは、ジョブ・スケジューラーとデータ・ムーバーの下す決定が食い違う事態が頻繁に生じるようになります。これは、特に驚くことではありません。なぜなら前述のテクノロジーの多くは、すべてのシステムが同一 LAN 上にあるという前提で開発されたものだからです。これらのソリューションをより遠距離環境で利用するよう拡張すれば、その意思決定システムの一部に制約が生じることは、容易に理解できます。
それでは、このように決定が食い違うことによってどのような影響が出るのでしょうか。その答えは実に単純です。単一ノード上でコンピューティングとデータを整合させることができなければ、計算は失敗します。その場合、ジョブ・スケジューラーは計算の再実行依頼を試みるはずです。ここで問題となるのは、同じ意思決定ロジックを使用する限り、次回もまた不適切な意思決定が行われる可能性があるということです。ジョブの再実行依頼が必要となるたびに、リソースを効果的に使用する機会は失われます。これではインフラストラクチャーの使用率目標を達成できないため、期待したワークロード量をグリッドで処理することができません。
まとめ
この記事では、利用可能なグリッド・ミドルウェア・ソリューションを選択する際に使用できるいくつかの基準について概観しました。また、同一グリッド上でそれらの製品を併用する場合の長所と短所についても取り上げました。第 3 部 では、さまざまなグリッド・ミドルウェア・ソリューションが同一グリッド・ノード上にジョブのデータ・コンポーネントとコンピューティング・コンポーネントを揃えようとする際の、意思決定の問題について検討します。
参考文献
-
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 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. |
記事の評価
| 
