Table of contents

スロットル ガイダンス | Graph API の概念Throttling guidance | Graph API concepts

Pat Altimore|最終更新日: 2018/06/19
2 投稿者

Azure Active Directory のリソースにアクセスするには、Azure AD Graph API ではなく Microsoft Graph を使用することを強くお勧めします。We strongly recommend that you use Microsoft Graph instead of Azure AD Graph API to access Azure Active Directory resources.現在は Microsoft Graph を中心にして開発が進められており、Azure AD Graph API の今後の機能強化は予定されていません。Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API.Azure AD Graph API の使用が適切である場合もありますが、非常にまれです。詳細については、Office Dev Center の Microsoft Graph または Azure AD Graph ブログの記事をご覧ください。There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the Microsoft Graph or the Azure AD Graph blog post in the Office Dev Center.

スロットルとはWhat is throttling?

スロットルとは、サービスの同時呼び出しの数に対する制限で、リソースの過剰な使用を防止します。Throttling limits the number of concurrent calls to a service to prevent overuse of resources.Azure Active Directory (AD) Graph は、非常に膨大な量の要求を処理するように設計されています。Azure Active Directory (AD) Graph is designed to handle a very high volume of requests.要求数があまりに多くなった場合は、スロットルによって Azure AD Graph サービスの最適なパフォーマンスと信頼性が維持されます。In the event of an overwhelming number of requests, throttling helps maintain optimal performance and reliability of the Azure AD Graph service.

スロットルの制限は、状況によって異なります。Throttling limits vary based on the scenario.たとえば、テナントに膨大な量の書き込みを実行している場合は、読み取りのみを実行している場合よりも、スロットルが大きいかもしれません。For example, if you are performing a large volume of writes to your tenant, the possibility for throttling is higher than if you are only performing reads.

スロットルが発生した場合の動作What happens when throttling occurs?

スロットルのしきい値を超過すると、スロットルが有効な間、Azure AD Graph がそのクライアントからのその後の要求を制限します。When a throttling threshold is exceeded, Azure AD Graph limits any further requests from that client while the throttle is in effect.スロットルが発生すると、Azure AD Graph は HTTP 状態 コード 429 ("要求が多すぎます") を返し、要求は失敗します。When throttled, Azure AD Graph returns HTTP status code 429 ("Too many requests"), and the requests fail.スロットルの動作は、要求の種類と数によって異なります。Throttling behavior can be dependent on the type and number of requests.たとえば、非常に大量の要求がある場合は、すべての要求の種類がスロットルの対象になります。For example, if you have a very 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:

  • 1 つのテナントにあるすべてのアプリケーションによる要求数が大量である。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

  • 要求あたりの操作の数を減らす。Reduce the number of operations per request.
  • 呼び出しの頻度を減らす。Reduce the frequency of calls.
  • HTTP エラー コード 429 で要求が失敗する場合は、Retry-After 応答ヘッダー フィールドで指定されている秒数を待機してから、要求を再試行します。When requests fail with a HTTP error code 429, wait the number of seconds specified in the Retry-After response header field and retry the request.

エラー処理を実装している場合は、HTTP エラー コード 429 を使用してスロットルを検出します。When implementing error handling, use the HTTP error code 429 to detect throttling.失敗の応答には、応答ヘッダーに Retry-After フィールドがあります。The failed response will include the Retry-After field in the response header.

  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.

クライアントがスロットル対象になっている間、AAD Graph はリソース使用状況の記録を続けるため、Retry-After の延期期間を使用して要求を取り下げるのが、スロットルから回復する最も早い方法です。Backing off requests using the Retry-After delay is the fastest way to recover from throttling because AAD Graph continues to log resource usage while a client is being throttled.使用制限はすべての要求に適用されるため、すぐに再試行することは避けてください。You should avoid immediate retries since all requests accrue against your usage limits.

Microsoft Cloud でのスロットルの詳細な情報については、「Throttling Pattern」 (スロットルの調整) を参照してください。For a broader discussion of throttling on the Microsoft Cloud, see Throttling Pattern.

© 2018 Microsoft