ホスティング ノードの構成

共有 Windows Server AppFabric データベースを除き、AppFabric Web ファームの各ホスティング ノードは、フル機能完備のスタンドアロン型ホスティング サーバーです。 最終的には、個々のノードの構成とパフォーマンスによって、AppFabric Web ファーム全体のパフォーマンスと管理性が決まります。

分散トランザクション コーディネーター (DTC) の構成

トランザクション サポートのために DTC を使用すると、ログ機能の既定の設定では、特定のしきい値に必要なスループットとパフォーマンスをサポートできないことがあります。 既定では、DTC は C:\Windows\system32\MSDtc にある 4 MB のファイルにアクティビティを記録します。 高負荷の場合、ログ ファイルのサイズと場所がボトルネックになることがあります。 そのため、ベスト プラクティスとして以下の操作が推奨されます。

• 1,000 の同時 DTC トランザクションごとに 1 MB のログ空間を見込んで、ログ ファイル サイズを調整します。 この値から、トランザクション レートを推定し、ログ ファイル サイズを計算できます。 または、コンポーネント サービス コンソールを使用してスループットを監視し、それに従ってログ ファイル サイズを調整します。

• ログ ファイルのサイズよりも重要なことは、ログ ファイルの保存場所です。 ログ ファイルの保存場所は、オペレーティング システムを含むドライブとは別の物理ドライブが最適です。

これらの設定は、次の図のように、コンポーネント サービス コンソールで管理されます。

DTC ログ ファイルのサイズと場所の管理の詳細については、「分散トランザクションのログ ファイルの管理」を参照してください。

AppFabric Windows サービス

(毎秒 10,000～15,000 を超える) 大量の追跡イベントが AppFabric Web ファームの各ノードから生成される場合、複数インスタンスの イベント コレクション サービス を登録および設定することが推奨されます。 アーキテクチャ上の観点からは、ワークフロー管理サービス の展開は 1 つの AppFabric ノードにつき 1 つのインスタンスという既定の構成に制限されますが、複数インスタンスを使用するように イベント コレクション サービス を設定できます。 複数の イベント コレクション サービス インスタンスを設定する手順の説明については、「複数のイベント コレクション サービスを作成する」を参照してください。 さらに、イベント コレクション サービスのスループットを向上させるために、後述する説明に従って複数のサービス インスタンスと複数の監視ストアを使用します。

IIS アプリケーション プール

IIS アプリケーション プールを適切に構成すると、AppFabric のパフォーマンスの最適化にも役立ちます。 AppFabric は実際のサービス ホスティングのために WAS を利用しているため、実行可能なプロセスとその実行時の設定は、IIS アプリケーション プールの構成によって決まります。 既定では、AppFabric をインストールし、その後に Web アプリケーションおよびサービスを展開すると、すべての項目のホストに DefaultAppPool が使用されます。 複数のアプリケーションでのアプリケーション プールの共有は、次のことを意味します。

• すべてのアプリケーションは同じ ID を共有します。

• キューに格納された要求の制限は、複数のアプリケーションで共有されます。

アプリケーション プールで実行されているサービスの構成を変更するなど、何らかの理由でアプリケーション プールをリサイクルすると、そのアプリケーション プールがホストするすべての Web アプリケーションに影響があります。 環境内のアプリケーション プール数を計画する場合、次の点も考慮してください。

• メモリ使用量: 新しく初期化したアプリケーション プールは、コードベースの WCF サービスのホスト時に最大 25 MB の RAM を使用し、WF サービスのホスト時には最大 50～60 MB を使用します。 ソリューションをテスト環境に配置し、負荷をかけてメモリ使用量を監視することで、ハードウェアが目的のアプリケーション プール構造に対応できるかを検証することが推奨されます。 メモリがボトルネックになる場合、物理メモリを増やすか、共有プールに Web アプリケーションとサービスをグループ化する方法があります。

• 管理性: 大量 (数百単位) のサービスと Web アプリケーションがある環境の場合、多数の専用アプリケーション プールの管理は、システム管理者にとって荷が重くなる可能性があります。 この場合の解決方法も、Web アプリケーションとサービスを共有プールで論理的にグループ化することで、専用プールの数を減らすことです。

一般的に、大規模な環境では、Web アプリケーションとサービスの論理的に関連付けられたグループをホストするには、専用アプリケーション プールを使用することが推奨されます。 たとえば、すべての発注処理サービスを 1 つのアプリケーション プールでホストし、給与サービスには専用のアプリケーション プールを用意することができます。 Web アプリケーションおよびサービスのグループ化によって、管理性、実行時の分離、およびパフォーマンスの適切なバランスを達成できます。 共有アプリケーション プールと専用アプリケーション プールに関して特定の規範的な指針を示すことは実用的ではありません。この判断には、多くの要素と環境に固有の考慮事項が関わるためです。 ただし、可能な場合は、共有アプリケーション プールでアプリケーションをグループ化することを検討してください。

サービスの展開オプションと考慮事項

サービスを展開するときに考慮する必要があるもう 1 つの要素は、Web アプリケーションのサービスをグループ化することです。 たとえば、ソリューションに 50 個のサービスが必要な場合、個々のサービスに 50 個の Web アプリケーションを作成しますか。それともいくつかのサービスまたはすべてのサービスを 1 つまたは複数の Web アプリケーションにグループ化しますか。 各サービスに独自の Web アプリケーションがあるという細かすぎるアプローチには、主に次の影響があります。

• 管理性: アプリケーションが多すぎて管理できない状況で、構成設定とファイルの保守に長時間が費やされます。 IIS マネージャー MMC で多数のアプリケーションから特定のサービスを検索することは困難になる可能性があります。

• パフォーマンス: イベント コレクション サービス と ワークフロー管理サービス の両方が Web.config ファイルの変更通知をサブスクライブし、構成の変更に応じて実行時のサービスを更新しています。 AppFabric は ASP.NET の複数レベル継承構成インフラストラクチャに基づいて構築されているため、ファイルが変更されると、多くの場合、アプリケーション ノード階層全体のスキャンが必要になります。 階層が大規模になるほど、実行時の構成の更新による イベント コレクション サービス および ワークフロー管理サービス に対する影響は甚大になります。 また、CPU 使用率とメモリ使用量も高くなります。

アプリケーション プールの計画と同様に、サービスの内容によって複数サービスを 1 つの Web アプリケーションに論理的にグループ化することが推奨されます。 AppFabric は、数百単位の Web アプリケーションを処理できるように設計されています。 ただし、パフォーマンスと管理性を最適にするには、Web アプリケーションの数を実用上で可能な限り少なくすることが推奨されます。 以上の点と、前述した「IIS アプリケーション プール」の考慮事項を検討して、1 つの Web アプリケーションに複数のサービスを含み、共通するアプリケーション プールを複数の Web アプリケーションで共有する一般的な展開トポロジを次の図に示します。

このトポロジの要点は次のとおりです。

• 共通の監視および永続化構成によってサポートできるサービス、および論理的に関連するサービスは、1 つの Web アプリケーションに展開されます。 上の図では、Web アプリケーション 1 と 4 にグループ化されたサービスがあり、各 Web アプリケーションは複数のインスタンスをホストしています。

• 構成の変更後に同じ ID を使用し、同時に再起動できる Web アプリケーションは、同じプールを共有します。 上の図では、Web アプリケーション 1 と 2 がアプリケーション プール 1 で実行されています。ID や実行時の可用性のためにサービスの分離が必要な場合、個別のプールを用意します。

• このトポロジでは、共有プールと専用プールを含め、IIS 環境のアプリケーション プールの合計数 (およびメモリ不足) を減らすことで、アプリケーション プールのメモリ オーバーヘッドを考慮に入れています。 また、管理が必要な高レベルの Web アプリケーションの数を最小限に抑えることで、管理性も改善されます。

  2011-12-05