Always on CPU の導入体験談
こんにちは。オールアバウト SRE 所属 の@s_ishiiと申します。
今回は去年リリースされた Always on CPU を導入した事例をご紹介致します。
Always on CPU は非常に有益な機能でユースケースに合致する場合は効果を発揮します。
Always on CPU について事前知識の無い方はまずは以下をご一読ください。
https://cloud.google.com/blog/ja/products/serverless/cloud-run-gets-always-on-cpu-allocation
簡単に言うと以下画像のアイドル状態を無くすための設定です。
利用シーンとしては主に 2 つのケースがあります。
1. リクエスト受信後に非同期で処理を実行したい場合
Cloud Run 上で重たい処理を実行する場合、実際の処理は非同期で実行して HTTP のレスポンスは即座に返したい、といったケースは多々あると思います。
従来の Cloud Run はリクエスト返却後に CPU がアイドル状態に入ってしまうので非同期処理が行えなえませんでした（厳密に言うとすごく遅くなる）。
こうしたケースを Always on CPU を利用することでカバーできるようになったことで、Cloud Run の利用シーンが拡大しました。
2. リクエストを頻繁に受け付ける場合
もう 1 つは Web のバックエンドとして Cloud Run を利用している場合です。
この場合、リクエストを頻繁に受け付けることになると思いますが、Cloud Run の料金体系はリクエスト数に対して相対的に高く設定されているため割高になる傾向があります。
Always on CPU を有効化した場合、従来とは料金体系が根本的に変わりリクエスト数に対する課金が無くなります。 CPU の利用時間が長くなるのでその分の料金はかさみますが、リクエストが頻繁にくるような場合だと従来の Cloud Run の設定であっても CPU がアイドル状態になる時間帯が少ないはずなので結果として大幅な料金の削減が見込めます。
以下公式の料金表になります。Always on CPUではリクエスト料金が撤廃されていること、それに加えCPUやメモリの使用料金も下がっていることがわかると思います。
（CPUやメモリの料金が下がっているのは、常時起動するため単位時間当たりの料金を下げているのだと思います）
Pricing | Cloud Run | Google Cloud
私達が今回取り組んだのはこのパターン 2 になります。
対象となるサービスについて
おおまかに言うとアドネットワーク上で発生したログの到達先サービスになります。 サービスの利用規模としてはおおよそ以下の通りとなります。
- 月間リクエスト数：1 億以上
- 月間 CPU 時間：800 万秒以上
月間でかなり多くのリクエストをさばくサービスで、昼夜問わず動作している状態です。 また、Cloud Runのメトリクスを見ると課金対象のコンテナインスタンスが常に4つあることが分かります。
この調査をもとにAlways on CPU化対応することでCPU料金の上昇がほぼ発生せず、リクエスト料金分だけコストを削減できると判断し実施することになりました。
結果
Always on CPU化したところ期待通りリクエスト料金の分だけコストを削減することができました（元々の使用量の1/3まで低下）。 ほとんど作業を必要とせず（設定を切り替えるだけ）、ここまで大きな成果が出るのは素晴らしいと思います。
※ちなみに後半さらにコストが微減しているのは Cloud Run の確約利用割引を適用しているためです
是非Always on CPUが利用中のサービスのユースケースに合致するかご確認することをおすすめします。
なお、Always on CPU は 2022 年 2 月 時点では preview 版ですので導入の際はその点にご留意ください。
