SharePoint Online で調整またはブロックを回避するAvoid getting throttled or blocked in SharePoint Online

ここでは、SharePoint Online の調整を説明し、調整とブロックを回避する方法を検討します。Find out about throttling in SharePoint Online, and learn how to avoid being throttled or blocked. 簡単に使用できる CSOM サンプルと REST コードも紹介します。Includes sample CSOM and REST code you can use to make your task easier.

SharePoint Online でファイルを移行するときなどに CSOM プロセスが実行されるものの調整されていることがよくありますか。さらに悪いことに、完全にブロックされることさえあります。このような状況の詳細と、これを回避する方法を説明します。Does this sound familiar? You're running a CSOM process - for example, to migrate files in SharePoint Online - but you keep getting throttled. Or even worse, you get completely blocked. What's going on and what can you do to make it stop?

調整とはWhat is throttling?

SharePoint Online は、SharePoint Online サービスの最適なパフォーマンスと信頼性を維持する目的で調整を使用します。調整では、リソースの過剰な使用を防ぐため、ユーザー アクションまたは (スクリプトまたはコードによる) 同時呼び出しの数が制限されます。SharePoint Online uses throttling to maintain optimal performance and reliability of the SharePoint Online service. Throttling limits the number of user actions or concurrent calls (by script or code) to prevent overuse of resources.

ただし、ユーザーが SharePoint Online で調整されるケースは非常に稀です。サービスは堅牢であり、非常に大量のボリュームにも対処できるように設計されています。調整が発生する場合、99% の割合でその原因はカスタム コードにあります。この原因以外に調整が発生することがないというわけではありませんが、そのような状況は一般的ではありません。たとえば 10 台のマシンをスピンアップし、10 台すべてのマシンでクライアント同期が実行され、各マシンで 1TB のコンテンツが同期されるとします。このような状況では調整が発生する可能性があります。That said, it is extremely rare for a user to get throttled in SharePoint Online. The service is robust, and it is designed to handle very high volume. If you do get throttled, 99% of the time it is because of custom code. That doesn't mean that there aren't other ways to get throttled, just that they are less common. For example you spin up 10 machines and have a sync client going on all 10. On each sync 1TB of content. This would likely get you throttled.

調整が生じる方法

SharePoint Online で調整が発生する状況What happens when you get throttled in SharePoint Online?

あるユーザーが使用制限を超えると、そのユーザー アカウントからさらに送られる要求は SharePoint Online によって短時間、調整されます。調整が有効な間、ユーザー操作はすべて調整されます。When a user exceeds usage limits, SharePoint Online throttles any further requests from that user account for a short period. All user actions are throttled while the throttle is in effect.

  • ユーザーがブラウザーで直接実行する要求の場合、SharePoint Online はユーザーを調整情報のページにリダイレクトし、要求は失敗します。For requests that a user performs directly in the browser, SharePoint Online redirects you to the throttling information page, and the requests fail.

  • その他すべての要求の場合 (CSOM または REST 呼び出しを含む)、SharePoint Online は HTTP ステータス コード 429 (「要求が多すぎます」) を返し、要求は失敗します。For all other requests, including CSOM or REST calls, SharePoint Online returns HTTP status code 429 ("Too many requests"), and the requests fail.

問題を起こすプロセスが使用率の制限を超え続ける場合は、SharePoint Online が完全にプロセスをブロックする可能性があります。この例では、成功したすべての要求は表示されません。Office 365 のメッセージ センターで、ブロックのお知らせをします。If the offending process continues to exceed usage limits, SharePoint Online might completely block the process; in this case, you may see HTTP status code 503 ("Service unavailable"), and we'll notify you of the block in the Office 365 Message Center. The error message is shown below:

アプリケーションの調整Application Throttling

ユーザー アカウントによる調整に加え、制限は各アプリケーションにも適用されます。In addition to throttling by user account, limits are also applied to each application. SharePoint Online のすべてのアプリケーションには独自の利用可能なリソースがあり、最終的には、同じテナントに対して実行している複数のアプリケーションが同じリソースのバケットを共有し、まれにレートの制限が発生することがあります。Every application in SharePoint Online has its own available resources, but multiple applications running against the same tenant ultimately share from the same resource bucket and in rare occurrences can cause rate limiting. これらの場合には、SharePoint Online は、バックグラウンド アクティビティよりも対話型のユーザー要求を優先しようとします。In these cases, SharePoint Online will attempt to prioritize interactive user requests over background activities.

SharePoint Online での一般的な調整シナリオCommon throttling scenarios in SharePoint Online

SharePoint Online でユーザー単位の調整が生じる最も一般的な原因は、クライアント側オブジェクト モデル (CSOM) コードまたは Representational State Transfer (REST) コードで実行される操作の頻度と数が多すぎることです。The most common causes of per-user throttling in SharePoint Online are client-side object model (CSOM) or Representational State Transfer (REST) code that performs too many actions too frequently.

  • 散発的なトラフィックSporadic traffic

    影響を少なくするため、一定の負荷または SharePoint Online に対する繰り返しの複雑なクエリは最適化する必要があります。Constant load or repetitive complex queries against SharePoint Online must be optimized for low impact. 一括のプロセス ファイルが調整になり得る アプリケーションをスキャンするためのベスト プラクティス に従う障害が発生しました。Failing to follow best practices for scanning applications that process files in bulk will likely result in throttling.

    • たとえば、ファイルを SharePoint Online へ移行した後に、ファイルのメタデータを更新するカスタム CSOM または REST スクリプトを実行するとします。CSOM/REST スクリプトは多数のファイルを非常に高い頻度で更新するため、調整が発生します。同様に、REST サービスを使用するオートコンプリート UI ウィジェットは、各エンド ユーザー操作中にリストの呼び出しを多数実行するため、同時にリソースを消費するその他の操作によっては、調整が発生することがあります。For example, after migrating files to SharePoint Online, you run a custom CSOM or REST script to update metadata on the files. The CSOM/REST script is updating a large number of files at a very high frequency, which triggers throttling. Similarly, an autocomplete UI widget using REST services, making too many calls to lists during each end user operation, may also cause throttling, depending on what other operations are consuming resources at the same time.

    散発的調整

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

    1 つのプロセスが、長期にわたって継続的に調整制限を大幅に超過します。A single process dramatically exceeds throttling limits, continually, over a long time period.

    • Web サービスを使用して、ユーザー プロファイル プロパティを同期するツールを作成したとします。このツールは、基幹業務 (LOB) 人事 (HR) システムの情報に基づいてユーザー プロファイルのプロパティを更新します。このツールが呼び出しを実行する頻度が高すぎます。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.

    • SharePoint Online でロード テスト用のスクリプトを実行すると、調整が生じます。SharePoint Online ではロード テストはできません。You're running a load-testing script on SharePoint Online and you get throttled. Load testing is not allowed on SharePoint Online.

    • SharePoint Online のチーム サイトをカスタマイズし、ステータス インジケーターをホーム ページに追加しました。このステータス インジケーターが頻繁に更新されて、そのページで 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.

    規則的調整

正確な調整制限を設定できない理由Why can't you just tell me the exact throttling limits?

正確な調整の制限の設定と公開は非常に単純そうですが、実際にはより制限の厳しい制限になり得ます。Setting and publishing exact throttling limits sounds very straightforward, but in fact it would result in more restrictive limits. 継続的に SharePoint Online でのリソース配分状況を監視します。We continually monitor resource usage on SharePoint Online. 使用状況によってユーザーが SharePoint Online のパフォーマンスと信頼性を低下させることがなくリソースの最大数を使用するようにしきい値を微調整します。Depending on usage, we fine-tune thresholds so users can consume the maximum number of resources without degrading the reliability and performance of SharePoint Online. そのため、CSOM または REST コードが retry-after ヘッダー値を優先することが非常に重要です。これにより、コードが任意の日に可能な限り高速に実行され、調整の制限に達した場合、「ちょうど良い」状態に戻るようにします。That's why it's so important for your CSOM or REST code to honor the retry-after header value; this lets your code run as fast as possible on any given day, and it lets your code back off "just enough" if it hits throttling limits. Retry-after ヘッダーの使用方法は、後でこの記事のコード サンプルで説明します。The code samples later in this article show you how to use the retry-after header.

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

  • 要求あたりの操作数を削減するReduce the number of operations per request

  • 呼び出しの頻度を減らすReduce the frequency of calls

  • ユーザーがわかるように、トラフィックを装飾する (後述のトラフィックを装飾するためのベストプラクティスを参照)Decorate your traffic so we know who you are (see section on traffic decoration best practice more on that below)

  • Retry-after ヘッダーを活用するLeverage the retry-after header

調整を実行する場合、スロットルが削除されるまで最小の遅延を確認するには、retry-after ヘッダーを活用する必要があります。If you do run into throttling, we require leveraging the retry-after header to ensure minimum delay till the throttle is removed.

retry-after は、SharePoint Online が再試行の適切なタイミングを動的に決定するため、調整を処理する最速の方法です。Retry after is the fastest way to handle being throttled because SharePoint Online dynamically determines the right time to try again. つまり、呼び出しが失敗した場合でも積極的な再試行が機能し、使用率の制限に対してなお生じます。In other words, aggressive retries work against you because even though the calls fail, they still accrue against your usage limits. 再試行のヘッダーに従うと、遅延が最短になります。Following the retry header will ensure the shortest delay.

SharePoint Online アクティビティの監視方法について詳しくは、「 Diagnosing performance issues with SharePoint Online」をご覧ください。For information about ways to monitor your SharePoint Online activity, see Diagnosing performance issues with SharePoint Online.

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

調整を回避するために、http トラフィックを装飾する方法How to decorate your http traffic to avoid throttling?

高い可用性の維持のため、一部のトラフィックが制限される可能性があります。To ensure and maintain high-availability, some traffic may be throttled. 調整はシステムの健全性が危険にさらされている場合に発生します。調整で使用する要件のひとつとしてトラフィックの装飾があります。これはトラフィックの優先度決定に直接影響を与えます。Throttling happens when system health is at stake and one of the criteria used for throttling is traffic decoration, which impacts directly on the prioritization of the traffic. 適切に装飾されたトラフィックは、不適切な装飾を施したトラフィックより優先されます。Well decorated traffic will be prioritized over traffic which is not properly decorated.

装飾されていないトラフィックの定義は?What is definition of undecorated traffic?

  • SharePoint Online への CSOM または REST API 呼び出しに、AppID/AppTitle および User Agent 文字列がない場合は、非装飾のトラフィックです。Traffic is undecorated if there is no AppID/AppTitle and User Agent string in CSOM or REST API call to SharePoint Online. User Agent 文字列は、次のように、特定の形式になっている必要があります。The User Agent string should be in a specific format as described below.

推奨事項を挙げてください。What are the recommendation?

  • アプリケーションを作成した場合、AppID と AppTitle を登録して使用するようお勧めします。これにより、総合的なエクスペリエンスが向上し、今後の問題解決のための最善の道筋が確立されます。If you have created an application, the recommendation is to register and use AppID and AppTitle – This will ensure the best overall experience and best path for any future issue resolution. また、次の手順に従い、User Agent 文字列情報も使用してください。Include also the User Agent string information as defined in following step.

  • SharePoint への API の呼び出しに、次の命名規則に従った User Agent 文字列を必ず含めてください。Make sure to include User Agent string in your API call to SharePoint with following naming convention

種類Type ユーザー エージェントUser Agent 説明Description
ISV ApplicationISV Application ISV CompanyName
エンタープライズ アプリケーションEnterprise application NONISV CompanyName
  • SharePoint Online API を呼び出すための自前の JavaScript ライブラリを構築している場合は、http 要求にユーザー エージェント情報を付加していることを確認してください。また、適切な場所で、使用する Web アプリケーションをアプリケーションとしても登録することを検討してください。If you are building your own JavaScript libraries, which are used to call SharePoint Online APIs, make sure that you include the User Agent information to your http request and potentially register your web application also as an Application, where suitable.

注意

ユーザー エージェント文字列の形式は RFC2616 に従ったものとします。よって、この勧告に従った右の区切り文字を使用してください。Format of the user agent string is expected to follow RFC2616, so please follow up on the above guidance on the right separators. 要求された情報のやりとりにも既存のユーザー エージェント文字列を付加することができます。It is also fine to append existing user agent string with the requested information.

注意

ブラウザーで実行中のフロント エンド コンポーネントを開発している場合、最新のブラウザーのほとんどはユーザー エージェント文字列の上書きを許可していないので、この機能を実装する必要はありません。If you are developing front end components executing in the browser, most of modern browsers don't allow overwritting the user agent string and you don't need to implement this.

クライアント側オブジェクト モデル (CSOM) を使用した場合で、ユーザー エージェントを使いトラフィックを装飾する例Example of decorating traffic with User agent when using Client Side Object Model (CSOM)

// Get access to source site
using (var ctx = new ClientContext("https://contoso.sharepoint.com/sites/team"))
{
    //Provide account and pwd for connecting to SharePoint Online
    var passWord = new SecureString();
    foreach (char c in pwd.ToCharArray()) passWord.AppendChar(c);
    ctx.Credentials = new SharePointOnlineCredentials("contoso@contoso.onmicrosoft.com", passWord);

    // Add our User Agent information
    ctx.ExecutingWebRequest += delegate (object sender, WebRequestEventArgs e)
    {
        e.WebRequestExecutor.WebRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
    };

    // Normal CSOM Call with custom User-Agent information
    Web site = ctx.Web;
    ctx.Load(site);
    ctx.ExecuteQuery();
}

REST API を使用した場合で、ユーザー エージェントを使いトラフィックを装飾する例Example of decorating traffic with User agent when using REST APIs

次の例は、C# の形式ですが、SharePoint Online のページで使用されている JavaScript ライブラリに対しても、同様のユーザー エージェント情報の使用をお勧めします。Following sample is in c# format, but the similar User Agent information is recommended to be used even for the JavaScript libraries used in the SharePoint Online pages.

HttpWebRequest endpointRequest = (HttpWebRequest)HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
endpointRequest.Accept = "application/json;odata=verbose";
endpointRequest.Headers.Add("Authorization", "Bearer " + accessToken);
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

CSOM コード サンプル: ExecuteQueryWithIncrementalRetry メソッドCSOM Code sample: ExecuteQueryWithIncrementalRetry method


public static void ExecuteQueryWithIncrementalRetry(this ClientContext context, int retryCount, int delay)
        {
            int retryAttempts = 0;
            int backoffInterval = delay;
            if (retryCount <= 0)
                throw new ArgumentException("Provide a retry count greater than zero.");
           if (delay <= 0)
                throw new ArgumentException("Provide a delay greater than zero.");
           while (retryAttempts < retryCount)
            {
                try
                {
                    context.ExecuteQuery();
                    return;
                }
                catch (WebException wex)
                {
                    var response = wex.Response as HttpWebResponse;
                    if (response != null &amp;&amp; response.StatusCode == (HttpStatusCode)429)
                    {
                       int retryAfterInMs = DefaultRetryAfterInMs;
                        string retryAfter = response.GetResponseHeader(RetryAfterHeaderName);
                        if (!string.IsNullOrEmpty(retryAfter * 1000))
                        {
                            if (!int.TryParse(retryAfter, out retryAfterInMs))
                            {
                                retryAfterInMs = DefaultRetryAfterInMs;
                            }
                        }

                        Console.WriteLine(string.Format("CSOM request exceeded usage limits. Sleeping for {0} milliseconds before retrying.", retryAfterInMs));
                        //Add delay.
                        System.Threading.Thread.Sleep(retryAfterInMs);
                        //Add to retry count.
                        retryAttempts++;
                    }

                    else
                    {
                        throw;
                    }
                }
            }
            throw new MaximumRetryAttemptedException(string.Format("Maximum retry attempts {0}, have been attempted.", retryCount));
       }

SharePoint Online でブロックが生じた場合の対処方法What should you do if you get blocked in SharePoint Online?

ブロックは、調整の最も極端な形態です。Blocking is the most extreme form of throttling. SharePoint Online のサービスの全体的な正常性を脅かす可能性がある、長期的で非常に大量のトラフィックを検出しない限り、テナントをブロックすることはほとんどありません。We rarely ever block a tenant, unless we detect long-term, extremely excessive traffic that may threaten the overall health of the SharePoint Online service. 過剰なトラフィックが SharePoint Online の信頼性とパフォーマンスを低下させることを防ぐためにブロックを適用します。We apply blocks to prevent excessive traffic from degrading the performance and reliability of SharePoint Online. ブロックは通常、アプリケーションまたはユーザー レベルに配置されており、問題が解決するまで、問題のあるプロセスの実行を防ぎます。A block - which is usually 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 のメッセージ センターでブロックを通知します。If we block your subscription we will notify you of the block in the Office 365 Message Center. メッセージがブロックの原因について説明し、問題を解決する方法についてのガイダンスを提供し、ブロックを解除するための連絡先をお知らせします。If we block your subscription, you'll see HTTP status code 503, and we'll notify you of the block in the Office 365 Message Center. The message describes what caused the block, provides guidance on how to resolve the offending issue, and tells you who to contact to get the block removed.

関連項目See also