Apache Airflow 2025-04-22 リリースノート解説: Airflow 3.0.0

Apache Airflow の公式リリースノートから、3.0.0 の実務上の意味を整理します。

要点

• Airflow 3.0.0 は Airflow 3 系の一般提供開始にあたる大きな節目
• Task Execution API と api-server により、実行環境の分離とリモート実行の土台が強化された
• DAG versioning、scheduler-managed backfills、asset-based scheduling は運用と監査の読み方を変える
• SLA、SubDAG、pickling など一部の legacy 機能が整理され、移行前点検が必須

今回の更新で何が変わるのか

Airflow 3.0.0 は、Airflow 2 系からの単純な延長ではなく、プロジェクトの設計思想を大きく更新する GA リリースです。Task Execution API、airflow api-server、安定した DAG authoring interface、DAG versioning、scheduler-managed backfills、asset-based scheduling、React/FastAPI ベースの新 UI などがまとまって入り、Airflow を「ジョブを定期実行するツール」から、より分離された orchestration platform として扱いやすくする方向が明確になりました。

対象になりそうなユーザー・チーム

• Airflow を self-managed または managed service 上で運用しているデータ基盤チーム
• DAG authoring、scheduler、executor、provider package の互換性を管理している platform team
• backfill、remote logging、secrets backend、asset、HITL、API 連携を本番で使っているチーム

実務でまず確認したいこと

実務では、3.0.0 は「新機能を使えるようになった」だけでなく、既存 DAG と運用手順を見直す契機になります。DAG author は airflow.sdk 名前空間を前提にした import、asset ベースの表現、logical date を持たない実行などを確認する必要があります。platform team は API server、scheduler、worker、executor、metadata DB、UI の境界が変わることで、監視・権限・デプロイ手順に影響が出ないかを見るべきです。特に backfill が UI/API で管理され、DAG 構造の履歴を追えるようになる点は、障害調査や監査の説明力を上げます。一方、削除された legacy 機能を残したまま移行すると、DAG parse や実行時に問題が出やすいため、upgrade check、staging 検証、provider version の固定をセットで進めるのが現実的です。

アップデート前の確認観点

1. 現在の Airflow core、provider packages、Python version、executor、Helm chart または managed environment の version を並べて確認する
2. staging 環境で DAG parse、manual trigger、retry、backfill、log 閲覧、権限別 UI/API 表示を確認する
3. 変更内容が secrets backend、remote logging、metrics、asset、HITL、dynamic task mapping に触れていないかをリリースノートで再確認する

どう読むべきか

Airflow は workflow 基盤なので、patch release でも影響は DAG 実行だけに閉じません。今回の更新は、該当 version を使っているか、近い minor 系へ上げる予定がある場合に、upgrade checklist へ入れておきたい内容です。特に Airflow 3 系へ移行中の組織では、core と providers と deployment surface を分けて読み、障害時に戻せる手順まで含めて検証するのがよさそうです。