維持できる最大の追跡スループットの測定

基幹業務ソリューションをBizTalk Server プラットフォームにデプロイした後、システムを追跡して監視し、次の内容を理解する必要があります。

• システムの動作の状況

• 発生するエラーと例外の内容および発生する理由

• BizTalk ソリューションとして実装されているビジネス プロセスの現在の状態

  多くの組織では、否認を目的としない目的で、システムを流れる実際の生メッセージを記録することも重要です。 BizTalk Serverには、次の要件に対応する 2 種類の追跡機能が用意されています。

• データ追跡とアクティビティ (DTA) の追跡。 DTA は、さまざまなユーザー定義メッセージ プロパティ、オーケストレーション デバッグ イベント、メッセージ フロー イベント、およびサービス インスタンス ステータスを追跡します。 追跡を使用して、BizTalk DTA 追跡データベース (BizTalkDTADb) に格納されたデータに対するクエリを実行できます。 DTA 追跡には、否認不可および問題解決を目的として、メッセージ本文の追跡も含まれています。

• ビジネス アクティビティ監視 (BAM) の追跡。 BAM はユーザー定義追跡プロファイルを使用してビジネス プロセスの状態を追跡し、特別な BAM データベースに記録します。

  このトピックでは、DTA アーキテクチャ、および DTA を使用するシステムが無限に維持できる最大スループットを決定する体系的な手法について説明します。 DTA と BAM は同じアーキテクチャ コンポーネントを共有しますが、このトピックでは DTA の動作のみ説明します。 BAM アーキテクチャの詳細については、「 Business Activity Monitoring (BAM)」を参照してください。

DTA 追跡アーキテクチャの概要

メッセージがシステムに送信されると、メッセージの本文、プロパティ、イベントなどさまざまな追跡対象の要素は一連のプロセスおよびデータベースを通過しますが、最終的に BizTalkDTADb データベースに書き込まれます。 要素が BizTalkDTADb データベースに書き込まれた後で、追跡を使用して、追跡した情報に対するクエリを実行できます。 BizTalkDTADb データベースと追跡の設定と使用の詳細については、「 履歴データと追跡データの表示」を参照してください。

システムが維持可能で、特定のメッセージ フロー レートで無期限に動作できるようにするには、追跡対象の要素の経路が BizTalkDTADb データベースまでの固有のパスを通り、データベース自体が正常な状態を維持している必要があります。 たとえば、データベース テーブル内の途中、または DTA でメッセージがたまると、データベース ファイルが無制限に増える可能性があります。これらは、適切に管理しないと維持できません。

最初に、アーキテクチャおよび追跡情報が通る経路について説明します。 これにより、追跡システムがBizTalk Server エンジンを通過するメッセージ トラフィックにどの程度追いついているかを判断するために監視する必要がある主要なリソースとパフォーマンス インジケーターが公開されます。

次の図は、DTA 追跡アーキテクチャおよび経路の概要を示しています。

図に示された番号付きプロセスを順にたどると、すべての DTA 追跡データは次のように BizTalkDTADb データベースに入ったり、データベースから出たりしています。

1. BizTalk Server ランタイム プロセスには、インターセプターというコンポーネントが含まれます。 インターセプターのジョブは、実行時に追跡要素をキャッシュし、次の MessageBox データベースとのやり取りで (たとえば、MessageBox データベースにメッセージをキューに入れるとき)、キャッシュした要素を MessageBox データベースに転送します。 インターセプターは、追跡構成 (追跡プロファイルとも呼ばれる) を参照して追跡する要素を決定します。追跡構成は、管理データベースから取得され、インターセプターが使用できるように各ホスト ランタイム インスタンスにキャッシュされます。

   この図に示したように、MessageBox データベースへのデータ ストリームは 2 つあります。

   • 1 つはスプール テーブルによって表されています。

   • もう 1 つは TrackingData テーブルによって表されています。

     追跡されるメッセージ本文は両方のストリームを使用します。 つまり、メッセージ本文 (データの BLOB と見なす) は、スプール テーブルによって表されるテーブルのセットを介して処理されます。 メッセージ本文に関連付けられたメッセージ イベント (たとえば、メッセージ識別子、メッセージ本文がいつ追跡されたか、メッセージ本文がどのインスタンスに関連付けられているか) は、TrackingData テーブルを介して処理されます。 メッセージ本文の追跡に関連付けられていないすべての追跡要素は、TrackingData テーブルを介してのみ処理されます。

2. MessageBox データベースは、追跡データの単なる最初の停止であり、その後の追跡データ処理によって直接ブロックされることなくランタイムが処理を続行できるように追跡データをキャッシュするために使用されます。

   追跡対象のメッセージ本文 (BLOB) を BizTalkDTADb データベースに転送して、より永続的なストレージに表示およびアーカイブできるようにするには、BizTalk Server各 MessageBox データベース サーバーで実行される TrackedMessages_Copy_BizTalkMsgBoxDb という SQL エージェント ジョブを使用します。 このジョブは、追跡のマークの付いたメッセージ本文を BizTalkDTADb データベースにコピーします。

3. メッセージ本文以外のすべての追跡データは、1 つ以上のBizTalk Server ホストで実行される TDDS というサービスによって、MessageBox データベースから BizTalkDTADb データベースに移動されます。 BizTalk Server 管理コンソールのホスト プロパティ ページでホストが [Hosts Tracking] として構成されていない限り、TDDS サブサービスはそのホストの各インスタンスで実行されます。

4. BizTalkDTADb データベースは、定期的に削除しない限り、無限に成長し、最終的に運用上の問題を引き起こします。 DTA Purge and Archive (BizTalkDTADb) と呼ばれる 1 つの SQL エージェント ジョブがあります。このジョブは、BizTalkDTADb データベースを削除するタスクを実行します。 既定では、このジョブは 1 分ごとに実行され、ユーザーが構成した時間 (たとえば 24 時間) が経過した完了済みインスタンスをすべて削除します。

   DTA 消去ジョブとアーカイブ ジョブの詳細については、「DTA 消去 ジョブとアーカイブ ジョブを構成する方法」を参照してください。

5. 必要に応じて、DTA Purge and Archive ジョブで、データの長期保管またはオフライン表示のために、BizTalkDTADb データを SQL バックアップとしてアーカイブすることもできます。 アーカイブ済みの BizTalkDTADb データにクエリを実行する必要がある場合は、最初に、SQL Server の新しいデータベースとして復元してから、追跡または SQL クエリ アナライザーを使用してクエリを実行します。

このセクションの内容

• DTA 追跡のパフォーマンス特性について

• DTA 追跡の MST を測定するためのテスト シナリオ

• DTA 追跡の MST を特定するためのヒントとテクニック

参照

追跡データベースのサイズに関するガイドライン