Amazon MWAA
Apache Airflow をフルマネージドで提供し、DAG によるデータパイプラインのオーケストレーションを実行するサービス
概要
Amazon MWAA (Managed Workflows for Apache Airflow) は、Apache Airflow をフルマネージドで提供するワークフローオーケストレーションサービスです。Airflow のスケジューラー、ワーカー、Web サーバーのインフラ管理が不要で、DAG (有向非巡回グラフ) の開発とデータパイプラインの運用に集中できます。Glue、EMR、Lambda、ECS、Redshift、Athena など AWS サービスとのネイティブ連携に加え、Airflow のプロバイダーパッケージを通じてサードパーティサービスとの統合も可能です。
環境クラスとワーカースケーリング
MWAA の環境は mw1.small、mw1.medium、mw1.large、mw1.xlarge、mw1.2xlarge の 5 つのクラスから選択します。クラスはスケジューラーと Web サーバーの CPU・メモリを決定し、同時実行可能な DAG 数とタスク数に直結します。小規模なパイプライン (DAG 数 50 未満) であれば mw1.small で十分ですが、数百の DAG を並列実行する場合は mw1.large 以上が必要です。ワーカーはオートスケーリングに対応しており、最小ワーカー数と最大ワーカー数を設定すると、キューに溜まったタスク数に応じて自動的にスケールアウト・スケールインします。最小 1、最大 25 の範囲で設定でき、タスクのバースト実行時にもキュー待ちを最小化できます。ただし、ワーカーのスケールアウトには数分のリードタイムがあるため、予測可能な大量バッチ処理では事前に最小ワーカー数を引き上げておく運用が有効です。環境クラスの変更は環境の更新操作で可能ですが、更新中は数十分のダウンタイムが発生するため、メンテナンスウィンドウを設けて実施します。
DAG のデプロイと S3 同期の仕組み
MWAA の DAG ファイルは S3 バケットの指定プレフィックス配下に配置します。S3 にアップロードされた Python ファイルは、約 30 秒間隔でスケジューラーに同期され、自動的にパースされて DAG として登録されます。DAG ファイルの更新も同様に S3 へのアップロードだけで反映されるため、デプロイパイプラインは S3 への同期処理を組み込むだけで構成できます。CodePipeline と CodeBuild で DAG の構文チェックとユニットテストを実行し、テスト通過後に S3 にデプロイするワークフローが実用的です。requirements.txt を S3 に配置すると、環境更新時に pip install が実行され、追加の Python パッケージをインストールできます。ただし、requirements.txt の変更は環境の更新を伴うため、DAG ファイルの更新とは異なり即座には反映されません。DAG 内で外部ライブラリを使用する場合は、requirements.txt に固定バージョンで記述し、環境更新後に動作確認を行います。startup.sh スクリプトを使えば、環境起動時のカスタム初期化処理も定義できます。
プラグイン管理と VPC ネットワーク設計
MWAA のカスタムプラグインは、plugins.zip として S3 にアップロードします。プラグインには Airflow のカスタムオペレーター、センサー、フック、Web UI の拡張などを含められます。社内共通のデータベース接続ロジックや独自の通知処理をプラグインとしてパッケージ化すれば、複数の DAG から再利用できます。プラグインの更新は環境の更新を伴うため、requirements.txt と同様にメンテナンスウィンドウでの適用が推奨されます。MWAA 環境は必ず VPC 内に作成され、2 つ以上のプライベートサブネットが必要です。Web サーバーへのアクセスモードはパブリックとプライベートの 2 種類があり、パブリックモードではインターネット経由で Airflow UI にアクセスでき、プライベートモードでは VPC 内からのみアクセス可能です。ワーカーから AWS サービス (S3、Glue、Redshift など) への通信には、VPC エンドポイントまたは NAT ゲートウェイが必要です。コスト最適化の観点では、頻繁にアクセスする S3 と CloudWatch Logs には VPC エンドポイントを設定し、NAT ゲートウェイのデータ処理料金を削減する設計が効果的です。