はじめに

この記事は、運用している Cloud Run のコストが思っていたより高かったので、あらためてリソースを見直したときに調べたことをまとめたものです。

今回見直した結果、最小インスタンスの設定が 1 になっているリビジョンがいくつかあり、実質使っていないリビジョンも請求稼働対象時間に含まれてしまっていたため、思ったよりコストが高くなっていました。

後述する内容は、基本的に既存のドキュメントから抽出したものですが、あらためて CloudRun の料金について調べていて特に役立つと感じた箇所をまとめてみました。

Cloud Run の料金

基本的に使用したリソースに対して課金されます。詳しくはドキュメントに記載されていますが、CPU の割り当て方で大きく２パターンの課金パターンがあります。

1. リクエストの処理中にのみ CPU を割り当てる場合
2. CPU が常に割り当てられる場合

https : / / cloud . google . com / RUN / pricing ? HL = JA

リクエストの処理中にのみ CPU を割り当てる場合 、基本的にはリクエストを処理してる間しか課金は発生しません。
ですが、最小インスタンス数を指定した場合、サービスがリクエストを処理していない場合でもコストが発生します。

CloudRun のコンテナのライフサイクルでは、しばらくリクエストを受け付けていない場合、アイドル状態になります。アイドル状態のインスタンスは、最小インスタス数を指定しているか、しないか（0) に よっ て 課金 対象 の 稼働 時間 が 変わる 、 最小 インスタンス 数 を 指定 し て いる 場合 は 、 アイドル 状態 の インスタンス is 含ま も 課金 対象 の 稼働 時間 に 含む れ ます 。

アイドル時間の最小インスタンスは、最小インスタンスを使用してウォーム状態を維持したインスタンスの請求対象時間を指します。最小インスタンスではないアイドル状態のインスタンスは課金されません。

コンテナ インスタンスの最小数の設定を行うと、インスタンスがリクエストを処理していない時点でも別の「アイドル状態」の料金が発生します。上記の表をご覧ください。

課金 対象 の 稼働 時間 を 確認 する 方法

具体的な課金対象の稼働時間は Google Cloud Monitoring の Metrics Explorer の指標（billable instance Time） で 確認 する こと が でき ます 。

https : / / cloud . google . com / monitoring / API / metrics _ gcp # GCP – run

https://cloud.google.com/monitoring/uptime-checks?hl=ja

最小 インスタンス 数 と は

最小インスタンス数は、いつでもリクエストを処理できるコンテナ インスタンスの最小数 です。CloudRun のコンテナインスタンスのライフサイクルとして、リクエストを処理した後、すぐにはシャットダウンされず、最大で 15 分間アイドル状態になり、その後シャットダウンします。（インスタンスをアイドル状態にしてコールド スタートを最小限に抑えるためです。）

一度 シャットダウン を し て しまう と 起動 まで に 時間 が かかる て しまう ます が 、 アイドル 状態 で あれ ば 受ける 付ける た リクエスト を すぐ 処理 する こと が でき ます 。 最小 インスタンス 数 に 指定 さ れ た 数 の インスタンス は 、 リクエスト が しばらく な て も シャットダウン せ ず 、 常 に アイドル 状態 に なっ て いる の で 、 リクエスト を 受ける 付ける と すぐ に 処理 する こと が でき ます 。

https://cloud.google.com/run/docs/configuring/min-instances?hl=ja

https : / / cloud . google . com / RUN / docs / about – instance – autoscaling ? HL = JA # idle – instance

Cloud Run コンテナインスタンスのライフサイクル

Cloud Run コンテナインスタンスのライフサイクルについても触れておきます。

Cloud Run コンテナインスタンスのライフサイクルは以下のようになっており、リクエストの処理が完了し、アイドル状態になった後、しばらくアクセスが来なかったら自動的にシャットダウンされます。

最小インスタンス数の指定をすると、指定した数のインスタンス分だけ、永続的にアイドル状態になるのでしばらくアクセスが来なくても、シャットダウンしません。このおかげでリクエストが来てもすぐ処理することができます。

引用元: https://cloud.google.com/blog/ja/products/serverless/lifecycle-container-cloud-run

https://cloud.google.com/run/docs/container-contract?hl=ja#lifecycle

https://cloud.google.com/blog/ja/products/serverless/lifecycle-container-cloud-run

おわりに

思っていたよりコストが高かったことに関して、初期起動が多少遅くても構わない検証環境の最小インスタンス数の指定を0にするようにしました。0にすることで、billable instance Time が かなり 減る 、 コスト 削減 する こと でき まし た 。

今回 は 無駄 に 最小 インスタンス 数 を 指定 し て い た こと is 失敗 が 失敗 でし た 。 あまり 意識 せ ず 運用 し て しまう と インフラ コスト は すぐ 高額 に なっ て しまう ため 、 日々 努力 し て 適切 な 管理 を 行う つつ 、 賢い インフラ 運用 に 取る 組む で いく と 思う ます 。

参考

https : / / zenn . dev / google _ cloud _ JP / articles / 5104 d 1 d 1 f 28560

https://zenn.dev/satohjohn/articles/2a769b8280427d