| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 11g リリース1(10.3.6) B60992-04 |
|
 前 |
 次 |
この章では、WebLogic Serverクラスタでホストされるアプリケーションのスケーラビリティ、信頼性およびパフォーマンスを最大にする設計およびデプロイメントのベスト・プラクティスを紹介します。
次の項では、クラスタ化されたアプリケーションの一般的な設計上のガイドラインを説明します。
分散システムは本質的にどうしても複雑になります。さまざま理由から、設計ではシンプルさを第一の目標にしてください。「可動部品」を最小限に抑え、アルゴリズムが複数のオブジェクトに分散しないようにします。
リモート呼出しを最小限に抑えると、パフォーマンスが向上し、障害の影響が少なくなります。
クライアントまたはサーブレット・コードからEJBエンティティBeanにアクセスしないようにします。そのかわりに、セッションBean (Facadeと呼ばれる)を使用して複雑な対話を内包し、WebアプリケーションからRMIオブジェクトへの呼出しを削減します。クライアント・アプリケーションが直接エンティティBeanにアクセスする場合、各ゲッター・メソッドはリモート呼出しです。セッションFacade BeanはエンティティBeanにローカルでアクセスし、データを構造体に収集して、それを値で戻すことができます。
EJBの実行には、システム・リソースとネットワーク帯域幅が著しく消費されます。このため、EJBはアプリケーションのすべてのオブジェクトの適切な実装になるとは考えられません。
EJBを使用すると、情報と関連するビジネス・ロジックの論理的なグループをモデル化できます。たとえばEJBを使用して、インボイスの項目の論理的な部分集合(割引、払い戻し、税金などの調整が適用される項目群など)をモデル化できます。
一方、インボイスの個々の項目は細かいので、それをEJBとして実装するのはネットワーク・リソースの浪費になります。データ・フィールドの集合のみを表すオブジェクト(getとsetの機能のみを必要とする)は、転送オブジェクトとして実装します。
転送オブジェクト(値オブジェクトまたはヘルパー・クラスとも呼ばれる)は、常に一緒にアクセスされる属性のグループを格納するエンティティをモデル化するのに適しています。転送オブジェクトは、関連する属性をグループ化して複合値を形成するEJB内のシリアライズ可能クラスです。このクラスは、リモート・ビジネス・メソッドの戻り値の型として使用されます。
クライアントは、大まかなビジネス・メソッドを呼び出してこのクラスのインスタンスを受信し、ローカルでその転送オブジェクト内の細かな値にアクセスします。サーバーとの間を1往復するだけで複数の値を取得すると、ネットワーク・トランザクションが削減され、待機時間とサーバー・リソースの使用量が最小限に抑えられます。
次の項では、クラスタ化されたサーブレットおよびJSPの設計上の考慮事項について説明します。
サーブレットまたはJSPの自動フェイルオーバーを有効にするには、セッション状態をメモリーに保持する必要があります。HTTPセッション状態のインメモリー・レプリケーションを構成する手順は、「HTTPセッション状態のレプリケーションに関する条件」および「インメモリーHTTPレプリケーションの構成」を参照してください。
次の項では、クラスタ化されたRMIオブジェクトの設計上の考慮事項について説明します。
サーバー・インスタンスでいつ障害が発生したのかを、その障害が発生したときに行われていた処理との関連で判断するのは必ずしも可能ではありません。たとえば、クライアント・リクエストの処理後、レスポンスを戻す前にサーバー・インスタンスで障害が発生した場合は、そのリクエストが処理されたのかを確認する手段がありません。レスポンスを受信していないユーザーは再試行するので、余分なリクエストが発行されることになります。
RMIオブジェクトのフェイルオーバーでは、メソッドが多重呼出し不変でなければなりません。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。
表11-1は、EJBの使用方法と構成のガイドラインを要約したものです。構成可能なクラスタ動作とリソースのリストおよび構成方法は、表11-2を参照してください。
表11-1 EJBのタイプとガイドライン
| オブジェクトの種類 | 使用方法 | 構成 |
|---|---|---|
|
全タイプのEJB |
EJBを使用すると、情報と関連するビジネス・ロジックの論理的なグループをモデル化できます。「転送オブジェクトでリモート呼出しが削減される」を参照してください。 |
クラスタリング可能なホームを構成します。表11-2を参照してください。 |
|
ステートフル・セッションBean |
規模が大きく、書込みの多いトランザクションで推奨されます。 EJBコンテナのオーバーヘッドを最小限に抑えるために、ステートフル・セッションBeanは終了時点で削除します。ステートフル・セッションBeanのインスタンスは特定のクライアントと関連付けられ、クライアントによって明示的に削除されるか、タイムアウトでコンテナによって削除されるまでコンテナに留まります。その間、コンテナはアクティブでないインスタンスをディスクにパッシブ化することもあります。その処理はオーバーヘッドを消費し、パフォーマンスに影響します。 注意: まれに、ステートフル・セッションBeanの現在の状態が失われることがあります。たとえば、Beanの関与しているトランザクションがクライアントによってコミットされ、状態の変更がレプリケートされる前にプライマリ・サーバーで障害が起きると、クライアントは以前に格納されていたBeanの状態にフェイルオーバーされます。あらゆる障害シナリオにおいて、Beanの状態の保持が重要な場合は、ステートフル・セッションEJBではなくエンティティEJBを使用します。 |
クラスタリング可能なホームを構成します。表11-2を参照してください。 EJBのインメモリー・レプリケーションを構成します。表11-2を参照してください。 |
|
ステートレス・セッションBean |
クライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性のあるステートフル・セッションBeanより、スケーラビリティにおいて優れています。 ホームでステートレスBeanが作成されると、Beanがデプロイされたどのサーバーにでも呼出しを転送できるレプリカ対応スタブが返されます。ステートレスBeanでは状態が保持されないので、スタブではBeanのホストであるどのサーバーにでも呼出しを転送できます。 |
クラスタリング可能なホームを構成します。表11-2を参照してください。 クラスタ・アドレスを構成します。表11-2を参照してください。 メソッド呼出し時のフェイルオーバーをサポートするように、メソッドを多重呼出し不変であるように構成します(表11-2を参照)。(フェイルオーバーは、メソッド呼出しの間に障害が発生した場合またはメソッドがサーバーに接続できなかった場合のデフォルトの動作です)。 ステートレス・セッションBeanホームのメソッドは、自動的に多重呼出し不変に設定されます。これらについては多重呼出し不変を明示的に設定する必要はありません。 |
|
読取り専用エンティティBean |
古いデータでも問題ない場合に推奨されます。製品カタログや多くのアプリケーションの内容の大部分に適しています。読取りは、タイマーに基づいて無効化されるローカル・キャッシュに対して実行されます。読取り専用エンティティのパフォーマンスは、トランザクション対応エンティティよりも3 - 4倍高速です。 注意:クライアントは読取り専用エンティティBeanでセッター・メソッドを正常に呼び出すことができますが、データが永続ストアに移動することはありません。 |
クラスタリング可能なホームを構成します。表11-2を参照してください。 クラスタ・アドレスを構成します。表11-2を参照してください。 メソッドはデフォルトで多重呼出し不変になるよう構成されます。 |
|
読み書き対応エンティティBean |
リクエストや更新が頻繁に行われることのない共有永続データに最適です。アクセスや更新の負荷が高い場合は、セッションBeanおよびJDBCを検討します。 顧客口座の管理など、高度なデータ一貫性が要求されるアプリケーションで推奨されます。読み書きはすべてデータベースで実行されます。
read-mostlyアプリケーション(頻繁に読込みが行われ、更新はまれであるカタログなど)では、読取り専用Beanと読取り専用Beanを拡張する読み書き対応Beanの組合せが適しています。読取り専用Beanでは高速で一貫性の乏しい読込みが行われ、読み書き対応Beanでは一貫性の優れた書込みが行われます。 |
クラスタリング可能なホームを構成します。表11-2を参照してください。 メソッド呼出し時のフェイルオーバーをサポートするように、メソッドを多重呼出し不変であるように構成します(表11-2を参照)。(フェイルオーバーは、メソッド呼出しの間に障害が発生した場合またはメソッドがサーバーに接続できなかった場合のデフォルトの動作です)。 読取り専用エンティティBeanのメソッドは、自動的に多重呼出し不変に設定されます。 |
表11-2に、クラスタで構成できる主要な動作と関連する構成方法を表示します。
表11-2 クラスタ関連の構成オプション
| 構成可能な動作またはリソース | 構成方法 |
|---|---|
|
クラスタリング可能なホーム |
|
|
多重呼出し不変 |
Beanレベルでは、 メソッド・レベルでは、 |
|
EJBのインメモリー・レプリケーション |
|
|
クラスタ・アドレス |
クラスタ・アドレスは、クラスタ内の管理対象サーバーを識別します。クラスタ・アドレスは、URLのホスト名部分を構築するためにエンティティBeanおよびステートレスBeanで使用されます。クラスタ・アドレスは明示的に割り当てることも、WebLogic Serverでリクエストごとに自動的に生成することもできます。詳細は、「クラスタ・アドレス」を参照してください。 |
clients-on-same-server |
EJBにアクセスするクライアントのすべてが、そのBeanがデプロイされているのと同じサーバー上からアクセスする場合には、
|
|
エンティティBeanおよびエンティティEJBのホームのロード・バランシング・アルゴリズム |
|
|
エンティティEJB、ステートフル・セッションEJB、およびステートレス・セッションのカスタム・ロード・バランシング |
|
|
ステートレス・セッションBeanのカスタム・ロード・バランシング |
|
|
ステートレス・セッションBeanのクラスタリング可能の構成 |
|
|
ステートレス・セッションBeanのロード・バランシング・アルゴリズム |
|
|
マシン |
WebLogic Serverマシン・リソースは、サーバー・インスタンスとそのインスタンスが動作するコンピュータを関連付けます。詳細は、「マシン名を構成する」を参照してください。 |
|
レプリケーション・グループ |
レプリケーション・グループを使用すると、HTTPセッション状態がどこにレプリケートされるかを制御できます。詳細は、「レプリケーション・グループを構成する」を参照してください。 |
WebLogic Serverクラスタの様々なサービスによって、いろいろな種類と程度の状態管理が提供されます。次のリストでは、メモリーまたは永続ストレージでの状態の保持方法によって区別される4つのカテゴリを定義します。
ステートレス・サービス - ステートレス・サービスは、呼出し間でメモリーを状態に保持しません。
会話型サービス - 会話型サービスは、あるセッションの期間中に特定のクライアント専用になります。セッションの期間中、そのクライアントからのリクエストのみをすべて処理します。一般に、セッションの間は、アプリケーション・サーバーがリクエスト間で保持する必要のある状態情報が存在します。通常、会話型サービスはメモリーに一時的なステートを保持します。このステートは障害が発生すると失われる可能性があります。セッション・ステートが呼出しの間に共有の永続ストレージに書き込まれる場合、サービスはステートレスになります。ステートの永続ストレージが必要ない場合は、パフォーマンスとスケーラビリティを向上するために次のような選択肢があります。
セッション状態を背後でクライアント/サーバー間で往復させることができます。結果として再びステートレス・サービスになります。この方法は、特に大量のデータがある場合には、必ずしも実現可能で望ましいとは限りません。
より一般的には、リクエスト間でセッション状態をアプリケーション・サーバー上のメモリーに保持することができます。メモリーを解放する必要がある場合は、セッション状態をメモリーからページ・アウトできます。個々の更新はディスクに書き込まれず、サーバーに障害が発生した場合はデータが失われるため、この場合もパフォーマンスとスケーラビリティは向上します。
キャッシュ済みサービス - キャッシュ済みサービスはメモリーに状態を保持し、その状態を使用して複数のクライアントからのリクエストを処理します。キャッシュ済みサービスの実装は、キャッシュされるデータのコピー同士の一貫性や、バッキング・ストア内の関連データとの一貫性をどの程度維持するかによって異なります。
シングルトン・サービス - シングルトン・サービスは、実行時にクラスタ内の1つのサーバー上でのみアクティブになり、複数のクライアントからのリクエストを処理します。通常、シングルトン・サービスは、メモリーにキャッシュしたプライベートな永続データによってバックアップされます。メモリーに一時的なステートを保持することもできます。このステートは障害が発生した場合は再生成されるか、または失われます。障害が発生した場合、シングルトン・サービスは同じサーバー上で再起動するか、新しいサーバーに移行する必要があります。
表11-3は、Java EEとWebLogicが各カテゴリのサービスをどのようにサポートしているかをまとめたものです。ステートレス・サービスと会話型サービスは、2つのタイプのクライアントごとに説明されています。
疎結合クライアントには、標準のプロトコルを使用してアプリケーション・サーバーと通信するブラウザまたはWebサービス・クライアントが含まれます。
密結合クライアントは、アプリケーション層またはクライアント側環境で動作し、独自のプロトコルを使用してアプリケーション・サーバーと通信するオブジェクトです。
表11-3 サービス・タイプごとのJ2EEとWebLogicのサポート
| サービス | Java EEのサポート | WebLogic Serverのスケーラビリティと信頼性の機能 |
|---|---|---|
|
疎結合クライアントを使用したステートレス・サービス |
すべてのJava EE APIは、ステートレスであるか、または、呼出し間で状態情報を共有永続ストレージに書き込むことでステートレスとして実装できます。 Java EEはロード・バランシングとフェイルオーバーに対する標準を指定していません。疎結合クライアントの場合、ロード・バランシングは外部のIPベースのメカニズムによって実行する必要があります。 |
WebLogic Serverは、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス・サービスの可用性を向上させます。 ステートレス・サービスの疎結合クライアントの場合、WebLogic Serverは外部ロード・バランシング・ソリューションをサポートし、セッション・フェイルオーバーとロード・バランシング用のプロキシ・プラグインを提供します。 詳細は、次を参照してください: |
|
密結合クライアントを使用したステートレス・サービス |
次のJava EE APIは、ステートレス・サービスへの密結合アクセスをサポートします;
|
WebLogic Serverは、サービスの複数のインスタンスをクラスタにデプロイすることで、ステートレス・サービスの可用性を向上させます。 ステートレス・サービスの密結合クライアントの場合、WebLogic ServerはRMI実装でロード・バランシングとフェイルオーバーをサポートします。 クラスタ化されたRMIオブジェクトに対するWebLogic Serverのレプリカ対応スタブは、オブジェクトに対してサービスと構成済みロード・バランシング・アルゴリズムを現在提供している、クラスタ内のサーバー・インスタンスのリストを示します。WebLogic Serverはスタブを使用して、ロード・バランシングとフェイルオーバーに関する決定を行います。 詳細は、次を参照してください: |
|
会話型サービス(疎結合クライアント) |
次のJava EE APIは、会話型サービスへの疎結合アクセスをサポートします。
Java EEはロード・バランシングとフェイルオーバーに対する標準を指定していません。 ロード・バランシングは、外部のIPベースのメカニズム、またはプレゼンテーション層のアプリケーション・サーバーのコードによって実現できます。会話型サービスのプロトコルはステートレスであるため、ロード・バランシングはセッションの作成時にのみ発生します。以降のリクエストは選択したサーバーに固定されます。 |
WebLogic Serverは次によってセッションの信頼性を向上させます。
詳細は、次を参照してください。 |
|
会話型サービス(密結合クライアント) |
Java EE標準はEJBステートフル・セッションBeanを提供して、密結合クライアントでの会話型サービスをサポートします。 |
WebLogic Serverは次の機能でステートフル・セッションBeanの可用性と信頼性を向上させます。
詳細は、「ステートフル・セッションBean」を参照してください。 |
|
キャッシュ済みサービス |
Java EEはキャッシュ済みサービスに対する標準を指定していません。 Bean管理による永続性を持つエンティティBeanはカスタム・キャッシュを実装できます。 |
Weblogic Serverは次に対するキャッシングをサポートします。 ステートフル・セッションBean ステートフル・セッションBeanのスケーラビリティと信頼性を向上させるWebLogic機能のリストについては、上記の行の説明を参照してください。 エンティティBean WebLogic ServerはエンティティBeanに対する次のキャッシング機能をサポートします。
キャッシュと外部データ・ストアの一貫性は、次により向上させることができます。
「read-mostlyパターン」 WebLogic Serverは読取り専用EJBと読み書き対応EJBを組み合わせて「read-mostlyパターン」をサポートします。 JSP WebLogic ServerはカスタムJSPタグを提供して、フラグメント・レベルまたはページ・レベルのキャッシングをサポートします。 |
|
シングルトン・サービス |
シングルトン・サービスの実装に使用されるJava EE APIは次のとおりです。
サービスを複数のインスタンスに「分割」することでスケーラビリティを向上させることができます。各インスタンスはバッキング・データの別々の断片とそれに関連付けられたリクエストを処理します。 |
シングルトン・サービスの可用性を高めるWebLogic Server機能には次のものがあります。
|
クラスタリング可能なオブジェクトは、クラスタ内の個別の管理対象サーバーではなくクラスタにデプロイします。詳細および推奨事項は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
各種のクラスタ・アーキテクチャ、ロード・バランシング・オプション、およびセキュリティ・オプションについては、第9章「クラスタ・アーキテクチャ」を参照してください。
次の項では、クラスタのプランニングと構成で留意すべき考慮事項を示します。
クラスタのサーバー・インスタンスの命名とアドレッシングのガイドラインについては、「名前とアドレスを識別する」を参照してください。
クラスタに参加しているWebLogic Serverインスタンスを起動する場合、各管理対象サーバーは、そのクラスタを含むドメインの構成情報を管理している管理サーバーに接続できなくてはなりません。セキュリティ上の理由から、管理サーバーはWebLogic Serverクラスタと同じDMZ内に配置する必要があります。
管理サーバーは、クラスタに参加しているすべてのサーバー・インスタンスの構成情報を保持します。管理サーバー上にあるconfig.xmlファイルには、クラスタ化されているかどうかに関係なく、管理サーバーのドメイン内の全サーバーの構成データが格納されます。クラスタ内のサーバーごとに個別の構成ファイルは作成しません。
クラスタ化されたWebLogic Serverインスタンスが起動するためには、管理サーバーが使用可能になっている必要があります。ただし、いったんクラスタが起動したら、管理サーバーに障害が発生しても実行中のクラスタの動作には影響しません。
管理サーバーをクラスタに参加させないでください。管理サーバーがサーバーの管理(構成データの保持、サーバーの起動と停止、およびアプリケーションのデプロイメントとアンデプロイメント)プロセスだけを受け持つような構成を採ることをお薦めします。管理サーバーにクライアントからのリクエストも処理させると、管理タスクの実行に遅れが生じるリスクが発生します。
管理サーバーをクラスタリングする利点はありません。管理オブジェクトはクラスタリング可能でなく、管理サーバーで障害が発生した場合、他のクラスタ・メンバーにフェイルオーバーされません。管理サーバーにアプリケーションをデプロイすると、サーバーおよびサーバーが提供している管理機能の安定性が損なわれる可能性があります。管理サーバーにデプロイしたアプリケーションが予期しない動作を見せた場合、管理サーバーの動作に影響するおそれもあります。
以上の理由から、管理サーバーのIPアドレスがクラスタ全体のDNS名に含まれていないことを確認してください。
構成にファイアウォールが含まれている場合は、プロキシ・サーバーまたはロード・バランサをDMZに配置し、クラスタ(WebコンテナとEJBコンテナの両方とも)をファイアウォールの背後に配置します。WebコンテナをDMZに配置することはお薦めしません。「プロキシ・アーキテクチャの基本ファイアウォール」を参照してください。
複数層アーキテクチャのサーブレット・クラスタとオブジェクト・クラスタの間にファイアウォールを配置する場合は、オブジェクト・クラスタ内のすべてのサーバーをIPアドレスではなく、外部に公開されているDNS名にバインドさせます。サーバーをIPアドレスにバインドさせると、アドレス変換に関する問題が発生し、サーブレット・クラスタが各サーバー・インスタンスにアクセスできなくなる場合があります。
WebLogic Serverインスタンスの内部DNS名と外部DNS名が同じでない場合、サーバー・インスタンスのExternalDNSName属性を使用して、サーバーの外部DNS名を定義します。ファイアウォールの外で、ExternalDNSNameはサーバーの外部IPアドレスに変換されます。管理コンソールの「サーバー」>「構成」>「全般」ページで、この属性を設定します。Oracle WebLogic Server管理コンソール・ヘルプの「サーバー」>「構成」>「全般」に関する項を参照してください。
1つまたは複数のファイアウォールを利用するクラスタ・アーキテクチャでは、すべてのWebLogic ServerインスタンスをIPアドレスではなく、外部に公開されているDNS名を使用して識別することが重要です。DNS名を使用することで、信頼性のないクライアントに対して内部IPアドレスをマスクする場合に使用されるアドレス変換ポリシーに関連する問題を回避できます。
|
注意: クライアントがt3およびデフォルト・チャネルを使用してWebLogic Serverにアクセスする場合を除き、ファイアウォールがネットワーク・アドレス変換を実行する構成では、ExternalDNSNameを使用する必要があります。たとえば、ファイアウォールがネットワーク・アドレス変換を実行し、クライアントがプロキシ・プラグインを介してHTTPでWebLogic Serverにアクセスする構成では、ExternalDNSNameが必須です。 |
図11-1に、WebLogic Serverインスタンスの識別にIPアドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールがサブネット「xxx」の外部IPリクエストをサブネット「yyy」の内部IPアドレスに変換します。
次のステップは、接続プロセスと、考えられる障害ポイントについての説明です。
クライアントは、205.20.xxx.100:7001にある最初のサーバーへの接続をリクエストしてWebLogic Serverクラスタへのアクセスを開始します。ファイアウォールは、このアドレスを205.20.yyy.100:7001というIPアドレスに変換し、クライアントをそのアドレスに接続します。
クライアントは、クラスタ内の3番目のWebLogic Serverインスタンスにある、固定されているオブジェクトCのJNDIルックアップを実行します。オブジェクトCのスタブには、そのオブジェクトのホストになっているサーバーの内部IPアドレス205.20.yyy.300:7001が含まれています。
オブジェクトCをインスタンス化しようとする場合、クライアントはIPアドレス205.20.yyy.300:7001を使用してオブジェクトCのホストになっているサーバーへの接続をリクエストします。ファイアウォールはこの接続を拒否します。クライアントが、外部に公開されているサーバーのアドレスではなく、制限されている内部IPアドレスを使用してリクエストしたことが原因です。
外部IPアドレスと内部IPアドレスの間の変換が行われなかった場合は、上記のようなクライアント・リクエストがファイアウォールで問題なく処理されます。ただし、ほとんどのセキュリティ・ポリシーでは内部IPアドレスへのアクセスは拒否されます。
