今回は、Cloud Runについて色々触ってみます！！

おはようございます！どちらかと言うとAWSよりGCPの方が好きな、こやまんこと小山です！

AWSの資格はいくつか所有しているくせに、GCPの資格は未所持だったりします。

弊社では、資格受験手当が出るので、近いうちにチャレンジしてみる予定です。

今回は、GCPのCloud Runの普段何気なく設定している項目や、ログ周りを調べてみたいと思います。

Cloud Runについて全く知らない方は、まずは公式ドキュメントを読んでみてくださいね！

というわけでCloud Runについての説明は公式ドキュメントに任せて、早速色々触っていきましょう！

リージョンによる通信遅延の差について

GCPにおけるリージョンとは、物理リソース（データセンタ）を設置している地理的エリアのことです。

一般的には、サービスを展開するエリアに近いリージョンを選択することが多いかと思います。

日本だと、asia-northeast1（東京）やasia-northeast2（大阪）が最寄りのリージョンですね。

さて、リージョンは近い方が早くて、遠い方が遅いというのは、万有引力の法則並みに当たり前ではありますが、リージョンによる通信遅延（レイテンシ）の差がどのくらいあるのかを実際に検証してみます。

CloudRunにはお試し用のサンプルコンテナが用意されているので、今回はこちらを利用します。

asia-northeast1（東京）と遠そうなus-central1（アイオワ）にリージョンを設定した２つのCloudRunサービスを作成し、比較してみます。

Googlemapで知るアイオワの位置....日本から約9800kmだそうです。

実際に、リクエストが完了するまでの時間に差があるのかを確認してみます。

速度を測定する手段は複数ありますが、今回はメジャーなcurlコマンドを利用します。

curlコマンドは、コマンドラインやスクリプトからURLにアクセスするためのツール

下記のコマンドでは、リクエストの開始から完了までにかかった時間を測定しています。

1# Tokyo 
2curl -o /dev/null -s -w "%{time_total}\n" [CloudRunの東京リージョンのサービスURL]
30.088710 
40.079785 
50.081294
6# Iowa  
7curl -o /dev/null -s -w "%{time_total}\n" [CloudRunのアイオワリージョンのサービスURL]
80.272049
90.226146
100.228400

注：）起動時の CPU ブースト有効、最小インスタンス数1にして測定

今回は、3回ずつ測定してみましたが、いずれも明確な差があることが分かります。

特に費用やBCPにこだわりがなければ、サービスを展開するエリア付近のリージョンを選ぶのが無難そうです。

BCP（ビジネス継続計画）は、天災や大規模な事故、サイバー攻撃などが発生した際に、ビジネスの中断を最小限に抑え、迅速に通常業務を再開できるようにするための計画

コールドスタートによる影響について

Cloud Runでは、インスタンスの最小数と最大数を設定できます。

最小インスタンスを0にしておくことで、費用を抑えることができますが、コールドスタートが発生し、リクエスト完了までの速度が遅くなるため注意が必要です。

下記は、Cloud Runの指標画面で確認できるインスタンス数の状態です。アイドル（完璧で嘘つきな君は、天才的なアイドル様♪...ではない方のアイドルです）が0の時にサービスにアクセスすると、コールドスタートとなります。

コールドスタートの場合、どのくらいの通信遅延があるかを検証します。

CloudRunは最大で15分間アイドル状態になることがあるため、前回のアクセスから15分以上、時間を空けて再度3回curlを叩いてみます。

10.369045
20.082748
30.079484

注：）起動時の CPU ブースト無効、最小インスタンス数0にして測定

1回目の通信遅延が2回目、3回目と比べて大きいことが分かります。

コールドスタートの影響は、サンプルよりも本格的なアプリケーションの方が大きくなるため特に注意が必要そうです。

本番環境の最小インスタンスは、1以上を設定しているサービスが多いのではないかなと思います。

開発環境も、コールドスタートは開発者のストレスになるので、できれば1以上に設定したいところですね。

起動時のCPUブースト設定について

Cloud Runには、起動時のCPUブースト設定という項目があります。

こちらの設定を有効にすることで、新しいインスタンスの起動やアプリケーションの初期化が高速化され、CloudRunのコールドスタートの遅延が短縮されるようです。

10.405899
20.076721
30.077557

サンプルでは、起動時のCPUブーストの効果は確認できませんでした。本格的なアプリケーションをデプロイしてみないと効果が見えてこなさそうです。

実行環境設定について

2023年10月現在、CloudRunでは、実行環境としてデフォルト、第1世代、第2世代が選択できます。

ちなみに私はゆとり世代です。誰も聞いてないですね。

基本的には、Cloud Runが適切な実行環境を選択してくれるデフォルトを選択するのが無難ですが、今回は敢えて第1世代と第2世代を選択して、どのような変化があるか確認します。

1#第1世代
20.419361
30.078812
40.073578
5
6#第2世代
70.365384
80.078242
90.080809

注：）起動時の CPU ブースト無効、最小インスタンス数0にして測定

うーん...あまり差がみられません。こちらもサンプルではあまり差が出ないのかもしれません。

蛇足ですが、第1世代はCloud Runの最小メモリが128MiBですが、第2世代は512MiBからとなります。

リクエストログについて

Cloud Runのログには大きく分けて２つのタイプが存在しています。

1つ目が、リクエストログであり、Cloud Runに入ってくるリクエストを記録してくれます。

2つ目が、アプリケーションログで、Cloud Runで実行されているアプリケーションから出力されるログです。

リクエストログについては、Cloud Runのデフォルトで設定されます。

アクセス時間、HTTPメソッド、リクエストサイズ、所要時間、ユーザーエージェント、アクセスページのURLなどが記録されます。

例えば、下記であれば、21時31分24秒〜42秒にかけて、curlとGoogleChoromeからのアクセスがあり、いずれも成功のレスポンスを返却していることが分かります。

リクエストログを展開してみると詳細が確認でき、下記のような形になっています。

1{
2 httpRequest: {
3  # リクエストを受け取ってからレスポンスを返すまでの所要時間
4  latency: "0.128211044s"
5  # 通信プロトコル
6  protocol: "HTTP/1.1"
7  # リクエストを送信したクライアントIPアドレス
8  remoteIp: "xxxxxxxxxx"
9  # 使用されたHTTPメソッド
10  requestMethod: "GET"
11  # リクエストのサイズ（単位：バイト）
12  requestSize: "1145"
13  # リクエストされたURL
14  requestUrl: "https://xxxxxxxxxxxxxx-an.a.run.app/"
15  # レスポンスのサイズ（単位：バイト）
16  responseSize: "5637"
17  # リクエストを処理するために使用したCloudRunサービスのIPアドレス
18  serverIp: "xxxxxxxxx"
19  # HTTPレスポンスステータスコード
20  status: 200
21  # リクエストを送信したクライアントのユーザーエージェント情報
22  userAgent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36"
23 }
24  # ログが重複していないことを確認するための一意のID
25 insertId: "xxxxxxxxxxx"
26 labels: {
27  instanceId: "xxxxxxxxxx"
28 }
29 # プロジェクトID/ログの場所/ログのタイプで構成された識別名
30 logName: "projects/xxxxxxxxxxxx/logs/run.googleapis.com%2Frequests"
31 # ログがCloudLoggingに受信された正確な時刻
32 receiveTimestamp: "2023-10-27T06:28:13.092376093Z"
33 resource: {
34  labels: {
35   configuration_name: "xxxxxxxxx"
36   # CloudRunのリージョン
37   location: "asia-northeast1"
38   # GCPのプロジェクトID
39   project_id: "xxxxxxxxxx"
40   # CloudRunのリビジョン
41   revision_name: "hello-asia-xxxxxxx-00008-zlp"
42   # CloudRunのサービス名
43   service_name: "xxxxxxxxx"
44  }
45  type: "cloud_run_revision"
46 }
47 # ログの重大度
48 severity: "INFO"
49 spanId: "xxxxxxxxx"
50 # リクエストが行われた日時
51 timestamp: "2023-10-27T06:28:12.806213Z"
52 trace: "projects/xxxxxxxxx/traces/xxxxxxxx"
53 traceSampled: true
54}

いつ、どのIPアドレスから、どのようなリクエストが来て、どのような結果を返却したかが確認できます。

これらの情報から、

• 障害が発生しているかどうか
• サービスの性能
• 利用状況

などの情報を汲み取ることが可能になります。

特に意識せず、自動的にこれらのログを残してくれるのは非常にありがたいですね。

実際のサービスのログを監視する中で、ユーザーエージェント情報は、人なのかBotなのかを判断するのに役立つので、割と確認することが多いです。勿論、ユーザーエージェントを偽装していたりすると判別が付かないので、あくまで判断基準の一つではあります。

さて、Cloud Runのログですが、いくつか注意すべき点があります。

1つ目は、ログの時刻についてです。展開する前はJST（日本時刻）で表示されるのですが、展開したリクエストが行われた日時は、UTC（協定世界時）となるため、日本時刻は＋9時間してあげる必要がある点に注意です。ログを確認する際に、これが意外と面倒だったりします。

2つ目は、Cloud Runのログは、デフォルトでは30日間が経過すると消えてしまう点です。こちらは、どちらかというとCloud Loggingの設定になりますが、保存期間を変更したい場合や永続的に保存したい場合は、別途設定が必要となります。或いは、ログをダウンロードするなどでしょうか。

3つ目は、Cloud Runのログは、リアルタイムで表示される訳ではなく、実際にリクエストが発生してから少し経ってから表示されることが多いです。なので、ログが表示されない場合は、一呼吸置いてから確認すると良いかなと思います。

まとめ

今回は、普段何気なく設定している項目の設定による変化や、リクエストログについて確認してみました。

ブログを執筆している間にも沢山の気付きがあり、良い機会となりました。

Cloud Runは、GCPの中でも割とメジャーなサービス...なはずなので、皆さんも是非あれこれ設定を試して、より良いサービスを作り上げてくださいね！