AppFabric データ ストア

  • [アーティクル]

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

複数の永続化ストア

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

単一の永続化データ ストア

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

AppFabric 永続化ストア

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

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

  2. 最初の AppFabric データ ストアと同じ SQL Server インスタンス、ただしドライブ セットは別にする

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

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

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

ヒント

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

複数の監視ストア

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 呼び出し/秒である場合に、監視レベルを "エラーのみ" よりも上にすると、ステージング レコードのバックログが蓄積します。この場合、次のオプションに制限されます。

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

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

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

サービスが多数あるために、全体ではステージング レコード到着レートがバックログのしきい値を超えてしまう場合は、最適なオプションは、次の図のように複数の監視ストアを用意し、追跡データを異なる監視ストアにキャプチャするようにサービスを構成することです。

単一のサーバー

この場合も、追加データ ストアの物理的な位置はさまざまなものが考えられます。SQL Server は同一でディスク ボリュームを別にすることも、同じサーバー上の別の SQL Server インスタンス、あるいはまったく別の SQL Server インストールを使用することもできます。各監視データベースには対応する SQL Server エージェント ジョブがあるため、ステージング ジョブのスループットは、サポートするサービスのスループット要件に合わせるために増える可能性があります。

この設計に関しては、1 つ注意が必要なことがあります。AppFabric の "エンドツーエンド アクティビティ" という監視レベルは、同じ監視ストアを使用するサービスのみに対して機能します。これは、ここで示した例には明らかに当てはまりません。エンドツーエンド アクティビティの追跡を有効にするには、ハイブリッド トポロジを採用できます。この場合、サービスの論理グループは追跡データを 1 つのストアに記録し、関連しない同じ環境の他のサービスは、データを他の監視ストアまたは追加の監視ストアに記録します。

  2012-03-05