Workflows と Cloud Composer では、どちらも、サービス オーケストレーションに使用し、複数のサービスを組み合わせてアプリケーションの機能を実装することや、データ処理を実行することが可能です。考え方は似ていますが、それぞれ異なるユースケースを対象に設計されています。このページでは、ユーザーがユースケースに適したプロダクトを選択できるようにサポートします。
主な違い
Workflows と Cloud Composer の主な違いは、それらがサポートするアーキテクチャのタイプです。
Workflowsは、複数の HTTP ベースのサービスを耐久性に優れたステートフル ワークフローにオーケストレートします。レイテンシが小さく、多数の実行を扱えます。完全にサーバーレスでもあります。
Workflows は、マイクロサービスの連結、VM の起動や停止などのインフラストラクチャ タスクの自動化、外部システムと統合に最適です。Workflows コネクタは、 Google Cloud Cloud Storage や BigQuery などのサービスでの簡単な操作シーケンスもサポートしています。
Cloud Composer は、データドリブン ワークフロー（特に ETL/ELT）をオーケストレートするように設計されています。Apache Airflow プロジェクト上に構築されていますが、Cloud Composer はフルマネージドです。Cloud Composer は、オンプレミスや複数のクラウド プラットフォームなど、場所を問わずパイプラインをサポートします。タスクやスケジューリングなど、Cloud Composer のすべてのロジックは、有向非巡回グラフ（DAG）定義ファイルとして Python で表現されます。
Cloud Composer は、タスク実行間の数秒のレイテンシを処理できるバッチ ワークロードに最適です。Cloud Composer を使用すると、BigQuery でのジョブのトリガーや Dataflow パイプラインの開始など、データ パイプライン内のサービスをオーケストレートできます。既存のオペレーターを使用してさまざまなサービスと通信できます。 Google Cloud だけでも 150 を超えるオペレーターがあります。
詳細な機能の比較
| 機能 | ワークフロー | Cloud Composer |
|---|---|---|
| 構文 | YAML または JSON 形式の Workflows 構文 | Python |
| 状態モデル | 命令型のフロー制御 | 宣言型の自動依存関係解決を使用した DAG |
| 統合 | HTTP リクエストとコネクタ | Airflow 演算子とセンサー |
| ステップ間でデータを渡す | 512 KB（変数用） | 48 KB1（XCom 用） |
| 実行のトリガーとスケジューリング | gcloud CLI、Google Cloud コンソール、Workflows API、ワークフロー クライアント ライブラリ、Cloud Scheduler | DAG 定義ファイルで cron に似たスケジュール設定、Airflow センサー |
| 非同期パターン |
|
ポーリング |
| 並列実行 | 同じワークフローの同時実行、または並列ステップを使用したワークフローの内部実行 | 依存関係に基づき自動 |
| 実行レイテンシ | ミリ秒 | 秒 |
| 基礎とするオープンソース | × | はい（Apache Airflow） |
| スケーリング モデル | サーバーレス（需要に応じてスケールアップおよびゼロまでスケールダウン） | プロビジョニング済み |
| 課金モデル | 使用量ベース（実行されるステップごと） | プロビジョニングされた容量ベース |
| データ処理機能 | × | バックフィル、DAG の再実行機能 |
-
airflow.models.xcom のソースコード。Apache Airflow のドキュメント（2021 年 8 月 2 日）。↩