サービス保護 API 制限

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

財務と運用アプリ サービスの可用性とパフォーマンスを一貫させるため、Microsoft はサービス API の使用方法に制限を適用します。 これらの制限は、クライアント アプリケーションがサーバー リソースに対して特別な要求を行う場合に、サービスを保護するためのものです。 突発的に発生する受信 API トラフィックが多かったり、サーバーに対して同時に実行時間の長い要求を行った場合、サーバー リソースが消耗し、サービスの停止、またはその可用性やパフォーマンスに影響を与える可能性があります。

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

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

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

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

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

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

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

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

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

匿名ユーザー

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

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

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

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

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

サービス保護 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 です。

• アプリケーション – 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 サーバー リソースの総消費量がサービスのパフォーマンスと可用性を低下させるレベルに達すると、サービス要求を調整します。 しきい値は、環境 Web サーバーでのメモリや CPU などのリソースの使用率に基づいて設定されます。 API 要求が行われたときにサーバー リソースの稼働率が定義済みのしきい値を超えると、要求は調整され、「要求が多すぎます」という応答が表示されます。

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

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

サービス保護 API の応答

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

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

要求数

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

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

対話型アプリケーションの一般的なユーザーが、1 分あたり 1,200 の要求を送信してこの制限を超えることは、アプリケーションがユーザーに一括操作の実行を許可しない限り、想定されていません。

たとえば、リスト ビューで一度に 250 件のレコードの選択が可能で、ユーザーが 1 回の操作ですべてのレコードに対して操作を実行できる場合、ユーザーは 300 秒以内にこの操作を 24 回実行しなければ、サービス保護 API 制限には達しません。

アプリケーションでこの機能を提供する場合は、次の戦略の一つまたは両方を考慮する必要があります:

• リストで選択できるレコードの合計数を減らします。 リストに表示される品目の数が 50 に減らされた場合、ユーザーは 300 秒以内にこの操作を 120 回実行する必要があります。 つまり、ユーザーは各リストの操作を 2.5 秒以内で完了する必要があります。
• 選択した操作をバッチに結合させます。 1 つのバッチに 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 と財務と運用アプリの統合が有効になっている場合にのみ適用されます。 サービス保護 API 制限は、財務と運用アプリ環境で統合が有効になっていない場合に、仮想テーブルに適用されます。 統合が有効な場合、仮想エンティティ プラグインによって呼び出された財務と運用アプリ API エンドポイントにのみ控除が適用されます。 財務と運用アプリ サービスは、要求を調整しません。 ただし、要求が Microsoft Dataverse API を介して行われた場合、サービス保護 API 制限 が引き続き要求に適用される場合があります。

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

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