レベル: 初級 Marlon Machado (mmachado@us.ibm.com), e-business Architect, IBM
2005年 6月 22日 アプリケーションのグリッド化に関する 6 つの戦略に精通している場合は、最初の 3 つの戦略のいずれかを既存アプリケーションに適用できます。この記事では、プラットフォーム固有の分散アプリケーション (一体型とモジュール型の両方) および Web 対応アプリケーション (サーブレット中心型とデータベース中心型の両方) をグリッド化する際に考慮すべき事項について説明します。
はじめに
この記事で説明する技法を使用する前に、まず以下の一連の記事で説明されている、アプリケーションのグリッド化に関する 6 つの戦略について十分に理解しておく必要があります。
この記事ではまず、既存のコードをグリッド化する場合のほとんどに当てはまる、基本的なアーキテクチャー・パターンを紹介します。次に、長年の経験の中において最も一般的なアーキテクチャーに基づいて、既存のコードをグリッド化する際のいくつかの戦略について説明します。プラットフォーム固有の分散アプリケーションの 2 つの基本シナリオを紹介し、各シナリオのアーキテクチャーの最も一般的なバリエーションと、それらのアーキテクチャーをグリッド化パターンに当てはめるための一般的な方法について検討します。最後に、Web 対応アプリケーション (サーブレット中心型とデータベース中心型) のシナリオを 2 つ紹介します。
パターンの存在
バッチ指向グリッド・インフラストラクチャー・ソフトウェアを使用したグリッド化作業の多くはよく似ているので、特定のパターンに沿って作業を進めることができます。このようなパターンを使用すれば、グリッド導入の最初の 3 つの戦略を実現することができます。
これらの 3 つのグリッド導入戦略の基本ケースとなるのは、コマンド行パラメーターを取得してそのコマンド行パラメーターで指定されたファイルまたはデータベースを使用するというプログラムです。ライセンス交付プログラムの場合、グリッド・インフラストラクチャーにはライセンス管理機能が必要となります。
一般に、既存のアプリケーションをグリッド上で動作可能にするための最初の 3 つの戦略では、ユーザーはクライアント・アプリケーションに対して要求を送る必要があります。要求を受け取ったクライアント・アプリケーションは、グリッド・インフラストラクチャーに対するリクエスターの役割を果たします。クライアント・アプリケーションに対するクライアントは、実際のユーザーの場合もあればポータルの場合もあります。グリッド・インフラストラクチャーが実際のアプリケーションを配備し、アプリケーションがグリッド・インフラストラクチャーに対するプロバイダーになります。（図 1を参照）
図1. Integration pattern for enabling existing code
ここで重要なのは、クライアント・プログラム (ジョブ送信ドライバー) は、あたかもアプリケーションと直接対話しているかのように、グリッド・インフラストラクチャーと対話する必要があるということです。これを最も簡単に実現する方法は、クライアント・プログラムから仮想化アプリケーションにコマンド行タイプの命令を発行させることです。
最小限の配備要件を満たすだけでよいスタンドアロン・プログラムのアプリケーションの場合、このシナリオの実装は容易です。しかし、統合アプリケーションを扱う場合には、全体的に若干の創造性が必要となる可能性があります。
既知のシナリオ
今日のソフトウェア業界の状況では、バッチ指向グリッド・インフラストラクチャー・ソフトウェアを使用して既存のコードをグリッド化するシナリオは、すでに知られているいくつかのものに限られています。具体的には、以下の 2 つのシナリオが存在し、両者とも基本的に同じタイプのアプリケーションを利用します。
- プラットフォーム固有の分散アプリケーションのグリッド化。これには、Web アプリケーションが存在する以前に作成された、クライアント/サーバー・アプリケーション、トランザクション・アプリケーション、およびバッチ指向アプリケーションが該当します。
- Web 対応アプリケーションのグリッド化。これには、Web アプリケーションとして動作するように Web 用の「フロント・エンド」または「ラッパー」を付加された、プラットフォーム固有の分散アプリケーションが該当します。たいていの場合、その統合戦略には、サーブレット中心型またはデータベース中心型のアプリケーションのグリッド化が必要になります。
プラットフォーム固有の分散アプリケーションのグリッド化
すでに述べたように、このシナリオは、クライアント/サーバー・アプリケーション、トランザクション・アプリケーション、およびバッチ指向アプリケーションに適用されます。これら 3 種類のアプリケーションでは、一体型とモジュラー型という 2 つのアーキテクチャーが主流です。
一体型アプリケーションの場合
一般に、バッチ指向グリッド・インフラストラクチャー・ソフトウェア上にプラットフォーム固有の一体型アプリケーションを配備する作業は、すべてのグリッド・ノード上にアプリケーションをインストールし、ユーザー要求、パラメーター渡し、およびグリッド・インフラストラクチャーからのプログラム呼び出しを統合する「グルー・コード」を作成するだけの単純なものです。
図2. Deploying monolithic applications using the standard enablement pattern
この「グルー・コード」によって、作業は統合ジョブになります。たいていの場合、一体型アプリケーションとバッチ指向グリッド・インフラストラクチャー製品は、スクリプトを介して統合できます。Perl、Python、または汎用のシェル・スクリプトを使用すると、グリッド・インフラストラクチャー・ソフトウェアのコンテキストの中で、ユーザー要求、パラメーター渡し、およびアプリケーション呼び出しを統合できます。
注意事項
一体型アプリケーションの機能とその動作については、注意すべき点があります。一体型アプリケーションには、すべてのユーザーにすべての機能を提供しようとする傾向があります。これが、このアプリケーションが一体型と呼ばれる理由の 1 つです (モジュールを信頼しない人もいます)。問題となるのは、一体型アプリケーションにグリッド機能が埋め込まれている場合です。埋め込まれたアイテムとグリッド機能の実装方法により、グリッド上でそのアプリケーションを実行できるかどうかが決定されます。
例えば、内蔵のグリッド・インフラストラクチャー機能を一切持たない一体型アプリケーションは、そうでないものよりもグリッド化が容易です。例として、同様のアプリケーションでありながら、本来想定されている機能に加えてスケジューリング機能 (どのインスタンスが何の要求を処理するか、所定のユーザーについてどのデータベース表をロックする必要があるか、トランザクション親和性をいつ適用する必要があるかなど) を持つアプリケーションを挙げることができます。さらに、内蔵機能の実装方法についても調べる必要があります。
内蔵のグリッド機能をアプリケーション内で停止できる場合、その一体構造のコードは、バッチ指向グリッド・インフラストラクチャー・ソフトウェア上で問題なく実行できます。一方、グリッド機能がアプリケーションの深い部分に組み込まれていて停止できない場合には、問題が生じます。
一般に、内蔵のグリッド・インフラストラクチャー機能を停止させるために必要な作業量は非常に大きなものです。当時のプログラマーは、コードの再利用方法を学ぶときに、機能を上下両方向に移動させることも学びました。ビジネス・ロジックのフレームワークへのグリッド・インフラストラクチャー機能の埋め込みは、下方向への機能の移動の一例です。
プログラマーがこの方法を採用したからといって、彼らを非難することはできません。多くのプラットフォーム固有の分散アプリケーションが開発された頃、グリッド・コンピューティングのことを考慮していた人はほとんどいませんでした。当時は、独自に開発したアプリケーションを既製のコンテナーに収容できるなどということは誰も思いつかず、まして、コードを展開するだけでそのコードに対応するような完全なグリッド・インフラストラクチャーの存在など、思いもよらないことでした。
モジュール型アプリケーションの場合
一般に、プラットフォーム固有のモジュール型分散アプリケーションのグリッド化は、一体型アプリケーションのグリッド化より容易です。これは、モジュール型アプリケーションでは、アプリケーションの配備方法を選択できるからです。一体型アプリケーションの場合と同様の注意は必要ですが、モジュール型アプリケーションには、簡単に問題を回避する方法があります。
モジュールの停止
モジュール型アプリケーションが持つ大きな利点は、必要に応じてモジュールを停止できる可能性にあります。アプリケーションとグリッド・インフラストラクチャーの双方が同種の機能を提供し、競合する場合、（アプリケーション側で競合機能を提供している）モジュールを停止して、その（environment-relatedな）機能はグリッド・インフラストラクチャー側で実現することができます。
一体型アプリケーションの場合と同様に、グリッド化作業の難易度は、内蔵のグリッド機能の存在やその機能を停止または除去できるかどうかによって決定されます。
異なるのは、大部分のモジュール型アプリケーションでは内蔵のグリッド機能があってもその機能が単一のモジュールや特殊なモジュールのグループに集中していることが多い、という点です。そのため、これらのモジュールは (理論上) 比較的簡単に停止または一括除去することできると考えられます。
2 つ目の注意事項
2 つ目の注意事項は、モジュール間通信についてです。アプリケーション・モジュールを停止または除去する際の難易度は、設計者によるモジュール間通信の実装方法によって決まります。一般に、トランスポート・メカニズムが単純であればあるほど、難易度は低くなります。
例えば、この種のアプリケーションでは、すべてのデータベース呼び出しを取り扱うための専用モジュールがあるのが普通です。場合によっては、このモジュールが複数のベンダー用の ODBC ドライバーや JDBC のドライバーをサポートすることによって汎用データベース・クライアントの役割を果たすだけでなく、「表アクセス・スケジューリング」と呼ばれる機能を実行していることがあります。この機能は、アプリケーションがデータベースとは無関係に表ロックを取り扱うことを可能にする、一種のアプリケーション内表ロック・メカニズムです。
汎用のデータベース・クライアントを装備するのは確かによいアイデアです。ただし、アプリケーションをグリッド化するのであれば、表ロックは (現在はアプリケーションで行っていると仮定すると) データ・グリッド・インフラストラクチャーに任せてしまった方がよいでしょう。そこで必要となるのは、問題のモジュールを普通のデータベース・クライアントに置き換えて、RDBMS をデータ・グリッド内に配備するという作業です。これにより、グリッド対応アプリケーションを完成させることができます。
大部分のデータベース・クライアントおよびデータベース・リスナーは、TCP/IP ソケットに依拠してプログラムからの命令を取得します。例えば、DB2R クライアントは、デフォルトでポート 50000 をリスンします。ところが、アプリケーション設計者が、この実証済みの TCP/IP ソケットに依拠する方法を自作のアプリケーションにそのまま使ったのではつまらないと判断する場合があります。また、設計者がモジュール間通信に独自仕様のメカニズムを使おうと決める可能性もあります。このような場合、問題は単純には解決できません。
さらに、モジュール間通信には別の側面があり、それが非常に大きな問題に発展する可能性があります。アプリケーションを計算グリッド上に配備すると、グリッド上では複数のモジュールの複数のインスタンスが並行して動作します。グリッド・インフラストラクチャー・ソフトウェアがトランスポート・、メカニズムを中継できなくなったり、あるいはトランスポート・メカニズムそのものがグリッド環境で正しく動作できなくなったりすると、アプリケーションは期待どおりに動作しなくなります。
こうなると、グリッド化プロジェクトを成功させるためには、モジュール間通信メカニズムを取り替える必要がでてきます。
配備戦略 :ベスト・シナリオ
理想的なモジュール型アプリケーションでは、ディスパッチャー・モジュールまたはブローカー・モジュールを使用してモジュール間通信を処理します。モジュール間通信は必ずブローカー経由で行われるため、このプランでは、グリッド上でのモジュールの配置場所は問題になりません。（図 3 を参照）
図3. Ideal deployment for modular applications
ベスト・シナリオには、次の 2 つの要件が要求されます。まず、各モジュールを互いに独立して配備できるように、アプリケーションのモジュールが atomiｃ されている必要があります。そうすれば、すべてのモジュール間通信とデータ交換は、ディスパッチャー/ブローカー・モジュールによって処理できます。
共有ライブラリーについては、システム全体にわたるインストールの一部である場合は、グリッド・インフラストラクチャーで処理できる必要があります。できない場合でも、共有ライブラリーを全モジュールのプロビジョニング・ポリシーの一部として組み込めば、すべのノードにローカル・コピーを持つことができます。
次に、アプリケーションの各モジュールには、同一モジュールの複数のインスタンスを (少なくとも) 同一マシン上で並行して実行できる程度の粒度が必要です。モジュール別の結果の集約は、それぞれのモジュールで行います。アプリケーション・レベルの結果集約は、ディスパッチャー/ブローカー・モジュールによって、またはデータベースを介して処理することができます。
配備戦略 :最も一般的なシナリオ
残念ながら、大部分のモジュール型アプリケーションは、ベスト・シナリオのように理想的には動作しません。ときには、モジュールのカプセル化が不完全で、真の独立した配備を実現できるほどatomicでない場合があります。また、ディスパッチャー/ブローカー・モジュールがすべてのモジュール間通信とデータ交換を処理しない場合もあります。その代わりに、一部のモジュールでは互いを直接呼び出しています。このようなモジュールは、（グリッド化した場合でも）同一マシン上に配置しなければなりません。
結果の集約についても、特にディスパッチャー/ブローカーがモジュール間通信の管理作業を全面的に担当していない場合には、問題が生じます。一部のモジュールが、結果を単にブローカーに戻すのではなく、他のモジュールに渡しているケースもあります。状況がどうであれ、最も一般的なシナリオでは、図 4 に示すようにすべてのグリッド・ノード上にアプリケーション全体を配備します。
図4. Most common scenario for deploying modular applications
最も一般的なシナリオを見てわかることは、モジュール型アプリケーションは最悪の場合には一体型アプリケーションとして配備できるということです。その場合、アプリケーションは動作しますが、理想のケースのようにグリッド・インフラストラクチャーによって有効に活用されることはないので、モジュール型であることの利点は失われます。
同様に、複数の並行インスタンスのケースにおける結果集約を管理するための戦略を立てる場合には、一体型アプリケーションを単一のモジュールで構成されるモジュール型アプリケーションと見なして、扱うことができます。
ここに説明した一体型アプリケーションとモジュール型アプリケーションの 2 種類のケースは、プラットフォーム固有の分散アプリケーションをグリッド化する場合の最もシンプルなシナリオと言えます。Web 対応アプリケーションを取り扱う場合には、状況はまったく異なります。それについては、次のセクションで説明します。
Web 対応アプリケーションのグリッド化
Web 対応アプリケーションは、真の J2EE アプリケーションではありません。元々はプラットフォーム固有の分散アプリケーションとして開発されにもかかわらず、Web フロント・エンドのおかげで Web アプリケーションとして動作するようになったアプリケーションのことを、「Web 対応」と呼んでいます。
最も一般的なアーキテクチャーは「サーブレット中心型」および「データベース中心型」と呼ばれるもので、グリッド化に関しては、それぞれ独自の問題があります。
サーブレット中心型アプリケーション
サーブレット中心型アプリケーションのアーキテクチャーは、一般に、図 5 に示すパターンに準じています。
図5. Most common Servlet-centric architectural pattern
図 5 に示したプラットフォーム固有アプリケーションは、場合によっては、XML やその他のテクノロジーをサポートするようにパッチが当てられています。また、JNI または独自仕様のコネクター・フレームワークを介して Java 仮想マシンと対話できるようになっています。データベースのサポートに関しては、ODBC-JDBC ブリッジを使用するか、そのまま ODBC を使用するのが一般的です。
J2EE アプリケーション・サーバー上で動作するように「移植」された場合、サーブレット中心型アプリケーションは、ゲートウェイ・サーブレットを介してクライアントと対話します。要求は、ゲートウェイ・サーブレットによってコネクターへ、さらに実際のアプリケーションへ中継されます。WebSphereR Application Server (WAS) などのアプリケーション・サーバーへの典型的な移植を、図 6 に示します。
図6. Typical servlet-centric Web enablement strategy
この実行パターンに沿ったアプリケーションをグリッド上で動作可能にするには、少なくとも以下の手順が必要です。
- ユーザーのポータルとなるゲートウェイ・サーブレットが、WAS 上に実際に配備される唯一のコンポーネントになるように、デプロイメント記述子を修正します。
- 中核のアプリケーションに対するインターフェースとして働くコネクター・フレームワーク (JNI または独自仕様) の Java 部分を取り出し、それをスタンドアロンの Java アプリケーションとして配備します。これがクライアント・プログラムまたはジョブ送信ドライバーになります。
- バッチ指向グリッド・インフラストラクチャー上に、アプリケーションのコアを、一体型またはモジュール型 (どちらか適当な方) のアプリケーションとして配備します。
その結果できたシナリオを図 7 に示します。
図7. Typical Servlet-centric grid deployment
このシナリオの実装時には、元々の前提をいくつか変更することが必要になる場合があります。例えば、図 7 に示すような配備では、WebSphere Application Server Advanced Edition や Apache Tomcat とは異なり、EJB コンテナーを含まない WAS Express 上でゲートウェイ・サーブレットを動作させた方が管理が容易になることがあります。この種類の変更は、アプリケーションの総費用を削減できるため、顧客にとって大きなメリットとなります。
ただし、これは 1 つの方法にすぎないという点に留意してください。アプリケーションの特性によって、よりよい配備パターンの設計方法が他にもある可能性があります。実現可能性、労力、利便性、および管理の観点から最大の利益をもたらす方法が、最良のソリューションといえます。
注意事項
一体型およびモジュール型のアプリケーションに影響を及ぼす問題は、サーブレット中心型のグリッド化にも影響を及ぼす可能性があります。さらに、アプリケーションのパフォーマンスに関連する問題が生じる可能性もあります。
サーブレット中心型アプリケーションでは、多くの場合、Web コンテナー・レベルでパフォーマンス上の問題が生じます。ゲートウェイ・サーブレットを使用すると、ときには始末に負えないようなボトルネックが生じることもあります。このボトルネックは、特に以下の事項が原因となって発生します。
- サーブレット実行モデル (特に、サーブレットのボトルネックが、プレゼンテーション・ロジックについて Java Server Pages (JSP) に依拠する場合)。
- JNI などのコネクター・フレームワークによって生じるレイテンシー。一部の JVM 実装 (例えば IBM の実装) では、JNI 呼び出しがあると、要求されたプラットフォーム固有のプロセスを割り当てるためのポインターを JVM が作成しなければなりません。場合によっては、これらのポインターが大量のメモリーを占有したり、さらにポインターがまだアクティブである間にガーベッジ・コレクション・スレッドに拾われてしまう (これは、起こってほしくない事態です) ことを回避したりするために、JVM がポインターを更新し続けなければならなくなります。この結果、JVM 上に余分なオーバーヘッドが生じ、それによって、JVM が動作している Java プロセスによる CPU とメモリーの使用率が激増することになります。
これらの問題には、グリッド・インフラストラクチャーとの関連性はありません。アプリケーションがグリッド上で動作していなくても、これらの問題がトラブルの原因となることはあり得ます。一旦グリッド上にアプリケーションを配備した後には、新しい条件下でアプリケーション・サーバーを調整しなければならないことを認識しておく必要があります。さらに、アプリケーション・サーバーとグリッド・インフラストラクチャーの対話が原因となって、上記以外の問題が生じる可能性もあります。その例を以下に挙げます。
- アプリケーション・サーバーとグリッド・インフラストラクチャーとの間のセキュリティーに関するオーバーヘッド。グリッドはセキュリティーについて異常なまでに厳しく、JNI 呼び出しは認証の要求を嫌うことがあるということを考えれば、その結果として、アプリケーションがコネクター呼び出しを行うたびに毎回グリッド・インフラストラクチャーにログオンしなければならないという事態が生じる可能性もあります。この状況は、処理の遅延を招きます。
- アプリケーション・サーバーとグリッド・インフラストラクチャーとの間のネットワーク・レイテンシー (特に、地理的に分散して配備した場合)。
これらの問題がすべて同時に表面化した場合、グリッド化の作業全体がその労力に見合わないほど複雑で高コストになってしまうことがあります。このような場合には、アプリケーションのプラットフォーム固有部分を通常の一体型またはモジュール型のアプリケーション (どちらか適用な方) として配備する可能性について検討するか、プラットフォーム固有部分を J2EE 準拠のコンポーネント・セットとして書き直した上で SOA ベースのグリッド・インフラストラクチャーを探す方が得策です。
データベース中心型アプリケーション
データベース中心型アプリケーションは、クライアント・サーバーが全盛であった時代にデファクト・スタンダードになりました。PowerBuilder、Oracle 2000、PacBase、Progress などの製品に代表されるツールは、広いスペースを占有する大規模な一体型アプリケーションを開発する目的で広く使用されました。このようなアプリケーションでは、専用の言語とそれを理解するための特殊技能が必要とされました。
この種の製品の一部は、新しい分散処理の時代への適応に成功し、データベース中心型アプリケーションとして現在知られている Web 対応のハイブリッド製品のべースとなりました。一部のベンダーは自社製品を真に分散型で Web ネイティブに作り直したと主張していますが、製品によっては一皮むけば古いクライアント・サーバー型の一体型アーキテクチャーが手付かずで残されています。
しかし、このような状況は十分に理解できます。多くのベンダーが、当時の表現で言うところの「アプリケーションの迅速なプロトタイピングと開発」を推進する目的で、非常に複雑なフレームワークを記述するための独自の言語までも考案してきたからです。
これらの製品の技術的価値とは関係なく、各ベンダーは「その開発に大金が投資された」という単純な理由で、この知的資本を守る必要があるのです。したがって、データベース中心型アプリケーションは、今後も長く存続するものと思われます。
データベース中心型アプリケーションの一般的な実装系は、独自仕様のフレームワークを中心に展開されています。たいていの場合、これらのフレームワークには、現在普及している他の業界標準上で、Java テクノロジー、XML、および JMS をサポートするための「パッチ」が当てられています。図 8 は、このアーキテクチャーの最も一般的な形を示したものです。
図8. Most common database-centric architectural pattern
たいていの場合、アプリケーションとデータベースは単一のパッケージ内で結合されており、ビジネス・ロジックとデータベース操作ロジックの違いはありません。そのため、追加されたサポート・モジュールがオリジナルのアプリケーションとネイティブで対話することはありません。
データベース中心型アプリケーションの移植シナリオは、通常は図 9 に示すように Web コンテナーを介する形で実行されます。
図9. Typical database-centric Web enablement scenario
その戦略は、サーブレット中心型アプリケーションに適用される戦略と非常に似ています。このシナリオには、依存クラスとしてのアドオン Java サポート・モジュールを介するか、XML ファイルを介して、独自仕様のフレームワークにアクセスするゲートウェイ・サーブレットを作成する作業が伴います。
一体型アプリケーションとして扱う
データベース中心型アプリケーションをグリッド化する最も簡単な方法は、そのアプリケーションを一体型アプリケーションとして扱う方法です。この場合、図 9 に示した配備パターンを実装することが必要になります。
ただし、データベース中心型アプリケーションには興味深い特性があり、その特性によってある種のアプリケーションを効率的にグリッド上に配備できる可能性があります。
データの仮想化
データベース中心型アプリケーションでは、データベースはデータの格納に使用されるだけでなく、構成情報やワークフローのデータ、さらにはプレゼンテーションのメタデータを保持するために使用されます。ときには、このデータベースへの依存性が強すぎて、データベースをランタイム環境から分離できない場合があります。アプリケーションが実際にデータベース・エンジン上で動作する場合もあります。
データベース・ランタイムがアプリケーション・ランタイムである場合、仮想化できる対象はビジネス・ロジックではなくデータです。そのため、すでに述べた各シナリオで示した計算グリッドの代わりに、データ・グリッドを使用する必要があります。
データベース中心型アプリケーションをデータ・グリッド上で仮想化することによって、間接的にアプリケーション・ランタイムを仮想化し、最終的にアプリケーションそのものを仮想化します。これにより、アプリケーションで実行する必要のあるすべてのデータはグリッド上のすべてのノード上でローカルに使用できるようになり、アプリケーションに変更が加えられるたびに、変更内容が自動的にグリッド全体に伝播されます。
これにより、データがグリッド全体に伝播される一方で、ユーザーはデータベースへの要求に関して場所に対する非依存性を獲得します。要求を発行するプログラムにとっては、実際にはデータがグリッド上のどこに置かれていてもかまわないのですが、データは常にローカルに存在しているように見えます。リクエスト・ブローカー (Java インターフェースおよびシック・クライアント用ドライバー) が単一インスタンスのバッチ・ジョブとして動作する一方で、データはグリッド・インフラストクチャーによって仮想化されます。
ビジネス・ロジックの記述方法によっては、図 10 に示すようにデータとビジネス・ロジックを仮想化できる可能性があります。
図10. Data virtualization scenario for database-centric applications
データ・グリッド上でデータとビジネス・ロジックを仮想化できるのは、データベース・エンジンがトリガーとなるプロセス内でビジネス・ロジックが実行される場合に限られるという点に注意してください。大部分の独自仕様のフレームワークは、これに該当します。
一方、ジョブ送信ドライバーなどの外部プロセスによってビジネス・ロジックをトリガーできる場合には、実際にデータをビジネス・ロジックから分離して、ビジネス・ロジック用の計算グリッドとデータベース用のデータ・グリッドとを組み合わせた形に展開できる可能性があります。ただし、この方法では配備モデルが複雑になりすぎて、ソリューションとして実現不可能になる場合もあります。
注意事項
通常、データベース中心型アプリケーションには、CPU とメモリーの使用量が多いという特性があります。この特性は、データベース・ランタイムでアプリケーションが同時に動作する場合に、特に顕著になります。
場合によっては、データ・グリッドそのものによって生じるオーバーヘッドに、リソースを大量に使用するデータベース・ランタイム環境によるオーバーヘッドが加わって、配備作業が期待どおりに進まないことがあります。また、別のケースでは、データとアプリケーションとの分離が可能なときに一体型アプリケーションの場合と似た状況に陥り、一体型アプリケーションと同じ問題が生じることもあります。
結論
この記事の情報は、製品のグリッド化に際して最良の方法を模索するためのブレーンストーミングを開始する際の検討材料として使用してください。プラットフォーム固有の分散アプリケーション (一体型とモジュール型の両方) および Web 対応アプリケーション (サーブレット中心型とデータベース中心型の両方) のグリッド化をお考えの場合、この記事は非常に参考になります。
参考文献
著者について  | | | Marlon Machado joined IBM in 1996 as a programmer for the ISSC organization (now IBM Global Services) in Atlanta, Georgia, where he worked on various projects involving distributed architectures. In 1998 Marlon joined the San Francisco Technology Center in Austin, Texas. He later became an e-business Architect for IBM Developer Relations where he has conducted research in high-performance distributed architectures based on the J2EE programming model. Marlon is the author and lead instructor of "Performance Tuning - WebSphere Application Server Advanced Edition," an advanced hands-on workshop offered at IBM Solution Partnership Centers worldwide. Marlon lives in Austin, Texas and in the beautiful Caribbean coast of Honduras, but he spends most of his time traveling around the world assisting IBM's ISV partners. You can contact him at mmachado@us.ibm.com. |
記事の評価
| 
