Oracle® Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理 12c (12.2.1.3.0) E90215-01 |
|
前 |
次 |
各HTTPセッションには、有効期限がいつ切れたかを判定する2つの情報が保持されます。1つ目は、そのセッションを最後に使用したアクティビティのタイムスタンプを示すLastAccessedTime
セッション・プロパティです。2つ目は、アクティビティがない状態でのセッション存続時間を指定するMaxInactiveInterval
セッション・プロパティです。一般に、このプロパティの値は30分に指定されます。MaxInactiveInterval
プロパティは、デフォルトでCoherence*Webに対して構成された値に設定されますが、セッションごとに変更することも可能です。
サーバーがHTTPリクエストを受信したときに、そのリクエストに関連付けられたHTTPセッションがある場合は、その都度セッションのLastAccessedTime
プロパティが現在の時刻に自動的に更新されます。そのセッションは、関連するリクエストが送信され続けるかぎり存続します。ただし、MaxInactiveInterval
プロパティで指定された時間の間、アクティビティがないと、そのセッションは期限切れとなります。セッションの期限切れは受動的に、すなわち時間の経過によってのみ発生します。Coherence*Webセッション・リーパーは、期限切れとなったセッションをスキャンし、見つかった場合はそれらを破棄します。
この章の内容は次のとおりです。
HttpSessionManagerMBeanWeb
は、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間をモニタリングするパフォーマンスの統計を提供します。どこでセッション・リーパーを実行するか理解する
セッション・リーパーは、Coherence*Webを実行するすべてのアプリケーション・サーバーで実行されます。つまり、キャッシュ・サーバーで構成される個別のキャッシュ層を提供するようにCoherenceが構成されている場合、セッション・リーパーはそれらのキャッシュ・サーバー上では実行されません。
デフォルトでは、セッション・リーパーはすべてのアプリケーション・サーバーで同時に実行されるため、期限切れのセッションを特定してクリーンアップするためのワークロードをすべてのサーバーで共有できます。coherence-reaperdaemon-cluster-coordinated
コンテキスト・パラメータを使用すると、一度に1台のサーバーのみが実際のリープを実行するようにクラスタ内のリープを調整しますが、このオプションを使用することはお薦めできません。また、このオプションは、Coherence*Extendトポロジを使用しているCoherence*Webには使用できません。
スティッキー最適化(coherence-sticky-sessions
)も有効化されている場合は、coherence-reaperdaemon-cluster-coordinated
コンテキスト・パラメータを使用しないでください。リープは一度に1台のサーバーによってのみ実行されるため、他のノードが所有するセッションはリープできません。したがって、クラスタに追加されたノードが多くなるほど、セッションのリープにかかる時間は長くなります。また、クラスタ内のノードでリープの所有権がどのように巡回するのかは制御されません。別のノードに渡される前に、1つのノードが長時間にわたってリープ・ノードとなることがあります。その間は、そのノードのセッションのみがリープされます。
セッション・リーパーを実行する頻度を理解する
セッション・リーパーは、リープ・サイクルと呼ばれる一定の期間(デフォルトは5分)にわたってすべてのセッションをスキャンするように構成されます。このリープ・サイクルの長さはcoherence-reaperdaemon-cycle-seconds
コンテキスト・パラメータで指定します。この設定は、セッション・リーパーの動作の積極性を示します。サイクルの長さが短すぎると、セッション・リーパーはリソースを余分に使用するだけで、特別な効果はもたらしません。サイクルの長さが長すぎると、期限切れセッションがCoherenceキャッシュ内のヒープ領域を不要に使用することになります。多くの場合、期限切れになったセッションを即座にクリーンアップすることよりも、リソースの使用量を減らすことの方がはるかに多く望まれます。したがって、デフォルトの5分というサイクルは、クリーンアップの迅速性と最小限のリソース使用量という両方の点をバランスよく保つことのできる長さです。
リープ・サイクルの期間中、セッション・リーパーは期限切れのセッションをスキャンします。ほとんどの場合、セッション・リーパーはクラスタ全体のすべてのHTTPセッションをスキャンするよう構成されますが、単一層トポロジに適用できる最適化も用意されています。単一層トポロジでは、記憶域が有効でアプリケーション・サーバーも実行しているCoherenceクラスタ・メンバーによってすべてのセッションが管理される場合、セッションの記憶域はアプリケーション・サーバーと同じ場所に配置されます。したがって、各アプリケーション・サーバーでは、ローカルに格納されるセッションしかセッション・リーパーがスキャンしないという可能性もあります。この動作は、coherence-reaperdaemon-assume-locality
構成オプションをtrue
に設定すると有効にできます。
同じ場所に配置されたセッションのみをスキャンするか、すべてのセッションをスキャンするかにかかわらず、セッション・リーパーは次のCoherenceデータ・グリッドの高度な機能を使用して、非常に効率的な方法でセッションをスキャンします。
セッション・リーパーは、カスタムのValueExtractor
実装を使用してデータ・グリッドに期限切れセッションの検索を委譲します。このValueExtractor
は、BinaryEntry
インタフェースを利用するため、セッションをデシリアライズしなくても、そのセッションが期限切れかどうかを判別できます。そのため、期限切れセッションの選択を他のパラレル問合せとまったく同じようにデータ・グリッドに委譲して、記憶域が有効なCoherenceメンバーで非常に効率的な方法で実行できるようになります。
セッション・リーパーは、com.tangosol.net.partition.PartitionedIterator
クラスを使用してメンバーごとに自動問合せを行います。またこの問合せは、大規模クラスタのハーモニックを回避するランダムな順序で実行されます。
記憶域が有効な各メンバーは、すべての期限切れセッションを非常に効率的にスキャンでき、リーパー・サイクルごとに各アプリケーション・サーバーで必要となるスキャンも一度のみですみます。そのため、デフォルトのセッション・リーパー構成は、1台以上のサーバーで構成されるアプリケーション・サーバー・クラスタで効果的に機能します。
セッション・リーパーをどのように実行するか理解する
Coherence*Webはワーク・マネージャを使用して、パラレル・リープを実行するスレッドを取得します。WebLogic Serverはデフォルトのワーク・マネージャ、wm/CoherenceWorkManager
を定義し、これの使用を試みることになります。ワーク・マネージャがその名前で定義されていない場合は、Coherenceで実装されているデフォルトのワーク・マネージャを使用します。
デフォルトのWebLogic Serverワーク・マネージャを使用するには、WebLogic Server管理コンソールを使用してwm/CoherenceWorkManager
という名前のワーク・マネージャを作成します。また、次のresource-ref
要素を、アプリケーションweb.xml
ファイルに追加します。
<resource-ref> <res-ref-name>wm/CoherenceWorkManager</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>
セッション・リーパーがアプリケーション・サーバーのスムーズな運用に影響しないよう、セッション・リーパーの作業は小さく分割され、リープ・サイクル全体にわたって分散されるようにスケジュールされます。セッション・リーパーは、スケジューリングが必要な作業量を認識する必要があるため、以前のサイクルで実行した作業量の統計を維持し、新しいリープ・サイクルの統計ほど重視されるように統計的重みづけを使用します。このようにセッション・リーパーが作業を分割する理由には、次のものがあります。
セッション・リーパーが同時に実行してCPU使用率が高くなると、ユーザーに対するアプリケーションの応答性が低下する可能性があります。一度に実行する作業を細分化することで、アプリケーションの応答性は維持されます。
Coherence*Webの主なパフォーマンス・イネーブラの1つは、Coherenceのニア・キャッシュ機能です。期限切れとなったセッションは、クリーンアップするために同じニア・キャッシュを介してアクセスされるため、期限切れとなるセッションが多すぎたり、期限切れにするタイミングが早すぎたりすると、アプリケーション・サーバーで使用されるはずのセッションがキャッシュから削除され、パフォーマンスの低下を招く可能性があります。
セッション・リーパーは、デフォルトの構成を採用した場合でも、次の方法で効率的にジョブを実行します。
できるだけ多くの作業をデータ・グリッドに委譲します。
一度に1つのメンバーにのみ作業を委譲します。
デシリアライズを行わずにデータ・グリッドで期限切れセッションを検出できるようにします。
CPUサイクルの使用量を制限します。
パフォーマンス上の理由でCoherence*Webが依存しているニア・キャッシュのキャッシュ・スラッシングを回避します。
セッション・リーパーがどのようにセッションを削除するか理解する
セッション・リーパーは、セッションをパラレルでもシリアルでも無効化できます。デフォルトでは、セッションはパラレルに無効化されます。これにより、セッションは適時に無効化されます。ただし、同時スレッドが多数あるためにアプリケーション・サーバーJVMのシステム負荷が高い場合は、シリアルに無効化するオプションを選択できます。リーパーがセッションをシリアルに無効化するように構成するには、coherence-reaperdaemon-parallel
コンテキスト・パラメータをfalse
に設定します。
セッション・リーパーはタイムアウトしたセッションを削除します。デフォルトの動作では、セッションをローカルのJVMからフェッチしてからセッションを削除し、invalidate
メソッドをHTTPセッションでコールします。ただし、セッション・リーパーを構成して、Coherenceエントリ・プロセッサを使用してリモートでセッションを削除することもできます。この場合、HTTPセッションおよびセッション・リスナーのinvalidate
メソッドは呼出されません。セッションをリモートで削除する方が、デフォルトのメカニズムよりも迅速ですが、セッション・リスナーを使用しないアプリケーションで使用する必要があります。リーパーを構成して、セッションをリモートで削除するには、coherence-session-reaping-mechanism
コンテキスト・パラメータをRemoteDelete
に設定します。
次のようにして、デフォルトのセッション・リーパー構成を使用します。
アプリケーションをインプロセス・トポロジでデプロイする場合は、coherence-reaperdaemon-assume-locality
構成オプションをtrue
に設定します。
アプリケーション・サーバーはいずれも期限切れセッションをスキャンするようになっているため、クラスタ内のアプリケーション・サーバーが10台を超えている場合は、coherence-reaperdaemon-cycle-seconds
構成オプションの値を増やすことをお薦めします。アプリケーション・サーバーの数が増えるほど、サイクルは長くなる可能性があります。たとえば、サーバーが200台ある場合、妥当なリーパー・サイクルは30分といえます(この場合はcoherence-reaperdaemon-cycle-seconds
構成オプションを1800に設定します)。
アプリケーションでセッション・リスナーを使用しない場合、coherence-session-reaping-mechanism
コンテキスト・パラメータをRemoteDelete
に設定します。
HttpSessionManagerMBeanWeb
は、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間をモニタリングするパフォーマンスの統計を提供します。
次のパフォーマンス統計がセッション・リーパーで使用可能です。
AverageReapDuration
: 統計をリセットした時点以降における平均リープ時間(リープ・サイクルが完了するまでの所要時間)で単位はミリ秒。
LastReapDuration
: 前回のリープ・サイクルが完了するまでの所要時間(ミリ秒単位)。
MaxReapedSessions
: 統計をリセットした時点以降における1回のリープ・サイクルでリープしたセッションの最大数。
NextReapCycle
: java.lang.Date
データ型で表現した次のリープ・サイクルの時間。
ReapedSessions
: 前回のサイクル中にリープしたセッションの数。
ReapedSessionsTotal
: 統計をリセットした時点以降にリープされた期限切れセッションの数。
「JMXによるアプリケーションの管理とモニタリング」を参照してください。
これらの属性には、JConsoleなどのモニタリングツールでもアクセスできます。ただし、それらにアクセスする前に、Coherenceクラスタ化JMXフレームワークを設定しておく必要があります。『Oracle Coherenceの管理』のJMXを使用したCoherenceの管理に関する項を参照してください。
セッション属性リスナーが期限切れのセッションをリープしているWebアプリケーションに登録されます。リスナーは、無効化の際にセッション属性値の取得を試みます。セッション属性が元のWebアプリケーションにのみ存在するクラスに依存している場合、セッション・リーパーでclass not found例外がスローされ、記録されます。これらの例外によって、Webアプリケーションまたはアプリケーション・サーバーの障害が発生することはありません。
Coherence*Webは、これらの例外を記録するかどうかを制御するコンテキスト・パラメータcoherence-session-log-invalidation-exceptions
を提供します。デフォルト値はtrue
で、例外が記録されます。これらの例外を記録しない場合は、このコンテキスト・パラメータをfalse
に設定します。