どのようなソフトウェアでも、動作する環境を指定する「環境情報」をほぼ確実に持っている。IISも同様で、これまでは「メタベース」と呼ばれる環境情報を持っていた。実体もmetabase.binからmetabase.xmlに変化したが、IIS 6.0でもやはりメタベースである。
このメタベースは構造上、やむなくそのサーバ固有の情報を保持しているため、ほかのコンピュータへ同一のメタベースを配布して同一構成のサーバを複製することができない。IIS 7.0ではこの課題に対処するために完全にスクラッチで作り替えてしまった。まずはどのように作り替えたかを見ていこう。
IISのメタベースは、プログラム類と一緒に%SystemRoot%\System32\Inetsrvフォルダに配置されている。IIS 7.0ではここにConfigフォルダが新設され、そこに新しい環境情報が配置される。applicationHost.configというファイルがその新しい形式だ。実はこの実装には.NET FrameworkとASP.NETというお手本がある。%SystemRoot%フォルダにはMicrosoft.NETというフォルダがあり、そこに.NET Frameworkがバージョンごとに格納されているが、ASP.NETではmachine.configとweb.configというファイルで環境情報を保持している。この.config形式をIIS 7.0も採用したわけである。
applicationHost.configファイルは環境情報に応じてセクション・グループとその子どものセクションで区切られており、<system.applicationHost>と<system.webServer>がIISの設定情報を保持しているセクション・グループ名になる。環境がお手元にある方はぜひ一度中身に目を通してほしい。付け加えるとweb.configが保持するASP.NETで利用されるセクション・グループは<system.web>である。実はこの構造は継承モデルで、下記の図のように機能する。
Webアプリケーションを構成する際、ASP.NETの場合にはweb.configをアプリケーション・フォルダ内に作成してその中にサーバのデフォルトとは異なる設定を記すわけだが、IIS 7.0の場合も同じように継承モデルが利用できる。例えば、サーバにインストールされているモジュールがa、b、c、d、eとあった場合に、アプリケーション1ではa、c、eを、アプリケーション2ではb、d、eを利用するというような設定も可能ということだ。これは明らかにIIS 7.0を特定の環境下で利用したい場合の例である。また、同じweb.config内に両方の設定を保持できるので、同一構成のサーバを展開する際にアプリケーションのフォルダをコピーして展開していく、という手段がついに実現できるわけだ。
これだけではあまり驚きはないかもしれない。なぜならアプリケーションのフォルダをUNCシェア(UNCパスの共有フォルダ)に置くという方法を採ると、ASP.NETの世界でもアプリケーション・フォルダを展開せずに各サーバで同じフォルダを参照すれば複数サーバの設定を一気に変更できるからだ。しかし、IIS 7.0はこれから紹介する共有構成(シェアード・コンフィグレーション)で一歩先に進む。
共有構成とは、ここまで話題になっているIISの環境情報をUNCシェアに置く仕組みだ。従来、サーバの動作環境を規定しているメタベースをUNCシェアのような共有フォルダには配置できなかった。その理由の1つは前述のように、メタベースがサーバの固有情報を含んでいるためだ。もう1つの理由としては、アプリケーション・コンテンツよりも頻繁にアクセスされるであろう環境情報を、ローカル・ストレージより遅いネットワーク上の共有フォルダに配置するとパフォーマンスを低下させる可能性もあったからだ。こうした運用方法は「想定外」だったわけである。しかし、Windows Server 2008でのSMBアクセス(ファイル共有へのアクセス)の高速化によってこの構成は現実味を帯びてきた。SMBの高速化の詳細については、以下の文書を参照していただきたい。
IIS 7.0の共有構成の実例としては、いまのところマイクロソフトのWebサイト(www.microsoft.com)が一番いい情報だろう。実はwww.microsoft.comのフロントエンドはすでに80台のIIS 7.0(ベータ3からスタート、順次アップグレードしていく)で稼働しているのである(*3)。もちろんあれだけ膨大なコンテンツを提供しているのでバックエンドのサーバもかなりの台数に上る。下図はそれらの構成を簡易化したものだ。
*3 実際にWebサーバの台数などを確認するには、Webサーバ製品のシェアを知りたいときによく利用されるNetcraft社のサイト(http://www.netcraft.com/)へ行き、検索でwww.microsoft.comと入力して検索してみるとよいだろう。
このように共有構成の環境情報およびコンテンツをリモート・パス(UNCシェア)に置くことが実践されている。それだけではなく、分散ファイルシステムの複製エンジン(DFS-R)がうまく利用されていることが分かるだろう(DFS-Rの詳細については「Windows Server 2003 R2レビュー 第3回 強化された分散ファイル・システムDFS」を参照していただきたい)。Windows Server 2003 R2で性能を高められたこのエンジンは、もちろんWindows Server 2008にも継承・改良されている。コンテンツを管理する仕組みを自前で作ってしまう前に、こうしたベースになる仕組みも検討してみるといいだろう。
次回の後編では、IIS 7.0で強化された管理機能や新しい診断システム、ASP.NETとの統合などについて解説する。
Copyright© Digital Advantage Corp. All Rights Reserved.