TL;DR
- 初期のGCP設計は、従量課金を前提とした妥当なものだった
- 問題は、運用中に不安から追加した小さな設定変更の積み重ね
- GCPでは「後から足した設定」が固定費になりやすい
はじめに
これは、GCPを使ったプロジェクトを運用する中で発生したコスト増加についての個人的な振り返りです。
私はインフラの経験が豊富なエンジニアではありません。
このプロジェクトが、GCPをある程度の規模で継続運用した初めてのケースでした。
結論を先に書くと、
初期設計そのものが大きく間違っていたわけではありません。
問題は、運用フェーズで行った「後からの調整」にありました。
本記事では、どのような意図で設定を変更し、それがどのようにコストへ影響していったのかを整理します。
初期設計について
最初の設計は、GCPの思想に比較的素直なものでした。
- アプリケーションは Cloud Run
- スケールゼロを前提
- トラフィックに応じた従量課金
- データベースは Cloud SQL
- 最小構成から開始
- バッチ処理は必要最低限
- ログ出力も控えめ
少なくとも当時は「固定費をできるだけ持たない」という方針を意識していました。
運用開始後に起きた変化
実運用が始まると、設計時には意識していなかった不安が少しずつ出てきました。
- レスポンスが遅くならないか
- 障害時に対応できるか
- 本番環境で問題が起きないか
これらを背景に、安定性を優先するための設定変更をいくつか行いました。
後から行った主な設定変更
Cloud Run の minScale 設定
Cloud Runの一部サービスで minScale = 1 を設定しました。
意図としては、
- コールドスタートを避けたい
- 常に応答できる状態にしておきたい
というものでした。
結果として、トラフィックがない時間帯でもインスタンスが常駐し、CPU・メモリ課金が継続的に発生する状態になっていました。
今ならこうする
→ minScale は基本0のままにし、実測データが出てから必要性を判断する。
バッチ処理の実行頻度調整
Cloud Scheduler を使った定期処理について、実行間隔を短くしました。
1回あたりの処理は軽量でしたが、
- 高い実行頻度
- 長期間の運用
が重なり、累積すると無視できないコストになっていました。
今ならこうする
→ 処理頻度は「業務要件ベース」で定期的に見直す前提にする。
本番環境でのログ出力
トラブルシュートを想定して、本番環境でも詳細なログを出力していました。
Cloud Loggingでは、
- ログの取り込み
- 保存
- インデックス作成
が課金対象になります。
結果として、ログの量そのものがコスト要因になっていました。
今ならこうする
→ 本番ログは warn / error を基本とし、debug は一時的にのみ有効化する。
Artifact Registry の管理不足
CI/CD により Docker イメージは自動的にビルド・保存されますが、削除ポリシーを設けていませんでした。
そのため、
- 未使用のイメージ
- 古いタグ付きイメージ
が蓄積し、Artifact Registry の容量が大きくなっていました。
今ならこうする
→ Artifact Registry には最初からライフサイクルポリシーを設定する。
Cloud SQL のサイジング
安定性を重視する判断から、Cloud SQL のスペックを引き上げました。
Cloud Run はスケールゼロになりますが、Cloud SQL は常時起動するリソースです。
この前提の違いにより、データベースのコストが全体の中で相対的に大きくなっていました。
今ならこうする
→ DBは最小構成で始め、CPU・メモリ使用率を見て段階的に拡張する。
振り返って分かったこと
請求額を見た際、最初は「何が原因なのか分からない」という状態でした。
しかし一つずつ確認していくと、
- 個々の設定変更は小さい
- 意図としては合理的
- ただし累積すると固定費になる
という構造が見えてきました。
学び
今回の経験から得た学びは次の通りです。
- GCPでは、小さな設定変更が継続コストに直結しやすい
- 不安を理由にした調整は、後から全体最適を崩しやすい
- 初期設計の前提は、運用後も定期的に見直す必要がある
特に、「後から足した設定が今も本当に必要か」を確認することは重要だと感じました。
おわりに
この記事は、過去の自分の判断を整理するためのメモでもあります。
同じように、
- インフラ経験が浅い状態でGCPを触っている
- 安定性を優先して設定を足してきた
という方にとって、何か一つ見直すきっかけになれば幸いです。
Discussion