Cloud Run jobsをバッチ処理基盤として使いたい

Jagu'e'r Cloud Native #16 ハイブリッド Meetupで登壇した資料となります。

Google Cloudでバッチ処理を実行するためには複数の選択肢があります。そのうちの1つがCloud Run jobsです。
Production環境でワークロードを処理するために必要な要素として「運用監視」は欠かせないものです。Cloud Run jobsをバッチ処理基盤として使っていくために運用監視をするメトリクス取得の話について述べた資料です。

Transcript

1. Cloud Run jobsをバッチ処理基盤として 使いたい Jagu'e'r Cloud Native #16 ハイブリッド Meetup
2. ⾺勝 淳史 株式会社ヘンリー所属 @HorseVictory • Senior Web Engineer • Jagu'e'r 分科会 無所属 • 猫と戯れるのが好き • 好きなサービスはCloud Run
3. 今回の発表が刺さる⼈ • Cloud Runが好きな⽅ • Cloud Run jobsについても知りたい⽅ • Cloud Run jobsの監視をやっている⽅
4. Cloud Run jobsをバッチ処理基盤として 使いたい Jagu'e'r Cloud Native #16 ハイブリッド Meetup ここについて少 し
5. バッチ処理とは 今回扱うバッチ処理は次のような⽤途で利⽤される処理を指す ref: 「Google Cloud で "バッチ ジョブ" を実⾏する 2 つの⽅法」https://zenn.dev/google_cloud_jp/articles/c99697707e3b2c Job Job Job Job Job Job Job NAS Job Job DB Job Job Queue 単⼀実⾏ 直列実⾏ 並列実⾏ ファイル共有 DB共有 イベント駆動
6. Google Cloudにおけるバッチ処理実⾏基盤の選択肢 厳密にはGKE上でJobを動かす、Google Cloud Composerを利⽤するなどもあるが実⾏基盤にフォーカスを当てるので割愛 Batch Cloud Run functions Cloud Run jobs
7. Google Cloudにおけるバッチ処理実⾏基盤の選択肢 厳密にはGKE上でJobを動かす、Google Cloud Composerを利⽤するなどもあるが実⾏基盤にフォーカスを当てるので割愛 Batch Cloud Run functions Cloud Run jobs
8. Cloud Run jobsとは • Job、Execution、タスクから構成 • Job ◦ ルートリソースとして各種設定 • Execution ◦ Jobを⼀度実⾏するためのタスクの集合 • タスク ◦ 処理の実⾏単位。並列起動やリトライ が可能 ref: https://cloud.google.com/run/docs/create-jobs?hl=ja
9. Cloud Run jobsをバッチ処理基盤として 使いたい Jagu'e'r Cloud Native #16 ハイブリッド Meetup 本番運⽤で 必要なものは？
10. Cloud Run jobsをバッチ処理基盤として 使いたい Jagu'e'r Cloud Native #16 ハイブリッド Meetup 動かすために 必要なものは？ 運⽤監視がちゃんとできるか？
11. Cloud Run jobsで取得できる組み込みメトリクス ref: https://cloud.google.com/run/docs/monitoring?hl=ja
12. バッチ処理で取得したい（であろう）メトリクス • リソースのキャパシティ（CPU、Memory） • 処理にかかった時間 • 正常終了した件数 • 異常終了した件数 • 実⾏中の件数 • 許容処理時間の超過（ロングランの検知）
13. Cloud Run jobsで取得できる組み込みメトリクス ref: https://cloud.google.com/run/docs/monitoring?hl=ja リソースの キャパシティ 正常終了した件数 実⾏中の件数
14. バッチ処理で取得したい（であろう）メトリクス • ✅ リソースのキャパシティ（CPU、Memory） • 処理にかかった時間 • ✅ 正常終了した件数 • 異常終了した件数 • ✅ 実⾏中の件数 • 許容処理時間の超過（ロングランの検知）
15. バッチ処理で取得したい（であろう）メトリクス • ✅ リソースのキャパシティ（CPU、Memory） • 処理にかかった時間 • ✅ 正常終了した件数 • 異常終了した件数 • ✅ 実⾏中の件数 • 許容処理時間の超過（ロングランの検知） 未カバーのメトリクスを取得する 対応を考える
16. 処理にかかった時間 • 処理にかかった時間⾃体はgcloudコマンドから取得可能 ◦ gcloud run jobs executions tasks list --execution=${EXECUTION_NAME} • ジョブオーケストレータ（Cloud Workflowsなど）で動かしている場合は バッチ実⾏の後処理で取得 • Cloud Run jobsを単独実⾏している場合は監視基盤側で実⾏する
17. 処理にかかった時間 • 取得した時間をCloud metricsの カスタム指標として送信 • お⼿軽に試すならAPIs Explorer(*1)が便利 - (*1): https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.timeSeries/create
18. 異常終了した件数 • ログベース指標(*1)でFailedしたバッチタスクの件数を抽出 • カウンタ指標として記録してアラート設定をすることで監視が可能 (*1) https://cloud.google.com/logging/docs/logs-based-metrics?hl=ja 異常終了した Executionを指標化
19. 異常終了した件数 • リトライ回数を考慮すべきか？ ◦ Cloud Run jobsにはリトライが設定 できる(*1) ◦ Cloud Run jobsが冪等な場合、リト ライによる再実⾏で正常終了するこ とがある ◦ リトライ回数を考慮したしきい値設 定をどこまでするかはケースバイケー ス (*1) https://cloud.google.com/run/docs/jobs-retries?hl=ja
20. 許容処理時間の超過（ロングランの検知） • （むずかしい） • 検討するパターンは2つ ◦ 定刻起動の場合：許容時間を超えても実⾏されている場合に検知 ◦ イベント駆動の場合：実⾏中バッチの処理時間を計測しておく必要あり
21. 実⾏中バッチの処理時間を計測 • OpenTelemetry サイドカー(*1)で実⾏時間の指標を記録できるか？ ◦ Cloud Run jobsはサイドカー未サポート(*2) • 監視基盤側から起動時刻と現在時刻を利⽤して逆算をする ◦ いまのところ、こちらが有⼒ • いいアイデアがある⽅、ディスカッションしたいです笑 (*1): https://cloud.google.com/run/docs/tutorials/custom-metrics-opentelemetry-sidecar?hl=ja#trying-it-out (*2): https://www.googlecloudcommunity.com/gc/Serverless/Can-I-use-sidecar-containers-with-Google-Cloud-Run-jobs/m-p/704051
22. バッチ処理で取得したい（であろう）メトリクス • リソースのキャパシティ（CPU、Memory） • 処理にかかった時間 • 正常終了した件数 • 異常終了した件数 • 実⾏中の件数 • 許容処理時間の超過（ロングランの検知） 再掲
23. バッチ処理で取得したい（であろう）メトリクス 取得したい情報 追加設定 メトリクス リソースのキャパシティ（CPU、Memory） なし 組み込み指標 処理にかかった時間 あり カスタム指標 正常終了した件数 なし 組み込みメトリクス 異常終了した件数 あり ログベース指標 実⾏中の件数 なし 組み込みメトリクス 許容処理時間の超過（ロングランの検知） あり 監視基盤等でカバー
24. まとめ • Cloud Run jobsをバッチ実⾏基盤として使っていきたい • 監視メトリクスが必要⼗分かどうかを調査した • ⼀部、組み込みメトリクスではフォローされていないものは カスタム指標、ログベース指標、監視基盤側の仕組みでフォロー するとよさそう
25. Fin.