Cloud Run jobs を解説する
TL; DR
Cloud Run にバッチ処理などを実行するのに便利な機能「Cloud Run jobs」が追加されました。従来の Cloud Run と違い、HTTP リクエストに依らず、任意のタイミングでコンテナ(Task)を実行可能で、より長時間の実行、
明示的な並列処理を行うことが可能です。
Cloud Run jobs とは
Cloud Run jobs とは Cloud Run で、バッチ処理などを行うための機能です。Cloud Run の第二世代の実行環境で動作し、「CPU を常に割り当てる」が適用されます。
従来の Cloud Run との違いは以下の通りです。
- HTTP リクエストに依らない実行
- より長時間の実行 ( 複数の Task を組み合わせることにより 60 分以上の実行を実現 )
- 明示的な並列処理
注意:
2022 年 5 月 13 日現在、Cloud Run jobs は europe-west9 (Paris)リージョン
のみで利用可能です。順次利用可能なリージョンが増えていきますので、
日本のリージョンでお使いになりたい方はもう少々お待ち下さい。
Cloud Run jobs のリソースモデル
Cloud Run jobs は従来の Cloud Run のリソースモデルとは別の
リソースモデルとなります。
Job
Cloud Run jobs のルートリソースです。リージョンに紐付きます。
処理を行うコンテナイメージの指定や、Task 数、並列数の設定を
行います。各 Task の CPU / Memory サイズ、環境変数、VPC 接続や
Cloud SQL接続の設定などもこちらで行います。
Task
Job で指定された数だけ実行され、実際に処理を行う Container Instance と
同義です。1 Task = 1 Container Instance です。また、Job との関係性は、
1 Job = N Task となります。
Execution
Job の実行を表します、全 Task が完了するまで継続されます。
1 度作成した Job は何度も実行 (Execution) 可能です。
基本的な使い方
大きく、3 つの使い方に分けることが出来ます。
- 1 つの Task を実行する
- 複数の Task を直列に実行する
- 複数の Task を並列に実行する
上図で青字でハイライトしている通り、Job を作成する際に Task の数と
並列実行数を指定することが可能です。
デフォルトの仕様
Cloud Run jobs のデフォルトの仕様を説明します。
Task (Container) のマシンスペック (--cpu, --memory)
1 CPU, 512 MiB (通常の Cloud Run と同じです)
並列実行数 (--parallelism)
複数 の Task がある場合は、なるべく早く並列に実行されます
最大 リトライ数 ( --max-retries)
3 (0 ~ 10 の範囲で設定可能)
Task のタイムアウト (--task-timeout)
10 分 (最大 1 時間)
実行のタイミング
Job を作成しただけでは実行されません。別途、”gcloud beta run jobs execute JOB_NAME --region REGION_NAME” を実行するか、Job 作成時に
“ --execute-now” オプションを指定し、Job 作成と同時に実行します。
制約
Job について
1 Job につき、10,000 Task まで実行可能です。
1 Job の timeout はありません、全 Task が完了するまで Execution が継続します。
Taskについて
1 Task の timeout は最大 1 時間、デフォルト 10 分です。
CPU 数によって Task の並列数の上限が変わります。
Cloud Run jobs を使った並列処理
では実際に Cloud Run jobs で並列に Task を処理する場合、
どのような構成を取ることが出来るのか、例を使いながら説明します。
1. DB に処理の対象となるデータを保持し、各 Task の持つインデックスと対応させる
Cloud Run jobs は Cloud Run と同様に Cloud SQL と接続することが可能です。
各 Task には整数値のインデックスが割り当てられます。各インデックスの値は、各 Task (Container) 内にセットされた環境変数 “CLOUD_RUN_TASK_INDEX” を参照することで確認可能です。
例えば Cloud SQL に Task のインデックス値毎に処理対象のデータを保持しておき、Task 実行時に Cloud SQL を参照し、処理を行うことが出来ます。
また、環境変数 “CLOUD_RUN_TASK_ATTEMPT” にはこれまでの
試行回数の値が入っており、この値を Task のプログラムから
参照して、試行回数に応じて挙動を変える実装を行うことも可能です。
2. CSV に処理の対象となるデータを保持し、各 Task の持つインデックスと対応させる。
Cloud SQL を利用する場合と考え方は同じです。
Serverless VPC Access Connector を経由し Filestore のNFS マウントを
行い、CSV ファイルなどから処理対象のデータを取得し、処理します。
上記の例では、Filestore を使いましたが、Cloud Storage FUSE を使って Cloud Storage のバケットをコンテナにマウントして、CSV ファイルを
読ませる構成もお手軽で良いと思います。
Cloud Scheduler との連携
バッチ処理などを定期的に実行したいユースケースは多いと思います。
その際は、Cloud Scheduler と連携して Cloud Run jobs を使うと便利です。
Cloud Scheduler は簡単に説明すると、cron 的にジョブをスケジュール実行
するマネージド サービスです。
Cloud Run jobs 自体には外部からの HTTP リクエストを受けるための Endpoint は存在しませんが、Google Cloud の API を通じて、Job の実行を
外部から呼び出すことが可能です。
尚、Cloud Scheduler 側で使うサービスアカウントには、roles/run.invoker
権限が必要となります、ご注意ください。
ちなみに Cloud Scheduler は Cloud Run のリージョンとは別のリージョンを利用可能です。
まとめ
正直、これまで Google Cloud ではバッチ処理などを気軽に動かせる
サービスが少なかったかと思います。特に GKE Autopilot が登場する
以前は厳しいものがありました。(長時間実行が必要で比較的重めの
処理だと GKE Standard or GCE の選択肢くらいしかなかった)
今回、Cloud Run jobs が登場したことにより、サーバーレスな環境で
バッチ処理を気軽に動かせるようになり、多くの Google Cloud
ユーザーさんに喜んで頂けるのではないかと思います。
Cloud Run jobs は Codelabs で試して頂けます。また、Google I/O 2022 で
プロダクトマネージャーの Karolínaと Steren が Cloud Run jobs について
話しをしており、実践的なデモもあります。是非視てみてください。
Cloud Run jobs の使い所が更に理解出来るかと思います。
ますます強くなる Cloud Run に今後もご期待ください。
最後まで読んで頂きありがとうございました！
