Amazon Managed Workflows for Apache Airflowの構築
概要
Airflowのマネージドサービスは今までGCP上でCloud Composer(以下、composer)を使うのみでしたが、AWSでもAmazon Managed Workflows for Apache Airflow（以下、MWAA）の検証機会があったので操作ログを残しました。
composerと比較してどのような違いがあるかについても記載しています。
## 環境の作成
Airflowのバージョン
2021年11月17日時点で以下の二つでした。2.1系の対応が待たれます
- 2.0.2
- 1.10.12
DAGを格納するS3バケット
composerでは自動的に作成されますが、MWAAでは別途作成しておく必要があります。
依存環境のインストール
S3バケットを指定したのちに、requirements.txtのパスを指定して、作成後に配置するとインストールができます
環境のスペック選定
以下から選べます
モニタリングの設定
composerとは違い細かく調整ができそうです、ただ選択肢が多いと何を基準に判断すれば分からないのでひとまず全てのログを情報レベルで取得するように設定しました。
ネットワークの設定
MWAAにおけるネットワークの設定では、既存のVPCやサブネットを選択する手法に加えてcloud formationによるテンプレートを用いて一発で作成も可能です（便利)
全ての設定をして作成ボタンを押すと30分弱で環境が構築されます。このぐらいの時間がかかるのはcomposerでも同様でした。
DAGの更新
S3の指定場所にDAGファイルをアップロードしてから2-3分ほどで更新されました。
肌感覚ではcomposerより遅いです。
なお、ユーザーガイドでは30秒に一度DAGファイルをFargateに同期する仕様とのことでした
Amazon MWAA runs a sync operation on your Amazon S3 bucket every thirty seconds. This causes any DAG deletions in an Amazon S3 bucket to be synced to the Airflow image of your Fargate container.
依存環境の更新
単にs3バケットにあるrequirements.txtを更新すれば良いのではなく、更新したのちにMWAAの環境を更新してあげる必要があります
作成後に編集可能な部分
- Airflowバージョン
- DAGコードの設置場所
- webサーバーへのアクセス
- セキュリティ・グループ
- 環境クラス（マシンタイプ・ワーカー数など）
- マシンスペックの変更は現状composerでは出来ず再作成が必要となるので、これは個人的にかなりアドバンテージがありました
- モニタリングの設定
料金
大枠でサーバー代(時間課金)とDAG実行代(実行時間に応じて課金)の二つです。これはcomposerと同じですね。
陥った罠
以下のPyPiを入れようとして更新するとOoops!されてしましました。原因は該当パッケージの最新バージョン(6.1.0)にAirflow2.1以上の要件があったからです。はやく2.1系に対応してほしいですね。
# Airflow2.0系で4.0.0以降は入れれない
apache-airflow-providers-google==3.0.0
エラー
Something bad has happened.
Please consider letting us know by creating a bug report using GitHub.
Python version: 3.7.10
Airflow version: 2.0.2
Node: redact
-------------------------------------------------------------------------------
Error! Please contact server admin.
まとめ
composerより詳細な設定、更新ができるのでこっちの方が良いかもしれない(現時点の感想)
Discussion