Apache Airflow は、データ処理の手順を有向非巡回グラフ（DAG）として Python コードで定義し、時刻起動や依存関係に従って自動実行するワークフロー管理プラットフォームです。2014 年に Airbnb の Maxime Beauchemin が社内の集計ジョブを整理する目的で開発し、2015 年に Apache Software Foundation の Incubator に寄贈、2019 年にトップレベルプロジェクトへ昇格しました。スケジューラ・ワーカー・ウェブ UI が分離しており、Celery や Kubernetes と組み合わせて数千タスクを並列実行できるため、データエンジニアリングの事実上の標準として広く採用されています。
この記事の目次
- DAGとオペレータの中核設計
- Airbnb発祥から2.x系への進化
- ETLとML学習パイプラインの定番化
- Dagster・Prefectとの設計思想比較
- まとめ
DAGとオペレータの中核設計
Airflow の最小単位はオペレータと呼ばれるタスク実体で、BashOperator・PythonOperator・KubernetesPodOperator などが標準で揃っています。これらを Python ファイル内で >> 演算子により接続すると、依存関係を持つ DAG が宣言的に定義され、メタデータデータベース（PostgreSQL や MySQL）に登録されます。スケジューラは cron 形式の指定や timedelta をもとに次回実行時刻を計算し、エクゼキュータ経由でワーカーにタスクを配ります。
実行履歴は SequentialExecutor・LocalExecutor・CeleryExecutor・KubernetesExecutor のいずれを選んでも一貫した形で記録され、Web UI のグリッドビューやガントチャートから失敗箇所を特定できます。失敗時の自動リトライ、SLA 監視、XCom による小規模なタスク間値受け渡し、Connection と Variable による接続情報の集約管理など、運用に必要な機能が初期から組み込まれているのが特徴です。
Airbnb発祥から2.x系への進化
Airflow は Airbnb のデータ基盤チームを率いていた Maxime Beauchemin が 2014 年に着手した社内ツールでした。当時はジョブの依存関係を crontab とシェルスクリプトで管理する文化が主流でしたが、ジョブ数の増大とともに破綻が顕在化し、コードで DAG を書く発想が注目されました。2015 年 6 月に Apache Incubator へ寄贈され、Astronomer や Polidea などの企業がコントリビュータとして加わったことで、プラグイン文化が短期間で形成されました。
2019 年 1 月にトップレベルプロジェクトへ昇格し、2020 年 12 月リリースの 2.0 では高可用性スケジューラと TaskFlow API、REST API の標準化が導入されました。2.3 で導入された動的タスクマッピングや 2.5 系のデータセット駆動スケジューリングにより、データアセット指向の世界観にも歩み寄っています。Google Cloud Composer・Amazon MWAA・Astro などのマネージドサービスが普及したことも、企業導入を後押ししました。
ETLとML学習パイプラインの定番化
代表的なユースケースは、業務システムから抽出したデータを Snowflake や BigQuery、Redshift にロードする夜間 ETL です。S3 への着信ファイルを SensorOperator で監視し、PostgresOperator や SnowflakeOperator で SQL を流したあと、dbt のモデルを呼び出して BI 用テーブルを更新する流れが典型例として確立しています。後段で Tableau や Looker のキャッシュを再生成するタスクを接続すれば、朝一でレポートが最新化された状態を維持できます。
機械学習領域でも、特徴量計算・学習・評価・モデル登録までの一連の処理を DAG で表現する例が多く見られます。Kubeflow Pipelines や MLflow と組み合わせ、GPU ノードでの学習ジョブを KubernetesPodOperator で投入する構成は、PayPal や Lyft、メルカリなどの事例で公開されています。データ更新を契機とした再学習の起動も、データセットスケジューリングにより宣言的に書けるようになりました。
Dagster・Prefectとの設計思想比較
Airflow は「タスクと依存」を一級概念とし、運用ノウハウとプロバイダパッケージの厚みが圧倒的に蓄積されています。一方、2018 年以降に登場した Dagster や Prefect はデータアセット指向や動的な並列実行を初めから前提に据えており、ローカル実行体験や型付け、テスト容易性で優位とされます。Airflow も TaskFlow API やデータセット機能で追随しており、両陣営の境界は徐々に薄れつつあります。
選定では、既存資産や運用体制との相性が決め手になります。Provider と Operator が網羅されている SaaS と接続し、SRE が監視に習熟しているなら Airflow が引き続き有力です。逆に、ノートブックや dbt と密結合した分析チームが小規模に始めるなら、Dagster や Prefect の方がコードベースを軽量に保てます。Astronomer 社の調査でも、Airflow は依然として 50 % 超の企業で本番稼働している主役と報告されています。
まとめ
Apache Airflow は 2014 年に Airbnb で生まれて以来、Python でワークフローを記述するという発想を業界標準に押し上げてきました。新興 OSS との競争を経て 2.x 系では観測性とアセット指向を強化しており、データ基盤の中核として現役で進化を続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント