Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する Part5 (End)

piqcy
piqcy
Sep 27 · 8 min read

Part5では実際に機械学習パイプラインを運用した知見をまとめます。
ただ、執筆時点では機械学習モデルの学習等は組み込まれていません。そのため”End”とするのは時期尚早なのですが、構築の段階でAirflowを使わなくなってしまったので(!?)いったん連載を切ることにしました。なぜAirflowから離れたのか、その代わりに何を使ったのか、その点を解説していこうと思います。本記事の題目は以下の通りです。

  1. Airflowを採用しなかった理由
  2. Airflowの代わりに採用した技術(AWS)
  3. 実際運用して感じた課題

なお本連載を通じて構築したパイプラインで収集したデータが一般公開されます(正式なプレスリリースは来月あたり出る予定です)。データセットの詳細や公開の背景については、別途どこかで解説しようと思います。

Part4からずいぶん間が空きましたが、その間にはデータ公開にまつわるもろもろの調整などがあったという。

Airflowを採用しなかった理由

最終的にAirflowを採用しなかった理由は2つあります。

  1. 運用コスト
  2. 開発コスト

運用コスト

Part3でも触れましたが、Airflowのホスティングは結構高くつきます。ホスティングサービスを提供しているのはGCPのCloud ComposerAstronomerの2つが主です。Astronomerの場合は月額$100まで抑えることが可能ですが、固定で毎月かかるとなるとそこそこの金額です。

スケジューラーは、スケジュール実行をする都合上常に稼働している必要があります。その点がこうしたコスト高の要因となっています。こちらとしては四六時中ジョブが稼働するわけではないので、必要な時に起きてそれ以外は寝ている(=料金がかからない)方がありがたいです。そのため、AWS Lambdaのようなサーバーレスの構成の方が割安であるという結論に至りました。

開発コスト

クラウドベンダのマネージドサービスを使うと、複雑な機能が比較的容易に開発できます。具体的にはキューを使用した並列実行、各種動作のロギング・監視、タスクをつなげてのジョブ作成、そのスケジュール実行などなどです。もちろんAirflowでもこれらは実装可能なのですが、並列実行をするにはLocalExecutorか、いやCeleryExecutorか、とか逐一調べるのはかなり面倒でした。

そこで、今回はAWSのマネージドサービスを利用して構築することにしました。AWSを使ったのはチームで使用しているインフラだからという理由で、特にこだわりがあったわけではありません。使用したサービスは以下で紹介しますが、他のクラウドプラットフォーム(GCP/Azure)でも対応したサービスがあると思います。

Airflowの代わりに採用した技術(AWS)

最終的なインフラ構成は以下のようになりました。詳細は発表スライドをご参照ください

実装にはAWSの以下のサービスを使用しました。

  • 並列実行: SQS + Lambda (ECS)
  • ロギング・監視/スケジュール実行: Cloud Watch
  • ジョブ作成: Step Function
  • データ蓄積・参照: Glue + Athena

データをSQS+Lambdaで収集してS3に保存、保存したデータをSQLで参照できるようにGlue Crawlerでテーブル構築、とするとデータベースレスでデータ活用環境を構築できます。データベースも基本は常に稼働している必要がありコスト高なので、データベースレスにすることで費用を抑えることができます。

上記の処理を行うため、Step FunctionからGlueのCrawlerを呼び出しています。ただ、GlueのCrawlerはStep Functionから呼び出すことができません。そのため、GlueのCrawlerを起動するPython shellジョブを作成してそれを呼び出すという方式を取っています(なおSparkのジョブにすると起動がめちゃめちゃ遅かったです)。

実際運用して感じた課題

Airflowのように、稼働監視のダッシュボードがないのは地味に面倒です。一応CloudWatchに統合できるのですが、たとえばStep Functionの実行状況を見る場合・・・

StepFunctionの画面。これは見やすいですね。

Cloud Watchで見る場合。心電図を見るような感じですね・・・

Cloud Watchは定量的なメトリクスを時系列に表示するのが主機能です。Cloud Watchの中では成功/失敗はCount 1の定量指標であり、上記のようにしか表示できないという事情があります。そのためもうちょい表現力がほしいなと感じます。またAthenaと統合されていないので、データの整合性チェックと稼働状況を統合的にみることができません。このあたりのダッシュボード機能が弱いなと感じます。

コストは以下のような感じです。Astronomerより安いコストで抑えられています。8月/9月は初期データ移行やデータセット作成処理など非定期のタスクをかなり行っていたほかYANSのアノテーションハッカソンの処理も上乗せされているので、実際はこれよりかなり低くなると思います($20~30ぐらい?)(コスト配分タグをActiveにしているのになぜかフィルタに出てこず、ちょっと混ざってます)。

Glueは大した仕事をしていないのに結構かかってますね。Athenaを使う上で欠かせないとはいえ、実働部隊のSQS/Lambda/ECSよりがぜん料金がかかっているので、ちょっと納得いかない感があります。振り返ればGCSでBigQueryにした方が安上がりだったかもしれません(ちゃんと比較してみないとわかりませんが)。

S3 × Athenaで、データベースを使わずSQLでの分析環境を構築できるのは便利+お財布にやさしいです。AthenaではJOINやWindow関数も使用でき、今のところ不都合を感じたことはありません。

AthenaのクエリをSageMaker(Jupyter)で分析/学習、という連携はPythonユーザーであれば心地よく使える分析環境だと思います(「エンドユーザー」にとってはまだちょっと高度ですが)。

開発・運用してみての結論は以下になります。

  • 開発/運用コストを抑えられた。
    基礎的な部分は1~2週間ぐらいで開発できた。
    Airflowは調査やテストなどで結構手間取った(慣れれば下がるが)。
  • ダッシュボード機能が弱い。
    稼働監視とデータチェックを統合的にみられない。
    記載の自由度が低く対応を行うための動線(リンク)が貼れない。
  • データベースレスで分析環境が整えられるのは財布にやさしい。
    低コストのS3のみでデータソースを構築できる。
    更新処理は難しいが、Athenaの集計で対応するなどやりようはある。
    ただ、Glueのコストは高め。

最終的にAirflowは使いませんでしたが、使うか否かは環境によると思います。判断材料の一助となれば幸いです(GCPで作った方のコスト感とかはちょっと聞いてみたいです)。

次の連載では、自然言語処理を使った開発をしっかりやろうかなと思います。最近NLPをなかなかできていないので。

programming-soda

Exciting research & programming like soda!

piqcy

Written by

piqcy

All change is not growth, as all movement is not forward. Ellen Glasgow

programming-soda

Exciting research & programming like soda!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade