ベストプラクティス: Web アプリケーションで高速でスケーラブルかつ安全なセッションステート管理の実現 -- MSDN Magazine, 2005 年 9 月

HTTP プロトコルはその特性上ステートを持たないため、常に Web アプリケーションはユーザーステート管理の負担を担ってきました。すばらしいことに、ASP.NET にはユーザーステートを保持する手段としていくつもの方法が用意されています。中でも特にすぐれているのが、セッションステートの保持です。ASP.NET のセッションステート機能は、任意のアプリケーションステートを特定ユーザーセッションに関連付けするための便利なプログラミングインターフェイスを提供し、アプリケーションに必要なバックエンドステートストレージやクライアントセッション管理といった処理を引き受けます。この記事では、ハイパフォーマンスでスケーラブルかつ安全なセッションソリューションの設計および開発について深く掘り下げ、既存の ASP.NET セッションステート機能だけでなく、ASP.NET 機能チームから届いたばかりの新機能に基づくベストプラクティスを提案します。

セッションステートの働き

ASP.NET のセッションステートを使用することで、ステートデータを含んだサーバーサイド文字列やオブジェクトディレクトリを特定の HTTP クライアントセッションに関連付けすることが可能になります。セッションとは、ある一定時間の間に同一のクライアントから発行された一連のリクエストのことであり、その管理は各クライアントごとにセッション ID を関連付けすることにより行われます。セッション ID は、リクエストごとにクライアントにより発行され、クッキーまたはリクエスト URL の一部分として保存されます。セッションデータは、サポートされたセッションステートストア、たとえば、インプロセスメモリ、SQL Server データベース、ASP.NET State Server サービスなどに格納されます。SQL Server データベースと ASP.NET State Server サービスを使用した場合は、同一 Web ファーム上にある複数の Web サーバーでセッションステートを共有することが可能になり、サーバーアフィニティの必要もありません (つまり、特定の Web サーバーを使用するようセッションを設定する必要がないということです)。

セッションステートの実行時オペレーションは、SessionStateModule クラスにより実装され、アプリケーションでは IHttpModule としてリクエストのパイプライン処理に組み込まれます。SessionStateModule は、AcquireRequestState パイプラインステージのハンドラ実行の前に一回、ReleaseRequestState パイプラインステージのハンドラ実行の後に一回、実行されます (図 1 を参照)。AcquireRequestState ステージの SessionStateModule は、リクエストからセッション ID を抽出し、そのセッション ID に対応するセッションデータをセッションステートストアプロバイダから取得しようと試みます。このとき、セッション ID が存在していて、ステートの取得が成功すれば、モジュールがセッションステートディレクトリを構築します。このセッションステートディレクトリは、ハンドラがセッションステートを調査、変更するのに使用するものです。

図 1 セッションステートの保持

ASP.NET 2.0 の場合、セッションの取り出しはセッション ID の管理コンポーネントにカプセル化されています。このコンポーネントは、カスタムインプリメンテーションで置き換えることができ、セッション ID のカスタム管理スキーマ (たとえば、セッション ID をクエリ文字列やフォームのフィールドに保存するなど)をサポートすることが可能です。デフォルトのセッション ID 管理では、クッキーベースと URL ベース、両方のセッション ID をサポートしています。また、ASP.NET 2.0 のデフォルトセッション ID 管理では、デバイスプロファイルまたはクライアントとのランタイムネゴシエーションから、使用すべきセッション ID モードを自動的に検出する機能もサポートしています。

リクエストにセッション ID が存在していなく、ハンドラが何らかの変更をセッションに対して行うと、ReleaseRequestState ステージで新しいセッション ID が発行されます。この新しいセッション ID はセッション ID 管理の実装により、クライアントに送信されます。この場合と既存のセッションに対して変更が行われていた場合は、SessionStateModule が、ステートストアプロバイダを使用してセッションに対して行われた変更を保持します。

また、ASP.NET 2.0 では、セッションステートの保存機能もセッションストアプロバイダコンポーネントにカプセル化されています。このコンポーネントとしては、あらかじめ用意されている InProc、SQLServer、StateServer プロバイダ、あるいはセッションデータ、セッションの作成、既存セッションへの変更の保存の取り出しを実装したカスタムプロバイダのいずれかを使用することができます。

パフォーマンスの改善

ASP.NET アプリケーションでセッションステートを使用すると、アプリケーションパフォーマンスに著しいオーバーヘッドがかかることがあります。このオーバーヘッドは、保存されたステートを取得するためのネットワークリクエスト等、各リクエストの処理中に実行されるアプリケーションのコード量が多いほど顕著です。しかしながら、要求されたステート管理機能を維持しながら、セッションステートによるパフォーマンスへの影響を抑えるための、アプリケーションでの利用が可能なテクニックがいくつか存在します。

SessionStateModule モジュールには、リクエスト単位で発生するセッションステートの一括処理機能が備わっています。このモジュールは、リクエスト情報により識別されたセッションステートを ASP.NET リクエストハンドラが取り出す前に一回と、同じく ASP.NET リクエストハンドラが、新規セッションを作成した後またはハンドラの実行中に既存セッションへの変更を保存した後に一回、実行されます。

InProc セッションステートモードは、あらかじめ用意されているストレージモードの中で最も高速なモードです。InProc セッションステートモードを使用した場合のオーバーヘッドの発生は、リクエストからのセッション ID の抽出、アプリケーションのメモリ空間に保存されたステートディクショナリのキャッシュルックアップの実行、セッションの消失を回避するためにアクセス中であることをマークする場合に限られます。セッション内のデータへの更新はメモリ中のオブジェクトに対して直接行われるため、次のリクエスト用にセッションステートを保持するための作業は一切必要ありません。ただし、InProc モードはアプリケーションリスタート等の耐障害性に乏しく、また Web ファームシナリオでは動作しないという理由から、ほとんどの場合、アプリケーションには他のアウトオブプロセスモードのいずれかを使用する以外の選択肢はありません。

デフォルトでアウトオブプロセスモードの SQLServer と StateServer の場合、セッションステートの取り出しは外部のストアから行い、AcquireRequestState ステージにおいて、バイナリブロブ (BLOB) リプレゼンテーションからインメモリステートディクショナリへのデシリアライズを行わなければいけません。ReleaseRequestState ステージでは、インメモリステートディクショナリを再度シリアライズして外部ストレージに転送する必要があります。また、データの消失を回避するため、ストア内のセッションエントリを更新して、最終アクセス日時を示しておく必要もあります。SQLServer、StateServer モードの場合、ステートデータのシリアライゼーションおよびデシリアライゼーション、アウトオブプロセスのデータ転送処理は、リクエストパスにおけるセッションステート関連のオペレーションの中でも最もコストの高いオペレーションです。

SessionStateModule では、オーバーヘッドを可能な限り回避するために、デフォルトで多くの最適化を実行します。こうした最適化は、次の 4 つに分類されます。

1 つ目は、セッションステートが必要なしとマークされているハンドラまたはページの場合です。この場合、セッションステート処理は一切行われません。ただし、セッションがストア内でアクセス中とマークされている場合を除きます。読み取り専用セッションステートアクセスが必要であるとマークされているページについては、最終アクセス日時のマークと初期データの取り出しのみが行われます。

2 つ目は、セッション ID をまた指定していないリクエストの場合で、この場合、データが実際にセッションディレクトリに保存されるまで、セッションを開始しません。

3 つ目は、セッションステートへのアクセスが一度も行われていないリクエストまたは不変なプリミティブ型を持つセッション変数に対し、読み取りアクセスしか行われていないリクエストの場合で、この場合、リクエストの最後の時点でステートの変更は保持されず、プロバイダへの書き込みは行われません。可変のセッションデータにアクセスがあったリクエストまたはそのセッションデータに修正が行われているリクエストについては、アクセスが行われた変数に対してのみシリアライズが行われ、残りの部分はバイナリブロブ (BLOB) リプレゼンテーションからコピーしてきます。

4 つ目は、プリミティブ型は直接シリアライズが行われますが、オブジェクト型の場合は、比較的速度の遅い、BinaryFormatter シリアライズメソッドを使用してシリアライズが行われます。

セッションステート管理によるパフォーマンスへの影響は、こうした最適化とこの記事で紹介するベストプラクティスを上手に活用することで軽減することができます。今回検討するプランでは、最も効果が期待できる次の 3 つのアプローチにフォーカスし、セッション使用時のアプリケーションパフォーマンスの改善、セッションステートパフォーマンスの最適化の有効活用に取り組みます。

オーバーヘッドの完全回避を目的として、セッションステートを可能な限り無効にする。
ステートデータのシリアライゼーションおよびデシリアライゼーションによるオーバーヘッドを削減する。
セッションステートをステートストアとの間でやりとりするアウトオブプロセスなデータ転送によるオーバーヘッドを削減する。

セッションステートを無効にする

アプリケーションでは、必ずしもすべてのページがセッションステートにアクセスする必要があるわけではありません。アクセスの必要がないページの場合、セッションステートが不要であるということをマークすることで、ページにリクエストがあった場合にステートストアからのセッションデータの取り出しを抑制することができます。

セッションステートを更新しないページの場合は、読み取り専用アクセスが要求されていることを示すことができます。この場合、ステートデータの取り出しは抑制されません。しかし、データベース上で読み取りロックがかかるため、複数の読み取り専用リクエストが一度にセッションにアクセスすることが可能になるだけでなく、同一セッション ID で複数のリクエストがサーバーに対して行われたときのロックコンテンションも回避できます。何より、この方法だと、セッションステートモジュールによる、リクエストの最後に行われるステートの更新を常に回避することができます (この手段としては、他にも方法があります。それについては、後述します)。

以下は、セッションステートを無効にするコードです。。

<%@ Page EnableSessionState="False" %>

同様に、以下は読み取り専用セッションステートを示すコードです。

<%@ Page EnableSessionState="ReadOnly" %>

実際、ショッピングカートのような標準的なページでは、ほとんどの場合、セッションステートを更新するのは、ユーザーが商品をカートに追加または削除するなどのポストバックアクションを実行した場合のみで、ショッピングカートを参照しただけでは更新はしません。ショッピングカートの場合、カートの参照部分のみを、更新を実行しない読み取り専用セッションステートを持つ独自のページに独立させることで、アプリケーションパフォーマンスを調整することができます。ショッピングカートの更新部分は、アクションのリクエスト時に参照部分を記述したページがポストを実行する別ページに独立させることが可能です (ASP.NET 2.0 ではクロスページポスティングをサポートしています)。

また、<pages> というコンフィグレーション要素を Web.config ファイル内で使用することにより、アプリケーションのデフォルト動作を読み取り専用としたり、セッションステートをデフォルトでオフにしたりすることができます。さらに、EnableSessionState というページ属性を下のように適宜設定することで、セッションステートを明示的に有効にしたり、セッションステートを必要とするページでのみ書き込みアクセスを有効にしたりすることができます。

<!--デフォルト状態ではセッション ステートなし-->
<configuration>
    <system.web>
        <pages enableSessionState="false" />
    </system.web>
</configuration>

<!--デフォルト状態では読み取り専用セッション ステート-->
<configuration>
    <system.web>
        <pages enableSessionState="ReadOnly" />
    </system.web>
</configuration>

また、アプリケーションでのリクエスト処理用にカスタムハンドラを作成している場合は、ハンドラクラスで System.Web.State.IRequiresSessionState マーカーインターフェイスを実装しなくても、セッションステートをデフォルト状態で無効にすることができます。読み取り専用モードを有効にするときは、System.Web.State.IRequiresSessionState の代わりに System.Web.State.IRequiresReadOnlySessionState マーカーインターフェイスを実装します。

ただし、アプリケーションでセッションステートをオフにしていると、ページまたはハンドラがセッションステートにアクセスしようとした場合に、HttpContext.Session プロパティから例外が投げられますので注意が必要です。また、ページを読み取り専用とマークしていると、アウトオブプロセスモードで行われたセッションへの更新は、リクエストを超えて保存はされません。ただし、InProc モードの場合、更新は複数リクエストを通じてメモリに常駐するライブオブジェクトに対して行われるため、次のリクエストでデータが失われることはありません。

また、特定のページまたはハンドラに対してセッションステートをオフにしても、SessionStateModule は、ストア内のセッションをアクセス済みとマークします。そのため、残念なことに、ストアに対して確立される接続は、InProc モードを使用していなくてもアウトオブプロセスとなってしまいます。これは、リクエスト先のリソースがセッションステートを必要とするか否かに関係なく、ユーザーがアプリケーションに対してアクティブにリクエストを行っている限りはセッションの終了を回避するための期待された正しい動作です。しかしながら、パフォーマンス上の理由から、一部のリクエストでこの動作を無効にしたい場合があるでしょう。たとえば、ASP.NET を使って、すでにセッションがアクティブとマークされている親 ASP.NET ページ内で使用される画像やページリソースを提供している場合などです。

この動作の最適化を図るには、ASP.NET 2.0 のカスタムセッション ID 生成機能を利用し、リクエストのセッション ID を隠蔽します。こうすることで、そのリクエストに対する一切のセッションステート関連処理を無効にできます。具体的な実装方法としては、System.Web.SessionState.SessionIDManager から派生したカスタム型を実装し、セッションステートを必要としないリクエストについては NULL セッション ID を返す GetSessionID を実装します (図 2 を参照)。それ以外のリクエストすべてについては、ASP.NET でデフォルトのクッキーおよびクッキーレスセッション ID サポートを提供する、SessionIDManager クラスのデフォルト GetSessionID インプリメンテーションに処理を委譲します。

セッションステートのトラックを無効にする ShouldSkipSessionState の実装方法には、面白い方法があります。たとえば、リクエスト先がカスタムコンフィグレーションセクションに指定した拡張の 1 つであると、セッションステートを省略してもかまいません。また、現在のリクエストハンドラのインスタンス (HttpContext.Current.CurrentHandler として利用が可) が、独自の ISkipSessionState インターフェイスを実装している場合も、セッションステートを無視できます。このインターフェイスは、独自のページ基本クラスを指定することで、ページに実装させることができます。

あるいは、現在のリクエストハンドラのインスタンスが IRequiresSessionState を実装していない場合で、アクセス済みとマークされたセッションのセッション ID で、最近リクエストが行われたばかりの場合です。(このことは、独自のカスタムクッキーの作成、または ASP.NET キャッシュにセッション ID とタイムスタンプのペアを保存することで、記録することができます。) たとえば、セッションをアクティブとマークしたリクエストが最後に行われたのが今から 30 秒以内の場合は、アクティブとしてはいけません。これにより目的が達成される一方で、セッションのアクティビティウインドウが減ることはありません。

カスタムセッション ID の管理コードは、App_Code アプリケーションディレクトリに配置してもいいですし、アセンブリにコンパイル後に \Bin アプリケーションディレクトリに配置することもできます。また、\Bin アプリケーションディレクトリに配置する代わりに GAC にインストールすることもできます。そして、次のようなセッションステートコンフィグレーションで登録を行うことで、コードは有効になります。

<configuration>
    <system.web>
        <sessionState 
             sessionIDManagerType="IndustryStrengthSessionState. 
                 SessionDisablementIDManager"/>
    </system.web>
</configuration>

クッキーレスセッション ID の使用時にこのテクニックを適用すると、リンクの生成や、クッキーレスセッションを保持するリダイレクト処理を実行する ASP.NET 機能の中には、NULL ID を返すリクエストで機能しないものがあります。

ネットワーク/ストレージのオーバーヘッドを軽減する

ネットワークラウンドトリップのオーバーヘッドを軽減し、さらにシリアライゼーションとデシリアライゼーションの影響を小さくするには、セッションに容量の大きいデータを保存しないようすることです。アプリケーションを設計する際に、セッションには操作を必要としないサイズの小さい情報セットのみを格納するようにし、残りのセッションオブジェクトモジュールについては、この情報セットをはさむようにリクエスト単位でビルドするようにしてください。この情報の再構築にそれほどコストがかからないのであれば、シリアライズ、デシリアライズ、データ転送の高速な、小さく、シンプルなセッションを実現できます。

同一セッションに対する複数のリクエストがサーバーに対して行われた場合に発生するロックコンテンションの発生を減らすには、サイトでのフレーム使用を抑制したり、セッションを多用するハンドラに提供される、画像やスタイルシートといったダウンロード可能なリソースを ASP.NET アプリケーションで使わないようにします。いずれの場合も、ブラウザは、同一セッション ID を使用して複数の同時リクエストをサーバーに対して発行します。その結果、セッションは複数回アクセスされることになり、他のリクエストによりセッションロックが開放されるのを待機しなければならないため、時間が浪費されることになります。ロックコンテンションを回避するには、前述の読み取り専用セッションステートテクニックを使用して、セッションステートモジュールにリーダーロックを使わせるようにします。これにより、同時複数読み取りが可能になります。

シリアライゼーションの最適化

セッションステートでは、カスタムシリアライゼーションメカニズムを使用して、セッションディクショナリとその内容をバイナリブロブに変換し、その上でアウトオブプロセスストアにデータを保存します。このシリアライゼーションメカニズムは、.NET Framework のプリミティブ型 (String、Boolean、DateTime、TimeSpan、Int16、Int32、Int64、Byte、Char、Single、Double、Decimal、SByte、UInt16、UInt32、UInt64、Guid、IntPtr 等) を直接サポートしています。これらの型は、直接ブロブに書き込まれます。一方、オブジェクト型の場合は、BinaryFormatter でシリアライズが行われ、こちらの場合速度は遅くなります。デシリアライゼーションの場合も同様です。セッションコンテンツを最適化することで、ステートデータのシリアライゼーションおよびデシリアライゼーションによるオーバーヘッドを著しく軽減することができます。

セッションオブジェクトモデルを設計するときは、オブジェクト型をセッションに保存しないようにします。代わりに、セッションディクショナリにプリミティブ型のみを保存し、セッションデータを使用するビジネスレイヤーセッションオブジェクトについてはリクエスト単位で再構築するようにしてください。これにより、BinaryFormatter 使用によるオーバーヘッドが回避されます。

セッションに様々な種類のデータアイテムを保存している場合は、それらを単一のクラスやバッファにまとめて 1 つのアイテムとするのではなく、独立したたくさんのセッションエントリにフラット化した方が効率的です。これにより、必要なアイテムにだけアクセスするといったより緻密なアクセスが可能になります。また、アプリケーションでは、セッションアクセスの際、必要データのオンデマンドデシリアライゼーションを利用することができます。またこの方法では、リクエストの実行中にデータの一部が変更された場合に、もう一度シリアライズする必要のあるデータアイテム数を軽減することができます。

プリミティブ型の代わりにクラスを使用している場合は、System.Runtime.Serialization.ISerializable インターフェイスを実装することで、BinaryFormatter に実行されるシリアライゼーション処理を制御することができます。この実装により、必要なデータのみをオブジェクトのシリアライズ時に書き出して、オブジェクトのデシリアライズ時に残りのデータを再構築することで、シリアライゼーションプロセスを最適化することができます。あるいは、クラスに SerializableAttribute でマークを施している場合は、NonSerializedAttribute を使用することで、デフォルトのシリアライゼーションメカニズムにシリアライズさせたくないオブジェクトデータメンバをマークすることができます。(.NET Framework のバイナリシリアライゼーションの詳細については、バイナリシリアル化を参照してください。

コードでは、必要なセッションアイテムにのみアクセスする、ASP.NET 2.0 の部分デシリアライゼーションメカニズムを利用してください。セッション内の残りのアイテムについては、デシリアライゼーションによるオーバーヘッドの影響を受けることなく、ステートストアの更新中 (再度シリアライズをせず)、アウトゴーイングセッションブロブへのコピーのみが行われます。書き込み可能なセッションステートページ上のすべての読み取りアクセスが不変なプリミティブ型に対して行われていることを徹底することで、さらに効率性を高めることができます。これが、セッションステートコレクションの書き込みアクセスの欠如と相まって、セッションデータを更新するためのサーバーへのラウンドトリップを完全に回避することができます。

それでは、こうしたテクニックは実際どのように使われているかを見てみることにしましょう。図 3 は、あるセッションベースのショッピングカートの、ビジネスロジックのレイヤーインプリメンテーションの最初の部分を示したものです (紙面の都合上、簡単なメソッドとプロパティアセッサを省略しています)。

この実装は、製品アイテム、製品アイテムと個数を含む注文、アイテムのコレクションを含むショッピングカートを含む、ショッピングカートオブジェクトモデルを定義しています。クラスはシリアライゼーション可能とマークされているため、カートの参照を保存し、セッションステートに実行時にオブジェクトグラフをシリアライズ/デシリアライズさせるだけで、カートをセッションに保存することができます。

図 4 は、今まで説明してきたテクニック - オブジェクトモデルをプリミティブ型に変換する、リクエスト単位でセッションから取得可能なデータを保存しない、プリミティブ型を使用してコレクションをフラット化する、アイテムの読み取り/書き込みアクセスを最適化してシリアライゼーションの再実行や更新をできる限り回避する - を適用した、最適化された実装です (サンプル内の変更されていないメソッドは省略してあります)。

この実装では、セッションへの保存が必要となる ID と個数に関する情報から、実行時に生成可能なアイテム情報を分離しています。また、注文のコレクションをフラット化してセッションに取り込むメカニズムも提供しています。つまり、ショッピングカートの注文の読み取り、書き込みが、互いに独立した状態で可能になり、部分デシリアライゼーション/シリアライゼーションメカニズムを利用できるようになります。最後に、この実装では、セット呼び出しの回避と読み取りアクセスの際に不変なプリミティブ型のみを使用することで、カートに変更が行われなかった場合の更新ラウンドトリップを、慎重に回避しています。

この実装では、オブジェクトモデル自体への変更は行っていませんが、SaveShoppingCartToSession および GetShoppingCartFromSession メソッドの使用による、セッション内にカートを保存、取得する方法のみを変更しています。これにより、ほとんどのアプリケーションから、必要な変更が切り離されます。便宜上、今回のサンプルコードでは、コレクションの削除または取得機能を実装していませんが、いずれの機能も、最適化の効果を損なうことなく実装することが可能です。

インプロセスの最適化

InProc モードは、アウトオブプロセスモードに比べるとはるかに高速ですが、インプロセスパフォーマンスを最適な状態で維持するために、いくつか覚えておかなければならないガイドラインが存在します。

1 つは、セッションにはシングルスレッドアパートメント (STA) COM オブジェクトを保存しないようにしてください。このガイドラインは、ASP 時代から有効です。STA COM オブジェクトは同じスレッドでしかアクセスすることができないため、ASP.NET は、セッションに対するすべてのリクエストが同じスレッドに処理されていることを確認した上で、COM オブジェクトへのアクセスをシリアライズします。ただし、これは、AspCompat ページ属性に True が設定されている場合に限ります。2 つ目は、セッションの全体サイズをできるだけ小さくして、メモリの使用量の増加を回避するようにしてください。これを怠ると、キャッシュチャーンが発生したり、アプリケーション全体のパフォーマンスやキャパシティにマイナス影響があります。

スケーラビリティの向上

ASP.NET のセッションステートでは、アウトオブプロセスステートストレージをサポートすることにより、ASP.NET アプリケーションでのホリゾンタルスケーリングが有効になります。これにより、複数の Web ファームマシンで、セッションデータを消失することなく、同一セッションに対するリクエストを処理することができます。しかしながら、Web ファームのキャパシティは、Web サーバーノードを追加していくことでほぼ直線的に増加することができますが、セッションキャパシティが増加していくに伴い、1 つだけのセッションステートストアはボトルネックとなります。InProc モードの場合 (Web ファームで動作するアプリケーションの外部や適切なアフィニティを設定した Web ファーム内での使用が可能)、Web サーバーメモリ内でのセッションのメモリの使用が禁止になることもあります。

ASP.NET 2.0 のセッションステートパーティショニング

ASP.NET 2.0 のステートパーティショニング機能により、セッションステートストアのホリゾンタルスケールアウトを有効にすることで、スケールアップが可能です。ASP.NET 2.0 には、その際に生じる問題の解決策が用意されています。ステートパーティショニングを使用すると、セッションデータおよび対応する処理負荷を複数のアウトオブプロセスステートストアに分割することができるため、Web ファームの拡大や同時実行セッション数の増加に伴うセッションステートの負担を減らすことが可能になります。具体的には、SessionStateModule にカスタムパーティショニングアルゴリズムを提供することで実現します。SessionStateModule はこのアルゴリズムを使って、ステートストア接続文字列を現在のリクエストで使用すべきかどうかをセッション ID を元に判断します。SQLServer、StateServer いずれのプロバイダも、適切な接続文字列を使って、セッションの取り出し、保存を行います。

パーティショニングスキーマは、System.Web.IPartitionResolver インターフェイスからクラスを派生し、セッション ID - 接続文字列のマッピングを ResolvePartition メソッド内に構築することで実装できます。図 5 に示す基本実装では、Initialize メソッドにおいて、利用可能なステートストアパーティショニングに対応したハードコード状態の接続文字列の配列を作成します。ResolvePartition メソッドでは、リゾルバがセッション ID 文字列に対してハッシュ処理を行い、ロードされている接続文字列の 1 つに対応したバケットを決定し、結果の接続文字列を選択しています。

理想としては、Initialize メソッドでロードする利用可能なパーティションを指定するためのコンフィグレーションコレクションを実装するか、Web ファームのネットワーク上にある集中ロケーションからコレクションを取得したいと思うでしょう。シンプルかつ一環したハッシュ処理を実装したとしても、セッションのストアへの配布でさえ相対的に見ると時間がかかります。これは、セッション ID の生成がランダムに行われるためです。一方で、現在のパーティションの負荷を基準にセッションを配置するパーティションを動的に決定するようなロードバランシングスキーマを実装してもよいでしょう。それには、パーティション ID をセッション ID にエンコードする必要があります。処理としては、カスタム SessionIDManager 派生と PartitionResolver を併用して新規セッションのパーティションを決定し、パーティション ID をエンコードした状態のセッション ID を生成します。将来のリクエストでは、パーティションリゾルバ内のセッション ID から抽出することで、パーティション ID を決定します。

パーティションリゾルバの実装は、App_Code アプリケーションディレクトリに配置してもいいですし、アセンブリにコンパイル後に \Bin アプリケーションディレクトリに配置することもできます。また、\Bin アプリケーションディレクトリに配置する代わりに GAC にインストールすることもできます。最後に、完全修飾名を partitionResolverType 属性に指定して、リゾルバ型をセッションステートコンフィグレーションに追加しなければいけません。

<configuration>
    <system.web>
        <sessionState 
            mode="StateServer" 
            partitionResolverType=
                "IndustryStrengthSessionState.PartitionResolver" />
    </system.web>
</configuration>

パーティションリゾルバは、セッションステートが SQLServer または StateServer モードを使用している場合にしか使うことができません。また、sqlConnectionString や stateConnectionString 属性を使っても、接続文字列を指定することはできないので注意が必要です。

セッションステートは、Web ファームのセッションステートを管理する手段として、別の選択肢も用意しています。Web ファーム上でセッション ID にも対応したアフィニティスキーマが使えることが前提になりますが、この方法を使用すると、アプリケーションは分散した InProc のステートストレージの速度を抑制することができます。アフィニティスキーマは、同じセッション ID を持つリクエストはすべて同一の Web サーバーに渡されることを保証する必要があります。その場合、各 Web サーバーは、他の Web サーバーとは共有しない独自のセッションステートストアを保持することができます。

アフィニティスキーマは、同じセッション ID を持つすべてのリクエストが同一の Web サーバーに導かれることが保証する、リクエストのセッション ID 等、特徴のある要素がベースとなっている必要があります。こうしたスキーマは、クライアント IP (クライアントは、動的に割り当てられた Web プロキシを経由している可能性を念頭に入れておいてください) のネットワーク範囲、またはユーザーエイジェントヘッダーをベースにすることもできます。こうしたアフィニティスキーマの実装上の問題としては、HTTP レベルでのリクエストのルーティングが必要になるため (一般的な IP または TCP レベルでの接続ルーティングとは対照的ですが)、ハードウェアロードバランシングシステム上ではすぐには使用できないという点が上げられます。また、ステートストアへのセッション ID のマッピングでステートを保持しなければならないという点から、ルーティングは確定的である必要があるために、このようなスキーマを実装すると、実際のロードバランシング処理ができなくなります。

セッションステートの保護

ASP.NET のセッションステートは、実際のステート情報はサーバー側に保存され、クライアントや HTTP リクエストパスのネットワークエンティティ上には現れないという点で、クライアントのステート管理テクニックに対してセキュリティ上の利点があります。しかしながら、セッションステートオペレーションには、アプリケーションのセキュリティを維持する上で検討しなければならない重要な側面がいくつかあります。セキュリティに関するベストプラクティスは、大きくわけると次の 3 つに分類されます: セッション ID のスプーフィング (なりすまし) やインジェクションを回避する、バックエンドのステートストレージの保護、専用または共有環境におけるセッションステートデプロイメントのセキュリティ確保。

セッションステートはクライアントチケットを使用してサーバー側のセッションを識別しているため、セッション ID のなりすましやインジェクション攻撃の危険にさらされています。セッション ID のなりすまし攻撃とは、悪意のある第三者がリクエストにおいて他人のユーザーのセッション ID を使用し、アプリケーションを欺き、なりすましたユーザーのセッションをロードすることです。一方、インジェクション攻撃は、なりすまし攻撃とはほとんど反対の意味を持ちます。インジェクション攻撃の場合、悪意のある第三者が攻撃者のセッション ID を使って、正規のユーザーにサーバー対して強制的にリクエストを実行させます。セッション ID は、BASE64 エンコードの 62 文字からなるランダムな文字列であるため、ブルートフォースによるセッション ID 検索は、実行不可能であり、セキュリティの脅威とは認識されていません。

ASP.NET 2.0 のセッションステートは、セッション ID のなりすましやインジェクション攻撃を回避できるよう強化が行われており、具体的には HTTPOnly というクッキー機能をうまく利用しています (現時点では、Microsoft Internet Explorer 6.0 SP1 または Windows XP SP2 をインストールした Internet Explorer 6.0 でサポートされています)。この機能により、クライアント側のスクリプトでセッション ID クッキーが使用できなくなります。その結果、セッション ID クッキーを盗むよう設計されたクロスサイトスクリプティングエクスプロイトについても同様の効果があります。この機能は、対応ブラウザでは自動的に有効になります。

また、ASP.NET 2.0 には、セッション ID の再生機能が用意されています。この機能は、サーバー上に見つからない、期限切れのセッション ID を新しく生成したセッション ID で強制的に置き換える機能です。これにより、クッキーレスセッションのリンク (検索エンジンクローラにより索引付けされるリンク等) で起こりやすいセッション ID の予想外の再利用を回避できるのはもちろんですが、さらにクッキーレスセッションリンクのポスティングによる悪意のあるセッション ID インジェクション攻撃も回避することができます。この機能は、デフォルトでオンになっていて、クッキーレスセッション ID でのみのサポートとなっています。アプリケーションでクッキーレスセッション ID を使用している場合は、この機能を常に有効にしておくようにしてください。ただし、オリジナルセッションがアクティブ状態のときに、攻撃者にセッション ID が分かってしまったような場合は、この機能ではセッションのなりすましを回避することはできませんので注意が必要です。

以前のバージョンの ASP.NET セッションステートでは、アプリケーションの設定を、クッキーベースのセッション ID とクッキーレスリンクベースのセッション ID のどちらか一方を使用するようにしなければいけませんでした。クッキーが使用できないモバイルクライアントやブラウザをサポートする必要のあるアプリケーションでは、アプリケーション全体でクッキーレスモードを使用する以外、選択肢はありませんでした。しかし、クッキーレス ID は人の目に触れやすいため、なりすましも容易です。さらに、リンクポスティングによるインジェクションやフィッシング攻撃にもさらされやすいため、セキュリティ上の観点から、クッキーレスモードの使用はお奨めできません。それでも、クッキー非対応ブラウザのサポートは必須です。

ASP.NET 2.0 では、2 つの新しいセッション ID モード、UseDeviceProfile と AutoDetect を使用できます。それぞれ、リクエストごとにどのタイプのセッション ID を使ったらよいかを、ブラウザデバイスプロファイルを使用するか、クッキー機能の自動判別処理を実行することで判断します。ノンクッキークライアントをサポートする必要がある場合は、クッキーレス ID を必要とするクライアントでのみクッキーレス ID を使用することでクッキーレスのリスクを軽減する、UseDeviceProfile モードを使用します。

なりすまし攻撃のリスクをさらに軽減する高度なテクニックとしては、ランダムなセッション ID とクライアントのユーザーエージェントのハッシュ、それからクライアントの IP アドレスのネットワーク部分を組み合わせ、ID の検証の際、情報の各部分が一致しているかどうかを確認する方法があります。残念ながら、これは完璧なプラクティスとはいえません。なぜなら、クライアントの多くが単一のプロキシサーバーを経由している可能性があるため、同じユーザーエージェント文字列を共有している可能性もあるためです。それでも、なりすまし攻撃に対してはワンランク上の防御を提供します。また、前述のように、ASP.NET 2.0 のカスタム SessionIDManager 拡張メカニズムを使用することでも、この機能を実装することができます。ASP.NET 1.x での実装例ですが、MSDN マガジンの 2004 年 8 月号の Jeff Prosise's column (英語) に類似機能の実装例が紹介されています。

セッションの有効期限のタイムアウトをできるだけ小さい値に設定するのも、セキュリティ上すぐれたプラクティスであり、セッション ID エクスプロイトのほとんどをうまく回避できます。さらにハイレベルな防御を実現したいのであれば、サイトを去る前のログアウトやセッションを中止する方法を簡単にした上で、JavaScript を使ってブラウザウインドウのクローズを検出し、サーバー上で強制的にセッションを破棄するようにします。

最後に、ネットワークレベルでのセッション ID、認証チケット、アプリケーションクッキー等のリクエスト/レスポンス情報のスニッフィング、を回避するため、SSL (Secure Sockets Layer) を使用するようにしてください。SSL の使用時は、クッキーで指定した URL スコープ内で HTTP 以外の URL を使用する場合、URL へのリクエスト中にブラウザにより送信されたクッキーはスニッフ (盗み見) される可能性があるということを認識しておいてください。このため、SSL を使用するときは、URL のサブセットのみを保護するのではなく、ドメイン全体を保護することを推奨します。

セキュリティの設定

SQLServer ステートプロバイダを使用する場合、通常、各バージョンに対応した Framework ディレクトリにある aspnet_regsql.exe ユーティリティを使用して、セッションステートスキーマを SQL Server データベースに配置します。このユーティリティは必要なセッションステートテーブルを作成してくれるのですが、データベースオブジェクトへのユーザーアクセスは付与してくれません。そのため、サーバー接続に使用する認証の種類 (統合 Windows 認証か SQL Server 認証か) に応じて、個々の Windows または SQL Server アカウントにデータベースと必須オブジェクトへのアクセスを明示的に付与する必要があります。

方法としては、SQL Server データベースロール ("SessionStateFullAccess" と呼ぶことにしましょう) を作成し、テーブル自体には一切のアクセス権を付与せずに、セッションステートストアドプロシージャを実行するだけのロール権限を付与するやり方を推奨します。このロールは、Web サーバーのセッションステートコンフィグレーションで使用するログインアカウントに付与してください。これは最小特権という、あらゆる ASP.NET データ主導型の機能にとって汎用的なベストプラクティスであり、その多くにはすでにロールの設定として取り込まれています。

SQL Server 接続文字列で統合 Windows 認証を使用している場合は、これまでのバージョンのようにリクエスト ID を基準とするのではなく、ホスティング ID を基準としてサーバーに接続する、ASP.NET 2.0 の設定オプションを利用してください。このオプションは、デフォルトで有効になっており、<sessionState> 構成要素で useHostingIdentity 属性を使用することで設定を行います。このオプションを設定すると、ドメイン全体や特定のユーザーセットに対してではなく、ASP.NET ワーカープロセスやアプリケーション ID に対してデータベースのアクセス権が付与されるために、イントラネット上における認証管理が簡便化されます。

SQL Server 接続文字列で SQL Server 認証を使用している場合は、接続文字列を <connectionStrings> 構成セクションに設定して、接続文字列名を <sessionState> 構成に設定するだけで、サーバーへの接続を確立できます。さらに、ASP.NET 2.0 の構成の暗号化機能を用いて、<connectionStrings> セクションを暗号化することで、ログインクレデンシャルを保護できます。

それから、SQL Server インスタンスが Web サーバー以外のマシンによるリモートアクセスから必ず保護されるよう注意してください。これは、Windows ファイアーウォールまたは IPSec ポリシーにより実現できます。

State Server サービスには、認証機能が用意されていません。そのため、State Server サービスにネットワークアクセスできる人であれば、誰でもセッションデータを変更することができてしまい、予期せぬ動作を引き起こすことがあります。State Server インスタンスの安全性を確保するには、Windows ファイアーウォールまたは IPSec ポリシーを使用して、Web サーバー以外のマシンからの不正なアクセスから保護されるよう注意しなければいけません。また、サーバーが動作するネットワークポートも変更した方がよいでしょう。ポートは、次のレジストリキーに新しいポートを設定することで変更できます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state
\Parameters\Port=PORT

.NET Framework 1.1 の時代から (.NET Framework 1.0 SP3 と .NET Framework 2.0 も含む)、ステートサーバーは、デフォルト状態ではローカルループバックインターフェイス上の接続しか待機しません。ステートサーバーは、ステートサーバーインスタンスが動作するマシン上の次のレジストリキーを設定することで、Web サーバーからのリモート接続を待機するよう設定することが可能です。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state
\Parameters\AllowRemoteConnection=1

まとめ

ASP.NET セッションステートでは、単一のアプリケーションや Web ファーム環境で、ステート管理を行う強力なメカニズムを提供することができます。ASP.NET 2.0 には、たくさんの新しいセッションステート機能が用意されています。このセッションステートのパワーをアプリケーションでうまく活用することで、従来はクライアントアプリケーションでしか実現できなかったリッチでステートフル (処理状態を把握できる) な操作性の構築が可能になります。本資料で説明してきたデザインおよびデプロイメントに関するベストプラクティスを適用することにより、パフォーマンス、スケーラビリティ、安全性にすぐれたセッションステートの保持を Web アプリケーションで実現することができます。

Web アプリケーションで高速でスケーラブルかつ安全なセッション ステート管理の実現

Web アプリケーションで高速でスケーラブルかつ安全なセッションステート管理の実現