IIS の技術メモ

ISS に関心のあるユーザ向けに、この付録ではアプリケーション・プール、Web ガーデン、およびビットネスについて説明します。

IIS アプリケーション・プールおよび Web ガーデン

IIS バージョン 6 では、Web サーバ環境全体のスケーラビリティと復元力がさらに向上しました。

IIS バージョン 6 では、サーバ・リソースの管理に使用できる、調整可能なアーキテクチャを介した Web ホスティング・サービスを実現しています。これにより、安定性、効率性、およびパフォーマンスが向上しました。IIS では、アプリケーションをプロセスの分離したプールに分け、メモリ・リーク、プロセスの不具合、および過度に使用しているリソースを自動的に検出します。問題が発生すると、IIS では障害のあるリソースを停止して再配置し、障害のあるプロセスを解析ツールに結び付けることで、これらの問題を管理します。

IIS バージョン 6 は、次の 2 つの相互排他モードのいずれかで実行できます。

ワーカ・プロセス分離モード。IIS 6.0 の既定のモードです。不具合のあるアプリケーションの影響を受けないように World Wide Web Publishing サービス (WWW サービス) の主なコンポーネントを分離し、ワーカ・プロセス・アーキテクチャを使用して、アプリケーションを他のアプリケーションから保護します。Microsoft では、IIS 5 の分離モードの使用が必要になるような特定の互換性の問題がない限り、ワーカ・プロセス分離モードを使用することを推奨しています。静的コンテンツ、単純な ASP アプリケーションおよび CSP アプリケーションを扱う Web サイトは、ワーカ・プロセス分離モードで実行する IIS 6.0 に移行できる必要があります。
IIS 5.0 の分離モード。このモードでは、以前のバージョンの IIS 専用に開発されているためにワーカ・プロセス分離モードと互換性のないアプリケーションを実行できます。IIS 5.0 で適切に動作するアプリケーションは、IIS 6.0 上で IIS 5.0 の分離モードを使用して正しく動作します。CSP アプリケーションの場合、このモードを使用する必要はありません。

Web アプリケーションを実行する場合、ワーカ・プロセス分離モードの方が、IIS 5.0 の分離モードよりも高度な既定のセキュリティを提供します。既定では、ワーカ・プロセスはネットワーク・サービスの ID で動作します。ネットワーク・サービス・アカウントは、IIS 5.0 の分離モードで既定となっているアカウントよりも低いアクセス権を持っています。IIS 5.0 のアプリケーション・モードでプロセス内で稼動する Web アプリケーションは、ローカル・システムとして実行されます。ローカル・システム・アカウントでは、コンピュータにあるほとんどのリソースの読み取り、実行、および変更が可能です。

アプリケーション・プール

アプリケーション・プールとは、1 つ以上のアプリケーションを、1 つ以上のワーカ・プロセスのセットに関連付ける構成です。アプリケーション・プールにある各アプリケーションは、ワーカ・プロセスの境界によって他のアプリケーションから分離されているので、あるアプリケーション・プールで実行中のアプリケーションに起因する問題によって、別のアプリケーション・プールにあるアプリケーションが影響を受けることはありません。

新しいアプリケーション・プールを作成して、Web サイトやアプリケーションをこれらのプールに割り当てることで、サーバの効率性と信頼性を高めることができます。あるアプリケーションを処理しているワーカ・プロセスに不具合が生じた場合でも、プールを介して動作する他のアプリケーションは常に利用できます。

アプリケーションは IIS 内でそのパスによって定義されます。例えば、/csp などです。

Web ガーデン

信頼性をさらに高めるために、アプリケーション・プールを複数のワーカ・プロセスでサポートするように構成できます。複数のワーカ・プロセスを使用するアプリケーション・プールを Web ガーデンといいます。Web ガーデン内のワーカ・プロセスは、特定のアプリケーション・プールに到着する要求を共有します。あるワーカ・プロセスに障害が発生しても、別のワーカ・プロセスが引き続き他の要求を処理できます。

Web ガーデンと Web ファームは異なることに注意してください。Web ガーデンは、1 つのアプリケーション・プールに複数のワーカ・プロセスを指定することで、1 台のサーバ上に構成されます。Web ファームは、複数のサーバを使用して 1 つの Web サイトをサポートするものです。

1 つのアプリケーション・プールに対して 1 つの Web ガーデンを作成すると、以下の状況でパフォーマンスを強化できます。

要求処理の堅牢化：アプリケーション・プール内の 1 つのワーカ・プロセスが停止した場合 (例えば、スクリプト・エンジンの応答が停止した場合)、他のワーカ・プロセスがそのアプリケーション・プールに対する要求を受け入れ、処理できます。
リソース競合の軽減： Web ガーデンが安定した状態になると、ラウンドロビン方式によって、新しい各 TCP/IP 接続が Web ガーデン内のワーカ・プロセスに割り当てられます。これにより、負荷が緩和され、ワーカ・プロセスにバインドしているリソースの競合が軽減されます。

アプリケーション・プール、Web ガーデン、および CSP

アプリケーション・プールと Web ガーデンの構成は、NSD ベースのゲートウェイ構成の動作に影響を与えません。これは NSD と通信する ISAPI モジュールは、永続情報やその他のリソース (Caché への接続など) をプールしないためです。永続リソースはすべて NSD モジュールで保持されます。NSD と通信する ISAPI モジュールは、IIS で ISAPI モジュールを管理する方法が変更されてもその影響を受けません。

NSD 以外をベースとするゲートウェイ構成 (CSPms.dll および CSPmsSys.dll) の方が、IIS で ISAPI 拡張を管理する方法の変更に敏感です。これは、永続リソース (Caché への接続など) のプーリングが拡張自体で行われるためです。

使用するワーカ・プロセスを 1 つのみとするように構成したアプリケーション・プールは、単一の Web アプリケーション・パス (/csp など) のコンテキスト内におけるゲートウェイの動作に対して目に見える影響を及ぼしません。ただし、複数のワーカ・プロセスを使用する構成の場合 (Web ガーデン)、CSP ゲートウェイの負荷は、プールに属するすべてのワーカ・プロセス間で均等に分散されます。各ワーカ・プロセスは、CSP ゲートウェイ・モジュールのそれぞれのインスタンスを管理します。この処理管理アーキテクチャにより、ゲートウェイの動作に関する問題は発生しませんが、以下の制限事項を念頭に置く必要があります。

ゲートウェイの構成に対する変更を有効にするには、IIS を再起動する必要があります。この場合、インターネット・サービス・マネージャのコントロール・パネルではなく、メインの Windows サービスのコントロール・パネルから World Wide Web Publishing サービス全体を再起動する必要があります。
ゲートウェイのシステム管理のフォーム (システム・ステータス) を使用して、CSP アプリケーションで使用する接続を正確に監視することはできません。システム・ステータスには、現在のワーカ・プロセス (つまり、ゲートウェイの要求を処理するワーカ・プロセス) にアタッチされている、ゲートウェイのインスタンスのステータスが、指定されたどの時点でも反映されています。
各 CSP アプリケーション (アプリケーションの Web パスで定義) は、Caché に対する永続接続のそれぞれのプールを維持します。また、アプリケーション・プール内の各ワーカ・プロセスは、Caché への永続接続のプールを各自維持します。ゲートウェイが使用する、Caché への最大接続数および最小接続数を構成する際に、この動作を念頭に置く必要があります。これらの設定は、プール内のすべてのゲートウェイ・インスタンスに適用されます。
ステート認識セッション (保持モード 1) は、Web ガーデンの構成では使用できません。特定の要求の処理に使用する、ゲートウェイのインスタンスを制御できないためです。したがって、これらの構成では、ステート認識要求を専用の Caché プロセスにルーティングできません。

こうした制限事項の一部は、CSP ゲートウェイの将来のバージョンで完全にまたは部分的に撤廃される予定です。ただし、ゲートウェイは IIS とは別に管理されているため、NSD ベースのオプションはこれらの制限事項の影響を受けないことに注意してください。

最後に、NSD 以外のバージョンのゲートウェイに対してワーカ・プロセス構成パラメータが及ぼす影響を考慮する必要があります。特に、アイドル・タイムアウトおよびプロセスのリサイクルの影響に留意する必要があります。

ワーカ・プロセスのアイドル・タイムアウト

多くの場合、未使用のワーカ・プロセスを終了して、システム・リソースの浪費を避ける必要があります。指定した時間が経過した後、ワーカ・プロセスを適切に閉じるように構成できます。この機能を使用すると、処理の負荷が大きい場合、特定のアプリケーションが頻繁にアイドル状態になる場合、または新しい処理領域がない場合に、リソースの管理を改善できます。

ワーカ・プロセスが終了すると、そのプロセスが管理するゲートウェイのインスタンスも閉じ、このゲートウェイ・インスタンスが保持する Caché への接続のプールも終了します。もちろん、他のステートレスな接続は CSP アプリケーションのユーザに対して透過的な方法で常に置き換えられますが、ステート認識セッション (保持モード 1) は、ホスト接続が閉じると終了します。

ワーカ・プロセスのリサイクル

ワーカ・プロセスを定期的に再起動して、障害のある Web アプリケーションをリサイクルできるように IIS を構成できます。この機能は、アプリケーション・プールを正常な状態に保ち、リークしたシステム・リソースを復元するのに役立ちます。

経過時間、処理された要求の数、予約した時間、およびメモリの使用状況に基づいて再起動するようにワーカ・プロセスを構成できます。

ワーカ・プロセスを閉じることによる CSP ゲートウェイへの影響については、前のセクション (アイドル・タイムアウト) に説明があります。このセクションでも同じ考慮事項が適用されます。CSP アプリケーションは、慎重に管理されるチャネルを介してのみ CSP ゲートウェイと相互運用できるので、CSP アプリケーションをサポートするワーカ・プロセスのリサイクルはお勧めしません。

ビットネス — Windows の 64 ビット・サーバ上での 32 ビット・アプリケーション

Note:

このセクションは、ホスト Web サーバのアドレス空間にロードされるモジュール、つまり ISAPI 拡張およびネイティブ・モジュール (CSPms[Sys].dll および CSPcms.dll) に適用されます。 CGI モジュールは、IIS に関しては分離されたプロセスとして動作するため、影響を受けません。

64 ビット Windows 2003 のインストールでは、IIS 6.0 は 32 ビット・モードと 64 ビット・モードのいずれかで動作するように構成できます。 Enable32bitAppOnWin64 メタベース・キーは切り替え可能で、すべてのワーカ・プロセスは選択されたビットネス・モードで動作します。この設定は、IIS インストール全体に適用されます (つまり、サーバが管理するすべてのアプリケーション・プールにグローバルに適用されています)。

IIS 7.0 では、Enable32bitAppOnWin64 設定がアプリケーション・プールのレベルまで下がっています。このため、特定のアプリケーション・プールに対してビットネスを設定することが可能となっています。つまり、単一のサーバ・インストール内で、1 つのアプリケーション・プールでネイティブ 64 ビット・アプリケーションを、もう 1 つのアプリケーション・プールで 32 ビット・アプリケーションを実行するように構成することが可能です。

アプリケーション・プールのビットネス設定にアクセスするには、IIS コントロール・パネルで以下の手順に従います。

左側のパネルで [アプリケーションプール] を選択します。
適切なアプリケーション・プールを選択します。
右側のパネルで [詳細設定] を選択します。
[詳細設定] ダイアログが表示されます。 [全般] セクションに [32 ビットアプリケーションの有効化] 設定が表示されます。これは True または False に設定できます。

ちなみに、この構成設定は、Windows コマンド行で appcmd コマンドを使用して操作できます。以下はその例です。

appcmd set apppool /apppool.name:DefaultAppPool/enable32bitapponwin64:true

この例では、アプリケーション・プール DefaultAppPool を 32 ビット・モードで実行するように設定しています。

また、appcmd コマンドを使用して、ビットネスに基づいてアプリケーション・プールをリストすることもできます。例えば、64 ビット・モードで動作するすべてのアプリケーション・プールをリストするには、以下のコマンドを使用します。

appcmd list apppools /enable32bitapponwin64:false

最後に、アプリケーション・プールは異なるビットネス・モードで実行できるため、アプリケーション・プールがロードするネイティブ・モジュール (および ISAPI 拡張) 自体がそのプールの正しいビットネスでなければなりません。例えば、ホストのアプリケーション・プールが 64 ビットの場合は、64 ビットのゲートウェイ・モジュール (CSPms[Sys].dll など) を使用する必要があります。ホストのアプリケーション・プールが 32 ビットの場合は、32 ビットのゲートウェイ・モジュールを使用する必要があります。

個々のモジュールのビットネス・チェックは、モジュールの web.config ファイルの preCondition を通して行われます。 CSP ゲートウェイの場合、このファイルは通常、次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="CSPGateway_All" path="*" verb="*" modules="CSPms" resourceType="Unspecified" \
             preCondition="bitness64" />
        </handlers>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <remove segment="bin" />
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

precondition 節のビットネス設定に注意してください。ここでは、ビットネスは bitness64 に設定されています。これは、IIS が、64 ビット・アプリケーション・プールで動作する 64 ビット・ゲートウェイ・モジュールをチェックすることを意味します。

32 ビット・アプリケーション・プールが使用されている場合は、32 ビット・ゲートウェイ・モジュールを使用し、preCondition を bitness32 に設定する必要があります。

インストールされたモジュール、precondition 節、またはホストのアプリケーション・プールが予期するものの間に不整合がある場合、IIS は以下のようなエラー状態を返します。

Error:
The module(s) assigned to this handler mapping has the following preconditions that are not
present in the handler mapping:
bitness64
Runtime errors may occur if a handler mapping does not have a set of preconditions that are
equally as restrictive as, or more restrictive, than the module(s) assigned to the mapping.
Please ensure that this handler mapping has the correct preconditions, and that the 
preconditions are not in conflict.