valid,invalid

関心を持てる事柄について

Airflow webserverのUIがなぜ2種類存在するのか

AirflowでDAG実行時にGUI, CLI, REST APIからパラメータを渡す - valid,invalid件の調査をしていて知ったのだが、Airflow webserverのUIには2種類のUIが存在する。

利用できる機能に差分があるうえに、Airflow本体のリリースフローも初見ではわからず、ややこしかったので整理する。

2種類のUI

1. flask-admin based web UI

1系ではデフォルトで使用されるUI。名前の通りflask-adminベースで作られている。

2. FAB based web UI

Roll Based Access Controlを提供しているのでドキュメントではRBAC UI と表記されることもある。 突然の略称のため名前からはわかりづらいがFlask AppBuilderベースで作られている。

1.10.0以降で利用可能 (changelog) であり、airflow.cfg[webserver] rbac = Trueを設定するとこちらになる。

なお、flask-admin based web UIはLegacy UIと表され、2系ではFAB based web UIのみの提供となる予定とのこと。


一部の機能は現時点で最新である1.10.12でも FAB-based web UI にしか存在しない。 同じバージョンでもviewに差分がある例↓(GUI から DAG Run に conf を渡すフィールドがFAB-basedの方にしか存在しない)

歴史的経緯

Improving Airflow UI Securityで明晰に語られている。

2015年のAirflowはセキュリティに関する機能が少なかった

誰もがメタデータDBを見られる、グローバルに共有されているオブジェクトを編集できる、DAG を開始または停止したり失敗した TaskInstance を成功マークにしたり、その逆をしたりすることができる…といった具合。

Nginxなど別の機構でGUIへのアクセスを制御することはできたがかなり不便だったのでRBAC UIに取り組み始めた。

Airflow webserverはFlask Adminで構築されており、RBAC UIを実装するために4つの可能性のあるアプローチが検討されていた

  1. Django への移行
    • ビルトインのユーザー認証システムと、より成熟した拡張機能のエコシステムを備えている
    • 移行作業の量が利益に比べて限定的となる
  2. クラッチ
    • Airflow に合わせてカスタマイズされた RBAC システムを構築することができ、この機能を時間をかけて進化させる柔軟性が得られる
    • 利用できる資産を利用しないので多大なコスト
    • 想定しているRBACセキュリティモデルはかなり汎用的なものであるため、ゼロからの実装は魅力的でなかった
  3. Flask extension
    • Flask-RBACやFlask-Principalなど、RBACを扱うために特別に書かれたflask拡張機能
    • 拡張機能はいずれも事前に定義されたロールを用いる必要があるが、Airflowではconfigurableであってほしい
  4. Flask-Appbuilderに切り替える
    • Flask-AppBuilder (FAB) は Flask-Admin に似た小さいフレームワーク
    • ビルトインの RBAC システムがconfigurable
      • セッション管理、様々な認証バックエンドとの統合ができる
    • Apache-Superset] で使用されていて実績がある

最終的にFABが採用された。メンテナは機能を統合して Airflow をshipすることに集中し、FABがほとんどを処理してくれることを期待した。

実際の移行作業

どちらもDjangoインスパイアのフレームワークであり、慣習も踏襲されていたので良かった。ORMのSQLAlchemyサポートを両者ともしてたのでモデル層は全く手を入れずに済んだ。

たくさん手を入れたのはViewであり、いくつかの機能が足りなかったぶんはFABにパッチを送った。

レポジトリ戦略

もともと別レポジトリで概念実証のために開発していた。

https://github.com/wepay/airflow-webserver 今は404

おかげで検証や開発は高速で進んだが、Airflowの早い進化に追従するには本体にマージしなければいけない。代替UIのための別レポジトリを維持するコストもかかるし、Airflow本体と誤認されたり、間違ってインストールされたりしたくないため。

互換性

Airflowは下位互換性を重視するため、ユーザーが新しいUIに移行するための十分な時間を確保したかった。レガシーUIを完全に廃する前に、短期間は両方のUIを並行して利用できるようにすることを決めた。

  • 既存の UI 関連のコードはすべて www/ ディレクトリに置く
  • コードベースがif文だらけにならないように、UI関連の変更はすべてwww_rbac/という新しいディレクトリで行い、RBAC専用の別のFlaskアプリを作成した

リリース

RBAC UIは2018-08にAirflow 1.10.0でリリースされた

Changelog — Airflow Documentation

airflow/UPDATING.md at master · apache/airflow · GitHub

今後

Airflow 2.xからはレガシーUIは提供しなくなるため、1系を使っているユーザーにもrbac = Trueで試すことを推奨している。

airflow/UPDATING.md at master · apache/airflow · GitHub

Airflowをベースにしている[Google Clound Composer]ではRBAC UIをサポートしていないため、一部機能は2系になるまで使えないはず。Clound IAMでおおむね権限を制御できるかもしれないがDAGレベルの制御は難しそうかも(触ったことないので不明)。


masterairflow/www/views.pyにmergeされているし、shipされたはずの機能がなぜ手元で表示されないのか…?と悩んでいたら、flask-admin based web UIだった、というハマりがあったので謎が解けてよかった。ちょうど移行の過渡期にAirflowに触り始めてしまっただけだった。

大きなOSSの内部大改装は作業だけでなくストラテジを練ったり広報したりも含めてものすごい大変というのが垣間見えた。Airflowメンテナが、www以下への変更をリリース前にwww_rbacへcherry-pickしていてかなり大変そうだったので早く2系が公開されて負担が減っていくとよいと思う。