SharePoint Online での調整またはブロックを回避する

ここでは、SharePoint Online の調整を説明し、調整とブロックを回避する方法を検討します。

次のような流れを経験したことはないでしょうか。 たとえば、SharePoint Online でファイルをスキャンするなど、アプリケーションを実行していますが、調整が行われます。 さらに悪いことに、ブロックされます。 何が起こっているのでしょうか、それを止めるするために何ができますか?

調整とは

SharePoint Online は、SharePoint Online サービスの最適なパフォーマンスと信頼性を維持する目的で調整を使用します。 調整では、リソースの過剰使用を防ぐために、期間内の API 呼び出しまたは操作の数が制限されます。

SharePoint Online で調整が発生する状況

使用制限を超えると、SharePoint Online は、そのクライアントからのそれ以降の要求を短期間抑制します。

ユーザーがブラウザーで直接実行する要求の場合、SharePoint Online はユーザーを調整情報のページにリダイレクトし、要求は失敗します。

Microsoft Graph、CSOM、REST 呼び出しなど、アプリケーションが行う要求の場合、SharePoint Online は HTTP 状態コード 429 ("要求が多すぎます") または 503 ("Server Too Busy") を返し、要求は失敗します。

  • HTTP 429 は、呼び出し元アプリケーションが時間枠内に送信した要求の数が多すぎて、所定の制限を超えたことを示します。
  • HTTP 503 は、サービスが要求を処理する準備ができていないことを示します。 一般的な原因は、サービスで一時的な負荷の急増が発生していることです。

どちらの場合も、Retry-After ヘッダーが応答に含まれ、呼び出し元のアプリケーションが再試行または新しい要求を行う前に待機する時間を示します。 スロットルされたリクエストは使用制限にカウントされるため、Retry-After を尊重しないと調整が増える可能性があります。

問題のあるアプリケーションが引き続き使用制限を超えている場合、SharePoint Online はアプリケーションまたはアプリケーションからの特定の要求パターンを完全にブロックする可能性があります。 この場合、アプリケーションは HTTP ステータス コード 503 を取得し続け、Microsoft は Office 365 メッセージ センターのブロックをテナントに通知します。

ユーザー調整

調整では、リソースの過剰使用を防ぐために、ユーザーの代わりにアプリケーションによって一括して行われる呼び出しと操作の数が制限されます。

とはいえ、SharePoint Online でユーザーが調整されることはまれです。 このサービスは堅牢で、大量を処理するように設計されています。 調整された場合は、99%の確率で、カスタム Web パーツ、複雑なリスト ビューやクエリなどのカスタム コード、またはユーザーが実行するカスタム アプリが原因です。 これは、調整される他の方法がないことを意味するのではなく、あまり一般的ではないということです。 たとえば、1 人のユーザーが同時に 10 台のマシン間で大量のデータを同期すると、スロットルがトリガーされる可能性があります。

アプリケーションの調整

ユーザー アカウントによる調整に加え、制限はテナント内のアプリケーションにも適用されます。

すべてのアプリケーションには、組織ごとに購入されたライセンスの数に基づくテナント内の独自の制限があります (含まれるライセンスについては、「SharePoint の制限」 に記載されているプランを参照してください)。 Microsoft Graph、CSOM、REST など、すべての API エンドポイントでアプリケーションが行うすべての要求は、アプリケーションの使用状況にカウントされます。

SharePoint にはさまざまな API が用意されています。 API の複雑さによって、API のコストは異なります。 API のコストは SharePoint によって正規化され、リソース ユニットによって表されます。 アプリケーションの制限は、リソース ユニットを使用して定義することもできます。

次の表では、テナント内のアプリケーションのリソース ユニットの制限を定義します。

ライセンス数 0 – 1k 1k – 5k 5k - 15k 15k - 50k 50k 以上
アプリ 1 分 1,200 2,400 3,600 4,800 6,000
日常的に使用するアプリ 1,200,000 2,400,000 3,600,000 4,800,000 6,000,000

注意

リソース ユニットの制限を変更する権利を留保します。

API コストに関しては、 Microsoft Graph API には 、要求ごとの事前のリソース ユニット コストがあります。

要求あたりのリソース ユニット数 操作
1
  • アイテムの取得などの単一アイテム クエリ
  • トークンを使用した差分
  • 2
  • トークンを含むデルタを除く、リストの子などの複数項目クエリ
  • 作成、更新、削除、アップロード
  • 5
  • $expand=permissions を含むすべてのアクセス許可リソース操作
  • 注意

    API リソース ユニットのコストを変更する権利を留保します。

    トークンを使用した差分は、SharePoint でコンテンツをスキャンする最も効率的な方法であり、 アプリケーションをスキャンするためのベスト プラクティスについて詳しく説明します。 ガイダンスに従うアプリケーションを支援するために、複数項目のクエリですが、トークンを使用して差分要求のリソース ユニット コストを 1 リソース ユニットに削減します。 トークンのない差分要求は複数項目クエリと見なされ、要求ごとに 2 つのリソース ユニットが必要です。

    バッチ処理では、バッチ内の要求はリソース ユニットによって個別に評価されます。

    CSOM と REST には事前に決められたリソース ユニット コストがなく、通常、同じ機能を実現するために Microsoft Graph API よりも多くのリソース ユニットを消費します。 また、リソースユニットの制限に加えて、CSOM と REST も他の内部リソース制限の対象となります。そのため、アプリケーションが CSOM と REST を呼び出すと、このドキュメントで説明されている制限よりも多くの調整が発生する可能性があります。 可能であれば、CSOM API と REST API よりも Microsoft Graph API を選択することを非常に推奨します。

    アプリケーションの制限はリソース単位であるため、実際の要求率 (1 分あたりの要求数など) は、アプリケーションの API の選択と対応する API リソース ユニットのコストによって異なります。 一般に、要求ごとの平均 2 つのリソース ユニットを使用して要求レートを見積もり、リソースユニットの制限を 2 で割って推定要求レートを取得できます。

    各アプリケーションにはテナント内で独自の制限があり、テナントで複数のアプリケーションを実行できますが、同じテナントに対して実行されている複数のアプリケーションは同じリソース バケットを共有します。まれに、一度に要求を送信するアプリケーションが多すぎると、レート制限が発生する可能性があります。

    調整を処理する方法

    調整を処理するためのベスト プラクティスの簡単な概要を次に示します。

    • 同時要求の数を減らす
    • 要求の急増を回避する
    • 可能な場合は、CSOM API と REST API を使用して Microsoft Graph API を選択する
    • Retry-After および RateLimit HTTP ヘッダーを使用する
    • ユーザーがわかるように、トラフィックを装飾する (後述のトラフィックを装飾するためのベストプラクティスを参照)

    前述のように、 Microsoft Graph は、最新の機能強化と最適化を備えたクラウド生まれの API です。 一般に、 Microsoft Graph は 、同じ機能を実現するために CSOM と REST よりも少ないリソースを消費します。 そのため、 Microsoft Graph を採用すると、アプリケーションのパフォーマンスを向上させ、調整を減らすことができます。

    お客様の要求に対して調整が行われた場合、調整が解除されるまでの遅延を最小限に抑えるため、Retry-After HTTP ヘッダーを使用する必要があります。 RateLimit HTTP ヘッダーは、制限に近づくと早期シグナルを送信し、スロットルに達しないように事前に要求を減らすことができます。

    Retry-after ヘッダー

    アプリケーションで調整が発生すると、SharePoint Online は要求内の Retry-After HTTP ヘッダーを返し、呼び出し元のアプリケーションが再試行または新しい要求を行う前に待機する時間を秒単位で示します。

    SharePoint Online は再トライのタイミングを動的に決定するため、Retry-After HTTP ヘッダーは、調整を受けた際に最も早く対処できる方法です。

    スロットルされたリクエストは使用制限にカウントされるため、Retry-After を尊重しないと調整が増える可能性があります。 言い換えると、呼び出しが失敗する場合でも、使用量の制限に反して呼び出しが発生するため、積極的なリトライは不利に働きます。 Retry-After HTTP ヘッダーを受け入れることで、最短の遅延が保証され、調整された要求の無駄なクォータが減ります。

    RateLimit ヘッダー - プレビュー

    SharePoint Online では、調整された要求の応答の Retry-After ヘッダーに加えて、特定の条件で選択した制限の IETF RateLimit ヘッダー も返され、アプリケーションがレート制限を管理するのに役立ちます。 スロットルに達しないように、これらのヘッダーを利用することをお勧めします。

    • RateLimit-Limit には、現在の時間枠の制限が含まれています。
    • RateLimit-Remaining は、現在のウィンドウの残りのクォータを示します。
    • RateLimit-Reset は、クォータがリフィルされるまでの秒数を示します。

    注意

    これらのヘッダーは現在 ベータ版 であり、変更される可能性があります。 ヘッダーが採用された時点では、IETF 仕様は下書きでした。 現在の実装は、IETF 仕様の draft-03 に基づいています。 仕様が最終的に変更される可能性があり、今後これらの変更に対応します。

    RateLimit ヘッダーは ベストエフォート ベースで返されるため、アプリケーションはすべての条件下でヘッダーを受け取らない可能性があります。 さらに、RateLimit ヘッダーに表示されない他の制限もあります。そのため、アプリケーションは、RateLimit ヘッダーで説明されている制限に達する前でも調整を受けることができます。 RateLimit ヘッダーをサポートする制限の一覧を次に示します。 ポリシーと値は、次のように変更される可能性があります。

    limit 条件 制限値 説明
    アプリ 1 分リソース ユニット 使用量 >= 制限の 80% リソース単位 アプリケーションがアプリの 1 分間の制限の 80% 以上を消費すると、制限、残り、およびリセットが返されます。

    RateLimit ヘッダーを理解するのに役立つ例をいくつか次に示します。

    • アプリケーションはリソース ユニット クォータの 90% (1,080 から 1,200) を消費し、その使用量はそれに適用されるすべての制限内にあります。 要求が成功し、 RateLimit ヘッダーが返されます。
    HTTP/1.1 200 Ok
    RateLimit-Limit: 1200
    RateLimit-Remaining: 120
    RateLimit-Reset: 5
    
    • アプリケーションはリソース ユニット クォータの 100% を消費しているため、このポリシーにより調整されます。 要求が調整され、 RateLimit ヘッダーが返されます。 Retry-AfterRateLimit-Reset に一致します 。
    HTTP/1.1 429 Too Many Requests
    Retry-After: 31
    RateLimit-Limit: 1200
    RateLimit-Remaining: 0
    RateLimit-Reset: 31
    
    • アプリケーションはリソース ユニット クォータの 90% を消費しましたが、その使用量は RateLimit ヘッダーでサポートされていない他の制限に既に達しています。 この場合、要求は調整され、RateLimit ヘッダーを返す条件は満たされますが、混乱を避けるためにヘッダーは返されません。
    HTTP/1.1 429 Too Many Requests
    Retry-After: 9
    

    http トラフィックを装飾する方法

    適切に装飾されたトラフィックは、不適切な装飾を施したトラフィックより優先されます。

    装飾されていないトラフィックの定義

    • SharePoint Online への CSOM または REST API 呼び出しに、AppID/AppTitle および User Agent 文字列がない場合は、非装飾のトラフィックです。 User Agent 文字列は、次のように、特定の形式になっている必要があります。
    • ブラウザーで実行する Web アプリケーションを開発している場合、ほとんどの最新のブラウザーではユーザー エージェント文字列の上書きが許可されておらず、実装する必要はありません。

    推奨事項には何がありますか?

    種類 ユーザー エージェント 説明
    ISV Application ISV|CompanyName|AppName/Version ISV を指定し、会社名、アプリ名をパイプ文字で区切り、その後ろにスラッシュで分離してバージョン番号を追加します。
    エンタープライズ アプリケーション NONISV|CompanyName|AppName/Version NONISV を指定し、会社名、アプリ名をパイプ文字で区切り、その後ろにスラッシュで分離してバージョン番号を追加します。
    • SharePoint Online API を呼び出すための自前の JavaScript ライブラリを構築している場合は、http 要求にユーザー エージェント情報を付加していることを確認してください。また、適切な場所で、使用する Web アプリケーションをアプリケーションとしても登録することを検討してください。

    注意

    ユーザー エージェント文字列の形式は RFC2616 に従ったものとします。よって、この勧告に従った右の区切り文字を使用してください。 要求された情報のやりとりにも既存のユーザー エージェント文字列を付加することができます。

    SharePoint Online での一般的な調整シナリオ

    SharePoint Online でユーザー単位の調整が生じる最も一般的な原因は、クライアント側オブジェクト モデル (CSOM) コードまたは Representational State Transfer (REST) コードで実行される操作の頻度と数が多すぎることです。

    • 散発的なトラフィック

      影響を少なくするため、SharePoint Online に対する一定負荷または繰り返しの複雑なクエリは最適化する必要があります。 「アプリケーションをスキャンするためのベスト プラクティス」に従ってファイルの一括処理を行わない場合、調整が発生する可能性が高くなります。 これらのアプリケーションには、同期エンジン、バックアップ プロバイダー、検索インデクサー、分類エンジン、データ損失防止用ツール、およびデータ全体を推論して変更を適用しようとするその他のツールが含まれます。

    • 圧倒的な大量トラフィック

      1 つのプロセスが、長期にわたって継続的に調整制限を大幅に超過します。

      • You used web services to build a tool to synchronize user profile properties. The tool updates user profile properties based on information from your line-of-business (LOB) human resources (HR) system. The tool makes calls at too high a frequency.
      • You're running a load-testing script on SharePoint Online and you get throttled. Load testing isn't allowed on SharePoint Online.
      • You customized your team site on SharePoint Online, for example, by adding a status indicator on the Home page. This status indicator updates frequently, which causes the page to make too many calls to the SharePoint Online service - this triggered throttling.
      • 移行アプリケーションまたはサイトをクロールしてデータを書き戻すアプリケーションを実行しながら OneDrive Sync クライアントを実行すると、要求量が多くなり、スロットルがトリガーされる可能性があります。
    • サポートされていないユース ケース

      Unsupported use of SharePoint Online may experience throttling. Using SharePoint and OneDrive as an intermediary service between Microsoft 365 and another repository is an example of an unsupported use case.

    • 同じアプリケーションに対して複数の AppID を作成する

      バックアップやデータ損失防止など、アプリケーションが基本的に同じ操作を実行する場合は、個別の AppID を作成しないでください。 同じテナントに対して実行されているアプリケーションは、最終的にテナントの同じリソースを共有します。 従来、一部のアプリケーションでは、アプリケーションの調整を回避するためにこのアプローチを試みていましたが、テナントのリソースを使い果たし、テナント内で複数のアプリケーションが調整される原因となっていました。 これを回避できない場合は、SharePoint Online と対話するカスタム コードの各インスタンスを設計して、調整が存在することを考慮する必要があります。

    シナリオ固有の制限

    Sites.Read.All アクセス許可でアプリのみの認証を使用する場合

    アプリのみの認証を使用し、Sites.Read.All アクセス許可が与えられている (または強力な) SharePoint Online 検索 API を使用している場合、アプリは完全なアクセス許可で登録され、すべての SharePoint Online コンテンツ (ユーザーのプライベート ODB コンテンツを含む) にクエリを実行できます。

    サービスの高速性と信頼性を維持するために、このようなアクセス許可を使用するクエリは 25 要求/秒で抑制されます。 検索クエリは http 429 応答で返されます。 調整リカバリーを待機する場合は、類似のアプリのみのアクセス許可を使用し、サービスに対して行う可能性があるすべての検索クエリ要求を必ず一時停止する必要があります。 調整の応答を受信するときに追加のコールを作成すると、アプリが未調整となるまでの時間が長くなります。

    ユーザーの検索結果を検索する場合

    ユーザーの結果をリクエストする結果ソースを使用して検索する場合、25 要求/秒の制限を超えるリクエストを抑制する場合があります。 この制限は、すぐに使用できる "ローカル ユーザーの結果" 結果ソースを使用するすべてのリクエストと、カスタム ユーザーの検索結果ソースを使用するすべてのリクエストに共同で適用されます。

    ユーザーの検索リクエストが抑制される原因となるアプリケーションまたはコンポーネントがある場合は、次のことをお勧めします。

    1. リクエストがアプリケーションに必要かどうかを検討してください。 たとえば、多数の同時クエリを実行するカスタム検索サイトを使用している場合は、組織の検索エクスペリエンスに大きな影響を与えることなく、これらのリクエストの一部を削除できるかどうかを確認してください。 または、SharePoint のスタート ページから検索して、Microsoft Search で最新のユーザーの検索エクスペリエンスを試すことを検討してください。 Microsoft Search でのユーザー検索は、パフォーマンスが向上し、より関連性の高い結果が得られるように最適化されています。
    2. 同時リクエストは避けてください。 たとえば、一度に 10 個のリクエストを発行するのではなく、連続して発行します。次のクエリは、前のクエリが完了した後にのみ発行します。 ページの読み込みなど、すぐに必要な場合は、これらの結果をキャッシュすることを検討する必要があります。
    3. リクエストを単一のクエリに統合してみてください。 たとえば、WorkEmail:user1@constoso.comWorkEmail:user2@constoso.com、...、WorkEmail:user10@contoso.com に対して 10 個の同時クエリを作成する代わりに、単一のクエリ、WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com を試します。
    4. リクエスト量の多いシナリオ (25 要求/秒を超える) が本当に必要な場合は、Microsoft Graph API の使用を検討してください。

    SharePoint Online でブロックが生じた場合の対処方法

    Blocking is the most extreme form of throttling. We rarely ever block a tenant, unless we detect long-term, excessive traffic that may threaten the overall health of the SharePoint Online service. We apply blocks to prevent excessive traffic from degrading the performance and reliability of SharePoint Online. A block - which is placed at the app or user level - prevents the offending process from running until you fix the problem. If we block your subscription, you must take action to modify the offending processes before the block can be removed.

    サブスクリプションがブロックされた場合は、Office 365 メッセージ センターでブロックのお知らせをいたします。 メッセージでは、ブロックを引き起こした原因の説明と問題の解決方法のガイダンスが提供され、ブロックを解除するための連絡先も書かれています。

    関連項目