【要約】Cloud Run でキャッシュを保持したいなら、課金モードではなく最小インスタンス数 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がCloud Runでインメモリキャッシュを維持しようとした際、設定の役割を誤解し、不要なコストを払い続ける問題が発生した。筆者はSaaS APIの中継サーバーを構築した際、キャッシュ保持を目的として誤った課金モードを選択した。
- ・キャッシュ保持のために「instance-based」を選択した。
- ・「必須の費用」と思い込み、コスト削減の検討を放棄した。
- ・月額約40ドルの不要な支出を継続した。
// Approach
設定の役割を「メモリ保持」と「CPU割り当て」に分離して再定義し、設計を根本から見直す手法を採用した。設定の目的を明確化し、リクエスト外の処理が必要な場合にのみ適切な設定を選択するプロセスを構築した。
1.最小インスタンス数（min instances）でメモリ保持を担保する。
2.リクエスト外の処理（setInterval等）の有無を確認する。
3.定期実行が必要な場合は、Cloud Run JobとCloud Schedulerへ処理を切り出す。
// Result
設計の適正化により、不要なCPU割り当てを排除し、コストと設計の健全性を両立させた。筆者の構成（1 vCPU / 512 MiB / 東京リージョン）において、以下の成果を得た。
- ・月額約40ドルのコスト削減を実現した。
- ・「キャッシュ保持」と「バックグラウンド処理」を分離した。
- ・Cloud Schedulerを用いた、よりスケーラブルな定期実行構成へ移行した。
Senior Engineer Insight
> サーバーレス環境では「状態（State）」と「実行（Execution）」を切り離して考えるべきだ。本件のように、設定の「理由」を正確に言語化できていないと、不要なコストを「必須の費用」と誤認するリスクがある。特に、Cloud Runのようなマネージドサービスでは、プラットフォームの仕様を正しく理解することが、設計の妥当性を担保する唯一の手段である。定期実行のような副作用のある処理は、サービス内に閉じ込めず、外部スケジューラへ切り出す設計が、スケーラビリティとコストの両面で正解となる。