Google Cloud では、リソースの使用や可用性における公平性を保って急激な変動を抑えるために、割り当てが使用されています。割り当ては、 Google Cloud プロジェクトで使用できるGoogle Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次のことを行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストし、割り当ての調整を自動化する手段を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、 Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。 Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
詳細については、Cloud Quotas の概要をご覧ください。
Agent Retrieval（旧称: ベクトル検索 2.0）では、サービスを保護し、プロジェクト間で容量を公平に共有し、パフォーマンスと費用をより予測しやすくするために、割り当てが適用されます。割り当てはリージョンごとに個別に追跡されます。たとえば、us-central での使用量は europe-west4 の割り当てに影響しません。
指標
すべての指標名には vectorsearch.googleapis.com/ という接頭辞が付きます。
レートに基づく割り当て（リクエスト数/分、バイト数/分）
データレートの割り当ての場合、割り当ては 1 分ごとに評価され、プロジェクトごと、リージョンごと（またはマルチリージョンごと）、必要に応じてコレクションごとに適用されます。
受け入れられた API 呼び出しごとに、カウンタが 1 リクエスト（バイト割り当ての場合は N バイト）ずつ増加します。カウンタは暦分ごとに設定され、スライディング ウィンドウ評価を使用します（:00 でのハードリセットはありません）。
「補充」効果なしで、上限まで継続的に実行できます。
カウンタが上限を超えると、追加のリクエストは RESOURCE_EXHAUSTED（HTTP 429）を返します。このとき、reason="RATE_LIMIT_EXCEEDED" と正確な指標名が quota_metric フィールドに設定されます。
コントロール プレーンのレートに基づく割り当て
次の割り当ては、リソースのライフサイクル、特定のプロジェクトとリージョンのコレクションとインデックスに対する読み取りオペレーションと一覧表示オペレーションに適用されます。
スコープ: プロジェクトごと、リージョンごと
単位: 1/min
上限: 1 分あたりのリクエスト数。
| 指標 | カウント |
|---|---|
collection_management_requests
|
collections.createcollections.updatecollections.delete |
collection_read_requests |
collections.get |
collection_list_requests |
collections.list |
index_management_requests
|
indexes.createindexes.updateindexes.delete |
index_read_requests |
indexes.get |
index_list_requests |
indexes.list |
長時間実行オペレーション（LRO）リクエスト
次の割り当ては、特定のプロジェクトとリージョンの長時間実行の読み取り、一覧表示、キャンセル、削除オペレーションに適用されます。
スコープ: プロジェクトごと、リージョンごと
単位: 1/min
上限: 1 分あたりのリクエスト数。
| 指標 | カウント |
|---|---|
lro_requests
|
operations.getoperations.listoperations.canceloperations.delete |
データプレーンのレートに基づく割り当て
特定のプロジェクト、リージョン、コレクションのデータ オブジェクト、クエリ、検索トラフィックには、次の割り当てが適用されます。
注: 検索リクエストの割り当て（search_requests）は、テキスト検索とセマンティック検索で消費されます。
スコープ: プロジェクトごと、リージョンごと、コレクションごと
単位: 1/min
上限: コレクションごとの 1 分あたりのリクエスト数
| 指標 | カウント |
|---|---|
data_object_writes
|
dataObjects.createdataObjects.updatedataObjects.delete 以下に含まれる各データ オブジェクト batchCreatebatchUpdatebatchDelete |
data_object_writes_us
|
data_object_writes と同じですが、us マルチリージョン用です。 |
data_object_reads |
dataObjects.get |
data_object_reads_us
|
data_object_reads と同じですが、us マルチリージョン用です。 |
query_requests |
dataObjects.query（メタデータのみのフィルタクエリ） |
query_requests_us
|
query_requests と同じですが、us マルチリージョン用です。 |
search_requests |
dataObjects.search: 高密度またはスパース ANN を実行する場合。 |
search_requests_us
|
search_requests と同じですが、us マルチリージョン用です。 |
knn_search_requests |
dataObjects.search: 網羅的な KNN 検索を実行する場合。 |
batch_search_requests_us
|
batch_search_requests と同じですが、us マルチリージョン用です。 |
batch_search_requests |
dataObjects.batchSearch（サブ検索の数に関係なく 1 件のリクエスト） |
batch_search_requests_us
|
batch_search_requests と同じですが、us マルチリージョン用です。 |
データプレーンのスループット割り当て
特定のプロジェクト、リージョン、コレクションで 1 分間に書き込まれるバイト数には、次の割り当てが適用されます。
スコープ: プロジェクトごと、リージョンごと、コレクションごと
単位: 1/min
上限: コレクションごとの 1 分あたりのリクエスト数
| 指標 | カウント |
|---|---|
data_object_write_bytes
|
すべての 、 create、update、delete、batchCreate、batchUpdate、、 batchDelete の呼び出しによって書き込まれた、シリアル化されたデータとベクトルバイトの合計。コレクション、データ オブジェクト、インデックス。 |
data_object_write_bytes_us
|
data_object_write_bytes と同じですが、us マルチリージョン用です。 |
バッチ オペレーション
batchCreate, batchUpdate, batchDelete dataObjects: リクエスト内の個々のデータ オブジェクトは、data_object_writesに対して 1 回の書き込みとしてカウントされ、シリアル化されたサイズ（バイト単位）がdata_object_write_bytesに加算されます。batchSearch dataObjects: バンドルされているサブ検索の数に関係なく、batch_search_requestsに対して 1 件のリクエストとしてカウントされます。 バッチ検索では、サブ検索の割り当てもカウントされます。
数量に基づく割り当て（現在の数）
数量に基づく割り当ては、現在の数です。
カウンタは、プロジェクトが所有するリソースまたは処理中のオペレーションのライブカウントです。
この数は、リソースの作成またはオペレーションの開始時に増加し、削除またはオペレーションの完了時に減少します。
上限に達すると、次の作成呼び出しで RESOURCE_EXHAUSTED が返されます。既存のリソースを削除するか、LRO が完了するまで待って割り当てを解放します。
コントロール プレーンの数量に基づく割り当て
次の割り当ては、プロジェクトが特定のプロジェクトとリージョンに対して保持できるリソース数または処理中のオペレーション数に適用されます。
- コレクション
- インデックス
- コレクション、データ オブジェクト、インデックスに対する同時作成、インポート、エクスポート オペレーション
スコープ: プロジェクトごと、リージョンごと
単位: 1
上限: 絶対数（正確な割り当て）
| 指標 | カウント |
|---|---|
collections |
プロジェクト / リージョンに存在するコレクションの数。 |
collections_us
|
collections と同じですが、us マルチリージョン用です。 |
indexes |
プロジェクト / リージョン内のインデックスの数（すべてのコレクションの合計）。 |
indexes_us
|
indexes と同じですが、us マルチリージョン用です。 |
concurrent_index_operations |
処理中のインデックス LRO（作成 / 更新 / 削除）。 |
concurrent_index_operations_us
|
concurrent_index_operations と同じですが、us マルチリージョン用です。 |
concurrent_collection_operations |
処理中のコレクション LRO（作成 / 更新 / 削除）。 |
concurrent_collection_operations_us
|
concurrent_collection_operations と同じですが、us マルチリージョン用です。 |
concurrent_data_object_imports |
処理中の dataObjects.import LRO。 |
concurrent_data_object_imports_us
|
concurrent_data_object_imports と同じですが、us マルチリージョン用です。 |
concurrent_data_object_exports |
処理中の dataObjects.export LRO。 |
concurrent_data_object_exports_us
|
concurrent_data_object_exports と同じですが、us マルチリージョン用です。 |
自動エンベディング
自動エンベディングでは、Gemini Enterprise Agent Platform（aiplatform.googleapis.com）の Gemini API を使用します。各 API リクエストは search_requests または data_object_writes にカウントされ、エンベディング呼び出しは予測割り当てにカウントされます。両方の API に余裕があることを確認します。
使用例
以降のセクションでは、さまざまな使用シナリオが割り当てにどのように影響するかについて説明します。
持続的な書き込みワークロード
ドキュメント（データと 768 次元の高密度ベクトル、約 4 KB）を us-central1 の単一のコレクションに取り込んでいます。次の 2 つの割り当てが同時に適用されます。
data_object_writes (requests per minute, per collection)
data_object_write_bytes (bytes per minute, per collection)
最初に到達した上限によって制限されます。小さなオブジェクトの場合、通常はリクエスト率の割り当てが適用されます。大きなオブジェクトの場合、バイト割り当てがバインドされます。
Google Cloud コンソールで両方の指標を確認して、どちらが上限に最も近いかを確認します。
検索重視のワークロード
単一のコレクションに ANN クエリを送信するサービング ワークロードは、search_requests を消費します。ピーク時の秒間クエリ数（QPS）がコレクションごとの上限に近づいている場合は、上限の引き上げをリクエストするか、同じリージョン内の複数のコレクションにトラフィックを分散します。
多数の小さなコレクション
プロジェクトの collections の上限を超える数のコレクションを作成する予定がある場合は、作成を開始する前に上限の引き上げをリクエストしてください。そうしないと、上限を超える作成呼び出しは RESOURCE_EXHAUSTED で失敗します。
バッチ検索
10 個のサブ検索を含む batchSearch は、正確に 1 つの batch_search_requests を消費しますが、各サブ検索は、外部バッチのレベルでのみ、それぞれのサブ検索ごとの指標にカウントされます。それに応じてバッチ ファンアウトを計画します。
割り当ての表示
割り当てを表示するには:
- Google Cloud コンソールで [IAM と管理] > [割り当て] ページを開きます。
Vector Search APIサービスでフィルタします。- [項目（ロケーションなど）] 列を使用して、リージョン別およびデータプレーン割り当てのコレクション別にフィルタします。
各指標の現在の有効な上限は、 Google Cloud コンソールの [割り当て] ページで、指標名の横に表示されます。この上限は、リージョンでフィルタリングされ、データプレーンの割り当ての場合はコレクションでフィルタリングされます。
割り当てアラートを設定する
ワークロードが依存する割り当ての 80% の使用率でアラートを設定することをおすすめします。詳細については、割り当てアラートを設定するとアラート ポリシーで割り当て指標を使用するをご覧ください。
失敗
割り当てを超過したために拒否されたリクエストは、割り当て自体にカウントされません。
他の理由（INVALID_ARGUMENT, NOT_FOUND など）で失敗したリクエストは、サービスが評価する必要があるため、レートに基づく割り当てにカウントされます。
vector_schema の検証エラーがカウントされます。レートに基づく割り当てのチェックが行われた後、API レイヤで拒否されます。
割り当ての超過
リクエストがスロットリングされると、API は次の値を返します。
gRPC: RESOURCE_EXHAUSTED (8)
HTTP: 429 Too Many Requests
エラー メッセージには、超過した指標が正確に記載されています。
次に例を示します。
Quota exceeded for quota metric 'vectorsearch.googleapis.com/search_requests'
and limit 'SearchRequestsPerMinutePerProjectPerRegionPerCollection' of service
'vectorsearch.googleapis.com' for consumer 'project_number:123456789012'.
この場合、割り当ての増加をリクエストできます。
推奨されるクライアントの動作
クライアントの要件:
- 一時的なレート制限エラーの場合は、指数バックオフとジッターを使用して再試行します。約 1 秒から開始し、最大約 32 秒までバックオフします。
- 数量に基づく割り当て（
"too many collections"など）が原因で発生したエラーを再試行しない。リソースを削除するか、割り当ての増加をリクエストします。 - 単一のコレクションが
data_object_writesまたはdata_object_write_bytesの割り当てをホットスポット化する場合は、コレクションまたはリージョン間で書き込みを分散します。 - 事前ウォームアップ。リリースが現在の制限を超えることがわかっている場合は、少なくとも数営業日前までに上限の引き上げをリクエストしてください。
割り当て増加リクエスト（QIR）
割り当ての増加をリクエストするには:
- Google Cloud コンソールで [IAM と管理] > [割り当て] ページを開きます。
- 高さを変更する行を選択します。
- [割り当てを編集] をクリックし、新しい値と簡単なビジネス上の理由を入力して送信します。以下の情報を記載します。
- 指標名（例:
vectorsearch.googleapis.com/search_requests）。 - リージョンと（データプレーンの場合）コレクション ID。
- 目標スループットとワークロードの簡単な説明（安定したワークロードと急増するワークロード、予想されるピーク QPS、予想されるデータセット サイズなど）。
- 指標名（例:
リクエストは、審査のために Agent Retrieval チームに転送されます。デフォルトの 2 倍までの増加は、ほとんどの場合自動的に承認されます。大幅な増加の場合は、追加の審査が必要になることがあります。