はじめに
最近Kubeflowも盛り上がってますが、DevopsとかMLops関連でAirflowも注目度が上がってるように思います。
今回はAirflow入門記事を書くチャンスがあったので、ここに書こうと思います。
Airflowとは？
Airflowとは、ワークフローエンジンと呼ばれるもので、
DAGと呼ばれる有向グラフを用いてジョブを管理します。
WebUIの出来が良く、管理しやすいのが特徴です。
また、Airflowをカスタマイズしていくと、結構色々なことができるので、
ぜひみなさんもAirflowを使って自動化をどんどんしていきましょう...!
Airflowの基本的な構造について
Airflowの基本的な構造については以下のようになっています。
単一ノードであれ、MasterNode-workerNode分離型であれ、
基本的にはこういう構造でそれぞれのプロセスが動いているっぽいです。
特徴的なのが、Airflowは互いの要素について通信したりしないということです。
(webUI→workerは通信することがあります)
WebUIが担保する情報
WebServer機能については、基本的にDagが記載されたFileとairflow.cfgファイル、
そして、metadataが記載されているPostgreSQLを読みにいってます。
WebUIは何を担保しているかというと、SchedulerとWorkerが行った行動記録を読み出すというだけです。
(図には矢印がないですが、裏でworkerと通信もしていることがあるっぽいですが)
ジョブの実行状況などは随時PostgreSQLに書き込まれていきますので、それをただ読んで反映するだけのようです。
Schedulerが担保すること
Scheduler機能に関しては、Dagに記載された手順とPostgreSQLを元にスケジューリングするだけです。
WebUIからトリガー要求が書き込まれることもありますし、それをPostgreSQLを介してSchedulerが読み取り
実行Queueに指示書を送ります。
Schedulerが送る指示書とは、DagIDの何を実行しろという情報で、基本的にDagFileが読めないと実行できません。
Workerが担保すること
Workerは、Schedulerから送られてきたQueueにあるタスクについてひたすらOperationを回していく作業をします。
WorkerはSchedulerが送ってきた、Dagidに基づいて実行を行います。
要は、DagFileにある何番の何をやりなさい。という情報だけが送られてきます。
そのため、WorkerもDagFileを読む必要があります。
Airflow構成の重要なこと
Airflowの各要素に関しては、Webserver→Workerを除き、それぞれの要素に対して通信したりすることはありません。
Airflowを理解する上で重要なのは、全てPostgreSQLとBrokerとDAGFileを通じてのみやりとりをしているということです。
DAGFileとairflow.cfgファイルの共有
その上で重要になってくるのが、このDagFileとairflow.cfgの全体共有です。
WorkerNodeを別に作成するのなら、WorkerNode全てが同じDagFileとairflow.cfgを読まなければなりません。
解決法としてはGit管理してレポジトリ化するということが一番いいです。
基本的に接続情報などに関しても共通化することができますし、何よりレポジトリで管理することができるので、
新しいJobをデプロイしたい時などにも簡単にできます。
おすすめの構成
GKEを用いるなら、CloudComposerを使用しますが、そうでない場合(かなり安く済ませたい場合など)は以下のような構成がおすすめです。
特に機械学習の話でいえば、GPUのハイスペックマシンなどをジョブを回す時だけ起動したい。
ジョブが終了したらインスタンスも終了するといったことも、これを使えば実現できます。
WebServerやSchedulerに関しても、Dockerで動かしても良さそうですね。
Compose化までしなくてもいい気はしますが、セキュアな環境が構築できるかと思います。
おわりに
今後もAirflowの記事をガンガン書いていきます。
今回のおすすめ構成でお話しした、機械学習Jobの時だけWorkerを起動し、仕事をさせる方法についても解説したいと思います。
よろしくお願いいたします。