Cloud Quotas

解決する課題

Google Cloud の各サービスには、API 呼び出しのレートや作成できるリソース数などに上限（クォータ）が設けられています。Cloud Quotas は、その上限をサービス横断で確認し、調整を一元的に運用できる管理面を提供します。

• どのサービスにどんな上限があり、今どれだけ消費しているのか一覧で把握したい
• 本番リリース前に、必要な容量へクォータ引き上げを事前申請しておきたい
• 開発環境では、暴走や不正利用による想定外の作成・課金を上限で抑えたい
• 多数のプロジェクトに対し、クォータの調整をまとめて適用・自動化したい
• 「クォータ超過（quota exceeded）」で処理が失敗する前に、逼迫を検知して手を打ちたい

主要概念と用語

• クォータ（Quota）: あるサービスの利用量に課される上限。Cloud Quotas が確認・調整の入口になる
• レート上限（Rate quota）: 一定時間あたりの API 呼び出し回数など、時間で区切った上限。期間が過ぎるとリセットされる
• 割り当て上限（Allocation quota）: VM 数や CPU 数など、同時に保持できるリソースの総量に対する上限。リセットの概念がなく、解放するまで消費が続く
• クォータ消費量（Usage）: 現在その上限に対してどれだけ使っているかの実績値
• クォータ引き上げ申請（Quota increase request）: 上限を上げてほしいと申請する手続き。承認には時間がかかることがある
• クォータ調整（Quota adjustment / preference）: 引き上げだけでなく、安全のために上限を低く設定する調整も含む。Cloud Quotas では希望値を「設定（preference）」として表現する
• クォータ超過エラー: 上限に達した状態でのリクエスト。レート上限なら RESOURCE_EXHAUSTED、割り当て上限なら作成失敗として現れることが多い

仕様・制限・クォータ

• Cloud Quotas はプロジェクト単位でクォータを管理するのが基本で、上位階層（フォルダ・組織）に対してまとめて設定を適用する仕組みも提供される
• 上限の値はサービスやリージョンごとに異なり、リージョン別・グローバル別など適用範囲（dimension）を持つものがある
• 引き上げ申請は自動承認される範囲と、Google 側の審査が必要な範囲がある。後者は承認に時間を要し、必ず通るとは限らない
• 安全のために現在の消費量を下回る上限へは下げられないなど、整合性を保つ制約がある
• API 名は cloudquotas.googleapis.com。クォータの確認・調整には対応する IAM ロール（閲覧系・編集系）が必要
• 具体的な上限値・引き上げ可能な範囲・承認所要時間はサービスや状況で変動するため、断定せず実際のコンソール／API 値を確認する

内部の仕組み

各 Google Cloud サービスは自身の利用量を計測し、クォータの上限と突き合わせて呼び出しや作成を許可・拒否します。Cloud Quotas は、それらの上限値と消費量を集約して見せ、調整要求を各サービスへ橋渡しする管理レイヤーとして働きます。

1. クライアントがサービスへリクエストを送る
2. サービスは対象クォータの消費量と上限を照合し、超過していれば拒否（レート上限なら一定期間で回復）
3. 利用者は Cloud Quotas で消費量を確認し、必要なら希望上限（preference）を設定して調整を要求
4. 自動承認の範囲なら即時反映、審査が必要なら申請として処理され、結果が上限に反映される

設計パターン / ベストプラクティス

• 本番リリースや大規模バッチの前に、必要量を見積もって事前に引き上げ申請しておく。申請は承認待ちが発生しうるため、当日対応にしない
• 開発・検証プロジェクトでは、暴走や不正利用に備えて上限をあえて低く設定し、想定外の作成・課金を抑える安全弁にする
• 多数プロジェクトには、上位階層への設定や API による調整でまとめて適用・自動化し、手作業のばらつきを防ぐ
• 重要サービスは消費量が上限に近づいたらアラートを出す運用にし、超過する前に余裕をもって対応する
• クォータの希望値はInfrastructure as Code / API 経由で宣言的に管理し、誰がいつどの値にしたかを追えるようにする

運用・監視

• クォータの確認・調整はコンソール（IAM と管理 → 割り当て）、gcloud、または Cloud Quotas API から行う
• 消費量は Cloud Monitoring のクォータ関連指標で可視化でき、上限に対する使用率のアラートポリシーを設定して逼迫を早期検知する
• 申請がすぐ通らない場合は、自動承認の範囲外で審査中の可能性がある。リリース日程から逆算して余裕をもって申請する
• 「上限を下げられない」場合は、現在の消費量が希望値を上回っていないかを確認する
• クォータの変更操作は Cloud Audit Logs に記録されるため、誰がいつ上限を変えたかを監査できる

コスト

Cloud Quotas 自体（クォータの確認・調整・引き上げ申請）は追加料金なしで利用できるのが基本です。クォータは「使える量の上限」であって、上限を上げただけでは課金は増えません。課金されるのは、その枠内で実際に作成・利用したリソースです。むしろクォータを安全弁として低めに設定することで、暴走や不正利用による想定外の課金を抑えるコスト防御に使えます。

セキュリティ

• クォータの閲覧と調整の権限を IAM ロールで分離し、上限を変更できる人を限定する。安易な引き上げが横行しないよう統制する
• クォータは不正利用や暴走時の被害範囲（blast radius）を限定する防御策にもなる。鍵の漏えいなどで API が乱用されても、上限が歯止めになる
• 上限の変更は実環境の挙動に影響するため、Cloud Audit Logs で変更履歴を追跡し、定期的にレビューする
• 自動化で上限を調整する場合は、サービスアカウントの権限を最小化し、引き上げ幅にガードレール（上限値の上限、承認フロー）を設ける

関連サービス・比較

クォータが「利用量の上限」を強制するのに対し、組織ポリシーは「構成上の禁止事項」をガードレールとして強制します。両者は目的が異なり、組み合わせて統制します。

ハンズオン / CLI例

# プロジェクトで適用されているクォータ情報を一覧（サービス指定）
gcloud quotas info list \
  --project=PROJECT_ID \
  --service=compute.googleapis.com

# 特定クォータの詳細（現在の上限や適用範囲）を確認
gcloud quotas info describe QUOTA_ID \
  --project=PROJECT_ID \
  --service=compute.googleapis.com

# 希望する上限値を「設定（preference）」として作成し調整を要求
gcloud quotas preferences create \
  --project=PROJECT_ID \
  --service=compute.googleapis.com \
  --quota-id=QUOTA_ID \
  --preferred-value=PREFERRED_VALUE

# 設定したクォータ調整の一覧と状態を確認
gcloud quotas preferences list --project=PROJECT_ID