特集　Windows Server 2003完全ガイド アーキテクチャを一新した新世代アプリケーション・サーバ ――　機能と信頼性を大幅に向上させたIIS 6.0　―― IIS 6.0の機能の詳細 1．信頼性を向上させるアプリケーション・プール 田口景介 2003/02/27

注意：本コーナーは、当初「Windows .NET Server 2003完全ガイド」として記事公開を開始 しましたが、その後マイクロソフトは、製品名称から「.NET」を取り、「Windows Server 2003」と改めました。この名称変更以降の記事については「Windows Server 2003」の表記で統一していますが、それ以前の記事については、基本的に公開時点での「Windows .NET Server 2003」をそのまま使っています。ご了承ください。

　前回は、IIS 6.0の概要について解説した。今回と次回の2回で、IIS 6.0の機能について、より詳しく見ていくことにする。

安定性、信頼性、可用性

　アプリケーションが複雑化するにつれ、安定したコードの開発は困難になる。これは当然だし、避けようがないことだが、不安定なコードがシステムまで道連れにして、悪影響を及ぼすというのであれば、それはプラットフォームの責任が問われる問題だ。

　かつてのWindowsは、1つのアプリケーションがクラッシュするだけで、システム全体が動作不能に陥るという脆弱なOSだったが、NTカーネルを導入した現在のWindowsは、以前とは比べ物にならないほどの安定性を持っている。その原動力はいくつもあろうが、各アプリケーションのプロセス空間、それにアプリケーションとカーネルのシステム・モードを完全に分離したことによるところが大きい。それぞれを独立させることにより、限られたインターフェイスを除けば、各プロセスの動作が互いに影響を及ぼすことはなくなった。その結果、現在のWindowsは、カーネル・モードで動作するデバイス・ドライバの類がトラブルを起こさない限りは、システム全体がクラッシュする可能性は非常に低いOSとなっている。

　IIS 6.0に見られる進化は、こうしたWindowsの進化になぞらえることができる。前回説明したワーカー・プロセス分離モードにより、アプリケーションを実行するワーカー・プロセスが個別のプロセスとして実行されるようになった結果、互いに影響を及ぼす範囲が限定された。そして、クライアントからのリクエストをキューイングするコンポーネントがカーネル・モードに移動され、ワーカー・プロセスからの影響が最大限に除外された。どちらも共通する構造を現在のWindowsに見ることができる。

　ただそれだけではなく、IIS 6.0では、いままでには見られない監視サービスも備えられ、より高い安定性が確保されている。従来のIISでは、ワーカー・プロセスに不具合が発生したら、管理者が手作業でIISを再起動するなどして、面倒を見なければならなかったが、IIS 6.0ではヘルス・モニタリングと呼ばれる監視サービスによって異常が検出されると、そのプロセスが自動的に再起動される仕組みになっている。その昔、無反応になったWindowsアプリケーションを検出し、復帰させるCrash Guardと呼ばれる製品がSymantec社から販売されていたが、これと同種のサービスがIISには標準で備わっていると考えてよさそうだ。

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

　ところで、なぜプロセス空間を分離すれば、システムの安定性を向上させられるのだろうか。理由の1つとしていえるのは、プロセスが分離されていれば、メモリ空間が分離され、ほかのプロセスが使用しているメモリを直接読み書きできなくなるからだ。そうすれば、誤動作したアプリケーションによって、同一ホストにあるほかのアプリケーションのメモリ空間の内容が破壊される心配はなくなる。また、あるプロセスがブロック状態に入って処理がストップしてしまっても、ほかのプロセスは処理を継続できるのも理由の1つに数えられる。それに、アプリケーションに与えられる実行権限はプロセス単位で設定できるため、各アプリケーションに必要な最低限の権限だけを与えておけば、何らかの攻撃を受けても、本来アクセスされるはずのない、重要なファイルを読み取られるなどの被害を防ぐことが可能だ。

■アプリケーション・プール
　ただし、IIS 6.0をインストールした直後の状態では、IIS 5.0と大差なく、すべてのアプリケーションが同一のワーカー・プロセスで処理されるように設定されている。プロセスを分離し、ワーカー・プロセス分離モードを効果的に利用したいのであれば、「アプリケーション・プール」を新規作成し、これにアプリケーションが所属するように設定を変更しなければならない。

　アプリケーション・プールとは、リクエスト・キューとワーカー・プロセスをまとめる単位である。アプリケーションは、いずれか1つの指定されたアプリケーション・プールに所属する。そして、同一のアプリケーション・プールに所属するアプリケーションは、同一のリクエスト・キューとワーカー・プロセスを共有することになる。つまり、プロセスの分離はアプリケーション・プールを単位として行われるのである。初期状態では、「DefaultAppPool」と名付けられたアプリケーション・プールが1つ定義されているだけなので、必然的にすべてのアプリケーションはDefaultAppPoolに所属することになり、プロセス分離は行われず、すべて同一のワーカー・プロセスによって処理されてしまう。

　特定のアプリケーションを専用のアプリケーション・プールで実行させたければ、次の画面に示すように、まずアプリケーション・プールを新規作成する。

アプリケーション・プールの作成

アプリケーション・プールを新たに作成するには、左側のペインで［アプリケーション プール］を選択して右クリックするか、右側のペインでマウスを右クリックし、ポップアップ・メニューから［新規作成］−［アプリケーション プール］を選択する。

現在のアプリケーション・プールの一覧を表示するには、このツリーの下を展開する。 　 現在定義されているアプリケーション・プール。デフォルトでは、一番上の「DefaultAppPool」だけが存在する。 　 作成するアプリケーション・プールの名前。 　 アプリケーション・プールの各種設定値をデフォルトのままにするときに選択する。 　 既存のアプリケーション・プールと同じ設定にするには、こちらを選択する。

　アプリケーション・プールを作成したら、次はアプリケーションのプロパティを開いて、所属するアプリケーション・プールを選択すればよい。

アプリケーションが所属するプールの選択

アプリケーションごとに、所属するアプリケーション・プールを選択できる。アプリケーション・プールの導入に伴い、従来の［高］［中］［低］で設定するアプリケーション保護はなくなった。

アプリケーションを選択するには、IISの管理ツールで仮想ディレクトリを選択し、その［プロパティ］−［仮想ディレクトリ］を表示させる。 　 所属するアプリケーション・プールを選択する。

　アプリケーション・プールが複数作成されていることは、タスクマネージャで簡単に確認できる。各アプリケーション・プールに対応付けられたワーカー・プロセスは、「w3wp.exe」として実行され、アプリケーション・プールが1つのときはw3wp.exeが1つ、2つあればこのプロセスが2つ現れる。

　ただしワーカー・プロセスは一定期間リクエストを処理せずにいると、自動的に終了する仕組みになっているので、初期状態（Webを全くアクセスしていない状態）では1つもw3wp.exeを見つけられないはずだ。これは、アプリケーション・プールを多数作成しても、アプリケーションがアクセスされない限りは、無駄にプロセスが起動されることはないということを意味している。

タスクマネージャでw3wp.exeを確認しているところ

ワーカー・プロセスは、初期状態では1つも起動されていないが、アプリケーション（Web）へのアクセスに応じて、オンデマンドに起動される。これは2つのワーカー・プロセス（w3wp.exe）が起動されているところ。

この場合は2つのワーカー・プロセスが起動されているので、w3wp.exeが2つ存在している。

■ISAPIエクステンションの更新が容易に
　アプリケーション・プールを分離する主な目的は安定性の確保だが、管理面でもメリットはある。

　IIS 5.0では、現在運用中のISAPIエクステンション（IISの拡張モジュール）を更新するには、いったんIISを完全に停止させなければならなかった。一度でもアクセスされたISAPIエクステンションは、メモリ上にロードされると同時にDLLファイルがロックされてしまい、上書きできなくなってしまうためだ。

　DLLファイルが上書きできなくなるのはIIS 6.0でも同じだが、IIS 6.0ではISAPIエクステンションを利用しているアプリケーション・プールだけを停止させれば、DLLは開放され、更新が可能になる。この作業中、ほかのアプリケーション・プールに所属するアプリケーションはいずれも影響を受けることなく、リクエストを処理し続けることができる。

　なお、ASP.NETで使われるアセンブリ（.NET Framework環境におけるプログラムの実装単位）は、アセンブリ・キャッシュに複製されてから実行されるため、ワーカー・プロセスを停止させることなく、いきなりDLLを更新することが可能だ。

■Webガーデン
　ここまでは、ワーカー・プロセスを分離するための道具としてアプリケーション・プールを解説してきたが、逆に複数のワーカー・プロセスを同一のアプリケーション・プールに割り当てることもできる。すると、1つのアプリケーションが複数のプロセスで処理されることになるため、マルチプロセッサ・システムで使用した場合のスケーラビリティを向上させることが可能だ。このように2つ以上のワーカー・プロセスが割り当てられたアプリケーション・プールは、「Webガーデン」と呼ばれる。

Webガーデン

1つのアプリケーション・プールに複数のワーカー・プロセスを割り当てた状態をWebガーデンと呼ぶ。Webガーデンの機能を利用すると、1つのアプリケーションが複数のプロセスで処理されることになるため、マルチプロセッサ・システムで使用した場合のスケーラビリティが向上する。

Webガーデンの設定は、各アプリケーション・プールの［プロパティ］画面で［パフォーマンス］タブを選択することによって行える。 　 割り当てるワーカー・プロセスの数。

カーネル・モード・ドライバHTTP.SYS

　IISの信頼性を支える3本柱のうち、2本目がカーネル・モード・ドライバであるHTTP.SYSである。HTTP.SYSはワーカー・プロセスから遠く分離され、ほかのプロセスから汚染されるのを防止されるとと同時に、パフォーマンスの向上にも貢献している。

■リクエスト／レスポンスのマネージャ
　HTTP.SYSは、HTTPに乗せて送受信されるすべてのデータを管理するマネージャである。あらゆるHTTPリクエストはHTTP.SYSによって受信され、リクエスト・キューに入れられる。このリクエスト・キューは、アプリケーション・プールごとに独立してHTTP.SYSによって管理されており、ワーカー・プロセスからの要求に応じてリクエストが取り出される。リクエストを処理すべきワーカー・プロセスがまだ起動されていないときに、ワーカー・プロセスを起動するのもHTTP.SYSの役割である。

　また、ワーカー・プロセスによる処理を終えて、レスポンスをクライアントへ戻すときもやはりHTTP.SYSを通過して、クライアントへと中継される。つまり、双方向に流れるすべてのリクエストとレスポンスが、たった1つのHTTP.SYSによって中継されるのである。その結果、HTTP.SYSがキャッシュの管理を行い、リクエストに対するレスポンスがすでにキャッシュにあれば、ワーカー・プロセスへと処理を移さずに、即座にレスポンスを返すことが可能になっている。また、キャッシュ以外にも、帯域制御やアクセス・ログの記録など、ワーカー・プロセスに依存しない、さまざまなサービスがHTTP.SYSを通して提供される。

HTTP.SYS

クライアントとの通信は、カーネル・モード・ドライバとして実装されたHTTP.SYSが担当する。そのほか、アプリケーションに依存しないキャッシュ管理やログの記録などもHTTP.SYSで処理される。

■カーネル・モード
　ところで、HTTP.SYSが担当する機能は、IIS 5.0にもほぼ同等に備わっていたものだが、それをなぜドライバとして実装し直し、カーネル・モードで動作させることになったのだろうか。その理由の1つはパフォーマンスの向上だが、これを解説する前に、簡単にカーネル・モードについて触れておこう。

　Windows NT／2000／XP、そしてWindows Server 2003と進化してきたNT系列のWindowsでは、システムを保護するために2種類のシステム・モードが設けられている。カーネルやデバイス・ドライバなどが実行されるカーネル・モードと、アプリケーションが実行されるユーザー・モードである。重要性の高いコードや、アプリケーション間で競合が発生するようなリソースへのアクセスは、特権モードであるカーネル・モードでしか実行できないように保護され、ユーザー・モードで動作する通常のアプリケーションによってシステムが不安定にさせられることがないよう防いでいるのである。

　ただし、ユーザー・モードとカーネル・モードの境界が常に明確だったわけではない。例えば、当初Windows NTのディスプレイ・ドライバは、一部ユーザー・モードで実行されていた。単純に考えれば、ビデオ・システムを制御するディスプレイ・ドライバは、カーネル・モードで実行されるのが自然だが、ディスプレイ・ドライバの機能を二分して、必要最小限のコードだけがカーネル・モードで実行される構成になっていたのである。なるべくカーネル・モードで動作する部分を少なくし、システムの安定性を優先させようとすればうなずける構成だが、その代償としてユーザー・モードとカーネル・モードの遷移が多発し、パフォーマンスに無視できない悪影響を与えていたため、その後すべてのディスプレイ・システムがカーネル・モードで実行されるように変更され、現在に至っている。

　このディスプレイ・ドライバとHTTP.SYSの共通点は、カーネル・モードとユーザー・モードの遷移にかかるオーバーヘッドを取り除くために、カーネル・モードへとコードを移設した点である。HTTP.SYSの場合は、キャッシュにヒットすれば、ユーザー・モードへ一切遷移することなく、カーネル・モードの中だけでリクエストを処理できるメリットがあるため、より効果的に機能するはずだ。

INDEX
	［特集］Windows .NET Server 2003完全ガイド
	IIS 6.0の機能の詳細
	1．信頼性を向上させるアプリケーション・プール
	2．動作状態の監視とセキュリティ機能
	3．IIS 6.0の管理
	4．そのほかの機能

　

Windows Server 2003完全ガイド

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）