Airflow、Airbnbの社内scriptを世界のworkflow標準へ変えたOSSの歩み

冒頭

Airflowは、2014年にAirbnbで始まったworkflow toolから、Apache Software FoundationのOSS projectへ成長した。

Maxime Beaucheminは公式project pageでcreatorとして記載される。出典

創業

出発点は、データ処理の依存関係を人が追うのではなく、PythonのDAGとして読めるようにすることだった。

Airflowは最初からOSSとして公開された。出典

転機

Apache Incubatorへの参加で、Airbnbの社内scriptは一社の事情を越えるprojectになった。

schedulerやmetadata databaseなどの運用要素も、失敗と再実行を扱うための構成として積み上がった。出典

成長

DAG、operator、provider、documentationの組み合わせが、別々のdata systemをつなぐ共通言語になった。

OSSの中立性は、単一vendorに閉じない導入判断を支えた。出典

結び

Airflowの歩みは、automationを増やす話ではなく、workflowの失敗をチームで説明できる形に変える話だ。

機能の多さより、読めるDAGと運用の共有が長期の資産になったと言える。

Airflowは、複数システムにまたがる定期処理の依存関係を、PythonのDAGとして読める形にしたいdata teamに刺さる。

scheduler、retry、監視を別々のscriptからworkflowの一部へまとめるため、job数が増えるほど価値が出る。出典

一方で、単純なjobには重い。

DAGをコードでレビューでき、provider ecosystemを選べる点が、data platformの共通言語としての適合を支える。出典

DAG・operator・providerの蓄積と、Apache projectとしての中立性が参入障壁になる。

技術単体より、既存workflowと運用知が移行コストを作る。出典

ネットワーク効果は中程度。

利用者が増えるほどprovider、解説、運用知が増えるが、workflow自体は単独でも動くため、強い両面市場ではない。出典

data engineer、analytics engineer、platform teamなど、複数データ処理の依存関係をコードで管理する組織。

単純な定期jobだけの小規模チームには別の軽量toolが向く。出典

DAGをPythonコードで表現したこと、OSSとしてproviderとoperatorを受け入れたこと、retry・監視・securityまで運用面をprojectの中心に置いたことが再現可能な要因だ。出典

scheduler、metadata database、workerの運用負担があり、DAGの設計やupgradeも利用者の責任になる。

realtime処理や少数jobでは過剰構成になり得るため、導入前の適合判断が必要だ。出典

OSSを入口にし、documentation、provider ecosystem、Apacheの中立的な運営で採用範囲を広げる。

managed serviceは運用負担を外部化する経路になるが、project本体と各providerの価値を混同しない設計が必要だ。出典

主要チャネル: open-source community, provider ecosystem, documentation, conferences

普及するplatformは、taskを実行するだけでなく、依存関係・失敗・再実行・責任範囲を共有する記法を持つ。

AirflowのDAGは、個別scriptをチームの運用資産へ変換する境界になった。出典

日本では、複数部門のデータ連携や定型業務を横断するplatformとして、導入支援と障害対応runbookを組み合わせる余地がある。

個人情報を扱うDAGの権限・監査を先に設計するのが現実的だと考える。出典