PoCを通して見えた、技術選定で重視すべき5つの視点
分析屋の柵木です。
今回は、Google Cloudでジョブオーケストレーションを検討する際に候補となる、Cloud ComposerとCloud Workflowsについて紹介します。どちらも処理の流れを制御するサービスですが、その設計思想や得意分野は大きく異なります。
以前この2つを比較し、どちらを採用すべきか検討する機会がありました。比較を始めた当初は、「Airflowを使うならCloud Composer」「サーバーレスを重視するならCloud Workflows」という一般的な理解しかありませんでした。
しかし、実際に並列処理、リトライ、障害対応、ログ確認などを一つずつ検証していくと、技術選定で本当に重要なのは、単純な機能の多さではないことが見えてきました。
この記事では、公式ドキュメントの機能比較だけではなく、実際のPoCを通して判断した5つのポイントをご紹介します。
最初に結論
私の結論は、次のとおりです。
ETLやバッチ処理、多数のジョブ管理が中心ならCloud Composer
API連携やイベント駆動の処理が中心ならCloud Workflows
これは、どちらか一方が優れているという意味ではありません。
重要なのは、サービスの特徴だけでなく、既存資産、障害対応、運用体制、コストなどを含めて、自分たちの要件に適したサービスを選ぶことです。
まずは全体像を整理する
Cloud Composerは、Apache Airflowを利用できるマネージドサービスです。PythonでDAGを定義し、Task間の依存関係、スケジュール、リトライなどを管理します。
一方、Cloud Workflowsは、Google Cloudサービスや外部APIを連携させるサーバーレスのオーケストレーションサービスです。ワークフローはYAMLまたはJSONで定義し、StepごとにAPIや各種サービスを呼び出します。
この2つは単純な競合サービスではなく、処理の性質と運用方法によって使い分けるサービスと考える方が分かりやすいでしょう。
技術比較の全体像
両サービスとも、並列処理、リトライ、例外処理を実装できます。
ただし、実際の技術選定では、「機能があるか」だけでなく、その機能を日々の運用でどのように使えるかが重要になります。
① 既存資産を活かせるか
最初に確認したのは、既存環境で利用しているシェルスクリプトを、どの程度活用できるかという点でした。
Cloud Composerでは、AirflowのBashOperatorからシェルスクリプトを実行できます。
Cloud Workflowsはシェルスクリプトを直接実行するサービスではありません。そのため、Cloud Run Jobsなどの実行基盤に処理を配置し、WorkflowsからAPI経由で起動する構成が考えられます。
【Cloud Composer】
Cloud Composer
│
▼
BashOperator
│
▼
シェルスクリプトを実行
【Cloud Workflows】
Cloud Workflows
│
│ APIでジョブを起動
▼
Cloud Run Jobsなどの実行基盤
│
▼
コンテナ内のシェルスクリプトを実行PoCでは、Cloud ComposerからBashOperatorを利用し、シェルスクリプトを実行できることを確認しました。
一方、Cloud Workflowsでは、シェルスクリプトをコンテナ化してCloud Run Jobsに配置し、Workflowsから呼び出す構成を検証しました。
どちらでも処理は実行できますが、移行時の考え方が異なります。
Cloud Composerは既存の実行方式を比較的活かしやすい一方、Cloud Workflowsでは、処理の実行場所とワークフロー制御を分離した構成に見直す必要があります。
”移行を伴う技術選定では、新しいサービスの機能だけでなく、既存資産をどこまで活用できるかが重要です。”
② ジョブ全体を管理できるか
続いて、直列、並列、合流を含む同じ処理構成を両サービスで実装しました。
Cloud Composerでは、DAGの中にTaskを配置し、Task間の依存関係として処理の順序を定義します。
【Cloud ComposerのDAG】
Task A
│
┌─────┴────┐
▼ ▼
Task B Task C
│ │
└─────┬────┘
▼
Task DCloud Workflowsでも、parallelを使用して複数の分岐を並列実行し、すべての分岐が完了した後に後続Stepへ進む構成を作れます。
【Cloud Workflows】
開始Step
│
▼
parallel
┌────┴────┐
▼ ▼
Branch B Branch C
│ │
└────┬────┘
▼
後続Step両サービスとも、1つのDAGまたはWorkflow内で並列・合流を表現できます。
違いを感じたのは、処理数が増えた場合の管理方法です。
Cloud Composerでは、Airflow UIのGraph ViewやGrid Viewから、Taskの依存関係と実行状態を確認できます。
Cloud WorkflowsでもWorkflow内のStepを管理できますが、複数のWorkflowをまたぐ全体構成については、親Workflowを設ける、設計資料で補完するなど、システム全体を管理する方法を別途考える必要があります。
”ジョブ管理では、個々の処理が動くことだけでなく、全体の依存関係と実行状態を把握できることが重要です。”
③ 障害発生後にどう復旧するか
今回のPoCで、特に判断へ影響したのが障害対応です。
Cloud Composerでは、Taskごとに実行状態を管理しています。失敗したTask InstanceをClearすると、そのTaskを再実行できます。
ただし、再実行対象は常に「失敗したTaskだけ」と決まっているわけではありません。障害の状態や処理設計に応じて、失敗Task、後続Taskなど、Clearする範囲を選択する必要があります。Airflowには、失敗Taskのみ、上流、下流などを指定してClearする仕組みがあります。
【初回実行】
Task A：成功
│
Task B：成功
│
Task C：失敗
│
Task D：未実行または upstream_failed
【復旧】
原因を修正
│
▼
再実行するTask Instanceを選択
│
▼
対象をClear
│
▼
必要な範囲を再実行そのため、以前の図にあった「Cのみ再実行」という表現は、少し単純化しすぎていました。
正確には、失敗したTaskを起点として、状態や依存関係を確認し、必要なTask Instanceを選択して再実行できるという特徴です。
Cloud Workflowsでは、try/exceptによる例外処理や、エラー条件、回数、待機時間を指定したリトライを実装できます。
【Cloud Workflowsのエラー制御】
処理Step
│
├─ 成功 ──────────▶ 次のStep
│
└─ 失敗
│
▼
Retry判定
│
┌──┴──┐
▼ ▼
再試行 except処理
│
▼
ログ出力・終了・代替処理ただし、実行が終了した後に「どの地点から再開するか」については、処理の冪等性、状態管理、再実行用の入力値などを考慮して、ワークフロー側で設計する必要があります。
”障害対応では、リトライの有無だけでなく、失敗後にどの単位で安全に再実行できるかまで確認する必要があります。”
④ ログから原因へたどり着けるか
両サービスとも、実行結果やログをGoogle Cloud上で確認できます。
ただし、ログ調査の入口は異なります。
Cloud Composerでは、Airflow UIから失敗したTaskを選択し、そのTaskのログや実行履歴を確認できます。Graph ViewではTaskの依存関係と状態、Grid ViewではDAG RunごとのTask状態を確認できます。
【Cloud Composer】
Airflow UI
│
▼
DAG Runを確認
│
▼
失敗したTaskを選択
│
├─ Task Log
├─ 実行回数
└─ Taskの状態Cloud Workflowsでは、Workflowの実行履歴から失敗したStepやエラー内容を確認し、必要に応じてCloud Loggingや、呼び出し先サービスのログを確認します。
【Cloud Workflows】
Workflowの実行履歴
│
▼
失敗したStep・エラーを確認
│
▼
必要に応じて追加調査
┌────┴────────────┐
▼ ▼
Cloud Logging 呼び出し先サービスのログ
例：Cloud Run JobsWorkflowsから別のサービスを呼び出す構成では、Workflow側のエラーと、実際に処理を実行したサービス側のログを分けて確認する必要があります。
これはWorkflowsの欠点というより、制御するサービスと実行するサービスを分離した構成上の特徴です。
”ログの評価では、ログを保存できるかではなく、障害箇所から原因へどのような順序でたどり着くかを確認することが重要です。”
⑤ コストをどの範囲で比較するか
Cloud Workflowsは実行したStep数などに応じた従量課金であり、常時稼働する実行環境を個別に管理する必要がありません。
一方、Cloud ComposerはAirflow環境を構築して運用するため、ワークフローを実行していない時間を含めて環境費用が発生します。
ただし、技術選定ではサービス利用料だけを比較すればよいわけではありません。
TCO
│
┌─────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
サービス利用料 開発・保守工数 運用・障害対応工数
│ │ │
└─────────────────┴───────────────────┘
│
▼
長期的な総コストで比較Workflowsではサービス利用料を抑えやすい場合がある一方、実行サービスとの連携、再実行制御、複数Workflowの管理などを独自に設計すれば、その開発・保守工数も考慮する必要があります。
Composerについても、Airflow環境の管理やアップデート、リソース調整などの運用負荷を含めて評価する必要があります。
”コストは月額料金だけでなく、開発、保守、監視、障害対応まで含めたTCOで比較すべきです。”
PoCを終えて
比較を始めた当初は、サーバーレスで利用できるCloud Workflowsの方が有力ではないかと考えていました。
しかし、同じ処理構成を両サービスで実装し、シェルスクリプトの実行、並列・合流、障害発生後の復旧、ログ調査まで確認すると、判断基準が変わりました。
ETLやバッチ処理が多く、Task間の依存関係や再実行を日常的に管理するのであれば、Cloud Composerが有力な選択肢になります。
一方で、Google Cloudサービスや外部APIの呼び出しを中心とし、イベントを起点に処理を制御するのであれば、Cloud Workflowsのシンプルさとサーバーレスの特性が大きな強みになります。
技術選定で大切なのは、「どちらが優れているか」を決めることではありません。
既存資産、処理の性質、障害時の復旧方法、運用体制、長期的なコストを踏まえて、自分たちに適したサービスを選ぶこと。
これが、今回のPoCを通して得られた最も大きな学びでした。
ここまでお読みいただき、ありがとうございました！
この記事が少しでも参考になりましたら「スキ」を押していただけると幸いです！
株式会社分析屋について
弊社が作成を行いました分析レポートを、鎌倉市観光協会様HPに掲載いただきました。
ホームページはこちら。
noteでの会社紹介記事はこちら。
【すべての意思決定に人間らしさを】
分析屋は、「データ分析」と「おもてなし」を融合させた
「おもてなし分析」を提供するデータ分析集団です。
「おもてなし分析」によって、合理 (データ・ロジック) と 情理 (経験則・直感・想い・事情など) が共存し合う、合理一辺倒ではない成熟した社会の実現を目指しています。
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。
