注
これは、スケーラブルなカスタマイズ設計に関する一連のトピックの 3 番目です。 最初に、「 Microsoft Dataverse のスケーラブルなカスタマイズ設計」を参照してください。 前のトピック 「スケーラブルなカスタマイズ設計: データベース トランザクション 」では、データベース トランザクションの適用方法と、それらがさまざまな種類のカスタマイズに与える影響について説明しました。
同時実行の要求がある場合は、ロックで衝突する可能性が高くなります。 トランザクションにかかる時間が長ければ長いほど、ロックが保持される時間が長くなります。 衝突の可能性はさらに高く、全体的な影響はエンド ユーザーに大きくなります。
また、アクティビティをアプリケーションに対して実行できる複数の方法にも注意する必要があります。各方法では、システム内の他のアクションと競合する可能性があるロックが適用されます。 このような場合、ロックによって、同じデータに対して重複アクションが発生したときに発生するデータの不整合が防止されます。
設計を検討し、問題が発生したかどうかを確認する重要な領域を次に示します。
- ユーザー 主導のアクティビティ: ユーザー インターフェイスを直接使用します。
- 非同期アクション: 他のアクションの結果として後で発生するアクティビティ。 このアクティビティが処理されるタイミングは、開始アクションがトリガーされた時点では認識されません。
- バッチ アクティビティ: 一括削除ジョブやサーバー側同期処理など、Dataverse 内から実行されるか、別のシステムからの統合などの外部ソースから駆動されます。
並行処理される非同期操作
一般的な誤解は、非同期ワークフローまたはプラグインがキューから順次処理され、それらの間に競合が発生しないということです。 Dataverse は、各非同期サービス インスタンス内と異なるサーバーに分散された非同期サービス インスタンス間の両方で複数の非同期アクティビティを並列で処理してスループットを向上させるので、これは正確ではありません。 各非同期サービスは、実際には、構成と負荷に基づいて、サービスごとに約 20 のバッチで実行されるジョブを取得します。
同じレコードで同じイベントから複数の非同期アクティビティを開始すると、並列で処理される可能性があります。 それらが同じレコードで開始したとき、共通のパターンは同じ親レコードに戻って更新されます; そのため競合する機会が高いです。
アカウントの作成などのトリガー イベントが発生すると、Dataverse の非同期ロジックによって、実行されるプロセスまたはアクションごとに AsyncOperation (システム ジョブ) エンティティ にエントリが作成される場合があります。 Async Service は、このテーブルを監視し、待機中の要求をバッチで選択し、処理します。 ワークフローは同時にトリガーされるため、同じバッチで取得され、同時に処理される可能性が高くなります。
トランザクションを理解することが重要な理由
自動番号付け例では、スケーラブルなカスタマイズを設計するときに、データベース トランザクションとコンカレンシーの問題を考慮する必要がある方法を示すシナリオを示します。
シリアル化とタイムアウト
通常、高度なシリアル化は、ブロックをタイムアウトと低スループットに変えます。 同時要求が多数ある場合、それらがシリアル化され、処理に時間がかかると、タイムアウトが発生し始めてエラーが発生するまで、各要求の時間が長くなり、時間がかかります。
プラグインのタイムアウトは、開始された時点から開始されます。 SQL タイムアウトはデータベース要求で計算されるため、クエリが長時間待機をブロックすると、タイムアウトする可能性があります。
アクションの連鎖
直接トリガーされるアクティビティの特定のクエリを理解するだけでなく、関連するイベントのチェーンが発生する可能性がある場所も考慮する必要があります。
プラグインまたは同期ワークフローのステップとして行われた各メッセージ要求は、直接アクションをトリガーするだけでなく、他の同期プラグインやワークフローが起動する可能性もあります。 これらの各同期アクティビティは同じトランザクションで発生し、そのトランザクションの有効期間が延長され、保持されているロックは実現できるよりもはるかに長くなる可能性があります。
全体的な効果は、最初に実現されたよりもはるかに大きくなる可能性があります。 これは、多くの場合、複数のユーザーが実装を構築している場合や、時間の経過と同時に進化する場合に、意図せずに発生することがあります。
プラットフォーム制約に直面する
ここでプラットフォームの制約を受けることができます。 実際には、この種の動作は、より広範なシステムを保護するために制約が存在するのとまったく同じものです。
このレベルの処理の遅延が発生するたびに、システムの他の領域や他のユーザーに意図しない結果が生じます。 そのため、この種のアクティビティがシステムのパフォーマンスを妨げるのを防ぐことが重要です。
エラーを回避する簡単な方法はプラットフォームの制約を緩和することですが、これはシステムの全体的なスケーラビリティとパフォーマンスに対するより基本的な影響には対処しません。 これは、最初に制約をトリガーする動作を修正して防ぐことで対処する必要があります。
使用状況への影響
また、多くの場合、使用に影響を与えるのは、この動作の連鎖的な一連の影響です。
最初の問題はロックであるため、システムでブロックされます。 これにより、ユーザーの応答時間が遅くなり、予測不能で信頼性の低いユーザー応答時間として増幅されます。多くの場合、システムの特定の領域で発生します。
極端な場合、または通常の負荷よりも重い場合は、スループットが低いバックグラウンドバッチ処理でこれが表示される可能性があります。 最終的には、すべてがシステムで発生するエラーにエスカレートする可能性があります。
SQLタイムアウトエラーを調査している際、ユーザーは応答時間が遅く予測できないことを報告することが多いですが、これらを関連する問題として結びつけることが行われていないのが一般的です。
次のステップ
パフォーマンスの問題を最小限に抑えるために適用 (または回避) できる設計パターンについて説明します。 詳細情報: スケーラブルなカスタマイズ設計: トランザクション設計パターン