計画手順 2: ASP.NET 設定を計画する

作成者: Keith Newman および Robert McMurray

2.1. セッション状態の設定

クライアントがサイトにアクセスする場合、通常 1 つのページから別のページに移動し、アクセスするページを頻繁に変更します。 ユーザーが参照したページと、Web サイトへのアクセス時に行った変更を追跡するには、セッション状態を構成します。

アプリケーションに対してセッション状態を有効にすると、ASP.NET アプリケーションから Web ページに対するユーザーの最初の要求時に、ユーザーは一意のセッションの ID を受け取ります。 セッション状態のデータは、次のいずれかの方法で、サーバー上に保存されます。

• インプロセス: セッション状態は、ASP.NET アプリケーションが実行されているワーカー プロセスの内部に格納されます。
• 状態サーバー: セッション状態は、ASP.NET アプリケーションが実行されているワーカー プロセスの外部に格納されます。
• SQL Server: セッション状態は SQL Server データベースに格納されます。

セッション状態データは、クライアントの Cookie に格納することもできます。 Cookie とは、ユーザーの基本設定やユーザー認証情報など、ユーザーに関する情報を格納するために使用されるデータが含まれているテキスト ファイルです。

次のセクションでは、セッション状態の記憶域オプションの詳細について説明します。

• プロセス内へのセッション状態の格納
• 状態サーバーを使用したセッション状態の格納
• SQL Server を使用したセッション状態の格納
• セッション状態の Cookie モード

プロセス内へのセッション状態の格納

インプロセス セッション状態モードでは、ASP.NET アプリケーションのセッション状態のデータが、アプリケーションが実行されているワーカー プロセスに格納されます。 このモードは IIS 8 の既定値です。

インプロセス セッション状態を使用する利点は、セッション状態データに最速のアクセスが提供されることです。 ただし、セッションに保存されるデータが多くなるにつれて、メモリの消費量が多くなり、サーバーのパフォーマンスが低下する可能性があります。

インプロセス セッション状態を構成する前に、セッション状態データについて、ワーカー プロセスをリサイクルする影響を検討してださい。 ワーカー プロセスをリサイクルすると、すべてのセッション状態データが失われます。 ASP.NET アプリケーションでセッション状態データを保持する必要があり、データへのアクセス速度を重要視しない場合は、このデータを格納するために、アウトオブプロセス セッション状態モードを使うことを検討してください。

既定では、ASP.NET アプリケーション内でユーザーがページの要求または更新を 20 分間実行しなかった場合、セッションの有効期限が切れます。 セッション オブジェクトは Web サーバー上のメモリを消費するため、タイムアウトの値を小さくしてリソースを節約することを検討してください。

重要: ユーザーが Web サイト上でアクティブでなくタイムアウトが発生した場合、ユーザーの Session オブジェクトに格納された情報は失われるため、セッション タイムアウト値を調整する場合は注意してください。

インプロセス セッション状態の記憶域を使用する場合は、Cookie を使用するかどうかも決定します。 Cookie の詳細については、「セッション状態の Cookie モード」を参照してください。

状態サーバーを使用したセッション状態の格納

状態サーバーは、ワーカー プロセス外のメモリに、セッション状態データを保持します。 この構成の利点は、アプリケーション ワーカー プロセスがリサイクルされた場合でも、セッション状態が保持されることです。 中規模サイズのアプリケーションの場合、状態サーバーを使用することをお勧めします。

状態サーバーは、Windows 状態サービス (Aspnet_state.exe) に依存していて、接続を介したセッション状態の確認にはコンピューター キーが必要です。

アプリケーションの状態を保持しているのと同じ Web サーバー上で状態サーバーが実行されている場合、Web ガーデン構成がサポートされます。 セッション状態データの保護を強化する場合、セッション状態を独立したサーバーに保存し、その状態をファーム内のすべてのサーバーで共有する Web ファーム構成を使用することを検討してください。 もう 1 つの方法は、SQL Server を使って、アウトオブプロセス セッション状態を保持することです。

重要: インプロセス セッション状態を有効にするには、Windows 状態サービス (Aspnet_state.exe) が実行されている必要があります。 既定では、このサービスは Windows Server 2012 がインストールされ、手動起動用に構成される際にインストールされます。 起動時の動作を [自動] に変更します。

状態サーバーを使ってセッション状態を保存する場合は、次の設計上の決定を行ってください。

• 状態サーバーの接続文字列を定義します。
• 接続がタイムアウトするまで待機する秒数を指定します。
• 圧縮を有効にするかどうかを決定します。
• セッション状態データを Cookie に格納するかどうかを決定します。 Cookie の詳細については、「セッション状態の Cookie モード」を参照してください。

SQL Server を使用したセッション状態の格納

ある種類のアウトオブプロセス セッション状態は、セッション状態データを保存するために SQL server を使用します。 この構成の利点は、アプリケーションのワーカー プロセスをリサイクルした場合や、Windows 状態サービスまたは Web サーバーのいずれかが停止した場合でも、セッション状態が保存されることです。

アプリケーションの状態を保持しているのと同じ Web サーバー上で SQL Server が実行されている場合、Web サーバーのスケーラビリティを向上させる Web ガーデン構成がサポートされます。 SQL Server が別のサーバーで実行されている場合、複数のサーバーにわたってスケーラビリティを大幅に向上させる Web ファーム構成がサポートされます。

セッション状態を SQL Server データベースに保存する場合は、次の設計上の決定を行ってください。

• データベースへの接続文字列を定義します。
• 接続タイムアウトの待機秒数を指定します。
• 再接続を試行するまでの待機秒数を指定します。
• カスタム データベースを有効にするかどうかを決定します。
• 圧縮を有効にするかどうかを決定します。
• セッション状態データを Cookie に格納するかどうかを決定します。 Cookie の詳細については、「セッション状態の Cookie モード」を参照してください。

セッション状態の Cookie モード

Web サーバーに接続するクライアントのセッション状態を追跡する方法の 1 つは Cookie を使用することです。 Web サーバーは、Cookie を使用する、Cookie を使用しない、または接続に使用するブラウザーに応じて Cookie の動作を選択するを構成できます。

セッション Cookie は、セッション情報をセッションのクライアント情報に関連付けます。 セッションとは、ユーザーをサイトに接続する期間です。 Cookie は、クライアントと HTTP ヘッダー内の Web サーバー間で、すべての要求と共に渡されます。

Cookie はリダイレクトを必要としないため、Cookie を使用したセッション状態の追跡は、Cookies を使用しない他の方法と比べて効率的です。 さらに、Cookie では Web ページをブックマークすることができます。また、ユーザーがあるサイトから別のサイトに移動した後、元のサイトに戻った場合でも、状態を保持します。 ユーザー Cookie の 1 つの欠点は、ユーザーが自分のブラウザーで Cookie を無効にすることができることです。

[デバイス プロファイルを使用する] Cookie モードでは、ブラウザーで Cookie がサポートされている場合、その Cookie が使用されます。それ以外の場合、Cookie は使用されません。 デバイス プロファイルが Cookie のサポートを示している場合、ユーザーが Cookie のサポートを無効にしているかどうかに関係なく、Cookie が使用されます。

[自動検出] Cookie モードでは、プロファイルが Cookie をサポートしている場合、モバイル デバイスで Cookie が使用されます。それ以外の場合、Cookie は使用されません。 Cookie をサポートすることが判明しているデスクトップ ブラウザーでは、ブラウザーで Cookie のサポートが有効になっている場合、ASP.NET は Cookie を使おうとします。 Cookie のサポートが無効の場合、セッション状態は、URL に格納されます。

Cookie を使わずに、セッション状態を構成できます。 URI (Uniform Resource Identifier) を使ってセッション状態を処理する場合、セッション ID は URI 要求内にクエリ文字列として埋め込まれ、最初に要求された URL にこの URI がリダイレクトされます。 変更された URI は要求はセッションの有効期間使用されるため、Cookie は不要です。

セッション状態を追跡するために URI を使用と、ブラウザーのサポートの問題やユーザーが cookie を無効にする可能性を含む、cookie の欠点を回避することができます。 ただし、URI の使用には以下の欠点があります。

• セッション状態を失うことなく絶対 URL を使用することができません。つまり、ユーザーが別のアプリケーションに移動してから、元のアプリケーションに戻ると、そのページにはユーザーの入力が残っていないということです。
• セッション状態が失われるため、Web ページをブックマークすることができません。

Cookie を使用して、セッション状態を保存する場合は、次の設計上の決定を行ってください。

• Cookie モードの選択: 自動検出、Cookie の使用、デバイス プロファイルの使用、または URI の使用を選択します。
• URI の使用を選択しない場合は、Cookie の名前を指定します。
• URI の使用を選択しない場合は、Cookie がタイムアウトするまでの分数を指定します。
• Cookie の使用を選択しない場合は、期限切れのセッション ID を再生成するかどうかを決定します。

2.2. ページおよびコントロールの設定

ASP.NET ページには、ページの実行時に ASP.NET を認識して処理する追加の要素が含まれます。 ASP.NET ページには、再利用可能なカスタム コントロールを含めることもできます。 これらのカスタム コントロールは、サーバー上で処理されます。 このため、サーバーのコードを使用して、ASP.NET Web ページのプロパティを設定することができます。

IIS 8 では、以下の ASP.NET ページと、ユーザー コントロール設定を構成できます。

• ビヘイビアー設定: 現在のページの要求が終了した場合に、Web ページの表示状態や、Web ページに含まれているサーバー コントロールの表示状態を保持するかどうかなどです。
• 全般設定: すべてのページに含まれる名前空間などです。
• コンパイル設定: ページがコンパイルされるか解釈されるかなどです。
• サービス: セッション状態を有効にするかどうかなどです。

IIS 8 は、ASP.NET ページおよびコントロールの既定の設定を提供しますが、必要に応じてこれらの設定を変更できます。 たとえば、サイトのマスター ページ ファイルを設定したり、表示状態を有効にすることができます。

Web カスタム コントロールとは、サーバー上で実行され、ユーザー インターフェイスや他の関連機能を再利用可能なパッケージにカプセル化する、コンパイル済みのコンポーネントです。 IIS 8 では、1 つのアプリケーションの複数のページで使用可能なカスタム コントロールに対して、タグ プレフィックスと名前空間マッピングを指定できます。

アプリケーションの複数のページで使用されるカスタム コントロールに対して、タグ プレフィックス/名前空間のマッピングを指定する場合は、カスタム コントロールを追加します。

ASP.NET カスタム コントロールを構成する場合は、構成するコントロールごとに、次の情報が必要です。

• コントロールのタグ プレフィックスを指定します。
• コントロールの .NET 名前空間を指定します。
• コントロールを含むアセンブリを指定します。

2.3. アプリケーションの設定

構成の一部として eb.config ファイルでキーと値のペアを保存する場合、アプリケーションの設定を構成します。 アプリケーション設定により、保存されているアプリケーション構成データに迅速で簡単にアクセスできます。

カスタム コントロールを管理するため、特定の構成レベルのすべてのカスタム コントロールが含まれている一覧を表示できます。 この一覧は、タグ プレフィックス、ソースまたはアセンブリ、スコープ (ローカルまたは継承) 別に並べ替えることができます。 コントロールをスコープ別にグループ化して、現在の構成レベルでどのカスタム コントロールを適用するか、および親レベルからどのカスタム コントロールを継承するかを表示できます。

アプリケーションの複数のページで使用されるカスタム コントロールに対して、タグ プレフィックス/名前空間のマッピングを指定する場合は、カスタム コントロールを追加します。

アプリケーション設定を構成する場合、構成する設定ごとに次の情報が必要です。

1. 設定の名前を指定します。
2. 設定の値を指定します。

2.4. .NET コンパイルの設定

アプリケーション コードでユーザーの要求を処理する場合、ASP.NET は最初にコードを 1 つまたは複数のアセンブリにコンパイルする必要があります。 アセンブリとは、ファイル名拡張子が .dll のファイルです。 ASP .NET コードのコンパイル方法を制御する場合に、IIS 8 で .NET コンパイル設定を構成します。

IIS では、次の .NET コンパイル設定を構成できます。

• バッチ設定 (バッチ設定可能な最大ファイル サイズ、バッチ処理対象のコンパイルごとに設定可能な最大ページ数など)。
• 動作設定 (アプリケーションが再起動するまでに、リソースを動的にコンパイルできる回数など)。
• 一般設定 (動的コンパイル ファイルで使用されている既定の言語など)。

2.5. .NET グローバリゼーションの設定

グローバリゼーションとは、アプリケーション コードを国際化し、その他の言語やカルチャにアプリケーションをローカライズするプロセスです。 国際化プロセスを行うことで、可能な場合は常に同じアプリケーション コード ベースを使用して、任意のロケールにアプリケーション内容を翻訳、保存、取得、提示することができます。 ロケールとは、言語とカルチャ環境の両方の組み合わせです。 これには、日付の書式、時刻、通貨、電話番号などが含まれています。 ローカライズとは、可能であればコードを変更することなく、カルチャに応じて、コンテンツの翻訳と書式設定を行うことで、アプリケーションを別のロケールに適応させることです。

サーバー上のすべての ASP.NET アプリケーションにグローバリゼーション設定を適用する場合、Web サーバー レベルで ASP.NET アプリケーションのグローバリゼーション設定を変更できます。 また、サイト、アプリケーション、ディレクトリ、およびファイルの ASP.NET グローバリゼーション設定を編集することもできます。

IIS では、次のグローバリゼーション設定を構成できます。

• カルチャ設定 (UI カルチャ、UI 言語など)
• エンコーディング設定 (応答ヘッダーのエンコード方式など)