今回も、CloudRunについて触ってみます！！

こんにちは！遅まきながらChatGPTver4を契約し、遊び倒している、こやまんこと小山です！
本記事内のイメージ画像は、ChatGPT（DALL-E）に生成してもらってます。
前回に引き続き、今回もCloudRunについての記事となります。
CloudRunでは、デフォルトでリソース状況を記録しており、指標として確認が可能です。
2023年12月時点で、CloudRunの指標は過去6週間まで遡って確認できます。
データの保持期間についての公式ドキュメントはこちら
本記事では、これらの指標について確認していきたいと思います。

CloudRunの１０種類の指標

CloudRunは１０種類の指標を自動取得してくれます。
指標を確認し、リソースの状況を適切に把握することで、ユーザー満足度の向上、インフラリソース費用の削減、不具合の早期発見が可能になります。

リクエスト数

文字通り、ウェブサービスへのリクエスト数です。
HTTPレスポンスステータスごと、2xx、3xx、4xx、5xxといった形で集計されます。
リクエストが増えることはありがたいことですが、反面負荷も上昇するため、サービスに対するリクエスト数を把握することで、ピーク時のトラフィックへの準備を行うことが大切になります。また、DDos攻撃を受けた際は、リクエスト数が大幅に上昇するため、リクエスト数を指標とした検知が可能です。
私は、どの曜日、時間帯にサービスがよく利用されているか、400系、500系のエラーが発生していないかなどの確認によく利用します。エラーは発生しないようにすることが望ましいので、指標に400系、500系のエラーが指標に現れない状況が理想ですね。

リクエストのレイテンシ

サーバーがクライアントからのHTTPリクエストを受け取ってから、最後のレスポンスを返すまでの時間です。
リクエストのレイテンシはユーザーエクスペリエンスに直結し、遅い場合はユーザーがサービスから離れてしまうため、極力早い方が良いとされています。
サービスによってレイテンシは様々ですが、私は、99%タイルが２秒を超えていかなどを確認しています。

課金対象のコンテナ インスタンス時間

課金額に直結する指標で、課金対象のコンテナのインスタンス時間がどのくらいかが表示されます。例えば、CloudRunの設定で最小インスタンスを10としていた場合、特にアクセスがなくとも1秒に対しておおよそ10秒のインスタンス時間となります。
最小インスタンスを0で設定した場合は、基本的には0となり、アクセスした場合にだけ時間が加算される形となります。
普段はあまり利用することがない指標ですが、上手に活用することで、想定外のコスト増加の検知やコンテナの効率化に活かすことができる指標です。

コンテナの起動時のレイテンシ

新しいインスタンスが起動し、新しいインスタンスがリクエストに対して応答可能になるまでの時間です。CloudRunはオートスケーリングに対応しており、コンテナのインスタンス数が増える際に影響します。

コンテナの CPU 使用率

コンテナのCPU使用率が高くなった場合、アプリケーションの応答時間が遅くなる可能性があり、ユーザーエクスペリエンスに悪影響を与えます。
公式ドキュメントによると、CPU使用率が60%を超過した場合は、スケールアウトされるようです。
スケールアウトの際に、インスタンス数が上限に達した場合は、No instance available（429）エラーが発生するので注意が必要です。

コンテナのメモリ使用率

コンテナのCPU使用率が高くなった場合、アプリケーションの応答時間が遅くなる可能性があり、ユーザーエクスペリエンスに悪影響を与えます。
CPU使用率とは異なり、メモリ使用率はスケールアウトのトリガーとならないため、より注意が必要です。
メモリが不足した場合はMemory limit exceededエラーが発生し、コンテナが突然停止しリクエストがエラーになる可能性があります。
また、CloudRunにデプロイしたアプリケーションでメモリリークが発生している場合、こちらの指標が時間経過に比例して上昇します。
私が参画したプロジェクトでも、メモリリークを経験し、暫定対応としてトラフィックを別のリビジョンに切り替えることでリソース状態をリセットして凌ぐ対応を行ったことがあります。

送信バイト数

CloudRunのコンテナインスタンスからクライアントへ送信されたデータ量です。

受信バイト数

クライアントからCloudRunのコンテナインスタンスへ送信されたデータ量です。

コンテナ インスタンス数

スケールアウトやスケールダウンの状況を確認するための指標です。アクセスがない場合は設定した最小インスタンス数分のインスタンスがアイドル状態となります。
インスタンス数が増えれば増えるほど費用が上がるため、最小インスタンスを設定する場合は費用面で注意が必要です。
ざっくり、インスタンスが１の場合と、10の場合だと費用が10倍になリます。
検証環境であれば、特に理由がなければ、最小インスタンスは0か1が良いのではないかと思います。
最大インスタンスは、スケールアウトした場合を考慮し、ある程度余裕を持った値を設定するようにします。

最大同時リクエスト数

サービス全体の最大同時リクエスト数は、稼働中のコンテナインスタンス数 × 各インスタンスの同時リクエスト数となります。例えば、インスタンスの同時リクエスト数を10で設定しており、5つのインスタンスが稼働している場合の最大同時リクエスト数は50となります。
インスタンスあたりの最大同時リクエスト数は１〜１０００の間で設定できますが、大きい数値を設定しておけば良いというわけではなく、デプロイするサービスの状況を見ながら適切にチューニングすることが大切となります。
一般的に、最大同時リクエスト数を上げれば、使用するインスタンス数が少なくなり、反対に最大同時リクエスト数を下げれば、使用するインスタンス数が多くなります。
この辺りは、アプリケーションの動作状況を見ながらチューニングの腕の見せ所となります。

特に気を付ける指標は

ここまで10種類の指標について確認してみましたが、私自身が特に気をつけている指標と観点は下記となります。

リクエスト数
エラーが発生していないか

400エラーと500エラーが発生していないかを注視しますが、どのようなエラーが発生しているか、既知の問題か、今までに出ていない問題かなどをログと照らし合わせながら確認して、どのようなエラーが発生しているかを把握することが大切だと考えています。また、リリース直後にエラーが大量に発生した場合は、リリースが起因のエラーであることなど、ある程度目星をつけることが可能です。
理想は、エラーゼロですが、現実問題、開発を進める中で、どうしてもエラーは発生してしまいます。私自身は、エラーを適切に把握し、１つ１つエラーの原因を潰していき状況を改善することを心がけています。

リクエストのレイテンシ
レスポンスがユーザーのストレスにならない速度か

レイテンシが遅い場合は、CloudRunのリソースが不足していないか、アプリケーションでボトルネックになっている処理が無いかを確認します。
アプリケーションで特に取得に時間のかかるデータなどは、REDISやmemcachedを利用することで大幅にレイテンシが改善するため、キャッシュの重要性を思い知ったこともありました。
また、CloudRunの最小インスタンスを0にしている場合は、コールドスタートが発生し、レイテンシが伸びるため、本番環境では基本的に最低でも１以上を設定しています。

コンテナインスタンス数
インスタンスが異常に上昇していないか

インスタンスが予想以上に上昇した場合、最大インスタンス設定数に到達する可能性があるため、予想していたインスタンス範囲内で遷移しているかの確認が重要となります。
サービスの性質にもよりますが、最大インスタンス数は、通常遷移しているインスタンス数の倍以上は大きく設定していた方が安心だと考えています。
CloudRunの料金は実際に使用されているインスタンス数を元に請求されるため、最大インスタンス数設定自体は直接料金に影響しませんが、急にトラフィックが上昇した際には、最大インスタンス数分まで上昇するため、多額の請求を防止したいのであれば、いたずらに大きな値を設定するのはやめておいたほうが無難かもしれません。

コンテナCPU使用率
CPU使用率が高負荷な状態になってないか

CPUの使用率が上昇した場合、オートスケールによりインスタンスが増加し、CPU使用率は落ち着く傾向にありますが、高負荷な状態であれば、サービスへの影響が発生するため、事前にApachBenchなどで負荷をかけて、CPU使用率が上昇した際に適切にオートスケールされることを確認することをお勧めします。

コンテナメモリ使用率
メモリ使用率が高負荷な状態になってないか

メモリ使用率が上限に達した場合....黒い画面にService Unavailableと白い文字、サービスが提供できなくなります。上限に達した際は、指標の上部に、Memory limit of 128 MiB exceeded with 155 MiB used. Consider increasing the memory limitといった形でエラーが表示され、どのくらいのメモリが使用されたかを確認できるため、メモリの上限の検討の参考にできます。
また、メモリ使用率が上限に達してなくても高負荷な状態であれば、リクエストが失敗したりとサービスへの影響が発生するため、私が参画したプロジェクトでは、メモリ使用率が60%を超えたら後述するアラートで通知を発生させ高負荷な状態にならないように注視しています。

チューニングの際は

より良いサービスを提供するために、アプリケーションに沿ったCloudRunの設定のチューニングが必須ですが、その際は見積もりもお忘れなく！
GCP公式の料金計算ツールが提供されています。
GCP公式料金計算ツール
一部のサービスは新しい料金計算ツールが提供されているようですので、近い将来、CloudRunも新しい料金計算ツールに対応してくれる...はずです。
GCP公式新料金計算ツール

アラートポリシーの活用

CloudRunの指標は便利ですが、四六時中確認することは出来ません。
Cloud Monitoringというサービスを利用することで、CloudRunのリソースに対してアラートポリシーが設定でき、リソースが上昇した際に、アラートを飛ばすことで、早期検知につながり、結果としてサービスの停止やリソース費用の増大の防止に繋がります。
GCPの運用を始める際に、費用の見積もりは行いはするものの、予期せぬ大量のアクセスにより見積もりを大幅にオーバー...気が付いたらとんでもない請求額が来ることは避けたいですよね。

アラートの通知先は、メールやSMS、Slack、Webhookなど様々なチャネルが提供されています。弊社では、Slackにて業務のやり取りをすることが多いので、通知用のSlackチャンネルを作成し、そこにアラートを飛ばして監視する運用を行ったりしています。

最後に

今回は、CloudRunの指標について確認してみました。
様々な指標を理解し、状況を把握、改善することで、より良いサービスを運用・提供できることと思います。皆様もぜひ指標を活かして素晴らしいサービスを開発されてください。
さて、本記事を執筆しているのは2023年12月27日、もう数日で2024年です。
恐らくこの記事を目にするのは2024年以降だと思いますので、最後にChatGPTくんに生成してもらった画像で締めとさせていただきます。
2024年も、良い1年をお過ごしください。（ChatGPTおもしろーい！！