AppFabric データ ストア

既定の Windows Server AppFabric のインストールおよび構成プログラムでは、1 つの永続化データベースと 1 つの監視データベースが生成されます。 高スループット環境では、ディスク I/O、SQL のロックなどのために、どちらのストアもパフォーマンスのボトルネックになる可能性があります。 AppFabric は、複数の永続化および監視データベースを使用することで、データ トポロジの柔軟性を大幅に向上できます。 適切に使用すると、この柔軟性によって良好なパフォーマンスを確保できます。

複数の永続化ストア

永続化ストアが AppFabric 環境でボトルネックになる可能性がある理由について理解することは重要です。 永続的な WF サービスは、その状態を AppFabric 永続化ストアに格納します。 各永続化インスタンスのほとんどの詳細は、インスタンス テーブルとキー テーブルに格納されます。 高スループット シナリオでは、短期間に、多数のワークフロー インスタンスが作成され (データベースの挿入)、永続化され (データベースの更新)、関連付けられ (データベースの読み取り/挿入/削除)、完了します (データベースの削除)。 このようなテーブルは、ディスク I/O の競合、およびデータベースのロックとラッチの原因になります。 このボトルネックについて、次の図に示します。

上記の情報を考慮すると、永続化データベースがボトルネックになる可能性がある状況では、複数の永続化ストアを作成することをお勧めします。 特定のサービス、または論理的に関連するサービスのグループに専用のストアを作成します。 新しい永続化データ ストアを作成するプロセスについては、「Windows Server AppFabric コマンドレットを使用したデータベースの作成および初期化」を参照してください。 概念上は、次のように図示できます。

追加の各データベースの物理的な位置は次のように構成できます (低い拡張性から高い拡張性の順)。

1. 最初の AppFabric データ ストアと同じ SQL Server インスタンスおよびドライブ セット (データおよびログ ファイル ボリューム)

2. 最初の AppFabric データ ストアと同じ SQL Server インスタンスで異なるドライブ セット

3. 同じ SQL Server クラスターで実行されている別の SQL Server インスタンス

4. 異なる SQL Server インストールおよびクラスター

上記の選択肢から何を選択するかは、環境と使用できるハードウェア リソースによって変わります。 ボトルネックがある場所を正確に理解するには、CPU、メモリ、ディスク I/O、および SQL のロック/ラッチに関連するパフォーマンス カウンターを使用する必要があります。 これらの値は、問題を軽減するために最適な選択肢を判断する際にも役立ちます。

ヒント

現在、Windows Server AppFabric に固有のパフォーマンス カウンターはありません。

複数の監視ストア

AppFabric の監視データ ストアの構成とトポロジ オプションは、前述した永続化データベースと似ています。 トポロジ オプションの詳細な説明に進み、適切な選択を行う前に、監視ストア内のデータ フローの概要を説明し、ボトルネックの主な原因を示します。 イベント コレクション サービス がキャプチャしたデータは、次の簡略化したプロセス シーケンスで処理されます。

1. キャプチャされた WCF および WF イベント データは、監視データベースの単一のステージング テーブルに書き込まれます。

2. SQL エージェント ジョブによって新しいイベントが頻繁にチェックされます。そのイベント データは解析され、標準化された WCF および WF イベント テーブルに移動されます。 このデータは、AppFabric ダッシュボードまたは任意のカスタム クエリ/レポート テクノロジにデータを提供するデータベースのビューに使用されます。 WCF イベントのステージング ロジックは、WF イベントとは異なります。 これは、WCF イベントがランダムな時点で発生するためです。通常、WF イベントは、ワークフロー インスタンスに対して長時間連続して実行される可能性があるイベントの一部です。 この場合、イベントの関連付け、一時的な状態、および整合性も重要です。

   1. 純粋な WCF サービス イベントの場合、SQL エージェント ジョブは、ステージング テーブルから標準化された WCF イベント テーブルに対して、一括してステージング レコードを処理します。 これは比較的高速な一括処理操作です。

   2. WF イベントの場合は逆に、SQL エージェント ジョブは、ステージング レコード (イベント) ごとにロジックを実行してから、標準化された WF イベント テーブルにデータを移動する必要があります。 その結果、処理時間が長くなります。

3. データは、標準化された WCF イベントおよび WF イベント テーブルに挿入されます。

この処理を次の図に示します。

パフォーマンス テストでは、SQL エージェント ジョブは毎秒 3,500～4,500 のステージング レコード (イベント) を処理できることがわかっています。このテスト環境として、32 GB の RAM を搭載した 4 クアッドコア CPU BL680c サーバーと、「SQL サーバー プラットフォームの最適化」の項で前述した記憶域の構成例に合わせたディスク記憶域構成が使用されました。

6 個のアクティビティがあるステートレス短期実行ワークフロー サービスは、参照として正常性の監視レベルを使用して、約 13～14 追跡イベントを生成します (結果としてステージング レコードが多数になります)。 つまり、ステージング テーブルの着信レコード レートは、SQL エージェントのステージング ジョブ処理 (ドレイン) レートの毎秒 285 以下のサービス呼び出し (4,000 ドレイン レート/14 イベント/ワークフロー インターフェイス = 285 以下のワークフロー インスタンス) と相応です。 高スループット レートは、ステージング テーブルでバックログの構築を開始します。

ヒント

純粋なコードベースの WCF サービスの場合、AppFabric の正常性の監視レベルは、既定で操作の呼び出しに関する統計情報を集計してから、追跡した情報を監視ストアに送信します。 既定のサンプリング/集計レートは 5 秒ごとであり、結果として、その期間中に呼び出されるサービス操作ごとに、監視ストアに対して生成されるイベントは 1 つです。

この環境内で 1 つの WF サービスに、一定して 280～300 呼び出し/秒の負荷がある場合、エラーのみを超える監視レベルを使用することで、ステージング レコードのバックログを構築します。 この場合、次のオプションに制限されます。

• このサービスについて監視をオフにします。 この場合、MonitoringLevel パラメーターを "Off" に設定して、AppFabric 管理 UI または et-ASAppMonitoring Windows PowerShell コマンドレットを使用します。

• このサービスについて監視レベルをエラーのみに下げます。 この場合、MonitoringLevel パラメーターを "ErrorsOnly" に設定して、AppFabric 管理 UI または et-ASAppMonitoring Windows PowerShell コマンドレットを使用します。

• 組み込みの状態監視追跡プロファイルからカスタム追跡プロファイルを定義します。また、ワークフローのすべてのアクティビティからイベントをキャプチャするのではなく、必要なイベントのみを含めます。 カスタム追跡プロファイルの作成については、「追跡の構成」を参照してください。

複数のサービスを合計すると、着信ステージング レコード レートがバックログのしきい値よりも高くなる場合、最適なオプションは、次の図のように、複数の監視ストアを用意し、追跡データを異なる監視ストアにキャプチャするようにサービスを構成することです。

この場合でも、追加データ ストアの物理的な位置は、同じ SQL Server で異なるディスク ボリューム、同じサーバー上で異なる SQL Server インスタンス、または完全に異なる SQL Server インストールという複数の構成があります。 各監視データベースには対応する SQL Server エージェント ジョブがあるため、ステージング ジョブのスループットは、サポートするサービスのスループット要件に合わせるために増える可能性があります。

この設計で特に重要な考慮事項は、AppFabric のエンドツーエンド アクティビティの監視レベルは、同じ監視ストアを使用するサービスについてのみ機能するという点です。これはこの項の例には適用されません。 エンドツーエンド アクティビティの追跡を有効にするには、ハイブリッド トポロジを採用できます。この場合、サービスの論理グループは追跡データを 1 つのストアに記録し、関連しない同じ環境の他のサービスは、データを他の監視ストアまたは追加の監視ストアに記録します。

  2011-12-05