新技術により、WebSphere Extended Deployment Compute Grid が、ミッション・クリティカルなバッチ・ワークロードの処理用として理想的になる

次世代のエンタープライズ・グリッドとバッチ・コンピューティングのための基盤が登場

IBM WebSphere Extended Deployment Compute Grid は、ミッション・クリティカルなバッチ・ワークロード用のエンタープライズ・グリッドとバッチ処理のランタイム環境を提供します。この場合のバッチとは、一定時間内に膨大な量のデータを処理するタスクを意味しますが、世界を相手にするビジネスにとって、この時間は継続的に短くなっています。企業が必要とするのは、オペレーション制御、セキュリティー、高可用性、スケーラビリティー、信頼性、およびトランザクション型のデータ・アクセスであるため、エンタープライズ環境でのバッチ処理は大きな課題になる可能性があります。この記事では、エンタープライズ・アプリケーションの新しいアーキテクチャー技術を、Compute Grid がどのように組み合わせて、次世代のバッチ・システムを実現するかについて説明します。そうした新しいアーキテクチャー技術には、XTP (eXtreme Transaction Processing)、HPC (High-Performance Computing)、グリッド、およびユーティリティー・コンピューティングなどがあります。

この記事が対象とする読者は、ミドルウェア基盤について一般的な知識を持ち、Compute Grid がミドルウェア基盤に提供できる機能、利益、および影響を理解する必要のある、IT 意志決定者、技術アーキテクト、および技術戦略家です。またこの記事では、エンタープライズ・グリッド・コンピューティングが、XTP、HPC、グリッド、およびユーティリティー・コンピューティングと、どのように関連しているかについても学びます。この記事は IBM WebSphere Developer 開発者向け技術ジャーナルから引用したものです。

Snehal Antani, ISSW, WebSphere Extended Deployment Technical Lead, IBM

Snehal Antani は、IBM Software Services for WebSphere (ISSW) の SOA Technology Practice に所属しており、IBM WebSphere Extended Deployment の技術リーダーです。彼は、WebSphere z/OS、WebSphere XD-Distributed、WebSphere XD-z/OS などの製品を開発した経歴を持っており、また IBM で最大の WebSphere Distributed と z/OS の世界中の顧客の一部に、製品を送り出す支援を行ってきました。彼はエンタープライズ・アプリケーション基盤やグリッド・コンピューティングの分野で数件の特許を公開しており、また何本かの技術記事を発表しています。彼は Purdue University でコンピューター・サイエンスの学位を取得しており、またニューヨーク州 Troy の Rensselaer Polytechnic Institute (RPI) で、ミドルウェア基盤の耐障害性の定量化と改善についての論文でコンピューター・サイエンスの修士号を取得する見込みです。



2008年 4月 02日

はじめに

IBM WebSphere Extended Deployment は以下の 3 つのコンポーネントで構成されています。

  • Operations Optimization は、アプリケーションの仮想化、およびミドルウェア基盤の障害回復力を向上させる機能を提供します。
  • Compute Grid は、エンタープライズ・レベルのグリッド・コンピューティングとバッチ・コンピューティングのための基盤です。
  • Data Grid は、XTP (eXtreme Transaction Processing) スタイルのアプリケーションのためのキャッシングとデータ・アクセスの基盤です。

この記事では、Compute Grid 技術が、HPC (High-Performance Computing)、XTP (eXtreme Transaction Processing)、グリッド、およびユーティリティー・コンピューティングを、どのように組み合わせて、次世代のバッチ処理の基礎を形成するかについて説明します。


バッチ処理とは何か

バッチ処理は、エンタープライズ・アプリケーション基盤の基本的なコンポーネントです。この、バッチ処理というコンピューティング方式の目的は、一定時間内に膨大な量のデータを処理することですが、その時間は制限されており、しかも多くの場合短くなっています。バッチ・アプリケーションは対話型ではなく、OLTP (OnLine Transaction Processing) と同等のものです。OLTP では通常、クライアントまたはユーザーが端末で応答を待っています。

ビジネスは、バッチ・ワークロードの適切な実行に依存しています。例えば、銀行は次の営業日までに、当日のすべての金融活動を調整する必要があります。保険会社は、何テラバイトものデータを精査し、保険契約のリスク (そしてその結果としての代償) を数値化する必要があります。クレジットカード会社は、支払い請求期間の終わりに、何十万件もの口座に対して利子を計算する必要があります。金融機関は通常、クレジット・スコアの計算、請求レートの調整、取引明細書の送付、および報告書の生成等をする必要があります。これらの活動なしに、各ビジネスが機能することはできません。したがってバッチ処理は、ビジネスとその IT 基盤にとって、基本となるミッション・クリティカルなコンポーネントです。

SOA (Service Oriented Architecture) の重要なコンセプトは、企業全体にわたって資産を再利用することです。資産は OLTP ワークロードとバッチの両方で構成されています。J2EE とその他の類似技術の焦点は、OLTP の問題に対応することでした。しかし、これらの新たなミドルウェア技術を採用したことにより、バッチ処理アプリケーションは取り残され、バッチと OLTP は切り離されて別のサイロに入れられてしまいました。最近、Gartner が発表した研究 (「参考文献」を参照) では、SOA でのバッチ処理とその役割を取り上げており、「オンライン・トランザクションで使用されるビジネス機能は、バッチ処理で使用されるビジネス機能と同じである可能性があります。そのため、組織は IT の近代化戦略について考察し、SOA をアプリケーション統合のための標準メカニズムとして検討する必要があります。」と述べられています。今や重要な課題は、このように大きく異なってしまった 2 つの世界を効果的に再統合し、機動的で効率的な、そしてハイパフォーマンスのミドルウェア基盤をどのように実現するか、ということです。


Compute Grid のはじまり

バッチ処理に関する特定の問題を解決する新しいコンピューティング方式がいくつか登場しています。しかし、これらのコンピューティング方式を単独で使用しても、多くの場合、ミッション・クリティカルなバッチ・アプリケーションが必要とするエンタープライズ要件を満足できません。単純にデータを短時間で処理することだけがバッチの要件ではありません。既存のバッチ・システムの周辺には、途方もない数の基盤が既に構築されています。以下にその例を示します。

  • エンド・ツー・エンドのジョブ・フローを記述するオペレーション計画を持つジョブ・スケジューラー
  • 障害復旧手順
  • データ・ログに対するアーカイブと監査のメカニズム
  • チャージバックのためのリソース利用
  • OLTP による、ゴール指向の実行と並行実行
  • オペレーション制御
  • トランザクション型のデータ・アクセス

次世代のバッチ・システムは、高度なバッチの顧客の要件を考慮した上で、既存の基盤を最大限に活用する必要があります。その一方で、HPC、XTP、グリッド・コンピューティング、およびユーティリティー・コンピューティングなど新方式から得られたベスト・プラクティスや教訓も取り入れる必要があります。このように構築された新しい基盤は、将来の技術に適応し、容易に組み込める必要があります。この基盤の中でホストされるアプリケーションは、ツールやプログラミングに関する最新のベスト・プラクティスを活用する必要もあります。要するに、次世代のバッチ処理システムは、あらゆる種類や規模の顧客の要件を満足できるほど機動的でなければならないということです。

Compute Grid は、エンタープライズ・グリッドとバッチ処理の基盤を実現しますが、この基盤にはこれらのコンピューティング方式の重要なベスト・プラクティスがいくつか取り入れられています。さらに重要な点は、Compute Grid は、バッチに大きく依存する顧客との開発提携から、非常に大きな影響を受けていることです。図 1 に、Compute Grid に影響を与えた要素を示します。

図 1. Compute Grid のはじまりと、Compute Grid に影響を与えた要素
Compute Grid のはじまり

HPC と Compute Grid

Compute Grid には、2 つの重要な HPC パターンが取り入れられています。ディスパッチャー・ワーカー・パターンは、高度にスケーラブルなコンピューティング環境を実現します。分割統治パターンは、ハイパフォーマンスのためには不可欠です。

ディスパッチャー・ワーカー・パターン

ディスパッチャー・ワーカー・パターンには、2 つの重要なコンポーネントとして、ディスパッチャーと一連のワーカーがあります。ディスパッチャーの役割は、ある作業の実行を、一連のワーカーの間で管理することです。作業は、ワーカー・コンポーネントの中で実行されます。さらに作業がシステムに追加されると、ディスパッチャーは追加のワーカー・インスタンスを起動することによって、基盤を動的にスケール・アップします。図 2 に、ディスパッチャー・ワーカー・パターンのトポロジーを示します。

図 2. ディスパッチャー・ワーカー・パターン
ディスパッチャー・ワーカー・パターン

図 3 に、システムの負荷が増大した場合に、ワーカーのスケーリングが行われる様子を示します。

図 3. システムの負荷の増大に合わせて、ディスパッチャー・ワーカー・ベースの基盤をスケーリングする
ディスパッチャー・ワーカー・ベースの基盤のスケーリング

WebSphere Compute Grid のアーキテクチャーは、実際にはディスパッチャー・ワーカー・パターンをベースにしています。ディスパッチャー・コンポーネントは JS (Job Scheduler) と呼ばれ、ワーカー・コンポーネントは GEE (Grid Execution Environment) と呼ばれます。Job Scheduler も GEE も、マルチスレッドのアプリケーション・サーバーです。システムの負荷が増大すると、Job Scheduler は定められたサービス・レベル・アグリーメントを実現するために、追加の GEE を起動し、要求を満たします。Job Scheduler は、WebSphere Extended Deployment Operations Optimization の動的ロード・バランシング機能を活用し、クラスター内の GEE で利用できる能力、およびバッチ・ジョブに対するビジネス・レベルの実行目標に基づいて、バッチ・ジョブのロード・バランシングを行います。WebSphere Operations Optimization については、「グリッド・コンピューティングの影響」で学びます。

Job Scheduler へのジョブの送信には、Web サービス、JMS (Java Messaging Service)、EJB (Enterprise Java Bean)、シェル・コマンド、または組み込みのジョブ・コンソールを使用することができます。図 4 に、WebSphere Compute Grid のトポロジーと、ジョブ送信のチャネルを示します。

図 4. Compute Grid のトポロジー
Compute Grid のトポロジー

分割統治パターン

2 番目の HPC パターンである分割統治は、高並列実行としても知られています。このパターンを使用すると、大規模なタスクはまず多くの小規模なタスクに分解され、リソースの集合全体にわたって同時に実行されます。例えば、100,000,000 件のレコードを処理する 1 つのバッチ・ジョブは、1,000,000 件のレコードを処理する 100 個のジョブに分割され、そして同時に実行されます。タスクを完了するまでの経過時間は、分割サイズの関数 f(1,000,000) と、処理対象の全レコード数の関数 f(100,000,000) の対比になります。

Compute Grid の各バッチ・ジョブは、1 つのマネージ・スレッド上で実行されます。マネージ・スレッドとはメタデータが関連付けられたスレッドのことで、メタデータには、認証と認可用のセキュリティー・コンテキストや、データの完全性のためにアプリケーション・サーバーで使用されるトランザクション・コンテキストなどがあります。従って 100 個の並列ジョブは、マルチスレッドの GEE の集合全体にわたって 100 本のスレッド上で実行されます。この、マネージ・スレッドごとに 1 つのジョブ、という関係を (特に z/OS ユーザーは) 知っておくことが重要です。というのは、このモデルによって、バッチ・ランタイムが使用するリソースが最小になるからです。例えば、プロセスごとに 1 つのジョブを処理する方が、スレッドごとに 1 つのジョブを処理するよりも、はるかに多くのリソースを使用します。

また、このスレッド・モデルにより、マルチスレッドのバッチ・ジョブの複雑さが開発者から見えなくなります。バッチ・アプリケーションの開発者はスレッド・セーフなコードを作成して、1 つのスレッドで実行すればよいのです。Parallel Job Manager を使用することで、そのアプリケーションの複数のインスタンスをディスパッチすることができます。Parallel Job Manager (PJM) では、各パーティションがデータの異なる部分を処理します。他のソリューションでは、こうしたマルチスレッド・プログラミングの複雑さを、開発者が負担しています。

高並列バッチ処理での難題は、オペレーション制御であり、同時に実行されている多くのジョブの管理です。例えば、高並列バッチ・ジョブを停止するために、並列に実行されている何百、あるいは何千というジョブのそれぞれを管理者が手動で停止する必要はありません。その代わりに、管理者はより適切なオペレーション制御を使って、論理ジョブを停止すべきです。論理ジョブを停止すると、基盤が並列に実行されている多くのジョブを停止します。しかも、ジョブが完了すると、ツールを使用したり、管理者が手動でログを収集したりしなくても、生成された多くのジョブ・ログは基盤によって集約されるはずです。

Parallel Job Manager を使用する

Compute Grid には、PJM (Parallel Job Manager) と呼ばれる機能が含まれています。PJM を使用すると、大規模なジョブを多くの小規模なジョブに分解するためのルールを定義することができます。そうしたルールを PJM にインストールすると、PJM はそのルールを使って大規模なジョブを分解し、オペレーションを制御することができます。図 5 に、PJM を含む Compute Grid の基盤と、PJM での一般的な実行フローを示します。以下に示す一連の図は、PJM によるオペレーション制御のタイプを示しています。

図 5. PJM (Parallel Job Manager) での一般的な実行フロー
PJM (Parallel Job Manager) での一般的な実行フロー

PJM を使用する場合の一般的なワーク・フローは以下のとおりです。

  1. 大規模な 1 つのジョブが、Compute Grid のジョブ・ディスパッチャーに送信されます。
  2. Job Scheduler は、そのリクエストを PJM に渡し、PJM は指定されたパーティション・ルールを使って大規模なジョブを多くの小規模なパーティションに分割します。
  3. PJM は、これらのパーティションを GEE クラスター全体にディスパッチします。
  4. GEE クラスターは、チェックポイント、ジョブ再起動、トランザクション管理、およびセキュリティーなどに関するサービス品質を適用して、ジョブ・パーティションを実行します。

図 6 に、多くの並列バッチ・ジョブを PJM によってモニタリングする場合のフローを示します。

図 6. 高並列バッチ・ジョブをモニタリングする
高並列バッチ・ジョブをモニタリングする

高並列バッチ・ジョブをモニタリングするためのステップは以下のとおりです。

  1. 多くの並列ジョブの実行ステータスが一連の GEE から PJM にレポートされます。
  2. PJM はそれらのステータス・データをデータベース・テーブルに永続化します
  3. 管理者またはジョブ送信者は、論理ジョブ (ジョブ・パーティションの集合的な要約を意味します) の進行状況をモニタリングします。

図 7 に、論理ジョブの停止、再起動、およびキャンセルなどのコマンドの実行フローを示します。

図7. 論理ジョブとその論理ジョブに含まれる多くのジョブ・パーティションの停止/再起動/キャンセル
図7. 論理ジョブとその論理ジョブに含まれる多くのジョブ・パーティションの停止/再起動/キャンセル

論理ジョブに対してコマンドを実行するための手順は以下のとおりです。

  1. 送信者は、いくつかあるチャネルの内の 1 つを使用して、論理ジョブの停止コマンド、再起動コマンド、またはキャンセル・コマンドを Job Scheduler に発行します。
  2. PJM は、その論理ジョブと関連付けられたジョブ・パーティションはどれかを判断します。
  3. PJM は、その論理ジョブと関連付けられたジョブ・パーティションそれぞれに対し、上記のコマンドを発行します。

図 8 に、ジョブ・パーティションに対するジョブ・ログが PJM によって集約されるフローを示します。

図 8. ジョブ・パーティションに対するジョブ・ログを集約する
ジョブ・パーティションに対するジョブ・ログを集約する

ジョブ・ログの集約は、以下のように行われます。

  1. PJM は、その論理ジョブと関連付けられたジョブ・パーティションがどれかを判断し、各パーティションのジョブ・ログを取得します。
  2. 次に PJM は、多くのジョブ・ログを単一のログに集約します。
  3. ジョブ・ディスパッチャーは、その単一のジョブ・ログを、送信者がアクセスできる場所に格納します。

XTP の影響

XTP スタイルのアプリケーション分野は広範にわたっており、常に進化しています。この記事では、XTP 分野における多くの重要な原則の 1 つである、可能な限りデータをビジネス・ロジックに近づけるという原則に焦点を絞ります。

この原則を実現するためには、以下を実装する必要があります。

  • N 階層キャッシング基盤全体にわたる積極的なキャッシング
  • 対応するデータにワーク・リクエストをインテリジェントにルーティングする、アフィニティー・ルーティング
  • map-reduce パターンをメモリー内データベースと組み合わせて実現する、データ・アクセス遅延時間の短縮

対応が必要な課題は無数にありますが、以下にその例を示します。

  • 失効キャッシュ・データの無効化と更新されたキャッシュ・データの複製の、N 階層キャッシュ全体にわたる調整。
  • データ・サーバーのリソース使用状況 (メモリー、CPU など) に基づく、データの動的な再パーティションニング。
  • キャッシュ・ヒットを最大化する、データのパーティショニング方法の検討。

バッチ・コンピューティングでは、ビジネス・ロジックとデータの近さが大きくパフォーマンスに影響します。データがビジネス・ロジックに近ければ近いほど、ワークロードの実行時間は短縮されます。データとビジネス・ロジックの近さを変える方法には、以下の 2 つがあります。

  • データをビジネス・ロジックに近づけます。これは、キャッシングとアフィニティー・ルーティングによって実現することができます。
  • ビジネス・ロジックをデータに近づけます。これは、データとビジネス・ロジックを同じサーバーまたはプラットフォームに一緒にデプロイすることによって実現することができます。例えば、分散プラットフォームの場合には map-reduce をメモリー内データベースと組み合わせます。System z の場合にはエンタープライズ・データへアクセスできるように一緒にデプロイします。

XTP 分野とバッチの間には、概念と技術の両面で自然な相乗効果があります。Compute Grid は XTP 分野の技術や方式を、いくつかの方法で活用しています。前述の第 1 の方法 (データをビジネス・ロジックに近づける) では、N 階層のキャッシング基盤を定義し、そのキャッシング基盤を GEE に関連付けることができます。図 9 に、Data Grid を使用している、このトポロジーを示します。

図 9. N 階層キャッシングを用いて、データをビジネス・ロジックに近づける
N 階層キャッシングを用いて、データをビジネス・ロジックに近づける

第 2 の方法 (ビジネス・ロジックをデータに近づける) では、データと同じプラットフォーム上にビジネス・ロジックをホストします。これは通常、System z や System p などの「大型コンピューター」のハードウェアと関係しています。System z にデータがホストされる場合、同じハードウェア上にホストされているアプリケーションの方が、リモート・システム上にホストされているアプリケーションよりも、データ・アクセスの遅延時間が小さくなります。図 10 に、WebSphere Application Server for z/OS 内に、Compute Grid をどのように取り入れるかを示します。

図 10. WebSphere for z/OS を用いて、ビジネス・ロジックをデータに近づける
WebSphere for z/OS を用いて、ビジネス・ロジックをデータに近づける

ビジネス・ロジックとデータとを近づけるどちらの方法にも、アフィニティー・ルーティングを適用することができます。アフィニティー・ルーティングでは、データはパーティションに分割され、複数の場所 (Java 仮想マシン、データベース等) にホストされます。ディスパッチャーはデータのパーティションと場所を認識しています。またディスパッチャーは、大規模なリクエストの分解先となるワーク・パーティションや、各ワーク・パーティションに必要とされるデータも認識しています。そしてワーク・パーティションは、そのワーク・パーティションに対応するデータ・パーティションをホストしている場所にディスパッチされます。図 11 に、分散プラットフォームでのアフィニティー・ルーティングを示します。

図 11. 分散プラットフォームでの、Compute Grid と Data Grid によるアフィニティー・ルーティング
分散プラットフォームでの、Compute Grid と Data Grid によるアフィニティー・ルーティング

図 12 に、z/OS でのアフィニティー・ルーティングを示します。

図 12. z/OS での、Compute Grid と DB2 によるアフィニティー・ルーティング
z/OS での、Compute Grid と DB2 によるアフィニティー・ルーティング

アフィニティー・ルーティングを効果的に使用するためには、基本的なデータ・モデルとワークロード・パターンを十分に把握しておく必要がありますが、この方法によって、大幅にパフォーマンスを向上させることができます。ワーク・パーティションとデータ・パーティションとを対応させることで、サーバー内でのキャッシュ・ヒットの確率を高め、また大きな遅延時間が発生するデータベースへのリモート・アクセスを減らすことができます。図 13 から 15 に、キャッシュのヒット率の増加によるメリットを定量モデルで示します。定量モデルを使用すると、ニア・キャッシュのヒット率の増加が平均データ・アクセス時間に与える影響をシミュレートすることができます。

図 13. N 階層キャッシング構造でのデータ・アクセス時間をモデリングするための定量モデル
N 階層キャッシング構造でのデータ・アクセス時間をモデリングするための定量モデル

図 13 の定量モデルは、N 階層キャッシュの各階層に対する確率の分布とサービス・レートを指定した場合の、平均データ・アクセス時間の計算方法を示しています。この場合、このキャッシュには以下の 3 つの階層があります。

  • ニア・キャッシュ (ビジネス・ロジックと同じ JVM にホストされるキャッシュ)
  • Data Grid Server のキャッシュ (ビジネス・ロジックを実行する JVM の近くにある、オブジェクト・サーバーのキャッシュ)
  • データベース (通常はアクセス時間が最も長い)

データ・アクセス時間を計算するには、ニア・キャッシュの中、サーバーのキャッシュの中、およびデータベースの中にデータが存在する確率を知る必要があります。この確率情報を使用して、データ・アクセス時間をモデリングして計算することができます。

図 14 の具体的な例を考えてみましょう。この例では、データの 30% がニア・キャッシュに、70% がオブジェクト・サーバーのキャッシュにあり、そして残りのデータはデータベースから取得されます。計算の結果、データ・アクセス時間の見積もりは、約 47 ms となります。

図 14. N 階層キャッシング構造でのデータ・アクセス時間をモデリングするための具体的な定量モデルの例
具体的な定量モデルの例

図 15 の例では、データがニア・キャッシュに存在する確率が 2 倍になっています。これを実現するためには、ニア・キャッシュのサイズを増やすか、あるいはアフィニティー・ルーティングを確立し、同等のリクエストを同じサーバーとキャッシュに送信します。ニア・キャッシュ内のキャッシュ・ヒット率を上げた効果として、データ・アクセス時間が 42% 改善されています。

図 15. ニア・キャッシュのサイズ増加、またはアフィニティー・ルーティングによって、ニア・キャッシュのヒット率を上げることで、平均データ・アクセス時間を短縮する
ニア・キャッシュのヒット率を上げる

PJM (Parallel Job Manager)、N 階層キャッシング構造、およびアフィニティー・ルーティングを組み合わせることにより、強力でハイパフォーマンスの計算グリッドを実現することができます。PJM は、大規模なワーク・リクエストを小規模なパーティションに分割します。これらの小規模なパーティションは、ニア・キャッシュ内のデータの場所と調和する方法で分割されます。次にジョブ・ディスパッチャーはジョブ・パーティションをインテリジェントにディスパッチし、データが既にメモリーにロードされているグリッド・エンドポイントで各ジョブ・パーティションが実行されるようにして、キャッシュのヒット率を高めます。

XTP スタイルのアプリケーションを実現する基礎技術は、ハイパフォーマンスのシステムにとって不可欠のコンポーネントです。特に、バッチ処理の場合には重要です。バッチ処理ではアプリケーションが、短くなりつつある一定時間内に大量のデータを処理する必要があるからです。また、データの場所、およびビジネス・ロジックが実行されるプラットフォームの場所は、データ・センターに XTP 技術を採用する方法に影響を与えます。

グリッド・コンピューティングの影響

グリッド・コンピューティングという用語は、多重定義されてきました。一部の人達にとって、グリッド・コンピューティングは、SETI@Home やその他の科学計算イニシアチブに類似したアーキテクチャー・パターンを意味します。このアーキテクチャー・パターンでは、適切に定義されたデータ・パケットがビジネス・ロジックと一体化され、デスクトップ・パソコンなどのシステムにディスパッチされます。そして、それらのシステム上で、利用可能な CPU サイクルのすべてが利用されます。こうしたグリッド環境では、何万ものノードをビジネス・ロジックの実行に使用することができ、サービス品質を最低限に抑え、また確実に計算が完了するように、同じ作業を複数マシンにディスパッチさせるという冗長性を持ちます。一般に処理対象のデータは機密ではなく、そのためセキュリティー要件は最低限であり、またトランザクション型のデータ・アクセスは例外的です。これらのモデルは途方もない規模にスケール・アップできるように設計されています。

企業の中では、データ・アクセスは、適切に制御されており、多くの場合トランザクション型であり、ビジネス・ロジックの実行に使用可能なリソースは有限です。そして、リソースの管理とモニタリング、および監査用の実行ログの管理等に関して、厳しいオペレーション要件があります。エンタープライズ・グリッド・コンピューティングは、科学計算用のグリッド・コンピューティングの手法をエンタープライズ・アプリケーションの基盤と融合し、セキュアでトランザクション指向、管理しやすく、そして高度にスケーラブルなグリッド実行環境を提供します。

Compute Grid は、エンタープライズ・グリッド・コンピューティングのランタイムです。Compute Grid は、高度にスケーラブルなグリッド・エンドポイントの集合に対する、オペレーション制御と管理のための機能を提供しますが、それと同時にセキュリティー、効率的なリソースの管理、およびトランザクションの整合性など、先ほど説明したエンタープライズ指向の要件を実施することができます。

ユーティリティー・コンピューティングの影響

ユーティリティー・コンピューティングの分野に含まれるものには、サービスのプロビジョニング、使用されたシステム・リソースのモニタリング、およびビジネス・レベルの目的の実施があります。ユーティリティー・コンピューティングはメインフレームに不可欠のものでしたが、現在は分散コンピューティングの新たな領域となっています。Compute Grid は、ユーティリティー・コンピューティングの多くの機能を取り入れています。特に重要な機能として、Compute Grid には以下が含まれています。

  • ゴール指向の実行環境。この環境のビジネス・レベルのサービス・アグリーメントによって、ビジネス・ロジックの実行優先順位が指示されます。
  • リソースの使用状況把握とモニタリング。これにより、ビジネス・ロジックによって使用されたリソースを定量化することができ、使用されたリソースの正確な量に基づいて、ビジネス・ロジックの所有者に課金することができます。

メインフレームでは、Compute Grid は z/OS ワークロード・マネージャー (zWLM) と統合され、これらの機能を提供します。Compute Grid のバッチ・ジョブは、zWLM のトランザクション・クラスや zWLM のサービス・ポリシーと関連付けることができます。そして zWLM は、z/OS オペレーティング・システムと連携動作することにより、ハードウェアとソフトウェアの割り当てを管理し、サービス・ポリシーを確実に実現させます。何らかのサービス・ポリシーを実現するために、追加のリソースが必要となった場合には、zWLM は例えば、追加のアプリケーション・サーバー・プロセスを動的にプロビジョニングしたり、あるいはバッチ・ジョブをディスパッチする優先順位を動的に調整し、CPU で実行される時間を長くしたりすることができます。

zWLM を利用できない分散プラットフォームでは、Compute Grid は WebSphere Operations Optimization と連携動作し、同様の機能を提供します。Operations Optimization は、ビジネス・レベルのサービス・ポリシーを強制したり、リソースの集合の中で追加のサーバー・インスタンスを動的にプロビジョニングしたり、また詳細な使用レポートにチャージバック用の統計データを提供したりすることができます。

ユーティリティー・コンピューティングにより、サービスとしてのソフトウェア・モデルが実現可能になります。図 16 に、サービスとしてのバッチの例を示しています。この例では、Compute Grid の基盤を使用して多様なクライアントのためにバッチ・ジョブを実行し、リソースの使用状況を追跡してチャージバック・データを提供しています。コスト・センターであったはずの基盤が突然、企業にとってのビジネス・モデルの一部となります。

図 16. Compute Grid がユーティリティー・コンピューティングの方式を活用し、データ・センターがサービスとしてのバッチを提供することを可能とする
Compute Grid がユーティリティー・コンピューティングの方式を活用する

この、サービスとしてのバッチの例のフローは以下のとおりです。

  1. 小規模な銀行が、データ・センターにホストされている Job Scheduler へリクエストを送信します。
  2. Job Scheduler は、各銀行に対するワークロードを実行し、各銀行のジョブで使用されたリソースの量を正確に記録します。分散プラットフォームの場合、この機能は Operations Optimization を使用して、リソースの量を統合することで実現されます。z/OS プラットフォームの場合には、zWLM、RMF、および z/OS のそれ以外のシステム機能による使用状況集計機能が活用されます。
  3. 月末になると、データ・センターは、CPU 使用時間の正確な秒数を基に、提供したサービスに対する請求を各銀行に送信します。

顧客との協力と提携

エンタープライズ・グリッド・コンピューティングは、特に銀行やデータ・ウェアハウス、保険などの業界の顧客にとって、重要なコンピューティング方式として登場しつつあります。Compute Grid は登場して間もなく、エンタープライズ・グリッド・コンピューティングのための堅牢なランタイムへと発展しました。その背景には、それらの業界の中で技術採用に積極的な企業との間に築かれた、強力な連携、協力関係があります。これらの業界の顧客は、オペレーション制御、監査手法、アーカイブ手法、スケーラビリティー、ユーティリティー・コンピューティング、高並列ジョブの実行、および外部スケジューラーとの統合に対して、共通の経験、要件、および期待を持っています。

例えば、多くの企業顧客は、既にエンタープライズ・スケジューラーを使用しています。そのため、Compute Grid を既存のエンタープライズ・スケジューラーと統合するという要件に交渉の余地はありません。これらの顧客は、Compute Grid の中でオペレーション・プランを定義し直すことを望んではいません。同様に、Compute Grid の目的はビジネスのスケジューリングではありません。その代わりに、ビジネス・レベルのサービス・アグリーメントを確実に達成しながら、バッチ・ワークロードとグリッド・ワークロードを短時間で実行することに焦点を絞っています。

エンタープライズ・グリッド・コンピューティングの基礎として Extended Deployment を使用する

WebSphere Extended Deployment の 3 つのコンポーネント (Operations Optimization、Data Grid、および Compute Grid) は、個別に使用することもできますが、3 つを統合することで、スケーラブルで耐障害性の高い、ハイパフォーマンスのグリッド・コンピューティング・プラットフォームを実現することができます。図 17 に、WebSphere Extended Deployment の 3 つのコンポーネントをすべて組み込んだアーキテクチャーを示します。

図 17: エンタープライズ・グリッド・コンピューティングの基礎としての WebSphere Extended Deployment
図 17: エンタープライズ・グリッド・コンピューティングの基礎としての WebSphere Extended Deployment

この統合では以下が実施されます。

  1. Job Scheduler 層は、Compute Grid コンポーネントの一部であり、新たに送信されたジョブを受け付け、それらのジョブをエンドポイントにディスパッチし、ジョブに対するオペレーション制御を行います。
  2. Parallel Job Manager 層も、Compute Grid コンポーネントの一部であり、大規模なジョブを小規模なパーティションに分割し、クラスター全体にわたって実行されるパーティショニングされたジョブに対してオペレーション制御を行います。
  3. Grid Execution 層は、Compute Grid と Data Grid の両方の技術で構成されており、バッチ・ジョブを実行します。Data Grid のニア・キャッシュは、パフォーマンスを高める N 階層キャッシング基盤へのエントリー・ポイントです。
  4. Data Server 層は、Data Grid の一部であり、パフォーマンスを高めるために、メモリー内にオブジェクトをキャッシュして、データベースへのアクセスをバッファリングしています。
  5. On-Demand Router (ODR) は、Operations Optimization の一部であり、ゴール指向の実行環境、サーバー・リソースの動的プロビジョニング、およびヘルス管理を提供します。

まとめ

コンピューティング方式である、HPC、XTP、グリッド、およびユーティリティー・コンピューティングは、それぞれ単独でも、エンタープライズ・コンピューティングにとって優れたメリットを提供します。しかし、これらのコンピューティング方式を適切に組み合わせることで、企業が要求するサービス品質に対応可能な、真にスケーラブルでハイパフォーマンスのシステムを実現することができます。Compute Grid は、これらのコンピューティング方式の機能を統合し、Operations Optimization と Data Grid とも連携動作することで、ミッション・クリティカルなバッチ・アプリケーションを実行するための基礎を提供します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=603269
ArticleTitle=新技術により、WebSphere Extended Deployment Compute Grid が、ミッション・クリティカルなバッチ・ワークロードの処理用として理想的になる
publish-date=04022008