• [アーティクル]

IIS

IIS 7.0 での運用を開始する

Fergus Strachan

概要 :

  • Web ファーム環境で IIS 7.0 を展開する
  • セキュリティとパフォーマンスの向上
  • ASP.NET Web アプリケーションを IIS 6.0 から IIS 7.0 に移行する
  • PHP Web アプリケーションを IIS 7.0 に移行する

目次

まずはテストから
テスト環境を構築する
IT 管理者にとって重要な機能強化
IIS のアーキテクチャ
統合モードとクラシック モード
モジュールと機能
Web アプリケーションを移行する
まとめ

マイクロソフトの IIS チームは、インターネット インフォメーション サービス (IIS) 7.0 は IIS 史上最大のリリースだと述べています。このバージョンによって、新しい標準が設定され、基盤が強化されると同時に、

Web 環境を統合するための新機能が導入されます。IIS 7.0 は Windows Server® 2008 と Windows Vista® SP1 に付属しており、既に Microsoft.com の運用に使用されています。また、いくつかの Web ホスティング企業は、既存の Web アプリケーションを新しい Web サーバー プラットフォームに移植する必要がある Web デザイナや開発者向けに、IIS 7.0 を使用したホスティングの提供を既に開始しています。

この記事では、IT プロフェッショナルにとって最も重要な IIS 7.0 の主な機能強化について説明した後、ASP.NET Web アプリケーションと PHP Web アプリケーションの移行について詳しく説明します。ただし、まずは基本的な運用環境に類似したテスト ラボの概要について説明します。

これは重要な作業です。IIS 7.0 を運用サーバーに展開する前に、時間をかけてラボ環境で徹底的にテストを行い、新しい Web サーバーで Web アプリケーションをスムーズに実行できるようにする必要があります。

まずはテストから

このテスト ラボには、Windows Server 2003 と IIS 6.0 を実行し、ASP.NET アプリケーションをホストするシステム、および Ubuntu 7.10 Linux ディストリビューションと Apache HTTP Server 2.2 を実行し、PHP ベースの Web アプリケーションをホストするサーバーが配置されています。ここでの最終的な目標は、Windows Server 2008 をステージング環境と運用環境のシステムに展開した後、複雑なアプリケーションを移行して、IIS 6.0 と Apache のインスタンスを IIS 7.0 に置き換えることです。

このテスト ラボでは、DotNetNuke 4.7 と osCommerce 3.0a4 という 2 つの重要な Web アプリケーションが実行されます。DotNetNuke は ASP.NET 2.0 と Microsoft® SQL Server® に基づいた Web アプリケーション フレームワークです。もう一方の osCommerce は、完全な機能を備えた電子商取引ソリューションの最新のアルファ版で、PHP と MySQL に基づいています。では、これらの高度なアプリケーションを IIS 7.0 に移行しましょう。

この記事の目的はもちろん、ソフトウェアのバージョン、製品、またはプラットフォームを比較することではありませんが、Windows Server 2008 と IIS 7.0 を基盤として使用することには数多くの利点があることをお伝えしておく必要があります。具体的に言うと、管理作業の複雑さが軽減され、実行する Web サーバーの総数を最小限に抑えることができます。

図 1 は、この記事の説明に使用したテスト ラボの概要を示しています。記事の内容を各自のテスト環境で再現する場合は、TechNet Magazine Web サイト (technetmagazine.com) のコード ダウンロード セクションからダウンロードできる付属リソースに、必要なソフトウェア コンポーネントの入手先、および詳細なインストール手順へのリンクが記載されているので、これらを参照してください。

fig01.gif

図 1 IIS 7.0 を展開するためのテスト環境 (画像をクリックすると拡大表示されます)

この記事の執筆を完了したのと同じくらいの時期に、Web アプリケーションを IIS 6.0 と IIS 7.0 に展開、同期、および移行できるコマンド ライン ツール (MSDeploy.exe) がマイクロソフトからリリースされました。このツールを試してみることをお勧めします。詳細については、マイクロソフトの Web 展開チームのブログ (go.microsoft.com/fwlink/?LinkId=118272) を参照してください。

テスト環境を構築する

この記事の執筆時点では、Windows Server 2008 はまだプレリリース版だったので、ドメイン コントローラやデータベース サーバー上の Windows Server 2003 は Windows Server 2008 に置き換えませんでした。Windows Server 2008 が公式にリリースされたら、Active Directory® インフラストラクチャの移行も検討することをお勧めします。また、この記事では、SQL Server® 2005 および MySQL データベースを SQL Server 2008 に移行する作業についても取り上げません。

ステージング サーバーには、SQL Server 2008 を展開しました。その主な理由は、SQL Server 2005 Service Pack 2 をインストールするよりも手間が少ないからです。SQL Server 2008 データベースを使用した場合でも、DotNetNuke は問題なく実行できました。また、Windows Server 2008 への MySQL 5.0 のインストールは簡単で、複雑な作業はありませんでした。

IIS 7.0 は Server Core 上でも使用できますが、ここでは特定のテスト要件のために Server Core インストールを使用しませんでした。まず、このステージング サーバーは、今回の最も重要なテスト システムだったので、完全インストールを実行する必要がありました。また、Server Core 上では Microsoft .NET Framework を使用できないことも、完全インストールを実行した理由の 1 つです。

PHP は Server Core 上で正常に動作しますが、今回の目標は ASP.NET アプリケーションと PHP アプリケーションを統合することです。したがって、Server Core を選択肢の 1 つに数えることはできません。Server Core 上で .NET Framework がサポートされるまでは、完全インストールを実行して ASP.NET アプリケーションをサポートする必要があります。テスト環境の詳細なインストール手順を示すガイドラインについては、付属リソースの 01_install_testlab.htm ファイルを参照してください。

今回は、既存のサーバーをアップグレードするのではなく、Windows Server 2008 のクリーン インストールを実行することにしました。何より、クリーン インストールを実行すると、図 2 のような段階的な移行シナリオを簡単に実装できるようになります。基本的な戦略は、関連する Web アプリケーション コンポーネントのテストがステージング サーバー上で成功し、新しい IIS 7.0 の Web ファームに移行されるまで、既存の Web ファームを実行し続けることです。

fig02.gif

図 2 IIS 7.0 への段階的な移行 (画像をクリックすると拡大表示されます)

環境の複雑さに応じて、既存の Web アプリケーションを一度にすべて移行することも、段階的に移行することもできます。Web アプリケーションまたはサイトごとに、新しい Web ファームでの最終的な受け入れテストが完了したら、ブラウザによって新しい IIS 7.0 Web ファームが参照されるように、関連する DNS レコードを変更して、移行を完了できます。このような方法を取ることによって、ダウンタイムと中断を最小限に抑えることができます。

IT 管理者にとって重要な機能強化

MSDN® Magazine には、Mike Volodarsky によって執筆された「Windows Vista 用 Web サーバーの新機能」(msdn2.microsoft.com/magazine/cc163453.aspx) というすばらしい記事が掲載されています。この記事では、IIS 7.0 の機能強化が簡単に紹介されています。

もう 1 つの優れた資料としては、Microsoft.com の運用チームによるブログ記事「ドッグフードの中に隠れたごちそう」(go.microsoft.com/fwlink/?LinkId=117436) を挙げることができます。この記事には、IIS 7.0 を使い始めた当初のチーム メンバの経験がまとめられています。簡単に述べると、このチームは IIS 7.0 の機能強化を次のように順位付けています。

  1. セットアップの単純化
  2. 高い互換性
  3. メタベースの排除
  4. UNC 共有に配置された applicationHost.config ファイルによる構成の一元化
  5. アプリケーション ディレクトリの web.config ファイルを使用した構成の委任
  6. 管理ツールの強化
  7. 失敗した要求トレース
  8. URLScan を必要としない要求フィルタ
  9. UNC 共有によって単純化されたコンテンツ同期
  10. 動的コンテンツの出力のキャッシュ

セットアップの簡略化は、私の中でも確実に上位に入っています。Microsoft.com の運用チームはブログ記事で、1 つのコマンド ラインを使用して IIS 7.0 のすべての機能 (または、もちろん必要な機能のみ) を展開する方法を示しています。この方法は、早速図 3 のようなコマンド ラインを使用して、テスト ラボの構築手順に組み込んであります。

確かに、このコマンドはかなり長いですね (このコマンドをコピーする場合は、手作業で再入力せずに、TechNet Magazine Web サイトからコピーして貼り付けることをお勧めします)。このコマンドを実行すると、利用できるすべてのモジュールが IIS 7.0 コンピュータにインストールされますが、これには PHP は含まれません。IIS 7.0 では PHP は提供されません。インターネット経由で Debian パッケージをダウンロードしてインストールするという考えは、Windows® パッケージ マネージャ (pkgmgr.exe) には取り入れられていません。このような場合は、Windows 自動インストール キット (AIK) を使用します。

図 3 単一のコマンド ラインを使用して IIS 7.0 の機能を展開する

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-­WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).

AIK を使用すると、IIS 7.0 と PHP 5 を含む Windows Server 2008 用のカスタム インストール DVD を作成できます。MySQL や Web アプリケーションのファイル、および展開に必要なその他のコンポーネントを含めることもできます。すべてのコンポーネントは Windows Server 2008 のセットアップに含めることができるので、すべての Web サーバーに一貫したカスタマイズを適用できます。このため、コマンド ラインも構成ファイルの編集も不要です。

また、完全な無人インストール用のカスタム DVD を作成することもできます。AIK に付属しているドキュメントとツールを使用して AutoUnattend.xml ファイルを作成し、このファイルを DVD のルート フォルダに保存します。一連の手順については、付属リソースに含まれている Custom Image Deployment.htm ファイルを参照してください。

互換性が重要な機能強化であることは、多くの管理者も認めています。テストを開始するとき、私は DotNetNuke と osCommerce の互換性に関する問題がいくつか発生することを予想していましたが、IIS 7.0 への移行はかなり簡単でした。どちらの Web アプリケーションにもフォーム認証、検索エンジンに対応した URL などの高度な機能が含まれていたので、この結果には驚きました。

DotNetNuke については、64 ビット プラットフォーム上の UNC 共有にコンテンツを格納する、複雑な Web ファームのシナリオに進むまで、問題は発生しませんでした。ただし、発生したのは非常に小さな問題です。結局は、互換性がこのように強化されたことによって、Web アプリケーションを IIS 7.0 上で実行するときにかかる時間が短縮されました。

Web アプリケーションで互換性の問題が発生した場合、新しく組み込まれた、診断とトレースのサポートをすぐに気に入ると思います。詳細な診断情報は非常に役立ち、提示される解決策も便利なだけでなく実際に効果があります。

図 4 は、DotNetNuke 4.7 を統合モードの IIS 7.0 で実行したときに表示される診断情報です。この例では、選択肢が 3 つ提供されています ([Things you can try] (対処方法) セクションに注目してください)。DotNetNuke の開発者にとっては、おそらく統合モードをサポートするようにアプリケーションを変更するという選択肢が最も適しています。エラーを無視すると、おそらく良い結果はもたらされません。私のお勧めは、Web アプリケーションを Classic .NET AppPool に切り替えてクラシック モードを有効にする、3 つ目の選択肢です。その理由は、変更を加えることなく DotNetNuke 4.7 を IIS 7.0 で実行する必要があるためです。

fig04.gif

図 4 統合モードで実行されている DotNetNuke の診断情報 (画像をクリックすると拡大表示されます)

IIS のアーキテクチャ

統合モードとクラシック モードとは何か、また、なぜ ASP.NET アプリケーション (DotNetNuke) はこれらのモードの影響を受け、PHP アプリケーション (osCommerce) は影響を受けないのか、疑問に思う方もいらっしゃるでしょう。この点をよく理解するには、まず IIS 7.0 のアーキテクチャを学習する必要があります。以前のバージョンでは、主に ISAPI 拡張 (aspnet_isapi.dll) を使用して、中核となる Web サーバーに ASP.NET ランタイムを統合していました。一方、IIS 7.0 を使用すると、ManagedEngine というグローバル レベルの HTTP モジュールを使用して、中核となる Web サーバーに直接、ASP.NET モジュールを追加できるようになります。

ネイティブ モジュールでは、IIS Web Server Core API を使用して、BeginRequest、AuthenticateRequest、AuthorizeRequest、ExecuteRequestHandler など、パイプライン内の特定のイベントが登録されます。ManagedEngine では、ASP.NET モジュールを要求パイプラインに統合するために必要なサポートも提供されます。この新しい IIS 7.0 のアーキテクチャによって、ネイティブ モジュールと ASP.NET モジュールを、要求されたコンテンツの種類に関係なく要求処理のどの段階でも呼び出すことができるようになります。

例として、ASP.NET のユーザー認証について考えてみましょう。IIS 6.0 では、ASP.NET ベースの HTTP モジュールを使用して、OnAuthenticate イベント (FormsAuthentication.OnAuthenticate、WindowsAuthentication.OnAuthenticate など) を登録し、現在の HttpContext でユーザーの ID を設定できます。この処理は ASP.NET ランタイム内では適切に機能しますが、この ASP.NET コードを使用して、PHP ベースの Web アプリケーション経由で公開されたリソースを保護することはできません。

IIS 6.0 では、スクリプトマップの構成に従って、ASP.NET コンテンツの要求が aspnet_isapi.dll に転送されますが、PHP コンテンツの要求は、この ASP.NET の ISAPI 拡張には転送されません。そもそも ASP.NET では PHP コードが処理されませんが、これは PHP ページが要求された場合に ASP.NET 認証コードが実行されないという意味でもあります。したがって、IIS 6.0 を使用する場合は、PHP アプリケーション専用の認証メカニズムを実装する必要があるので、同じ認証ロジックをもう 1 つ用意する必要があります。

IIS 7.0 では、イベント駆動型の処理モデルが使用されます。このモデルでは、要求パイプライン内の個々のモジュールを組み合わせることができます。IIS 7.0 に付属するコンポーネントには、要求パイプラインで AuthenticateRequest イベントが発生したときに OnAuthenticate イベントを生成する、マネージ モジュールの WindowsAuthentication や FormsAuthentication などがあります。IIS 7.0 では、RequestFilteringModule や IpRestrictionModule などのネイティブ モジュールを使用して、BeginRequest イベントの発生時に、致命的な問題がある要求をできる限り早く拒否できます。その後、AuthenticateRequest イベントの発生時にカスタムの ASP.NET 認証コードを実行し、ExecuteRequestHandler イベントの発生時に FastCgiModule で PHP スクリプト エンジン (php-cgi.exe) を実行して、PHP ページを処理できます。

このようにアーキテクチャが統合された結果、Web 開発者は共通のビジネス ロジックを実装するために、同じコードを繰り返し使用する必要がなくなりました。カスタムの ASP.NET 認証コードを使用して、PHP アプリケーションを含むすべての IIS リソースを保護できます。また、ASP.NET モジュールを使用して、URL の書き換え、カスタム トレース、エラーのログ記録など、その他の前処理および後処理のタスクを実行できます。

統合モードとクラシック モード

この新しいアーキテクチャの欠点は、既存の ASP.NET アプリケーションのコードや構成を変更する必要が生じる場合があることです。変更を実装するアプリケーション開発者は、実装した変更によって、要求パイプラインでモジュールの競合が発生しないようにする必要があります。ただし、既存の Web アプリケーションをすぐに移植できない場合は、アプリケーション プールでクラシック モードを有効にし、クラシック モードのワーカー プロセスで Web アプリケーションを実行できます。IIS 7.0 では、クラシック モードのワーカー プロセスに ManagedEngine が読み込まれません。したがって、要求パイプラインで ASP.NET モジュールを解決したり呼び出したりすることはできません。その代わり、IIS 7.0 では IsapiModule (aspnet_isapi.dll) に基づいた多くの ISAPI ハンドラが実行され、IIS 6.0 と同じように ASP.NET コンテンツが処理されます。これは、applicationHost.config ファイルの system.webServer の下にある handlers セクションを分析するとわかります。既定では、applicationHost.config ファイルは %WinDir%\System32\InetSrv\Config フォルダにあります。

たとえば、文字列 aspx を検索すると、あるエントリでは PageHandlerFactory-Integrated (preCondition="integratedMode" という設定に従って、統合モードのアプリケーション プールで実行されるワーカー プロセスに読み込まれます) が指定され、他のエントリでは PageHandlerFactory-ISAPI-2.0 および PageHandlerFactory-ISAPI-2.0-64 (preCondition="classicMode" という設定に従って、クラシック モードのアプリケーション プールで実行されるワーカー プロセスに読み込まれます) が指定されていることがわかります。

パイプラインのモードはアプリケーション プール レベルで設定されるので、IIS 7.0 では、ある Web アプリケーションを統合モードで実行するのと同時に、他の Web アプリケーションをクラシック モードで実行できます。ワーカー プロセスだけは異なるアプリケーション プールで実行する必要がありますが、これらのプロセスは同じサーバー上でホストできます。

統合モードとクラシック モードの影響を受けるのは、IIS 7.0 で ASP.NET がどのように要求パイプラインに統合されるかという点のみであることに注意してください。これらのパイプラインのモードは、PHP アプリケーションには直接影響を与えません。FastCgiModule とその他のすべてのネイティブ モジュールは、パイプラインのモードの前提条件にかかわらず、統合モードとクラシック モードの両方で必ず読み込まれます。FastCGI は、PHP スクリプト エンジンを IIS 7.0 で実行するのに適したインターフェイスです。FastCGI を使用せずに、CGI で PHP スクリプト エンジン用のハンドラ マッピングを作成したり、IsapiModule を PHP-ISAPI (php4isapi.dll) と組み合わせて使用したりすることもできます。

ただし、FastCGI を使用するとパフォーマンスと安定性が大幅に向上するので、私の考えでは、IIS 6.0 形式の構成方法はもう時代遅れです。CGI を使用した場合、HTTP 要求が発生するたびに IIS で新しい CGI プロセスを初期化する必要があるので、処理に時間がかかります。一方、FastCGI では、複数の要求に対して CGI プロセスが再利用されます。ISAPI ではスレッド セーフな PHP ビルドが要求されるので、スレッド セーフではない PHP ビルドを実行する場合よりもオーバーヘッドが増加します。

さらに重要なのは、すべての PHP 拡張がスレッド セーフなバージョンで入手できるわけではないことと、スレッド セーフではない拡張を ISAPI と共に実行するのは、サーバーの安定性が低下する可能性があるので好ましくないことです。これに対して、FastCGI は CGI のような単一の同時実行環境です。スレッド セーフではない PHP の実行に FastCGI を使用した場合でも、安定した高速な処理が実現されるので、IIS 7.0 で PHP 5 を実行する場合に FastCGI が適していることは明らかです。IIS 7.0 に移行する準備がまだ整っていない場合は、IIS 6.0 でも FastCGI を使用できます。

モジュールと機能

IIS 7.0 の特徴は、高度にモジュール化されたアーキテクチャ (IIS 開発者の表現では、コンポーネント化された機能セット) です。これは、IIS 7.0 によって使用されるメモリのサイズと、IIS 7.0 が攻撃を受ける危険性を最小限に抑える必要がある Web 管理者にとっては朗報です。さまざまなモジュールを有効にしたり、さらには標準的なモジュールをカスタム モジュールで置き換えたりすることによって、Web サーバー上の IIS 7.0 の機能を完全に制御できます。

ASP.NET を統合モードまたはクラシック モードで実行するだけでなく、PHP アプリケーションも同じサーバー上で実行するには、要求の処理、サーバーの構成、ASP.NET、ISAPI、および CGI (FastCGI モジュールを含む) がサポートされるように、少なくとも Web サーバーの役割と主要なモジュールをインストールする必要があります。この作業は、次のコマンド ラインを使用して行うことができます。

start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

私は基本的に、すばやく Web アプリケーションを起動して実行できるように、提供されているすべてのオプションを IIS 7.0 と共にステージング サーバーにインストールして、すべてのコンポーネントと管理ツールを使用可能な状態にすることを好みます。戦略としては、アプリケーションが正常に動作することを確認できたら、役割サービスをアンインストールしたり、モジュールを無効にしたりして、構成を絞り込みます。アプリケーションが正常に動作しなくなった場合は、削除した役割サービスやモジュールを再度追加します。

パッケージ マネージャ (pkgmgr.exe) や IIS 7.0 のコマンド ライン ツール (appcmd.exe) を使用したり、applicationHost.config ファイルの globalModules セクションを直接編集したりすることもできますが、個人的にはグラフィカル ツールが非常に便利だと思います。RequestFilteringModule、StaticCompressionModule などの一部のモジュールは、厳密に言えば Web アプリケーションの実行には必要ありませんが、これらは非常に役立ちます。アプリケーション プールに必要なモジュールを削除した後、Web アプリケーションにアクセスすると、HTTP エラーが表示されます (図 5 参照)。

fig05.gif

図 5 IsapiModule が存在しないことによってクラシック モードで実行できない ASP.NET アプリケーション (画像をクリックすると拡大表示されます)

注 : この場合のベスト プラクティスは、すべての IIS 7.0 サーバーに同じ組み合わせのモジュールがインストールされ、それらが有効になっているかどうかを確認することです。インストールされているコンポーネントを確認するには、HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ のレジストリ キーを確認します。NetFxEnvironment や CGI などのレジストリ キーで REG_DWORD の値が 0000 0001 になっている場合は、対応するコンポーネントがインストールされています。

Web アプリケーションを移行する

理論の説明は終わりました。では、Web アプリケーションを IIS 7.0 に移行する作業に取りかかりましょう。既に説明したとおり、このテスト環境のステージング サーバーでは、IIS 7.0 を、すべての利用可能なコンポーネント、および FastCGI に登録されたスレッド セーフではない PHP 5 と共に実行します。作業を始める前に、次の基本事項を確認する必要があります。

  • Web アプリケーションには SQL Server や MySQL などのデータベース管理システムが必要であるかどうか。
  • ODBC 接続、COM オブジェクト、SSL 証明書などの追加のコンポーネントをインストールしたり構成したりする必要があるかどうか。
  • Web アプリケーションでは、ファイル共有などのリソースを操作するために、特別なサービス アカウントや、昇格したローカルまたはリモートのアクセス許可が必要であるかどうか。
  • URL の書き換え用 Apache モジュール (mod_rewrite) など、IIS 7.0 では利用できない、プラットフォーム固有の機能に依存しているかどうか。

上記の基本事項を確認することは、Web アプリケーションを IIS 7.0 で高速に実行するのに役立ちます。たとえば、mod_rewrite を使用する Apache 2.2 から PHP アプリケーションを移行しようとしている場合 (検索エンジンに対応したり、インライン フレームを使用してリンクされた画像によって帯域幅が占有されるのを防いだりするため)、互換性のあるカスタムの URL 書き換えソリューションを IIS 7.0 に実装しない限り、問題が発生します。さいわい、osCommerce は IIS 7.0 上で mod_rewrite 機能を必要としませんが、一部の検索エンジン最適化パッケージでは必要になる場合があります。

これで、ステージング サーバーに必要な追加のコンポーネントを確認してインストールできたので、Web アプリケーションを起動して実行する準備が整いました。ここで今度は、次の事項を確認する必要があります。

  • Web アプリケーションのサポートに使用できる最も単純な構成は、どのような構成であるか。
  • 運用環境では、現在どのような構成が使用されているか。
  • 新しいプラットフォームで Web アプリケーションの構成を最適化できるかどうか。
  • Web アプリケーションを目的の構成で動作させるには、どの役割サービスとモジュールが最低限必要であるか。

Web アプリケーションを最も単純な構成で実行すると、アプリケーションが動作するかどうかを簡単に確認できます。問題なく動作するようであれば、既存の運用環境と同様の構成を適用し、運用環境のデータをテスト環境のデータベースにインポートします。もちろん、一部の問題は、詳細な構成を適用するまで表面化しない場合があります。

また、運用環境の構成をテスト ラボで再現すると、改善できる部分に気が付くこともあります。applicationHost.config ファイルを UNC 共有に配置すると、複数の Web サーバーの構成を一元化できるので、非常に便利です。冗長性とコンテンツの同期によってフォールト トレランスを強化するには、分散ファイル システム (DFS) レプリケーションの実装を検討します。この機能は、Windows Server 2003 R2 と Windows Server 2008 で使用できる、状態ベースのマルチマスタ レプリケーション エンジンです。さらに、Web アプリケーションのコンテンツ ファイルを UNC 共有に配置すると、Web フロントエンドのストレージ要件を最小限に抑えることができます。

この他には、セキュリティや動的キャッシュに関連する最適化が考えられます。セキュリティとパフォーマンスの最適化は、この記事の説明範囲を超えるので、このテスト ラボでは行っていません。また、インストールするサーバーの数を抑えるため、DFS も構成していません。付属リソースに含まれている一連の手順では、applicationHost.config ファイルと Web コンテンツを UNC 共有でホストする方法の簡単な例が提供されます。図 6 は、DFS を使用する UNC ベースの Web ファームを実装する方法を示しています。

fig06.gif

図 6 applicationHost.config ファイルと Web コンテンツが UNC 共有に配置された Web ファームの展開 (画像をクリックすると拡大表示されます)

まとめ

IIS 7.0 は優れた Web サーバー プラットフォームです。IIS 7.0 は、中核となるアーキテクチャの設計が変更されているにもかかわらず、IIS 6.0 との下位互換性がほぼ完全に確保されていることを特徴としています。ほとんどの ASP.NET Web アプリケーションは、変更を加えずに実行できますが、アーキテクチャが大幅に変更されたことを考えると、互換性の問題が発生しないとは言い切れません。

ASP.NET Web アプリケーションと PHP Web アプリケーションのどちらを IIS 7.0 に移行する場合でも、段階的な方法を使用し、計画、準備、テスト、およびコードと構成に加える変更の文書化に力を入れて取り組むことをお勧めします。

IIS 7.0 には、手間をかける価値があります。セキュリティ、パフォーマンス、構成可能性、柔軟性など、さまざまな機能強化が提供されており、これらをすべて説明するには、書籍 1 冊分のスペースが必要になるでしょう。UNC 共有に基づいた構成の一元化とコンテンツの共有、アプリケーション ディレクトリ内の web.config ファイルを使用した構成の委任、管理ツールの強化、詳細な診断情報と失敗した要求トレース、および動的な出力のキャッシュは、必ず Web 管理者の心をつかむはずです。

要求パイプラインでネイティブ モジュールとマネージ モジュールを組み合わせて使用できることは、ASP.NET 開発者にとって役立ちます。また、IIS 7.0 の FastCGI によって実現されるパフォーマンスと安定性の向上は、PHP アプリケーションの開発者にとってすばらしいことです。

もう 1 つ、IIS 7.0 を使用して IT プロフェッショナルが成功を収めるうえで役立つ重要なリソースを紹介しておきます。それは、マイクロソフトの IIS コミュニティ ポータル (www.iis.net) です。このサイトには、必要な情報がすべて揃っています。たとえば、新しいアーキテクチャについての詳しい記事、IIS 7.0 モジュールの作成方法がわかる、C++ 開発者と ASP.NET 開発者向けのソース コード、PHP アプリケーションを起動して実行するための順を追った説明が提供されます。ぜひこのサイトにアクセスしてみてください。IIS に関する疑問の答えを探している場合は、まずこのサイトを参照すると便利です。

Fergus Strachan は、Maestra Ltd London の創立者であり、取締役を務めています。このコンサルティング企業は、IT インフラストラクチャの設計とプロジェクト管理のサポートを専門とし、英国の国際銀行と教育機関にサービスを提供しています。彼はマイクロソフトのサーバー テクノロジについての記事を執筆しており、『Integrating ISA Server 2006 with Microsoft Exchange 2007』の著者です。また、『Microsoft Exchange Server 2003 Resource Kit』の共著者でもあります。

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