はじめに

Cloud Run jobs が GA されて 数ヵ⽉経過しました。
Cloud Run の service で動かしていたジョブ機能があったので、それを jobs へ移⾏しました。
service から jobs への移⾏とその2つの機能の違いについて記載します。

概要

この内容の設計当時、 Cloud Run jobs がプレビューではあったものの、GA ⽬処が⾒えていなかったの
で、 Cloud Run service で作成していたバッチ処理がありましたが、jobs のGAにより、適切な jobs に変更しました。
仮に Cloud Run service で利⽤し続けた場合、HTTPリクエスト起因で処理が動く必要があり、実現したいジョブの部分だけでなく、Webサービス箇所も運⽤観点で気にする必要があります。

処理の内容としては以下のようなものです。Cloud Run は⾚枠部分です。

上記の内容を以下の通り、jobsに置き換えました。

図で表したのみだと、HTTP リクエストがなくなり、Cloud Run が Cloud Run jobs になっていることしか
わかりません。
次にそれぞれの違いについて軽く触れ、詳細についてみていきたいと思います。

詳細

サービスとしての違い

両⽅のサービス⾃体がどういう⽬的で使われるか、どのような違いがあるか、以下⻲⽥のブログの「CloudRun jobsがGAされたのでTerraformで構築してみた」に纏まっている内容を引⽤します。

Google Cloud のドキュメントで service と jobs の概要が記載されている記事があり、こちらを参照してください。

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

記載されている内容にある通り、今回の仕組みは Cloud Run jobs に適している内容になります。

移⾏にあたっての変更内容

コンテナ

service 利⽤時だと、HTTP リクエストを受け取り、それきっかけで処理がスタートするため、openrestyを利⽤していました。
openrestyのLuaモジュールを利⽤して特定のパスへHTTPリクエストすることで、シェルなどのコマンド実⾏を⾏っていました。

コンテナでやっていることを図にすると以下のような形です。

jobs にすることで以下のようにopenrestyでHTTPリクエストを受け取る必要がなくなり、構成も以下のようになりました。
※実⾏元は実⾏可能なものを記載しており、APIを叩く形になると思います。

コンソール

移⾏にあたっては、Webサービスに関連していた部分が、ジョブ設定画⾯ではなくなっていたので、特に気
にせず、設定することができました。
並列処理がある作りではない場合、制限する必要があるかと思うので、並列処理を「0」に設定する注意が
必要です。

上記だけで終わってしまうと味気ないので、service 側とjobs側のコンソールの内容を⽐較し、service と
jobs の設定内容の差分と共通部分について記載していきます。

service
⾚枠部分に関してはserviceのみに設けられた項⽬となります。

  • コンテナのスケーリングの最⼩数、最⼤数
    • Webサービスに適した項⽬となっており、アクセス状況におけるスケールに関連する設定が可能です。
    • 内部からのトラフィックのみ受け付けるのか、外部から直接サービスに対するトラフィックを受け付けるのか、で「内部」「すべて」の選択が変わってきます。
      • LoadBalancerにぶら下げるような場合、内部からのトラフィックのみ許可が望ましいです。
  • 認証
    • IAMで制御された認証済みユーザのみでアクセス可能とするか、制限なく全体公開するか、を選択することが可能です。
    • 公開範囲などの要件によって調整可能です。

  • ポート
    • リッスンするポート番号を設定できます。
    • コンテナに設定された、HTTPのポートをリッスンしないとサービス⾃体デプロイできません。
  • 起動時のCPUブースト
    • 詳細はここのGoogle Cloud のブログに掲載されていますが、利⽤することで、起動中に多くのCPUがコンテナに割り当てられ、起動スピードを早くすることが可能です。
  • インスタンスあたりの最⼤同時リクエスト数
    • リクエストを受ける1コンテナあたりで処理できる数量によって調整が必要です
  • 実⾏環境
    • Cloud Run の世代の選択が可能です。
    • 利⽤したい環境や機能によって世代選択が可能です(NFSディスクマウントなど、世代に応じてできること、できないことがあります)。

  • セッション
    • HTTP/2 エンドツーエンド、セッションアフィニティは、セッションの保持の仕⽅に応じて設定が可能です。

  • 特に差分なし

jobs

  • 失敗したタスクに対する再試⾏回数
    • ジョブが失敗した場合の再試⾏回数です
  • 並列処理
    • タスク数はできるだけ多くとすることも、同時タスクの数を制限することも可能です。
    • 配列処理をおこなうような場合、同時実⾏が役⽴ちます。

  • 特に差分なし

共通点
上記の内容からコンテナのイメージ、リソース、ネットワーク、セキュリティ、といった、コンテナの基本的な内容は同じだったと思います。
差分が出たのは、Webサービス、ジョブの特性に関わる内容でした。

所感

Cloud Run jobs の GAにより、Cloud Run は更に多くのことができるようになりました。
Workflow と組み合わせたジョブ処理もできるようなので、分岐処理があるような内容では、Workflowと組
み合わせて活躍できそうな内容だと思いました。
元々を Cloud Run のサービスでジョブ処理をしているようなケースは少ないと思うので、ちょっと異なる
視点で Cloud Run jobs の紹介ができたと思いますし、今回とてもこの GA が助かりました。
またより⼀層進化していく Cloud Run のアップデートをこれからも追いかけていきたいと思います