SPOFとはもう呼ばせない!Airflow 2.0で生まれ変わったHAスケジューラー
見出し画像

SPOFとはもう呼ばせない!Airflow 2.0で生まれ変わったHAスケジューラー

電通デジタルでSREをしている神田です。

この記事は電通デジタルアドベントカレンダーの4日目の記事です。前回の記事は「Reactアプリケーション内でGoogle Analytics計測をする際、react-gaを使わず、gtag.jsを利用した方法とその選択理由」でした。

電通デジタルのいくつかの開発プロジェクトでは、データ処理のためのワークフローエンジンとしてAirflowが採用されています。

この記事では、Airflow 2.0で改善された機能の1つである、スケジューラーのHA(High Availability)対応について解説します。

Airflow 2.0で提供される機能について詳しく知りたい方はAirflow 2.0 Planningを参照してください。

そもそも、スケジューラーって何をしているの?

スケジューラーは、DAGやタスクを監視し依存関係をもとに実行可能なTaskInstanceを見つけ、ワーカーへ割り当てます。

スケジューラーが行なっているおおまか処理内容は下記の通りです。

1. (DagRunの初期化)DAGを解析し、必要であればDagRunを作成しバックエンドDBに登録します。

2. (Executorキューへ追加)DagRunに関連づけられているTaskInstanceの状態を確認し、TaskInstanceの依存関係を解決します。必要であれば、TaskInstanceをExecutorキューへ追加します。

3. (DagRunの状態更新)TaskInstanceの状態をもとにDagRunの状態を更新します。

1.x系のスケジューラーの問題点

Executorキューへの追加処理は、クリティカルセクションとなっており複数のスケジューラーが同時に実行できません。複数のスケジューラーが同時に処理した場合、同じTaskInstanceが複数のワーカーへ割り当てられる可能性が生じます。

画像1

以上の制約からスケジューラーは常に単一インスタンスである必要があり、単一障害点(Single Point of Failure)となっていました。

また、機械学習用パイプラインで数千タスクを短時間で実行するような場合、単一インスタンスで稼働しているスケジューラーが性能上のボトルネックとなる問題がありました。

2.0では複数のスケジューラーを同時に稼働できる

複数スケジューラーが同時稼働できるようにする機能拡張は、「AIP-15 Support Multiple-Schedulers for HA & Better Scheduling Performance」で提案されています。

AIP-15では以下の方針に基づきHA構成を実現しています。

- クラスター構築のために特定のインフラを追加する必要がないこと。

- ノード間で直接的な通信を必要としないこと。

この方針から、Raftなどのコンセンサスアルゴリズムや、Apache ZookeeperやConsulなどのコンセンサスツールは採用されませんでした。Airflow 2.0ではバックエンドDBの行レベルロックによる排他制御によってHA構成を実現しています。

複数スケジューラーが同時稼働したときに、前述のExecutorキューへの追加処理を実行しているスケジューラーが必ず1つになるよう、行レベルロックを利用しています。これは、AirflowのすべてのコンポーネントがバックエンドDBを共有しているためにとれたアプローチです。

画像2

スケジューラーをHA構成で稼働させる際の制約

複数スケジューラーを稼働させるためにはバックエンドDBにPostgreSQL 9.6+またはMySQL 8+を使う必要があります。MariaDB, MySQL 5.x, MSSQLはサポートされていません。

この制約は、行レベルロックを使う際にNOWAITオプションを利用していることから生じています。NOWAITはロック取得ができない場合に直ちにエラーを返すためのオプションです。

MariaDBやMySQL 5.xではNOWAITが実装されていません。その結果、パフォーマンス上の問題が生じるのでサポート対象外とされています。MSSQLについてはまだテストが完全ではないため2.0のリリーススコープから外れています。

おわりに

Airflow 2.0のリリースは開発がAirbnbからApache Software Foundationへ移管されて以降、初めてのメジャーバージョンアップになります。

そのため、今回紹介したスケジューラーのHA構成対応など、抜本的な機能改善や3rd partyパッケージの構成変更など、歴史的経緯により変更しづらかった多くの点が改善されています。

このアドベントカレンダーでも、いくつかの機能の紹介する予定ですので、ご期待下さい。

次回の記事は「【心得3箇条付】全員テレワーク環境でKaizenDay(ハッカソン)を開催してみたゾっ」になります。