6 期限切れHTTPセッションのクリーンアップ

この章では、セッション・リーパーの構成および使用方法について説明します。セッション・リーパーは、セッションのタイムアウト時に使用されていないと判断されたセッションを破棄します。

この章の構成は、次のとおりです。

Coherence*Webセッション管理モジュールの一環として、期限切れのHTTPセッションは最終的にセッション・リーパーによってクリーンアップされます。セッション・リーパーは、JVMのガベージ・コレクション(GC)機能に似たサービスを提供します。つまり、セッションのタイムアウト時に使用されていないと判断されたセッションを破棄する役目を担います。

各HTTPセッションには、有効期限がいつ切れたかを判定する2つの情報が保持されます。1つ目は、そのセッションを最後に使用したアクティビティのタイムスタンプを示すLastAccessedTimeセッション・プロパティです。2つ目は、アクティビティがない状態でのセッション存続時間を指定するMaxInactiveIntervalセッション・プロパティです。一般に、このプロパティの値は30分に指定されます。MaxInactiveIntervalプロパティは、デフォルトでCoherence*Webに対して構成された値に設定されますが、セッションごとに変更することも可能です。

サーバーがHTTPリクエストを受信したときに、そのリクエストに関連付けられたHTTPセッションがある場合は、その都度セッションのLastAccessedTimeプロパティが現在の時刻に自動的に更新されます。そのセッションは、関連するリクエストが送信され続けるかぎり存続します。ただし、MaxInactiveIntervalプロパティで指定された時間の間、アクティビティがないと、そのセッションは期限切れとなります。セッションの期限切れは受動的に、すなわち時間の経過によってのみ発生します。Coherence*Webセッション・リーパーは、期限切れとなったセッションをスキャンし、見つかった場合はそれらを破棄します。

6.1 セッション・リーパーの理解

セッション・リーパーは、次の3つの基本的な質問に対応して構成します。

どのサーバーでリーパーを実行するか
どのくらいの頻度でリーパーを実行するか
リーパーを実行するときに、どのサーバー上で期限切れのセッションを検出するか

どこでセッション・リーパーを実行するか理解する

セッション・リーパーは、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で実装されているデフォルトのワーク・マネージャを使用します。

セッション・リーパーがアプリケーション・サーバーのスムーズな運用に影響しないよう、セッション・リーパーの作業は小さく分割され、リープ・サイクル全体にわたって分散されるようにスケジュールされます。セッション・リーパーは、スケジューリングが必要な作業量を認識する必要があるため、以前のサイクルで実行した作業量の統計を維持し、新しいリープ・サイクルの統計ほど重視されるように統計的重みづけを使用します。このようにセッション・リーパーが作業を分割する理由には、次のものがあります。

セッション・リーパーが同時に実行して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に設定します。

6.2 セッション・リーパーのチューニング

ここでは、セッション・リーパーのデフォルト構成をチューニングする際の推奨事項を示します。

アプリケーションをインプロセス・トポロジでデプロイする場合は、coherence-reaperdaemon-assume-locality構成オプションをtrueに設定します。
アプリケーション・サーバーはいずれも期限切れセッションをスキャンするようになっているため、クラスタ内のアプリケーション・サーバーが10台を超えている場合は、coherence-reaperdaemon-cycle-seconds構成オプションの値を増やすことをお薦めします。アプリケーション・サーバーの数が増えるほど、サイクルは長くなる可能性があります。たとえば、サーバーが200台ある場合、妥当なリーパー・サイクルは30分といえます(この場合はcoherence-reaperdaemon-cycle-seconds構成オプションを1800に設定します)。
アプリケーションでセッション・リスナーを使用しない場合、coherence-session-reaping-mechanismコンテキスト・パラメータをRemoteDeleteに設定します。

6.3 セッション・リーパー・パフォーマンス統計の取得

HttpSessionManagerMBeanWebは、セッション・リーパーのパフォーマンス統計として使用される属性を提供します。これらの統計には、次のリストに示すように、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間が含まれます。

AverageReapDuration: 統計をリセットした時点以降における平均リープ時間(リープ・サイクルが完了するまでの所要時間)で単位はミリ秒。
LastReapDuration: 前回のリープ・サイクルが完了するまでの所要時間(ミリ秒単位)。
MaxReapedSessions: 統計をリセットした時点以降における1回のリープ・サイクルでリープしたセッションの最大数。
NextReapCycle: java.lang.Dateデータ型で表現した次のリープ・サイクルの時間。
ReapedSessions: 前回のサイクル中にリープしたセッションの数。
ReapedSessionsTotal: 統計をリセットした時点以降にリープされた期限切れセッションの数。

これらの属性の説明は、「JMXによるアプリケーションの管理とモニタリング」の表5-2にもあります。

これらの属性には、JConsoleなどのモニタリングツールでもアクセスできます。ただし、それらにアクセスする前に、Coherenceクラスタ化JMXフレームワークを設定しておく必要があります。フレームワークの構成およびインストール手順については、『Oracle Coherenceの管理』のJMXを使用してCoherenceを管理する方法に関する項を参照してください。

6.4 セッション・リーパーのセッション無効化の例外の理解

各Coherence*Webインスタンスには、セッション・キャッシュ内のすべてのセッションを定期的に繰り返し、期限切れのセッションをチェックするセッション・リーパーがあります。複数のWebアプリケーションでCoherence*Webを使用している場合は、1つのWebアプリケーションのリーパーが、別のアプリケーションで使用されるセッションを無効にできます。期限切れのセッションをリープしているWebアプリケーションに登録されているセッション・リスナーが実行されます。

セッション属性リスナーは、無効化の際にセッション属性値の取得を試みます。セッション属性が元のWebアプリケーションにのみ存在するクラスに依存している場合、セッション・リーパーでClassNotFound例外がスローされ、記録されます。これらの例外によって、Webアプリケーションまたはアプリケーション・サーバーの障害が発生することはありません。

Coherence*Webは、これらの例外を記録するかどうかを制御するコンテキスト・パラメータcoherence-session-log-invalidation-exceptionsを提供します。デフォルト値はtrueで、例外が記録されます。これらの例外を記録しない場合は、このコンテキスト・パラメータをfalseに設定します。