使用制限

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

商品の制限

組織全体で 20 件を超える書き出しを同時に処理することはできません。

API リクエストの割り当て

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

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

プロジェクトあたりの読み取りリクエスト数（1 分あたり）
エクスポート、案件、保存済みクエリ 120
保留 228
長時間実行オペレーション 300
1 分、1 プロジェクトあたりの書き込みリクエスト数
エクスポート 20
保留 60
案件の権限 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 ミリ秒以下の乱数です。これにより、ある状況で、多数のクライアントが同期して再試行を一度に実行し、リクエストが同時に次々と送信されるような状況を避けることができます。random_number_milliseconds の値は再試行リクエストの後に毎回再計算されます。
  • 通常、maximum_backoff は 32 秒または 64 秒です。適切な値はユースケースによって異なります。

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

適切な再試行間の待ち時間と再試行回数は、ユースケースとネットワークの状態により異なります。

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

プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用していると見なされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。

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

詳細については、次のリソースをご覧ください。

料金

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