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

Windows Server 2008に標準搭載のIIS 7.0は、モジュール構造の採用や環境情報の一新などさまざまな改善を図っている。

» 2007年11月14日 00時00分 公開
[奥主洋(エバンジェリスト)マイクロソフト株式会社 ]
  Windows Server 2008の基礎知識 ―― 新サーバOSで何が変わるのか? ―― 
Windows Server Insider

 

「  Windows Server 2008の基礎知識 ―― 新サーバOSで何が変わるのか? ―― 」のインデックス

連載目次

「Windows Server 2008の基礎知識」は、2008年に出荷が予定されている、Windows Server 2003の後継OSである、Windows Server 2008の注目機能について解説するコーナーです。


 本記事では、第1回第3回までWindows Server 2008全体を対象に、その概要を解説した。今回からWindows Server 2008に搭載される個別の機能に焦点を当てて、より深く掘り下げて解説していく。その最初となる本稿では、Internet Information Services(IIS)の新版であるIIS 7.0について解説する。この前編では概要と内部構成の変更点などを、後編では管理機能や診断システムなどについて解説する。

 IIS 7.0はすでに出荷中のWindows Vistaにも組み込まれているが、Windows Server 2003+IIS 6.0というアプリケーション・サーバの本来の後継はWindows Server 2008+IIS 7.0であり、非常に重要なコンポーネントであることはいうまでもない。本稿では、主にIISによるサイトの運用や開発に携わっているエンジニアやユーザーを対象に、IIS 7.0の構成やバリエーションなどの基礎から、機能や内部構造の変更点などの詳細についても解説する。

 なお、特記しない限り本稿ではWindows Server 2008 RC0の仕様に従っている。RTM版(製品版)で仕様が変更される可能性もあるので留意いただきたい。またIIS全体を指す場合は「IIS」、特定のバージョンを指す場合は「IIS .6.0」「IIS 7.0」などと記す。

IISのこれまで

 ご承知のように、IISはWindows 2000のサーバとクライアントに搭載されたVer. 5.0でOSの広がりとともに多くの利用者を獲得した。しかし、2001年〜2002年にかけてCodeRedやNimdaというワームによる新たな脅威にさらされた結果、IISは危険なWebサーバであり、イントラネットに限定して使うべきだ、という印象を持った技術者が多い。その後、マイクロソフトはこの重大な経験を踏まえ、「Trustworthy Computing」という旗印の下、革新的な機能の開発を抑えてでも「セキュリティが第一義」という道を歩むことになった。その成果はIISの製品出荷後に判明した脆弱性情報の件数という形で表れている。下表のとおり、2007年11月時点でIIS 6.0(Windows Server 2003)に見つかった脆弱性は2件にすぎない。

IISのバージョン OS 公表された脆弱性情報の件数
IIS 5.0 Windows 2000 31
IIS 5.1 Windows XP 7
IIS 6.0 Windows Server 2003 2
公表されたIISの脆弱性情報の件数(2007年11月時点)
これらは、いずれもセキュリティ・パッチの提供によって解消されている。IIS 6.0の脆弱性のうち緊急レベルは0件で重要レベルは2件(ASP関連とWebDAV関連)と、IIS 5.xに比べて大幅に少ないことが分かる。最新情報はマイクロソフトTechNetのセキュリティ情報検索を参照していただきたい。

 その一方でIIS 6.0においてはセキュリティが第一義ながらも、HTTPの初動処理をカーネル・モードに移行し、アプリケーション・プールという新しいプロセス分離構造を取り入れた(詳細は関連記事を参照)。これにより、処理性能および安定性の向上を実現している。しかし、構造的に変更しなければ無理だったために実現できなかった機能も存在する。その中でも代表的な3つのポイントを説明しよう。

■最適化の難しい内部構造
 それまでのIISと同様、IIS 6.0は、依然として1つの大きなプログラムとして動作する内部構造を採用していた。レジストリやメタベース(サーバ構成情報)で切り替えることで一部の機能についてはオン/オフの制御が可能なものの、構造的にはやはりサーバ内部処理は大きな1つのプログラムがワーカー・プロセス上で動作する。そのため、もし脆弱性が見つかった場合には、その原因となった機能を利用していなくてもプログラム全体を交換せざるを得ない。また、プログラム全体がメモリにロードされるため余計にメモリが消費されるなど、リソース面でも最適な構造とはいえなかった。例えば、基本認証とCGIとログ機能だけを利用したい場合、メモリ上にはこの3種類の機能だけがロードされるのが理想だが、IIS 6.0ではそうした最適な構成を採ることができなかった。

■柔軟な取り扱いが難しい構成情報ファイル
 IIS 6.0では、それまでバイナリ形式だったサーバ構成情報ファイルがXML形式の新しいフォーマットに変更された。しかしながら、この新しいサーバ構成情報ファイルmetabase.xmlは分かりにくいXMLデータであり、かつそのコンピュータ固有の情報が含まれるという点は改善されなかった。そのため、例えばIISによるサーバを100台用意する際、まず1台だけ構築して残りの99台はそれをコピーするだけでは済まず、サーバごとに固有の設定が必要な部分では、スクリプトを活用するなどの工夫が必要だった。このように構成情報ファイルの制限が、IIS 6.0の柔軟な展開を難しくしている。

■ISAPIに依存した拡張性
  一般的にIIS 6.0では、リクエストを受け付けてからレスポンスを返すまでの間に何か独自の処理を追加したい場合、ISAPI(Internet Server Application Programming Interface)という旧来のAPIを利用した複雑な開発手法を必要とする。ASP.NETが利用できる場合、.NET言語によって拡張モジュールを開発・追加することは不可能ではない。しかし、IIS自身が持っている認証処理を変更したり、あるいは圧縮機能を別のものと置き換えたりすることは、ASP.NETでは対処できない。これらはASP.NETの処理としてではなく、IISの機能として実装されているものであり、ASP.NETの処理フローから外れたところで動作するからである。

 このようにIIS 6.0は確かに以前のIISに比べればセキュリティ面での不安は大幅に減少し、機能や性能の向上も図られたが、さらに要求したい点がいくつかある。IIS 7.0はこのような点を明確に新機能として取り込むというコンセプトで開発されたわけである。

IIS 7.0におけるWindows VistaとWindows Server 2008の関係

 さて、IIS 7.0はすでに製品版が出荷されているWindows Vistaにも搭載されている。そこでまず、IIS 7.0におけるWindows VistaとWindows Server 2008の関係や制限などに触れておく。

 マイクロソフトはWindows 2000から、サーバOSだけではなくクライアントOSにもWebサーバ機能を標準で搭載するようになった。この位置付けは運用環境としての利用ではなく、開発環境として用意されているもので、そこからアプリケーションを運用環境であるサーバに持っていくという発想だ。Windows Vistaもこの発想を踏襲している。一方でWindows Server 2003同様、Windows Server 2008は本格的な運用環境、しかも多くの台数でファームを組むような大規模Webサイトをホストする規模まで利用可能である。前述のとおり、Windows VistaもWindows Server 2008もIISのバージョンはともに7.0であり、Windows Vistaでアプリケーションの開発とテストを進め、それをWindows Server 2008の運用環境に展開することが考慮されている。マイナーのバージョンに関してはまだ不確定な要素も多いので言及できないが、少なくともIISの機能についてはWindows Vista SP1でWindows Server 2008のRTMと足並みがそろう予定である。

 ただし、Windows Vistaに搭載されるIIS 7.0は、エディションごとに以下のような機能の違いがある。

OSとエディション 機能制限 セットアップ方法 最大同時接続数
Windows Vista Home Basic IISなし
Windows Vista Home Premium FTPなし、一部の認証なし、ログなし、リモート管理なし [プログラムと機能]、 Pkgmgrコマンド 3
Windows Vista Business/Enterprise/Ultimate リモート管理なし [プログラムと機能]、 Pkgmgrコマンド 10
Windows VistaにおけるIIS 7.0の機能制限
このように同じWindows Vistaでも、エディションによって制限の内容は異なる。一方、IIS 7.0をセットアップする方法としてはHome Basicを除いて、GUIベースの[プログラムと機能]とコマンドライン・コマンドのPkgmgrの両方が利用できる。最大同時接続数については、これを超えるリクエストはすぐエラーになるのではなく、待ち行列(キュー)によって順次処理されるため、表面上は処理が遅くなったように見える。

 ご覧のように、Home BasicではIIS 7.0は搭載されておらず、Home PremiumもBusiness/Enterprise/Ultimateに比べて全機能を持っているわけではない。従って、開発環境を準備する際にはHome Premiumの機能でも十分なのか、それともBusiness/Enterprise/Ultimateの機能が必要なのか注意すべきだ。また、最大同時接続数については、3あるいは10の上限を超えた際の挙動が、Windows XPのIISとは異なる点に注意が必要だ。Windows XPでは上限を超えたリクエストは処理されず、ブラウザにはエラーが返されるのに対し、Windows Vistaではそのリクエストが待ち行列(キュー)に蓄えられる(キューがいっぱいだとやはりエラーが返される)。キューに入ったリクエストは同時接続数の範囲内で順次処理されていくので、表面上は処理が遅くなったように見える。

 さて、Windows Server 2008搭載のIIS 7.0と各エディションなどとの関係についても、いくつか知っておくとよい点がある。どんな提供形態があるのかこれも表で整理しておく。

OSとエディション インストール形態 機能制限 セットアップ方法 最大同時接続数
Windows Server 2008 Standard/Enterprise/Datacenter 完全インストール 全機能が利用可能 サーバ・マネージャ、 ServerManagerCmdコマンド、 Pkgmgrコマンド 制限なし
Server Core GUI、.NETなし Pkgmgrコマンド 制限なし
Windows Web Server 2008 完全インストール 全機能が利用可能 サーバ・マネージャ、 ServerManagerCmdコマンド、 Pkgmgrコマンド 制限なし
Server Core GUI、.NETなし Pkgmgrコマンド 制限なし
Windows Server 2008の各エディション/インストール形態とIIS 7.0の機能との関係
このようにWindows Server 2008のIIS 7.0では、エディションよりインストール形態によって機能が大きく変わる。セットアップ方法のうち、「サーバ・マネージャ」はGUIベースのツールで「ServerManagerCmd」「Pkgmgr」はコマンドライン・コマンドである。

 ここで注目度が高いのはやはりServer Coreの登場だ(Server Coreの詳細については関連記事を参照していただきたい)。スタート・メニューがなく、ログオンするといきなりコマンド・プロンプトが開くこのインストール形態にもIIS 7.0が搭載されることが決まり、2007年6月のCommunity Technology Preview版(*1)から搭載されている。ただ、Server Coreのコンセプトは「攻撃を受けにくい、リソースをより使わない最小のWindowsサーバ」というもので、その意味合いから.NET Frameworkは搭載されない。従って現時点では、ASP.NETの運用環境としてServer Coreを使うことはできず、Windows PowerShellもServer Core上では動作しない。またServer Coreは、EnterpriseやStandardのようなエディションではなく、インストール時に完全インストールとServer Coreのどちらかを選択する、インストール形態の一種だという点にも注意すること。

*1 ベータほど大掛かりではないが、いくつか修正を加えつつ限定的に公開されるテスト・ビルド。


 もう1つ上表で確認しておきたいのはWindows Web Server 2008というエディションだ。これはWindows Server 2003(R2), Web Editionの後継に位置付けられる。ただし、Windows Server 2003(R2), Web Editionの入手方法がサーバ・マシンのプレインストールなどに限られている(*2)のに対し、Windows Web Server 2008はこうした制限なしで、ほかのWindows Server 2008のエディションと同じように取り扱われる予定だ。このエディションはインターネット環境での利用を想定しているため、ほかのエディションよりCALの面で有利な条件となっている。しかもWeb機能としての制限はない。

*2 詳細はWindows Server 2003, Web Edition の概要を参照していただきたい。


 Windows Web Server 2008とほかのエディションとの大きな違いは、利用可能な「ロール(役割)」の数である。この「役割」という考え方はWindows Server 2008から本格的に採用されており、「このサーバはドメイン・コントローラ」であるとか「このサーバはファイル・サーバ」というような考え方でインストールが行われる。RC0時点でWindows Server 2008ファミリにおける役割の数は全部で17個であるのに対して、Windows Web Server 2008ではWebサーバとWindows SharePoint Servicesの2個だけに限られる(現段階でもWindows Mediaサービスはダウンロードして追加できるので、RTMでは3個に増える予定)。さらにServer Coreを選択すると、.NET Framework(ASP.NET)を搭載していない分、役割数は完全インストールより減る点も覚えておきたい。例えばWindows Web Server 2008でServer Coreを選択すると、ASP.NETベースであるWindows SharePoint Servicesが利用できない。

 ということで、インターネットで利用するサーバの選択において、ASP.NETを利用するのであればWindows Web Server 2008の完全インストール、そうではなく静的なHTMLやASP、PHP(そのほかCGI動作環境)を動作させるのであればServer Coreも選択肢に入る。RC0時点ではWindows Web Server 2008でもServer Coreを選択できることも忘れないようにしたい。

 もっと詳しくWindows VistaとWindows Server 2008の対比を知りたい方はIIS製品開発部門の責任者Bill Staplesのブログが参考になるだろう。英語ではあるが、IIS開発部門の見解として分かりやすい。

【更新履歴】

【2008/04/26】IIS 7.0におけるWindows VistaとWindows Server 2008の関係において、IIS開発チームによるWindows Vistaの各エディションとIISの機能の関係の解説記事を紹介していましたが、当該記事が消失したので該当箇所を削除しました。



       1|2|3 次のページへ

Copyright© Digital Advantage Corp. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。