エンジンの永続性と耐久性
このセクションでは、SQL Server を介してプロセスの状態をディスクに永続化することによって、疎結合されたビジネス プロセスを BizTalk Server が確実に統合する方法について説明します。 トランザクションを活用し、状態の永続化を適切なタイミングで行うことによって、ハードウェアまたはソフトウェアに障害が発生しても、プロセスの状態が失われることのないシステム環境を保証できます。 これはシステムの耐久性とも呼ばれます。
疎結合されたビジネス プロセスの管理
既存の複数システムを統合して 1 つの論理ビジネス プロセスを実行するには、これらの既存システムの外側でプロセスの状態を管理することが必要です。 ビジネス プロセスが長時間にわたるものか、短時間で終了するものかにかかわらず、システムどうしを密結合したことによるカスタム通信経路の急増を回避するために、プロセスの状態は個別に管理する必要があります。
ビジネス プロセスがミッション クリティカルである場合、実行中のビジネス プロセス インスタンスの状態に高い信頼性が求められることは明白です。 ビジネス プロセスの信頼性および持続性を高くするために、BizTalk では SQL Server のトランザクションを活用し、プロセスの状態およびビジネス データをメッセージ ボックス データベースと呼ばれるデータベース内のディスクに保存します。 MessageBox データベースの詳細については、「 MessageBox データベース」を参照してください。
BizTalk Server内のすべてのメッセージと最も単純なビジネス プロセス インスタンス (オーケストレーション インスタンスなど) はすべて、処理中に少なくとも 1 回は MessageBox データベースに保持されます。
永続性と持続性
BizTalk Serverはすべてのメッセージを保持し、ほとんどのオーケストレーションがサステナブル パフォーマンスとは何かに関するページで説明されているように、ほとんどのオーケストレーションが持続可能性に直接影響を与えるという事実。メッセージが MessageBox データベースに到着すると、メッセージは待機中のサブスクライバー (オーケストレーションや送信ポートなど) にルーティングされ、サブスクライバーがメッセージ ボックス SQL テーブルにキューに入れて処理するのを待機するためにメッセージ ボックス SQL テーブルにルーティングされます。 到着した一部のメッセージは、新しいサブスクライバー インスタンスをアクティブ化します。 それ以外のメッセージは、到着すると、既に実行中のサブスクライバー (関連付けられたオーケストレーションなど) の待機中のインスタンスに、関連付けを介して回送されます。
関連付けられたオーケストレーションが処理を続行するには、関連付けられた到着メッセージがブロックされない状態を維持する必要があります。 そのために BizTalk では、関連付けられたメッセージを待っているサブスクライバーが処理を完了して他のプロセスに実行領域を開放することができるように、高負荷な状態であってもメッセージ (アクティブ化を行うメッセージおよび関連付けられたメッセージの両方) の受信を可能な限り継続します。 つまり、メッセージを処理してメッセージ ボックス データベースから削除するよりも速くメッセージを受信することが可能になり、バックログとしてメッセージが蓄積される状況を生じます。 ストア アンド フォワード テクノロジでは、通常、BizTalk がこのようなバッファリングを行いますが、常に受信レートが処理レートを上回る状態がいつまでも続いてバックログが大きくなると、問題につながります。
BizTalk Server によって受信されたメッセージまたは BizTalk Server 内で作成されたメッセージは変更できません。 つまり、メッセージがいったん受信または作成されると、その内容は変更できません。 また、受信したメッセージに複数のサブスクライバーが存在することもあります。 その場合、同じメッセージの単一コピーが、複数のサブスクライバーによって参照されます。 この方法では記憶域は最小化されますが、各メッセージについて参照カウントを保存する必要が生じます。また、参照カウントが 0 のメッセージは、定期保守で除去する必要があります。
メッセージ ボックス データベース内で大きなバックログの蓄積が許容される場合、各メッセージ ボックス データベースの SQL ジョブのセットとして実装されているデータベースのメンテナンス処理が遅れることになり、その遅れを取り戻す機会がなければ、最終的にディスク領域が不足するなどの事態を招くことがあります。 この状況を回避するために、BizTalk Server には制限メカニズムがあり、メッセージ ボックス データベースのバックログがユーザーの設定したレベルに達したときにメッセージの受信レートを下げます。 調整の詳細については、「ホストの調整 によるリソース使用量の最適化」を参照してください。
持続性にかかわるすべてのアクティビティおよびプロセスを考慮すると、長時間の持続性を維持するには、バックログが無制限に蓄積されないようにすることが重要です。 つまり、メッセージ ボックス データベースのバックログを処理可能な平均サイズに維持できるように、長期にわたってスループット レベルの高いピークと低いピークの間のバランスをとる必要があります。 バックログの主なメジャーは、BizTalk:Message Box:General Counters:Spool Size と呼ばれるBizTalk Server パフォーマンス カウンターとして公開されるスプール テーブルの深さです。 このパフォーマンス カウンターの詳細については、「 メッセージ ボックスのパフォーマンス カウンター」を参照してください。
スプール サイズとその他のカウンターを使用してシステムが維持できる最大スループットを決定する方法の詳細については、「 最大持続可能なエンジン スループットの測定」を参照してください。
Recommendations
BizTalk Serverは、すべてのメッセージとほとんどのオーケストレーションを保持し、チェックを解除したままにして、ディスク領域の不足などの問題が発生する可能性があるメッセージのバックログを開発できます。 バックログの主なメジャーは、メッセージ ボックス スプール テーブルの深さです。これは、BizTalk:Message Box:General Counters:Spool Size というパフォーマンス カウンターとして公開されます。
持続性の高いスループットを得るには、長期間にわたり安定した平均的なスプール サイズを維持する必要があります。 つまり、スプール サイズを抑制せずに無限に増大させるわけにはいきません。 「 持続可能なエンジンの最大スループットの測定」では、この動作について詳しく説明し、スプールサイズやその他の業績評価指標を活用してシステムが維持できる最大スループットを決定する方法を提供します。
参照
維持可能な最大エンジン スループットの測定
維持可能なパフォーマンスとは
パフォーマンスのヒントとテクニック
メッセージ ボックスのパフォーマンス カウンター