Skip to content

Cloud SQL sizing

ルール ID: gcp.cloudsql.instance.sizingカテゴリ: sizing ・ 必要な読み取り: インベントリ + 利用メトリクス 計画中

Cloud SQL は「余裕を見て大きめに」作られがちです。このルールは、実測の CPU・メモリ利用率に対して過大なマシン構成のインスタンスを見つけ、実測に基づく縮小先を提案します。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

ピーク実測(p99)で見ても CPU・メモリの両方に大きな余裕があるまま、大きなマシン構成の料金を払い続けている Cloud SQL インスタンス。

判定条件

  • 30 日間の p99 CPU 利用率 ≤ 25%、かつメモリ利用率 ≤ 50%(両方を満たす場合のみ)
  • 降格先はカスタムマシン構成の制約の範囲で解決します(制約内に実在する構成のみ提案)
  • HA(高可用性)構成は、スタンバイ分を含む 2 倍係数で削減額を計算します

必須 facts

  • 現行のマシン構成(vCPU・メモリ)
  • 30 日窓の p99 CPU 利用率・メモリ利用率
  • HA 構成の有無
  • 取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

  • 月末・年次バッチなど、観測窓に現れなかった周期ピークを持つ DB
  • メモリ量に依存する同時接続上限やキャッシュ効率を前提にした構成(縮小で接続上限・性能が下がり得る)
  • 直近でワークロードの追加・移行を控えているインスタンス

実行前の確認

  • マシン構成の変更は再起動を伴うため、許容できる時間帯(メンテナンスウィンドウ)を確認する
  • アプリケーション側の接続リトライ設定と、必要な同時接続数を確認する
  • IaC(Terraform 等)での構成定義箇所を確認する

非破壊テストとロールバック

Safety Tier: medium(構成変更は可逆。ただし変更のたびに再起動を伴う)

  1. メンテナンス時間帯に、提案されたマシン構成へ変更する
  2. CPU・メモリ利用率・クエリレイテンシ・接続エラーを観察する
  3. 余裕がなくなる兆候があれば、次の手順で元に戻す

ロールバック: 元のマシン構成に戻します(同じく再起動を伴います)。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。