Web お役立ち情報IIS 6.0 でアプリケーション プールを構成する

Brett Hill

IIS 6.0 に施された最大の機能強化は、アプリケーション プールの導入でした。IIS 6.0 がワーカー プロセス分離モード (Microsoft® Windows Server™ 2003 を新規インストールしたときの既定のモード) で実行されている場合、すべての IIS 6.0 サイトがアプリケーション プールで実行されます。各プールは 1 つの w3wp.exe インスタンスに関連付けられています。w3wp.exe は、プールに関連付けられているアプリケーションのホスト プロセスです。w3wp.exe は "ワーカー プロセス" のことで、W3 (www の意味) WP (ワーカー プロセス) .exe という名前が付いているのは、そのためです。

プールは複数のワーカー プロセスを含むように構成できるため、厳密には "1 つ以上の w3wp.exe インスタンス" と説明すべきですが、そのような構成が役に立つことはめったにありません。説明を単純にするため (また、少なくとも 95% の場合に当てはまるので)、ここでは各アプリケーションが 1 つの w3wp.exe インスタンスに関連付けられていると仮定して説明します。

IIS 5.0 のプロセス モデル

IIS 5.0 では、アプリケーションのアプリケーション保護を "低"、"中 (プール)"、または "高" に設定して、アプリケーションをホストするワーカー プロセスを制御しました (図 1 参照)。

IIS Web の設定

図 1 IIS Web の設定

アプリケーション保護 "低" で実行するように割り当てられたコンテンツは、Inetinfo.exe で実行されました。Inetinfo では、IIS コア プロセスがホストされました。そのため、アプリケーションのホスト プロセスが停止またはハングするような方法でアプリケーションでエラーが発生すると、Web サーバー全体の機能が停止しました。

アプリケーション保護 "中 (プール)" では、複数のアプリケーションが 1 つの dllhost.exe インスタンスを共有しました。この方法には、アプリケーションが Inetinfo から分離されているためアプリケーションでエラーが発生しても Web サーバーが停止しないというメリットや、1 つのプロセスに複数のアプリケーションが含まれるため Web サーバーのオーバーヘッドが削減されるというメリットがありました。

アプリケーション保護 "高 (分離プロセス)" では、1 つのアプリケーション (または一連のアプリケーション) を独自のプールで実行するように割り当てて、Inetinfo と他の dllhost インスタンスから分離することができました。

この設計は多くのユーザーの役に立ちましたが、分離された dllhost.exe インスタンスを最適な数だけ保持することはできません (IIS のドキュメントでは、インスタンスの数は最大 10 個にすることを推奨していますが、実際にはより多くのインスタンスを保持できます)。また、dllhost のプロセス ID を変更する作業が困難になります。企業環境では、dllhost のプロセス ID の変更が必要になることがよくありますが、Web アプリケーションを監視する組み込みの機能も存在しません。

IIS 6.0 におけるアプリケーション プールの割り当て方法

IIS 6.0 では、アプリケーション プールを必要な数だけ構成することが可能で、条件がそろえば何万個ものプールを構成できます。つまり、制限要因となるのは、IIS 6.0 自体ではなく、アプリケーションで使用されるリソースのみです。決定する必要があるのは、必要なプールの数と使用する組織構造です。プールを構成するいくつかの方法については、補足記事「プールの方法」を参照してください。

プール計画を選択したら、プールには、わかりやすい名前を付けるようにしてください。プールが 2 ~ 3 個しかなければ、Application Pool Number 2 のような名前を付けてもたいしたことではないと思うでしょうが、新しい社員を雇用したり、休暇を取ったり、またはプール数が増えたりした場合は、汎用的な名前からは使用目的がよくわかりません。

また、アプリケーション プールは、トラブルシューティング手法として使用できることを覚えておいてください。問題の原因として疑わしいアプリケーションがある場合は、そのアプリケーションを専用のプールに分離します。そうすることで、アプリケーションを個別に監視することが可能になり、他の重要なアプリケーションに悪影響を与えないようにすることもできます。

プールの方法

汎用アプリケーションをプールし、ミッション クリティカルなアプリケーションを分離する: このモデルでは、ミッション クリティカルなアプリケーションは専用のプールに含まれます。そのため、ミッション クリティカルなアプリケーションを、他のプールで不適切に動作しているアプリケーションから分離することが可能で、アプリケーションの監視、トラブルシューティング、および構成をより容易に行えます。汎用アプリケーションは、リソースを節約するために 1 つのプールに追加し、必要以上にプールを作成しないようにして、管理オーバーヘッドを削減できます。

アプリケーションを種類別に分離する: 多くの場合、アプリケーションは言語またはテクノロジ別にプールされます。ASP.NET アプリケーションと従来の ASP アプリケーションを同じプール内に混在させることはできますが、アプリケーションを言語別にプールに分類することで、複雑さを回避できます。たとえば、ASP アプリケーションと ASP.NET アプリケーションが同じプール内に存在し、ASP アプリケーションで問題が発生してワーカー プロセスの再起動が必要な場合、ASP.NET アプリケーションもリセットされます。

不適切に動作するアプリケーションを分離する: Microsoft.com では、不適切に動作するアプリケーションを適切に動作するアプリケーションから分離しています。新しいアプリケーションは "一時的な" プールに追加して、稼動時間とパフォーマンスを監視します。アプリケーションの安定性が時間をかけて証明されると、アプリケーションを適切に動作するアプリケーションのプールに移動します。安定性が証明されないと、アプリケーションは分離されたままになります。この方法は、記録的な稼働時間を実現するのに役立ちました。

統合する: 信頼性の高いアプリケーションまたは静的なサイトを 1 つのプールに統合します。そうすることで、より多くの問題がないアプリケーションをまとめることができます。

アプリケーション プールの構成

作成するプールを決定したら、プールを構成するのに最適な方法を考える必要があります。既定の設定をそのまま使用することは可能で、ほとんどの場合、それでうまく機能します。ただし、調整が必要な場合は、いくつかの操作を実行できます。たとえば、アプリケーション プールのルート ノードを右クリックし、そこで設定を調整することをお勧めします。ここで設定を調整すると、すべてのアプリケーション プールで設定が継承されるため、各プールを個別に構成する必要はありません。また、新しいプールには調整済みの設定が適用されるので、作成時から適切な構成になっています。

では、アプリケーション プールのプロパティを見ていき、個々の設定をいくつか確認しましょう。

IIS 6.0 でアプリケーション プールを停止および再起動すると、リサイクルが発生します。リサイクルは、[アプリケーション プールのプロパティ] ダイアログ ボックスの [リサイクル] タブ (図 2 参照) で手動で構成したり、プログラムを使用して構成したりできる多数のイベントが原因で発生する可能性があります。このプロセスは "重複するリサイクル" と呼ばれ、これらのプロセスを適切にリサイクルできるように設計されています。新しい要求は新しいワーカー プロセスにルーティングされますが、古いワーカー プロセスは既存の接続に対応し続けます。リサイクルするように設定されているプロセスは、処理する要求がなくなるまで、または構成されているタイムアウトに達するまで、メモリに保持されます。

[リサイクル] タブ

図 2 [リサイクル] タブ

アプリケーション プールは、定期的にリサイクルすることをお勧めします。そうすることで、メモリの断片化、メモリ リーク、中断したスレッドなどの不要なものを排除できます。アプリケーション プールをリサイクルすると、インプロセスに格納されているプールのセッション状態情報は失われますが、他のプールには影響しないことを覚えておいてください。ただし、ASP.NET では、セッション状態をワーカー プロセスの外部に格納できるため、セッション情報がリサイクル時に失われることはありません。

既定では、[ワーカー プロセスのリサイクル (分ごと)] は 1,740 分 (29 時間) に設定されています。そのため、自動リサイクルが毎日、前日の 5 時間遅れで発生します。1 日の中でサーバーの負荷が最も低い時間にリサイクルが発生するように、この設定の変更を検討することもできます。Web ファームでは、設定を調整できます。

メモリをリークするアプリケーションがある場合、メモリ使用量が指定のしきい値に達したときにアプリケーションを自動的に再起動するように設定できます (図 3 参照)。このオプションは、リークが発生するアプリケーションで非常に役立ちます。管理者の手を煩わせることなく、アプリケーションを実行し続けることができます。

[パフォーマンス] タブ

図 3 [パフォーマンス] タブ

負荷の高いサーバーでは、[アイドル タイムアウト] の設定が非常に役立ちます。アプリケーション プールが 20 分間 (既定の設定) アクティブでない場合、そのプールはシャットダウンし、他の用途のためにリソースが解放されます。この設計はアプリケーション数が多く、リソースに関する厳しい制限があるサーバーでは役立ちますが、1 ~ 2 つのアプリケーションしかなく、リソースに十分余裕があるサーバーでは必ずしも必要な設計ではありません。

また、1 日に 8 ~ 10 回しか使用されず、1 回使用されたら次回使用されるまで約 1 時間使用されない、重要な Web アプリケーションがある場合について考えてみてください。アプリケーション プールが 20 分間アクティブでないときはシャットダウンするように設定されていると、アプリケーション ユーザーからは、初回アクセス時の応答はかなり遅いが、それ以降は問題ないという報告を受ける可能性が高くなります。このように初回要求時に応答が遅くなるのは、ワーカー プロセスを使用して要求を処理できない場合です。IIS では、ワーカー プロセスを起動して、IIS のコア コンポーネント (特定のスクリプト エンジン) を読み込む必要があり、場合によっては、応答が返される前にスクリプトをコンパイルする必要があります。リサイクル後に最初の要求を行ったクライアントでは、この処理で顕著な遅延が発生することがあります。このような状況では、20 分間アクティブでない状態が続いた後にワーカー プロセスをシャットダウンしても大きなメリットはありません。

[要求キューの制限] の設定は、サーバーの負荷が非常に高い環境でのみ調整が必要です。1 秒あたり数千個の要求を処理し、ユーザーに対して "サーバー使用中" というメッセージがときどき表示される場合は、この数値を上げることをお勧めします。ただし、数値が小さいとサービス拒否攻撃に対して多少の保護が提供されるため、必要な場合以外は、この数値を上げないでください。

通常、[CPU 監視を有効にする] チェック ボックスはオフにします。CPU の使用率を調べる場合は、パフォーマンス モニターを使用することをお勧めします。CPU の調整が必要な場合は、リソース モニターを使用してください。

ほとんどのサーバーの場合、[Web ガーデン] には 1 より大きな値を設定しないでください。この値によって、アプリケーション プールの処理に使用されるワーカー プロセスの数が設定されます。要求はラウンド ロビン方式で別のワーカー プロセスに送信され、インプロセスのセッション状態情報を共有しません。一般に、この機能のメリットを享受するアプリケーションは、Web アプリケーションで使用されるリソースが大きく制約されているアプリケーションのみです。たとえば、1 つの接続で 4 ~ 5 個の要求を受け取ると完全に停止するように見える古いバックエンド システムへのデータベース接続では、この機能のメリットを享受できます。この場合、複数のワーカー プロセスがあると、複数の接続を保持できるので、パフォーマンスが向上します。いたずらに [Web ガーデン] に 2 以上の値を設定すると、アプリケーションで診断が非常に難しい問題を誘発するおそれがあります。

[状態] タブ (図 4 参照) の既定値を調整することは、めったにありません。

[状態] タブ

図 4 [状態] タブ

[Ping を有効にする] チェック ボックスをオンにすると、IIS 6.0 では、自動的にワーカー プロセスをクエリして、ワーカー プロセスが応答するかどうかが確認されます。ping という名前は付いていますが、インターネット制御メッセージ プロトコル (ICMP) の ping ではなく、内部関数が使用されます。この ping の結果としてネットワーク トラフィックが発生することはありません。

[ラピッド フェール保護を有効にする] チェック ボックスは、アプリケーションで一連のエラーが発生した後、そのアプリケーションでエラーが発生しないようにする機能です。重大な問題が発生していたり、短期間に繰り返しエラーが発生するアプリケーションを IIS 6.0 で継続的に起動しても意味がありません。

[起動の制限時間] と [シャットダウンの制限時間] は、ワーカー プロセスに起動またはシャットダウンが通知されてからアプリケーション プールが起動またはシャットダウンするまでに IIS 6.0 で待機する時間に関する制限を設定するために使用します。アプリケーション プールが 90 秒以内に命令に従わなかった場合、ラピッド フェール保護の目的から、エラーが発生したと見なされ、プロセスは終了します。

ここでも、ほとんどの場合、アプリケーション プールのプロセス ID を調整する必要はありません (図 5 参照)。既定の Network Service アカウントは、ネットワーク アクセスと Kerberos 認証を提供することを目的としたもので、高い権限を持つアカウントではありません。一意の ID の指定が必要な場合がありますが、一意の ID を指定することは可能です。他のアプリケーション プールからアプリケーション プール コンテンツを保護する方法の詳細については、「Windows Server 2003 と Internet Information Services (IIS) 6.0 でのアプリケーションの分離構成」を参照してください。

[識別] タブ

図 5 [識別] タブ

その他の設定

IIS 管理コンソールに表示されない、構成可能なオプションは、他にもいくつかあります。1 つ目のオプションは、IIS メタベースの AppPools キーの LogEventOnRecycle プロパティです (/LM/W3SVC/AppPools にあります)。このプロパティに値 255 を設定すると、すべてのリサイクル イベントがイベント ログに記録されます。既定では、一部のリサイクル イベントは記録されません。IIS メタベースを使用した作業の詳細については、TechNet マガジンの 2005 年 11/12 月号の記事「IIS メタベースの究明: Web サーバー構成の詳細を解き明かす (英語)」を参照してください。

2 つ目のオプションは、HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters レジストリ キーに、値データを 0xdff4e7 に設定した ErrorLoggingFields 値を追加することです。この設定によって、httperr.log に記録されているすべてのエントリに、アプリケーション プールの名前をはじめとする役立つ情報が追加されます。エラー ログ記録の詳細については、「Windows Server 2003 SP1 での HTTP API への変更点 (英語)」を参照してください。

まとめ

偏見があることは承知ですが、私はマイクロソフトの IIS エバンジェリストなので、当然ながら、IIS は、すばらしいサーバーだと思っています。しかし、偏見を持たなくても、IIS 6.0 が世界中で最も大きく複雑ないくつかのサイトを安定した状態で支えていることは紛れもない事実です。(このコラムの執筆時点の情報ですが) 現在までに、IIS 6.0 のセキュリティ修正プログラムは、緊急度の高いものはリリースされておらず、申し分のない状態です。また、IIS 6.0 で実行するアプリケーションの稼働時間とパフォーマンスは大幅に強化されています。

Brett Hill は、マイクロソフトの IIS エバンジェリストです。マイクロソフトに入社する前は、IIS の MVP として 3 年間活躍し、IIS のトレーニングを生業としていました。現在も IISlists.com でディスカッション グループを運営しています。Brett の連絡先は、brett@iisanswers.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。