高可用性で apache airflow (正式には airbnb の airflow として知られている) スケジューラをデプロイする方法は?
明らかに高可用性構成でデプロイする必要があるバックエンド DB または RabbitMQ について質問しているわけではありません。
私の主な焦点はスケジューラーです - 何か特別なことをする必要がありますか?
高可用性で apache airflow (正式には airbnb の airflow として知られている) スケジューラをデプロイする方法は?
明らかに高可用性構成でデプロイする必要があるバックエンド DB または RabbitMQ について質問しているわけではありません。
私の主な焦点はスケジューラーです - 何か特別なことをする必要がありますか?
少し掘り下げた後、複数のスケジューラーを同時に実行するのは安全ではないことがわかりました。これは、そのままではエアフロースケジューラーを高可用性環境で使用するのは安全ではないことを意味します。
エアフロー チームは、DAG データ構造にロック メカニズムを追加することでこの問題を解決することを計画していますが、これはまだ実装されていません (2 つのスケジューラーを実行して確認したところ、同じ DAG インスタンスがスケジュールされていることがわかりましたが、これは良くありません)。これについては、https: //groups.google.com/forum/# !topic/airbnb_airflow/-1wKa3OcwME で説明されています。
スケジューラーを独自のコードでラップし、クラスター ツールを使用してリーダーを選出することで、この高可用性の問題を回避する方法を見つけました (私は個人的に、この目的のために領事を使用しています)。この方法では、選出されたマスターのみがスケジューラを実行し、マスターがダウンすると、スレーブが彼に取って代わります。
高可用性環境でエアフローを使用する場合は、これを考慮してください。これは、すぐに使用できるエアフロー スケジューラが現在これに適していないためです (この問題を自分で解決しない限り)。
編集 - マスター スレーブ ソリューションの代替アプローチは、クラスター マネージャー/スケジューラーを使用して、1 つのエアフロー スケジューラー インスタンスのみが常に利用可能であることを確認することです。このアプローチは、あなたが持っているクラスターマネージャーの自己修復能力に依存しています。たとえば、 mesos と nomad の両方がこの種の構成をサポートしています (私はその単純さから前もって nomad を選びました)。
私の個人的な経験では、いくつかのベスト プラクティスについて見つけた指示に従うことでした。つまり、10 回の実行ごとにスケジューラを再起動し ( -N 10 )、可能な場合はこのソフトウェアを使用します。
https://github.com/teamclairvoyant/airflow-scheduler-failover-controller
また、スケジューラーが消えていないことを確認するために監視システムに ping を送信する DAG も使用しています。