第4回 柔軟性と機能性を大幅に高めたIIS 7.0（前編）：Windows Server 2008の基礎知識（2/3 ページ）

[奥主洋（エバンジェリスト），マイクロソフト株式会社 ]

新たな動作モードが加わったアーキテクチャ

　 ここからは機能面におけるIIS 7.0の変更点を見ていく。まずは全体像として押さえておきたいアーキテクチャの変更を、IIS 7.0のベースとなったIIS 6.0も含めて見ていこう。

　IIS 6.0ではHTTP.SYSというカーネル・モードで動作するいわばHTTP通信用のドライバが登場し、このドライバが使用するキューやキャッシュも一緒に設けることでWindows NT／Windows 2000に比べてパフォーマンス面の大幅な向上を図った。実際のパフォーマンスについては、Lionbridge Technologiesのサイトにある以下のレポートが詳しい。

• Windows Server 2003 File Server, Web Server, and Active Directory Performance Testing（Lionbridge Technologies）（英語）（PDF）

　同時にアプリケーション・プールという概念をIIS 6.0の新モードでは採用した。それまでの分離プロセスの考え方を進めて、もっと自由度を高くし、アプリケーションと実行プロセスの関係を明確に指定できるようにした。つまりn個のWebアプリケーションをn個のプロセスで実行するような複雑な指定ができるようになった。これにより、不安定なアプリケーションあるいは最重要なアプリケーションをほかのアプリケーションから切り離し、それぞれのサービス・レベルを調整できる。また、ヘルス・モニタリング機能を連動させ、例えばメモリ・リークが生じるような不安定なアプリケーションが実行されているプロセスは、定期的にその状態を調べて、あらかじめ設定したしきい値を超えると再起動するようにできるなど、実際の現場におけるWebサーバの運用に即した機能が追加された。

IIS 6.0のアーキテクチャ（プロセス分離構造）
IIS 7.0も基本的にこのアーキテクチャを踏襲しているが、後述するように統合モードが新設された点が異なる。
* WASM（Web Service Administration and Monitoring）はWWW発行サービス内で実行されるサービスの1つ。

　IIS 7.0ではこの大きな変更をそのまま踏襲しているので、アプリケーションが実行される実行プロセスの構造は変わらずにHTTP.SYS→ワーカー・プロセス（W3WP.EXE）のままである。

　IIS 6.0と比べて、アーキテクチャ面で明確に変わったのは動作モードである。IIS 6.0はIIS 5.0の互換モードを持っていたが、IIS 7.0も同様に「クラシック・モード」という互換モードを搭載している。これは一言でいえばIIS 6.0ワーカー・プロセス分離モードとの互換性を維持した動作モードである。これとは別にIIS 7.0の新モードとして「統合モード」が追加されている。IIS 7.0ではこの2つのモードで共にアプリケーション・プールが利用可能であり、その実行プロセスはw3wp.exeで統一されている。統合モードの詳細については、後編の「ASP.NETとの統合」を参照していただきたい。

　動作モードで注意すべき点としては、IIS 5.0対応アプリケーションとの互換性が挙げられる。IIS 5.0で動作していたアプリケーションを一気にIIS 7.0に移行する場合に、IIS 6.0のワーカー・プロセス分離モードで検証して何らかの修正が必要だったときには、IIS 7.0クラシック・モードという「互換」のモードであっても同様にアプリケーションの修正を強いられる可能性が高い。参考までにIIS 6.0のワーカー・プロセス分離モードに対応をするために、マイクロソフトが2005年ごろのセミナーで例としてリストアップしていたのは下記のような点である。

IIS 5.0で実行している内容やアプリケーション	ワーカー・プロセス分離モードで実行させるために必要な修正
READ_RAW_DATAフィルタ（IISの通知イベントを利用するフィルタの一種）	フィルタの機能を拡張として再記述し、アプリケーションのワイルド・カード・マッピングを利用する： EXCEL_URL
INETINFO／DLLHOSTとしてハードコード	アプリケーション自体を修正
Local Systemアカウントで実行されていることを期待	アプリケーション・プールのIDをLocal Systemに変更
WAM（Web Application Manager）オブジェクトを期待	アプリケーション自体を修正
マルチ・インスタンスで実行できない	リサイクルを無効化し、Webガーデンを利用しない
インプロセスであることに依存（ステート）	リサイクルを無効化し、ステートをプロセス外に保持する
IIS 5.0対応アプリケーションをIIS 7.0のクラシック・モードに移行するのに必要と思われる修正項目 これはIIS 6.0のワーカー・プロセス分離モードに対応をするためにマイクロソフトが2005年ごろのセミナーで例としてリストアップしていたもの。IIS 7.0のクラシック・モードに移行する場合でも、この修正が必要となる可能性は高い。

　なお、Windows 2000の環境では、ASPを用いたアプリケーションが多いと思われるが、これをIIS 7.0に移行する場合には、ASPそのものの互換性より、その背後にあるコンポーネントの互換性について検討・確認をした方がよいだろう。

モジュール構造の採用

　次に大きな変更は、やはり機能のモジュール化だろう。各種手法を検討し、ユーザーからの要望も加味した結果、やはり細分化することが最適という結論に達したようだ。

　IIS 7.0におけるモジュール化は、基本的には元（IIS 6.0）のw3core.dllのソース・コードから各機能を抽出し、別のDLLとして動作するためのインターフェイスを付加しつつ、既存のアプリケーションへの影響を考慮して、内部の処理はできるだけ変えないようにしたもようである。その結果、各機能は1つ1つ個別のDLL（モジュール）になり、その数はWindows Vista Ultimateで38、Windows Server 2008で40（RC0時点）に上る。

IIS 7.0における各機能のモジュール化
IIS 6.0では単一のDLLに組み込まれていた各機能が、IIS 7.0では個別のDLLに実装された。これにより脆弱性が生じたときの影響をより小さく抑えられるほか、メモリの使用量も削減しやすくなった。またモジュール単位で機能の追加・拡張がしやすいという利点もある。その半面、アプリケーションに必要なモジュールが組み込み済みか注意を払う必要が生じる。

　それでは、モジュール化の利点を整理しておく。引き続き重要であるセキュリティの観点ではもちろん効果的な変更である。必要のある機能のみをインストールでき、インストールされていないモジュールに脆弱性が見つかっても対処の必要がないからだ。これまでの構造のように細分化されておらず、常に全体をパッチで置き換える構造だと、脆弱性とは関係のない部分も修正される可能性があり、アプリケーションへの影響も大きくなる。しかしモジュール化されていると、部分的な更新を行った場合でもアプリケーションへの影響を最小限で済ませることができ、テストの規模を抑える効果も期待できるだろう。また不要なモジュールをワーカー・プロセスにロードしないようにすれば、使用するメモリも最小化できる。

　この変更はほかにも影響を及ぼすと考えられている。それはOSとIISの出荷タイミングの非同期化である。OSそのものを改変せずともモジュールの追加によってIISの機能を拡張できるので、マイクロソフトとしては必ずしもOS全体としてのメジャー出荷を待たなくても、完成度の高いモジュールができたらすぐに出荷できる。さらに付け加えると、IIS 7.0の開発部門は、可能な限り公開されたAPIを使用するように努めている。その結果、これまでのISAPIよりはるかに開発のしやすいAPIを、しかも開発部門が行うのと同じレベルで利用して、機能拡張のモジュールを開発できるようになった。これは現在サーバ機能の不足を感じて機能拡張をしてWebサーバを利用している方々にとっては朗報である。しかも、IIS開発チームも参画しているコミュニティ・サイトのIIS.netでは、公開・提供してよいモジュールについてはアップロードしてコミュニティで使えるようにすることを推奨しており、IIS 7.0の開発部門が作った検討中のモジュールなども入手可能だ。現在および今後の追加機能については、後編の「新しい役割もプラグイン」で解説する。

　ただし、この変更が及ぼすダーク・サイドについても触れておく必要がある。Windowsの強みは「簡単に複雑なことができる」ところにあるといえる。GUI中心でいろいろなことが整備されてきたのは、とかく煩雑で地道な作業をより簡便化し、ミスの少ない広範な構築を可能にするためだった。しかし、IIS 7.0のモジュール化がもたらすものは「複雑さ」かもしれない。とかく自由度を求める技術者と簡便さを求める技術者では期待値に矛盾が存在する。今回は自由度を上げたことになるが、そうすると明らかに簡便さが低下する部分が現れる。具体的には、サーバの構成をしっかり標準化しておかないと、サーバAの環境情報をサーバBに持っていったらエラーが発生し、原因がすぐには分からないというようなことが起こる。調べてみるとサーバAとサーバBではインストールされているモジュール数が異なっており、この結果エラー503（サービス利用不可）が発生していると判明する。つまり、従来はなかった「モジュールがインストールされているか」というパラメータを検討しなければならないわけだ。自由になった半面、やることも増えたといえる。実はモジュール化によってパフォーマンスに関しても検討事項が増えるのだが、それは後編の「ASP.NETとの統合」で整理する。