Cloud Run のコールドスタート費用：最小インスタンスガイド

Cloud Run は traffic がないと service を instance 0 まで縮小できます。その後の最初の request は container instance の起動を待つ場合があります。Warm instance に費用をかける前に、idle 後の最初の request について startup latency と利用者が感じる response time を測定してください。たまに動く background・内部 request と明確な応答時間目標がある対話経路も分けます。

最小 instance は準備済み capacity を維持し、0 から scale するときの遅延を減らせますが、課金対象の idle time が生じます。特定の process が永続する保証ではなく best-effort の warm capacity 目標なので、application は restart に耐え、安全に初期化できる必要があります。

Service ごとに region、最小 instance 数、vCPU、memory、billing 設定、月間の有効時間を記録します。Request-based billing では request を待つ最小 instance に該当する idle rate が適用され、active な処理時間は別に課金されます。Instance-based billing では idle time を含む instance lifecycle の CPU と memory が課金対象です。現在の地域別単価と free tier は公式 Cloud Run 料金ページで確認してください。

Request 数に固定の cold-start 料金を掛けてはいけません。Startup と active compute は image size、初期化処理、network call、request duration、concurrency、traffic pattern、instance の維持時間で変わります。Scale-to-zero と minimum-one のケースを作り、現実的な test で測った latency 改善と月間 baseline を比較します。

Firebase Functions に最小インスタンスの費用モデルを適用する

Container image を小さく保ち、必須でない初期化を遅らせ、startup 中の不要な network call を避け、必要に応じて startup probe を使います。Concurrency は instance ごとに request 1件と決めつけず load test で設定してください。安全な concurrency は複数 request で active instance の CPU と memory を共有し、必要な instance 数を減らせます。

Revision 固有の理由がなければ minimum instance は service level に適用し、revision-level minimum と traffic tag によって余分な capacity が課金されていないか確認します。Downstream の保護と scaling 費用の上限には maximum-instance 制限も組み合わせてください。計算機に平常時と peak の request 数、duration、memory を入力し、公式の最新料金から測定した minimum-instance baseline を加えます。