はじめに

このシリーズのパート 1 では、6 つの戦略の概要を紹介し、各戦略の特性と利点を要約します。この記事は、シリーズのパート 2 に該当し、「戦略 1: ノード非依存バッチ」と「戦略 2: 独立並行バッチ」を使用してアプリケーションをグリッド化するための方法について説明しています。最初の戦略では、アプリケーションはグリッド内の任意のコンピューター上で単一ジョブとして実行できます。2 番目の戦略では、アプリケーションの複数の独立インスタンスを並行して実行できます。パート 3 では、アプリケーションのグリッド化に関する 6 つの戦略のうち、第 3 と第 4 の戦略について説明します。バッチ・プログラムの処理を分割する方法と、プログラムをサービス・サブルーチンとして処理する方法が概説されています。サービス・サブルーチンは、クライアントがグリッド・ミドルウェア経由で呼び出すことができます。このシリーズのパート 4 では、アプリケーションがサービスを並列使用するときに活用できる、新しいパラダイムについて説明します。

簡潔に説明するため、最初の 2 つの戦略と以降のレベルの関連性について、図 1 に示します。

「戦略 1: ノード非依存バッチ」の主な特性は次のとおりです。

• 場所に依存せず、ジョブの単一インスタンスが複数ノードのうちの任意の 1 つで実行される。
• LAN および WAN の入出力ボリューム、タイミング、パフォーマンスが許容範囲内にある。
• プロビジョニングの負荷が適度である。
• ライセンス交付の負荷が適度である。
• セキュリティー・レベルが妥当である。
• 開始に要する時間が許容範囲内にある。
• カレンダー、前提ジョブ、またはファイルの到着に応じて、スケジューリングが行われる。

図 2 は、グリッド内の 1 つのノードで実行されるバッチ・ジョブのインスタンスを示しています。

「戦略 2: 独立並行バッチ」の主な特性は次のとおりです。

• 複数のインスタンスが相互に干渉せず、独立して実行される。
• 独立ジョブを共有できる。例えば、アカウント A のジョブ X を、アカウント B のジョブ X と並行して実行できます。
• データベースおよびその他の資源にホット・スポットやデッドロックがない。

この「戦略 1: ノード非依存バッチ」の説明では、ケース・スタディーを示した後、ライセンス交付、セキュリティー、ノードの類似性、ジョブ管理、複数サイト、オプションの変更、およびミドルウェアについて必要な処理を示します。

上に戻る

戦略 1: ノード非依存バッチ

戦略 1: ノード非依存バッチのケース・スタディー

この戦略の基本ケース・スタディーで取り上げるのは、コマンド行パラメーターを取得し、コマンド行パラメーターで指定されたファイルとデータベースを使用するアプリケーションです。ライセンス・アプリケーションの場合についても考慮しています。

この戦略の目標は、実行時のグリッド・ミドルウェアの選択に応じて、グリッド内に多数存在するノードのほぼすべてから、アプリケーションの 1 つのインスタンスを実行できるようにすることです。ミドルウェアは、次回の実行時には他のノードを選択するかもしれません。選択されたノードと他のノードが別のアプリケーションを並行して実行している場合以外、並行処理の局面は発生しません。

ライセンス交付

アプリケーションは合法的に使用する必要があります。ライセンス交付の対象であるアプリケーション、ライブラリー、ミドルウェアを使用するには、ライセンス条項を満たしている必要があります。グリッド内のすべてのノードでソフトウェア・ライセンスを取得できる見込みがない限り、ドングルやノード・ロック・ライセンスをアプリケーションで使用することはできません。このグリッド化戦略では、少なくとも「一度に 1 つのノード」にライセンスを交付できるモデルを採用する必要があります。

Open Group X-Open Software License Use Management (XSLM) (参考文献のリンク参照) の標準的ライセンス交付には、次の 5 つのモデルがあります。

• 基本:企業またはサイト単位のライセンス。
• 名前指定:登録ユーザーまたは特定のマシン名に基づくライセンス (「ノード・ロック・ライセンス」とも呼ばれます)。
• 同時使用:同時使用ユーザー数が制限されたライセンス。
• 累積的または消費的:使用状況 (ジョブの実行回数や実行時間) に基づくライセンス。このライセンスは事前に設定された制限に基づく場合と、実際の使用状況の監査ログに基づく場合があります。
• 処理能力:特定のコンピューティング能力を下回るマシンで使用するように制限されたライセンス。

ライセンス管理にはいくつかの方法があります。

• 技術的にではなく、契約によって管理する方法。ユーザーはライセンス条項に従う責任を負います。
• 監査記録によって管理する方法。アプリケーションまたはジョブ管理ソフトウェアによって、使用状況のログが管理されます。
• Platform Computing の Global License Broker などのように、グリッド・ミドルウェアのライセンス管理サービスによって管理する方法。
• Isogon の LicensePower/iFOR、Macrovision の FLEXnet、IBM の License Usage Manager などのライセンス管理ソフトウェアを使用して管理する方法 (参考文献 を参照)。
• 自分で管理する方法 (推奨されません)。ライセンス管理コードは自分で作成しないでください。ライセンス管理に利用できる市販のコードを活用してください。

セキュリティー

適切なセキュリティーを確保する必要があります。セキュリティーはアプリケーションの外部で提供するのが理想的です。どのユーザーにアプリケーションの実行を許可するかは、環境に応じて決定します。許可されたユーザー ID のみがアプリケーションを起動できるように設定する必要があります。

機密データを含む中間ファイルが作成されるアプリケーションで、アプリケーション・エラーの発生時に中間ファイルが削除されない可能性がある場合は、潜在的な問題に関する記述を操作手順に含めておく必要があります。

ノードの類似性

アプリケーションが次回も同じノードで実行されるとは限りません。前回とは別のノードで実行されることもあります。そのため、使用可能にしておくべきファイル、作成されるファイル、および変更されるファイルについて、あらかじめ文書化しておく必要があります。アプリケーションを配備するときにこの文書を参照すれば、プロビジョニングの計画や、キャッシング・テクノロジー (IBM の SAN File System や Avaki の Data Grid など) の検討が容易になります (参考文献 のリンク参照)。

ジョブ管理

アプリケーションは、ユーザーがコマンド・プロンプトやメニュー・システムから実行するのではなく、ジョブ管理システムによって実行されるものと想定します。stdin、stdout、および stderr などの標準入出力をファイルにリダイレクトしてください。

単一サイト -- LAN のトラフィック

正しく接続されたサイト内のいずれかのノードでアプリケーションを実行し、かつサイト内の資源のみを使用する場合は、ローカル・エリア・ネットワークのトラフィックを考慮する必要があります。このトラフィックは、ノードで実行されるアプリケーションや前提ファイルをプロビジョニングするときにまず発生し、次に、作成結果をローカルの別の場所に移動するときに発生します。ノード外部のデータベース、メッセージング、トランザクション・システムなどを使用するときにも、トラフィックが発生します。また、同じノード上や別のノード上には LAN を使用している別のアプリケーションも存在する、ということも考慮する必要があります。

複数サイト -- WAN のトラフィック

複数のサイト上の複数のノードのいずれかでアプリケーションが実行される場合は、広域ネットワークのトラフィックの問題を考慮してください。各サイトにキャッシュされないファイルは、プロビジョニング処理の対象になります。アプリケーションが終了したら、結果を最終的な宛先に送り返す必要があります。NFS やその他の技法による、キャッシュされていないコンテンツへのリモート・アクセスは、アクセス量や転送データ量の増加がアプリケーションの実行時間に大きな影響を与えない場合にのみ可能です。例えば、大きなファイルの一部分のみを必要とする実行では、ファイル全体のコピーやキャッシュは必ずしも要求されません。サイト間のデータベース・アクセスについても同じことが言えます。

複数サイト -- データベースの使用状況

1 つ以上のリモート・サイトにあるデータベースやトランザクション資源にアプリケーションがアクセスする場合は、WAN のトラフィック以外にも考慮すべき点があります。データベース管理システム (DBMS) に複数のクライアントがある場合は、通常、ロック期間を最小限に抑えることが重要です。ストアード・プロシージャーによるアプリケーションの更新はクライアント・アプリケーションには許可されませんが、ロック期間が短縮されてセキュリティー管理が向上した場合は、データ所有者によって許可される可能性があります。複数の場所からデータを結合するときは、DB2R Information Integrator (参考文献 を参照) などのフェデレーテッド・データベース・テクノロジーを利用すると、WAN のトラフィックおよびクライアント側コードを削減することができます。

その他の変更

これ以外にも、戦略 1 には次のような変更が有効です (必須ではありません)。

• 必要に応じて、アプリケーション・パラメーターで制御できる項目 (最大メモリー容量や使用するプロセッサー数など) を拡張できます。
• 必要に応じて、いったんキャンセルしたアプリケーションを後で問題なく再実行できるようにすることができます。時間をおいて実行することも、別のマシンで実行することも可能です。
• 必要に応じて、アプリケーションにチェックポイントを作成できます。これにより、アプリケーションをいったんキャンセルした後で再実行した場合でも、すべての処理を最初から実行する必要がなくなります。チェックポイントと再起動のパラメーターに、チェックポイント・レコードの書き込み頻度 (n 個の入力レコードごと、m 分ごとなど) を指定できます。チェックポイント・レコードがない場合は、アプリケーションを最初から再実行できるようにする必要があります。
• 通常どおり、配備計画用として資源消費情報を提供する必要があります。例えば、起動時および作業単位あたりのメモリー、I/O パターン、壁時計、CPU の使用状況などを提供します。これらの要件は、アプリケーションの配備担当者の経験を反映し、業界標準の詳細な文書形式で記載される必要があります。Globus Resource Specification Language (RSL) の定義済み属性や RSL Schema Documentationの要素 (参考文献 を参照) は、どのようなミドルウェア環境でアプリケーションを実行する場合であっても、最適な開始点および命名規則として利用できます。RSL を内部で使用しないグリッド・ミドルウェア製品の中には、RSL と独自の形式を関連付けるツールが用意されているものもあります。

特定のグリッド・ミドルウェアに対する非依存性

既存のほとんどのビジネス・アプリケーションは、特定のグリッド環境には依存しません。通常、グリッド・ミドルウェアはアプリケーションの実行に十分な機能を備えています。特定のグリッド・ミドルウェアに依存する必要があるビジネス・アプリケーションについては、シリーズの次の記事で説明する予定です。

戦略 1: ノード非依存バッチの要約

バックエンド・アプリケーション・コードをグリッド化するために必要な作業はほとんどありません。

• ライセンス交付: 通常、特にありません。最悪の場合は、各マシンにノードロック・ライセンスやドングルが必要になるため、組織によってはコストが法外に高くなる可能性があります。グリッド内のノードのサブセットにのみライセンスやドングルをインストールしている場合、そのライセンスやドングルは、RSL では資源として定義されます。そのため、その資源を所有していると定義されているノードにのみ、アプリケーションが送信されます。
• セキュリティー: 通常、特にありません。アプリケーションを実行できるユーザーやコンテンツにアクセスできるユーザーは、環境によって異なります。機密性の高い作業ファイルは、アプリケーションを実行するシェル・スクリプトで消去する必要があります。
• ノードの類似性: 特にありません。後続の実行において、適切な場所で適切なファイルが使用されるようにするのは、運用部門の責任です。
• ジョブ管理:特にありません。
• 単一サイトの LAN トラフィック:特にありません。
• 複数サイトの WAN トラフィック:特にありません。
• その他:特にありません。
• 特定のミドルウェアへの依存:特にありません。特定のミドルウェアに依存する状況は避けてください。これはデプロイヤーまたはインテグレーターの責任です。

上に戻る

戦略 2: 独立並行バッチ

この 2 番目の戦略は最初の戦略を拡張したものです。「戦略 2: 独立並行バッチ」では、同一ジョブ、例えば分析 A を、複数回並列して独立実行することができます。例えば、John が自分のデータを分析 A として実行しているときに、Jane が自分のデータを分析 A の別インスタンスとして実行する、ということも可能です。最初の戦略と大きく異なるわけではありませんが、いくつか注意点があります。

図 3 は、干渉せずに同時実行されている複数の独立インスタンスを示しています。

ライセンス交付

ライセンス・アプリケーションの場合は、ライセンス交付のモデルとテクノロジーによって、同時使用が許可されている必要があります。戦略 1 で説明された技法を除き、同時使用に基づくライセンス交付はオプションの場合があります。同時使用の対象には、マシン、プロセッサー、インスタンスなどが含まれます。

非干渉性

複数のインスタンスを同時に実行できる場合、各インスタンスが互いに干渉しないことが重要です。また、最初に起動されたインスタンスが最初に終了するとは限りません。ある実行から生じた出力や更新が他の実行結果を上書きしてしまう、といった状況は回避しなければなりません。トランザクションの資源を使用するときは、デッドロック・パターンを発生させないでください。

ホットスポットはややわかりにくい問題です。ここで問題になるのは、アプリケーションのインスタンスごとに頻繁に共通行が更新されるようなデータベース設計です。次のいずれかに当てはまるように、アプリケーションを変更する必要があります。

• 各インスタンスが別の行を更新する。
• インスタンスごとに頻繁に共通行が更新されるという状況を回避し、かつ長時間のロックを発生させない。

同時実行インスタンスで共通行を共有する場合は、アプリケーションの有効性と再起動性を慎重に検討してください。

• 増分する資源ディスペンサー (シリアル番号など)
• 乱数ジェネレーター
• シード・ディスペンサー

戦略 2: 独立並行バッチの要約

バックエンド・アプリケーション・コードをグリッド化するために必要な追加作業は、ほとんどありません。

• ライセンス交付:特にありません。最悪の場合、各マシンにノードロック・ライセンスやドングルが必要になります。
• 非干渉性:同一マシンまたは別のマシンで、同時に複数のコピーを実行できるようになります。

上に戻る

次の記事の内容

アプリケーションのグリッド化に関する 6 つの戦略、パート 3: 「戦略 3: 並列バッチ」と「戦略 4: サービス」 には、アプリケーションに「戦略 3: 並列バッチ」を実装し、単一ジョブの作業を複数の並列実行ジョブに分割して、その結果を単一ノードに集約する方法が示されています。「戦略 4: サービス」では、バッチ処理から離れて、クライアントとサーバーが疎結合されているサービス指向アーキテクチャーの実装方法を示します。

参考文献

• Must, can optionally, and should are used as in Key words for use in RFCs to Indicate Requirement Levels.
  
  
• WebSphere Information Integrator might help reduce the WAN traffic and client-side code.
  
  
• Find out the five models of the Open Group X-Open Software License Use Management (XSLM) Standard Licensing.
  
  
• The Redbook Enabling Applications for Grid Computing with Globus -- Chapter 3 Application Architecture Considerations provides background information.
  
  
• The Redbook Introduction to Grid Computing with Globus provides introductory information.
  
  
• The Redbook Fundamentals of Grid Computing provides basic information.
  
  
• License control software options such as License Use Management from IBM provide enforcement.
  
  
• Plan for any necessary provisioning and consider caching technology such as SAN File System from IBM or Data Grid from Avaki.
  
  

著者について

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.

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 戦略 1: ノード非依存バッチ
• 戦略 2: 独立並行バッチ
• 次の記事の内容
• 参考文献
• 著者について
• コメント