| Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方 11g リリース 1 (10.3.1) B55518-01 |
|
 戻る |
 次へ |
以下の節では、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 を使用すると、情報と関連するビジネス ロジックの論理的なグループをモデル化できる。「転送オブジェクトでリモート呼び出しが削減される」を参照。 |
クラスタ対応ホームをコンフィグレーションする。 |
|
ステートフル セッション Bean |
規模が大きくて書き込みの多いトランザクションに推奨。 EJB コンテナのオーバーヘッドを最小限に抑えるために、ステートフル セッション Bean は終了時点で削除する。ステートフル セッション Bean のインスタンスは特定のクライアントと関連付けられ、クライアントによって明示的に削除されるか、タイムアウトでコンテナによって削除されるまでコンテナに留まる。その間、コンテナはアクティブでないインスタンスをディスクにパッシベーションすることもある。その処理はオーバーヘッドを消費し、パフォーマンスに影響する。 注意 : 滅多にないが、ステートフル セッション Bean の現在のステートが失われることもある。たとえば、Bean の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた Bean のステートにフェイルオーバされる。どのような障害が起きても Bean のステートを保持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用する。 |
クラスタ対応ホームをコンフィグレーションする。 EJB のインメモリ レプリケーションをコンフィグレーションする。 |
|
ステートレス セッション Bean |
クライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性のあるステートフル セッション Bean よりスケーラビリティが高い。 ホームでステートレス Bean が作成されると、Bean がデプロイされたどのサーバにでも呼び出しを転送できるレプリカ対応スタブが返される。ステートレス Bean では状態が保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できる。 |
クラスタ対応ホームをコンフィグレーションする。 クラスタ アドレスをコンフィグレーションする。 メソッド呼び出し時のフェイルオーバをサポートするように、メソッドは多重呼び出し不変であるようにコンフィグレーションする。フェイルオーバは、メソッド呼び出しの間に障害が発生した場合、またはメソッドがサーバに接続できなかった場合のデフォルトの動作。 ステートレス セッション Bean ホームのメソッドは、自動的に多重呼び出し不変に設定される。これらについては多重呼び出し不変を明示的に設定する必要はない。 |
|
読み込み専用エンティティ Bean |
古いデータでも問題ない場合に推奨。製品カタログや多くのアプリケーションの内容の大部分に適している。読み込みは、タイマーに基づいて無効化されるローカル キャッシュに対して実行される。読み込み専用エンティティのパフォーマンスは、トランザクション対応エンティティよりも 3 ～ 4 倍速い。 注意 : クライアントは読み込み専用エンティティ Bean でセッター メソッドを正常に呼び出すことができるが、データが永続ストアに移動することはあり得ない。 |
クラスタ対応ホームをコンフィグレーションする。 クラスタ アドレスをコンフィグレーションする。 メソッドはデフォルトで多重呼び出し不変になるようコンフィグレーションされる。 |
|
読み書き対応エンティティ Bean |
リクエストや更新が頻繁に行われることのない共有永続データに最適。アクセスや更新の負荷が高い場合は、セッション Bean および JDBC を検討する。 顧客口座の保守など、高度なデータ一貫性が要求されるアプリケーションに推奨。読み書きはすべてデータベースで実行される。
read-mostly アプリケーション (頻繁に読み込みが行われ、更新はまれであるカタログなど) では、読み込み専用 Bean と読み込み専用 Bean を拡張する読み書き対応 Bean の組み合わせが適している。読み込み専用 Bean では高速で一貫性の乏しい読み込みが行われ、読み書き対応 Bean では一貫性の優れた書き込みが行われる。 |
クラスタ対応ホームをコンフィグレーションする。 メソッド呼び出し時のフェイルオーバをサポートするように、メソッドは多重呼び出し不変であるようにコンフィグレーションする。フェイルオーバは、メソッド呼び出しの間に障害が発生した場合、またはメソッドがサーバに接続できなかった場合のデフォルトの動作。 読み込み専用エンティティ 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 は次のとおり。
サービスを複数のインスタンスに「分割」することでスケーラビリティを向上させることができる。各インスタンスはバッキング データの別々の断片とそれに関連付けられたリクエストを処理する。 |
シングルトン サービスの可用性を向上させるための WLS 機能は次のとおり。
|
クラスタ対応オブジェクトは、クラスタ内の個別の管理対象サーバではなくクラスタにデプロイします。情報と推奨事項については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』を参照してください。
各種のクラスタ アーキテクチャ、ロード バランシング オプション、およびセキュリティ オプションについては、「クラスタ アーキテクチャ」を参照してください。
以下の節では、クラスタのプランニングとコンフィグレーションで留意すべき考慮事項を示します。
クラスタのサーバ インスタンスの命名とアドレッシングのガイドラインについては、「名前とアドレスを識別する」を参照してください。
クラスタに参加している 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 アドレスに変換されます。Administration Console の [サーバ｜コンフィグレーション｜全般] タブで、この属性を設定します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ : コンフィグレーション : 全般」を参照してください。
1 つまたは複数のファイアウォールを利用するクラスタ アーキテクチャでは、すべての WebLogic Server インスタンスを IP アドレスではなく、外部に公開されている DNS 名を使用して識別することが重要です。DNS 名を使用することで、信頼性のないクライアントに対して内部 IP アドレスをマスクする場合に使用されるアドレス変換ポリシーに関連する問題を回避できます。
|
注意 : クライアントが t3 およびデフォルト チャネルを使用して WebLogic Server にアクセスする場合を除き、ファイアウォールがネットワーク アドレス変換を実行するコンフィグレーションでは、ExternalDNSName を使用する必要があります。たとえば、ファイアウォールがネットワーク アドレス変換を実行し、クライアントがプロキシ プラグインを介して HTTP で WebLogic Server にアクセスするコンフィグレーションでは、ExternalDNSName が必須です。 |
次の図 11-1 に、WebLogic Server インスタンスの識別に IP アドレスを使用する場合に発生する可能性のある問題を示します。この図では、ファイアウォールは、サブネット「xxx」の外部 IP リクエストを、サブネット「yyy」の内部 IP アドレスに変換しています。
図 11-1 サーバが 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 アドレスへのアクセスは拒否されます。
