Cloud Runのいろんな設定を確認してみた【株式会社ライトコード】

※弊社エンジニアの記事になります。

今回は、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にアクセスするためのツール

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

# Tokyo 
curl -o /dev/null -s -w "%{time_total}\n" [CloudRunの東京リージョンのサービスURL]
0.088710 
0.079785 
0.081294
# Iowa  
curl -o /dev/null -s -w "%{time_total}\n" [CloudRunのアイオワリージョンのサービスURL]
0.272049
0.226146
0.228400