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 |
注:
Microsoft は、リソース ユニットの制限を変更する権利を留保します。
マルチテナント アプリケーションの場合:
- アプリケーションをホストする各テナントは個別と見なされ、他のテナントとは独立して動作します。 そのため、すべてのアプリケーションは、上記で定義した各テナント内の独自の使用制限の対象となります。
- アプリケーションによるリソースユニットの消費量は、アプリケーションごとにテナントごとに測定されます。 これにより、各テナントとアプリケーションのペアが、その特定のテナントに対して指定された許容リソース制限内に保持されます。
- アプリケーションが 1 つのテナント内でリソース制限に達した場合、この状況は、異なるテナントで動作するアプリケーションの他のインスタンスには影響しません。 各テナントのリソース使用率は分離され、テナント間の影響を防ぎます。
API コストの観点から見ると、 Microsoft Graph API には 、要求ごとに事前に決められたリソース ユニット コストがあります。
| 要求あたりのリソース ユニット数 | 操作 |
|---|---|
| 1 | |
| 2 | |
| 5 |
注:
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およびRateLimitHTTP ヘッダーを使用する - ユーザーがわかるように、トラフィックを装飾する (後述のトラフィックを装飾するためのベストプラクティスを参照)
前述のように、 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 を登録して使用するようお勧めします。 - これにより、総合的なエクスペリエンスが向上し、今後の問題解決のための最善の道筋が確立されます。 次の手順で定義されているように、ユーザー エージェントの文字列情報も含めます。
注:
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 要求に User-Agent 情報を含め、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 応答を返します。 調整リカバリーを待機する場合は、類似のアプリのみのアクセス許可を使用し、サービスに対して行う可能性があるすべての検索クエリ要求を必ず一時停止する必要があります。 調整の応答を受信するときに追加のコールを作成すると、アプリが未調整となるまでの時間が長くなります。
委任されたユーザーのアクセス許可を使用して検索する場合
委任されたユーザーのアクセス許可を使用した検索は、アプリケーションがサインインしているユーザーのアクセス許可を持つ検索クエリ要求を送信したときに発生します。 委任された要求の例は、SharePoint ページの検索ボックス、SharePoint ページに埋め込まれた検索ベースの Web パーツまたはカスタム アプリケーション、およびアイテム情報のクエリを実行する Power Automate ワークフローです。
サービスの安定性を確保するために、サービスは、1 ユーザーあたり 1 秒あたり 10 要求を超える委任されたユーザー要求を調整します。 このユーザーごとの制限は、すべてのアプリからのすべての要求に対して集計されます。 1 人のユーザーが 1 秒あたり 10 件を超える検索クエリ要求を送信すると、HTTP 429 が返されます。 要求側アプリケーションは、後続の要求を送信する前に、応答ヘッダーで指定されたタイムアウト時間を待機する必要があります。 検索ベースのアプリケーション、SharePoint ページ、およびワークフローを設計する場合、実装者は、ページとアプリケーションが 1 秒あたり 10 件の要求を集計して 429 個の調整応答を処理しないようにする必要があります。 ページの設計と検索の最適化の詳細とガイダンスについては、「 SharePoint Online モダン サイト ページでの検索要求の最適化 」および「 SharePoint Online のページ診断ツールを使用する」を参照してください。
ユーザーの検索結果を検索する場合
ユーザーの結果を要求する結果ソースを使用して検索する場合、1 秒あたり 25 件の要求の組織全体の制限を超える要求を絞り込む場合があります。 この制限は、すぐに使用できる "ローカルユーザーの結果" の結果ソースまたはカスタムユーザーの検索結果ソースを使用するすべての SharePoint 検索 CSOM および REST 要求に適用されます。
アプリケーションまたはコンポーネントがある場合、ユーザーの検索要求が調整される原因となっている場合は、次のことをお勧めします。
- リクエストがアプリケーションに必要かどうかを検討してください。 たとえば、多数の同時クエリを実行するカスタム検索サイトを使用している場合は、組織の検索エクスペリエンスに大きな影響を与えることなく、それらの要求の一部を削除できるかどうかを確認します。 または、SharePoint のスタート ページから検索して、Microsoft Search で最新のユーザーの検索エクスペリエンスを試すことを検討してください。 Microsoft Search でのユーザー検索は、パフォーマンスが向上し、より関連性の高い結果が得られるように最適化されています。
- 同時リクエストは避けてください。 たとえば、10 個の要求を一度に発行する代わりに、それらを連続して発行します。前のクエリが完了した後にのみ、次のクエリを発行します。 ページの読み込みなど、すぐに必要な場合は、これらの結果をキャッシュすることを検討する必要があります。
- リクエストを単一のクエリに統合してみてください。 たとえば、
WorkEmail:user1@constoso.comに対して 10 個の同時クエリを作成する代わりに、WorkEmail:user2@constoso.com,...,WorkEmail:user10@contoso.com、1 つのクエリを試WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com。 - リクエスト量の多いシナリオ (25 要求/秒を超える) が本当に必要な場合は、Microsoft Graph API の使用を検討してください。
OneDrive サイトにアクセスする場合
存在しない多くの OneDrive サイト コレクションにクライアントが過度にアクセスしようとすると、そのクライアントの IP アドレスからの要求が調整される可能性があります。 調整期間中に OneDrive サイト コレクションにアクセスすると、クライアントは HTTP 429 応答を受け取ります。
SharePoint Online でブロックが生じた場合の対処方法
ブロックは、最も強い形式の調整です。 SharePoint Online サービスの全体的な正常性を脅かす可能性のある長期的で過剰なトラフィックを検出しない限り、テナントをブロックすることはめったにありません。 ブロックは、過剰トラフィックが SharePoint Online のパフォーマンスと信頼性を低下させてしまうことを防ぐために適用されます。 ブロックはアプリまたはユーザー レベルで配置され、問題が解決されるまで問題のあるプロセスが実行できないようにします。 サブスクリプションをブロックする場合、ブロックを削除する前に、問題のあるプロセスを変更するよう対処する必要があります。
サブスクリプションがブロックされた場合は、Office 365 メッセージ センターでブロックのお知らせをいたします。 メッセージでは、ブロックを引き起こした原因の説明と問題の解決方法のガイダンスが提供され、ブロックを解除するための連絡先も書かれています。