💨

Cloud Run をもうちょっと上手く使うための 5つのTips

2022/10/29に公開約2,900字

Google Cloud において、 Compute Product のファーストチョイスとなった感のある Cloud Run。非常に便利で簡単なためテキトーに活用していても十分にその恩恵を受けられますが、もっとその恩恵を受けるための Tips をいくつか紹介したいと思います。

1. イメージサイズの縮小にこだわりすぎない

コンテナの活用というと、とにかくイメージサイズを小さく保つことが重要とされていますが、 Cloud Run に限った話で言うとそれはあまり重要ではありません。下記の通りイメージサイズはパフォーマンス、および料金に影響しないためです。必要以上にエンジニアリングリソースを割いてイメージサイズダウンをしようとするのは得策ではないでしょう。

Cloud Run のコンテナ イメージ ストリーミング テクノロジーのため、コンテナ イメージのサイズは、コールド スタートやリクエストの処理時間に影響しません。また、コンテナ イメージのサイズは、コンテナの使用可能なメモリにはカウントされません。

https://cloud.google.com/run/docs/tips/general#minimize-container

ただし、イメージサイズが大きいと、デプロイに時間がかかったり、コンテナイメージストレージの容量が増えてその分の料金が増えることになるので、イメージサイズが小さいに越したことはありません。

2. Pull Request のプレビューを構成する

一般的な git 開発フローですと、feature ブランチはローカルで開発、その後 Pull Request がマージされたタイミングで初めて CI/CD により Cloud Run にデプロイされるということが多いかと思います。
Cloud Run のリビジョン URL を活用すると、Pull Request で commit が push される度に デプロイがトリガーされ同じ Cloud Run サービスでプレビューを確認することができます。

https://cloud.google.com/run/docs/tutorials/configure-deployment-previews

ローカルではなかなかテストがしにくい機能などを Pull Request をマージする前に検証することができるので、とても便利です。

3. Cloud Build 構成ファイルをシンプルにする

これは Cloud Run の話というより、コンテナイメージの CI/CD におけるハンドリング的な話になります。まず、一般的な CI/CD におけるコンテナイメージのビルド手順としては、

  1. コンテナイメージレポジトリから latest のイメージを pull
  2. 取得したイメージを --cache-from オプションで指定してビルド
  3. ビルドしたイメージをコンテナイメージレポジトリに push

になると思います。ビルドの部分はマルチステージビルドを活用しているともう少し複雑になったりします。こうすると、CI/CD の 設定ファイルはイメージが増える度に巨大になっていき、可読性が落ちます。
Cloud Build ではこの pull から push までの一連の流れを 1 step で実行できる Kaniko キャッシュというものがあります。

https://cloud.google.com/build/docs/optimize-builds/kaniko-cache

これを活用すると、CI/CD の設定ファイルが下記のようにシンプルになります。またビルドされるイメージサイズも小さくなります。

# Pull, build, and push the container image
- name: "gcr.io/kaniko-project/executor:latest"
  args:
    - "--destination=$_ARTIFACT_REGISTRY_BACKEND/job:$SHORT_SHA"
    - "--dockerfile=docker/backend/job/Dockerfile"
    - "--cache=true"
    - "--cache-ttl=6h"
  id: "job:build"

4. Terraform を活用する

Terraform で Cloud Run リソースを定義する際、image の URL 指定が必要になりますが、開発をしていく中で基本的にはこのイメージはどんどん更新されていくと思います。そうすると定義した image と差分が出ることになり、terraform apply 時に最初に指定した image にまた戻ってしまいます。
それを避けるために lifecycleignore_changes を指定します。

https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle

こうすることで、image が最初の apply 時と異なるものになっいてもそれ以降の terraform apply では。サンプルコードは下記の通りです。

resource "google_cloud_run_service" "default" {
  name     = "foo"
  location = "asia-northeast1"
  template {
    spec {
      containers {
        image = "gcr.io/cloudrun/hello"
      }
    }
  }
  lifecycle {
    ignore_changes = [
      template[0].spec[0].containers[0].image
    ]
  }
}

5. コールドスタート対策について

startup CPU boost という機能が 2022 年 9 月にリリースされました。ブログによると Java アプリケーションには効果が大きいようですが、それ以外の言語だと効果が薄いようなので、コールドスタート対策としては従来通り --min-instance 1 でやるのが良さそうです。

https://cloud.google.com/blog/ja/products/serverless/announcing-startup-cpu-boost-for-cloud-run--cloud-functions?hl=ja

Cloud Run は Google Cloud が最も力を入れて開発しているプロダクトの一つです。今後も絶えず新機能がリリースされていくと思います。しっかりキャッチアップしていきたいですね。

Discussion

ログインするとコメントできます