使用制限

Google Vault API は共有サービスであるため、すべてのユーザーが公平に使用し、Google Workspace システムの全体的な健全性を保護するために、割り当てと制限が適用されます。

商品の制限

組織全体で進行中のエクスポートは 20 個までです。

API リクエストの割り当て

各組織では、すべてのプロジェクトとユーザーを対象に、1 分あたり 600 件の案件の読み取りが許可されています。これには、Vault API と vault.google.com によるリクエストも含まれます。

次の表に、プロジェクトごとの 1 分あたりのリクエスト上限を示します。

1 プロジェクト、1 分あたりの読み取りリクエスト数
エクスポート、案件、保存したクエリ 120
保留 228
長時間実行オペレーション 300
1 プロジェクト、1 分あたりの書き込みリクエスト数
エクスポート 20
保留 60
Matter の権限 30
Matter 60
保存したクエリ 45
1 プロジェクト、1 分あたりの検索（数）リクエスト数
検索数 20

メソッド別の割り当て使用量

リクエストで使用される割り当ては、呼び出されるメソッドによって異なります。次の表に、メソッドごとの割り当て使用量を示します。

メソッド 割り当て費用
matters.close
matters.create
matters.delete
matters.reopen
matters.update
matters.undelete 		1 件の案件の読み取り
1 件の案件の書き込み
matters.count 1 回
matters.get 1 件の案件の読み取り
matters.list 課題の読み取り 10 回
matters.addPermissions
matters.removePermissions 		1 件の案件の読み取り
1 件の案件の書き込み
1 件の案件の権限の書き込み
matters.exports.create 1 件のエクスポートの読み取り
10 件のエクスポートの書き込み
matters.exports.delete 1 件のエクスポートの書き込み
matters.exports.get エクスポートの読み取り 1 件
matters.exports.list エクスポートの読み取り 5 回
matters.holds.addHeldAccounts
matters.holds.create
matters.holds.delete
matters.holds.removeHeldAccounts
matters.holds.update 		案件の読み取り 1 件
案件の書き込み 1 件
読み取りを 1 回保持
書き込みを 1 件保持
matters.holds.list 1 件の案件の読み取り
3 件の記録保持（リティゲーション ホールド）の読み取り
matters.holds.accounts.create
matters.holds.accounts.delete
matters.holds.accounts.list 		案件の読み取り 1 件
案件の書き込み 1 件
読み取りを 1 回保持
書き込みを 1 件保持
matters.savedQueries.create
matters.savedQueries.delete 		案件の読み取り 1 件
案件の書き込み 1 件
保存したクエリの読み取り 1 件
保存したクエリの書き込み 1 件
matters.savedQueries.get 1 件の案件の読み取り
1 件の保存済みクエリの読み取り
matters.savedQueries.list 1 件の案件の読み取り
3 件の保存済みクエリの読み取り
operations.get 1 件の長時間実行オペレーションの読み取り

時間ベースの割り当てエラーを解決する

1 分または組織あたりの割り当ての上限を超えると、通常は 429: Too many requests HTTP ステータス コード レスポンスが返されます。

すべての時間ベースのエラー（X 分あたり最大 N 件のリクエスト）については、コードで例外をキャッチし、切り捨て型指数バックオフを使用して、デバイスが過度な負荷を発生させないようにすることをおすすめします。

指数バックオフは、ネットワーク アプリケーションにおける標準的なエラー処理方法です。指数バックオフのアルゴリズムは、リクエスト間の待機時間を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。それでもリクエストが失敗する場合は、リクエストが成功するまで時間の経過とともにリクエスト間の遅延を長くすることが重要です。

アルゴリズムの例

指数バックオフのアルゴリズムは、指数関数的にリクエストを再試行し、再試行間の待機時間を最大バックオフ時間まで増加させます。例:

  1. Google Vault API にリクエストを送信します。
  2. リクエストが失敗した場合、1 + random_number_milliseconds 待ってから、リクエストを再試行します。
  3. リクエストが失敗した場合は、2 + random_number_milliseconds の後にリクエストを再試行します。
  4. リクエストが失敗した場合、4 + random_number_milliseconds 待ってから、リクエストを再試行します。
  5. このようにして、最大 maximum_backoff 時間まで繰り返します。
  6. 再試行の最大回数まで待機と再試行を継続しますが、再試行の待機時間を増やさないでください。

ここで

  • 待機時間は min(((2^n)+random_number_milliseconds), maximum_backoff) で、n は反復（リクエスト）のたびに 1 ずつ増加します。
  • random_number_milliseconds は、1,000 ミリ秒以下の乱数です。これにより、ある状況で多数のクライアントが同期され、すべてが同時に再試行され、リクエストを同期 Wave で送信するケースを回避できます。random_number_milliseconds の値は再試行リクエストごとに再計算されます。
  • 通常、maximum_backoff は 32 秒または 64 秒です。適切な値はユースケースによって異なります。

maximum_backoff 時間に達した後も、クライアントは再試行を続行できます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントが 64 秒の maximum_backoff 時間を使用していて、この値に達した後は、クライアントは 64 秒ごとに再試行できます。ある時点で、クライアントが無期限に再試行できないようにする必要があります。

再試行の間隔と再試行回数は、ユースケースとネットワーク状態によって異なります。

割り当ての増加をリクエストする

プロジェクトのリソース使用量に応じて、割り当ての増加をリクエストできます。サービス アカウントによる API 呼び出しは、1 つのアカウントを使用するものとみなされます。割り当ての増加を申し込んでも、承認が保証されるわけではありません。割り当ての増加が大きい場合は、承認に時間がかかることがあります。

割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が増加するにつれて、割り当ての増加が必要になることがあります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当て] ページから割り当ての調整をリクエストできます。

詳しくは、次のリソースをご覧ください。

料金

Google Workspace のお客様は、Google Vault API を追加費用なしでご利用いただけます。