Apache Airflow入門――ワークフローオーケストレーションの定番を理解する

Apache AirflowはPythonでワークフローを定義し、タスクの依存関係を管理する分散オーケストレーションプラットフォームです。データパイプラインの世界では事実上のデファクトスタンダードとして10年以上使われ続けており、DAG(有向非巡回グラフ)という概念で「何をどの順番で実行するか」を宣言的に記述します。cronの延長線上にある単純なスケジューラではなく、「依存関係・リトライ・監視・履歴管理」を含む本格的な指揮者だと捉えてください。本記事ではAirflowの基本概念、DAGの書き方、実行環境の選択肢、そしてAirflowが向くケースと別ツールを検討すべきケースを整理します。導入判断の材料として最後までお役立てください。

Apache Airflowとは何か――「データパイプラインの指揮者」

Apache Airflowは、2014年にAirbnbで誕生したワークフローオーケストレーションプラットフォームです。創始者のMaxime Beauchemin氏が社内のバッチジョブ管理の複雑さに業を煮やし、「Pythonで依存関係を記述して、失敗時のリトライや実行履歴まで一元管理できる仕組み」を作ったのが出発点でした。その後Apache Software Foundationに寄贈され、現在はオープンソースのトップレベルプロジェクトとして世界中のデータチームに採用されています。

Airflowの中心概念はDAG(Directed Acyclic Graph、有向非巡回グラフ)です。ジョブAの次にジョブB・C、B・Cの両方が完了したらジョブD、という処理の依存関係を1つのグラフとして記述します。単なるcronとの決定的な違いは、この「依存関係」が一級市民である点です。時刻ベースで独立に走るジョブの集合ではなく、グラフ全体として成功・失敗を捉える設計思想なのです。

したがってAirflowを「cronの代替」と紹介するのは正確ではありません。正しくは「依存関係管理を第一にした分散スケジューラ」であり、失敗時のリカバリ、再実行、バックフィル、可視化といった運用機能まで含めてパッケージ化された統合ツールです。

Airflowの基本概念

Airflowを理解するには、5つの主要概念を押さえる必要があります。どれも運用で頻繁に登場する用語なので、名前と役割をセットで記憶してください。

1. DAG(Directed Acyclic Graph)：タスクの依存関係を定義するグラフそのものです。Pythonファイルとして記述し、dags/フォルダに配置するとAirflowが自動で読み込みます。

2. Task / Operator：DAG内の実行単位を「Task」と呼び、具体的な処理を担うクラスが「Operator」です。BashOperator、PythonOperator、SnowflakeOperatorなど数百種類が存在し、用途に合わせて選びます。

3. Scheduler：DAGの実行タイミングを制御するコンポーネントです。定義されたスケジュール式に従って、タスクの起動をトリガします。

4. Executor：タスクの実行方式を決めます。LocalExecutor(同一ホスト)、CeleryExecutor(分散キュー)、KubernetesExecutor(Pod単位)などがあり、負荷と運用要件で選び分けます。

5. Web UI：DAGの実行状況・ログ・履歴・グラフ表示を確認するダッシュボードです。運用者が日常的に触れる窓口になります。

【Airflowのアーキテクチャ】

[Web Server]  <-->  [Metadata DB (PostgreSQL)]
      ^                    ^
      |                    |
      v                    v
[Scheduler]  ------->  [Executor]
                            |
                            v
                    [Worker1] [Worker2] [Worker3]
                        |        |         |
                        v        v         v
                   [Task実行]  [Task実行]  [Task実行]

※ MetaDBはDAGの状態・ログ・実行履歴を保持する中枢

構成要素	役割	典型的な実装
Web Server	DAG・実行状況の可視化UI	Flask + Gunicorn
Scheduler	DAGのトリガと状態管理	Pythonデーモン
Executor	タスクの実行方式の抽象化	Local/Celery/Kubernetes
Worker	実際にタスクを実行するプロセス	Celeryワーカー等
Metadata DB	DAG・タスク・ログ等の状態永続化	PostgreSQL/MySQL

DAGの書き方――Python as Configuration

AirflowのDAGはPythonファイルとして記述します。「設定ファイルをYAMLで書く」ではなく「プログラムとして宣言する」という思想は、好き嫌いが分かれる設計です。柔軟性は抜群である反面、単体テストのしにくさや副作用の管理が課題にもなります。

まずはシンプルな3タスクのDAGを見てみましょう。毎日午前2時にデータ取得・変換・通知の順で実行するパイプラインです。

from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator
from datetime import datetime

def notify_slack():
    print("Daily pipeline completed")

with DAG(
    dag_id='daily_sales_pipeline',
    start_date=datetime(2026, 1, 1),
    schedule='0 2 * * *',
    catchup=False,
) as dag:
    ingest = BashOperator(task_id='ingest', bash_command='python ingest.py')
    transform = BashOperator(task_id='transform', bash_command='dbt run')
    notify = PythonOperator(task_id='notify', python_callable=notify_slack)

    ingest >> transform >> notify

タスクの依存関係は、>>演算子で宣言的に記述します。複雑な依存も直感的に書けるのが特徴です。

ingest >> [transform_sales, transform_users] >> join_tables >> notify
# ingestの後、transform_salesとtransform_usersを並列実行
# 両方が終わったらjoin_tables、その後notify

dbtとの統合も定番パターンです。BashOperatorでdbt runを呼び出すのが最もシンプルな連携方法で、dbt Coreと組み合わせて日次バッチを構築する場合はこの形がよく採用されます。

dbt_run = BashOperator(
    task_id='dbt_run',
    bash_command='cd /opt/dbt_project && dbt run --target prod --profiles-dir .',
    env={'DBT_PASSWORD': '{{ var.value.dbt_password }}'},
)

より高度な統合にはastronomer-cosmosやdbt-airflowのようなライブラリを使えば、dbtのモデル単位で1タスクを生成する細かい制御も可能です。

Airflowの実行環境の選択肢

Airflowは自由度が高い反面、実行環境をどう用意するかが最初の悩みどころです。大きく分けて4つの選択肢があります。

1. セルフホスト：Docker ComposeやKubernetes上に自前で構築する方法です。自由度は最大ですが、アップグレード・監視・バックアップまですべて自前で担います。

2. AWS MWAA(Managed Workflows for Apache Airflow)：AWSのマネージドAirflowで、VPC・IAM連携が強みです。バージョン追従にやや遅れがある点に注意が必要です。

3. GCP Cloud Composer：GCPのマネージドAirflowで、BigQueryやDataprocなどGCPサービスとの連携が非常にスムーズです。

4. Astronomer：Airflowの商用マネージド提供元で、Astro CLI・プロダクトロードマップへの影響力・専門サポートが強みです。エンタープライズ運用では第一候補になります。

実行環境	運用負荷	コスト	スケーラビリティ	カスタマイズ性	推奨チーム規模
セルフホスト	高	低〜中	設計次第	最大	インフラ力のある大規模チーム
AWS MWAA	低	中	中〜高	中	AWS中心の中規模チーム
Cloud Composer	低	中〜高	高	中	GCP中心の中〜大規模チーム
Astronomer	最低	高	高	中	エンタープライズ全般

Airflowのメリットと課題

Airflowを評価する際は、光と影の両面を冷静に見ることが肝要です。以下に代表的なメリットと課題を対比で示します。

メリットは3つあります。第一に、Pythonで何でも書けるという柔軟性です。第二に、Operator・Providerのエコシステムが圧倒的に豊富で、主要なクラウドサービスやSaaSとの統合が即座に可能です。第三に、10年近い運用実績と巨大なコミュニティがあり、トラブル時の情報資産が豊富です。

一方で課題も無視できません。第一に、DAG・Operator・Executorといった概念が多く学習コストが高めです。第二に、インフラ運用の負担は決して軽くありません。第三に、ローカル開発・単体テストのしにくさがあり、Dagsterのような新世代ツールと比較するとやや古さを感じる部分があります。

項目	メリット	課題
柔軟性	Pythonで任意の処理を記述可能	設定ファイルがコードのため副作用管理が難しい
エコシステム	Operator/Providerが豊富	互換性の地雷（Providerのバージョン依存）
運用実績	10年超の採用実績、情報が豊富	学習コストが高く、初心者には重厚
開発体験	DAG可視化UIが実用的	ローカル開発・単体テストが困難
スケジューリング	依存関係・リトライ・バックフィルが標準装備	インフラ運用負担が大きい

Airflowを使うべきケース・別ツールを検討すべきケース

Airflowが最も輝くのは、複雑な依存関係を持つ多システム連携のバッチ処理です。データベースからの取り込み、機械学習の前処理、DWHへの投入、BIツールへの通知、といった異種のシステムをまたぐワークフローでは、AirflowのOperator群とPythonの柔軟性が威力を発揮します。チームにPythonスキルがあり、自由度を優先するなら第一候補です。

逆にAirflowが過剰になるケースもあります。例えば「dbtのジョブを日次で回したいだけ」なら、dbt Cloud単体のジョブスケジューラで十分です。ローカル開発の体験を重視するならDagster、クラウドネイティブなシンプルさを求めるならPrefectといった選択肢も有力です。オーケストレーションツールの横断比較は別記事で扱っていますので、選定の際はそちらも参考にしてください。

まとめ――Airflowは「柔軟」だが「手厚い運用」が前提

本記事の要点を振り返ります。

• AirflowはPythonでDAGを定義する分散ワークフローオーケストレーションプラットフォーム
• 基本概念はDAG・Task/Operator・Scheduler・Executor・Web UIの5つ
• 実行環境はセルフホスト・MWAA・Cloud Composer・Astronomerの4択
• 柔軟性と豊富なOperatorが強み、学習コストと運用負荷が課題
• 複雑な依存関係を扱うならAirflow、シンプルなELTならdbt Cloud単体でも可

次に読むべき記事は、オーケストレーションツールの横断比較、dbt入門、そしてCI/CD設計の実践編です。DE-STKではAirflow含むデータパイプライン設計の診断と実装支援を提供しています。導入や見直しの相談はお気軽にどうぞ。

よくある質問(FAQ)

Q. Apache Airflowとは何ですか?

A. PythonでワークフローをDAG(有向非巡回グラフ)として定義し、タスクの依存関係管理・スケジューリング・監視を行うオープンソースのオーケストレーションプラットフォームです。

Q. AirflowとcronJobの違いは何ですか?

A. cronは時刻ベースの単一タスク実行ですが、Airflowはタスク間の依存関係管理、リトライ、ログ管理、Web UIによる可視化を提供します。複数タスクの順序制御が必要な場合にAirflowが有効です。

Q. Airflowの運用にはどのくらいのインフラが必要ですか?

A. 最小構成（Docker Compose）なら1台のサーバーで稼働しますが、本番運用ではKubernetes上のデプロイやマネージドサービス（AWS MWAA、Cloud Composer）の利用が推奨されます。