ワークフロー管理 - Amazon MWAA で Apache Airflow をマネージド運用する
Amazon MWAA (Managed Workflows for Apache Airflow) によるデータパイプラインのオーケストレーションを解説。セットアップ、DAG 管理、Step Functions との使い分けまで実践的に紹介します。
MWAA の位置づけと Airflow の課題
Apache Airflow はデータパイプラインのオーケストレーションにおけるデファクトスタンダードです。Python で DAG (有向非巡回グラフ) を定義し、タスク間の依存関係・スケジュール・リトライ・アラートを宣言的に管理できます。しかし、Airflow を自前で運用するには、Web サーバー・スケジューラー・ワーカー・メタデータ DB (PostgreSQL) の構築と運用が必要で、バージョンアップやスケーリングの負荷が大きい課題がありました。Amazon MWAA (Managed Workflows for Apache Airflow) は 2020 年にリリースされたフルマネージドの Airflow サービスで、環境の構築・パッチ適用・スケーリング・可用性確保を AWS が管理します。ユーザーは S3 バケットに DAG ファイルと requirements.txt をアップロードするだけで、Airflow 環境が自動的に構成されます。MWAA は Python コードで DAG を定義するため、Git によるバージョン管理、コードレビュー、ユニットテストとの親和性が高く、ソフトウェアエンジニアリングのプラクティスをデータパイプラインに適用できます。
環境構築と DAG のデプロイ
MWAA 環境の作成には、DAG を格納する S3 バケット、VPC (2 つ以上のプライベートサブネット)、実行ロール (IAM) が必要です。環境クラスは mw1.small ・ mw1.medium ・ mw1.large ・ mw1.xlarge ・ mw1.2xlarge の 5 段階で、同時実行可能なタスク数とスケジューラーの性能が異なります。mw1.small は小規模な検証環境向け (約 0.49 USD/時)、mw1.large は本番ワークロード向け (約 1.96 USD/時) です。 ```python # DAG の例: Glue ジョブ → Athena クエリ → SNS 通知 from airflow import DAG from airflow.providers.amazon.aws.operators.glue import GlueJobOperator from airflow.providers.amazon.aws.operators.athena import AthenaOperator from airflow.providers.amazon.aws.operators.sns import SnsPublishOperator from datetime import datetime with DAG('daily_etl', start_date=datetime(2026, 1, 1), schedule='@daily') as dag: extract = GlueJobOperator(task_id='run_glue', job_name='raw-to-clean') query = AthenaOperator(task_id='run_query', query='SELECT count(*) FROM clean.events', database='clean', output_location='s3://results/') notify = SnsPublishOperator(task_id='notify', target_arn='arn:aws:sns:ap-northeast-1:123:alerts', message='ETL completed') extract >> query >> notify ``` DAG ファイルを S3 にアップロードすると、MWAA が自動的に検出してスケジューラーに登録します。Python の追加パッケージは requirements.txt で指定し、プラグインは plugins.zip として S3 に配置します。
AWS サービスとの連携と運用
MWAA は apache-airflow-providers-amazon パッケージを通じて、 AWS サービスとの豊富な連携 Operator を提供します。 Glue (ETL ジョブ実行)、 Athena (SQL クエリ)、 EMR (Spark ジョブ)、 Redshift (データウェアハウスクエリ)、 Lambda (関数呼び出し)、 ECS (コンテナタスク実行)、 SageMaker (ML トレーニング/推論)、 Step Functions (ステートマシン実行) など、データパイプラインで必要なサービスをほぼ網羅しています。ワーカーの Auto Scaling により、タスクキューの深さに応じてワーカー数が自動的に増減します。最小ワーカー数と最大ワーカー数を設定でき、ピーク時のみスケールアウトしてコストを最適化できます。モニタリングは CloudWatch メトリクス (DAG 処理時間、タスク成功/失敗数、キュー深さ) と Airflow の Web UI の両方で行えます。 Web サーバーはパブリックアクセス (IAM 認証付き) またはプライベートアクセス (VPC 内のみ) を選択できます。 データパイプライン 構築のアーキテクチャを網羅的に学ぶなら、技術書 (Amazon)を参照してください。
Step Functions との使い分け
MWAA と Step Functions はどちらもワークフローオーケストレーションサービスですが、設計思想と得意領域が異なります。Step Functions はイベント駆動型で、API Gateway や EventBridge からのトリガーに対して低レイテンシ (ミリ秒単位) で応答します。状態遷移を JSON (ASL) で定義し、Lambda ・ ECS ・ Bedrock などを組み合わせたサーバーレスワークフローに最適です。料金は状態遷移あたりの課金 (Standard: 0.025 USD/1,000 遷移) で、短時間・高頻度のワークフローに向いています。一方、MWAA はスケジュール駆動型のバッチパイプラインに強みがあります。複雑な依存関係 (数十〜数百タスクの DAG)、リトライポリシー、SLA 監視、バックフィル (過去日付の再実行) など、データエンジニアリング固有の要件に対応します。既存の Airflow 資産 (DAG、プラグイン、カスタム Operator) をそのまま移行できる点も大きな利点です。判断基準として、リアルタイム処理や API 連携なら Step Functions、日次/時次のデータバッチ処理なら MWAA を選択するのが適切です。
MWAA の料金
MWAA の料金は環境クラスとワーカーの時間課金で構成されます。mw1.small 環境は 1 時間あたり約 0.49 ドル (月額約 353 ドル) です。追加ワーカーは mw1.small で 1 時間あたり約 0.055 ドルです。環境は 24 時間稼働するため、月額の最低コストは約 353 ドルです。セルフホストの Airflow (EC2 + RDS + Redis) と比較すると、運用コスト (パッチ適用、スケーリング、監視) の削減効果を含めた TCO で評価します。DAG の実行頻度が低い場合は Step Functions の方がコスト効率が高い場合があります。
まとめ - MWAA の活用指針
Amazon MWAA は、Apache Airflow のマネージドサービスとして、データパイプラインのオーケストレーションを運用負荷なく実現します。Python による DAG 定義はバージョン管理やテストとの親和性が高く、AWS サービスとの豊富な Operator 連携により、ETL ・分析・ ML パイプラインを効率的に構築できます。Step Functions がイベント駆動・サーバーレスのワークフローに適するのに対し、MWAA はスケジュール駆動・複雑な依存関係を持つバッチ処理に最適です。既存の Airflow 環境からの移行先として、またデータエンジニアリングチームの生産性向上ツールとして、MWAA は有力な選択肢です。