IIS 7.0: Top 10 Performance Improvements in IIS 7.0

[アーティクル]
08/25/2016

IIS 7.0

IIS 7.0 のパフォーマンス向上機能トップ 10

Mike Volodarsky

概要 :

アプリケーションのフットプリントを最小化する
帯域幅コストを削減する
強化されたキャッシュ機能を使用する

より軽量な Web サーバー
軽量 OS を基盤に構築する
特化型アプリケーショントポロジ
強化されたアプリケーションサポート
アプリケーション集積度を高める
圧縮により帯域幅を削減する
メディアビットレートを調整する
出力キャッシュ
ISAPI コードを IIS 7.0 モジュールに変換する
サーバーの拡張性
まとめ

IIS 7.0 の採用を計画している企業の方とお会いしたときに必ず聞かれるのは、IIS 7.0 に移行することでサーバーやアプリケーションのパフォーマンスは向上するかどうかということです。概ね、

その質問に対する回答は「向上する」になりますが、IIS 7.0 にアプリケーションを初めて移行した時点で、パフォーマンスの向上が見られない場合があることも覚悟してください。

これを理解するには、IIS 7.0 の性質を理解する必要があります。IIS 6.0 は、セキュリティ、信頼性、およびパフォーマンスの強化という 3 つの目標を掲げたエンジニアリングリリースでした。これに対して、IIS 7.0 はプラットフォームリリースです。IIS 7.0 の目的は、IIS 6.0 の高品質な基本の Web サーバーコアを、現在の主要な開発シナリオと管理シナリオをサポートできる、モジュール型の拡張可能なプラットフォームに変換することでした。

たとえば、主要な変更の 1 つとして、厳密に最適化された Web サーバーコードのパスが破棄され、Web サーバーから特別な処理を受けないスタンドアロンのモジュールに作り変えられていることを考えると、多数のアーキテクチャ上の変更や新機能は、実際には Web サーバーのパフォーマンスに悪影響を与える可能性があります。ただし、IIS 製品チームのパフォーマンスに対する多大なる取り組みのおかげで、IIS 7.0 は IIS 6.0 と同レベルの (一部の領域では IIS 6.0 を上回る) パフォーマンスを実現しています。私は Web サーバーコアと統合パイプライン開発に携わった経験から、これを実現するにはさまざまな設計上の工夫と製品実装において、たいへんな努力が必要であったことを断言できます。

いずれにせよ、IIS 7.0 は、これまでのどの IIS リリースよりも、サーバーファームの大幅なパフォーマンス向上とパフォーマンス関連コストの削減を実現できる高い可能性を持っています。

IIS 7.0 に移行しただけで、このようなメリットが実現されるとは限りませんが、中には、移行するだけで、このようなメリットを実際に実現できる環境もあります。たとえば、Microsoft.com では CPU 使用率が 10% 改善されました (詳細な解析結果については、Microsoft.com チームのブログ go.microsoft.com/fwlink/?LinkId=122497 を参照してください)。また、SSL (Secure Sockets Layer) や Windows® 認証 (いずれも現在はカーネル内で実行) など、特定の領域でパフォーマンスが大幅に向上したり、マルチコアコンピュータとマルチプロセッサコンピュータ上でハードウェア追加による拡張が容易になるといったメリットを実感できる場合もあります。

しかし、IIS 7.0 の真の威力は、既存機能のパフォーマンス強化により実現されるのではなく、積極的に使用する必要がある IIS 7.0 の新機能によって実現されます。このような機能は、多くの場合、プラットフォームの持つ柔軟性と拡張性の高さと、新しいパフォーマンス機能に根ざしています。この記事では、IIS 7.0 に移行することで可能になるパフォーマンスの向上を実現する最も重要な 10 個の機能について説明します。

より軽量な Web サーバー

軽量な IIS 7.0 サーバーを展開できるのは、サーバーのモジュール型アーキテクチャのおかげです。実際、IIS 7.0 の Web サーバー機能はすべて、個別に追加または削除できるモジュールコンポーネントとして実装されています。ですから、アプリケーションの運用に必要ないサーバー機能を削除できるため、攻撃対象となる領域を大幅に削減できる、運用フットプリントを縮小できる、パフォーマンスが向上するなど、注目に値するメリットが得られます。

IIS 7.0 の完全な Web サーバー機能には、ネイティブ IIS モジュールや統合パイプラインにサービスを提供する ASP.NET モジュールも含め、44 個のモジュールが含まれています。これらのモジュールにより、認証 (Windows 認証モジュールとダイジェスト認証モジュール)、アプリケーションフレームワークサポート (FastCGI モジュール)、アプリケーションサービス (セッション状態モジュール)、セキュリティ (要求フィルタモジュール)、パフォーマンス (出力キャッシュモジュール) などのサービスが提供されます。しかし、静的コンテンツを提供するだけの最小構成の Web サーバーであれば、たった 2 個のモジュールで機能します。

要求ログモジュールや失敗した要求のトレースモジュールの場合など、不要なモジュールから生じるオーバーヘッドはかなり大きくなることがあります。このようなモジュールが不要な場合、環境からこれらを削除することで、全体のスループットが向上するだけでなく、応答時間も短縮され、サーバー負荷の指標である TTFB (最初のバイト受信までの時間) と TTLB (最後のバイト受信までの時間) が低下します。

図 1 は、完全な機能セット、該当ワークロードの既定の機能セット、および該当ワークロードに最低限必要な機能セットの構成に対して実行した、HTML ファイル (静的ワークロード) と "hello world" ASP.NET ページ (ASP.NET ワークロード) を使用した簡単なスループットテストの結果です。完全構成でもほとんどの二次的機能は無効になっていますが、最小構成ではこれらの機能を完全に削除することで、静的ワークロードと ASP.NET ワークロードの両方で、かなりのスループットの向上が認められました。

図 1 100 台の同時実行クライアントを使用した 3 種類の構成における静的ワークロードと ASP.NET ワークロードのスループット率 (画像をクリックすると拡大表示されます)

また、特に共有ホスティング環境や、大量のワーカープロセスが使用されている場合などでは、メモリフットプリントの改善やサイトの集積度の向上も認められる場合があります。これは、通常、各プロセスに読み込まれる DLL 数が少なくなり、モジュールの初期化と要求の処理時に発生するメモリ割り当てが省かれることで実現されています。図 2 は、前出のスループットテストにおけるメモリ使用率 (IIS ワーカープロセスのプライベートバイト) を示しています。この例では、それほど大きな改善は見られませんが、ASP.NET アプリケーションドメインのオーバーヘッドが、モジュールの削除による使用メモリの削減量よりも比較的高いため、メモリ使用率の向上は予期したとおりの結果だと言えます。

図 2 100 台の同時実行クライアントを使用した 3 種類の構成における静的ワークロードと ASP.NET ワークロードのメモリ使用率 (プライベートバイト) (画像をクリックすると拡大表示されます)

IIS 7.0 では、アプリケーションレベルでどのモジュールを有効にするかについてより細かい制御ができるだけでなく、モジュールの前提条件を設定してワークロードを基にモジュールの使用方法を制御できます。これには詳細な構成が必要ですが、複数サイトがある環境や複数の異なるワークロードをサポートするアプリケーションでは、追加のメリットを得られる可能性があります。

ただし、必要な機能を特定することは厄介な場合があります。というのは、アプリケーションフレームワークのサポートに必要な最小限の機能だけでなく、アプリケーションが間接的に依存している可能性がある追加機能についても考慮する必要があるからです。たとえば、アプリケーションは特定の認証方法やさまざまな IIS 機能で提供される認証セマンティクスに依存している可能性があり、このような場合に該当するモジュールを削除するとアプリケーションのセキュリティに悪影響を及ぼす可能性があります。同様に、アプリケーションが機能やパフォーマンスを実現するのに、いくつかのモジュールに依存している場合、これらのモジュールを削除するとアプリケーションが正しく動作しなくなったり、パフォーマンスが低下する可能性があります。

軽量 OS を基盤に構築する

Windows Server® 2008 でも OS レベルのコンポーネント化が行われており、これを利用して Web サーバーの攻撃対象領域をさらに縮小することができます。Server Core は Windows Server 2008 オペレーティングシステムの最小インストールオプションで、最小限のコア OS サブシステムのセットが含まれています。Server Core は、軽量な IIS 7.0 Web サーバーの環境として理想的なインストールオプションです。

ただし、Server Core を評価するときは、一部の制限によりアプリケーションが影響を受ける可能性があることに注意してください。Server Core では Microsoft® .NET Framework がサポートされていないので、ASP.NET、IIS 対応の .NET 拡張、IIS マネージャを利用できません。また、Microsoft 管理コンソール (MMC) も利用できないため、ローカルの管理作業にはコマンドラインツールを使用する必要があります。パフォーマンスの観点では、既に IIS のコンポーネント化を適切に利用している場合、Server Core と完全な Windows Server 実装で実行されるアプリケーションワークロード間で、メモリフットプリントやスループットに違いが見られない可能性があります。これは、IIS とアプリケーションによって実行される作業が、どちらのプラットフォーム上でも同じためです。ただし、違いが見られるものが 1 つあります。それは、サーバーの全体的なフットプリントで、ディスク領域とメモリ使用率の両方で違いが見られます。

図 3 に、完全な Windows Server 2008 構成と Server Core で静的ワークロードテストを実行した後のフットプリントの違いの例を示します。IIS のリソース使用率はどちらの場合もほぼ同じですが、Server Core では OS 全体のフットプリントが縮小したので、はるかに少ないメモリでワークロードをサポートできました。フットプリントが低くなることで、アプリケーションのワークロードを機能性の低いハードウェアに展開でき、運用環境ではなく、アプリケーションの処理要求にのみ注意を向けることができます。もちろん、これが Server Core が仮想化環境として適切なオプションである理由です。

図 3 完全な Windows Server 2008 実装と Server Core 間の静的ワークロードテスト実行後のメモリフットプリントの違い (画像をクリックすると拡大表示されます)

特化型アプリケーショントポロジ

アプリケーションワークロードを最適化するときに、ワークロードを種類ごとに分離できます。たとえば、アプリケーションを 30 台の同じ Web サーバーから成るファームで実行するのではなく、10 台の Web サーバー、5 台のアプリケーションサーバー、およびキャッシュと圧縮を実行する 3 台のプロキシサーバーで実行することができます。

このような特化が有効である理由はいくつかあります。まず、多くのアプリケーションワークロードのパフォーマンスは、メモリを始めとして、さまざまな共有リソースに大きく依存しており、アプリケーションの複数の構成要素間でリソースの競合が発生する可能性があります。このようなリソースの競合が発生すると、各サーバーが他のリソースで十分に活用されることを妨げるボトルネックが生じかねません。アプリケーションの構成要素を分離することで、分離されなければ競合することになるリソースに各構成要素がいつでもアクセスできる状態になり、同じハードウェアリソースでも利用効率が向上します。

また、特化により、アプリケーションがローカルにより多くのデータをキャッシュできるようになり、パフォーマンスが向上する可能性があります。これには、仮想メモリの変換ルックアサイドバッファ (TLB)、ファイルシステムのキャッシュ、他のオペレーティングシステムキャッシュやアプリケーションキャッシュなどの下位レベルのキャッシュが含まれます。CPU にも、特化によるメリットがあります。アプリケーションの特定の構成要素のみを処理することで、並行して実行される操作の数が減少するので、アプリケーションのコンテキストスイッチの回数が減り、CPU の作業効率を最大限に高められます。

特化により、ワークロードごとの最適化も可能になるので、アプリケーションの各構成要素が効率よく機能するようにできます。このような最適化の多くは、アプリケーション全体が同じサーバーでサポートされている場合、そのアプリケーションの各構成要素の要件が競合するため、実現できません。

これがよく発生する領域の 1 つは IIS と ASP.NET のスレッド構成ですが、この構成は同時実行に大きく影響するだけでなく、多くのアプリケーションのメモリ使用率、待ち時間、およびスループットに間接的に影響します。IIS の静的ファイルワークロードは非常に非同期的で厳しい同時実行要求制限を必要としますが、利用可能なスレッド数はわずかで済みます。一方、ASP.NET 機能の多くは、同期的で長い時間リソースを占有し、多くのスレッドを必要としますが、メモリへの影響を低減できるよう同時実行制限がゆるいものもあります。静的ワークロードを分離し、要求処理パイプラインの構成要素を異なるプロセスやサーバーに分散することで、個々のワークロードの同時実行を最適化できます。

さらに、特化によって、アプリケーションが個々のワークロードやアプリケーション構成要素を個別にスケールアウトできるようになるため、全体的なスケーラビリティを向上することができます。これにより、同じテンプレートをアプリケーション全体に適用するのではなく、最も必要とされる箇所でアプリケーショントポロジの収容力と冗長性を高めることができます。このモデルでは、物理サーバー、仮想サーバー、または同じコンピュータのアプリケーションプールでも、特化されたリソースとして扱うことができます。

アプリケーショントポロジで特化を行うことで得られるメリットを評価する際には、まずアプリケーションの処理上または多くのリソースを必要とするボトルネックを特定します。このような領域が特化を行う最有力候補になります。というのも、この領域は、分離すると最適化できる可能性が高く、最大限のエンティティの追加によるスケールアウトが要求されるからです。次に、これらの領域を分離することで、アプリケーションの他の領域でより有効にリソースを使用できるかどうかを評価します。最後に、分離されたアプリケーションコンポーネントを連携させるために必要な接続メカニズムに伴うオーバーヘッドを評価する必要があります。

強化されたアプリケーションサポート

IIS 7.0 には、FastCGI によるアプリケーションフレームワークの拡張サポートが実装されています。FastCGI は多くのオープンソースアプリケーションフレームワークによってサポートされているオープンプロトコルで、このサポートがなければ安定した高パフォーマンスの IIS とのネイティブサポートは実現できない可能性があります。IIS で長年サポートされている CGI (Common Gateway Interface) プロトコルと異なり、FastCGI は Windows プラットフォーム上ではるかに優れたパフォーマンスを実現します。これは主に FastCGI ではプロセスを再利用できるアーキテクチャが採用されていることにあります。プロセスの再利用により、要求ごとにプロセスを作成することで生まれる大きなオーバーヘッドが省かれ、クライアントが固定キープアライブ接続を活用できます。

CGI などのメカニズムを使用して IIS でアプリケーションフレームワークをサポートしている場合、FastCGI プロトコルに移行することで、パフォーマンスを (場合によっては安定性も) 向上できる可能性があります。

このサポートを初めて利用したアプリケーションフレームワークは PHP です。実際、IIS 製品チームは Zend Technologies 社から直接協力を得て、IIS の FastCGI 実装が PHP とスムーズに連携し、Windows 上での PHP フレームワークのパフォーマンス向上を実現できるようにしました (このプロジェクトの詳細については、私のブログ go.microsoft.com/fwlink/?LinkId=122509 を参照してください)。IIS で実行される ASP または ASP.NET アプリケーションと、他のテクノロジを使用する PHP または他の FastCGI 準拠のアプリケーションフレームワークが含まれるという Web サーバーテクノロジが混在している環境では、IIS 7.0 プラットフォームで、これらのアプリケーションを統合できる可能性があります。

PHP や他のアプリケーションフレームワークを IIS 7.0 と FastCGI に移行すると、ASP.NET 統合パイプラインなどの IIS 7.0 機能を利用できます。これにより、アプリケーションフレームワークを ASP.NET に変換しなくても、ASP.NET サービスを使用してアプリケーションフレームワークの機能を強化する非常に便利な手段が得られます。また、異なるフレームワークを使用するアプリケーション間での連携も可能になります。これを使用して、コードを変更することなく既存のアプリケーションの機能を拡張し、パフォーマンスを改善する方法の例については、私の MSDN® Magazine の記事「統合 ASP.NET パイプラインでアプリケーションを拡張する」(msdn.microsoft.com/magazine/cc135973.aspx) を参照してください。

アプリケーション集積度を高める

IIS 7.0 には、1 台のサーバーでホストできるアプリケーションの集積度を高めることを目的としたさまざまな機能拡張が施されています。このような機能拡張は、共有ホスティングの品質を向上する目的で IIS 7.0 が提供しているさまざまな機能の一部であり、これにはサイトプロビジョニングとアプリケーション分離機能の強化が含まれます。

この機能強化ではパフォーマンスの観点から、IIS 7.0 サーバー上にプロビジョニングできるアプリケーションを増やすことと、一度にアクティブにできるアプリケーションを増やすことの 2 点に重点を置いてアプリケーション集積度を向上しています。

IIS 7.0 では、1 台のサーバーで以前よりも多くの数のアプリケーションをプロビジョニングできます。社内テストでは、1 台のサーバーに最大 100,000 件のサイトをプロビジョニングできました。これには、多数のサイトとアプリケーションを作成して構成する機能が必要です。

ただし、高速のプロビジョニングは古い API では実現できないため、これを実現するには、新しい構成 API に移行する必要があります。また、すべての IIS 構成 API で同じパフォーマンス特性が提供されるわけではないので、確実に高いパフォーマンスが得られるように、APIを選択する際には十分に検討する必要があります。迷う場合は、新しい IIS 構成オブジェクトを直接利用する構成オプションを選ぶことをお勧めします。これには、Microsoft.Web.Administration 名前空間、AppCmd.exe コマンドラインツール、スクリプト、.NET、または C++ コードからアクセスする IIS の COM 構成オブジェクトが含まれます。

プロビジョニング可能なサイト数とアクティブにできるサイト数の差は、固定アプリケーションとワーカープロセスを使用して要求処理を実行する IIS アーキテクチャにおいては非常に重要です。このモデルでは、アクティブなアプリケーションは、サーバーのリソースをより多く消費しますが、キャッシュの利用と初期化コストがないことにより、パフォーマンスを維持できます。

アクティブな各アプリケーションには、(推奨されるアプリケーション分離モデルが使用される場合は) 一定量のメモリと個別のワーカープロセスが必要なため、アクティブにできるアプリケーションの数はアプリケーションのメモリフットプリントに大きく依存します。したがって、静的コンテンツのみを処理するアプリケーションのワーカープロセスでは 3 MB しか必要としません (また同じワーカープロセスを他の静的コンテンツアプリケーションと共有することもできます) が、一部の動的なアプリケーションは、あまり使用されていない状態でも 100 MB 以上の RAM を必要とする場合があります。このため、最大集積度を特定する場合、アプリケーションのフットプリントに対して IIS ワーカープロセス自体のメモリオーバーヘッドがかなり高くなります。

一般的な共有ホスティングシナリオでは、通常、80/20 の配布という現象が見られます。これは、要求の 80% がサイトの 20% に渡されるというものです。その結果、どの時点でもアクティブなサイトは少数にとどまります。アクティブなサイト数を増やすため、IIS 7.0 ではアクティブライフタイム管理機能を提供しています。この機能は、より多くのアクティブアプリケーションをホストできるよう、アクティブでないアプリケーションのメモリを回収できるようにするためのものです。

IIS 7.0 は、動的アイドルという新しいアルゴリズムを導入しています。これは、サーバー上の利用可能なメモリに基づいて事前にワーカープロセスのアイドルタイムアウトを調整するものです。メモリが少なくなったときに、アイドル状態のアプリケーションが削除される速度が速くなるので、より多くのアクティブアプリケーションがホストされるようになります。ただし、メモリが利用可能な場合は、より高いパフォーマンスを提供できるようタイムアウトまでの時間が通常どおり確保され、アプリケーションの状態が維持されます。より多くのアプリケーションをアクティブにできるよう、動的アイドル機能では、メモリ不足状態が発生して、スラッシングによるパフォーマンスの大幅な低下を招くことがないようにします。

アクティブなアプリケーションを多数ホストできるようにするには、64 ビットオペレーティングシステムを利用して、4 GB 以上のメモリを割り当てられるという特性を活用することをお勧めします。また、IIS のワーカープロセスが 32 ビットモード (SysWoW64) で実行されるように構成することもお勧めします。このモードでは、IIS のワーカープロセス自体のメモリ消費を節約できるだけでなく、OS では 32 ビット環境で割り当て可能である以上のメモリを割り当てることができます。

圧縮により帯域幅を削減する

インターネットに接続しているデータセンターの最大の運用コストの 1 つが帯域幅のコストであることは、驚くことではありません。また、要求されたコンテンツを送信するのに必要な帯域幅も、認識されるアプリケーションの応答性に影響する主要な要素です。

アプリケーション応答を送信するのに必要な帯域幅を削減する最も有効な方法の 1 つは、HTTP 圧縮を使用することです。これにより、応答のサイズを大幅に削減でき、HTML のような容易に圧縮できるテキストコンテンツに適用した場合は、通常 1/10 に削減できます。最大のメリットは、ほぼすべてのデスクトップブラウザがこれをサポートしていることと、少ないデータを送信することで得られる待ち時間上のメリットと比較して、デスクトップのハードウェア側で圧縮解除コストが軽いことです。また、圧縮は HTTP 1.1 プロトコルで規定されているコンテンツエンコードネゴシエーションに基づいて処理されるため、圧縮を有効にしても、圧縮をサポートしていないクライアントでは圧縮されていないコンテンツを受け取るので問題にはなりません。

IIS 7.0 は、IIS 6.0 で導入された "静的圧縮" および "動的圧縮" という 2 種類の圧縮機能を提供しています。静的圧縮は静的コンテンツを事前に圧縮してディスクに保存することで、将来、圧縮済みのコンテンツを直接処理して、圧縮のオーバーヘッドが生じないようにすることができます。動的圧縮はリアルタイムで応答を圧縮することで、アプリケーションが生成する応答の圧縮を可能にします。IIS 7.0 上のどのアプリケーションフレームワークでも、動的圧縮 (ASP、ASP.NET、または PHP) を利用できます。

定説に反して、動的圧縮は通常、法外な CPU オーバーヘッドを伴うことはありません。実際、多くの場合、動的圧縮はアクセス頻度の高いサーバーで全体の CPU 使用率の 5% 未満のオーバーヘッドしか生みません。動的圧縮は、アプリケーションワークロードの帯域幅を最大限節約できるよう、比較的自由に展開できます。

圧縮と CPU オーバーヘッドの望ましい割合を実現できるように圧縮の度合いを構成することで、さらに圧縮オーバーヘッドを最適化できます。しかし、それだけではありません。圧縮コンテンツをキャッシュできるようにアプリケーションを構成すると、要求されたデータがキャッシュ内にあった場合に、既に圧縮されているコンテンツを処理することで、圧縮のオーバーヘッドを削減できます。ASP.NET と IIS の出力キャッシュはどちらも、圧縮コンテンツをサポートするクライアント用に圧縮コンテンツをキャッシュするだけでなく、非圧縮コンテンツを必要とするクライアントからの要求を処理するオプション機能によってアップグレードされています。

メディアビットレートを調整する

メディアコンテンツを提供するサイトが増えるにつれ、多くのビジネスで帯域幅コストが急速に増大しています。さらに困ったことに、クライアントに送信されるメディアコンテンツは、実際には使用されないことが多いので、メディア帯域幅の大半は無駄に使用されています。なぜこのような事態が起きるのでしょうか。

最後にオンラインビデオを鑑賞したり、ネットサーフィン中にビデオを見たりしたときのことを考えてみてください。ビデオは最後まで見ましたか。ビデオサイトにアクセスするユーザーは、一般的に、ビデオの一部だけを見て次のビデオを見始めたり、閲覧中のページから移動してしまいます。ただし、プログレッシブダウンロードを使用してビデオを提供する Web サーバーでは、通常、このような数秒間の再生に必要なデータよりもかなり多くのデータを送信しています。そして、このデータのほとんどは使われることがありません。

平均してビデオが 5 秒間しか再生されないのに、この 5 秒間に (バッファとして) 30 秒分のビデオデータが提供されるとすると、帯域幅の 80% 以上を無駄にしていることになります。

1 年前、IIS 7.0 のベータリリースを導入していたあるお客様のために、この問題を解決する目的で、自動的にビデオビットレートを検出し、サーバーがほぼ同じレートで確実にクライアントにビデオを提供するようにする帯域幅調整モジュールを作成しました。IIS メディアチームは、Bit Rate Throttling Module (図 4 参照) というこのモジュールを採用し、iis.net ダウンロードセンター (iis.net/downloads/?tabid=34&g=6&i=1640) で提供しています。このモジュールの詳細については、Scott Guthrie のブログ (go.microsoft.com/fwlink/?LinkId=122514) を参照してください。

図 4 ビットレートの調整により帯域幅使用率を最小化 (画像をクリックすると拡大表示されます)

Bit Rate Throttling Module では、一般的なビデオの種類のほとんどのエンコードレートを自動的に検出します。初期バッファ遅延が発生しないように (ファストスタート) クライアントに事前に送信されるデータの量や、コンテンツを提供するエンコードレート率を制御できます。また、最大帯域幅と現在の接続など、その他にも多くのオプションを構成したり、プログラムを使用してモジュールを制御したりすることができます。

出力キャッシュ

一般にキャッシュは、何度も同じ処理を実行するアプリケーションのパフォーマンスを向上する最適な方法です。多くの手間が必要とされ、アプリケーションの処理オーバーヘッドを削減する必要に迫られるアプリケーションのパフォーマンス向上とは異なり、キャッシュは同じコンテンツに対して繰り返し発行される要求のオーバーヘッドを削除できます。

IIS 7.0 以前は、IIS と ASP.NET では、どちらも IIS カーネルキャッシュと ASP.NET 出力キャッシュの形でキャッシュ機能を提供していました。IIS カーネルキャッシュを利用すると最高のパフォーマンスが得られましたが、主に静的コンテンツしかキャッシュできませんでした。ASP.NET 出力キャッシュは、動的コンテンツのキャッシュソリューションという点では、はるかに包括的なものでしたが、パフォーマンスと効率的なメモリ管理という点においては比較的劣っていました。IIS 7.0 で導入された新しい出力キャッシュは、IIS カーネルキャッシュと ASP.NET 出力キャッシュの溝を埋めています。

IIS 7.0 の出力キャッシュを利用すると、ASP、ASP.NET、PHP、他の IIS 7.0 対応アプリケーションフレームワークなど、任意のアプリケーションの動的コンテンツをキャッシュできます。この新機能では、コンテンツの可変性と有効期限という基本的なサポートを提供することで、IIS カーネルキャッシュではキャッシュできないコンテンツのキャッシュの実装を可能にしています。ただし、カーネルキャッシュの制限に適合するコンテンツに対しては、カーネルキャッシュを使用できます。

また、IIS 7.0 出力キャッシュは、ASP.NET 出力キャッシュでしか提供されない高度なキャッシュ機能 (キャッシュの依存関係やキャッシュの無効化など) を必要としない ASP.NET コンテンツをより高いパフォーマンスで処理する、ASP.NET 出力キャッシュの代替機能として利用できます。

出力キャッシュの一般的な課題は、必要なキャッシュの正確性とデータの新しさを維持しながら効率のよい応答のキャッシュを実現できる、適切なコンテンツの有効期限、無効化、および可変性のポリシーを定義することにあります。多くの場合、適切なキャッシュルールを構成するだけで適切なポリシーを定義できますが、実行時の情報に基づいたより複雑なポリシーが必要になる場合があります。このような状況に対応するため、IIS 7.0 出力キャッシュでは、必要なキャッシュ動作を保証するのに使用できるプログラム API を提供しています。この API により、本来ならキャッシュのメリットを得られないコンテンツで、キャッシュによるパフォーマンス向上が見られる可能性が生まれます。また、ASP.NET 統合パイプラインを使用すると、ASP.NET 以外のコンテンツにも ASP.NET 出力キャッシュを使用できます。

動的コンテンツの出力キャッシュを展開することは容易ではなく、IIS 7.0 プラットフォームの異なるキャッシュ機能の効率性と柔軟性を利用できるよう、重層的な戦略が必要になることがあります。この場合は、通常、応答に影響する複数のパラメータの記述して、キャッシュの新しさを維持する有効期限戦略と無効化戦略を定義したうえで、必要なセマンティクスをサポートするキャッシュを定義します。

しかし、ほとんどの場合、このような複雑な対応はそれだけの価値があります。IIS 7.0 出力キャッシュを実装することで、アプリケーションの全体的なスループットを桁違いに改善できるだけでなく、データベース層およびビジネス層のコンポーネントの負荷もそれに合わせて削減できます。

ISAPI コードを IIS 7.0 モジュールに変換する

IIS 7.0 では新しいサーバー API が導入されており、IIS 7.0 の全モジュールはこの API を基盤にしています。これは、以前のバージョンの IIS で使用されていたレガシ API である ISAPI フィルタと ISAPI 拡張 API に置き換わる API です。以前のバージョンをサポートする必要がない新しいモジュールでは、新しい API の方が使いやすく、より信頼性の高いサーバー側コードを作成できます。また、機能面でも優れています。

ただし、IIS 7.0 では、オプションの IIS 7.0 モジュールにより実装される互換性レイヤを利用して、既存の ISAPI フィルタと拡張をサポートするオプションも提供しています。これにより、既存の ISAPI コンポーネントは、書き換えなしで IIS 7.0 でも機能するようになっています。

既存の ISAPI 投資を使用することで IIS 7.0 への移行のハードルは低くなりますが、レガシ ISAPI コードを新しい IIS 7.0 API へ移植することをぜひ検討してください。コードを移植すると、ISAPI 互換性レイヤのオーバーヘッドを取り除いて、ISAPI コンポーネントでは得られないパフォーマンス向上を実現できます。ISAPI コンポーネントが実行する作業に応じて、このパフォーマンス上のメリットにはかなりの開きが出る可能性があります。たとえば、IIS 7.0 モジュール API では、構成メタベースや、サイト、アプリケーション、URL に関連するその他の任意のデータのキャッシュの組み込みサポートが提供されるので、コンポーネント内部での処理を大幅に高速化できます。

また、IIS モジュール API を利用すると、モジュールが、要求エンティティデータの受信や応答の送信など、時間のかかる操作を非同期に実行できます。このような作業を非同期に実行すると、サーバーでは、要求スレッド数の制限のために数十台かせいぜい数百台の同時接続クライアントで限界に達するのではなく、大量 (数万台) の同時実行クライアントに対応できるようになります。また、非同期処理により、他の要求やアプリケーション内の作業の処理に対する影響を取り除き、メモリ使用率を低減し、CPU 使用率を大幅に改善することができます。

ネイティブ API を使用すると、特定のパフォーマンスの影響パターンを得られるだけでなく、要求処理作業の柔軟性を高めることができます。このため、サーバーコンポーネントのデザインを改善して、大幅な効率化を実現できます。たとえば、これまでワイルドカード ISAPI 拡張と子要求の実行が必要だった特定のフィルタ作業は、1 つのモジュールとして元の要求処理中に実行できるほか、応答に IIS カーネルキャッシュも利用できます。

これには、移行によるメリットを最大限得られる最適なデザインを特定するために、多少のプロトタイプ作成とテストが必要になる場合があります。ISAPI と IIS 7.0 モジュール API の根本的なアーキテクチャの違いにより、直接的な移植は必ずしも適切な移植方法ではありません。ただし、IIS 7.0 モジュール API は ISAPI よりも簡単に使用できるため、比較的容易に移行できます。

サーバーの拡張性

IIS 7.0 には、エンドツーエンドの拡張性が備わっています。この拡張性を使用するには、サーバー運用についての実践的な知識がかなり必要ですが、アプリケーション固有のパフォーマンス向上についても大きな可能性を開きます。サーバーアーキテクチャと要求処理についての知識を身に付ければ、この拡張性を利用してご使用のアプリケーション、ワークロード、およびハードウェア要件に適したカスタムのパフォーマンスソリューションをデザインできます。

これは、任意の組み込みの IIS 7.0 機能をカスタム実装で置き換える形で実現できます。IIS 7.0 の機能については、多くの最適化が施され、パフォーマンステストを行っていますが、当然ながら、すべての使用状況において最適化されているわけではありません。したがって、固有のワークロードに合わせて最適化することで、特定のモジュールのパフォーマンスを向上できる可能性があります。たとえば、ファイルシステム API を使用してファイルを一覧表示するのではなく、ディレクトリ一覧モジュールを再実装してディレクトリをメモリにキャッシュすることもできます。

また、この拡張性を利用して新しいパフォーマンス機能を作成することもできます。組み込み機能のうち、このような機能の例としては、出力キャッシュ、圧縮モジュール、その他いくつかの内部キャッシュが挙げられます。

カスタマイズしたパフォーマンス機能が必要かどうかを判断するには、アプリケーションのパフォーマンス特性とワークロードを理解して、解消する必要があるボトルネックを把握する必要があります。IIS 7.0 は、パフォーマンスを分析するための診断サポート機能を豊富に備えています。これらを利用することで、必要な機能の要件とデザインの候補をより明確に把握できるようになります。

まとめ

IIS 7.0 は基本的に機能リリースですが、そのモジュールアーキテクチャ、構成可能性、および新しいパフォーマンス機能により、特筆すべきパフォーマンス強化を実現しています。このような機能強化は、サーバー統合によるビジネスコストの大幅な節約につながります。また、帯域幅コストを削減したり、より優れたユーザーエクスペリエンスを提供したりすることもできます。

IIS 7.0 のパフォーマンス強化の多くを適切に利用するには、多くの場合、現在使用中のアプリケーションプラットフォームを詳細に分析し、IIS 7.0 アーキテクチャの詳しい知識を身に付ける必要があります。この記事で紹介した IIS 7.0 のアーキテクチャと機能の詳細については、iis.net を参照してください。また、私のブログ mvolo.com では、IIS 7.0 を積極的に利用してアプリケーションのパフォーマンスを向上し、運用コストを削減する手法について紹介する予定です。

Mike Volodarsky は、マイクロソフトの IIS チームの元プログラムマネージャです。この 5 年間は、ASP.NET 2.0 と IIS 7.0 のコア機能の設計と開発を推進してきました。現在は、IIS 7.0 と Windows Server 2008 を使用した高パフォーマンス Web ファームのための高度な Web サーバーテクノロジを開発しています。Mike は『Internet Information Services (IIS) 7.0 Resource Kit』の主執筆者であり、MSDN Magazine への寄稿や自身の IIS 7.0 ブログ (mvolo.com) への投稿も活発に行っています。

目次

その他のリソース