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

Coherence*Webセッション管理モジュールには、期限切れのHTTPセッションを削除するセッション・リーパーが含まれます。セッション・リーパーを監視し、アプリケーションおよびデプロイメント環境に基づいて適切に構成されていることを確認する必要があります。セッション・リーパーを正しく管理すると、リソースの使用量を最小限にでき、パフォーマンスの向上に役立ちます。

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

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

この章の内容は次のとおりです。

• セッション・リーパーの理解
  セッション・リーパーの構成は、どんな頻度でリーパーを実行するか、どのサーバーでリーパーを実行するか、およびどのサーバーで期限切れセッションを探すかなど、基本的な問題を示します。
• セッション・リーパーのチューニング
  セッション・リーパーにはいくつかの構成プロパティがあり、アプリケーションがどのように実装およびデプロイされているかに基づいて変更できます。
• セッション・リーパー・パフォーマンス統計の取得
  HttpSessionManagerMBeanWebは、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間をモニタリングするパフォーマンスの統計を提供します。
• セッション・リーパーのセッション無効化の例外の理解
  複数のWebアプリケーションでCoherence*Webインスタンスを使用している場合は、1つのWebアプリケーションのリーパーが、別のアプリケーションで使用されるセッションを無効にできます。

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

セッション・リーパーの構成は、どんな頻度でリーパーを実行するか、どのサーバーでリーパーを実行するか、およびどのサーバーで期限切れセッションを探すかなど、基本的な問題を示します。

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

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

デフォルトのCoherenceワーク・マネージャ実装では、java.util.concurrent.ThreadPoolExecutor Java APIを使用し、プール内の多数のスレッドのうち1つを使用して送信済タスクを処理します。LinkedBlockingQueueなどのブロッキング・キューは、先入れ先出し(FIFO)の順序で待機タスクをスケジュールするために使用されます。

デフォルトの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コンテキスト・パラメータをtrueに設定します。

セッション・リーパーはタイムアウトしたセッションを削除します。デフォルトの動作では、セッションをローカルの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に設定します。

• セッション・リーパー・ワーク・マネージャのキュー・サイズを設定する場合は、coherence-reaperdaemon-queue-size構成オプションを使用します。設定しない場合、キュー・サイズは無制限です。このオプションは、パラレル・リープが有効になっていて、サービス・プロバイダ・インタフェース(SPI)で適用できない場合にのみ使用します。

• セッション・リーパー・デーモンに最大スレッド数を設定する場合は、coherence-reaperdaemon-max-threads構成オプションを使用します。このオプションのデフォルト値は5です。

• セッション・リーパー・デーモンに最小スレッド数の構成パラメータを設定する場合は、coherence-reaperdaemon-min-threads構成オプションを使用します。このオプションのデフォルト値は1です。

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

HttpSessionManagerMBeanWebは、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間をモニタリングするパフォーマンスの統計を提供します。

次のパフォーマンス統計がセッション・リーパーで使用可能です。

• AverageReapDuration: 統計をリセットした時点以降における平均リープ時間(リープ・サイクルが完了するまでの所要時間)で単位はミリ秒。

• LastReapDuration: 前回のリープ・サイクルが完了するまでの所要時間(ミリ秒単位)。

• MaxReapedSessions: 統計をリセットした時点以降における1回のリープ・サイクルでリープしたセッションの最大数。

• NextReapCycle: java.lang.Dateデータ型で表現した次のリープ・サイクルの時間。

• ReapedSessions: 前回のサイクル中にリープしたセッションの数。

• ReapedSessionsTotal: 統計をリセットした時点以降にリープされた期限切れセッションの数。

「JMXによるアプリケーションの管理とモニタリング」を参照してください。

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

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

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

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

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