制限と呼び出しパターンについて

適用対象: Developer

この記事を使用して、大量のコンテナーとコンテンツ操作を構築する前に、SharePoint 埋め込み呼び出しパターンを計画します。 SharePoint Embedded では、スループットが、1 秒あたりの固定要求数レートではなく、 1 分あたりのリソース ユニット (正規化された要求コスト モデル) として表されます。 API レート制限セクション では、リソース ユニットを予想されるリクエスト レートに変換する方法について説明します。

* が付いた制限は、要求に応じて、Microsoft サポートまたは SharePoint Embedded オンボーディング担当者を通じて引き上げることができます。既定の制限を計画し、運用環境でそれに近づく前に引き上げを要求します。

カテゴリの制限

SharePoint Embedded の制限は以下に影響を与えます。

  • コンテナーの種類数*
  • コンテナー数*
  • コンテナー タイプおよびコンテナーごとのストレージ
  • ファイルとフォルダー
  • アクセス許可
  • ファイルのサイズ
  • バージョン数
  • API レートの制限*
  • アプリ、コンテナー、ユーザーごとの要求数*

注:

これらの制限は変更される可能性があります。 運用環境に起動する前に、現在の制限を確認します。

サイズの制限

SharePoint Embedded では、次のサイズ制限が適用されます。

リソース 極限
開発者テナントが作成できるコンテナーの種類 25*
アプリが所有できるコンテナーの種類 1
消費テナントごとのコンテナー タイプごとのストレージ 100 TB*
コンテナーごとの Files とフォルダー 3,000 万
コンテナーごとのストレージ 25 TB
コンテナーごとの追加のアクセス許可を持つ Files とフォルダー 5,000
ファイルのサイズ 250 GB
ファイルごとのバージョン数 500 (既定の自動バージョン履歴制限)
フォルダーまたはファイルごとに共有されるユーザー数 5,000
コンテナーごとのカスタム列数 40

アスタリスク (*) は、引き上げを要求できる制限を示します。

テナントが作成するコンテナーの種類のうち、1 つは開発およびテスト用の無料 試用版コンテナーの種類 にすることができ、残りは 標準 (課金) コンテナーの種類です。 新しいテナントは、要求に応じて引き上げることができる低い既定値で開始します。 評価版と標準版の詳細については、「 コンテナーの種類の作成と構成」を参照してください。

コンテナー タイプ制限の設計

アプリは 1 つの種類のコンテナーを所有できます。

顧客、プロジェクト、ワークスペース、またはユーザーを個別のコンテナーの種類としてモデル化しないでください。

コンテナー タイプ内のアプリケーション ストレージ インスタンスにコンテナーを使用します。

アプリ レベルの動作、アクセス関係、課金アカウンタビリティ用のコンテナーの種類を選択します。

コンテナー タイプの計画については、 コンテナー タイプとコンテナーについて を参照してください。

コンテナー制限の設計

コンテナーは、ストレージとセキュリティの境界を提供します。

消費する各テナントが作成するコンテナーの数を計画します。

アクティブなコンテナーと、クォータまたはストレージに影響を与える可能性のある削除されたコンテナーのライフサイクルを考慮します。

コンテナーの境界をアクセス、ライフサイクル、およびガバナンスの要件に合わせて維持します。

アクセス許可の制限の設計

SharePoint Embedded では、コンテナーごとに追加アクセス許可を持つファイルとフォルダーが最大 5,000 個許可されます。

コンテナー レベルまたはフォルダー レベルのモデルで十分な場合は、すべてのファイルまたはフォルダーに固有のアクセス許可を持つように設計しないでください。

可能な場合は、コンテナー メンバーシップとロールを使用します。

アクセス許可の概念については、「 認証とアクセス許可の計画」を参照してください。

調整応答

アプリケーションがサービス制限に達すると、SharePoint Embedded は次の値を返すことができます。

  • HTTP 429 Too Many Requests。
  • HTTP 503 Server Too Busy。

どちらの応答にも Retry-After ヘッダーが含まれます。

ヘッダーは、再試行または新しい要求を行うまでの待機時間をアプリに指示します。

重要

調整された要求は使用制限にカウントされます。 Retry-Afterを無視すると、アプリでより多くのスロットリングが発生する可能性があります。

再試行のガイダンス

次のような再試行ロジックを実装します。

  • HTTP 429 および 503 を検出します。
  • Retry-After ヘッダーを読み取ります。
  • 指定した時間待機してから再試行します。
  • 調整後のコンカレンシーを減らします。
  • 即時再試行ループを回避します。
  • 待機期間後の要求スパイクを回避します。

有界再試行を使用し、操作テレメトリに対する永続的なエラーを表示します。 調整応答の処理に関する一般的なガイダンスについては、「 Microsoft Graph の調整ガイダンス」を参照してください。

同時実行のガイダンス

スロットリングが発生している同時要求の数を減らします。

同時に多くの要求を送信するバースト パターンは避けます。

大量のコンテナーまたはファイルを処理するときに、時間の経過と共に作業を分散します。

トラフィックをスムーズにするために、キューまたはバックグラウンド ワーカーを使用します。

限界に近いときは、バックグラウンド メンテナンスよりもユーザーに表示される操作を優先します。

API リソース ユニット

API が異なれば、機能や複雑さに応じてコストも異なります。

コストは正規化され、リソース ユニットとして表されます。

API レート制限もリソース ユニットを使用して定義されます。

各要求は、その複雑さに基づいてリソース ユニットのコストを消費します。

要求あたりのリソース ユニット数 操作
1 アイテムの取得など、単一アイテムのクエリ。
2 子の一覧表示、作成、更新、削除、アップロードなどの複数アイテムのクエリ。
5 $expand=permissions を含むすべてのアクセス許可リソース操作。

注:

リソースの単価は変更される可能性があります。

API レート制限

SharePoint Embedded では、これらの API レート制限が適用されます。

リソース 極限
コンテナーあたりの要求数 3,000 リソース ユニット/分
テナントあたりのアプリあたりの要求数 12,000 リソース ユニット/分*
ユーザーごとの要求数 600 リソース ユニット/分

アスタリスク (*) は、引き上げを要求できる制限を示します。

アプリケーションの制限は、リソース ユニットで定義されます。

1 分あたりの実際の要求数は、呼び出す API とそのリソース単価によって異なります。

要求率を見積もるには、要求あたり平均約 2 つのリソース ユニットを、アプリケーション リソース ユニットの制限を 2 で割ります。

コンテナー作成レートの制限

消費するテナントごと、およびテナントのピーク時間中に、コンテナーの作成は 1 秒あたり 5 つの新しいコンテナーに制限されます。 この制限を超える要求はレート制限されます。 ピーク時間以外は、より高速な速度でコンテナーを作成できます。

権限操作コスト

アクセス許可リソース操作では、リソース単価が高くなります。

$expand=permissionsを含む操作は、5 つのリソース ユニットで一覧表示されています。

不要な権限拡張を削減します。

アクセス許可に基づく決定は、セキュリティ モデルにとって安全な場合にのみキャッシュします。

メンバーシップまたは役割の変更が発生したときにアクセス許可データを更新します。

バッチ処理に関する考慮事項

バッチ処理によってクライアントのオーバーヘッドを削減できますが、サービスの制限や課金への影響がなくなるわけではありません。

リソース ユニットの消費量とトランザクション コストを見積もるときに、基になる各操作をカウントします。

短時間に 1 つのコンテナー、アプリ、テナント、またはユーザーに対して多くの作業を集中させるバッチを作成しないでください。

プラットフォームから返される応答の詳細に従って、バッチ操作の調整応答を尊重します。

パフォーマンスに関する考慮事項

デザイン対象:

  • アクセス許可を必要とする呼び出しを削減します。
  • 予測可能な同時実行性。
  • 増分同期。
  • 調整後のバックオフ。
  • フォアグラウンド作業とバックグラウンド作業の分離。
  • マルチテナント アプリのテナント レベルの公平性。
  • 要求レート、応答コード、待機時間の監視。

API トランザクションの課金への影響については、「 課金モデルの選択」を参照してください。

運用の監視

トラック:

  • HTTP 429 と 503 応答率。
  • 再試行回数と待機時間。
  • リソースを大量に消費する操作。
  • アプリ、テナント、ユーザー、コンテナーごとの要求。
  • バックグラウンド ジョブ キューの長さ。
  • コンテナーおよびテナントあたりのストレージの増加。
  • アクセス許可操作の頻度。

これらのシグナルを使用して、同時実行性を調整し、設計の変更が必要なテナントまたはワークフローを特定します。

計画チェックリスト

  • 実稼働開始前に、現在のサイズ制限を確認します。
  • 多くのコンテナー タイプを作成するのではなく、コンテナーをモデル化します。
  • コンテナーごとおよび消費テナントごとのストレージを見積もります。
  • ファイルとフォルダーの数を見積もる。
  • 不要な追加アクセス許可は避けてください。
  • 429 と 503 のRetry-After処理を実装します。
  • 同時実行を制限し、スパイクを回避します。
  • 操作の種類別にリソース ユニット使用量を見積もります。
  • アクセス許可を必要とする操作を削減します。
  • 調整と待機時間を監視します。
  • API 設計に課金への影響を含めます。

次の手順

クイック スタートで構築を開始する : VS Code で最初のアプリをビルドします。

  • Last updated on