🔷 Apache Airflow とは？
Apache Airflow は、定期実行・依存関係を持つ処理を管理するためのワークフローオーケストレーターです。タスクを DAG（有向非巡回グラフ）として定義し、Pythonコードで柔軟にワークフローを構築できます。
✅ 主な特徴
- DAG（Directed Acyclic Graph）による依存関係の可視化と管理
- Pythonベースの柔軟なタスク定義
- スケジューリング（cron相当）
- タスク失敗時のリトライやアラート通知
- Web UIによる可視化と操作
- ロギング、メトリクス、セキュリティの統合
🏗️ Cloud Composer とは？
Cloud Composer は、Google Cloud が提供する Apache Airflow のマネージドサービスです。Airflow のインストール・構成・スケーリング・モニタリングなどの煩雑な管理を GCP が代行してくれます。
✅ Cloud Composer のメリット
- Airflow 環境のセットアップ不要（すぐ使える）
- GCP サービス（BigQuery、GCS、Pub/Sub など）とシームレスに統合
- スケーラブルなインフラ構成（GKE上で稼働）
- セキュリティ（IAM、VPC、Secret Manager 連携）
- Web UIでワークフローの可視化とモニタリング
🔄 Airflow / Composer で実現できること
- データパイプラインの自動化（ETL/ELT）
- 機械学習パイプラインの構築（学習〜推論）
- データ転送や整形、通知などのオーケストレーション
- ストレージやDBのトリガー処理
- スケジュールに沿った定期バッチの実行
📂 GitHub + GCS + Composer の実践構成(実際の開発例)
- GitHub で DAG を含むワークフローファイルを管理
- GitHub Actions などで GCS に同期
- Composer は GCS 上の DAG を読み込んで実行
この構成により、コード管理・自動デプロイ・CI/CD が実現できます。
⚠️ 注意点：Airflowは「分散処理エンジン」ではない
Airflowは分散処理エンジン（例えば、SparkやBigQuery）のように大量データを処理するわけではなく、タスク単位での並列実行を行うオーケストレーターです。
| ✘ よくある誤解 | ✔ 正しい理解 |
|---|---|
| AirflowがSparkみたいに大量データを並列に処理する | Airflowは「処理を並列に“実行”させるスケジューラー」 |
| Airflowが分散データ処理をする | Airflowは「タスクを投げて指示する指揮官」、処理そのものは他ツールが担当 |
✅ Airflowの並列処理の正体
Airflowは「複数のタスクを同時に動かす（=並列実行）」ことができます。例えば：
task_a >> [task_b, task_c, task_d]
この場合、task_b〜task_dは並列で実行されます。
Airflowは1つ1つのタスクは基本的に「シングルスレッド」
データの並列処理（分散MapReduce的な処理）はSpark、BigQuery、Dask、Rayなどに任せます。
つまり、並列に実行されるタスクはそれぞれ独立したプロセスで動作し、そのタスクの中身をどう実行するかはOperatorが担います。
⚖️ 他のワークフローツールとの比較
| ツール名 | 特徴 | メリット | デメリット |
|---|---|---|---|
| Airflow (Composer) | DAGベース、Python、拡張性◎ | 柔軟な処理定義、GCP連携◎、大規模対応 | 学習コストやや高、セットアップ手間（Composerで解消） |
| Prefect | Python製、フロー志向、UI優秀 | タスク間依存が柔軟、エラー処理強力 | DAGより抽象度高く初心者には取っ付きにくい |
| Luigi | タスク依存と実行に強み | 軽量で自前構築しやすい | UIやスケジューラが弱い、GCP連携が薄い |
| Dagster | 型付きDAG、開発者体験重視 | 開発支援ツールが豊富、テストしやすい | 学習コスト高め、Airflowほどの採用実績はまだ少ない |
| Kubeflow Pipelines | ML特化、Kubernetes連携 | 機械学習向けに最適化、GPU対応 | MLに特化しすぎて汎用性に欠ける |
参照記事