維持可能なパフォーマンスとは

システム持続性を計画および評価する場合、長期間の持続性について考慮することが重要です。 主要な考慮事項は次のとおりです。

• プロファイルの読み込みとパフォーマンスの目標: プロファイルとパフォーマンスの目標の読み込みに関しては、あまり詳細を含めることはできません。 テストと準備が完了したことは、これらの負荷を長期間にわたって処理できるかどうかによって判断されます。

• サーバー リソースに対して競合するその他のアクティビティとプロセス: メッセージの読み込みだけではありません。 サーバーでは、パフォーマンスに影響を与える他のプロセスおよびアクティビティ (データベース メンテナンスや、メッセージのクエリなど) が発生します。

• 計画的および計画外のシステム停止とダウンタイム: Floodgate イベントとメッセージ バックログによって、有効な読み込みプロファイルが変更される可能性があります。

  維持可能なシステムの構築および証明するためのテストについて検討する場合は、これらの事項を考慮する必要があります。

維持可能なパフォーマンスについて

BizTalk Serverのパフォーマンスについて説明する場合は、次のように最大の持続可能なパフォーマンスを定義します。

• システムが実稼働環境で無制限に処理できるメッセージ トラフィックの最大負荷。

  単純なようですが、特定のハードウェアで動作するソリューションが、実稼働環境へのソリューション適用後に毎日発生する負荷に対応できるかどうかを評価する場合は、多数の要因を考慮する必要があります。

  ソリューションを実稼働に移す前に、ソリューションがメッセージ トラフィックの最大負荷を無制限に処理できるかどうかを評価するために、次の事項について考慮してください。

• 適切なパフォーマンス目標、および、スループットと待機時間のプロファイル

• 同じハードウェアで実行される他のプロセス

  • 標準の監視ツールとトラブルシューティング ツール

  • ログ配布、バックアップ、削除、インデックス メンテナンス、統計の更新など、稼働中のデータベースのメンテナンス

  • その他のアプリケーション

• 計画内または計画外のシステムの障害

  • 取引先サイトのダウンによるメッセージ送受信のブロック

  • 通常のシステム メンテナンス ダウン タイム

パフォーマンスの目標の理解

ソリューションの持続性を評価するには、実稼働環境の負荷の予測を詳細に理解する必要があります。 目標を適切に把握していないと、準備が十分かどうかを評価できません。 システムのテストおよび保証は、パフォーマンス目標を軸として遂行されるので、目標を適切に設定することが重要です。 パフォーマンスの目標には次の要素が必要です。

• パフォーマンスを時間の関数として定義する曲線。 これらの関数は、非常に単純なものから非常に複雑なものまであります。

• パフォーマンス関数に関連付けるパフォーマンス要件。

• ファイルのサイズと種類の分布。

例 1

• 毎日、蓄積されるメッセージは、8:00AM に 0 メッセージ/秒、正午に 80 メッセージ/秒となり、9:00PM に 0 メッセージ/秒に戻ります。ベル曲線にほぼ近い形です。

• システムにはメッセージごとに特定の待機時間要件はありませんが、この負荷に加えて、前日のすべてのメッセージ負荷 (たとえば、24 時間システムが停止した場合) を遅れることなく処理できる必要があります。

• 伝票タイプには、販売バスケット、バックオーダー、在庫依頼の 3 種類があります。 販売バスケット ドキュメントのサイズの範囲は 2 ～ 10 KB で、どの時点でもメッセージ数の 75% を占めます。 注文残および在庫要求ドキュメントのサイズは常に約 1 KB で、どの時点でもメッセージ数の 10% と 15% をそれぞれ占めます。

例 2

• 毎日、深夜 0 時に、500,000 メッセージのバッチが処理のために到着します。

• バッチのメッセージはすべて、8 時間以内に完了するように処理する必要があります。

• メッセージはすべて同じ種類で、10 ～ 15 KB の範囲で均等に分布しています。 さらに、バッチは常に、それぞれ 10 MB のカタログ タイプ メッセージ 10 件を含んでおり、処理のために個別のカタログ エントリに分割する必要があります。

例 3

• 4,000 人の顧客サービス担当者が、週に 7 日間、毎日午前 8 時から対話型のシステムにログオンし、午後 5 時の終了時間までに各人が 1 分間に平均 4 件の問い合わせを実行します。

• すべての問い合わせは、2 秒未満で結果を返す必要があります。

• 問い合わせはすべて同じ種類で、500 ～ 1,000 KB の範囲で均等に分布しています。

パフォーマンス関数に関連付けるパフォーマンス要件

上記の例をもう一度使用します。

• 例 1 (続き): システムにはメッセージごとに特定の待機時間要件はありませんが、この負荷に加えて、前日のすべてのメッセージ負荷 (たとえば、24 時間のシステム障害が発生した場合) を処理できる必要があります。

• 例 2 (続き): バッチ内のすべてのメッセージを 8 時間以内に完了するように処理する必要があります。

• 例 3 (続き): すべての問い合わせで 2 秒未満の結果が返される必要があります。

ファイルのサイズと種類の分布

• 例 1 (続き) : 販売バスケット、バック オーダー、在庫要求の 3 種類のドキュメントがあります。 販売バスケット ドキュメントのサイズの範囲は 2 ～ 10 KB で、どの時点でもメッセージ数の 75% を占めます。 注文残および在庫要求ドキュメントのサイズは常に約 1 KB で、どの時点でもメッセージ数の 10% と 15% をそれぞれ占めます。

• 例 2 (続き) : すべてのメッセージは同じ種類であり、10 から 50 キロバイト (両端を含む) の間で均等に分散されます。 さらに、バッチは常に、それぞれ 10 MB のカタログ タイプ メッセージ 10 件を含んでおり、処理のために個別のカタログ エントリに分割する必要があります。

• 例 3 (続き): すべての問い合わせは同じ種類であり、サイズが 500 から 1000 バイトの間で均等に分散されます。これらの値は含まれます。

他のプロセスに関する考慮事項

BizTalk エンジンに直接送られるロード プロファイル以外に、リソースに対して競合する他のプロセスが同じハードウェア上に常に存在します。 このような他のプロセスにより、維持可能なシステムのパフォーマンス機能が全体的に低下します。 データベース メンテナンスは、この種類のプロセスの最も一般的な例です。

各データベースは (サイズの大小に関係なく)、ログ配布、バックアップ、アーカイブ、削除など、定期的な稼働中のメンテナンスが必要です。 監視およびトラブルシューティングは、何が維持可能かを定義および証明する場合に考慮すべき操作の 1 つです。 たとえば、管理コンソールの [グループ ハブ] ページなどから、メッセージ ボックスで、24 時間以内に保留された特定の種類のメッセージ数を求めるクエリを実行する場合は、SQL Server のリソースが必要ですが、メッセージの処理に使用されている可能性があります。

通常、BizTalk Serverの全体的な持続可能性に最も影響を与えるアクティビティの一覧を次に示します。

• ログ配布とバックアップ。 SQL Serverに関連するほとんどのディザスター リカバリー 計画の一環として、すべてのBizTalk Server グループ データベースに対してログ配布とバックアップを定期的に実行する必要があります。 詳細については、「BizTalk Server データベースのバックアップと復元」を参照してください。 「ログ配布」も参照してください。

• 追跡データのアーカイブと消去。 BizTalk Tracking (BizTalkDTADb) データベースには、全体的なログ配布とバックアップ計画に加えて、独自のアーカイブと消去の体制があります。詳細については、「 BizTalk 追跡データベースのアーカイブと消去」を参照してください。 BizTalk 追跡データベースからデータをアーカイブおよび削除できる速度は、特に重要です。追跡が使用中である場合は、通常、BizTalk 追跡データベースのアーカイブと削除がボトルネックとなるためです。

• システム クエリ。 API またはBizTalk Server管理コンソール UI を使用して、システムに対してさまざまな種類のクエリを実行すると、持続可能なパフォーマンスに影響します。

• MessageBox のメンテナンス。 処理が完了したメッセージとインスタンスをクリーンアップして MessageBox データベースを維持するBizTalk Serverのコア機能の一部である SQL ジョブは多数あります。 コア エンジンの一部として、これらのジョブを完了できる速度は、持続性を予測するときの主要な要素です。 これらのジョブとその役割の詳細については、「 BizTalk Server1 の保守」を参照してください。

• ソリューション展開アクティビティ。 新しいアプリケーションまたは既存のアプリケーションの新しいバージョンを展開、バインド、および開始すると、メッセージ ボックス データベースの新しいサブスクリプションの作成など、BizTalk に追加の負荷が加わります。 アプリケーションの展開後、処理されるメッセージがリソースに対して競合するので、既存のアプリケーションのパフォーマンスに影響が及びます。

  これらの各領域について、次のように質問する必要があります。これらのアクティビティの影響を最小限に抑えるための推奨事項は何ですか? たとえば、午前 3 時に実行する計画を立てるべきか。

計画内または計画外のシステムの障害への考慮

障害によるシステム パフォーマンスへの影響は広範であり、障害が発生したシステムによって異なりますが、最も一般的な影響は次のとおりです。

• フラッドゲート イベント。 システムが一定期間ダウンしている間、メッセージが蓄積され、後でシステムが再び使用可能になったときに、すべてのメッセージが一度に到着します。 たとえば、BizTalk で動作しているアプリケーションが MSMQ を介してメッセージを受信し、そのアプリケーションが一定期間ダウンしている間、取得を待機するメッセージがキューに蓄積されます。 アプリケーションを再び起動すると、大量のメッセージが一度に届いたように動作します。

• メッセージ バックログ。 メッセージの送信先であるシステムがダウンした場合、通常は、追加のリソースを使用する再試行サイクルが使用されます。 再試行サイクルが終了すると、通常、メッセージは保留されます。 ダウンしたシステムが再びオンラインで使用可能になると、フラッドゲート タイプのイベントが発生し、多数のメッセージが再開され、正常に送信されます。

  システムを設計および保証する場合は、スケジュールされた定期的なメンテナンスなど、すべての計画内の障害を必ず考慮する必要があります。 また、計画外の障害とその影響の分析について考慮することもお勧めします。

  発生する可能性のある障害の種類を特定し、リスク レベルの予測 (確率×重大度) によって順位付けし、よりリスクの高い障害の期間および影響 (フラッドゲート イベント、保留メッセージ量、バックログなど) を予測することにより、障害が発生した場合にも問題とならないシステム能力が明らかになります。 BizTalk Serverなどのストア アンド フォワードのメッセージング ベースの非同期システムは、計画的および計画外の停止に対処するのに十分な "ヘッドルーム" を処理するように設計する必要があります。

参照

エンジンの永続性と耐久性
フェーズごとのプロジェクト計画の推奨事項
維持可能な最大エンジン スループットの測定
維持できる最大の追跡スループットの測定
ソリューションの拡張
パフォーマンスのボトルネックの特定
エンジンのパフォーマンスおよび容量