ホーム  >   ブログ  >   AWSのマネージドAirflow "MWAA" 所感

2021-12-19

AWSのマネージドAirflow "MWAA" 所感

Google Cloud Composerのリリース（2018年7月19日GA）から遅れること2年数ヶ月、AWSは2020年11月24日に Managed Workflows for Apache Airflow (MWAA) をリリースした。

それから1年、遅ればせながら自分でも軽く試してみた。AWSコンソールからAirflow UIに飛ぶのに違和感を覚えつつも1、種々のAWSサービスとの連携を考えると「むしろなんで今まで無かったんだろう」という気さえする。

概要

公式のデモ動画が分かりやすいので、まずはそれを見てみよう。

ポイントは次の通り。

  • DAGファイル（Pythonコード）は専用のS3バケットに置く
  • OSSのAirflowに完全準拠
  • （事前に設定した上限値までの）Workerの自動スケール
  • KMS管理下の鍵によるデータ暗号化
  • CloudWatch連携によるログ・メトリクスの一元化
  • 各タスクの実行に際して用いられるIAM Roleを指定

もちろん設定・デプロイはCDK (CloudFormation) 経由で行うこともできて、サンプルは aws-samples/amazon-mwaa-examples などにある。ユースケースとしては、たとえばS3のファイル操作はAirflowの S3KeySensor と PythonOperator の組み合わせによってフレキシブルに実現できて、その他各種AWSサービス用のオペレーターも豊富。

AirflowのAWSオペレーターたち

Airflow本体のコードベースに内包されていて、MWAAリリース以前から開発の続く apache-airflow-providers-amazon が各種オペレーターを提供している。ETL + MLに必要であろう主要サービスは一通りカバーされている印象。

MWAAに限らない一般的な話になってしまうので深入りはしないが、たとえば前処理から最終的な予測結果生成までのフローを組むとすれば次のようなイメージ。

[prep_data_1, prep_data_2, ...] >> build_features >> predict >> post_process >> publish
  • 特徴量エンジニアリングはSparkのDataFrame処理で実現したいので、EMRオペレーターを用いる。ドキュメントにも記載されているように、ここは単一オペレーターではなくて、EmrCreateJobFlowOperator >> EmrAddStepsOperator >> EmrStepSensor >> EmrTerminateJobFlowOperator のチェインから構成される。
  • 予測は SageMakerTransformOperator から、学習済みSageMakerモデルによるBatch Transformジョブで行う。
  • 再びSpark on EMRで、予測結果の後処理。具体例として、『後処理による人気アイテムの“格下げ”で確保する推薦多様性』で書いた後処理 rerank を差し込むならココだろう。多様性の指標をCloudWatchに書き出してモニタリングするのもアリかもしれない。多様性がある閾値を下回ったらアラートあるいはタスク失敗、とか。
  • そして途中/最終結果の吐き出しはデータフォーマットや保存先に応じて適当なオペレーターを選ぶ。

あるいは、データのマイグレーション用途であればRedshift, Glue, Database Migration Service (DMS) オペレーターあたりが活躍しそうだ。ETLの"Transform"に際して必要な単純なバッチ処理には ECSOperator が使えるだろうか。

なぜMWAAか

ハマりどころとしては、MWAAそれ自体よりも、各オペレータが扱うAWSサービスたちが問題になることの方が多そうだ。個人的には、この点がMWAAを使うことの最大の理由であるように感じた。

たとえばパーミッション周りは、状況に応じて適切にKMSキーやIAM role/policyを設定しないとワークフローが最後まで走りきらず、何かと苦戦しそうな雰囲気。ここで仮に自前でAirflow環境を構築・運用していたとすれば、問題がAirflow環境それ自体に起因するものか、Airflow <> AWS間でおかしなことが起こっているのか、それともAWS上の設定に限った話なのかを切り分けるところから始めなければならない。

一方でワークフロー実装に際しては、こまめにイロイロといじって試行錯誤を繰り返したいこともまた事実。したがって、Airflow環境それ自体を疑う状況というのは可能な限り避けたいものである2。

AWS Podcastの8月の放送回ではそのあたりの動機、「なぜAWSがマネージドAirflowを作ったのか」をプロダクトマネージャーから直接聞くことができる。

当然といえば当然だが、冒頭の言及からかなり機械学習ユースケースを意識している様子が伺える。公式アナウンス記事のサンプルデータもMovieLensで“匂わせ”感がある。

とはいえ主要な動機はやはり、ネットワーキング（サービス間連携）、スケーリング、モニタリング、ロギングにおける設定・オペレーションの簡素化にある。タスクワーカーひとつひとつがVPC上のプライベートサブネットに接続されたFargateコンテナであり、これによってユーザは先に挙げたような種々の煩わしさから解放される。

mwaa-architecture

※ 画像ソース：What Is Amazon Managed Workflows for Apache Airflow (MWAA)?

「多様性の指標をCloudWatchに書き出してモニタリング」と先述したように、個人的にはモニタリング・ロギングに際して享受できるメリットが特に大きいと感じる。

ワークフローとは、処理を自動化してラクをするための道具であると同時に、異常をいち早く検知するための“仕組み”でもある。そしてそれは、社内SREやインフラエンジニアのためである以前に、エンドユーザの体験を高いレベルで維持し続けるために欠かせない要素となる。

その点において、Airflow単体のロギング機構は必ずしも有用であるとは言い難いし、インフラ稼働状況・タスク出力それぞれの各種メトリクスを可視化する際のベストプラクティスやツール選択は議論の分かれるところ。ゆえに、ここで「とりあえずCloudWatch」として話を前に進められることは、かなりのアドバンテージであるように思う。

以上も踏まえて、第一歩としてローカルで試すための公式Dockerイメージは aws/aws-mwaa-local-runner より入手可能。ただし apache-airflow-providers-amazon==1.3.0 とやたら古いので注意（執筆時点での最新版は 2.5.0）。EMRクラスター依存のタスクを1時間以上走らせたらboto3が ExpiredTokenException を吐いて、「そんなギャグみたいな死に方する？」と思っていたら、最新版では既に解決している話 (apache/airflow #16771) だったりした。

というわけで、MWAAの概要と雑感でした。試すのが遅すぎた感は否めないが、リリースから1年経った今、果たしてどれだけ使われているのだろうか。

そして、そもそもデータエンジニアリングの現場では既にAirflowがワークフローエンジンのデファクトという理解で良いのだろうか。Luigiは元気だろうか・・・。そんなことを考えていたら、GitHubスター数に基づくグラフと考察を見かけたので貼っておく。

Luigi...

1. EMRでHadoop, Tez, SparkのUIに飛ぶのは「まぁそういうもの」という認識が強いが、Airflowの比較的フレッシュなUIは「エンタープライズ感」があまり無いので不思議な感覚に陥る。私だけでしょうか。 ↩
2. もちろん、究極的には常にあらゆる可能性を疑わなければならないわけだが。“手が届く範囲においては”（オンプレを含む）自前での環境構築も必ずしも悪ではない。 ↩

  シェアする

このエントリーをはてなブックマークに追加

  カテゴリ

コンピュータシステム データサイエンス 機械学習

  あわせて読みたい

2017-12-09
AmazonのDynamoDB論文を眺めた
2017-10-06
The Amazon Way on IoT - Amazonのビジネスから学ぶ、10の原則
2017-04-09
なぜSparkか

  もっと見る

最終更新日: 2022-09-02

  書いた人: たくち

Takuya Kitazawa（たくち）です。長野県出身、カナダ・バンクーバー在住のソフトウェアエンジニア。これまでB2B/B2Cの各領域で、Web技術・データサイエンス・機械学習のプロダクト化および顧客への導入支援・コンサルティング、そして関連分野の啓蒙活動に携わってきました。現在は主に北米（カナダ）、アジア（日本）、アフリカ（マラウイ）の個人および企業を対象にフリーランスとして活動中。詳しい経歴はレジュメ を参照ください。いろいろなまちを走って、時に自然と戯れながら、その時間その場所の「日常」を生きています。ご意見・ご感想およびお仕事のご相談は [email protected] まで。

  近況   一杯のコーヒーを贈る

  免責事項

  • Amazonのアソシエイトとして、当サイトは amazon.co.jp 上の適格販売により収入を得ています。
  • 当サイトおよび関連するメディア上での発言はすべて私個人の見解であり、所属する（あるいは過去に所属した）組織のいかなる見解を代表するものでもありません。
  • 当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、個人ブログという性質上、誤情報や客観性を欠いた意見が入り込んでいることもございます。いかなる場合でも、当サイトおよびリンク先に掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。
  • その他、記事の内容や掲載画像などに問題がございましたら、直接メールでご連絡ください。確認の後、対応させていただきます。