Google Cloudで業務ジョブネットを実現する① ～クラウドネイティブなバッチ実行方式の検討～

1. はじめに

昨今、さまざまな業務システムで、オンプレミス環境からパブリッククラウドへの移行が進んでいます。

もし、あなたが既存の業務システムをクラウドへ移行する担当者だった場合、次のように悩んだことはないでしょうか。

「JP1で実装している、この長大で複雑なジョブネット。パブリッククラウド上でどう実現しよう？」

このとき、まず思い浮かぶ選択肢の一つが、次のような構成ではないでしょうか。

「オンプレミスと同じように仮想マシンを構築して、JP1を導入しよう。そうすると、ジョブ管理サーバの冗長化やクラスタリングはどうしようか……」

もちろん、こうした方式は十分に実現可能です。特に、既存のジョブネットや運用方式を極力変更せずに移行したい場合には、有力な選択肢となります。

しかし、せっかくパブリッククラウドへ移行するのであれば、従来の構成をそのまま持ち込むのではなく、クラウドの特性を生かした構成にできないだろうかと考える方も多いのではないでしょうか。

従来型のジョブ管理ソフトウェアを利用する場合、ジョブ管理サーバの構築や冗長化、ミドルウェアのバージョンアップなど、これまでオンプレミスで対応していた管理作業を引き続き考慮する必要があります。

一方で、クラウドネイティブな構成を検討しても、Cloud Schedulerのような時刻起動の仕組みだけでは、業務システムで求められる複雑なジョブネットを実現することはできません。

例えば、複数ジョブの依存関係、条件分岐、途中からの再実行、異常終了時の制御、業務カレンダーなど、考慮すべき機能は多岐にわたります。

そのため、クラウドネイティブな構成を採用したくても、従来のジョブ管理ソフトウェアを利用する方式を選ばざるを得ない場合もあると思います。

そこで本連載では、Google Cloudのマネージドサービスを組み合わせることで、業務システムのジョブネットをクラウドネイティブな構成で実現する方法について紹介します。

具体的には、Cloud Scheduler、Workflows、Cloud Run Jobsを組み合わせた方式を取り上げ、次の内容を複数回に分けて解説していきます。

• 従来型のジョブ管理ソフトウェアとクラウドネイティブな方式の比較
• Google Cloudでのバッチ実行方式の検討と選定
• Cloud Scheduler、Workflows、Cloud Run Jobsによるジョブネットの実装
• PoCによって確認した制約と、その対応方法
• 実際のシステムに適用した後の評価と課題

今回は第1回として、業務ジョブネットに求められる機能を整理したうえで、Google Cloud上で実現するための複数の構成案を紹介します。

2. 業務ジョブネットに求められる機能とは

まず、業務システムのジョブネットに求められる機能を整理してみます。

単純なバッチ処理であれば、決まった時刻にプログラムを起動するだけで実現できます。

しかし、企業の基幹業務で利用されるジョブネットでは、複数のジョブが依存関係を持ち、実行結果に応じて後続の処理を制御する必要があります。

例えば、次のようなジョブネットを考えてみます。

このジョブネットでは、ファイルの取り込みとデータチェックが正常終了した後、二つのデータ集計処理を並列実行し、両方が終了してから結果を出力します。

さらに、データチェックでエラーが発生した場合には、後続の集計処理を実行しないようにする必要があります。

この程度の構成であれば、比較的シンプルに実現できそうです。

しかし、実際の業務システムでは、これに加えてさまざまな運用要件が存在します。

分類	主な機能	内容
ジョブ管理	ジョブネットの階層化	複数のジョブネットを階層構造として定義する
ジョブ管理	実行順序の制御	順次実行、並列実行、分岐・合流などを制御する
スケジュール	時刻起動・周期起動	指定時刻や一定周期でジョブネットを起動する
スケジュール	業務カレンダー	営業日・非営業日などに応じて実行日を制御する
ジョブ制御	条件分岐	先行ジョブの実行結果に応じて後続処理を切り替える
ジョブ制御	途中からの再実行	異常終了したジョブや、その後続ジョブから再実行する
障害対応	異常終了時の後続抑止	エラーが発生した場合に後続ジョブを実行しない
障害対応	次回実行の抑止	前回の異常終了が未解決の場合に、次回の実行を抑止する
監視	実行状態の確認	ジョブやジョブネットの実行状況を確認する
監視	遅延監視	想定時間を超えて実行中のジョブを検知する

JP1/AJS3などのジョブ管理製品は、こうした業務運用に必要な機能を幅広く提供しています。

一方、パブリッククラウドのサービスは、それぞれが特定の役割を担う構成になっています。

そのため、従来のジョブ管理製品が一体として提供していた機能を、複数のクラウドサービスでどのように実現するかが重要な検討ポイントになります。

3. 従来型のジョブ管理ソフトウェアを利用するか

Google Cloudの具体的なサービスを比較する前に、まずは大きな方針として、従来型のジョブ管理ソフトウェアを利用するか、クラウドネイティブなサービスを組み合わせるかを考えます。

両者の特徴を整理すると、次のようになります。

評価観点	従来型ジョブ管理ソフトウェア	クラウドネイティブな構成
機能	豊富なジョブ管理・運用機能を利用できる	必要な機能を複数サービスで組み合わせる
初期構築	管理サーバやミドルウェアの構築が必要になる場合がある	マネージドサービスを活用し、管理基盤の構築を抑えやすい
コスト	ライセンスや管理サーバの費用が発生する場合がある	従量課金を活用できるが、利用量や補完実装によって変わる
運用負荷	管理サーバのOS・ミドルウェアなどの保守が必要	インフラ管理を減らせる一方、ワークフローや監視の運用は必要
変更容易性	製品が提供する管理画面や定義機能を利用できる	IaCやCI/CDとの組み合わせで変更を自動化しやすい
拡張性	製品・構成に応じた制約を考慮する必要がある	サービスごとの制約を考慮しながら拡張できる

3.1. 従来型ジョブ管理ソフトウェアを利用する方式

従来型のジョブ管理ソフトウェアを利用する最大のメリットは、豊富なジョブ管理機能と、これまで培ってきた運用ノウハウをそのまま活用しやすいことです。

特に、既存システムで複雑なジョブネットや運用手順が確立されている場合には、移行に伴うアプリケーションや運用への影響を抑えられます。

一方で、仮想マシン上にジョブ管理サーバを構築する場合、サーバの可用性や冗長化、OS・ミドルウェアの保守などを考慮する必要があります。

そのため、クラウドへ移行しても、ジョブ管理基盤については従来と同様の運用負荷が残る可能性があります。

3.2. クラウドネイティブな構成を利用する方式

クラウドネイティブな構成では、クラウドが提供するマネージドサービスを組み合わせて、必要な機能を実現します。

この方式のメリットは、管理サーバを自分たちで構築・維持する負担を抑えられることです。

また、サービスの多くはAPIやIaCによる管理が可能であり、ジョブネットの定義や実行基盤の設定をアプリケーションの開発プロセスと組み合わせやすい特徴があります。

ただし、ジョブ管理製品と同等の機能が標準で提供されるわけではありません。

必要な機能をサービスの組み合わせやアプリケーション側の実装によって補う必要があり、その開発・運用コストも考慮しなければなりません。

つまり、どちらが優れているというものではなく、業務要件、コスト、運用負荷、将来の拡張性を踏まえて方式を選ぶ必要があるということです。

4. Google Cloudで実現するジョブネットの方式

では、Google Cloudのサービスを使って業務ジョブネットを構築する場合、どのような選択肢があるでしょうか。

例えば、GKE（Google Kubernetes Engine）上にKubernetesの共通基盤を構築しているシステムであれば、KubernetesのCronJobを利用して、定期的にコンテナを実行する方式が考えられます。

また、GKEなどのKubernetes基盤を利用しない場合には、Cloud SchedulerからCloud Run Jobsを起動する方式も選択肢となります。

しかし、これらは基本的に個々のジョブを定期実行するための仕組みであり、複数ジョブの依存関係や条件分岐などを管理するには、別途実行制御の仕組みが必要です。

そこで、複数のジョブを組み合わせた業務ジョブネットを実現する方式として、次の4つを取り上げます。

No.	方式	概要
1	Cloud Composer（Apache Airflow）	AirflowのDAGを利用してジョブ間の依存関係や実行を管理する
2	Cloud Scheduler＋Workflows＋Cloud Run Jobs	Workflowsで実行順序を管理し、Cloud Run Jobsでコンテナを実行する
3	Cloud Scheduler＋Workflows＋Batch	Workflowsで実行順序を管理し、Batchで計算リソースを確保して処理を実行する
4	Cloud Scheduler＋Workflows＋Batch（runnable制御）	Workflowsに加え、Batch内のrunnableでも処理の実行順序を制御する

※Cloud Composerは、現在「Managed Service for Apache Airflow」という名称に変更されています。本記事では旧名称のCloud Composerを使用します。

4.1. Cloud Composer（Apache Airflow）

Cloud Composerは、Apache AirflowをGoogle Cloud上で利用できるマネージドサービスです。

Airflowでは、DAG（Directed Acyclic Graph：有向非巡回グラフ）を使ってジョブの依存関係を定義します。

ジョブの実行順序、分岐、並列実行などに加えて、タスク単位の再実行などの機能も備えています。

そのため、複雑なジョブネットやデータパイプラインを管理するための有力な選択肢です。

一方、DAGをPythonで定義するため、Airflowの仕組みを理解する必要があります。また、マネージドサービスではあるものの、Airflowの実行環境を維持するための費用が発生します。

ジョブネットの規模や必要な機能、運用体制によっては適した選択肢となりますが、構成や運用の複雑さも含めて比較する必要があります。

4.2. Cloud Scheduler＋Workflows＋Cloud Run Jobs

この方式は、Google Cloudの3つのサービスを組み合わせてジョブネットを構築するものです。

役割は次のように分担します。

• Cloud Scheduler：ジョブネットの起動スケジュールを管理する
• Workflows：ジョブの実行順序や条件分岐を管理する
• Cloud Run Jobs：個々のバッチ処理をコンテナとして実行する

Cloud Schedulerで指定時刻にWorkflowsを起動し、Workflowsに定義された処理順序に従ってCloud Run Jobsを実行します。

この方式では、ジョブの実行制御とバッチアプリケーションの実行を明確に分離できる点が特徴です。

また、ジョブ管理のための専用サーバを用意する必要がなく、サーバーレスな構成で実現できます。

一方で、従来のジョブ管理製品が提供する途中からの再実行や業務カレンダーなどは、標準機能だけで同じ運用を実現できるとは限りません。

4.3. Cloud Scheduler＋Workflows＋Batch

この方式は、Cloud Run Jobsの代わりにGoogle CloudのBatchを利用する構成です。

Batchでは、指定した計算リソースを利用して、コンテナやスクリプトなどの処理を実行できます。

Workflowsを利用してジョブの実行順序を制御する点は、Cloud Run Jobsを利用する方式と同様です。

ただし、実行環境の確保や管理方法は異なるため、必要なマシンスペックや処理時間などの要件に応じて選択します。

4.4. Cloud Scheduler＋Workflows＋Batch（runnable制御）

Batchには、一つのジョブ内に複数のrunnableを定義する機能があります。

これを利用して、WorkflowsだけでなくBatch内でも処理の実行順序を管理する方式が考えられます。

ただし、ジョブネット全体の制御をWorkflowsで行い、さらにBatch内でも複数処理を制御すると、実行制御を管理する場所が分散します。

そのため、構成によっては設定や障害時の調査が複雑になる可能性があります。

5. まとめ

今回は、パブリッククラウド上で業務ジョブネットを実現するための考え方と、Google Cloudを利用した複数の実装方式について紹介しました。

従来型のジョブ管理ソフトウェアを利用する方式には、豊富な機能や既存の運用ノウハウを活用できるメリットがあります。

一方で、Google Cloudのマネージドサービスを組み合わせることで、ジョブ管理基盤の運用負荷を抑えながら、クラウドネイティブな構成でジョブネットを実現する選択肢もあります。

今回紹介した方式には、それぞれ特徴やメリット・デメリットがあるため、必要な機能だけでなく、コスト、運用負荷、実装難易度、将来の拡張性などを考慮して選定することが重要です。

私が実際に担当した業務システムでも、これらの観点から複数の方式を比較・検討し、最終的に 「Cloud Scheduler＋Workflows＋Cloud Run Jobs」 を採用しました。

ただし、すべてのジョブ管理機能を標準で実現できるわけではなく、採用にあたっては機能面や運用面の制約についても検討する必要がありました。

次回は、なぜこの方式を選んだのか、ほかの方式と比較してどのような点を評価したのかについて、具体的な選定理由とともに紹介します。