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 ("サーバーがビジー") を返し、要求は失敗します。

  • 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 と REST API よりも Microsoft Graph API を選択することを強くお勧めします。

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

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

    調整を処理する方法

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

    • 同時要求の数を減らす
    • 要求の急増を回避する
    • 可能な場合は、CSOM と 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-After は RateLimit-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

    追加情報については、「SharePoint Online で RateLimit ヘッダーを使用してアプリケーションの調整を防止する」を参照してください。

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

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

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

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

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

    • アプリケーションを作成した場合、AppID と AppTitle を登録して使用するようお勧めします。 - これにより、総合的なエクスペリエンスが向上し、今後の問題解決のための最善の道筋が確立されます。 また、次の手順に従い、User Agent 文字列情報も使用してください。

      注:

      Azure AD アプリケーションの作成方法の詳細については、「クイックスタート: Microsoft ID プラットフォーム にアプリケーションを登録する ページ」のような、Microsoft identity ドキュメント を参照してください。

    • SharePoint への API の呼び出しに、次の命名規則に従った User Agent 文字列を必ず含めてください。

    種類 ユーザー エージェント 説明
    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 つのプロセスが、長期にわたって継続的に調整制限を大幅に超過します。

      • Web サービスを使用して、ユーザー プロファイル プロパティを同期するツールを作成したとします。 このツールは、基幹業務 (LOB) 人事 (HR) システムの情報に基づいてユーザー プロファイルのプロパティを更新します。 このツールが呼び出しを実行する頻度が高すぎます。
      • ユーザーは、SharePoint Online で負荷テストのスクリプトを実行しているため、調整されています。 負荷テストは、SharePoint Online では許可されていません。
      • SharePoint Online のチーム サイトをカスタマイズし、ステータス インジケーターをホーム ページに追加しました。 このステータス インジケーターが頻繁に更新されて、そのページで SharePoint Online サービスに対する呼び出しが多くなりすぎ、調整が発生します。
      • 移行アプリケーションまたはサイトをクロールしてデータを書き戻すアプリケーションを実行しながら OneDrive Sync クライアントを実行すると、要求量が多くなり、スロットルがトリガーされる可能性があります。

    • サポートされていないユース ケース

      SharePoint Online のサポートされていない使用方法では、調整が発生する可能性があります。 サポートされていないユース ケースの例には、Microsoft 365 と他のレポジトリとの間で SharePoint と OneDrive を中継サービスとして使用することが挙げられます。

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

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

    シナリオ固有の制限

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

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

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

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

    ユーザーの結果を要求する結果ソースを使用して検索する場合、1 秒あたり 25 要求のorganization全体の制限を超える要求を絞り込む場合があります。 この制限は、すぐに使用できる "ローカル People結果" の結果ソースまたはカスタムユーザーの検索結果ソースを使用して、すべての SharePoint 検索 CSOM および REST 要求に適用されます。

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

    1. リクエストがアプリケーションに必要かどうかを検討してください。 たとえば、多数の同時クエリを実行するカスタム検索サイトを使用している場合は、組織の検索エクスペリエンスに大きな影響を与えることなく、これらのリクエストの一部を削除できるかどうかを確認してください。 または、SharePoint のスタート ページから検索して、Microsoft Search で最新のユーザーの検索エクスペリエンスを試すことを検討してください。 Microsoft Search でのユーザー検索は、パフォーマンスが向上し、より関連性の高い結果が得られるように最適化されています。
    2. 同時リクエストは避けてください。 たとえば、一度に 10 個のリクエストを発行するのではなく、連続して発行します。次のクエリは、前のクエリが完了した後にのみ発行します。 ページの読み込みなど、すぐに必要な場合は、これらの結果をキャッシュすることを検討する必要があります。
    3. リクエストを単一のクエリに統合してみてください。 たとえば、WorkEmail:user1@constoso.com、WorkEmail: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 でブロックが生じた場合の対処方法

    ブロックは、最も強い形式の調整です。 SharePoint Online サービス全体の正常性を脅かすような過剰トラフィックが長期に渡り検出された場合を除き、テナントをブロックすることはまずありません。 ブロックは、過剰トラフィックが SharePoint Online のパフォーマンスと信頼性を低下させてしまうことを防ぐために適用されます。 ブロックはアプリまたはユーザー レベルで配置され、問題が解決されるまで問題のあるプロセスが実行できないようにします。 サブスクリプションをブロックする場合、ブロックを削除する前に、問題のあるプロセスを変更するよう対処する必要があります。

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

    関連項目