制限と呼び出しパターンについて理解する

適用対象: 開発者

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

*でマークされた制限は、Microsoft サポートまたは SharePoint Embedded オンボード連絡先を通じて要求に応じて増やすことができます。既定の制限を計画し、運用環境でアプローチする前に引き上げを要求します。

カテゴリを制限する

SharePoint Embedded の制限は次に影響します。

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

サイズの制限

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

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

テナントが作成するコンテナーの種類のうち、開発とテスト用の無料 試用版コンテナーの種類 を指定でき、残りのコンテナーの種類は 標準 (課金) です。 新しいテナントは、要求時に発生できる低い既定値から始まります。 試用版と標準の詳細については、「 コンテナーの種類を作成して構成する」を参照してください。

コンテナーの種類の制限の設計

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

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

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

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

コンテナーの種類の計画については、「 コンテナーの種類とコンテナーについて」を参照してください。

コンテナーの制限の設計

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

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

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

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

アクセス許可の制限を設計する

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

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

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

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

調整応答

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

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

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

ヘッダーは、再試行または新しい要求を行う前に待機する時間をアプリに伝えます。

再試行ガイダンス

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

• HTTP 429 と 503を検出します。
• Retry-After ヘッダーを読み取ります。
• 再試行する前に、指定した期間待機します。
• 調整後のコンカレンシーを減らします。
• 即時再試行ループを回避します。
• 待機期間後の要求の急増を回避します。

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

コンカレンシー ガイダンス

調整が発生した場合の同時要求の数を減らします。

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

大規模なコンテナーまたはファイルのセットを処理するときに、時間の経過と同時に作業を分散します。

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

制限に近い場合は、バックグラウンド メンテナンスよりもユーザーに表示される操作に優先順位を付けます。

API リソース ユニット

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

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

API レートの制限は、リソース ユニットを使用して定義することもできます。

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

API レートの制限

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

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

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

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

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

コンテナーの作成率の制限

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

アクセス許可操作コスト

アクセス許可リソース操作では、リソースユニットのコストが高くなります。

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

不要なアクセス許可の拡張を減らします。

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

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

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

バッチ処理によってクライアントのオーバーヘッドが削減されますが、サービスの制限や課金への影響は取り除きません。

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

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

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

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

次の設計:

• アクセス許可が多い呼び出しが少なくなります。
• 予測可能なコンカレンシー。
• 増分同期。
• 調整後のバックオフ。
• 前景と背景の作業の分離。
• マルチテナント アプリのテナント レベルの公平性。
• 要求レート、応答コード、待機時間の監視。

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

運用監視

トラック：

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

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

計画チェックリスト

• 運用環境の起動前に、現在のサイズ制限を確認します。
• 多数のコンテナーの種類を作成する代わりに、コンテナーをモデル化します。
• コンテナーごと、および使用しているテナントごとのストレージを見積もる。
• ファイルとフォルダーの数を見積もります。
• 不要な追加アクセス許可は避けてください。
• 429と503のRetry-After処理を実装します。
• コンカレンシーを制限し、スパイクを回避します。
• 操作の種類別にリソースユニットの使用状況を見積もります。
• アクセス許可の負荷の高い操作を減らします。
• 調整と待機時間を監視します。
• API 設計に課金への影響を含めます。

関連する計画に関する記事

• アプリとテナントのアーキテクチャについて
• コンテナーの種類とコンテナーについて
• 認証とアクセス許可を計画する
• 課金モデルを選択する

次の手順

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