apache airflowは様々なサービスを含んでいて何が何をしているのか良くわからない上に設定項目も無数にありそれぞれが指すパラメータも抽象的でドキュメントが整っておらずバージョンを重ねるごとに負債が増えていっているソフトウェアであるにもかかわらずよく使われています。何をするソフトなのか、をひとことで言うと、「cronのパイプラインをweb UI付きで管理できる」ソフトです。
内部で運用している企業は本当にちゃんと分散させて安定稼働しているのか？という程度には単一ホストを想定した設計になっていて、マイクロサービスっぽさに騙されて複数ノードに展開すると軽く地獄を見ます。地獄を見ないためにdocker imageを作ってみました。alpine linuxを使っているので軽いです(約1GB。。。airflowの割には、軽いです)。airflow v1.9です。
その他dockerfileはこちら:
Contents
何ができるの？
http://site.clairvoyantsoft.com/setting-apache-airflow-cluster/
上記記事の画像みたいな感じの構成が作れます。つまり、workerを複数ノードに展開したairflow環境がセットアップできます。正確には、schedulerもwebserverも別のインスタンスとして動かすようにしています。
そもそもairflowの内部には、
- scheduler: タスクの登録やスケジューリング
- webserver: web UI
- worker: タスクの実行インスタンス(celeryベース)
- flower: celeryのクラスタ管理画面(optional)
といったサービスがあり、さらに
- db: タスクのメタデータや実行履歴などを記録。mysqlやpostgresqlなどが利用できる。
- broker: タスクキュー。分散実行に必要。
上記のような外部のサービスも分散環境時には必要になりますが、このそれぞれのサービスがコンテナになっているというイメージです。
どうやってセットアップするの？
Dockerをインストールし、READMEのUsageに沿って進めてください。
- DAGのフォルダやmysqlの/var/lib/mysqlはvolumeとしてmountするようにしています。gitなりreplicationなりで管理してください。
- 各サーバーマシンに各サービスを分散させていたとしても、同一のDAGフォルダがそれぞれにマウントされている必要があります。git clone等してきてください。これはairflowの設計のクソな点の一つです(他にもたくさんあります)。
- 実行ログはs3に保存するようにしています。どうしてs3なのかは下記。
どうしてログはs3保存なのか？
airflowは複数workerでscaleさせることができる、と謳ってはいますが開発元のairbnbではSynapse/Nerveなどのクラスタ管理システムの支援を受けることでそのスケーラビリティを達成していたと考えられます。つまり実際に普通の複数ノード環境に展開するだけではシステムが崩壊します。
具体的な例を挙げましょう。
airflowのwebserverでは各タスクの実行ログを見ることができますが、これは各workerからwebserver側にログをfetchして表示しています。もちろんこの際webserverは各workerのipアドレスを知っている必要がありますが、これは各workerのhostnameとipの紐付けがairflowによって/etc/hostsに記述されることで達成されます。
しかしここには落とし穴があります。airflowはみんな同一のマシンで動くことを前提にしている、またはhostnameが何らかの方法(クラスタの管理システム等)で共有されることを前提にしており、それぞれのサービスはそれぞれのマシンの/etc/hostsに自分のhostnameとipを記述するだけなのです。
webserverとworkerが別のマシンで動いている場合、当然webserverはworkerのipを知ることができないので、ログを取得することができません。なので、s3にログを保存しているというわけです。
コメント