MWAA(Amazon Managed Workflows for Apache Airflow)への移行理由
こんにちは。
株式会社Goalsインフラチームの今村です。
今回からはTech記事を公開し、開発部署にスポットを当てた情報発信もしていきたいと思います！！
本記事はその第１回ということで、弊社クラウドサービス「HANZO」シリーズを裏から支えているツールの１つであるAmazon Managed Workflows for Apache Airflow（以後、MWAAと呼称）へ移行・選定した理由をメリット・デメリットを併せてご紹介します。
クラウドサービス「HANZO」シリーズについてご興味をもっていただいた方は、以下の記事もご覧ください。
Airflowとは
突然ですが、Apache Airflow（以後、Airflowと呼称）というツールをご存じでしょうか。
一言でまとめると、Airbnbが開発したオープンソースのワークフロー管理ツールになります。
弊社では定期的な実行を必要とするバッチ処理群を管理するために、「HANZO」シリーズのサービス開始当初から利用していました。
当時はAWSのEC2上にAirflowのWeb・Scheduler・Worker専用インスタンス、RDS上にも専用のインスタンスを立てて起動していました。
しかし2020/11/24に、AWSからAirflowがマネージド化されたMWAAサービスが公開されました。
ここからは既存のAirflowから、MWAAへ移行することを決断するにあたった理由をメリット・デメリットを併せてご紹介します。
メリット
自動スケーリングされる
以前はAirflowを動かすために起動していたEC2・RDSインスタンスの監視や、スケールアップ・スケールアウトの計画等で工数がかかっていましたが、これらが不要になりました。
弊社のAirflowの使い方はサービス利用者増に伴い、実行したいバッチ処理群も増加する必要がある構築となっており、一定数増える度にメンテナンス等を伴う工数が発生していました。
しかし、MWAAへの移行に伴ってリアルタイムで勝手にインスタンス数が増減してくれるようになり、運用工数の削減ができました。
インスタンス監視・再起動
上記メリットと被る点がありますが、何らかの問題が発生してインスタンスが異常停止した場合等に自動で該当インスタンスは再起動されます。
インフラ担当の方々には、ステータス状況を監視・異常停止等の問題時には即検知して手動作業が発生する！！
・・・といったフローが発生するケースもあるのではないでしょうか。
（かくいう私が、MWAA移行前までは上記運用をしていました。。）
特に弊社の場合、以前まではSchedulerサーバーが高負荷による異常停止が稀にあったため、この対応が不要になることは実工数的にも精神的にも楽になりました。
Airflow管理の一元化
MWAAはAWSの提供するサービスのため、各種設定値やワークフロー状況等の確認は、AWSのマネジメントコンソールやAirflow UIで行います。
元々の「HANZO」シリーズのサービスがAWS上で動いているのもあり、各種ツール等もAWSに一元化されるのは管理面で運用工数が削減されました。
また、弊社の場合はAWS IAM Identity Center(旧 AWS Single Sign-On)を利用しており、AWS上に一元化されることはセキュリティ面での個別対策にかける工数も削減されました。
AWS IAM Identity Centerについての詳細は、以下のAWSドキュメントをご覧ください。
https://aws.amazon.com/jp/iam/identity-center/
デメリット
Airflowの最新バージョンに対応していない
本記事公開時点では、Airflowのバージョンは2.4.2まで公開されています。 しかし、MWAAではAirflowのバージョン2.2.2までが利用可能となっており、最新バージョンに追従しきれておりません。
先日、弊社でもバージョン2.2.5にて修正が適用された問題に該当してしまい、設定値変更等で暫定的に回避しています。
良くも悪くもマネージド化されている
マネージド化されていることはメリットのみではありませんでした。
一部情報はブラックボックス化されており、自身でAirflow環境を運用している場合には見える情報が取得できないものがあります。
具体例をあげると、データベース等もマネージド化されているものに内包されています。
そのため、実クエリをAirflowデータベースに対して実行してデータを取得するようなことはできなくなっています。
運用事例が少ない
MWAAは2020年末に公開されたサービスというのもあり、まだまだ運用事例が少ないと感じています。
（少なくとも個人的には。。）
Airflow起因の問題例や運用事例等は調べれば多数見つかります。
しかし、MWAA起因の事例となると極端に少なくなるというのが所感です。
なので、是非とも本記事をご覧いただくことで、MWAAを利用してみようかな・・・と少しでも検討いただけますと非常に嬉しいです！！
まとめ
弊社の場合は、主にメリットとして記載した運用工数の削減の面から既存のAirflowからMWAAへの移行を決断しました。
本記事の弊社事例をご参考にいただければ幸いです。
また、本記事では紹介しきれなかったのですが、MWAAの類似サービスとしてAWS StepFunctionsがあります。
AWS StepFunctionsについての詳細は、以下のAWSドキュメントをご覧ください。
https://aws.amazon.com/jp/step-functions/
弊社ではどちらのサービスも運用しており、利用用途によって使い分けています。
次回の機会があれば、これについての弊社運用について等をご紹介したいと考えています。
最後に
株式会社Goalsでは一緒に働く仲間を募集しています！
ご興味ある方はいつでも気軽にご連絡ください。
弊社ホームページの採用情報ページにて、写真写りの悪い私の社員インタビューも公開されています。
冷やかし半分でも見ていただけたら幸いです・・・！！
最後までお読みいただき、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？