ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理
12c (12.1.2)
B70746-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

5 Coherence*Webセッション管理機能

この章では、Coherence*Webの機能(セッション・モデル、セッション・スコープ設定、セッション・ロック、デプロイメント・トポロジ、ロギングなど)について説明します。Coherence*Webは、作業環境の要望を満たすために様々な方法で構成できます。そのために、一部のデフォルトの構成オプションの変更が必要になる場合があります。この章では、構成とデプロイメントについて適切な意思決定ができるように、Coherence*Webでサポートされている機能について詳しく説明します。

5.1 セッション・モデル

セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように保存するのかを記述します。セッション・データはHttpSessionModelオブジェクトで管理し、Webアプリケーションのセッション・コレクションはHttpSessionCollectionオブジェクトで管理します。web.xmlファイルでコレクション・タイプのみを構成する必要があります。モデルはコレクション・タイプから暗黙的に派生します。Coherence*Webは、次のような様々なセッション・モデル実装を備えています。

この項では、セッション・モデルについて詳しく説明します。


注意:

一般的に、同じCoherenceクラスタに属するWebアプリケーションは、同じセッション・モデル・タイプを使用する必要があります。構成に一貫性がないと、デシリアライズ・エラーが発生することがあります。

図5-1は、3つのセッション・モデルを示しています。

図5-1 トラディショナル、モノリシック、およびスプリット・セッション・モデル

トラディショナル、モノリシック、およびスプリット・セッション・モデル
「図5-1 トラディショナル、モノリシック、およびスプリット・セッション・モデル」の説明

5.1.1 モノリシック・モデル

モノリシック・モデルは、MonolithicHttpSessionModelオブジェクトとMonolithicHttpSessionCollectionオブジェクトで表されます。これらはトラディショナル・モデルと似ていますが、すべての属性を単一のオブジェクト・ストリームにシリアライズおよびデシシアライズすることで共有オブジェクトの問題を解決している点が異なります。そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することがよくあります。

図5-2に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュの物理表現では、メタデータと属性は単一のストリームにシリアライズされます。メタデータと属性にはセッションIDが関連付けられます。

図5-2 モノリシック・セッション・モデル

モノリシック・セッション・モデル
「図5-2 モノリシック・セッション・モデル」の説明

5.1.2 トラディショナル・モデル

トラディショナル・モデルは、TraditionalHttpSessionModelオブジェクトとTraditionalHttpSessionCollectionオブジェクトで表されます。TraditionalHttpSessionCollectionオブジェクトはHTTPセッション・オブジェクトを単一のキャッシュに格納しますが、各属性を個別にシリアライズします。

このモデルは、HTTPセッション・オブジェクトが比較的小型で(10KB以下)、セッション属性間でオブジェクト共有の問題が発生しない用途に最適です。セッション属性間のオブジェクト共有は、1つのセッションにある複数の属性で同じオブジェクトを参照する場合に発生します。このような状況では、HTTPセッションを後でデシリアライズすると、これらの属性のシリアライズとデシリアライズが独立して実行されるので、共有オブジェクトの複数のインスタンスが発生します。

図5-3に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュ内の物理表現では、メタデータと属性はバイナリに変換され、これらにセッションIDが関連付けられます。属性は、単一のバイナリBLOBとして(モノリシック・モデルのように)ではなく、個々にシリアライズされることに注意してください。

図5-3 トラディショナル・セッション・モデル

トラディショナル・セッション・モデル
「図5-3 トラディショナル・セッション・モデル」の説明

5.1.3 スプリット・モデル

スプリット・モデルは、SplitHttpSessionModelオブジェクトとSplitHttpSessionCollectionオブジェクトで表されます。SplitHttpSessionCollectionはCoherence*Webで使用されるデフォルトです。

これらのモデルは、主要HTTPセッション・メタデータとすべての小型セッション属性を、トラディショナル・モデルと同じ方法で格納します。これによって、バイナリ・セッション・データのブロックを小型に維持できるので、高いパフォーマンスが得られます。すべての大型の属性は、独立したキャッシュ・エントリに分割して別々に管理するので、リクエストが発生するたびにクラスタ内でアクセスまたは更新を必要とするデータ量を増やさずに、大規模なHTTPセッション・オブジェクトをサポートできます。つまり、属性の更新によってネットワーク・オーバーヘッドが発生するのは、特定のリクエストで大型の属性を変更する場合のみです。したがって、一般的にスプリット・モデルでは、主要なHTTPセッション・データへのアクセスでも、またどのセッション属性へのアクセスでもネットワーク・オーバーヘッドがほとんど発生しません(これはニア・キャッシュを使用しているからです)。

図5-4に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。このモデルでは、大型のオブジェクトは独自のセッションIDを持つ個別のキャッシュ・エントリとして格納されます。

図5-4 スプリット・セッション・モデル

スプリット・セッション・モデル
「図5-4 スプリット・セッション・モデル」の説明

5.1.4 セッション・モデルの推奨事項

次に、アプリケーションに対してどのセッション・モデルを選択するかについて推奨事項を示します。

  • スプリット・モデルは、ほとんどのアプリケーションにお薦めできるセッション・モデルです。

  • トラディショナル・モデルは、HTTPセッション・オブジェクトが小型であることがわかっているアプリケーションに適しています。

  • モノリシック・モデルは、複数のセッション属性で1つの共有オブジェクトを参照し、そのオブジェクトを共有オブジェクトとして維持する必要がある場合、それら複数のセッション属性に関連する特定のクラスの問題を解決することを目的としています。


注意:

セッション・モデルの構成に使用するパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.1.5 セッション・モデルの構成

デフォルトではCoherence*Webは、大型の属性が独立したキャッシュ・エントリに分割され、個々に管理されるスプリット・セッション・モデルを使用します。Coherence*Webにより使用されるセッション・モデルは、-Dcoherence.sessioncollection.classシステム・プロパティを構成するか、Webアプリケーションのweb.xmlファイル内の同等のcoherence-sessioncollection-classコンテキスト・パラメータを設定することにより変更できます。コンテキスト・パラメータ(またはシステム・プロパティ)の値として、HttpSessionCollection実装の完全修飾クラス名を使用します。

  • com.tangosol.coherence.servlet.SplitHttpSessionCollection (デフォルト)は、スプリット・モデルを構成します。

  • com.tangosol.coherence.servlet.MonolithicHttpSessionCollectionは、モノリシック・モデルを構成します。

  • com.tangosol.coherence.servlet.TraditionalHttpSessionCollectionは、トラディショナル・モデルを構成します。

例5-1は、モノリシック・モデルを構成するためのweb.xmlエントリを示しています。

例5-1 セッション・モデルの構成

...
<context-param>
   <param-name>coherence-sessioncollection-class</param-name>
   <param-value>com.tangosol.coherence.servlet.MonolithicHttpSessionCollection</param-value>
</context-param>
...

5.1.6 クラスタ環境でのデータの共有

クラスタ化によって、アプリケーションのスケーラビリティと可用性を高めることができます。Coherence*Webなどのクラスタ化ソリューションは開発者の多くの問題を解決しますが、開発を成功させるためには、基礎となるテクノロジの制限とその対処方法を認識する必要があります。開発者は、プラットフォームが提供する機能とユーザーの要求内容を把握することによって、これら2つの間のギャップを埋めることができます。

セッション属性を複数のJVM間で処理する場合は、属性をシリアライズ可能にする必要があります。これはクラスタ化では必須です。セッション属性の一部のフィールドを非クラスタ化することもできます。その場合、対象のフィールドを一時フィールドとして宣言します。それによって、セッション属性のすべてのフィールドをシリアライズ可能にする必要はなくなりますが、このような属性はバックアップ・サーバーに完全にレプリケートされません。アプリケーションの開発時にこのアプローチを採用する場合は、属性フィールドが失われても、アプリケーションで一貫性のある動作が可能なことを入念に確認する必要があります。一般に、このアプローチを採用すると、すべてのセッション属性をシリアライズ可能オブジェクトに単純に変換する場合よりも、作業が難しくなります。しかし、セッション内でユーザー固有のデータが大量にキャッシュされる場合は、このパターンが役立つことがあります。

Java EEサーブレットの仕様(バージョン2.2、2.3および2.4)では、サーブレットのコンテキストをクラスタ内で共有しないように規定しています。サーブレットのコンテキストをシングルトン・データ構造として使用している非クラスタ化アプリケーションでは、クラスタ環境への移行時に移植の問題が発生します。

クラスタ環境で発生する、より複雑な問題として、オブジェクトの共有の問題があります。クラスタ化されていないアプリケーションでは、2つのセッション属性が共通オブジェクトを参照している場合、その共通オブジェクトに対する変更は両方のセッション属性の一部として参照可能です。しかし、クラスタ化されたアプリケーションでは、多くの場合、これと異なります。ほとんどのセッション管理の実装では、計算リソースを無駄に使用しないために、必要に応じて個別にセッション属性のシリアライズとデシリアライズが実行されます。Coherence*Webは、(トラディショナルおよびスプリット・セッション・モデルにおいて)通常、この方法で動作します。共通オブジェクトを参照する2つのセッション属性を個別にデシリアライズする場合、共有されている共通オブジェクトは2回インスタンス化されます。共有されているオブジェクトの動作に依存する、容易に修正できないアプリケーション向けに、Coherence*Webは、セッション・オブジェクト全体を単一操作としてシリアライズおよびデシリアライズするモノリスティック・セッション・モデルのオプションを備えています。これによって、もともとクラスタ化を考慮して設計されていないアプリケーションに対する互換性が確保されます。

多くのプロジェクトが、複数のWebアプリケーション間でのセッション・データの共有を必要とします。この場合の課題は、通常、Webアプリケーションごとに固有のクラス・ローダーがあることです。それが原因で、Webアプリケーション間でのオブジェクトの共有が難しくなります。回避策として使用できる一般的な方法が2つありますが、それぞれ固有のトレードオフがあります。

  • 共通クラスをJava CLASSPATHに配置することによって、共通クラスのインスタンスを複数のアプリケーションで共有できます。ただし、この場合、構成が通常より若干複雑になります。

  • Coherence*Webを使用して、クラス・ローダーの境界間でセッション・データを共有します。各Webアプリケーションは、たとえ同じJVM内で実行されていても、独立したクラスタ・メンバーとして扱われます。このアプローチでは、Webアプリケーション間が疎結合されます(シリアライズ・クラスが共通のシリアル・バージョンUIDを共有していることが前提となります)。ただし、この場合、クラスタ・メンバー間の転送のためにオブジェクトをシリアライズ/デシリアライズする必要があるため、パフォーマンスに影響します。

5.1.7 スケーラビリティとパフォーマンス

クラスタ環境への移行時には、セッション・サイズが重要な考慮事項になります。メモリー使用量は、アプリケーションがクラスタ化されるかどうかにかかわらず影響要因となりますが、クラスタ化アプリケーションの場合はさらに、セッションが大規模な場合のCPU使用率とネットワーク負荷の増加についても考慮する必要があります。メモリー内セッションを使用する非クラスタ化アプリケーションではセッション状態のシリアライズ/デシリアライズは必要ありませんが、クラスタ化アプリケーションではセッション状態の更新時に毎回シリアライズ/デシリアライズを実行する必要があります。セッション状態のシリアライズと、その後のネットワークを介した転送は、アプリケーションのパフォーマンスに影響を及ぼす重要な要因になります。このような理由などから、サーバーでは、通常、セッション・サイズを2、3KB以下に制限する必要があります。

Coherence*Webのトラディショナル・セッション・モデルとモノリシック・セッション・モデルでは制限要因が共通していますが、スプリット・セッション・モデルは大規模なHTTPセッションを効率よくサポートするように明示的に設計されています。単一のクラスタ化されたキャッシュ・エントリを使用して小さいセッション属性のすべてを格納することによって、セッションまたはその比較的小さい属性に対するアクセスや更新時にネットワーク通信量が最小化されます。各属性を個別にデシリアライズすることによって、CPU使用率も最小化されます。Coherence*Webは、比較的大きいセッション属性を独立したクラスタ化キャッシュ・エントリに分離します。そのため、アプリケーションでそのような大きいセッション属性に関連するコストが発生するのは、対象の属性へのアクセスまたは属性の更新が実際に実行されたときのみに限定されます。また、Coherence*WebではCoherenceのデータ管理機能が活用されるため、ニア・キャッシング、NIOバッファ・キャッシング、ディスクベースのオーバーフローなど、基礎となるすべての機能をセッション属性管理に利用できます。

図5-5は、セッション・サイズに応じたパフォーマンスを示しています。各セッションは、10個の10文字の文字列と0 - 4個の10,000文字の文字列で構成されています。各HTTPリクエストでは、小さい属性1つと、大きい属性1つ(セッション内に大きい属性が存在する場合)が読み取られ、リクエストの50%でこれらの属性が更新されます。2つのサーバーから成るクラスタで、テストが実行されました。トラディショナル・モデルとモノリシック・モデルのパフォーマンスはだいたい同じである点に注目してください。文字列のシリアライズ/デシリアライズでは最小限のCPUリソースしか消費されないため、実際に使用された属性のみのデシリアライズによるパフォーマンスの向上はほとんどありません。スプリット・モデルによるパフォーマンスの向上率は、セッション・サイズが1MB(大きな文字列100個)に達するまでに37:1を超えます。特筆すべき点として、クラスタ環境では、基本的なデータにしかアクセスしないアプリケーション・リクエストについては、スケーラビリティとパフォーマンスの向上の可能性があります。これは、セッションを妥当なサイズに抑える必要がある理由の1つとなっています。

図5-5 セッション・サイズに応じたパフォーマンス

この図については前の文で説明しています。

もう1つの最適化方法は、セッション属性クラスでの一時データ・メンバーの使用です。Javaのシリアライズ・ルーチンは、一時フィールドを無視するため、セッション属性がクラスタ化されているか、単一のクラスタ・メンバーに分離されているかを制御するための非常に便利な手段になります。これは、データが他のデータソースから遅延ロードされる(したがって、サーバーのフェイルオーバー・プロセスでは再計算される)場合や、絶対的な信頼性を必要としないシナリオで役立ちます。セッション状態の一部が失われてもアプリケーションに支障がなく、ユーザーへの影響がゼロ(または許容範囲内)の場合は、パフォーマンス上のメリットを考慮する価値がある場合があります。同様に、スケールの大きいアプリケーションでは、セッションの喪失をセッションのタイムアウトとして処理し、ユーザーにアプリケーションへの再ログインを要求することもめずらしくありません(これには、アプリケーション・セッションの状態に関するユーザーの期待を適切に設定するという暗黙的なメリットがあります)。

スティッキー・ロード・バランシングは重要な役割を果たします。なぜなら、セッションの状態はクラスタ全体でグローバルに参照可能なわけではないためです。スケールの大きいクラスタでは、ユーザー・リクエストは、通常、一連のステートレス・ロード・バランサを介してアプリケーション層に入り、これらのバランサによって、Microsoft IISやApache HTTP Serverなどの一連のスティッキー・ロード・バランサに(ある程度ランダムに)再分配されます。これらのスティッキー・ロード・バランサは、リクエストのHTTPヘッダーを解析して、そのリクエストを処理しているサーバー・インスタンスを(セッションCookieに指定されたサーバーIDに基づいて)判別するという、より集中的な計算を必要とする処理を行います。なんらかの理由でリクエストが誤ってルーティングされた場合、セッションの整合性が失われます。たとえば、一部のロード・バランサでは、大量(64KB超など)のPOSTデータを含むリクエストのHTTPヘッダーが解析されず、このようなリクエストが適切なサーバー・インスタンスにルーティングされないことがあります。ルーティング障害のその他の原因として、セッションCookie内のサーバーIDの破損や形式の誤りなどがあります。これらの問題のほとんどは、ロード・バランサを適切に選択するとともに、可能な場合はアプリケーションの設計で耐久力を組み込むこと(たとえば、大きなPOSTリクエストではいずれもセッション状態に対するアクセスや変更を行わないなど)によって対処できます。

スティッキー・ロード・バランシングはCoherence*Webのパフォーマンスを促進しますが、必須ではありません。Coherence*WebはCoherenceデータ管理プラットフォームを基盤としているため、すべてのセッション・データがクラスタ全体でグローバルに参照可能です。Coherence*Webの標準的なデプロイメントでは、セッション・データがニア・キャッシュ・トポロジに配置されます。このトポロジでは、パーティション化されたキャッシュの使用により、膨大なデータがスケーラビリティとフォルト・トレランスのある方法で管理されるとともに、各アプリケーション・サーバーJVMのローカル・キャッシュによって、よく使用されるセッション状態へのアクセスが迅速化されます。スティッキー・ロード・バランサはCoherence*Web使用時に必須というわけではありませんが、このバランサの使用によって2つの重要なメリットが得られます。ニア・キャッシュ・テクノロジが使用されるため、ユーザー・リクエストが常に同じサーバーにルーティングされるのであれば、セッション属性への読取りアクセスが迅速化されます。なぜなら、ローカル・キャッシュを使用することで、コストのかかるセッション属性のデシリアライズとネットワーク転送が不要になるためです。また、スティッキー・ロード・バランシングによって、Coherenceで並行性をローカルで管理できるようになります。ユーザー・リクエストが別のサーバーにリバランスされるときにのみ、セッション・ロックが転送されます。

5.2 セッションとセッション属性のスコープ設定

Coherence*Webを使用すると、アプリケーション境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定(共有)するかについてきめ細かな制御が可能になります。

5.2.1 セッション・スコープ設定

Coherence*Webを使用すると、同じWebコンテナまたは別々のWebコンテナにデプロイした複数のWebアプリケーションでセッション・データを共有できます。これを行うには、セッションCookieコンテキスト・パラメータを正しく構成して、セッション属性に保存したオブジェクトのクラスを各Webアプリケーションで使用できるようにする必要があります。

Cookieを使用してセッションIDを保存している場合(つまり、URLリライティングを使用していない場合)、セッションCookieパスには、セッション・データを共有するすべてのWebアプリケーションの共通コンテキスト・パスを設定する必要があります。たとえば、/web/HRPortalと/web/InWebのコンテキスト・パスで登録した2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-pathパラメータを/webに設定する必要があります。一方、/HRPortalと/InWebのコンテキスト・パスで2つのWebアプリケーションを登録している場合は、coherence-session-cookie-pathパラメータをスラッシュ(/)に設定する必要があります。

セッション・データの共有を必要とする複数のWebアプリケーションのそれぞれを、互いに別のマシンで実行している別のWebコンテナにデプロイしている場合に、これらのマシンに共通のロード・バランシングを適用していないと、セッションCookieドメインをこれらのマシンで共有しているドメインに構成することも必要です。たとえば、server1.mydomain.comとserver2.mydomain.comで実行している2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-domainコンテキスト・パラメータを.mydomain.comに設定する必要があります。

共有セッションに保存したオブジェクトを適切にシリアライズまたはデシリアライズするには、セッション属性に保存したすべてのオブジェクトのクラスを、セッション・データを共有するWebアプリケーションで使用できるようにする必要があります。


注意:

EARクラスタ・ノードのスコープ設定またはアプリケーション・サーバーJVMクラスタのスコープ設定を採用し、かつ個々のWebアプリケーション間でセッション・データを共有しない高度な用途は、「Webアプリケーション間でのセッション・データ共有の禁止」を参照してください。

5.2.1.1 Webアプリケーション間でのセッション・データ共有の禁止

同じCoherenceクラスタに属する複数のJava EEアプリケーションであっても、HTTPセッション・データを共有しないようにすることが必要な場合があります。たとえば、Enterprise JavaBeans (EJB)層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。これを実行する方法の1つは、ApplicationScopeControllerインタフェースを使用して、アプリケーションの属性のスコープを定義することです。「セッション属性スコープ設定」でこの手法について説明します。もう1つの方法は、アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定することです。

アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定する手順は、次のとおりです。

  1. アプリケーションの各default-session-cache-config.xmlファイルで、<service-name/>要素を探します。

  2. この要素をアプリケーションごとに異なる一意の値に設定します。

    これによって、セッション・データについては、アプリケーションごとに別々のクラスタ・サービスを使用できるようになります。

  3. 変更したdefault-session-cache-config.xmlファイルをアプリケーションに組み込みます。

例5-2は、あるHRPortalアプリケーションのdefault-session-cache-config.xmlファイルの例です。HRPortalアプリケーションとInWebアプリケーションとの間でセッション・データを共有しないようにするには、レプリケートするスキームの<service-name>要素の名前をReplicationSessionsMiscHRPに変更します。分散スキームの<service-name>要素の名前をDistributedSessionsHRPに変更します。

例5-2 アプリケーション間でセッション・データを共有しないようにするための構成

<replicated-scheme>
  <scheme-name>default-replicated</scheme-name>
  <service-name>ReplicatedSessionsMisc</service-name> // rename this to ReplicatedSessionsMiscHRP 
  <backing-map-scheme>
    <class-scheme>
      <scheme-ref>default-backing-map</scheme-ref>
    </class-scheme>
  </backing-map-scheme>
</replicated-scheme>

<distributed-scheme>
  <scheme-name>session-distributed</scheme-name>
  <service-name>DistributedSessions</service-name> // rename this to DistributedSessionsHRP
  <lease-granularity>member</lease-granularity>
  <backing-map-scheme>
    <class-scheme>
      <scheme-ref>default-backing-map</scheme-ref>
    </class-scheme>
  </backing-map-scheme>
</distributed-scheme>

<distributed-scheme>
  <scheme-name>session-certificate</scheme-name>
  <service-name>DistributedSessions</service-name> // rename this to DistributedSessionsHRP
  <lease-granularity>member</lease-granularity>
  <backing-map-scheme>
    <local-scheme>
      <scheme-ref>session-certificate-autoexpiring</scheme-ref>
    </local-scheme>
  </backing-map-scheme>
</distributed-scheme>

5.2.1.2 複数のキャッシュ構成の操作

Coherence*Webで実行している複数のアプリケーションを操作する場合、それらに複数の異なるキャッシュ構成を設定できます。この場合、キャッシュ・サーバーのキャッシュ構成には、記憶域を有効化して実行しているか記憶域を無効化して実行しているかに関係なく、これらのキャッシュ構成の和を含める必要があります。これにより、同じキャッシュ・クラスタでそれらのアプリケーションをサポートできます。

5.2.1.3 セッションCookieの独立性の維持

Cookieを使用してセッションIDを保存している場合は、あるアプリケーションで作成したセッションCookieが別のアプリケーションに伝播されないようにする必要があります。これを行うには、各アプリケーションのweb.xmlファイルで、そのアプリケーションのセッションCookieのドメインとパスを設定する必要があります。Cookieが伝播されないようにするには、2つのアプリケーションで同じコンテキスト・パスを共有しないようにします。

たとえば、2つのWebアプリケーションをそれぞれ/web/HRPortalと/web/InWebのコンテキスト・パスで登録しているとします。これらのWebアプリケーションがCookieでセッション・データを共有しないようにするには、一方のアプリケーションのCookieパスを/web/HRPortalに設定し、もう一方のアプリケーションのCookieパスを/web/InWebに設定します。

それぞれ別のマシンで実行している異なるWebコンテナに複数のアプリケーションをデプロイした場合、それらが同じドメインにならないようにCookieドメインを構成できます。

たとえば、2つのWebアプリケーションをserver1.mydomain.comとserver2.mydomain.comで実行しているとします。それらの間でセッションCookieを共有しないようにするには、一方のアプリケーションのCookieドメインをserver1.mydomain.comに設定し、もう一方のアプリケーションのCookieドメインをserver2.mydomain.comに設定します。

5.2.2 セッション属性スコープ設定

複数のWebアプリケーションでセッションを共有している場合は、セッション属性をグローバルに認識できるように(すべてのWebアプリケーションからアクセスして変更できるようにする)、または逆に個々のWebアプリケーションのみで認識できるように(他のアプリケーションのインスタンスからはアクセスできないようにする)、個々のセッション属性のスコープをアプリケーションで設定することが必要になる場面が数多くあります。

Coherence*Webでは、この動作はAttributeScopeControllerインタフェースを使用して制御できます。複数のアプリケーションでセッションを共有する場合に、このオプション・インタフェースを使用して属性を選択的にスコープ設定できます。これにより、他のアプリケーションの属性を誤って読取り、更新、削除することなく、複数のアプリケーションでアプリケーション・スコープ状態について同じ属性名を使用できます。セッションでは、アプリケーション別スコープを設定した情報のほか、セッションを共有するすべてのアプリケーションで読取り、更新、および削除できるグローバルな(スコープ設定していない)情報を保持することもできます。

AttributeScopeControllerインタフェースの2つの実装(ApplicationScopeControllerとGlobalScopeController)が使用できます。GlobalScopeControllerの実装は属性のスコープを設定しませんが、ApplicationScopeControllerでは、すべての属性名の先頭にアプリケーションの名前を追加することによって、すべての属性のスコープをアプリケーションに設定します。

coherence-application-nameコンテキスト・パラメータを使用して、アプリケーション(およびアプリケーションが記述されたWebモジュール)の名前を指定します。ApplicationScopeControllerインタフェースでは、アプリケーションの名前を使用して属性のスコープを設定します。このパラメータを構成しない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。詳細は、表2-2のcoherence-application-nameの説明を参照してください。


注意:

構成済のAttributeScopeController実装は、作成後、属性名の修飾に使用できるWebアプリケーションの名前を使用して初期化されます。coherence-application-nameコンテキスト・パラメータを使用して、Webアプリケーションの名前を構成します。

5.2.2.1 複数のアプリケーション間におけるセッション情報の共有

Coherence*Webでは、複数のアプリケーションが同じセッション・オブジェクトを共有できます。これを行うには、セッション属性がすべてのアプリケーションから参照可能である必要があります。また、WebLogic Serverで処理するURLにおいてCookieを受信できるURLを指定する必要があります。

アプリケーションでセッション属性の共有および変更ができるようにするには、web.xmlファイルのcoherence-scopecontroller-classコンテキスト・パラメータの値としてGlobalScopeController (com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController)インタフェースを参照します。GlobalScopeControllerは、com.tangosol.coherence.servlet.HttpSessionCollection$AttributeScopeControllerインタフェースの実装であり、これによって個別のセッション属性をグローバルに参照できます。

例5-3は、web.xmlファイルで指定されたGlobalScopeControllerインタフェースを示しています。

例5-3 web.xmlで指定されたGlobalScopeController

<?xml version="1.0" encoding="UTF-8"?>  <web-app>    ...
    <context-param>
      <param-name>coherence-scopecontroller-class</param-name>
      <param-value>com.tangosol.coherence.servlet. AbstractHttpSessionCollection$GlobalScopeController</param-value>
    </context-param>
    ...
  </web-app>

5.3 クラスタ・ノード分離

Coherence*Webをデプロイする方法はいくつかあります。デプロイメント・オプションについて決定するときの考慮事項の1つは、クラスタ・ノード分離です。クラスタ・ノード分離の考慮事項は次のとおりです。

アプリケーションには、アプリケーション・サーバー・スコープ、EARスコープ、またはWARスコープを設定できます。この項では、これらの考慮事項について説明します。これらの各オプションに対するXML構成の詳細は、「Coherence*Webの記憶域モードの構成」を参照してください。

5.3.1 アプリケーション・サーバー・スコープ設定クラスタ・ノード

この構成では、Coherence*Webを使用するコンテナにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、クラスタに作成されるCoherenceノードの数が最小となります(WebコンテナJVMごとに1つ)。また、Coherenceライブラリ(coherence.jar)がコンテナのクラスパスにデプロイされるので、JVMにロードされるCoherenceクラスのコピーは1つのみです。これによって、リソースの使用が最小限に抑えられます。その一方で、すべてのアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのアプリケーションに不具合があるとすべてのアプリケーションが影響を受けます。

図5-6に、クラスタ・ノード(アプリケーション・サーバー・インスタンス)が2つのアプリケーション・サーバー・スコープ設定クラスタを示します。Coherence*Webは各インスタンスのクラスパスにデプロイされているため、各インスタンスはCoherenceノードと見なすことができます。各ノードには2つのEARファイルが含まれ、それぞれのEARファイルには2つのWARファイルが含まれます。各インスタンスで実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスを共有します。

図5-6 アプリケーション・サーバー・スコープ設定クラスタ

アプリケーション・サーバー・スコープ設定クラスタ
「図5-6 アプリケーション・サーバー・スコープ設定クラスタ」の説明

WebLogic Serverでは、すべてのCoherence*Web対応アプリケーションがアプリケーション・サーバー・スコープを持ちます。WebLogic Serverのアプリケーション・サーバー・スコープ設定クラスタ・ノードのXML構成要件の詳細は、「Coherence*Webの記憶域モードの構成」を参照してください。

すべてのCoherence*Web対応アプリケーションがアプリケーション・サーバー・スコープを持ちます。アプリケーション・サーバー・スコープはGlassFish Serverでは使用できません。


注意:

アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。

このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。

このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択したらよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。

5.3.2 EARスコープ設定クラスタ・ノード

この構成では、EARファイルごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、Coherence*Webを使用するデプロイ済EARファイルごとに1つのCoherenceノードが作成されます。Coherenceライブラリ(coherence.jar)がアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーはEARファイルごとに1つです。EARファイル内のすべてのWebアプリケーションが同じクラスタ・ノードを使用するので、いずれかのWebアプリケーションに不具合があるとEARファイル内のすべてのWebアプリケーションが影響を受けます。

図5-7は、4つのEARスコープ設定クラスタ・ノードを示します。Coherence*Webは各EARファイルにデプロイされているため、各EARファイルがクラスタ・ノードとなります。各EARファイル内で実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスへのアクセス権を持ちます。

図5-7 EARスコープ設定クラスタ

EARスコープ設定クラスタ
「図5-7 EARスコープ設定クラスタ」の説明

EARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。このオプションは、1つのアプリケーション・サーバーにデプロイするEARファイルを1つのみとする場合にも適しています。

EARスコープ設定クラスタ・ノードのXML構成要件の詳細は、「EARスコープ設定クラスタ・ノードの構成」を参照してください。


注意:

この構成は、WebLogic Serverプラットフォームで実行されているCoherence*Webアプリケーションでは使用できません。WebLogic Serverプラットフォームで実行されているアプリケーションに対して可能なのは、アプリケーション・サーバー・スコープ設定のみです。

5.3.3 WARスコープ設定クラスタ・ノード

この構成では、デプロイしたWebアプリケーションごとに専用のCoherenceノードがあります。この構成でクラスタに作成されるCoherenceノードの数は最多となります(Coherence*Webを使用するデプロイ先WARファイルごとに1つずつ)。Coherenceライブラリ(coherence.jar)がWebアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーの数はデプロイ先WARファイルと同じ数になります。その結果、3種類の構成オプションの中で最もリソース使用率が高くなります。ただし、デプロイしたWebアプリケーションごとに専用のクラスタ・ノードがあるので、いずれかのWebアプリケーションに不具合があっても、他のWebアプリケーションは分離されているので影響を受けません。

WARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。このオプションは、1つのアプリケーション・サーバーにデプロイするWARファイルを1つのみとする場合にも適しています。

図5-8に、アプリケーション・サーバー内のWARファイルの2つの異なる構成を示します。各WARファイルにはCoherence*Web(およびCoherence)のコピーが含まれているため、これはクラスタ・ノードと見なすことができます。

図5-8 WARスコープ設定クラスタ

WARスコープ設定クラスタ
「図5-8 WARスコープ設定クラスタ」の説明

WARスコープ設定クラスタ・ノードのXML構成要件の詳細は、「WARスコープ設定クラスタ・ノードの構成」を参照してください。


注意:

この構成は、WebLogic Serverプラットフォームで実行されているCoherence*Webアプリケーションでは使用できません。WebLogic Serverプラットフォームで実行されているアプリケーションに対して可能なのは、アプリケーション・サーバー・スコープ設定のみです。

5.4 セッション・ロック・モード

Oracle Coherenceには、HTTPセッションへの同時アクセスを実現する次の構成オプションが用意されています。


注意:

一般的に、同じクラスタに属するWebアプリケーションは、同じロック・モードおよびスティッキー・セッション最適化設定を使用する必要があります。構成に一貫性がないと、デッドロックが発生することがあります。

Webアプリケーションが使用するセッション・ロッキング・モードを指定するには、coherence-session-locking-modeコンテキスト・パラメータを設定します。表5-1は、コンテキスト・パラメータの値と、それによって指定されるセッション・ロッキング・モードを示しています。coherence-session-locking-modeコンテキスト・パラメータの詳細は、次の項と、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

表5-1 coherence-session-locking-modeコンテキスト・パラメータ値の一覧

ロック・モード coherence-session-locking-modeの値

オプティミスティック・ロック

optimistic

最後の書込みを優先するロック

none

メンバー・ロック

member

アプリケーション・ロック

app

スレッド・ロック

thread

5.4.1 オプティミスティック・ロック

オプティミスティック・ロック・モードを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。ConcurrentModificationException例外のスローはセッションがキャッシュにフラッシュされたときに行われ、これはサーブレット・リクエストが処理を終了した後になります。例外を表示するには、コンテナの起動スクリプトでweblogic.debug.DebugHttpSessionsシステム・プロパティをtrueに設定します(例: -Dweblogic.debug.DebugHttpSessions=true)。

オプティミスティック・ロック・モードは、coherence-session-locking-modeパラメータをoptimisticに設定することにより構成できます。

5.4.2 最後の書込みを優先するロック

Coherence*WebとCoherence*Web SPIは、デフォルトで最後の書込みを優先するロックを使用するように構成されています。最後の書込みを優先するロックは、オプティミスティック・ロック・モードの一種です。これを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了時に同時更新は防止されません。かわりに、最後の書込み、つまり最終変更によってセッションが変更されます。

最後の書き込みを優先するロック・モードは、coherence-session-locking-modeパラメータをnoneに設定することにより構成できます。この値により、セッションに対して最後の更新が適用される同時変更ができます。

5.4.3 メンバー・ロック

メンバー・ロック・モードを使用すると、同じクラスタ・ノードにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスして変更できますが、別々のメンバーにあるスレッドからは同時にアクセスできません。これは、HTTPセッションを取得したときに、そのセッションのメンバー・レベルのロックを取得することによって実現されます。ロックはHTTPリクエストの完了時に解放されます。メンバー・レベルのロックの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のdistributed-schemeに関する項で<lease-granularityを参照してください。

メンバー・ロック・モードは、coherence-session-locking-modeパラメータをmemberに設定することにより構成できます。

5.4.4 アプリケーション・ロック

アプリケーション・ロック・モードでは、1つのWebアプリケーション・インスタンスにある一連のスレッドからのみセッションに同時にアクセスし、変更できます。この動作は、セッションの取得時点でHTTPセッションに対するメンバー・レベルのロックとアプリケーション・レベルのロックの両方を取得して、HTTPリクエストの完了時点で両方のロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のdistributed-schemeに関する項で<lease-granularityを参照してください。

アプリケーション・ロック・モードは、coherence-session-locking-modeパラメータをappに設定することにより構成できます。

5.4.5 スレッド・ロック

スレッド・ロック・モードでは、一度に1つのメンバーにある1つのスレッドからのみセッションにアクセスし、変更できます。この動作は、セッションの取得時点でHTTPセッションに対するメンバー・レベルのロック、アプリケーション・レベルのロックおよびスレッド・レベルのロックを取得して、リクエストの完了時点でそれらの3つすべてのロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のdistributed-schemeに関する項で<lease-granularityを参照してください。

スレッド・ロック・モードは、coherence-session-locking-modeパラメータをthreadに設定することにより構成できます。

5.4.6 HTTPセッションでのロックのトラブルシューティング

HTTPセッション・アクセスに対してメンバー、アプリケーションまたはスレッドのロックを有効にすることは、セッションへのアクセスを必要とする各HTTPリクエストに対してCoherence*Webがクラスタ規模のロックを取得することを意味します。デフォルトでは、ロックされたセッション(別のメンバーにあるスレッドでロックされたセッション)にアクセスしようとするスレッドは、ロックが取得できるまでアクセスをブロックします。ロック取得のタイムアウトを有効にする場合は、これをcoherence-session-get-lock-timeoutコンテキスト・パラメータで構成します。次に例を示します。

...  
<context-param>
    <param-name>coherence-session-get-lock-timeout</param-name>
    <param-value>30</param-value>
  </context-param>
...

多くのWebアプリケーションには、このような厳しい同時処理要件がありません。このようなアプリケーションの場合は、オプティミスティック・ロック・モードを使用することによって、次のようなメリットが得られます。

  • HTTPリクエストのたびにクラスタ規模のロックを取得して解放することで発生するオーバーヘッドを排除できます。

  • 障害が発生したメンバーや応答しないメンバーからアクティブなメンバーにリクエストをルーティングして負荷分散できます。クラスタ規模でセッションに適用されているロックの解放を、応答しなくなったメンバーに要求する必要がありません。

Coherence*Webは、メンバーがセッションに対してクラスタ・ロックを取得できない場合に実行される診断起動サービスを提供します。このサービスを有効にするかどうかはcoherence-session-log-threads-holding-lockコンテキスト・パラメータで設定します。このコンテキスト・パラメータをtrue(デフォルト)に設定した場合、この起動サービスによって、セッションの所有権を持つメンバーが、現在ロックを保持しているスレッドのスタック・トレースを記録するようになります。

coherence-session-log-threads-holding-lockコンテキスト・パラメータは、coherence-sticky-sessionsコンテキスト・パラメータがtrueに設定されている場合にのみ使用可能です。このような要件があるのは、スティッキー・セッションの最適化が有効でないかぎり、Coherence Webが各セッション・アクセス・リクエストごとにクラスタ規模のロックを取得するためです。スティッキー・セッションの最適化を有効にすることにより、頻繁なロックの保持およびそれに続く多数のログ・ファイルの生成を回避できます。

すべてのCoherence*Webメッセージと同様に、Coherence logging-config操作構成要素によって、メッセージの記録方法が制御されます。Coherenceにおけるロギングの構成方法の詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のオペレーション構成要素に関する項にあるlogging-configの説明を参照してください。

5.4.7 スティッキー・セッション最適化の有効化

スティッキー・ロード・バランサの対象となっているWebアプリケーションの要件としてメンバー・ロック、アプリケーション・ロック、またはスレッド・ロックがある場合は、HTTPセッションへのアクセスに必要なクラスタ規模のロックの取得をCoherence*Webで最適化できます。その名が示すとおり、スティッキー・ロード・バランサは、セッションに対する各リクエストを、前回そのセッションでリクエストの転送先として使用されたものと同じアプリケーション・サーバーJVMにルーティングしようとします。これは、そのセッションを作成したアプリケーション・サーバーJVMと同じものです。スティッキー・セッション最適化では、セッションに対するクラスタ規模のロックをそのセッションの有効期限が切れるまで、または解放するよう要求されるまで保持することによって、この動作を利用しています。なんらかの理由で、スティッキー・ロード・バランサが同じセッションに対するリクエストを別のアプリケーション・サーバーJVMに送信した場合は、そのJVMから該当セッションのロックを保持しているJVMに対して、できるだけ早くロックを解放するよう要求します。詳細は、表C-2のSessionOwnershipエントリを参照してください。

スティッキー・セッション最適化は、coherence-sticky-sessionsコンテキスト・パラメータをtrueに設定すると有効になります。この設定では、メンバー、アプリケーションまたはスレッドのロックが有効になっている必要があります。

5.5 デプロイメント・トポロジ

Coherence*Webでは、Coherenceで使用できるデプロイメント・トポロジのほとんどを使用できます。これには、インプロセス・トポロジ、アウトオブプロセス・トポロジ(クライアント/サーバー・デプロイメント)、Coherence*Extendを介してクライアントとサーバーをブリッジするトポロジなどがあります。サポートされている主なデプロイメント・トポロジについて次で説明します。

5.5.1 インプロセス・トポロジ

インプロセス・トポロジは、本番環境での使用にはお薦めできません。主に、開発用とテスト用としてサポートされています。このトポロジは、アプリケーション・サーバーを使用してセッション・データをプロセス内で保存することで、容易に起動して、スモーク・テスト、開発、およびテスト用として高速で実行できます。このトポロジでは、ローカル記憶域が有効化(tangosol.coherence.distributed.localstorage=true)されます。

図5-9に、インプロセス・トポロジを示します。すべてのアプリケーション・サーバーが同じセッション・データ・キャッシュと通信します。

図5-9 インプロセス・デプロイメント・トポロジ

インプロセス・デプロイメント・トポロジ
「図5-9 インプロセス・デプロイメント・トポロジ」の説明

5.5.2 アウトオブプロセス・トポロジ

アウトオブプロセス・デプロイメント・トポロジでは、アプリケーション・サーバー(アプリケーション・サーバー層)をキャッシュ・クライアントとして構成し(tangosol.coherence.distributed.localstorage=false)、クラスタ化データを物理的に保存および管理してキャッシュ・サーバーとして動作する専用のJVMを配置します。

このアプローチには次のようなメリットがあります。

  • セッション・データ記憶域の負荷を、アプリケーション・サーバー層からキャッシュ・サーバー層に移管できます。これによって、ヒープ使用量やガベージ・コレクション時間などを低減できます。

  • アプリケーションとキャッシュ・サーバー層は、独立してスケールできます。アプリケーションの処理能力が不足している場合は、起動するアプリケーション・サーバーの数を増やすだけですみます。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やすだけです。

アウトオブプロセス・トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。図5-10に、アウトオブプロセス・トポロジを示します。アプリケーション層の各サーバーは、独自のニア・キャッシュを保持します。これらのニア・キャッシュは、別のキャッシュ・サーバー層で実行されるセッション・データ・キャッシュと通信します。

図5-10 アウトオブプロセス・デプロイメント・トポロジ

アウトオブプロセス・デプロイメント・トポロジ
「図5-10 アウトオブプロセス・デプロイメント・トポロジ」の説明

5.5.2.1 インプロセス・トポロジからアウトオブプロセス・トポロジへの移行

アプリケーションをインプロセス・トポロジからアウトオブプロセス・トポロジに容易に移行できます。このためには、アプリケーション・サーバーに加えてキャッシュ・サーバーを実行する必要があります。キャッシュ・サーバーを記憶域有効モードで起動し、これがアプリケーション・サーバーで使用しているものと同じセッションおよびキャッシュ構成ファイル(default-session-cache-config.xml)を参照するようにします。記憶域無効モードでアプリケーション・サーバーを起動します。詳細は、「アウトオブプロセス・トポロジへの移行」を参照してください。

5.5.3 Coherence*Extendによるアウトオブプロセス・トポロジ

Coherence*Extendは、クラスタの外部で実行されるExtendクライアント(またはプロキシ)と、1台以上のキャッシュ・サーバーでホストされているクラスタ内で実行される拡張プロキシ・サービスの2つの基本コンポーネントで構成されます。Coherence*Extendによるアウトオブプロセス・トポロジは、アウトオブプロセス・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由(TCP/IP)で行う点が異なります。このシナリオの構成手順は、「Coherence*ExtendによるCoherence*Webの構成」を参照してください。Coherence*Extendの詳細は、『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』を参照してください。

このアプローチには、アウトオブプロセス・トポロジと同じメリットがあるほか、アプリケーション・サーバーとキャッシュ・サーバーのデプロイメントをセグメントに分割する機能もあります。この特性は、UDPをサポートしていないネットワーク上にアプリケーション・サーバーが存在する環境に最適です。TCPを使用してクラスタにアプリケーション・サーバーを接続した上で、独立した専用のネットワークにキャッシュ・サーバーを配置できます。

図5-11に、Coherence*Extendによるアウトオブプロセス・トポロジを示します。アプリケーション・サーバー層のサーバー内のニア・キャッシュは、拡張プロキシを使用して、キャッシュ・サーバー層のセッション・データ・キャッシュと通信します。

図5-11 Coherence*Extendによるアウトオブプロセス・デプロイメント・トポロジ

Coherence*Extendによるアウトオブプロセス・トポロジ
「図5-11 Coherence*Extendによるアウトオブプロセス・トポロジ」の説明

5.5.4 Coherence*ExtendによるCoherence*Webの構成

Coherence*Webのデプロイメント・オプションの1つに、Coherence*Extendを使用して、WebコンテナのJVMをTCP/IP経由でクラスタに接続する方法があります。この構成は、次のいずれかの状況が該当する場合に検討してください。

  • Web層JVMがDMZにあるのに、Coherenceクラスタがファイアウォールの内側にあります。

  • Web層がUDPをサポートしていない環境に作成されています。

  • Web層JVMで、ガベージ・コレクション(GC)が長時間または頻繁に一時停止します。

  • Web層JVMが頻繁に再起動します。

これらのデプロイメントの参加者には、次の3種類があります。

  • Web層JVMは、このトポロジではExtendクライアントとして機能します。クラスタのメンバーにはならず、クラスタ内のプロキシ・ノードに接続します。クラスタへのリクエストの発行は、そのプロキシ・ノードが代行します。

  • プロキシJVMは、クラスタ内の記憶域が無効なメンバー(ノード)として、ExtendクライアントからのTCP/IP接続を受け入れ、管理します。クライアントからのリクエストはクラスタに送信され、応答はTCP/IP接続を通じて返送されます。

  • 記憶域JVMは、実際のセッション・データをメモリーに格納する際に使用されます。

Coherence*Webを構成してCoherence*Extendを使用する手順は次のとおりです。

  1. オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成します(「オプティミスティック・ロック」を参照)。

  2. プロキシおよび記憶域JVMのキャッシュ構成ファイルを構成します(「"プロキシJVMと記憶域JVMのキャッシュの構成」を参照)。

  3. Web層キャッシュ構成ファイルが1つ以上のプロキシJVMを指定するように変更します(「Web層JVMのキャッシュの構成」を参照)。

5.5.4.1 プロキシJVMと記憶域JVMのキャッシュの構成

セッション・キャッシュ構成ファイル(WEB-INF/classes/default-session-cache-config.xml)は、Coherence*Extendを使用するCoherence*Webセッションのキャッシュ構成ファイルの例です。

プロキシおよびサーバーJVMにはこのファイルを使用します。これには、同じファイルをプロキシJVMと記憶域JVMの両方に使用できるシステム・プロパティのオーバーライドが含まれます。プロキシJVMで使用する場合は、表5-2に示すシステム・プロパティを指定する必要があります。


注意:

WebLogic Serverプラットフォームのアプリケーションを記述しており、カスタマイズしたセッション・キャッシュ構成ファイルを使用している場合は、この構成ファイルをデプロイメントのためのGARファイルにパッケージ化する必要があります。詳細は、カスタム・セッション・キャッシュ構成ファイルの使用方法に関する項を参照してください。

GARファイルのパッケージ化要件の詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のWebLogic Server用のCoherenceアプリケーションのパッケージ化に関する項および『Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』のOracle WebLogic Server用のCoherenceアプリケーションの作成に関する項も参照してください。

表5-2 プロキシJVM用のシステム・プロパティ値

システム・プロパティ名 値

tangosol.coherence.session.localstorage

false

tangosol.coherence.session.proxy

true

tangosol.coherence.session.proxy.localhost

プロキシがバインドされるNICのホスト名またはIPアドレス。

tangosol.coherence.session.proxy.localport

プロキシがバインドされるポートの一意のポート番号。

キャッシュ・サーバーで使用する場合は、表5-3に示すシステム・プロパティを指定します。

表5-3 記憶域JVM用のシステム・プロパティ値

システム・プロパティ名 値

tangosol.coherence.session.localstorage

true

tangosol.coherence.session.proxy

false

例5-4は、記憶域JVMのセッション・キャッシュ構成ファイルの全内容を示しています。

例5-4 default-session-cache-config-server.xmlファイル

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
              xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!--                                                                       -->
<!-- Server-side cache configuration descriptor for Coherence*Web over     -->
<!-- Coherence*Extend (see default-session-cache-config-web-tier.xml).               -->
<!--                                                                       -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  <caching-scheme-mapping>
    <!--
    The clustered cache used to store Session management data.
    -->
    <cache-mapping>
      <cache-name>session-management</cache-name>

      <scheme-name>session-distributed</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store ServletContext attributes.
    -->
    <cache-mapping>
      <cache-name>servletcontext-storage</cache-name>
      <scheme-name>session-distributed</scheme-name>
    </cache-mapping>
    <!--
    The clustered cache used to store Session attributes.
    -->
    <cache-mapping>
      <cache-name>session-storage</cache-name>
      <scheme-name>session-distributed</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store the "overflowing" (split-out due to size)
    Session attributes. Only used for the "Split" model.
    -->
    <cache-mapping>

      <cache-name>session-overflow</cache-name>
      <scheme-name>session-distributed</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store IDs of "recently departed" Sessions.
    -->
    <cache-mapping>
      <cache-name>session-death-certificates</cache-name>
      <scheme-name>session-certificate</scheme-name>

    </cache-mapping>
  </caching-scheme-mapping>

  <caching-schemes>
    <!--
    Distributed caching scheme used by the various Session caches.
    -->
    <distributed-scheme>
      <scheme-name>session-distributed</scheme-name>
      <scheme-ref>session-base</scheme-ref>

      <backing-map-scheme>
        <local-scheme>
          <scheme-ref>unlimited-local</scheme-ref>
        </local-scheme>
      </backing-map-scheme>
    </distributed-scheme>

    <!--
    Distributed caching scheme used by the "recently departed" Session cache.
    -->
    <distributed-scheme>

      <scheme-name>session-certificate</scheme-name>
      <scheme-ref>session-base</scheme-ref>
      <backing-map-scheme>
        <local-scheme>
          <eviction-policy>HYBRID</eviction-policy>
          <high-units>4000</high-units>
          <low-units>3000</low-units>

          <expiry-delay>86400</expiry-delay>
        </local-scheme>
      </backing-map-scheme>
    </distributed-scheme>
    <!--
    "Base" Distributed caching scheme that defines common configuration.
    -->
    <distributed-scheme>
      <scheme-name>session-base</scheme-name>

      <service-name>DistributedSessions</service-name>
      <serializer>
        <instance>
          <class-name>com.tangosol.io.DefaultSerializer</class-name>
        </instance>
      </serializer>
      <thread-count>0</thread-count>
      <lease-granularity>member</lease-granularity>
      <local-storage>true</local-storage>

      <partition-count>257</partition-count>
      <backup-count>1</backup-count>
      <backup-storage>
        <type>on-heap</type>
      </backup-storage>
      <backing-map-scheme>
        <local-scheme>

          <scheme-ref>unlimited-local</scheme-ref>
        </local-scheme>
      </backing-map-scheme>
      <autostart>true</autostart>
    </distributed-scheme>

    <!--
    Proxy scheme that Coherence*Web clients used to connect to the cluster.
    -->
    <proxy-scheme>

      <service-name>SessionProxy</service-name>
      <thread-count>10</thread-count>
      <acceptor-config>
        <serializer>
          <instance>
            <class-name>com.tangosol.io.DefaultSerializer</class-name>
          </instance>
        </serializer>
        <tcp-acceptor>

          <local-address>
            <address system-property="tangosol.coherence.session.proxy.localhost">localhost</address>
            <port system-property="tangosol.coherence.session.proxy.localport">9099</port>
          </local-address>
        </tcp-acceptor>
      </acceptor-config>

      <autostart system-property="tangosol.coherence.session.proxy">false</autostart>
    </proxy-scheme>

    <!--
    Local caching scheme definition used by all caches that do not require an
    eviction policy.
    -->
    <local-scheme>
      <scheme-name>unlimited-local</scheme-name>
      <service-name>LocalSessionCache</service-name>
    </local-scheme>  
  </caching-schemes>

</cache-config>

5.5.4.2 Web層JVMのキャッシュの構成

例5-5に示されているセッション・キャッシュ構成ファイルは、coherence-web.jarファイルにあるdefault-session-cache-config.xmlファイルに基づいています。この例は、Coherence*Extendを使用するCoherence*Webキャッシュ構成ファイルを示しています。Web層JVMは、このキャッシュ構成ファイルを使用する必要があります。次の手順に従います。

Web層のセッション・キャッシュ構成ファイルをインストールする手順は次のとおりです。

  1. coherence-web.jarファイルからdefault-session-cache-config.xmlファイルを抽出します。

  2. ファイルの<remote-addresses/>セクションに、プロキシJVMのホスト名とIPアドレス、およびポートを追加します。一般には、ロード・バランシングとフェイルオーバーに備えて、すべてのプロキシJVMのホスト名、IPアドレスおよびポートを追加します。


    注意:

    <remote-addresses>要素には、Webコンテナの接続先となるプロキシ・サーバーがリストされています。デフォルトでは、Webコンテナはランダムにアドレスを選択します(複数のアドレスが構成されている場合)。Webコンテナとプロキシ間の接続が切断されると、コンテナはリスト内の別のプロキシに接続します。

  3. ファイル名をdefault-session-cache-config-web-tier.xmlに変更します。

  4. このファイルをWebアプリケーションのWEB-INF/classesディレクトリに配置します。WebInstallerを使用してCoherence*Webをインストールした場合は、WebInstallerによって追加されている既存のファイルと置き換えます。

例5-5は、クライアント側のセッション・キャッシュ構成ファイルの全内容を示しています。

例5-5 default-session-cache-config-web-tier.xmlファイル

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
              xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!--                                                                       -->
<!-- Client-side cache configuration descriptor for Coherence*Web over     -->
<!-- Coherence*Extend (see default-session-cache-config-server.xml).       -->
<!--                                                                       -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  <caching-scheme-mapping>
    <!--
    The clustered cache used to store Session management data.
    -->
    <cache-mapping>
      <cache-name>session-management</cache-name>

      <scheme-name>session-near</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store ServletContext attributes.
    -->
    <cache-mapping>
      <cache-name>servletcontext-storage</cache-name>
      <scheme-name>session-near</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store Session attributes.
    -->
    <cache-mapping>
      <cache-name>session-storage</cache-name>
      <scheme-name>session-near</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store the "overflowing" (split-out due to size)
    Session attributes. Only used for the "Split" model.
    -->
    <cache-mapping>

      <cache-name>session-overflow</cache-name>
      <scheme-name>session-remote</scheme-name>
    </cache-mapping>

    <!--
    The clustered cache used to store IDs of "recently departed" Sessions.
    -->
    <cache-mapping>
      <cache-name>session-death-certificates</cache-name>
      <scheme-name>session-remote</scheme-name>

    </cache-mapping>
  </caching-scheme-mapping>

  <caching-schemes>
    <!--
    Near caching scheme used by the Session attribute cache. The front cache
    uses a Local caching scheme and the back cache uses a Remote caching
    scheme.
    -->
    <near-scheme>
      <scheme-name>session-near</scheme-name>
      <front-scheme>
        <local-scheme>

          <scheme-ref>session-front</scheme-ref>
        </local-scheme>
      </front-scheme>
      <back-scheme>
        <remote-cache-scheme>
          <scheme-ref>session-remote</scheme-ref>
        </remote-cache-scheme>
      </back-scheme>

      <invalidation-strategy>present</invalidation-strategy>
    </near-scheme>

    <local-scheme>
      <scheme-name>session-front</scheme-name>
      <eviction-policy>HYBRID</eviction-policy>
      <high-units>1000</high-units>

      <low-units>750</low-units>
    </local-scheme>

    <remote-cache-scheme>
      <scheme-name>session-remote</scheme-name>
      <initiator-config>
        <serializer>
          <instance>
            <class-name>com.tangosol.io.DefaultSerializer</class-name>
          </instance>
        </serializer>
        <tcp-initiator>
          <remote-addresses>
            <!-- 
            The following list of addresses should include the hostname and port
            of all running proxy JVMs. This is for both load balancing and
            failover of requests from the Web tier.
            -->
            <socket-address>
              <address>localhost</address>
              <port>9099</port>
            </socket-address>

          </remote-addresses>
        </tcp-initiator>
      </initiator-config>
    </remote-cache-scheme>
  </caching-schemes>
</cache-config>

5.6 遅延取得によるセッションへのアクセス

デフォルトでは、WebInstallerで設定されたWebアプリケーションは、サーブレットまたはフィルタがコールされるたびにセッションを取得します。サーブレットまたはフィルタで実際にセッションが必要であるかどうかに関係なく、セッションは取得されます。これにより、セッションが不要なサーブレットやフィルタを多数実行すると、時間がかかる場合や処理に負担がかかる場合があります。

この動作を防止するには、web.xmlファイルのcoherence-session-lazy-accessコンテキスト・パラメータをtrueに設定して遅延取得を有効にします。サーブレットやフィルタがアクセスを試みたときにのみ、セッションは取得されます。

5.7 HTTPセッションと属性のディストリビューションのオーバーライド

HttpSessionCollection.SessionDistributionControllerインタフェースで記述されるCoherence*Webセッション・ディストリビューション・コントローラを使用すると、Webアプリケーション内のHTTPセッションと属性のデフォルトのディストリビューションをオーバーライドできます。coherence-distributioncontroller-classコンテキスト・パラメータを設定してデフォルトのディストリビューションをオーバーライドします(「セッション・ディストリビューション・コントローラの実装の登録」を参照)。コンテキスト・パラメータの値は、SessionDistributionControllerインタフェースの実装を示します。

SessionDistributionControllerインタフェースの実装では、セッションまたは属性を次のいずれかの方法で特定できます。

セッションの存続期間中であればどの時点でも、セッションまたはそのセッションの属性をlocalまたはdistributedから変更できます。ただし、一度分散されたセッションまたは属性は、localに戻すことはできません。

セッション・ディストリビューション・コントローラには、次のような使い方があります。

5.7.1 セッション・ディストリビューション・コントローラの実装

例5-6は、HttpSessionCollection.SessionDistributionControllerインタフェースの実装例を示しています。この例では、セッションにショッピング・カートがアタッチされているかどうかがテストされます(アタッチされているセッションのみが分散されます)。次に、そのセッションに特定の属性が含まれているかどうかがテストされます。その属性が検出された場合、その属性は分散されません。

例5-6 セッション・ディストリビューション・コントローラの実装例

import com.tangosol.coherence.servlet.HttpSessionCollection;
import com.tangosol.coherence.servlet.HttpSessionModel;
 
/**
* Sample implementation of SessionDistributionController
*/
public class CustomSessionDistributionController
        implements HttpSessionCollection.SessionDistributionController
    {
    public void init(HttpSessionCollection collection)
        {
        }
 
    /**
    * Only distribute sessions that have a shopping cart.
    *
    * @param model Coherence representation of the HTTP session
    *
    * @return true if the session should be distributed
    */
    public boolean isSessionDistributed(HttpSessionModel model)
        {
        return model.getAttribute("shopping-cart") != null;
        }
 
    /**
    * If a session is "distributed", then distribute all attributes with the 
    * exception of the "ui-rendering" attribute.
    *
    * @param model Coherence representation of the HTTP session
    * @param sName name of the attribute to check
    *
    * @return true if the attribute should be distributed
    */
    public boolean isSessionAttributeDistributed(HttpSessionModel model,
            String sName)
        {
        return !"ui-rendering".equals(sName);
        }
    }

5.7.2 セッション・ディストリビューション・コントローラの実装の登録

SessionDistributionControllerの実装を記述したら、coherence-distributioncontroller-classコンテキスト・パラメータを使用して、この実装をアプリケーションに登録できます。このパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.8 変更された属性値の検出

デフォルトでは、セッションから取得された属性がリクエストの処理中に変更された場合にCoherence*Webが追跡を行います。これを行うには、最初のシリアライズされたバイナリ・フォームの属性がセッションから取得されたときに、これをキャッシュします。リクエストの処理の最後に、Coherence*Webは現在の属性のバイナリ値と「古い」バージョンのバイナリを比較します。値が一致しない場合、現在の値がキャッシュに書き込まれます。アプリケーションで該当するsetを行わずにセッション属性を変更することはないことがわかっている場合は、coherence-enable-suspect-attributesコンテキスト・パラメータをfalseに設定する必要があります。これにより、メモリー使用率およびニア・キャッシュの最適化が改善されます。

5.9 シリアライズ不可能な属性のローカルな保存

デフォルトでは、Coherence*Webはすべてのセッション属性のシリアライズを試みます。シリアライズできないセッション属性を処理している場合、coherence-preserve-attributesパラメータをtrueに設定することにより、これらをローカルに保存できます。このパラメータでは、セッションのシリアライズ不可属性を取得するためにロード・バランサが必要です。

クライアント(アプリケーション・サーバー)が失敗した場合、属性は失われます。アプリケーションは、この状態から復旧できる必要があります。

このパラメータのデフォルトはfalseです。GlassFishにActiveCacheを使用している場合、GlassFish Serverではローカル・セッションが使用できる必要があるため、この値はtrueに設定します。

coherence-preserve-attributesパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.10 Coherence*Webデプロイメントの保護

許可されていないCoherence TCMPクラスタ・メンバーによるHTTPセッション・キャッシュ・サーバーへのアクセスを防止するため、CoherenceではSecure Socket Layer (SSL)実装を提供します。この実装は、クラスタ・ノード間のTCMP通信やCoherence*Extendクライアントとプロキシ間のTCP通信の保護に使用できます。Coherenceでは、SSL 3.0プロトコルの次のバージョンのTransport Layer Security (TLS) 1.0プロトコルを使用できます。しかし、SSLの方が広く認識されている用語であるため、SSLという用語を使用します。

ここでは、Coherence環境でのSSLの使用方法の概要のみを説明します。詳細および構成のサンプルは、『Oracle Fusion Middleware Oracle Coherenceの保護』のSSLを使用した通信の保護に関する項を参照してください。

SSLを使用したTCMP通信の保護

Coherenceクラスタは、TCMPでSSLを使用するように構成できます。Coherenceでは、一方向と双方向の両方の認証を使用できます。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関してSSLが受ける可能性のある影響について、慎重に考慮する必要があります。

この構成では、ピア信頼に基づく双方向通信のSSL接続を可能にする事前定義済のそのまま使用できるSSLソケット・プロバイダを使用することも、独自のSSLソケット・プロバイダを定義することもできます。

SSLを使用した拡張クライアント通信の保護

Extendクライアントと拡張プロキシの間の通信は、SSLを使用して保護できます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。クラスタ側では、プロキシ・サービス用のSSLソケット・プロバイダを定義することにより、SSLをクラスタ側キャッシュ構成ファイルに構成します。SSLソケット・プロバイダは、すべてのプロキシ・サービス用にも、個々のプロキシ・サービス用にも定義できます。

クライアント側では、リモート・キャッシュ・スキーム用、また必要に応じてリモート起動スキーム用のSSLソケット・プロバイダを定義することにより、SSLをクライアント側キャッシュ構成ファイルに構成します。クラスタ側と同様に、SSLソケット・プロバイダは、すべてのリモート・サービス用にも、個々のリモート・サービス用にも定義できます。

5.11 セッション・キャッシュ構成ファイル名のカスタマイズ

デフォルトでは、Coherence*Webはdefault-session-cache-config.xmlファイル内の情報を使用して、Coherence*Web内でセッション・キャッシュを構成します。web.xmlファイル内のcoherence-cache-configuration-pathコンテキスト・パラメータを指定することにより、別のファイルを使用するようにCoherence*Webに指示できます。次に例を示します。

...
<context-param>
   <param-name>coherence-cache-configuration-path</param-name>
   <param-value>my-default-session-cache-config-name.xml</param-value>
</context-param>
...

5.12 Coherence*Webのロギングの構成

Coherence*Webでは、Coherenceにより提供されるロギング・フレームワークを使用します。Coherenceは、独自のロギング・フレームワークを持ち、一般的なアプリケーションのロギング環境を提供するlog4j、slf4jおよびJavaロギングの使用もサポートします。システムの重要な部分への影響を軽減するために、Coherenceでのロギングは優先度の低い専用のスレッドで実行されます。ロギングは事前構成されており、必要に応じてデフォルト設定を変更する必要があります。詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のロギングの構成に関する項を参照してください。

Coherence*Webのロギング・レベルは、コンテキスト・パラメータ/システム・プロパティcoherence-session-logger-levelを使用して設定することもできます。これは、JDKロギングを使用するかわりにCoherence*Webのロギング・レベルを設定する方法です。このパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。


警告:

JDKロギング・フレームワークを使用するアプリケーションでは、CoherenceもJDKロギングを使用するように構成できます。ただし、ログ・レベルをFINESTに設定すると、ログ・レベル内のセッションIDを公開できることに注意してください。

5.13 同一のセッション・インスタンスへの同時アクセス

この機能は、パッチ・リリースの一部として追加されました。パッチに追加された機能の詳細は、『Oracle Coherenceリリース・ノート』を参照してください。

キャッシュ・デリゲータ・クラスは、分散キャッシュ内のデータ操作(取得、配置および削除)を担当するクラスです。web.xmlファイルの<coherence-cache-delegator-class>コンテキスト・パラメータを使用して、このデータ操作を担当するクラス名を指定します。

このコンテキスト・パラメータで可能な値は、com.tangosol.coherence.servlet.LocalSessionCacheDelegatorクラスなどです。このクラスは、セッション・インスタンスの保存および取得に分散キャッシュが使用される前に、ローカル・キャッシュが使用される必要があることを示しています。このデリゲータは、同一のセッション・インスタンスへの同時アクセスが必要なアプリケーションで有用です。


注意:

PeopleSoftアプリケーションを使用する場合は、この機能を有効にする必要があります。

LocalSessionCacheDelegatorキャッシュ・デリゲータを有効にするには、web.xmlで次の項目を構成する必要があります。

例5-7に、web.xmlファイルのキャッシュ・デリゲータの構成例を示します。

例5-7 web.xmlファイルのキャッシュ・デリゲータの構成

...
 <context-param>
    <param-name>coherence-cache-delegator-class</param-name>
    <param-value>com.tangosol.coherence.servlet.LocalSessionCacheDelegator
</param-value>
 </context-param>
 <context-param>
    <param-name>coherence-preserve-attributes</param-name>
    <param-value>true</param-value>
 </context-param>
 <context-param>
    <param-name>coherence-distributioncontroller-class</param-name>
    <param-value>com.tangosol.coherence.servlet.AbstractHttpSessionCollection$HybridController</param-value>
 </context-param>
...

また、LocalSessionCacheDelegatorをキャッシュ・デリゲータとして使用する場合は、session-cache-config.xmlファイルのニア・キャッシュを構成しないでください。これは、ローカル・セッション・インスタンスが使用されるためです。付録D「ニア・キャッシュのないセッション・キャッシュ構成ファイル」には、ニア・キャッシュ構成を省略したsession-cache-config.xmlファイルの例が示されています。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次