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

注意

これはスケーラブル カスタマイズ設計に関する 1 つめの記事です。 この内容は個別の記事に分かれていますが、スケーラブル カスタマイズの設計に関する概念、問題、および戦略の全体像を示します。 各記事の内容は、先行の記事で説明された概念に基づいています。 データをオフラインで読みたい場合は、これらの記事を単一の PDF 文書として記事をダウンロード できます。 目次で PDF をダウンロード リンクを選択します。

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

Dataverse は、要求を行っているユーザーに対する応答時間およびシステムの安定性と応答性の両方に影響を与える可能性のある長時間実行中の活動から、ユーザーやシステム自体を保護します。

Dataverse のソリューションを実装している一部のユーザーが直面する課題として、これらの保護対策が実施された場合にプラットフォームや基盤となる Microsoft SQL Server データベースによってスローされるエラーがあります。 これらのエラーは、多くの場合、プラットフォームが拡張できない、不正な終了、システムへの要求のスロットリングとして解釈されます。

この内容は、このようなほとんどの主要な課題について根本的な原因を調査し、解決してきた経験に基づいています。 以下の記事では、システムに対するこのれらの要求からプラットフォームが自身を保護する方法を説明します。さらに、ほとんどの場合において、この動作がプラットフォーム内でブロックおよびトランザクションを使用することの影響を理解していないカスタム実装の結果として生じている理由について説明します。

また、このような動作を回避するためにカスタム実装を最適化することが、プラットフォーム エラーを回避するだけでなく、結果的にパフォーマンスの向上とユーザー エクスペリエンスの向上につながることについても説明します。 優れた設計のプラクティスを示し、回避すべき一般的なエラーを特定します。

課題

特定の種類のエラーや現象がシステム内で発生する場合は、一般的にこの領域で課題を調査し解決することから始めます。 これらのエラーと症状はプラットフォームの問題であると認識されます。必要な救済ステップは、通常、報告対象となる時間のかかる要求をトリガーするプラットフォームの制約を緩和することです。

実際に、プラットフォームの制約の一部を緩和することでエラーを短期的に回避できます。ただし、これらの制約にはもっともな理由があり、非常に時間のかかるアクションが別のユーザーやシステム パフォーマンスに影響することを防ぐために設計されています。 制約を緩和してエラーを回避できますが、それでもこのユーザーにとっての応答時間が遅くなり、これらのパフォーマンスの問題がシステムのほかのユーザーのエクスペリエンスにも影響します。

したがって、なぜ制約がトリガーされてエラーを引き起こしているのか、その根本的な原因を調べてから、コードのカスタマイズを最適化して回避することが推奨されます。 このアプローチは、一貫性と応答性の優れたシステムをユーザーに提供します。

共通した現象

次の表に示すように、これらの種類の問題には共通した現象がみられます。

現象	説明
時間のかかる要求	ユーザーは、システムの特定の領域 (特定のフォームやクエリなど) で応答時間が遅いことを認識します
一般的な SQL エラー	特定のアクションは、一般的な SQL エラーを報告するプラットフォーム エラー レポートで応答します。 ほとんどの場合、このエラーはプラットフォーム層で SQL タイムアウトに変換します。
デッドロック	アクションを強制的に終了してロールバックするデッドロックが発生したことを報告するプラットフォーム エラーです。
制限付きスループット	特にバッチの読み込みシナリオにおいて、比較的遅いスループットが見られます。
間欠的エラー / パフォーマンスの低下	このような動作の重要なインジケーターは、同じアクションの処理速度が速い、または極めて遅い場合は、再試行してより速く動作するか、エラーを回避します

実際、問題の発生時には、これらの現象が組み合わせて発生し、まとめて報告されます。 これらの現象が必ずしも設計の問題を示すわけではありません。 データベースのディスク I/O 操作の制限や製品のバグなど、そのほかの問題により、同様の現象が発生する可能性があります。 ただし、これらの現象の最も一般的な原因であるため、カスタム実装の設計との直接的な関係とシステムへの影響について確認する価値はあります。

なぜ心配する必要があるのですか。Dataverse が対応してくれるのではないのですか…?

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

マイクロソフトでは、データへのアクセス制御が重要な場合に、特定のシナリオについて選択して決定できるオプションも提供しています。 ただし、間違った選択により、カスタム コードに意図しない結果が生じる可能性があります。 通常これらの問題では、長い応答時間がユーザー エクスペリエンスに影響します。そのため、特定のアクションの影響を把握することで一貫性が向上し、結果的にユーザー エクスペリエンスも向上します。

原因の詳細

一般的な現象が原因で、特定の要求の実行速度が強制的に遅くなり、これによりプラットフォームの制約がトリガーされます。 次の図は、これらの現象の一般的な根本原因の一部により発生する典型的な現象を示します。

長い時間のかかるトランザクション、データベースのブロック、複雑なクエリの潜在的な影響として、互いにオーバーラップしてこれらの現象の原因となる悪影響を増幅させる可能性があります。 たとえば、互いに独立した時間のかかるクエリが連続してある場合、ユーザーの応答時間が遅くなることがあります。これらのクエリが一度だけ同じリソースにアクセスする必要がある場合、応答時間は非常に遅くなりエラーになります。

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

Dataverse プラットフォームには、1 つのアクションがシステム、そしてユーザーに有害な影響を与えることを防ぐために、意図的に課すことのできる多くの制約があります。 この動作によりが特定の要求をブロックでき、制約を外すことができるかどうかという疑問につながることが多いため、いらだたしく感じられることがあります。これは、幅広く影響を及ぼしたい場合は適切なアプローチではありません。

プラットフォームが目的どおりに使用されて実装が最適化されている場合、これらの制約があるシナリオがあることはまれです。 制約を課す状態は、システム内のリソースを過度に縛り付ける動作を示すことがほとんどです。 これは、同じユーザーまたは他のユーザーからの別の要求を処理できないことを意味します。 そのため、ブロックしている要求の制約を緩めることはできても、実際にはその要求が使用しているリソースはより長い時間縛り付けられるため、他のユーザーにより大きな影響が及ぶことになります。

このような制約のため、ユーザーの要求への迅速な応答が重要度な場合に、トランザクション タイプのマルチユーザー アプリケーションをサポートするように Dataverse プラットフォームが設計されています。 長い時間のかかる処理やバッチ処理のためのプラットフォームではありません。 Dataverse は一連の短い要求を管理できますが、Dataverse はバッチ処理を扱うようには設計されていません。 同様に、大量の反復処理を実行する活動がある場合、Dataverse はこのような反復処理を扱うように設計されていません。

次のシナリオでは、個別のサービスを使用して長い時間のかかるプロセスをホストし、短いトランザクション要求は Dataverse で管理します。 たとえば、ほかの場所でフローを使用したり、Microsoft SQL Server Integration Services (SSIS) をホストして、個々の作成要求や更新要求を Dataverse で管理するパターンのほうが、Dataverse で作成される何千ものレコードをプラグインを使用してループするよりも適しています。

存在しているプラットフォームの制約をアプリケーションの設計で考慮できるためには、それらの制約を認識して理解することが大切です。 また、このようなエラーが発生した場合は、発生した原因を理解して発生しないように変更することができます。

制約	Description
プラグインのタイムアウト	• プラグインは 2 分後にタイムアウトします。 • プラグインでは長時間の操作を実行しないでください。劣悪なユーザー エクスペリエンスからプラットフォーム、サンドボックス サービス、そして最終的にはユーザーを保護します
SQL のタイムアウト	• SQL Server へのリクエストは通常​​ 120 秒でタイムアウトしますが、コマンドのタイムアウトがそれより長くなる場合もあります • 長い時間のかかる要求から保護します • 特定の組織内およびそのプライベート データベース内での保護を提供します。 • また、プロセッサやメモリなどの共有リソースの過度な使用に対する保護をデータベース サーバー レベルで提供します。
ワークフローの制限	• 公平に使用するポリシーで実行 • 特定の厳しい制限はないが、組織内でリソースを均等化 • 要求が少ない場合、組織は使用可能なキャパシティを最大限に利用できます。 要求が多い場合、リソースとスループットは共有されます。
同時接続の最大数	• IIS の Web サーバー接続プールからデータベースへの接続プールの上限は 100 接続というプラットフォームの既定の接続があります。 Dataverse はこの値を変更しません。 • これに遭遇した場合、これはシステム内のエラーを示します。多くの接続がブロックされている理由を調べてください。 • 複数の Web サーバーでは、各サーバーが一般的な < 10m s のデータベースに対して使用する同時接続は 100 接続です。これは各 Web サーバーの > 10k データベース要求のスループットを示します。 これは必須ではなく、それよりも前にほかの問題が発生します
ExecuteMultiple	• ExecuteMultiple メッセージは、外部ソースから Dataverse にまとめて送信される操作を支援するように設計されています。 • これらのリクエストの大規模なグループの処理は、ユーザーによるより多くの応答の重要なリクエストを犠牲にして、Dataverse の重要なリソースを拘束する可能性があります。
サービス保護の制限	• すべてのユーザーに一貫した可用性とパフォーマンスを確実に提供するために、API の使用方法にいくつかの制限を適用します。 これらの制限は、クライアント アプリケーションがサーバー リソースに対して異常な要求を行っていることを検出するように設計されています。 • 詳細: サービス保護の API 制限

次の手順

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

注意

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

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