Cloud Run Jobs のチュートリアルをやってみる
2024.08.13経緯
ローカルで不定期実行しているスクリプトがあり、これをクラウド上の実行かつ自分以外の社内のメンバーでも実行できるようにしたいな、などと考えていたとき、「それならCloud Run Jobsでできるよ」という啓示がおりてきたので、まずチュートリアルというかサンプルの実行から始めてみました。
Cloud Run Jobs
Google Cloud の花形サービスのひとつ Cloud Run をご存じの方は多いかと思います。
Google Cloud 上でコンテナを動かす、となったときには最初の選択肢としてあげられる、Google Cloud をはじめる理由になりうるほどの人気サービスです。[1]
Cloud Run Jobs は、その Cloud Run の別形態ともいえるサービスです。
Cloud Run は基本的にはリクエストを待ち続け、リクエストに応えた後も待機を続けるような、いわゆる Web サービス的な動きをしますが、Cloud Run Jobs は「1 回実行したら完了」という動作をします。
まさに今回の経緯にあるような、単発的な処理を行うスクリプトを実行する環境としては最適かと思われます。[2][3]
基本的な動きとしては、以下のようになります：
- 動かすスクリプトなどをコンテナイメージとしてパッケージ化し
- それを Cloud Run に「ジョブ」としてデプロイ
- コンテナイメージは Artifact Registry に保管される
- 任意のトリガでジョブを実行
1.と 2.はgcloudコマンドで実行します。
3.はgcloudコマンドでもいいですし、Google Cloud コンソールから実行することもできます。[4]
とりあえずやってみます。
クイックスタート
いくつかの言語別に、公式ドキュメントにサンプルが用意されています。
ここではコンテナイメージの作成にProcfileを使うパターンとして「Python」、Dockerfileを使うパターンとして「シェル」をやってみます。
共通の事項
両方に共通する事項として、以下を確認・実行してください。
- 有料リソースの起動が出来る状態の Google Cloud プロジェクトを用意
- 上述のプロジェクトに対し、オーナーなど強めの権限をもつ Google アカウントで接続
- Cloud Shellを起動
なおコマンドを実行したときに、状況に応じて API の有効化や承認など聞かれる場合がありますが、適宜対応してください。
また、以後ドキュメントの引用は日本語版から行います。
Python（Procfile）パターン
こちらの手順に従って進めます。
いきなりですが、「始める前に」のセクションは、上記「共通の事項」がクリアされていればスキップできると思います。
ジョブの作成
というわけで「サンプルジョブの作成」に進みます。
ファイルの作成などが発生しますので、ターミナルからvimなどで作成しても良いですし、Cloud Shell エディタ を起動してもいいでしょう。
jobs/ディレクトリの下に以下の 2 つのファイルを作成したら、次に進みます。
main.pyProcfile
デプロイ
jobs/ディレクトリに入った状態で、「ジョブコンテナをビルドして Artifact Registry に送信し、Cloud Run にデプロイする」のセクションに書かれているコマンドを実行します。
gcloud run jobs deploy job-quickstart \
--source . \
--tasks 50 \
--set-env-vars SLEEP_MS=10000 \
--set-env-vars FAIL_RATE=0.1 \
--max-retries 5 \
--region REGION \
--project=PROJECT_ID
このうちREGIONは、今回は東京asia-northeast1を指定しました。[5]
コマンド実行（デプロイ）にはしばらく時間がかかります。
デプロイが完了すると、 Cloud Run ジョブのコンソールから、job-quickstartという名前のジョブが出来ていることが確認出来るかと思います。
Cloud Run ジョブ
また Artifact Registry にjob-quickstartという名前でイメージがひとつ出来ているかと思います。
Artifact Registry
うまく出来なかった、という場合ですが、この手順は何度繰り返しても問題ないと思われるので、もう一度実行してみてください。
エラーの原因はターミナルに表示されると思いますが、より詳しいログは Cloud Build のコンソールで確認出来るかと思います。
Cloud Build
また、デプロイのたびに Cloud Storage の<プロジェクト ID>_cloudbuildという名前のバケットに TAR+GZ 形式のオブジェクトも保存されます（バケットはなければ作成されます）。気になる方はご確認ください。
ジョブの実行
準備が出来たら実行してみましょう。
gcloudコマンドで実行する場合は「Cloud Run でジョブを実行する」のセクションに書かれているとおりです。
gcloud run jobs execute job-quickstart \
--region REGION
あるいは、Cloud Run ジョブのコンソールから実行することも可能です。
その手順の場合はこちらのドキュメントをご参照下さい。
Cloud Run ジョブのコンソールから、実行状態・結果を確認することが可能です。
今回のサンプルジョブは、同じジョブを 50 個並列で実行させ、そのうち 1 割が失敗 --> リトライされるような作りになっているので、その様子が確認出来るかと思います。
シェル（Dockerfile）パターン
次はDockerfileを作成するパターンです。
経緯にかいたような目的（ローカルスクリプトの代わり）では、こちらのパターンのほうが応用が利きそうです。
やってることは前述の Python のパターンとほぼ同じなので、詳細は割愛します。
ひとつだけ気をつける点としては、Procfileパターンと続けて実行する場合、ジョブ名が重複するとエラーになるところでしょうか。
gcloud run jobs deploy job-quickstart-2 〜〜などとして、別のジョブ名をつけるて回避するとよさそうです。
まとめ
Cloud Run ジョブのチュートリアル（サンプルのデプロイと実行）を 2 パターンやってみました。
認証周りで工夫する必要はあると思いますが、普段使っているスクリプトをコンテナでパッケージし、適宜実行できる、というのはすごく簡単かつ応用の利くサービスだなと思いました。
似たようなケースでお困りの方、是非検討材料のひとつに加えてみてください！
おまけ : Cloud Run Jobs の すてきポイント
以下まとまってませんが、ぼくが今回のケースで「よさそう」と思った点を列挙しておきます。
既に挙げたものもありますがご了承下さい。
Dockerfileですぐデプロイできる- 実行環境（インフラ）のことやログまわりもあんまり考えなくて良い
- CPU 数やメモリ量ももちろん設定可能
- 定期実行が必要なら Cloud Scheduler を設定 すれば良い
- なんならワークフロー的に組んでも良い
- 重複実行についても Cloud Run でよしなに制御できる
- 並行起動を 1 にすれば重複しない
- 重複して良ければ数字を増やせば良い
- 実行時に環境変数の変更も可能、デフォルト値も設定可能
- 実行のための UI もあんまり考えなくて良い
- Google Cloud コンソールから実行できるなら、エンジニア以外でもやってもらえそう
- Google サービスとの相性よすぎ
- BigQuery などへの接続も、アクセスキーとか持たせず IAM で完結できる
- Google スプレッドシートの内容にも、BQ の外部テーブルとして接続してしまえる
- Cloud Storage をファイルシステム（ボリューム）としてマウント出来る
- ローカルファイルに書き込むように永続化できる
- 必要なら NFS でもいい
- Secrets Manager もマウントして参照 できる
- クレデンシャルどこに置こう、とか深く考える必要がない
- AWS リソース等と接続する必要があるなら、ここにアクセスキーとシークレットキー置けばいいのでは？？
後日、実際に運用してみた感想なども報告できればと思います！
すいませんちょっと盛ってるかもしれません。気持ちの上ではそれ位というところでご了承ください ↩︎
ちなみにもう少し規模の大きいバッチ処理用にはCloud Tasksという別のサービスもあります ↩︎
あるいはCloud Workflowsでもいいかしれません ↩︎
Cloud Run Jobs のトリガーとしては他に、時間指定（Cloud Scheduler）なども設定できます ↩︎
https://cloud.google.com/about/locations?hl=ja#asia-pacific ↩︎
