サービス保護 API 制限

この記事では、財務と運用アプリ サービスのサービス保護アプリケーション プログラミング インターフェイス (API) の制限について説明します。

財務と運用アプリ サービスの可用性とパフォーマンスを一貫させるため、Microsoft はサービス API の使用方法に制限を適用します。 これらの制限により、クライアント アプリケーションがサーバー リソースに対して特別な要求を行うときに、サービスが保護されます。 受信 API トラフィックが急増したり、サーバーに対して実行時間の長い要求が同時に発生したりすると、サーバー リソースが使い果たされる可能性があります。 これらの状態により、障害が発生したり、サービスの可用性とパフォーマンスに他の影響が及んだりする可能性があります。

制限は、対話型クライアントの通常のユーザーには影響しません。 これらは、特別な API 要求を実行するクライアント アプリケーションにのみ影響します。 この制限は、財務と運用プラットフォームの可用性とパフォーマンス特性を脅かす要求量のランダムで予期しない急増からの保護レベルを提供します。

クライアント アプリケーションへの影響

クライアント アプリケーションは、サービス保護 API 制限のエラーを管理する責任を負います。 エラーの管理方法は、アプリケーションの性質によって異なります。

対話型のクライアント アプリケーション

サービス保護制限は十分に高いため、対話型クライアントアプリケーションのユーザーが通常の使用中にそれらに遭遇することはめったにありません。 ただし、クライアント アプリケーションに一括操作が許可されている場合、ユーザーは制限に遭遇する可能性があります。 クライアント アプリケーション開発者は、サービス保護 API 制限がどのように適用されるかを認識し、ユーザーがサーバーに極端な要求を送信する可能性を減らすのに役立つ、ユーザー インターフェイス (UI) を設計する必要があります。 ただし、サービス保護 API 制限のエラーが発生する可能性が予想され、これらのエラーを処理できるよう準備しておく必要があります。

ユーザーが意図した対象者ではないため、クライアント アプリケーション開発者は、ユーザーがエラー メッセージを受け取るよう単にエラーをスローするべきではありません。 API 要求がサービス保護の制限を超えたときに、スロットル応答の管理に使用する具体的な戦略については、再試行操作を参照してください。

データ統合アプリケーション

財務アプリや運用アプリにデータを読み込んだり、一括データ操作を実行したりするアプリケーションでは、サービス保護 API の制限エラーを処理する必要があります。 これらのアプリケーションは、できるだけ早く作業を完了できるように、スループットに優先順位を付ける必要があります。 操作を再試行し、最大スループットを達成するための戦略が必要です。

詳細については、API スループットの最大化を参照してください。

匿名ユーザー

一部のアプリケーションは、サービス プリンシパル アカウントを介して匿名ユーザーから要求を送信します。 システムがユーザーごとに評価するサービス保護 API の制限では、アプリケーションがすべてのクライアント ユーザーに対して発生するトラフィックの量が原因で、これらのアプリケーションが制限に達する可能性があります。 対話型クライアント アプリケーションと同様に、ユーザーはサービス保護 API の制限エラーに関するメッセージを受信しないでください。 代わりに、UI はそれ以上の要求を無効にし、サーバーがビジー状態であるというメッセージを表示する必要があります。 メッセージには、アプリケーションが新しい要求の受け入れを開始する時刻を含む場合があります。

サービス保護 API 制限の実施

財務アプリと運用アプリには、ユーザーベースとリソースベースの 2 種類のサービス保護 API の制限があります。 ユーザー ベースの制限は、個々のユーザーまたは統合がシステムのパフォーマンスと可用性を低下させるのを防ぐのに役立ちます。 リソース ベースの制限は、高い環境リソース稼働率のしきい値を適用することにより、環境を保護するのに役立ちます。 高いしきい値に達すると、システムはサービス要求を制限します。

ユーザー ベースのサービス保護 API 制限

2 つのユーザーベースのサービス保護 API の制限では、評価に 5 分 (300 秒) のスライディング ウィンドウが使用されます。 上記の 300 秒間にいずれかの制限を超えた場合、後続の要求はサービス保護 API 制限エラーを返します。 このエラーは、 Retry-After 間隔 が終了するまでサービスを保護するのに役立ちます。

サービス保護 API の制限は、各ユーザーに適用されます。 認証された各ユーザーには、独立した制限があります。 特別な要求を行うユーザー アカウントのみが制限されます。 他のユーザーは影響を受けなくなります。

ユーザー ベースのサービス保護 API の制限は、次の 3 つの要因によって異なります。

• ユーザーが送信する要求の数
• ユーザーが送信する要求を処理するために必要な合計実行時間
• ユーザーが送信する同時要求の数

次の表では、 ユーザーごと、アプリケーション ID ごと、Web サーバーごとに適用される既定のユーザー ベースのサービス保護 API の制限について説明します。

環境で使用できる各 Web サーバーでは、サービス保護 API の制限が個別に適用されます。 ほとんどの環境には、複数の Web サーバーがあります。 ただし、試用版環境では、1 つの Web サーバーのみが割り当てられます。 複数の要因によって、マネージド 財務および運用アプリ サービスの一部として環境で使用できる Web サーバーの実際の数が決まります。 これらの要因の 1 つは、購入したユーザー ライセンスの数です。 環境で使用できる Web リソースの使用方法については、API スロットリングを監視するを参照してください。

API の使用状況を追跡し、サービス保護 API の制限を適用するために、環境内の各 Web サーバーは API 要求の調整キーを追跡します。 調整キーは、次の値を組み合わせたものになります。

• ユーザー – API 要求を行うユーザー。

  • アプリケーションがユーザー認証を使用して認証する場合、この値は API 要求を行うユーザーの Microsoft Entra ユーザー プリンシパルのオブジェクト ID です。
  • アプリケーション認証を使用してアプリケーションが認証される場合、この値は Microsoft Entra ID 内のアプリケーションのオブジェクト ID です。

• Application – Microsoft Entra IDのアプリ登録からのアプリケーションのクライアント ID。

API 要求に使用されるアクセス トークンは、これらの値を提供します。 たとえば、会社には、OData API を使用して財務および運用データに接続する Web アプリケーションである従業員ポータルがあります。 各従業員は、会社のメール アドレスとパスワードを使用して Web アプリにサインインします。 このシナリオでは、API 要求はユーザー オブジェクト ID とアプリケーション クライアント ID を使用して、サービス保護 API の制限に対する使用状況を追跡します。 アプリケーションの各ユーザーの API の使用状況は、個別に追跡、調節されています。 このシナリオでの認証フローの詳細については、承認 を参照してください。

アプリケーションがユーザー認証ではなくアプリ認証を使用して、ユーザーがアプリケーションにサインインしないようにする場合、調整キー ユーザーは Microsoft Entra ID のアプリケーションのオブジェクト ID です。 アプリケーション オブジェクト ID を検索する方法については、「Microsoft Entra ID のアプリケーション オブジェクトとサービス プリンシパル オブジェクトを参照してください。

リソース ベースのサービス保護 API 制限

ユーザー ベースのサービス保護 API の制限は、Web サーバーごとにユーザーごとに適用されます。 リソースベースのサービス保護 API の制限により、環境リソースの使用率に基づいてしきい値が適用されます。 ウェブサーバーリソースの総消費量がサービスのパフォーマンスと可用性を脅かすレベルに達した場合、リソースによりサービス要求が制限されます。 しきい値は、環境 Web サーバーでのメモリや CPU などのリソースの使用率に基づいて設定されます。 API 要求の実行時にサーバー リソースの使用率が定義されたしきい値を超えると、要求は調整され、"要求が多すぎます" 応答を受け取ります。

リソース ベースのサービス保護 API 制限は、ユーザー ベースの制限と連携し、リソースの過剰使用率を回避するのに役立つ保護設定として機能します。 これにより、システムの応答性を維持し、財務と運用アプリを実行する環境で一貫した可用性とパフォーマンスを実現できます。

リソース ベースのサービス保護 API 制限については、リソースのしきい値に達すると統合が調整される優先順序を定義できます。 詳細については、スロットリング優先度を参照してください。

サービス保護 API の応答

クライアント アプリケーションが特別な要求をする場合、財務と運用アプリ サービスは、要求が多すぎること示すエラーを返します。 このサービスは、 429 要求が多すぎる応答を返すことによって、オンライン サービスの一般的なパターンに従います。

429 要求過多の応答に関しては、サービス保護 API 制限ごとに特定のエラー メッセージが返されます。 このセクションでは、エラー メッセージと、それぞれについて可能な軽減策を説明します。

要求数

この制限は、上記の 300 秒間の要求の合計数をカウントします。 次のエラー メッセージが API 応答と共に返されます:

300 秒のタイム ウィンドウで、要求の数が 6000 の制限を超えました。

対話型アプリケーションの一般的なユーザーは、ユーザーが一括操作を実行できない限り、1 分あたり 1,200 件の要求を送信することで、この制限を超えるとは限りません。

たとえば、リスト ビューで一度に 250 個のレコードを選択でき、ユーザーが 1 回のアクションですべてのレコードに対して操作を実行できる場合、ユーザーはサービス保護 API の制限に達するまでに 300 秒以内に 24 回この操作を実行する必要があります。

アプリケーションがこの機能を提供する場合は、次の戦略のいずれかまたは両方を検討してください。

• リストで選択できるレコードの合計数を減らします。 リストに表示される項目の数が 50 に減った場合、ユーザーはこの操作を 300 秒以内に 120 回実行する必要があります。 つまり、ユーザーは 2.5 秒以内に各リストの操作を完了する必要があります。
• 選択した操作をバッチに結合させます。 バッチには最大 5,000 個の操作を含めることができるため、要求数の制限を回避できます。 ただし、実行時間制限に備えて準備してください。

実行時間

この制限は、上記の 300 秒間に受信する要求の実行時間の合計を追跡します。 API 応答は、次のエラー メッセージを返します。

300 秒のタイム ウィンドウで、受信する要求の実行時間の合計が 1200 秒の制限を超えました。 同時要求の数を減らすか、要求の期間を短くして、もう一度やり直してください。

一部の操作では、より多くのリソースを必要とするものもあります。 バッチ操作と非常に複雑なクエリは、非常に負荷がかかります。 同時要求でこれらの操作を同時に実行することもできます。 そのため、5 分以内に、合計計算時間が 20 分を超える操作を要求できます。

この制限は、バッチ処理と同時要求を使用する戦略が、要求数の制限を回避するのに使用される場合に発生する可能性があります。 バッチ操作でこのエラーが発生した場合、潜在的な軽減戦略として、操作を小さなバッチに分割し、異なるサービス プリンシパルを使用することで個々のバッチを同時に実行することができます。

同時要求

この制限はユーザーの同時要求の数を追跡します。 次のエラー メッセージが API 応答と共に返されます:

同時要求の数が 52 の制限を超えました。

クライアント アプリケーションでは、個別に連続して要求を送信することに限定されていません。 クライアントは、並行プログラミング パターンやさまざまな方法を適用して複数の要求を同時に送信できます。 同時要求の数の制限を超えた場合、エラーは API 応答と共に返されます。

スループットを最大化する戦略の重要な部分として同時要求を送信することができますが、この方法を使いすぎないようにしてください。 .NET で並行プログラミングが使用されると、既定の並列度は、コードを実行するサーバーの CPU コアの数に依存します。 この数値は 52 を超えないようにしてください。 ParallelOptions.MaxDegreeOfParallelism プロパティを設定して、同時タスクの最大数を定義できます。

リソース稼働率のしきい値

この制限は、サーバー リソースの累積稼働率のしきい値を追跡します。 次のエラー メッセージが API 応答と共に返されます:

システムのリソース稼働率が高いため、現時点ではこのリクエストを処理できませんでした。

このエラーは、必ずしも単一のユーザーまたは統合が問題の原因となっていることを示しているとは限りません。 代わりに、すべてのサービス統合における Web サーバー リソースの累積稼働率が、サービスのパフォーマンスと可用性を低下させるしきい値を超えたことを示します。 この場合、API スループットの最大化で説明した戦略などの、API 統合を最適化するための一般的な戦略が役立ちます。 加えて、API 統合のスロットリング優先度を定義したことを確認してください。

サービス保護制限に対する例外

サービス保護 API 制限は、すべての Microsoft サービスには適用されません。 現在、次のサービスは除外されています:

• ドキュメント回覧エージェント (DRA)
• 倉庫管理モバイル アプリ (WHSMobile)
• Retail Server API
• Office 統合
• データのインポート/エクスポート フレームワーク (DIXF)
• 定期統合
• データ インテグレーター
• 財務と運用アプリの Power Platform 仮想テーブル
• 財務と運用アプリ コネクタ

仮想テーブルの除外は、Microsoft Power Platform Finance and Operations アプリ との統合が有効になっている場合にのみ適用されます。 Finance and Operations アプリ環境で統合が有効になっていない場合、サービス保護 API の制限は仮想テーブルに適用されます。 統合が有効になっている場合、除外は、仮想エンティティ プラグインが呼び出す Finance and Operations アプリ API エンドポイントにのみ適用されます。 Finance and Operations アプリ サービスでは、要求が制限されません。 ただし、要求は Microsoft Dataverse API を介して行われるため、 サービス保護 API の制限 が引き続き要求に適用される場合があります。

現在、これらのサービスは制限の対象外となっていますが、サービス保護制限の実装を優先しています。 通知は変更前に提供され、これらのサービスの除外が削除されるとドキュメントが更新されます。

在庫可視化アドイン などの、財務と運用 OData やカスタム サービス API を使用しないサービスは、控除は必要ないため、調節は適用されません。 サービス保護 API の制限は、財務と運用 OData とカスタム サービス API エンドポイントにのみ適用されます。 これらのエンドポイントを使用しないサービスは、調節に影響されません。