Cloud SQLの料金が高いとき、縮小する前に見るもの

「Cloud SQLの合計」を、構成と費用の内訳に分ける

はじめに、どのプロジェクトの、どの構成に費用がかかっているかを確認します。CPU・メモリ以外にもストレージ、バックアップ、通信などが含まれるため、合計額だけを見てマシンサイズの問題と決めつけないようにします。料金はエディションやリージョン、構成によって異なります。Google公式：Cloud SQLの料金

構成

エディション、リージョン、vCPU・メモリ、ストレージ、HA、レプリカ

環境の役割

本番・検証、夜間バッチ、読み取り処理、障害時の切り替え先

費用の基準

対象月、実効単価、確約利用割引の有無と契約期間

請求レポートではサービスをCloud SQLに絞り、SKUなどの単位で内訳を確認できます。費用が増えた時期と構成変更の時期も並べます。Google公式：請求レポート

平均CPUが低いときも、ピークと周辺指標を確認する

クラウドスリムの調査では、日中の平均だけでなく、月末処理・夜間バッチ・リリース直後など、負荷が集中する時間を確認します。普段使わない余力に見えても、その時間を支えるために必要な場合があります。

「CPUが何％以下なら必ず縮小できる」という一律の基準は置きません。縮小後の構成で必要な性能を満たせるかを、利用実態と検証結果から判断します。

Recommenderに出ない構成もある

過剰なサイズを検出するCloud SQL Recommenderは、調査の手がかりになります。ただし、公式資料では、作成から30日を超えたプライマリを対象に過去30日のCPU・メモリを分析し、リードレプリカやHA構成は分析対象外とされています。

そのため、推奨事項がないことだけを理由に「最適化済み」と判断することはできません。推奨が出た場合も、実際の業務要件と負荷のグラフを確認してから変更を決めます。Google公式：過剰なサイズのインスタンスを見直す

HAやレプリカは、必要な役割から判断する

HA構成やレプリカには役割があります。HAは可用性のための構成で、費用だけを見て解除すると、障害時に求める復旧の条件を満たさなくなる可能性があります。Google公式：高可用性の構成

調査では「この環境は何分の停止まで許容できるか」「レプリカへ接続する処理はあるか」「障害時にどの構成を使うか」を確認します。削除や構成変更を提案するなら、担当者が用途を確認できる根拠を添えます。

設定変更によっては再起動などの影響が出ます。具体的な変更項目について公式の挙動を確かめ、反映する時間と戻す条件を決めておきます。Google公式：インスタンス設定

実施判断に使える改善提案の形

例えば、CPUとメモリの構成を見直す案なら、次の情報を揃えて提案します。削減額は構成・単価・割引の条件が確認できてから試算します。

1. 根拠対象インスタンス、観測期間、ピーク負荷と業務上の条件。
2. 変更案現在と変更後の構成、影響する機能、必要な作業時間。
3. テスト代表的な負荷での応答時間・エラー率と、業務処理の完了確認。
4. 反映・復旧・計測お客様の反映担当、元の構成へ戻す条件、比較する費用と利用指標。

確約済みの費用がある場合、リソースの利用量が減っても支払額が同じ時期があります。請求に反映される効果と、将来の更新時に見込む効果を区別して説明します。

今の情報で、調べる順番を整理する

詳しい設定が分からなくても、Cloud SQLを使っていることと月額費用が分かれば、簡易診断を利用できます。返すのは確認ポイントと次に必要な情報です。具体的なサイズ変更と削減見込み額は、NDA後に実際の構成を調べて提案します。

全体の費用整理から始めたい場合は、Google Cloudのコスト削減の進め方もご覧ください。