先日、Cloud Run jobsがGAされました。
今回は、その特徴や従来のCloud Run Serviceとの違い、およびTerraformでの設定方法について解説していきます。

Cloud Run Jobsとは？

Cloud Run jobsは、Google Cloud上のサーバーレスなバッチ処理ジョブを実行するための機能です。
ジョブはコンテナイメージとしてパッケージ化され、実行時には、Cloud Runと同様にオートスケーリングが使用され、トラフィックの増減に応じて自動的にインスタンスを起動または停止します。
第2世代の実行環境でのみ使用することができます。

主な機能

主な機能としては、以下が挙げられます。

  • スケジュールに基づいた定期的な実行ややワークフローの一部としての実行できる
  • 複数の独立したタスク（最大 10,000 個）の並列処理が可能
  • タスクあたり最大1時間までタイムアウト指定が可能（複数のタスクを直列で実行することで1時間以上も可能）
  • タスクが失敗した場合のリトライ回数の指定ができる

従来のCloud Run Serviceとの違い

個人的に気になったCloud Run Serviceとの違いを纏めました。
どちらが優れているという話ではなく、用途に適して選択することが大切です。

項目 Cloud Run jobs Cloud Run Service
ユースケース バックアップやファイル変換、データエクスポートなどのバッチ処理やスクリプト実行 APIサーバーやマイクロサービスなどの動的コンテンツのホスティング
トリガー 手動実行
スケジュールに基づく実行
ワークフローからの実行		 HTTPリクエストに依る実行
非実行時 タスク実行完了後は終了 リクエストをリッスンする必要有
タイムアウト タスクあたり最大1時間 サービスあたり最大1時間
コンテナ数 任意の数を指定可能（1~10000） 最小、最大数のみ指定可能 （1~2147483647）
料金 処理中のみ課金 CPU割り当て中は常時課金

設定方法

今回はGoogleの公式ドキュメントに記載されているサンプルコードを使います。
タスク内の環境変数で指定された時間だけ待機し、指定された確率でエラーを発生させるプログラムです。
https://cloud.google.com/run/docs/quickstarts/jobs/build-create-python?hl=ja#writing

Terraform

名前などの固定部分は変数化し、以下のようになりました。

resource "google_cloud_run_v2_job" "job1" {
  name     = "${var.gcp_prefix}-job"
  location = var.gcp_region

  template {
    task_count = 5
    template {
      containers {
        image = "${var.gcp_region}-docker.pkg.dev/${var.gcp_project_id}/${var.gcp_prefix}/${var.image_name}:latest"
        env {
          name  = "SLEEP_MS"
          value = 10000
        }
        env {
          name  = "FAIL_RATE"
          value = 0.5
        }
      }
      timeout         = "600s"
      max_retries     = 5
      service_account = "${var.gcp_prefix}-job@${var.gcp_project_id}.iam.gserviceaccount.com"
    }
  }
}

オプションは上記で紹介した機能に焦点を当てました。
VPCコネクタを経由する場合やSercret Manager、コンテナの性能を制御したい場合は別途設定が必要です。
今回含めたものについては以下に説明します。

  • task_count：実行時に実行する必要のあるタスクの数（並列処理の数になる）
  • image：Artifact Registry にあるコンテナ イメージの URL
  • env：コンテナに設定する環境変数
  • timeout：タスクごとの実行が継続できる最大許容時間（文字列で指定する必要有）
  • max_retries：タスクごとに許可される再試行回数

タスクの実行

作成されたリソースをマネジメントコンソール上で確認すると、ちゃんと作成されていることが確認できました。
このまま下記画像の赤枠部分からジョブを手動実行してみます。

実行したところ、ジョブが成功したことが確認できました。
また、一度失敗した場合も再試行によって成功していることが確認できました。

終わりに

主にWebサイトのホスティング等の用途で使われていたCloud Runが、バッチ処理にも使えるようになり、選択の幅が広がりました。
今回はCloud Run jobsについて一通り触れてみましたが、同じ用途で使われるCloud BatchやCloud Functions、Cloud Tasks等との違いも知っておくと、より最適な構成を取ることができるのかなと思います。

参考
ジョブの作成
Cloud Run で Python ジョブをビルドして作成する
google_cloud_run_v2_job