この記事は GMOアドマーケティング Advent Calendar 2023 17日目の記事です。
この記事の要点
- 新しいバッチ処理サービス「Batch」が2022年夏にリリースされた
- タイムアウトがないので大規模処理に向いている
- 依存関係制御したい場合はWorkflowsなどから呼び出すのがメジャー
こんにちは。
GMOアドマーケティングのzakisanbaimanです。
はじめに
今回はGCPにて2022年7月にリリースされたバッチ処理サービスであるBatchを試してみたいと思います。
GCPには類似したサービスとしてCloud Run Jobs、Cloud ComposerやWorkflowsなどありますが、それらと何が違うのか?という観点で説明し、実際に使ってみます。
まず比較したものを以下にまとめました。
Batch | Cloud Composer | GKE | Cloud Run Jobs | Cloud Functions | Workflows | |
---|---|---|---|---|---|---|
コンテナイメージ指定 | ◯ | ◯ | ◯ | ◯ | ✕ (関数ベース) |
✕ (GCP API指定のみ) |
依存関係制御 | △ (複雑な制御は不可) |
◯ | △ (複雑な制御は不可) |
✕ | ✕ | ◯ |
タイムアウト | なし | 不明 | なし | 最大24時間 | 最大1時間(第2世代) | 最大1年 |
それぞれ微妙にできることや制限に違いがあり、ここを捉えた上で選択する必要があります。
Batchの強みはおそらくタイムアウトがないことによって長時間実行ができ、かつシンプルに実装できることだと思います。
(タイムアウト最大値に関して、Batchにおいては存在しないと公式動画の方で説明していますが、Cloud Composerについては不明でした。)
Batch単体でもジョブ定義ファイル内で各タスクの依存関係(順次実行、並列実行)はできますが、Cloud ComposerやWorkflowsのように複雑なジョブネットを書くことは難しそうです。
ジョブネットのように動かしたい場合には公式ドキュメントにもあるようにWorkflowsなどからBatchジョブを実行するのが良さそうです。
動かしてみよう
実際にジョブを作って動かすまで試してみたいと思います。
GCP公式がBatchのサンプルコードをGitHubに公開しているためそちらを参考にジョブを作ってみます。
ジョブ定義ファイルを作ります。
taskGroups内に複数のtaskを定義でき、その中で実行したスクリプトやコンテナ&エントリポイントを指定できます。
今回はコンテナを使わず簡単なechoスクリプトのみ設定します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "taskGroups": [ { "taskSpec": { "runnables": [ { "script": { "text": "echo hello world" } } ] }, "schedulingPolicy": "IN_ORDER" } ], "logsPolicy": { "destination": "CLOUD_LOGGING" } } |
$ gcloud batch jobs submit sample-job --config=[定義ファイル] --location=us-central1
上記を実行することでジョブが登録され、VMインスタンスが起動しスクリプトが実行されます。
Batchジョブをsubmitしてから実際にジョブが始まるまではVM起動を挟むため数十秒の待機時間がかかります。
ログを見ると設定したスクリプトが確認できました。
Workflowsから実行してみる
Batchジョブをジョブネットのように動かす際はWorkflowsなどのサービス内からBatch APIを呼び出す流れになります。
ここではWorkflowsからBatchジョブを作成&実行を試してみます。
workflow.yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
main: params: [input] steps: - init: assign: - projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} - region: "us-central1" - jobId: ${"job-primegen-" + string(int(sys.now()))} - createAndRunBatchJob: call: googleapis.batch.v1.projects.locations.jobs.create args: parent: ${"projects/" + projectId + "/locations/" + region} jobId: ${jobId} body: taskGroups: taskSpec: runnables: - script: text: "echo hello world" logsPolicy: destination: CLOUD_LOGGING result: createAndRunBatchJobResponse |
ワークフローをデプロイします。
1 2 3 |
$ gcloud workflows deploy batch-workflow \ --source=workflow.yaml \ --location=us-central1 |
デプロイされ、画面やAPIからいつでも実行できる状態になりました。
WorkflowsはCloud Schedulerからも呼び出せるため、スケジュール実行したい場合はCloud Scheduler→Workflows→Batchの流れで実行すると良さそうです。
まとめ
Batchを採用するメリットとしては、タイムアウトがないこととバッチ実行に必要な時間だけVMインスタンスが起動するためコスト上の無駄が少ないこと。
ユースケースとして、常時稼働のVMインスタンスなどで定期実行されていたような長時間の処理はBatchが担えるのかなと思います。
既にDataflowやCloud Functionsなどフルマネージドで動いている処理はBatchへ移行するメリットはあまりなさそうです。
弊社プロダクトの中にもサーバ上で何時間もかかるバッチが多く存在しているため、それらをぜひBatchに移行してみたいです。
最後までお読み頂きありがとうございました!
参考
公式ドキュメント(Batch) | Google Cloud
batch-samplesリポジトリ | GitHub
Google Cloudバッチ処理ツールざっくり整理2022 | Zenn
Google Cloud 上で依存関係のあるタスクを定期実行する方法 (2022) | Zenn
明日はKazuakiMさんによる「AutoMLからVertexAIに移行した」です。
引き続き、 GMOアドマーケティング Advent Calendar 2023 をお楽しみください!
■採用ページはこちら!
https://recruit.gmo-ap.jp/
■GMOアドパートナーズ 公式noteはこちら!
https://note.gmo-ap.jp/