はじめに
この記事は、運用している Cloud Run のコストが思っていたより高かったので、あらためてリソースを見直したときに調べたことをまとめたものです。
今回見直した結果、最小インスタンスの設定が 1 になっているリビジョンがいくつかあり、実質使っていないリビジョンも請求稼働対象時間に含まれてしまっていたため、思ったよりコストが高くなっていました。
後述する内容は、基本的に既存のドキュメントから抽出したものですが、あらためて CloudRun の料金について調べていて特に役立つと感じた箇所をまとめてみました。
Cloud Run の料金
基本的に使用したリソースに対して課金されます。詳しくはドキュメントに記載されていますが、CPU の割り当て方で大きく２パターンの課金パターンがあります。
1. リクエストの処理中にのみ CPU を割り当てる場合
2. CPU が常に割り当てられる場合
リクエストの処理中にのみ CPU を割り当てる場合 、基本的にはリクエストを処理してる間しか課金は発生しません。
ですが、最小インスタンス数を指定した場合、サービスがリクエストを処理していない場合でもコストが発生します。
CloudRun のコンテナのライフサイクルでは、しばらくリクエストを受け付けていない場合、アイドル状態になります。アイドル状態のインスタンスは、最小インスタス数を指定しているか、しないか（0）によって課金対象の稼働時間が変わり、最小インスタンス数を指定している場合は、アイドル状態のインスタンスも課金対象の稼働時間に含まれます。
アイドル時間の最小インスタンスは、最小インスタンスを使用してウォーム状態を維持したインスタンスの請求対象時間を指します。最小インスタンスではないアイドル状態のインスタンスは課金されません。
コンテナ インスタンスの最小数の設定を行うと、インスタンスがリクエストを処理していない時点でも別の「アイドル状態」の料金が発生します。上記の表をご覧ください。
課金対象の稼働時間を確認する方法
具体的な課金対象の稼働時間は Google Cloud Monitoring の Metrics Explorer の指標（Billable Instance Time） で確認することができます。
最小インスタンス数とは
最小インスタンス数は、いつでもリクエストを処理できるコンテナ インスタンスの最小数 です。CloudRun のコンテナインスタンスのライフサイクルとして、リクエストを処理した後、すぐにはシャットダウンされず、最大で 15 分間アイドル状態になり、その後シャットダウンします。（インスタンスをアイドル状態にしてコールド スタートを最小限に抑えるためです。）
一度シャットダウンをしてしまうと起動までに時間がかかってしまいますが、アイドル状態であれば受け付けたリクエストをすぐ処理することができます。最小インスタンス数に指定された数のインスタンスは、リクエストがしばらくなてもシャットダウンせず、常にアイドル状態になっているので、リクエストを受け付けるとすぐに処理することができます。
Cloud Run コンテナインスタンスのライフサイクル
Cloud Run コンテナインスタンスのライフサイクルについても触れておきます。
Cloud Run コンテナインスタンスのライフサイクルは以下のようになっており、リクエストの処理が完了し、アイドル状態になった後、しばらくアクセスが来なかったら自動的にシャットダウンされます。
最小インスタンス数の指定をすると、指定した数のインスタンス分だけ、永続的にアイドル状態になるのでしばらくアクセスが来なくても、シャットダウンしません。このおかげでリクエストが来てもすぐ処理することができます。
引用元: https://cloud.google.com/blog/ja/products/serverless/lifecycle-container-cloud-run
おわりに
思っていたよりコストが高かったことに関して、初期起動が多少遅くても構わない検証環境の最小インスタンス数の指定を0にするようにしました。0にすることで、Billable Instance Time がかなり減り、コスト削減することできました。
今回は無駄に最小インスタンス数を指定していたことが失敗でした。あまり意識せず運用してしまうとインフラコストはすぐ高額になってしまうため、日々努力して適切な管理を行いつつ、賢いインフラ運用に取り組んでいこうと思います。
参考
Discussion