マネージドサービスかつクラウドネイティブなワークフロー管理ツールの需要が高まる中、複数のプロジェクトにおいて、それぞれ AWS Step Functions と Amazon MWAA の導入をしているところです。
それぞれのメリット・デメリットはありますので、自身の知見を交えながら、ご紹介します。
いやぁ、要件定義とか技術選定って難しいよね。
Amazon MWAA (Managed Workflows for Apache Airflow) vs AWS Step Functions
概要
ワークフロー管理ツールの2つであるMWAAとAWS Step Functionsの比較です。どちらを選ぶべきかは、ワークフローの複雑さや要件によって異なります。
比較表
特徴 | MWAA | AWS Step Functions |
---|---|---|
使いやすさ | 学習コストが高い | シンプルで直感的 |
柔軟性 | 非常に高い | 限定的 |
ワークフローの視覚化 | DAGで視覚的にわかりやすい | 標準的な状態遷移図 |
スケジューリング機能 | 高度なスケジューリングが可能 | 単純なワークフローに最適 |
統合性 | Pythonスクリプトでカスタマイズ可能 | AWSサービスとの統合が強力 |
コスト効率 | 大規模ワークフローに適している | 小規模ワークフローに適している |
MWAAの長所と短所
長所
-
高度なスケジューリング: DAG(Directed Acyclic Graph)を使い、複雑な依存関係を定義可能
→ DAGとは、一方向のみ前方向に情報が流れるといった意味を持つジョブみたいなもので、集合体となりワークフローを形成します。ここでいう、ワークフローというのは、データの取り組み・データの変換・分析といったデータ分析における一連のタスクを意味しています。私のいる現場では便宜的に「ジョブ」として扱うことが多いです。
→ また、DAGを細分化して、Taskとすることも可能です(≒ DAGとはTaskの集合体である)。DjangoやLambdaからMWAAに移行する時の注意点なども、別記事で紹介予定。 -
カスタマイズ性: Pythonを使って柔軟なロジックを記述可能
→ ネイティブ言語として、Pythonを使用しているようで、フルコードでカスタマイズが可能です -
プラグイン拡張: Apache Airflowのエコシステムを利用可能
→ Apache Airflowにはさまざまなプラグインが用意されており、サポートされています。ただし、ネイティブ管理ツールの一つであるastronomer社のAstro CLIとは、完全に互換性があるとは限りませんので、要注意です。(こちらについて、別途記事を作成予定)
短所
-
設定の難しさ: 比較的初期設定や学習コストが高い
→ Pythonや既存のプロダクトである日立のJP1に精通している人でないと、一から構築が難しいと言わざるを得ません。導入のコツがありますのでそちらに関しては別記事を作成予定 - コスト: 小規模なタスクには割高
AWS Step Functionsの長所と短所
長所
-
使いやすさ: GUIで簡単にワークフローを構築可能
→ ローコードでワークフローの構築が容易です -
AWS統合: LambdaやDynamoDBなどAWSサービスとのシームレスな統合
→ MWAAと同様に、AWSのマネージドサービス - 小規模タスクに最適: スケールの小さいワークフローでコスト効率が良い
-
ステート管理は状態推移で行う
→ 各タスクは「状態(ステート)」として定義されます。次のタスクにどう遷移するか(成功、失敗、リトライ、分岐など)をJSON形式で宣言的に記述することができます。 - **状態保持の自動化``
→ 個人的には、これがすごくありがたいところです。タスクの入出力と出力データが自動的に管理されることから、開発者は状態の保存や管理を意識して開発することはありません。また、状態間での戻り値の引き渡しも簡単です!
短所
- 柔軟性の制限: 複雑なワークフローやカスタムロジックには向かない
-
大規模タスク非対応: DAGのような複雑な依存関係の表現は苦手
→ MWAAのようにコードでの状態遷移ができないが、逆に言えば、単純なものには対応しています。
選択基準
MWAAを選ぶ場合
- 複雑で長期間動作するワークフローを構築したい場合
- カスタマイズ性が重要で、Pythonに精通している場合
AWS Step Functionsを選ぶ場合
- 簡単なワークフローを迅速にデプロイしたい場合
- AWSサービスとの統合を優先する場合
- コストを重視し、小規模なワークフローが多い場合
MWAA と AWS Step Functions の具体的なユースケースはこんな感じかなと思います。
MWAA(Managed Workflows for Apache Airflow)のユースケース
1. データパイプラインの構築
-
例: データを収集・変換・ロード(ETL)するパイプラインを構築
-
詳細:
- Amazon S3 にデータをアップロード
- Glue を使ってデータを変換
- Redshift にデータをロード
- 利点: DAGを使って複雑な依存関係を簡単に管理可能
-
詳細:
2. 機械学習のワークフロー管理
-
例: データ準備からモデルのトレーニング、デプロイまでのパイプライン
-
詳細:
- データ収集(Amazon S3)
- モデルのトレーニング(SageMaker)
- トレーニング後の評価とモデルデプロイ
- 利点: ワークフローが多段階かつ複雑でも柔軟に管理できる
-
詳細:
3. 定期タスクのスケジューリング
-
例: 毎日特定の時間にレポートを生成して送信
-
詳細:
- レポートを生成するスクリプトを実行
- Amazon S3 に保存
- SNS を通じて通知を送信
- 利点: 定期実行タスクを簡単に自動化
-
詳細:
AWS Step Functionsのユースケース
1. サーバーレスアプリケーションのオーケストレーション
-
例: AWS Lambda 関数をチェーン化して処理を実行
-
詳細:
- API Gateway でリクエストを受信
- Lambda 関数でデータ処理
- DynamoDB に保存
- 利点: GUIベースで設計でき、AWSサービスとの統合が容易
-
詳細:
2. エラー管理付きのデータ処理
-
例: 外部APIコールを含むバッチ処理
-
詳細:
- Lambda でAPIコール
- 成功時は次の処理、失敗時はリトライ
- エラーが多発した場合、SNS で通知
- 利点: エラー処理やリトライを自動で管理可能
-
詳細:
3. マイクロサービス間の連携
-
例: ECサイトの注文処理フロー
-
詳細:
- 注文データを受け取り、在庫を確認
- 在庫があれば、決済処理を実行
- 出荷指示を送信
- 利点: 各処理を状態機械として定義でき、フロー全体を見やすく管理
-
詳細:
どちらを選ぶべきか?
MWAAを選ぶ場合
- 複雑で多段階のデータ処理やスケジュールが必要
- データエンジニアがPythonで柔軟にスクリプトを記述する必要がある
AWS Step Functionsを選ぶ場合
- AWSサービスを中心としたワークフローを迅速に構築したい
- 小規模でシンプルな処理が多い
- 失敗時のリトライやエラー通知を簡単に設定したい
図解
Step Functions の状態遷移
+----------------+ +----------------+ +----------------+
| タスク A | ----> | タスク B | ----> | タスク C |
+----------------+ +----------------+ +----------------+
| | |
成功/失敗 成功/失敗 成功/失敗
*** MWAAのDAG ***
Start -> [ Task A ] -> [ Task B ] -> [ Task C ]
\----> [ Task D ] ----/
プロジェクトへの導入
具体的なプロジェクトは明かせないので、以下の通りあくまでも一般論として考慮すべき事項を上げます。そのため、技術選定・要件定義などで、参考にしていただければ幸いです。
1. Amazon EMRを導入して大規模なETLを行いたい場合
Amazon MWAA
-
長所:
- MWAA(Apache Airflow)はAmazon EMRと密接に統合可能です
- AirflowにはAmazon EMR用の専用オペレーター(
EmrCreateClusterOperator
、EmrStepSensor
など)があり、EMRのクラスターの作成、ジョブの実行、ステータスの監視を簡単にスクリプト化できます - DAGを使って、複雑な依存関係を持つデータフローを整理しやすい
- 複数のETLジョブを定期実行したり、失敗時のリトライを設定するなど、細かなタスク管理が可能
-
短所:
- クラスター管理や設定が高度になると、Airflow DAGの保守性が低下する可能性あり
- 大規模な分散データ処理を行う場合、ワークフローエンジン自体にオーバーヘッドが生じることもある
Step Functions
-
長所:
- AWS SDKインテグレーションを使用して、EMRクラスターを作成したり、ステップを実行可能
- JSON形式でワークフローを定義でき、シンプルな処理フローに最適
- エラー処理、リトライ、条件分岐などを簡潔に記述可能
- ネイティブにAWSサービスと統合しているため、AWS環境内での処理効率が高い
-
短所:
- DAGのような複雑な依存関係を扱う場合には柔軟性に欠ける
- 視覚的なタスク管理は可能だが、複雑なETLフローにはコードが冗長になる場合がある
結論
- Amazon MWAA は、大規模で複雑なETLジョブをスケジュールしたり、依存関係が多い場合に向いています
- Step Functions は、比較的シンプルなEMRジョブの実行やAWSネイティブサービスとの統合に優れています
2. サーバーレスなマイクロサービスアーキテクチャでLambdaやSnowflakeと絡めて使う場合
Amazon MWAA
-
長所:
- Snowflake用のカスタムオペレーターを利用することで、Snowflakeに対するクエリ実行やデータ操作を簡単に記述可能
- 複雑なタスク依存関係があってもDAGで整理でき、全体のフローを可視化しやすい
- 他の外部システム(例: Lambda、S3、RDS)とも柔軟に連携可能
- タスク間の状態保持やスクリプトの実行フローのカスタマイズに優れている
-
短所:
- サーバーレス環境でのインフラ管理はやや複雑(MWAAのオーバーヘッドがある)
- Lambdaなどの軽量なサービスと比較すると、スピードやコストがネックになる場合も
Step Functions
-
長所:
- 完全なサーバーレスで、Lambdaと非常に相性が良い
- AWS SDKサービス統合により、Snowflakeとのデータ連携やクエリ実行も可能(SnowflakeクエリをLambdaで実行し、Step Functionsでワークフローを管理)
- 状態管理が自動化されており、コードベースで簡潔にワークフローを定義できる
- 高いスケーラビリティと低コスト
-
短所:
- タスク間の依存関係が複雑な場合、JSON定義が増えて保守が難しい
- DAGのような視覚的なタスク整理がAirflowほど直感的ではない
結論
- Step Functions は、軽量なサーバーレス環境でのワークフロー管理や、AWSネイティブサービス(例: Lambda, DynamoDB, S3)との統合に最適
- Amazon MWAA は、複雑な外部システムとの連携やSnowflakeを活用した高度なETLワークフローに適している
選択基準のまとめ
Use Case | 推奨ツール | 理由 |
---|---|---|
複雑な依存関係を持つEMRベースのETL | MWAA | DAG形式でタスクを整理でき、EMRオペレーターが豊富に用意されているため。 |
シンプルなEMRジョブ実行 | Step Functions | JSONベースで簡潔に処理を定義でき、エラー処理やリトライも自動化されているため。 |
サーバーレス環境でのETL | Step Functions | Lambdaとの統合が簡単で、完全サーバーレスに適しているため。 |
Snowflake連携を含む複雑なETL | MWAA | カスタムオペレーターを活用した外部システムとの複雑な連携が可能で、柔軟性が高い。 |
Amazon MWAAに関する参考文献
-
公式ドキュメント
-
ブログ記事
-
関連コース
AWS Step Functionsに関する参考文献
-
公式ドキュメント
-
ブログ記事
-
関連コース
両ツールの比較に関するリソース
-
公式リファレンス
-
ブログ記事
-
YouTube