ホーム  >   ブログ  >   コンピュータシステム / データサイエンス / 機械学習   >   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の S3KeySensorPythonOperator の組み合わせによってフレキシブルに実現できて、その他各種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. もちろん、究極的には常にあらゆる可能性を疑わなければならないわけだが。“手が届く範囲においては”(オンプレを含む)自前での環境構築も必ずしも悪ではない。

  シェアする

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

  サポートする(ありがとうございます)

  一杯のコーヒーを贈る

なお、Amazonのアソシエイトとして、当サイトは amazon.co.jp 上の適格販売により収入を得ています。

  あわせて読みたい

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

  もっと見る

最終更新日: 2022-09-02

  書いた人: たくち

たくちです。長野県出身、カナダ・バンクーバー在住のソフトウェアエンジニア。現在フリーランス。これまでB2B/B2Cの各領域で、データサイエンス・機械学習のプロダクト化および顧客への導入支援・コンサルティング、そして関連分野のエバンジェリズムに携わってきました。趣味は旅行、マラソン、登山、ブリュワリー巡り。近況は takuti.me/now より。ブログへのご意見・ご感想、お仕事のご依頼など、[email protected] までいつでもお気軽にご連絡ください。

  オンラインで直接話す

※当サイトおよび関連するメディア上での発言はすべて私個人の見解であり、所属する(あるいは過去に所属した)組織のいかなる見解を代表するものでもありません。

  過去の人気記事

2021-08-12
いい加減、プロダクトマネージャーという職業に幻想を抱くのはやめよう。
2017-12-16
データサイエンスプロジェクトのディレクトリ構成どうするか問題
2017-06-10
Amazonの推薦システムの20年