Cloud Run Jobsは本当に使えるのか？本番データで検証する
Cloud Functionsの最大60分というタイムアウト、あるいはメモリ制限に突き当たる。かといってバッチ処理のためだけにCompute Engineインスタンスを常時稼働させるのは、コスト的にも管理的にも避けたい。多くの開発者がこのジレンマに直面します。
当メディアが開発・運用するAIブログ自動化システム「Auto-Article Core」も、まさにその課題を解決するためにCloud Run Jobsを採用しました。この記事は「やってみた」レベルのチュートリアルではありません。毎朝稼働している本番システムの運用データに基づき、Cloud Run Jobsのリアルなコスト、実践的なアーキテクチャ、そして本番投入後に直面した課題と解決策を一次情報として提供します。
この記事を読み終えれば、あなたのバッチ処理基盤としてCloud Run Jobsが最適な選択肢か、データに基づいて判断できるはずです。
主要サーバーレスバッチ処理サービスの比較
机上のスペック比較だけでは本質は見えません。重要なのは、どのサービスが自身のワークロードの特性（実行時間、リソース要求、トリガー）に最もコスト効率良くフィットするかです。以下に、運用者の視点から見た主要な比較ポイントを示します。
| 項目 | Cloud Run Jobs | Cloud Run functions | Google Cloud Batch |
|---|---|---|---|
| 主な用途 | コンテナ化されたバッチ処理、データ処理、長時間タスク | イベント駆動の短い処理、軽量API | 大規模HPC、複雑な依存関係を持つ並列処理 |
| 最大実行時間 | 最大168時間 (7日間) | 最大60分 (第2世代) | 最大30日間 |
| 課金単位 | 最低1分のvCPU/メモリ秒 | 実行回数、vCPU/メモリ秒 (ミリ秒単位) | VMインスタンスの実行時間 |
| 選定理由@Auto-Article Core | Gemini APIの応答時間を含めると数分かかり、実行時間が予測不能なため選定。常時起動は不要。 | 実行時間が9分を超える可能性があり、60分でも将来的に不安が残るため不採用。 | 現状のワークロードではオーバースペック。コンテナ化前提で開発しているためJobsが最適。 |
2024年8月にはCloud Functionsが「Cloud Run functions」としてリブランディングされ、Cloud Runプラットフォームへの統合が完了しました。これにより、関数とコンテナの使い分けがよりシームレスになりましたが、実行時間の制約や課金単位といった根本的な特性は維持されており、技術選定の勘所は変わりません。
Cloud Run Jobsのメリット：本番運用データが示す3つの魅力
理論の次は実践です。Auto-Article Coreの運用データから見えてきた、Cloud Run Jobsの具体的なメリットを3つ解説します。
圧倒的なコスト効率：1ジョブ2.8円で実現する長時間バッチ処理
サーバーレスのコストは「使った分だけ」ですが、実際にいくらかかるのか。Auto-Article Coreの直近30日間の運用データから、1ジョブ（1記事生成）あたりのコストを円単位で算出しました。1ジョブあたりの実行コストは約2.8円です。内訳はCPUコストが約1.5円、メモリコストが約1.3円（1vCPU, 1GiBメモリ, 平均実行150秒, asia-northeast1, 1ドル155円換算）。ちなみに同ジョブで消費するGemini 1.5 Pro APIのコストが約35円であり、インフラコストがいかに低く抑えられているかがわかります。Compute Engineのe2-microインスタンスを1ヶ月常時稼働させると約1,200円かかりますが、このジョブは1日1回なので月90円以下。圧倒的なコスト差です。
設計自由度の爆発的向上：最大7日間実行とサイドカー対応
2024年11月のアップデートで、最大実行時間が24時間から168時間（7日間）へと大幅に延長されました。これはゲームチェンジャーです。従来はGCEやGKEでしか考えられなかった大規模なデータ処理や機械学習のバッチ推論も、サーバーレスで実行可能になりました。Auto-Article Coreでは、リソース割り当てを「2vCPU, 2GiB」から「1vCPU, 1GiB」に最適化した結果、実行時間は5秒しか伸びずにコストを約半分（5.5円→2.8円）に削減できました。このようにワークロードに合わせてリソースを細かく調整し、コストとパフォーマンスの最適点を探れるのが強みです。2025年1月にはサイドカーコンテナもプレビューとなり、監視やロギングを分離する構成も可能に。アーキテクチャの柔軟性は驚くほど向上しています。
疎結合アーキテクチャの核：Pub/Sub連携による堅牢性と拡張性
Auto-Article Coreでは、Cloud Schedulerから直接Jobsをトリガーせず、間にPub/Subを挟んでいます。この疎結合アーキテクチャがシステムの堅牢性を担保します。SchedulerとJobsが直接依存しないため、将来トリガーを別のイベント（例: Cloud Storageへのファイル配置）に変更する際もJobs側の改修は不要です。また、Pub/Subの再試行ポリシーとJobs自体の再試行設定を組み合わせることで、ネットワーク障害（Pub/Sub側でリトライ）とアプリエラー（Jobs側でリトライ）を切り分けて制御できます。この設計により、障害発生時の原因特定と対応がかなり迅速になりました。
デメリットと注意点：本番運用で直面した課題
優れたサービスですが、万能ではありません。導入後に直面した課題と、その対策を共有します。
課題1：単純なリトライでは破産するAPIエラーハンドリング
当初、ジョブの再試行設定（--max-retries）に依存していました。しかし、Gemini APIがプロンプトの内容を理由に4xx系のエラー（例: 安全でないコンテンツ）を返した場合、リトライしても100%成功しません。にもかかわらず、ジョブは設定回数分リトライを繰り返し、無駄なAPIコールと実行コストを発生させていました。これは文字通り「API利用料をドブに捨てる」行為です。
解決策: アプリケーション内でAPIのHTTPステータスコードを判定するロジックを実装。5xx系などリトライで成功する可能性がある場合は非ゼロの終了コードを返し、Cloud Run Jobsのリトライ機構に任せます。4xx系などリトライが無意味な場合は、ログに記録した上で終了コード0でプロセスを正常終了させ、無駄なリトライを止めるように変更しました。
課題2：最低1分課金とコールドスタートの遅延
Cloud Run Jobsは、実行時間が1分未満でも最低1分として課金されます。Auto-Article Coreのジョブは平均150秒なので問題ありませんが、仮に10秒で終わる処理を高頻度で実行する場合、毎回50秒分のコストが無駄になります。このようなワークロードには、ミリ秒単位で課金されるCloud Run functionsの方が明確に有利です。また、コンテナのコールドスタートにより、初回実行時に数秒から数十秒の遅延が発生する可能性も考慮に入れるべきです。
他の選択肢との比較：Jobsか、functionsか、Batchか
- Cloud Run functions (旧 Cloud Functions)
- 実行時間が短く（数秒〜数分）、実行頻度が高いイベント駆動処理に最適です。最低1分課金のJobsとは対照的に、ミリ秒単位の課金がコスト効率に直結します。APIのWebhook受け取りや、Cloud Storageへのファイルアップロードをトリガーにした画像リサイズなどが典型的なユースケースです。
- Google Cloud Batch
- より大規模で複雑なHPC（ハイパフォーマンスコンピューティング）や、ジョブ間の依存関係管理が必要な場合に選択肢となります。配列ジョブをネイティブでサポートし、数千コアを使った並列計算など、Jobsのスケールを超えるワークロードに向いています。
- Compute Engine / GKE
- サーバーレスの制約を受け入れられない、ステートフルな処理やOSレベルでの完全な制御が必要な場合の最後の砦です。管理コストと引き換えに、最大限の自由度が得られます。
Auto-Article Core程度の「毎日1回、数分間のLLM APIコールを含む処理」という規模であれば、Cloud Run Jobsがコストと管理の手間のバランスで最も優れていると判断できます。
この構成が向かないケース【導入前に要確認】
- 1分間に何十回も実行する、数秒で終わる処理を実装したいエンジニア
最低1分課金がコストの無駄になります。この場合はミリ秒課金のCloud Run functionsを選ぶべきです。 - ジョブ間で複雑な依存関係を持つパイプラインを構築したいデータエンジニア
Jobs単体では依存関係を管理する機能が弱いため、Cloud ComposerやArgo Workflows on GKE、あるいはGoogle Cloud Batchを検討した方が堅牢なシステムを構築できます。
Cloud Run Jobs 運用に関するQ&A
ローカル環境での開発・テストはどう進める？
基本的な動作確認は、docker runでコンテナをローカル実行し、環境変数を渡すことで可能です。ただし、IAM認証や他のGCPサービスとの連携部分はローカルでの完全な再現が難しい。Auto-Article Coreでは、基本的なロジックはローカルの単体テストで担保し、GCPサービス連携部分は専用の開発プロジェクトにデプロイして結合テストを実施するフローを組んでいます。
コンテナ内での安全なシークレット管理方法は？
APIキーなどの機密情報を環境変数で渡すのは避けるべきです。Secret Managerとの連携が最適解です。Cloud Run Jobsの実行サービスアカウントにSecret Managerのシークレットアクセサー（roles/secretmanager.secretAccessor）ロールを付与し、コンテナ起動時にアプリケーションがGCPのクライアントライブラリ経由で直接シークレットを取得します。これにより、機密情報が環境変数やコードリポジトリに一切残りません。
パフォーマンスのボトルネックはどう特定する？
標準のテキストログ（stdout）だけでは追跡が困難です。構造化ロギングを導入してください。Pythonであれば標準のjsonライブラリを使い、ログをJSON形式で出力します。各ログエントリにseverityやGCPが解釈可能なトレース情報を付与することで、Cloud LoggingのLog AnalyticsやCloud Traceと連携し、特定の処理区間の所要時間をクエリで集計・可視化できるようになります。
Cloud Run Jobsは、特にLLM APIを扱うようなモダンなバッチ処理において、「長時間実行」と「サーバーレスのコスト効率」を両立させる、現状の最適解の一つです。Cloud Functionsの時間制限に悩まされ、Compute Engineのコストと管理に躊躇している開発者にとって、まさに痒い所に手が届くサービスと言えます。
ただし、万能ではありません。ワークロードの特性（実行時間、頻度、依存関係）を正しく見極め、Cloud Run functionsやGoogle Cloud Batchといった他の選択肢と比較検討することが、失敗しない技術選定の鍵です。
今日から始めるべきアクション
- あなたのバッチ処理の平均実行時間と実行頻度を計測する。
- Cloud Monitoringで既存ワークロードのCPU/メモリ使用率を可視化し、適切なリソース割り当てを見積もる。
- 外部APIのエラーハンドリングを見直し、4xx系エラーで無駄なリトライをしていないか確認する。
