Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

IIS の技術メモ

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

IIS アプリケーション・プールおよび 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 モジュールは、永続情報やその他のリソース (InterSystems IRIS への接続など) をプールしないためです。永続リソースはすべて NSD モジュールで保持されます。NSD と通信する ISAPI モジュールは、IIS で ISAPI モジュールを管理する方法が変更されてもその影響を受けません。

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

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

  • Web ゲートウェイの構成に対する変更を有効にするには、IIS を再起動する必要があります。この場合、インターネット・サービス・マネージャのコントロール・パネルではなく、メインの Windows サービスのコントロール・パネルから World Wide Web Publishing サービス全体を再起動する必要があります。

  • Web ゲートウェイのシステム管理のフォーム (システム・ステータス) を使用して、Web アプリケーションで使用する接続を正確に監視することはできません。システム・ステータスには、現在のワーカ・プロセス (つまり、Web ゲートウェイの要求を処理するワーカ・プロセス) にアタッチされている、Web ゲートウェイのインスタンスのステータスが、指定されたどの時点でも反映されています。

  • 各 Web アプリケーション (アプリケーションの Web パスで定義) は、InterSystems IRIS に対する永続接続のそれぞれのプールを維持します。また、アプリケーション・プール内の各ワーカ・プロセスは、InterSystems IRIS への永続接続のプールを各自維持します。Web ゲートウェイが使用する、InterSystems IRIS への最大接続数および最小接続数を構成する際に、この動作を念頭に置く必要があります。これらの設定は、プール内のすべてのゲートウェイ・インスタンスに適用されます。

  • ステート認識セッション (保持モード 1) は、Web ガーデンの構成では使用できません。特定の要求の処理に使用する、Web ゲートウェイのインスタンスを制御できないためです。したがって、これらの構成では、ステート認識要求を専用の InterSystems IRIS プロセスにルーティングできません。

Web ゲートウェイは IIS とは別に管理されているため、NSD ベースのオプションはこれらの制限事項の影響を受けないことに注意してください。

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

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

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

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

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

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

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

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

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

Note:

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

[32 ビット アプリケーションの有効化] 設定はアプリケーション・プール・レベルに適用されるため、特定のアプリケーション・プールにビットネスを設定できます。 単一のサーバ・インストールで、1 つのアプリケーション・プールでネイティブ 64 ビット・アプリケーションを、もう 1 つのアプリケーション・プールで 32 ビット・アプリケーションを実行するように構成することが可能です。

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

  1. 左側のパネルで [アプリケーション プール] を選択します。

  2. 適切なアプリケーション・プールを選択します。

  3. 右側のパネルで [詳細設定] を選択します。

  4. [詳細設定] ダイアログが表示されます。 [全般] セクションに [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 を通して行われます。 Web ゲートウェイの場合、このファイルは通常、次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="WebGateway_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.
Next sectionリモート Web サーバでの Web アプリケーションの使用
Previous sectionApache に関する考慮事項 (UNIX®/Linux/macOS)
FeedbackOpens in a new tab