概要

TIG 所属の多賀です。

AWS 上でのワークフロー構築のため、Step Functions を直近で導入しました。

筆者は Airflow (MWAA) の経験が長く、いくつかブログも書いています。 (過去ブログ一覧)。今回、両サービスを利用してみた上での比較を整理したく記事化しました。

前提として、どちらも素晴らしいサービスで、ユースケースに合わせて選定していくことが大事かと思います。

サービス概要

各サービスについて、概要を整理しました。

※ Airflow は AWS 上でマネージドサービスとして提供されている Amazon Managed Workflows for Apache Airflow (以下 MWAA) をベースに記載します。

サービス比較

各サービス別に、Good/Challenge に分けて記載しています。

Good

MWAA

• Pythonで実現できることは基本すべて実装可能で、実装の制約が少ない
• UI が充実しており、実行履歴、ログ、実行時間等の様々な情報を参照することが可能
• UI 上でワークフローの任意の位置からリトライ可能
• 各種クラウドSDK/OSS API を呼び出しを簡易化するための provider がサードパーティ提供されている
  • Providers packages reference — apache-airflow-providers Documentation
  • provider を pip でインストール後、各 provider に実装されている operator 関数を呼び出すことで実現可能

Step Functions

• AWS サービスの呼び出しをローコード(パラメータ指定程度)で実現可能
• Workflow Studio を利用した AWS コンソール上でのワークフロー組み上げが可能
  • Amazon States Language を直接書くことなく定義できる
• パラメータ指定(JSON形式)でワークフロー実行可能
• AWS サービスの呼び出しごとにログが出力されており、各 SDK の呼び出し結果を確認可能

Challenge

MWAA

• ソースコードベースであることから実装コストはある程度見込む必要あり
  • 初期構築等で、デフォルトで用意されていなければ、単純なクラウド SDK 呼び出しをするだけの処理を Python で都度実装が必要になる
• UI 上からパラメータ指定での実行がしづらい
  • 厳密には実行可能な方法があるが、UI 上でサポートされていない or ジョブの実行画面外に存在しており、運用しづらくなっている
  • (2022/01/07時点で MWAA 未サポート) Aiflow version 2.1.0 以上でパラメータ指定(Trigger Dag w/ config)でワークフローを実行可能となっている
  • デフォルトで実行時間等はワークフローへ渡されるため、時間ベースでの実行の場合は特段困らない
• 運用コスト面では、EC2等と同様に起動時間課金であり、基本は立ち上げたままで運用されることから、Step Functions よりコストは高くなる
• ソースコードを実装するため単体テストを実装したいが、外部 API 呼び出し等が多くなる場合はモック化含めてコストは高くなる
• VPC の構築が必須
  • MWAA 向けのネットワーク要件が存在するため、VPC 構築時に合わせて確認しておく必要がある
  • Amazon MWAA でのネットワーキングについて - Amazon Managed Workflows for Apache Airflow
• マネージドサービスのため直接意識することは少ないが、Airflow の構成について学習するコストはかかる

Step Functions

• ワークフロー途中からの実行が未サポート
  • 初期構築等で失敗しながら動かしていく際に、毎回最初からになって効率が悪かった
  • 運用上は、リトライ単位 = 1 State Macine の原則で構築すれば問題なし
• Workflow Studio で作成した定義を IaC 管理化に置きたい場合は、環境情報(本番、開発..)等の一部修正が必須
  • 「Workflow Studio で基本作成→JSONをダウンロード→IaC 管理下へ配置」の作成フロー
• 組み込み関数でできることがあまりないため、入力を少し加工をしたい等で Lambda の実装が必要
• API の実行結果が非同期で成功する場合(インスタンス作成等)に、成功を待ち受けるためのループ処理を都度実装する必要がある
  • Job ステータスのポーリング (Lambda、AWS Batch) - AWS Step Functions
• 各 State の入出力を扱うための、Input/Output/ResultPath,ResultSelector等の学習コストは低くはない
  • 同一のパラメータをワークフロー全体で引き回したいケースで実装に考慮が必要
    • OutputPath を指定して、Input がすべて上書きされる問題に直面した
  • 最終的に、ResultSelector で残したいレスポンス情報を選定して、ResultPath で追加する形式を取ることが多かった
  • 参考: Step Functions の入出力処理 - AWS Step Functions

選定方針

各ケースごとに細かい要件等があるかと思いますが、大まかな方針としては以下の通りと考えています。

• MWAA (Airflow)
  • ワークフローの複雑度(※ 実行するタスクの量が指標) が高い
  • 実行する 処理時間の長いタスクが複数連続している (リトライ観点)
  • 単純な AWS SDK や API Call で処理が完結しない (※ 設計としてワークフローにロジックをもたせる可否は要検討)
  • 初期構築にコストをかけることができる
• Step Functions
  • 複雑度が低くAWS の各種 SDK を呼び出すのみの単純なワークフロー
  • ワークフローの実行頻度が低い
  • 手動でのパラメータ指定必須

所感

Step Functions を本格的に利用したのは初めてだったので、同じワークフロー系サービスとして経験のあった Airflow との比較をしてみました。

実際に AWS 上でワークフローを構築しようとする際は、まずはこの2つのサービス比較から入ることが今後は多くなってくるのではと思いますので、参考になりましたら幸いです。

Airflow は 2.0 がリリースされて以降も、月1程度で継続的にリリースがされていてますので、引き続きウォッチしていていきたいと考えてます。

参考

• Apache Airflow Documentation — Airflow Documentation
• Amazon Managed Workflows for Apache Airflow (MWAA) とは - Amazon Managed Workflows for Apache Airflow
• AWS Step Functions とは - AWS Step Functions