スケーラブル カスタマイズ設計:同時実行の問題

注意

これはスケーラブル カスタマイズ設計に関する 3 つめのトピックです。 最初から始めるには、Microsoft Dataverse におけるスケーラブル カスタマイズ設計 を参照してください。 前のトピック スケーラブル カスタマイズ 設計: データベース トランザクション ではデータベース トランザクションが適用される方法、およびそれらがさまざまな種類のカスタマイズに与える影響について説明しました。

同時実行の要求がある場合は、ロックで衝突する可能性が高くなります。 トランザクションに時間がかかるほどロックが長く保持されます。 衝突の可能性がさらに高まり、エンドユーザーの全体的な影響は大きくなります。

アクティビティがアプリケーションで駆動する複数の方法についても認識する必要があり、システム内の他のアクションと競合する可能性があるそれぞれにロックをかけています。 このような場合、ロックは同じデータに対して重複するアクションが発生したときに発生するデータの不整合を防止します。

設計を検討し問題があるか確認するために重要な領域は下記です:

• ユーザー駆動の活動: 直接ユーザーインターフェイスを介して。
• 非同期の操作: 他のアクションの結果として後に発生する活動。 この活動がいつ処理されるかは、開始アクションがトリガーされた時点では不明です。
• バッチ 活動: 一括削除ジョブやサーバー側の同期処理などの Dataverse、または他のシステムからの統合などの外部ソースからのいずれかで駆動されます。

並行処理される非同期操作

よくある誤解は、非同期のワークフローまたはプラグインはキューから連続的に処理され、それらの間に競合は生じないということです。 Dataverse は、各非同期サービス インスタンス内でも、スループット向上のため異なるサーバーに分散した非同期サービスインスタンス間でも、同時に複数の非同期活動を並列処理するため、これは正確ではありません。 各非同期サービスは、構成と負荷に基づいてサービスごとに約 20 のバッチで実行されるジョブを実際に取得します。

同じレコードの同じイベントから複数の非同期活動を開始した場合、それらは並行して処理される可能性があります。 それらが同じレコードで開始したとき、共通のパターンは同じ親レコードに戻って更新されます; そのため競合する機会が高いです。

アカウントの作成などトリガーとなるイベントが発生すると、Dataverse の非同期ロジックは各プロセスまたは行われる操作ごとに 非同期処理 (システム ジョブ) エンティティ にエントリを作成する場合があります。 非同期サービスはこのテーブルを監視し、待機中の要求をバッチとして取得して処理します。 ワークフローは同時にトリガーされるため、同じバッチに取得され同時に処理される可能性が非常に高いです。

トランザクションの理解が重要な理由

スケーラブルなカスタマイズを設計するときに 自動付番の例 はデータベース トランザクションと同時実行の問題を考慮する方法を示すシナリオを提供します。

シリアル化とタイムアウト

高度なシリアル化とは通常、ブロックをタイムアウトと貧弱なスループットに変えるものです。 多数の同時実行要求がある場合にそれらがシリアル化されて処理に時間がかかると、各要求の順番待ちが長くなりタイムアウトやエラーが発生してしまいます。

プラグインのタイムアウトは開始されたときから始まります。 SQL タイムアウトはデータベース要求で計算されるため、クエリ ブロックが長時間待機するとタイムアウトになる可能性があります。

一連の操作

直接トリガーされた活動で特定のクエリを理解するとともに、関連する一連のイベントがどこで発生するのかを検討することも必要です。

プラグインまたは同期ワークフローのステップとして作成された各メッセージ要求は、直接操作をトリガーするだけでなく、他の同期プラグインやワークフローを起動させる可能性もあります。 これらの同期活動それぞれは同じトランザクションで発生し、そのトランザクションと保持されたすべてのロックの寿命を、認識よりはるかに長く延長する可能性があります。

全体的な影響は最初の認識よりはるかに大きい可能性があります。 これは複数人で実装を構築した場合や、または時間をかけて拡張した場合に、意図せず頻繁に発生する可能性があります。

プラットフォームの制約に遭遇

これがプラットフォーム制約が生じる可能性がある場所です。 そして実際にこの種の振る舞いからまさに広大なシステムを保護するために制約が存在します。

このレベルの処理遅延が発生するたびに、システムの他の領域と他のユーザーに対して意図しない結果が生じます。 したがって、この種の活動がシステム パフォーマンスを妨げるのを防ぐことが重要です。

そのエラーを回避する安易な方法はプラットフォーム制約の緩和ですが、これは全体的なスケーラビリティとシステムのパフォーマンスに対するより根本的な影響に対処するものではありません。 そもそもこれは制約をトリガーする動作を修正および防止することで対処する必要があります。

使用の影響

使用にも影響することが多いのは、この動作の連鎖的な一連の影響です。

最初の問題はロックであり、したがってシステム内のブロックです。 これはユーザー応答時間の遅延につながり、多くの場合システムの特定の領域で、予測不能で信頼できないユーザーの応答時間に増幅されます。

極端なケースや通常の負荷より重い場合、これはバックグラウンドのバッチ処理でのスループット低下として現れる可能性があります。 結局それはすべてシステムで発生するエラーに拡大する可能性があります。

SQL タイムアウト エラーを調査するときは、ユーザーが貧弱で予測不能な応答時間も報告しており、関連する問題としてこれらの間で接続が確立されていないのが一般的です。

次のステップ

パフォーマンスの問題を最小限に抑えるために適用（または回避）できる設計パターンの理解。 詳細: スケーラブル カスタマイズ設計: トランザクション設計パターン

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。