動的 Web アプリケーションのアーキテクチャの決定 : パフォーマンス、スケーラビリティ、および信頼性

Microsoft Corporation

November 2000

要約 : この記事では、アーキテクチャの決定の違いが Web アプリケーションのスケーラビリティやパフォーマンスにどうような影響を与えるかを示す、Windows 2000 での Doculabs ベンチマーク テストについて説明します。これには、さまざまな展開オプションや構成設定によるベンチマーク テストの結果が含まれています。

日本語編集注: この記事の本文中で引用されている TPC-C の順位は、オリジナル英文記事の執筆当時におけるデータに基づいています。最新の情報は、TPC (Transaction Processing Performance Council) サイト を参照ください。

MSDN Online Code Center の Nile.com サンプル コードの参照とダウンロード

目次

はじめに
Nile アプリケーション
テスト プラットフォーム
Active Server Pages を使用した Visual Basic アプリケーション
すべて ASP による実装
Visual C++/ISAPI/COM+ 実装
テスト
結果
COM+ を使用する場合と使用しない場合のパフォーマンスの比較
プロセス隔離レベルとパフォーマンス
Windows 2000 ネットワーク ロード バランシングを使用したスケール アウト
コンポーネント ロード バランシング
適切な分割
COM+ トランザクション導入の効果
動的 SQL とストアド プロシージャ
スケール アップとスケール アウト
結論とパフォーマンス チューニングの考察

はじめに

Microsoft は、最近電子商取引アプリケーションのアプリケーション サーバー プラットフォームとして Microsoft Windows® 2000 のベンチマーク テストを行うために Doculabs を採用しました。この記事は、1999 年 7 月の PC Week の記事「Application Server Shootout」の続報としてベンチマーク テストの結果を示しています。オリジナルの Doculabs/PC Week ベンチマークでは、Compaq Proliant サーバー上の Microsoft Windows NT® 4.0 が、ハイエンド Sun サーバーを実行する (Sun Microsystems 社の iPlanet を含む) 7 台の異なる Unix ベースのアプリケーション サーバーを打ち負かしました。PC Week が公表しているオリジナルの結果は記事「Microsoft Comes Through PC Week Scalability Benchmark "like a bolt of lightning."」をご覧ください。また、Marianne Pendleton と Gautam Desai によるWindows 2000 に関する新しい Doculabs レポートは「@Bench Test Report: Performance and Scalability of Windows 2000」でご覧になれます。この記事は、サンプル パッケージでも利用できます。

ベンチマーク後に、私たちはさまざまな聴衆へのプレゼンテーションでその結果を議論しました。結果は好意的に受け取られましたが、いつも決まって次のような補足質問が寄せられました。

• オリジナルの結果は Windows NT 4.0 で取られましたが、Windows 2000ではどの程度向上しているのでしょうか ?
• COM+ コンポーネントには Microsoft Visual Basic® または Visual C++® を使うべきでしょうか ?
• アプリケーションをビルドするのに ASP または ISAPI を使用すべきでしょうか ?
• 状態を管理し、さらにスケーラビリティを向上する最善の方法は何でしょうか ?
• COM+ トランザクションにするとパフォーマンスにどのような影響がありますか ?
• アプリケーションをインプロセスまたはアウト プロセスで実行すべきでしょうか ?
• COM+ ロード バランシングはアプリケーションのスケーラビリティにどのような影響がありますか ?
• 動的 SQL またはストアド プロシージャを使用すべきでしょうか ?
• スケーラビリティを向上するためにどのようにネットワーク ロード バランシングを使用できますか ?
• 負荷の高い環境でアプリケーションの可用性を最高に維持するにはどうすればよいでしょうか ?
• サーバーに多くのプロセッサを追加することはパフォーマンスにどの程度の効果がありますか ?
• ベンチマーク のソース コードを提供してもらえますか ?

この記事で、これらの問題を解決するつもりです。実際にこの記事は、Tech Ed 2000 などいくつか異なるテクニカル イベントでこれまで行ってきたプレゼンテーションを文書にしたものです。この記事の目標は、異なるアーキテクチャの決定が Web アプリケーションのスケーラビリティとパフォーマンスにどのような影響を与えるかを示すことです。記事には、Doculabs の公式レポートには含まれない付加データが含まれています。上記に一覧した質問に答えるために、異なる展開オプションと構成設定でベンチマーク テストを余分に行いたかったので、このデータが含まれています。Doculabs @Benchmark アプリケーションの完全なソースは、サンプルで提供されています。

Nile アプリケーション

Doculabs @Bench ベンチマーク アプリケーションは Nile と呼ばれ、オンライン ブックストアをモデルに作成されました。このベンチマーク アプリケーションは Doculabs が指定した機能に従って、ASP ページを使用した Visual Basic で、またすべて ASP で、さらに ISAPI と COM+ コンポーネントを使用した Visual C++ で実装しました。

Nile アプリケーションは非常に単純な Web ベースのアプリケーションです。一般的にすべてのベンチマーク アプリケーションは、元になる技術基盤が現実のアプリケーションにかかる負荷を処理する能力をテストするため単純なアプリケーションになります。もちろん、実際のアプリケーションはもっと複雑なもので、一般的には内部レガシー システムとの通信や Nile で使用されているよりも複雑なロジックが組み込まれています。ただし、Nile はサーバーになることを目的としています。これは、アプリケーション サーバーがデータベース通信、動的ページ生成、トランザクションといった機械的な作業をどの程度うまく処理できるかに焦点を当てています。これらは、すべてのアプリケーション サーバー製品が通常行うべき作業です。

機能的には、Nile アプリケーションは TPC-W に大まかに準拠しています。TPC-W は、TPC (Transaction Processing Performance Council) の電子商取引ベンチマーク用の新たな標準です。Nile アプリケーションは、単純なオンライン ブックストア アプリケーションで、製品カタログ、製品のアドホック検索、製品の参照、顧客のアカウント管理、ショッピング カート、および注文トランザクションに対してアプリケーション サーバーを使用することに焦点を当てたものです。ベンチマークのページの 90 パーセントはデータベースの内容から動的に作成されます。Doculabs は、ベンチマーク アプリケーションが実際のアプリケーションで使用する可能性のあるより高度な機能を使用する能力をいくつか制限する規則に従う必要があることを指定しています。たとえば、特定のページがあるレベルのキャッシングを要求する場合でも、データベース情報はキャッシュされません。さらに、クライアント セッションを個別のショッピング カートにマップするために使用する単一の Cookie を使って中間層またはデータ層で状態を管理する必要があります。最後に、このアプリケーションではセキュリティは考慮されません。すべてのユーザーは、データを暗号化せずに匿名で接続します。現実のアプリケーションでは、顧客アカウント ページやトランザクション ページは明らかに https を使用するでしょう。 

私たちは、以下の 3 つの異なるアプリケーションを使用して Nile ベンチマーク アプリケーションを実装しました。:

1. ASP ページによってアクティブになる Visual Basic 6.0 COM+ コンポーネント。
2. Visual C++ 6.0 で記述された COM+ コンポーネントをアクティブにする Visual C++ ISAPI。
3. コンパイルしたコンポーネント/コードを含まないすべてが ASP のページ。

これらのアプリケーションのソースとインストール方法はサンプルから利用できます。

メモ Vertigo Software, Inc. 社が Microsoft の Nile.com の実装に対して行った変更については、Nile.com: COM+ の実装 を参照してください。ここでは、サンプル アプリケーションを Microsoft Windows 2000 で COM+ を使用する複数層 Web アプリケーションにしています。

テスト プラットフォーム

テスト プラットフォームは以下のハードウェアで構成されました。

• 1 台の Compaq Proliant 8500 SQL Server 7.0 データベース (2 MB の L2 キャッシュと 3 GB の RAM を持つ 8 基の 550 MHz Pentium III プロセッサ)
• 4 台の CMPQ 8500 Web/アプリケーション サーバー (それぞれ 2 MB の L2 キャッシュと 512 MB の RAM を持つ 8 基の 550 MHz Pentium III プロセッサ)
• 5 台の CMPQ 1850 Web/アプリケーション サーバー (それぞれ 512 KB の L2 キャッシュと 512 MB の RAM を持つ 2 基の 550 MHz Pentium II プロセッサ)
• Cisco ギガビット ネットワーク バックボーン
• Windows 2000 Server を実行し、負荷を生成する 100 台の Dell クライアント ワークステーション (128 MB の RAM を持つ 1 基の 500 MHz CPU)

図 1. Microsoft @Bench テスト ラボ

Active Server Pages を使用した Visual Basic アプリケーション

Visual Basic による実装では、大部分の企業内開発者が Microsoft 開発プラットフォームで使用する次の主要な RAD テクノロジをすべて使用しました。Active Server Pages、Visual Basic 6.0、COM+、およびすべてのデータ アクセスに ADO 2.5。私たちはロジックを非常に単純にしているので、データ層やプレゼンテーション層に XML や XSL を使用するなどの洗練された技法は使用していません。使用しているのは、今日インターネット上で大部分の Microsoft ベースの企業 Web アプリケーションとよく似ているアプリケーション ロジックです。Visual Basic による実装は特に以下の特徴を持っています。

• COM+ を使用した論理 3 階層の実装が存在します。
• ASP は Visual Basic 6.0 で記述された COM+ コンポーネントをアクティブにします。
• IIS セッション オブジェクトを使用しません。
• データベース ID をもとに生成されたクライアント sessionID を Cookie に格納します。
• COM+ コンポーネントは、すべてのデータベース ロジックに対して ADO 2.5 を使用します。
• データのキャッシュは行いません。
• ASP は、書式化/表示用に COM+ コンポーネントから戻された切断されたレコードセットを取得します。
• 適切な ADO コーディング技法が使用されています。データベースのインデックスは高度にチューニングされ、すべての SQL に対して SPROC が使用されています。

すべて ASP による実装

すべて ASP による実装は、コンパイルされた COM+ コンポーネントの代わりに、VBScript クラス ファイルを使用して、全体的にスクリプトで実行されることを除けば、Visual Basic による実装からコードを正確にコピーしたものです。この実装の目的は、スクリプトを使用した場合とコンパイルされた COM+ コンポーネントを使用した場合のパフォーマンスの比較検討を示すことです。アーキテクチャは 3 階層のままで、すべてのデータ アクセスはビジネス ロジックやプレゼンテーション ロジックではなく、独立したクラス ファイルを使用します。ただし、すべてがスクリプトで実行されるので、展開オプションは Visual Basic/COM+ バージョンよりも少なくなります。たとえば、この実装は COM+ ダイナミック ロード バランス、COM+ セキュリティ メカニズムなどは利用できません。

Visual C++/ISAPI/COM+ 実装

この実装は最初の 2 つの例とは根本的に異なります。ここは、RAD 開発ではなく、純粋にパフォーマンスを目標にしています。私たちは、可能な限り最高のパフォーマンスを引き出すために、開発者に低レベルのコードを記述させる Visual Studio 6.0 開発ツールの柔軟性を示したいと考えました。本質的にこのようなコードの記述は困難です。嬉しいことに、Visual C++ チームは、Visual C++ .NET の設計を支援するための課題としてこれを使用しました。ここでの新しい機能は、Visual C++ .NET で採用されている Active Template Library (ATL) Server と呼ばれるものです。これは、この種のアーキテクチャを使用するアプリケーションの開発プロセスを根本的に単純化するでしょう。 

アーキテクチャには、ISAPI の薄いレイヤーが含まれ、これはすべての作業やデータ アクセスを行う Visual C++ の COM+ コンポーネントをアクティブにします。データ アクセスには ADO を使用せず、代わりに ODBC API を使用します。

既におわかりのように、このアプリケーションのパフォーマンス特性は、Visual Basic/ASP のバージョンやすべて ASP を使用するバージョンとは大きく異なります。これには以下の 3 つの主な理由があります。

1. ASP ではなく、IIS の低レベルの拡張として ISAPI を使用しているため。 このアプリケーションでアクティブになるサーバー側のスクリプト エンジンは存在しません。
2. データ アクセスに ADO ではなく ODBC API を使用しているため。 ADO は、手作業のコーディングを大幅に少なくする優れたデータ アクセス ラッパーですが、1 つの抽象層としてある程度のオーバーヘッドを必要とします。
3. Visual Basic ではなく Visual C++ を使用しているため。 C++ のコードは、コンパイルされた形式ではマシン コードに非常に近い、単純化された低水準のものです。ただし、Visual Basic も Visual Basic 5.0 からはネイティブ コードにコンパイルされることを知っておいてください。ただ、コンパイルされた形式では Visual C++ のコードの方がより効率的です。

もちろん、これらすべての決定に対する比較検討には、要求される開発技術力やアプリケーションのビルドに必要な時間も含まれます。Visual Basic アプリケーションやすべて ASP を使用したアプリケーションが Visual C++ アプリケーションほど高速であるとは言えませんが、サーバー クラスタリングを使って達成される優れたスケーラビリティで信じられないほど高速になることを強調しておきたいと思います。実際、私たちは非常に高価な SUN の装置で実行されるあらゆる、またはすべてのハイエンド UNIX アプリケーション サーバーよりも Visual Basic や ASP アプリケーションを躊躇なく推薦します。Visual Basic や ASP テクノロジは、Web 上の大多数の電子商取引アプリケーションのパフォーマンスとスケーラビリティの必要条件を満足するでしょう。

Visual C++ による実装は、Doculabs により PC Week でベンチマーク テストされたオリジナルの C++ Nile アプリケーションを改訂したものです。オリジナルの実装では、すべてのコードが 1 つの ISAPI DLL に含められた、一枚岩的な 2 層構造を持っていました。新しい COM+ アプリケーションは、より管理しやすく、コンポーネント ロード バランシングや COM+ トランザクションの使用など、より多くの展開オプションを提供する論理 3 階層アーキテクチャであり、より優れたものです。

テスト

実際のベンチマークの結果を得る前に、覚えておく必要のある重要な点がいくつかあります。まず、私たちは負荷を生成し、パフォーマンスの結果を測定するため、および信頼性テストの実行中にエラー率を監視するために Quest Software の Benchmark Factory を使用しました。またトップ ラインのテストは Doculabs が実行し、その結果を監査しましたが、補足テストはアーキテクチャの比較検討を示すために同じラボで Microsoft が内部的に行ったことも覚えておいてください。

Benchmark Factory の負荷特性と、Microsoft 独自の Web Application Stress ツールの負荷特性は類似したものです。つまり、比較的少ないクライアントでは簡単にシステムに大きなストレスを与えることはできません。安全のため、100 台のクライアント コンピュータを使用し、テスト中にクライアント数がボトルネックにならないことを保証しました。システムにかかるストレスを最大にするには、Doculabs が PC Week で公表しているオリジナルの Windows NT 4.0 テストと、2000 年 8 月に Windows 2000 Advanced Server で行った補足再テストの両方で行ったように、すべてのテストを "シンクタイム" なしで実行しました。結果を見るときは、これを覚えておくことが重要です。テストでの 1 人の仮想 "ユーザー" は、実際にはサーバーにアクセスするもっと多くの "現実の" ユーザーに相当します。Doculabs は、シンクタイムを持たない 1 人のユーザーは、通常はページ要求の間にユーザー遅延を生じる現実のユーザーの少なくとも 10 人分に相当すると推測しています。ただし、あくまでもこれは概算値です。100 台のクライアント コンピュータを持つ Benchmark Factory は、大多数のインターネット サイトが通常経験するよりも多くのストレスをサーバーにかけることができると言えるでしょう。

結果

図 2 はオリジナルの Doculabs/PC Week Shootout の結果を表しています。ここでは、Windows NT 4.0 上で Nile アプリケーションを、Visual Basic/ASP で実装された場合と、ISAPI アプリケーションとして Visual C++ で実装された場合でテストしました。このテストでは、Oracle 8i データベースに対してハイエンドな SUN サーバーで実行されているいくつかの Java ベースのアプリケーションと Nile が直接比較されました。Microsoft Nile チームは SQL Server 7.0 データベースに対して実行しました。

図 2. オリジナルの Unix と Windows NT の比較

このテストは 1 年前に行われたので、その後パフォーマンスやスケーラビリティに影響するような変化が何かあったでしょうか ? 実は、2 つの大きな変化がありました。1 つは、Windows NT 4.0 の後継としての Windows 2000 の導入です。もう 1 つは、高速の Intel Pentium チップを使用した新しい 8 ウェイ システムの導入です。以下に示した 2000 年 8 月の Doculabs の Microsoft Nile アプリケーションの再テストの結果のように、これらの 2 つの要素の組み合わせによりパフォーマンスがより向上します。

図 3. Unix と Windows NT の再テスト

以下の図は、システムにユーザーを追加した場合に、テストしたアプリケーションごとの完全な相対スループット曲線を表しています。よりよい結果を達成するために、バックエンド ハードウェアとオペレーティング システムの両方がアップグレードされたことに注意してください。ハードウェアは 4 基の 500 MHz CPU を持つ Compaq ProLiant 6400R から 8 基の 550 MHz CPU を持つ Compaq ProLiant 8500 にアップグレードされました。オペレーティング システムは Windows NT 4.0 Enterprise (Service Pack 5) から Windows 2000 Advanced Server にアップグレードされました。

図 4. オリジナルの Windows NT 4.0 の結果と Windows 2000 の再テストの結果 (Visual Basic-COM+/ASP)

図 5. オリジナルの Windows NT 4.0 の結果と Windows 2000 の再テストの結果 (Visual C++/ISAPI)

次のデータのセットは、Windows 2000 Advanced Server と同じハードウェアに Windows NT 4.0 をインストールして行った完全な再テストの結果を示しています。この結果は、Nile アプリケーションに対するこれら 2 つのオペレーティング システム間の相対的なパフォーマンスの違いを純粋に比較したものになります。データは、Visual Basic/ASP と Visual C++/ISAPI のどちらの場合も、負荷が高い状態でのスループットが Windows 2000 の方が Windows NT 4.0 に比べて約 30 パーセント以上向上していることを示しています。ただし、すべて ASP を使用したバージョンでのパフォーマンスの違いは劇的なものであることに注目してください。このバージョンは、オリジナルの Doculabs/PC Week Shootout ではテストされていません。このバージョンの場合、Windows 2000 の方が Windows NT 4.0 に比べて 100 パーセント以上向上していることを示しています。この違いは、ADO だけでなく IIS 5.0 で ASP スクリプト エンジンに対して行ったパフォーマンス改善作業によるものです。

図 6. Windows 2000 Advanced Server と Windows NT 4.0 (Visual Basic-COM+/ASP)

図 7. Windows 2000 Advanced Server と Windows NT 4.0 (Visual C++/ISAPI)

図 8. Windows 2000 Advanced Server と Windows NT 4.0 (すべて ASP)

データの表形式の一覧、および Windows 2000 と SQL Server 7.0 上で Doculabs が行ったフェールオーバーと信頼性のテストに関する議論全体については、Doculabs の公式レポートを参照してください。

COM+ を使用する場合と使用しない場合のパフォーマンスの比較

残りのデータは、異なるアーキテクチャと展開オプションに関する比較検討を示すために、Windows 2000 Advanced Server でテストを行った結果を示します。このデータは、同じ設備を使用して社内で Microsoft Nile チームが行ったテストに基づいています。

図 9 は、Visual Basic/ASP/COM+ 実装とすべて ASP を使用した実装のパフォーマンスの比較を表しています。

図 9. すべて ASP のバージョン (VBScript クラス) と Visual Basic/COM+ コンポーネントを使用した ASP

図 9 は、いくつか興味深い結果を示しています。まず、Windows NT 4.0 で私たちが開発者にアドバイスしたことは、コンパイルした Visual Basic コードの方がスクリプト コードよりも優れたパフォーマンスが得られるということでした。また、開発者はロジックを COM+ コンポーネントに収めることにより、非常に長く、複雑な ASP ページが収拾がつかない "スパゲッティ コード" になってしまう性質を回避できると考えるがちでした。しかし、実際には Windows 2000 ですべて ASP を使用した Nile の実装は、すべてに渡ってわずかではありますがコンパイルした COM+ バージョンよりもすぐれた実行結果を示しました。ここでわかることは、スクリプトとコンパイルされた Visual Basic コードとの比較で以前あったパフォーマンスの低下は、Windows 2000 ではほとんど生じないということです。ASP スクリプト エンジンが Windows 2000 では非常に高速になりました。さらに、私たちは新しく導入されたクラス定義を使ってオブジェクトを作成する能力を持つ VBScript 5.0 を使用したので、コードは Visual Basic 6.0 バージョンの Nile とまったく同じぐらい整然としたものになっています。実際、Visual Basic 6.0 クラス モジュールで COM+ オブジェクトを定義する代わりに VBScript クラスを持つこと以外は同じコードを使用しています。もちろん、すべて ASP を使用するバージョンでは、セキュリティ モデル、コンポーネント キューイング、ダイナミック ロード バランスのような COM+ の機能を利用することはできません。その反面、運用サイトでのコンポーネントのバージョン管理や再登録に関する問題なしで、運用中に容易にロジックをアップグレードできるので、多くの大規模サイトはスクリプトで作業することを好みます。幸いなことにこれらは相互に排他的な選択肢ではありません。頻繁に変更が行われるロジックはスクリプトで記述し、より固定的なロジックは COM+ コンポーネントにカプセル化することをお勧めします。

図 10. Visual C++: 単体型 ISAPI から n 階層 COM+ コンポーネントへの移動

図 10 は、Visual C++ アプリケーションに関して似たような結果を示しています。基本的に、私たちは 2 階層の ISAPI DLL であったオリジナルの Nile アプリケーションを、単に Web サイトから COM+ コンポーネントをアクティブにするために、ISAPI 層が存在する COM+ 実装に移植しました。最終結果は、COM+ を使用することにより重大なオーバーヘッドが生じることはなく、2 つのアプリケーションのパフォーマンスは非常に接近したものになりました。

プロセス隔離レベルとパフォーマンス

任意の Web アプリケーションを展開しているときに、答える必要のある別の疑問点はプロセス隔離に関する疑問です。私たちは、プロセス隔離レベルの決定がパフォーマンスに重大な影響を与えることを示すために、さまざまなプロセス隔離レベルで Visual Basic/ASP/COM+ アプリケーションをテストしました。その結果、ASP と COM+ を基にした Web アプリケーションのプロセス隔離レベルの既定の初期設定は、理想的ではなく、可能な場合は常に調整が必要であることを示しています。

プロセス隔離とは、実行しているコードを、オペレーティング システムが管理する異なるプロセス空間に分割することです。基本的な考え方は、Windows 2000 (および Windows NT 4.0) の管理下では 1 つのプロセスがクラッシュしても、別のプロセスには影響しないということです。たとえば、ある ASP アプリケーションのプロセスと IIS Web サーバー (InetInfo.exe) のプロセスが分離されている場合、アプリケーションがクラッシュしても、そのコンピュータ上の Web サーバーは依然としてほかのサイトのページを処理できます。従って、システム全体がクラッシュすることはありません。ただし、プロセス隔離の欠点はまさにそのパフォーマンスにあります。1 つのアプリケーション内でプロセス境界を超える場合は負荷が高くなります。データ マーシャリングに関連するオーバーヘッドが多く存在し、これは CPU のコンテキスト切り替えを数多く引き起こします。Windows NT 4.0 ではそのコストが非常に高かったので、新しく作成するすべて ASP Web アプリケーションの既定の設定では、IIS と同じプロセス空間で実行されるようになっていました。Windows 2000 では、ASP アプリケーションのパフォーマンスが大きく向上したので、オペレーティング システムは既定値を変更し、新しく作成されるアプリケーションは Web サーバーとは異なるプロセス空間で実行されるようになりました。Windows NT 4.0 と Windows 2000 とで独自のパフォーマンス テストを実行する場合、Windows 2000 のアウトプロセス (既定値) と Windows NT 4.0 のインプロセス (既定値) の比較は、同じものを比べていないことに注意することをお勧めします。

では、Visual Basic/COM+/ASP アプリケーションとプロセス隔離に関する基本的な 3 つのオプションを見てみましょう。その後、そのパフォーマンス データに基づく推奨アプローチを説明します。Windows 2000 での最初のオプションは、ASP アプリケーションの設定を変更し、すべてのものを Web サーバーと同じプロセス空間で実行する Windows NT 4.0 の既定の設定に戻すことです。これは、純粋で単純な最も高速のオプションです。また、このオプションにより、すべての COM+ アプリケーションの既定の設定がサーバー アクティベーション (COM+ オブジェクトのすべてのインスタンスに対して独立したプロセス空間が割り当てられます) からライブラリ アクティベーション (COM+ オブジェクトは呼び出したアプリケーションのプロセス空間に作成されます) に変更されます。ASP アプリケーションと COM+ コンポーネントが十分にテストされていて、さらにこのアプリケーションがそのコンピュータ上で処理される唯一のアプリケーションである場合は、これが一貫したパフォーマンスで最も多数の同時実行ユーザーをサポートするための最善のオプションです。

図 11. シングル プロセス オプションを使用したプロセス隔離

次のオプションは、ASP アプリケーションのプロセス隔離を既定のオプションのままにし、COM+ アプリケーションの設定をサーバー アクティベーションからライブラリ アクティベーションに変更することです。つまり、すべての COM+ オブジェクトは ASP ページの呼び出し側と同じプロセス空間に作成されますが、ASP ページ (従って COM+ オブジェクトも) のプロセスは Web サーバーから分離されます。これはより安全な構成ですが、IIS が ASP と IIS http サーバーとの間でデータのマーシャリングを必要とするので、多くのパフォーマンス オーバーヘッドが必要になります。

これは、新しく、あまりテストされていないアプリケーションや、複数のサイトまたはアプリケーションを実行しているサーバーでは優れたオプションです。このオプションは 1 つのアプリケーションがクラッシュしても Web サーバーがほかのアプリケーションの実行を維持できることを保証します。COM+ コンポーネント内の障害が Web サーバー自体を停止することはありません。

図 12. ASP/ISAPI のプロセスが分離されたプロセス隔離

最後のオプションは、実際には新しく作成される COM+ コンポーネントを呼び出す ASP アプリケーションに対する既定の設定になります。ここでは、ASP アプリケーションはアウトプロセスとしてマークされ、COM+ アプリケーション (COM+ コンポーネントのコンテナ) はサーバー パッケージとしてマークされます。ただし、このオプションでは実際にはプロセスが急増することがわかります。アクティブになる COM+ コンポーネントごとにプロセス境界が追加され、ASP 呼び出しのたびにプロセス境界を超えることになります。これには、多くのオーバーヘッドが必要になり、大多数のサイトにとっては過剰なオーバーヘッドです。

図 13. ASP/ISAPI のプロセスと COM+ のプロセスがそれぞれ分離されたプロセス分離

以下は、これらのオプションを指定した、プロセス隔離の各構成での Nile アプリケーションのパフォーマンス データです。このデータは、1 台の Compaq ProLiant 8500 で取得されました。

図 14. Visual Basic/COM+ と ASP プロセス隔離の変更

明らかに、プロセス隔離の決定がパフォーマンスに大きな影響を与えています。

Windows 2000 ネットワーク ロード バランシングを使用したスケール アウト

ロード バランシングは、Doculabs Windows 2000 テスティングの重要な側面の 1 つです。ロード バランシングは、多くの複製されたサーバーをバックエンドに追加してキャパシティを増加することにより、サイトが クラスタのサーバーにまたがって "スケール アウト" (規模の分散) できるようにします。また、サイトにフェールオーバー機能を与えることにより、冗長性を提供します。従って、バックエンドで 1 台以上のサーバーに障害が発生しても (または保守のために電源を落とす必要があっても)、ユーザーが利用可能な状態が維持されます。最近のアプリケーション サーバーをめぐる論争では、多くのアプリケーション サーバー ベンダによって、さらには報道機関やアナリストによって "ダイナミック ロード バランス" と呼ばれる機能がもてはやされています。皮肉なことに、ダイナミック ロード バランスはごく少数の大規模 Web サイトで使用される機能です。むしろ、大部分の大規模サイトでスケール アウトを達成する最も効果的な方法は、より単純化されたネットワーク レベルのロード バランシングを使用することです。ここでは、1 つのアプリケーション内の個別のコンポーネントを取り出し、利用できる処理容量に基づき動的にロジックを分散しようとするのではなく、単純に着信する IP 要求を複製されたサーバーにまたがってルーティングします。なぜ、この技法が広範に使用されているのでしょうか ? それは、ネットワーク ロード バランシング (NLB) が機能するためです。これは、単純で、容易にセットアップでき、きちんと機能します。これに対して、大部分のアプリケーション サーバーは、複数のアプリケーション サーバーにまたがって負荷を分散するために、専用のブラックボックスのアルゴリズムを使用します。これはうまくいく場合もありますが、多くの場合うまくいきません。特に、分散やルーティングのロジックが複雑なときは、このようなデータ センタをセットアップし、管理することは本当に面倒なことです。さらに、それ自体がシステムのボトルネックになる可能性もあります。 

バックエンド サーバーのクラスタにまたがって負荷を分散する場合は、動的な、コンポーネント レベルのロード バランシングよりも、ネットワーク ロード バランシングの方がはるかに一般的です。これには、 CISCO Local Director のような、NLB を提供するハードウェア ソリューションと、単純なラウンドロビン DNS のようなソフトウェア ソリューションの両方があります。優れたソリューションは障害が 1 個所に集中することはありません。単純なラウンドロビン DNS は使い易いものですが、クラスタ内で 1 つのサーバーに障害が発生した場合でも、着信する要求は依然としてそのサーバーにルーティングされるので、理想的なものではありません。そのため、3 台のサーバーがあり、そのうちの 1 台がダウンした場合、クライアントでは要求の 3 分の 1 が失敗し始めます。Windows 2000 Advanced Server は、組み込みの NLB サービスを持っています。これは、イントラネットおよびインターネットの両方で任意の Web サイトをデザインする場合に考慮すべき重要な機能の 1 つです。Windows 2000 NLB サービスでは、バックエンド サーバーのクラスタにまたがって着信するすべてのネットワーク要求のロード バランスを簡単に設定できます。障害は 1 個所に集中しません。万一、1 台のサーバーがダウンした場合、すべての要求はすぐに残りの利用可能なサーバーだけに送られるようになります。これは 1 秒以内に行われます。Doculabs のベンチマークでは、サーバーの主要なロード バランシング メカニズムとして Windows 2000 NLB を使用しました。これは、4 台のサーバー (テストされた最大数) にまたがる Visual Basic アプリケーションに対して、直線的な規模拡大 (および信頼性テストではサブセカンドフェールオーバー) をもたらしました。

NLB は 2 台のサーバーにまたがる Visual C++ アプリケーションに対しても直線的な規模拡大をもたらしますが、Visual C++ アプリケーションは秒単位に動的に多くのページを処理するので、データベースのストレス レベルが非常に高くなります。そのため、中間層で 2 台のサーバーを超えると、3 番目と 4 番目のサーバーを追加してもスループット パフォーマンスの点では利点が少なくなりました。この時点では、SQL Server 7.0 データベースの CPU 利用率が 85 パーセントを超えて実行されていたので、ゲーティングの要因は既に中間層にはありませんでした。要因はむしろデータベースにありました。Visual C++ アプリケーションの規模拡大を続ける唯一の方法は、複数のデータベース サーバーにまたがって負荷を分散する方法を見つけ出すことでしょう。では、データを見てみましょう。

これを整理すると、毎秒 8,452 ページは毎日 730,252,800 ページに相当します。これはインターネットで最もトラフィックの多いサイトである Yahoo の忙しい日の 1 日のトラフィック量の約 2 倍になります。中間層でのキャッシュなしで、ベンチマークでの Nile ページの 90 パーセントがデータベース クエリを含んでいることを考えれば、単一の SQL Server 7.0 データベース サーバーとしては悪くない結果です。もちろん、Nile は非常に簡単なアプリケーションです。しかし、現在 SQL Server が絶対パフォーマンスの面で、TPC-C の結果の第 1 位を含めて、上位 6 位のうちの 4 つを占有していることの理由の 1 つになるでしょう。

Nile Visual C++ アプリケーションをさらにスケール アウトすることは、複数のサーバーにまたがるある種のデータベース パーティショニングが必要になります。または、"スケール アップ" アプローチを採用し、新しい Compaq や Unisys E7000 のように CPU を 32 基までサポートする高機能のコンピュータで SQL データベースを実行する必要があります。さらに、SQL Server 2000 では、新しい DPV (Distributed Partitioned Views) 機能を使用して、特定のデータベース テーブルを並列に動作する複数のバックエンド サーバーにまたがって分割することによりスケール アップできます。

コンポーネント ロード バランシング

Windows 2000 Advanced Server はネットワーク ロード バランシングを提供しますが、Application Center 2000 はコンポーネント ロード バランシング (CLB) を導入します。これは、アプリケーション内の個別のリモート COM+ コンポーネントのダイナミック ロード バランスです。この機能は、リモート処理されるコンポーネントに対するプログラミングに透過性を提供するので役に立ちます。論理 n 階層アプリケーションを作成するために COM+ を使用する理由の 1 つは、物理 2 階層または物理 n 階層データ センタ アーキテクチャのいずれかに展開する柔軟性を提供することです。つまり、ローカル Web サーバー呼び出しで COM+ コンポーネントを実行できます。または、アプリケーション サーバーの専用の層に Web サーバーのコンポーネントの一部またはすべてを分散することができます。

しかし、最終結果としては Web サーバーのアウトプロセスとしてコンポーネントを実行するとパフォーマンスが低下するのと同じように、Web サーバーからリモートでコンポーネントを処理すると、各コンポーネントの相互作用での余分なネットワーク ホップやネットワークにまたがる COM+ データ マーシャリングにより、パフォーマンスが低下します。それにもかかわらず、多くの顧客はさまざまな理由により、Web サーバーとは別のリモート ロジックを希望します。たとえば、内部 ERP システム (例 SAP R/3) や顧客データベースのような保護されたサブシステムを操作するコンポーネントと Web サーバーの間に特別なファイアウォールを導入する機能などが理由になります。

私たちはCOM+ コンポーネントをリモート処理することによるパフォーマンスへの影響を計測するために、Doculabs に 物理 3 階層データ センタ アーキテクチャを使用した Nile アプリケーションでテストを実行させました。図 15 は、Visual C++/ISAPI/COM+ アプリケーションで、Web サーバーのインプロセスですべての COM+ コンポーネントを実行する場合と、1 つのアプリケーション サーバーに対してすべてのコンポーネントをネットワークにまたがりリモートで処理する場合の大幅なパフォーマンスの違いを示しています。ここで、この混在環境により多くのアプリケーション サーバーを導入することにより、この例でのスループット曲線は向上する可能性があります。この混在環境では、アプリケーション サーバーが 1 つであることがボトルネックになっています。ただし、最終的にはローカルなインプロセス コンポーネントと同等のパフォーマンス レベルを取り戻すには、多くのハードウェアが必要になります。

図 15. Visual C++ COM+ オブジェクト、ローカル対リモート

適切な分割

すべてのコンポーネントを Web サーバーから切り離しリモートで処理する必要があるでしょうか ? この重要な疑問への答えはいいえです。実際、セキュリティがデータ センタおよびアプリケーション自体の内部に正しくセットアップされている場合は、個別の COM+ コンポーネントを Web サーバーから切り離しリモートで処理することにセキュリティ上の利点はまったくありません。しかし、Nile アプリケーションを構成するコンポーネントと、アプリケーション ロジックに "適切な分割" の概念を導入することについて考えてみましょう。実際に、Nile アプリケーションがアクセスする大多数のコンポーネントは、サーバー上での GUI 形式の操作に関係するコンポーネントです。つまり、カタログ参照の結果を持つ動的に構築される HTML ページや製品のアドホック検索のようなものです。これらの操作は、一般的にこれらのコンポーネントに公開される読み取り専用の製品カタログなどに対する読み取り専用の操作になります （おそらく、マスタとなる更新可能なカタログは Web にはまったく公開されない内部システムになります)。

Nile アプリケーションのその他のコンポーネントは、より重要なデータベース情報を操作します。たとえば、顧客データベースとの相互作用 (読み取りと書き込み) を扱うコンポーネントや実際に注文トランザクションをチェックアウトするコンポーネントなどです。ロジックを Web サーバーから切り離し、リモートで処理する主な理由がセキュリティにある場合、クラス ファイルを分割することを考えます。その結果、すべてのコンポーネントをリモートにしないで、HTML UI の生成を支援するだけの単純なコンポーネントなど、本当にリモートで処理しようと考えているコンポーネントだけをリモートにできます。興味深いことに、Nile やその他のアプリケーションで、適切な分割や "選択リモート化" を非常に重要にする 3 つの側面があります。

1. 多くのコンポーネントは、たくさんのデータをクライアントに戻すこと、データベースから製品情報を取得すること、その後の HTML を生成すること、およびこれをクライアントに送信するために Web サーバーに戻すことなどに関係しています。これらのコンポーネントをリモート化すると、数多くのデータ マーシャリング オーバーヘッドが導き出され、パフォーマンスに多大な影響を与えます。
2. その反面、顧客レコードを更新するコンポーネントや注文トランザクションを提出するコンポーネントは、クライアントに大量のデータを戻すことをそれほど頻繁には行いません。クライアントに渡されるデータは、表示用の大量のデータではなく、せいぜいある種の注文確認番号程度です。一般的に、これらのコンポーネントをリモート化することにより、パフォーマンスへの影響がまったく同じになることはありません。
3. 代表的な Web サイトのトラフィック パターンを見た場合、大多数のトラフィックは製品の参照や検索などを行うページの方が、注文を申し込んだり、機密の顧客情報を更新するページよりも不利になります。

これら 3 点を組み合わせて考えると、システムの機密に属する部分を扱うコンポーネントをリモート化することが合理的であるといえます。この場合は、GUI が集中するコンポーネントをリモート化するような多くのオーバーヘッドを生じません。このようなコンポーネントは、実行時間がかかり、複数の内部システムとインターフェイスを取るので、リモート化したい場合があります。また、リモート化することにより、Web サーバー自体の処理負荷がいくぶん少なくなるでしょう。

Nile では、上記のような方法でコードを適切に分割し、その後、個別のコンポーネントを Web サーバーで実行するか、CLB を使用してアプリケーション サーバーの専用のクラスタで実行するかを決定するために、一定の条件を適用しました。まず、コンポーネントがデータベースに対するトランザクションまたは書き込みを含んでいる場合は、そのコンポーネントをリモート化しました。第 2 に、コンポーネントが顧客データベースに対する処理 (読み取りまたは書き込み) を含んでいる場合は、そのコンポーネントもリモート化しました。コンポーネントが、参照要求や検索要求に応答するために読み取り専用の製品データベースを扱っているだけの場合は、Web サーバーの拡張としてローカルに実行するようにしました。ベンチマークでは、Doculabs が電子商取引サイトの代表的な使用パターンであると信じている 6 つの異なるユーザー プロファイルを混在して使用しました。そのプロファイルのいくつかは参照/検索を行い、いくつかは注文を申し込み、いくつかは顧客アカウントを作成または更新します。さらにいくつかは異なるプロファイルが混在したものです。図 16 は、適切にリモート化されたアプリケーションとすべてローカルに実行するアプリケーションとを比較したパフォーマンス図です。

図 16. 適切にリモート化したものとすべてローカルな COM+ オブジェクト

この図からもわかるように、システム内のすべてのコンポーネントをリモート化した場合とは対照的に、パフォーマンスに非常に大きな影響を与えます。この話題の教訓は、コンポーネントをリモート化する理由についてじっくりと検討し、どのコンポーネントをリモートにし、どのコンポーネントをローカルに実行するかを正しく判断する必要があるということです。

最後に、私たちは複数の Web サーバーと (上記の条件で) 適切にリモート化された構成で実行している複数の専用アプリケーション サーバーを持つ構成をテストしました。ここでは、Visual Basic/COM+/ASP 実装用のフロントエンド Web サーバーの背後で専用のアプリケーション サーバーとして動作する一連の Compaq ProLiant 1850r サーバーを導入しました。この場合、すべての Compaq Proliant 8500s は NLB を使ってクラスタ化され、障害が 1 個所に集中しないように、アプリケーション サーバーに対する冗長の COM+ ルーターとして動作します。1850r サーバーは、Web サーバーと切り離されて分散化された COM+ コンポーネントを単にそこで実行するために、CLB を使ってクラスタ化されました。さらに、CLB は NLB と同様に万一アプリケーション層で 1 つ以上のサーバーがダウンした場合のフェールオーバーを提供するので、この層でも障害が 1 個所に集中することはありません。結果を以下に示します。

図 17. 適切な分散とすべてローカルなオブジェクト

分散された、コンポーネント ロード バランシングを使用する構成のスループット曲線がすべてローカルな構成の曲線からすぐに離れ始めていることに注意してください。アプリケーション層 (1850r サーバー) がある時点を超えると飽和状態になるためにこの現象が発生します。より多くの専用アプリケーション サーバーを追加すると、この青い線はすべてローカルのスループット曲線に重なるように平坦になります。ただし、この場合はアプリケーション層により多くのハードウェアが必要になるでしょう。

COM+ トランザクション導入の効果

COM+ が提供する主要なサービスの 1 つに、コンポーネント間の分散トランザクションに対するサポートがあります。Nile のパフォーマンス データを提示したところ、次のような質問をよく耳にしました。「ベンチマークではトランザクションをオンにしましたか、それともオフにしましたか ?」オリジナルの PC Week Shootout では、トランザクションをオンにすることがベンチマークの条件ではなかったことと、ほかのベンダがトランザクション処理 (TP) モニタを所持しなかったことにより、この質問に対する答えはトランザクションはオフでした。

Nile アプリケーションの COM+ コンポーネントを "トランザクションを要求する" としてマークすることにより、これらのコンポーネントに対するトランザクション サポートをオンにした場合何が起こるかを見てみましょう。この結果、コンポーネントを呼び出すたびに Microsoft 分散トランザクション コーディネータが起動され、すぐに想像できるようにシステムにオーバーヘッドが生じます。適切な分割に基づいてコンポーネントをリモート化することに関する話題に戻りましょう。トランザクション サポートの問題についても同じロジックを適用できます。Nile のすべてのコンポーネントを真のデータベース トランザクションにする必要はあるでしょうか ? その答えはいいえです。実際には、アプリケーションでのトランザクションは単純で、1 つのデータベースに対するものになり、さらにストアド プロシージャで直接簡単に処理できるので、本当に COM+ トランザクション サポートを必要とするコンポーネントはありません。しかし、このまま先に進み、Nile のロジックを適切に分割し、注文データベースや顧客データベースに書込み操作を行うコンポーネントはすべてトランザクション サポートを有効にし、単純な Select ステートメントだけを実行するコンポーネントはトランザクション サポートをオフにするようにします。図 18 は、システム内のすべての COM+ コンポーネントに対して無意味に COM+ トランザクションをオンにするのではなく、それが意味を持つように適切にトランザクションを使用する場合の影響を示しています。図 18 は、単一の Compaq ProLiant 8500 Web/アプリケーション サーバーで実行されている Visual C++ アプリケーションを表しています。

図 18. 適切に COM+ トランザクションを使用する

再びここでの教訓は、どのコンポーネントでトランザクションをサポートする必要があるかを注意深く検討し、"トランザクションを要求する"としてマークするコンポーネントを選択できるようにクラス ファイルを適切に分割することです。

動的 SQL とストアド プロシージャ

使用中またはアプリケーション ロジックの実行中に動的に SQL ステートメントを構築するのではなく、SQL ステートメントを使用することが前もってわかっているときは、ほとんど場合ストアド プロシージャを使用することをお勧めします。アプリケーション内に直接 SQL 文字列を埋め込むのではなく、ストアド プロシージャを使用するとシステムをより保守しやすくなります。また、SQL Server はプリコンパイルされたクエリ プランを持っているので、動的に SQL を使用するときよりもそのプランの実行が高速になります。図 19 は、Nile ASP アプリケーションですべて動的 SQL を使用する場合とストアド プロシージャを使用する場合の比較を示した図です。

図 19. Nile ASP アプリケーションですべて動的 SQL を使用した場合とストアド プロシージャを使用した場合

スケール アップとスケール アウト

最後に、8 基の CPU を使用する Windows 2000 システムと 4 基の CPU を使用する Windows 2000 システムで Nile アプリケーションを実行することにより、スケール アップによる影響をテストしました。図 20 で表されたデータは、重要なポイントを示しています。つまり、システムにプロセッサを追加したときに、直線的な規模拡大は期待できません。多くの場合、複製されたコンピュータを追加してスケール アウトする方が、サーバーに多くのプロセッサを追加するよりもより効果があります。ただし、スケール アップ (規模の拡大) とスケール アウト (規模の分散) は共に重要です。スケール アップすることにより、ユーザーの負荷を処理するために必要なサーバー数を大幅に削減できます。その結果、データ センタでの管理コストを削減できます。それに対して、スケール アウトすることにより、低いコストで大幅に規模を拡大でき、利用度の高いサイトに対して優れたフェールオーバー サポートを提供できます。また、新しい Windows 2000 Data Center Server では、最大 32 基までの CPU を持つシステムで実行する能力を得ます。さらに、個別の CPU を特定のアプリケーションに占有させることができ、サーバーの統合により大きな可能性が生じます。また、Windows 2000 Data Center Server は、CPU を占有する特定のアプリケーションに対して CPU が飽和状態に達したとき、そのアプリケーションにより多くの CPU を占有させるようにプロセッサを自動的に再構成できます。

図 20. Windows 2000 で 4 基から 8 基へのプロセッサ数の拡大

結論とパフォーマンス チューニングの考察

以下の一覧は、私たちが Nile の実装をビルドし、チューニングしているときに行った最も重要なステップをいくつか示したものです。

• 負荷のかかる状況でアプリケーションをテストし、チューニングします。
  • パフォーマンスの目標を設定します。
  • 目標に達するまで、ボトルネックを探し、除去します。
• データベース チューニングが最も重要です。
  • 正しいインデックスが重要です。
  • SQL Server CPU の使用率を監視します。適度の負荷では使用率は低く、軽い負荷では使用率が最小になる必要があります。
• データベースを正しく構成します (たとえば、並列 RAID コントローラやデータとトランザクション ログ用のデバイスを分けることなど)。
• 状態を持たないデータベース操作を使用し、常に切断されたレコードセットを使用します。
• 正しい ADO コーディング技法を使用します (FMStocks 2000 と MSDN の Nile サンプルを参照してください。) rs.CursorLocation = adUseClient rs.Open cmd, , adOpenForwardOnly, adLockReadOnly
• 以下のことは避けるようにします。
  • 1 行のレコードセット (出力パラメータを使用)、adExecutenoRecords。
  • 大きなレコードセット (数百なら問題ありませんが、数千なら問題です)。
• ASP または ISAPI をインプロセスまたは独立したプロセスで実行し、COM+ パッケージを可能な限りインプロセス (ライブラリ パッケージ) で実行します。
• Windows 2000 ネットワーク ロード バランシングを使用します。
• CLB を使用してすべての COM+ コンポーネントを無意味に分散することは行いません。適切な条件を使用します。読み取り専用データを扱う UI 中心のオブジェクトを含めて、多くのオブジェクトは分散する必要はありません。
• COM+ トランザクションを適切に使用します。
• イベントや統計、同期、トランザクション、JIT など使用していない COM+ の機能はオフにします。
• 思いつきで中間層のキャッシュを使用しません。必要がない場合がほとんどです。
• 可能な場合は常にユーザー状態用にデータベースまたはクライアントを使用します。IIS のセッション オブジェクトやアプリケーション オブジェクトの使用を避けます。
• 注文の申し込みやレガシー システムを使用した抽出など、実行時間がかかる操作では非同期操作 (COM+ 疎結合イベント、メッセージ キュー) を使用します。

 ページのトップへ