Microsoft Graph 調整ガイドMicrosoft Graph throttling guidance

調整とは、リソースの使いすぎを防ぐために、サービスの同時呼び出し数を制限することをいいます。Microsoft Graph は、大量の要求を処理できるよう設計されています。過剰な数の要求が発生した場合、調整を行うことは Microsoft Graph サービスの最適なパフォーマンスと信頼性の維持に役立ちます。Throttling limits the number of concurrent calls to a service to prevent overuse of resources. Microsoft Graph is designed to handle a high volume of requests. If an overwhelming number of requests occurs, throttling helps maintain optimal performance and reliability of the Microsoft Graph service.

制限の調整はシナリオによって異なります。たとえば、大量の書き込みを行う際には、読み込みのみを行う場合に比べて調整が起こる可能性は高くなります。Throttling limits vary based on the scenario. For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

調整が発生すると、何が起こるのでしょうかWhat happens when throttling occurs?

調整のしきい値を超えた場合、Microsoft Graph はそのクライアントの以降の要求を一定時間制限します。調整が発生した場合、Microsoft Graph は HTTP ステータス コード 429 (Too Many Requests) を返し、要求は失敗します。失敗した要求の応答ヘッダーで、推奨される待機時間を返します。調整の動作は要求の種類と数によります。たとえば、大量の要求があれば、すべての種類の要求が調整されます。しきい値は要求の種類によって異なります。そのため、書き込みは調整を受けるが、読み込みはそのままで許容されるシナリオが起こりえます。When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. A suggested wait time is returned in the response header of the failed request. Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.

一般的な調整のシナリオCommon throttling scenarios

クライアントに対して調整が発生する最も一般的な原因は次のとおりです。The most common causes of throttling of clients include:

  • あるテナントのすべてのアプリケーションから大量の要求がある。A large number of requests across all applications in a tenant.
  • すべてのテナントで、特定のアプリケーションから大量の要求がある。A large number of requests from a particular application across all tenants.

調整に対応するためのベスト プラクティスBest practices to handle throttling

調整に対応するためのベスト プラクティスには、次のようなものがあります。The following are best practices for handling throttling:

  • 要求あたりの操作の数を減らす。Reduce the number of operations per request.
  • 呼び出しの頻度を減らす。Reduce the frequency of calls.
  • すべての要求が使用量の制限に計上されるため、即時の再試行を避ける。Avoid immediate retries, because all requests accrue against your usage limits.

エラー処理を実装する場合は、HTTP エラー コード 429 を使用して調整の発生を検出します。失敗した要求への応答ヘッダーには、Retry-After フィールドが含まれています。Microsoft Graph はクライアントが調整による制限を受けている間でもリソースの使用量を記録しています。そのため、Retry-After の指示に従って要求を遅延させることが最も迅速に調整を解消できる方法です。When you implement error handling, use the HTTP error code 429 to detect throttling. The failed response includes the Retry-After field in the response header. Backing off requests using the Retry-After delay is the fastest way to recover from throttling because Microsoft Graph continues to log resource usage while a client is being throttled.

  1. Retry-After フィールドに指定された秒数だけ待機してください。Wait the number of seconds specified in the Retry-After field.
  2. 要求を再試行してください。Retry the request.
  3. 要求が再度エラーコード 429 で失敗した場合は、依然として調整を受けています。Retry-After で推奨された遅延に引き続き従い、成功するまで再試行してください。If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended Retry-After delay and retry the request until it succeeds.

現在、次のリソースで Retry-After ヘッダーが提供されています。The following resources currently provide a retry-after header:

Microsoft Cloud における調整についてのより幅広い議論については「調整パターン」を参照してください。For a broader discussion of throttling on the Microsoft Cloud, see Throttling Pattern.