Microsoft Dataverse のスケーラブルなカスタマイズ設計

注

これは、スケーラブルなカスタマイズ設計に関する一連の記事の最初の記事です。 このコンテンツは別々の記事に分かれていますが、スケーラブルなカスタマイズの設計に関する概念、問題、および戦略の一覧を示します。 各記事は、前の記事で確立された概念に基づいています。 オフラインで読む場合は、これらの記事を 1 つの PDF ドキュメントとしてダウンロードできます。 目次の [ PDF のダウンロード ] リンクを選択します。

このコンテンツは、Azure SQL を使用する Dataverse 標準 テーブルのみを参照します。 Dataverse エラスティック テーブルは Azure Cosmos DB であり、トランザクションはサポートされていません。 エラスティック テーブルの特性は異なります。 エラスティック テーブルの詳細

Dataverse は、要求を行うユーザーの応答時間と、他のユーザーのシステムの安定性と応答性の両方に影響する可能性がある、実行時間の長いアクティビティから自分自身とそのユーザーを保護します。

Dataverse ソリューションを実装する一部のユーザーが直面する課題は、これらの保護措置が有効になるとプラットフォームや基になる Microsoft SQL Server データベースがエラーをスローすることです。 これらのエラーは、プラットフォームがシステムへのリクエストを拡張できないか、誤って終了または制限していると解釈されることがよくあります。

このコンテンツは、これらの種類のほとんどの課題の真の根本的な原因を調査し、対処した経験に基づいています。 これらの記事では、プラットフォームがシステムに対するこれらの要求の影響から自身を保護する方法について説明し、カスタム実装がプラットフォーム内のブロックとトランザクションの使用への影響を理解していないことが原因で、この動作が最も多い理由について説明します。

このコンテンツでは、これらの種類の動作を回避するためにカスタム実装を最適化することで、プラットフォーム エラーを回避するだけでなく、結果としてパフォーマンスとエンド ユーザー エクスペリエンスを向上させる方法についても説明します。 適切な設計手法を提供し、回避する一般的なエラーを特定します。

課題

この領域の課題の調査と対処は、通常、特定の種類のエラーや症状がシステムに現れたときに開始されます。 多くの場合、これらのエラーと症状はプラットフォームの問題であると認識され、必要な修復手順は、通常、実行速度の遅い要求が報告されたエラーになる原因となるプラットフォームの制約を緩和することです。

実際には、プラットフォームの制約の一部を緩和することで短期的にエラーを回避できますが、これらの制約には正当な理由があり、実行時間の長すぎるアクションが他のユーザーやシステムのパフォーマンスに影響を与えないように設計されています。 エラーを回避するために制約を緩和できますが、ユーザーは応答時間が遅く、これらのパフォーマンスの問題はシステムの他のユーザーのエクスペリエンスにも影響します。

そのため、これらの制約がトリガーされ、エラーが発生する原因の根本原因を調べ、それらを回避するためにコードのカスタマイズを最適化することをお勧めします。 このアプローチにより、ユーザーにとって一貫性のある応答性の高いシステムが提供されます。

共通した現象

これらの種類の問題は、通常、次の表に示すように、一般的な症状の組み合わせを示します。

症状	Description
要求が遅い	特定のフォームやクエリなど、特定の領域でシステムの応答時間が遅い
一般的な SQL エラー	特定のアクションは、一般的な SQL エラーを報告するプラットフォーム エラーで応答します。 多くの場合、このエラーはプラットフォーム レイヤーで SQL タイムアウトに変換されます。
デッドロック	デッドロックが発生したことを報告するプラットフォーム エラー。これによって、アクションが強制終了され、ロールバックされます。
制限付きスループット	特にバッチ読み込みシナリオでは、多くの場合、達成されるスループットが遅く、可能な場合よりも遅くなります。
断続的なエラー/パフォーマンスの低下	これらの動作の重要な指標は、同じアクションが高速または非常に遅くなる可能性があり、再試行がはるかに迅速に動作するか、エラーを回避することです。

実際には、これらの症状の組み合わせは、これらの課題に直面したときにまとめて報告される可能性があります。 これらの症状が設計に関する問題の指標であるとは限りません。 データベースのディスク I/O 制限や製品のバグなど、他の問題も同様の症状を引き起こす可能性があります。 しかし、このような症状の最も一般的な原因であり、したがって確認する価値のあるものは、カスタム実装の設計と、それがシステムに与える影響に直接関係しています。

なぜ私たちは心配する必要がありますか? Dataverse がこれを処理してくれないのか…?

できる限り対応します… ただし、ロックとトランザクションを使用して、必要に応じて競合からシステムを保護します。

また、特定のシナリオに関する選択を行い、データへのアクセスを制御することが重要な場所を決定するためのオプションも提供します。 しかし、これらの選択は間違って行われる可能性があり、カスタム コードに意図しない結果が生じる可能性があります。 通常、これらの問題は応答時間が遅くなり、ユーザー エクスペリエンスに影響を与えるので、特定のアクションの影響を理解すると、ユーザーの一貫性と結果が向上する可能性があります。

原因の理解

一般的な症状により、特定の要求の実行速度が遅くなり、プラットフォームの制約がトリガーされます。 次の図は、これらの症状の一般的な根本原因の一部と一般的な症状を示しています。

実行時間の長いトランザクション、データベースブロック、複雑なクエリの根本的な影響は、すべて互いに重複し、それらの影響を増幅してこれらの症状を引き起こす可能性があります。 たとえば、互いに独立した一連の実行時間の長いクエリでは、ユーザーの応答時間が遅くなる可能性がありますが、同じリソースへのアクセスが必要な場合にのみ、応答時間が非常に遅くなり、エラーになります。

プラットフォーム制約の設計

Dataverse プラットフォームには、1 つのアクションがシステムの残りの部分やユーザーに影響を与えるのを防ぐために課す多くの意図的な制約があります。 この動作は、特定の要求の完了を妨げる可能性があり、制約を解除できるかどうかに関する質問につながることが多いため、不満を感じる可能性があります。広範な影響を考慮する場合、これはあまり良いアプローチではありません。

プラットフォームが意図したとおりに使用され、実装が最適化されている場合、これらの制約が発生するシナリオはまれです。 制約に直面することは、ほとんどの場合、システム内でリソースを過度に占有している動作を示しています。 これは、同じユーザーまたは他のユーザーからの他の要求を処理できないことを意味します。 そのため、ブロックされる要求の制約を緩和できる可能性もありますが、実際に意味するのは、消費しているリソースが、さらに長い間関連付けられ、他のユーザーに大きな影響を与えるということです。

これらの制約の中心にあるのは、Dataverse プラットフォームは、ユーザーの要求に迅速に対応することが優先されるトランザクションマルチユーザー アプリケーションをサポートするように設計されているという考え方です。 これは、実行時間の長い処理やバッチ処理のためのプラットフォームを意図したものではありません。 Dataverse に対して一連の短い要求を実行することはできますが、Dataverse はバッチ処理を処理するように設計されていません。 同様に、大規模な反復処理を実行するアクティビティがある場合、Dataverse はその反復処理を処理するようには設計されていません。

このようなシナリオでは、実行時間の長いプロセスをホストするために別のサービスを使用して、Dataverse 自体へのトランザクション要求を短くすることができます。 たとえば、Flow を使用するか、Microsoft SQL Server Integration Services (SSIS) を他の場所でホストし、個々の作成要求または更新要求を Dataverse に送る方が、プラグインを使用して Dataverse で作成されている何千ものレコードをループ処理するよりも優れたパターンです。

存在するプラットフォームの制約を認識して理解し、アプリケーション設計で許可できるようにする価値があります。 また、これらのエラーが発生した場合は、エラーが発生している理由と、それらを回避するために何を変更できるかを理解できます。

制約	Description
プラグインのタイムアウト	• プラグインは 2 分後にタイムアウトします。 • プラグインで実行時間の長い操作を実行しないでください。プラットフォームとサンドボックス サービスを保護し、最終的にはユーザー エクスペリエンスの低下からユーザーを保護します
SQL タイムアウト	• SQL Server への要求は通常 120 秒でタイムアウトしますが、場合によってはコマンドのタイムアウトが長くなる場合があります • 実行時間の長い要求から保護 • 特定の組織内およびそのプライベート データベース内の保護を提供します。 •また、プロセッサ/メモリなどの共有リソースの過剰な使用に対するデータベースサーバーレベルでの保護を提供します
ワークフローの制限	• 公正な利用ポリシーに基づく運用 • 特定のハード制限はありませんが、組織間でリソースのバランスを取ります • 需要が低い場合、組織は利用可能な容量を最大限に活用できます。 需要が高い場合は、リソースとスループットが共有されます。
最大同時接続数	• IIS の Web サーバー接続プールからデータベースへの接続の上限は、プラットフォームの既定の設定で 100 です。 Dataverse では、この値は変更されません。 •あなたがこれをヒットした場合、それはシステム内のエラーの兆候です。では、非常に多くの接続がブロックされている理由を見てみましょう。 • 通常の 10 ミリ秒 < のデータベースへの同時接続が 100 個ある複数の Web サーバーでは、Web サーバーごとに 10,000 > データベース要求のスループットが提案されます。 これは必須ではないはずであり、その前に他の課題に大きな打撃を及ぶだろう
ExecuteMultiple	• ExecuteMultiple メッセージは、外部ソースから Dataverse に送信される操作のコレクションを支援するように設計されています。 •これらの要求の大規模なグループの処理は、ユーザーによるより多くの応答クリティカルな要求を犠牲にして、Dataverseの重要なリソースを結び付けることができます。
サービス保護の制限	• すべてのユーザーに一貫した可用性とパフォーマンスを確保するために、API の使用方法にいくつかの制限を適用します。 これらの制限は、クライアント アプリケーションがサーバー リソースに対して特別な要求を行うタイミングを検出するように設計されています。 • 詳細情報: Service Protection API の制限

次のステップ

プラットフォームの制約がどのように適用されるかを理解するには、データベース トランザクションを理解する必要があります。 詳細情報: スケーラブルなカスタマイズ設計: データベース トランザクション