Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する Part5 (End)
Part5では実際に機械学習パイプラインを運用した知見をまとめます。
ただ、執筆時点では機械学習モデルの学習等は組み込まれていません。そのため”End”とするのは時期尚早なのですが、構築の段階でAirflowを使わなくなってしまったので(!?)いったん連載を切ることにしました。なぜAirflowから離れたのか、その代わりに何を使ったのか、その点を解説していこうと思います。本記事の題目は以下の通りです。
- Airflowを採用しなかった理由
- Airflowの代わりに採用した技術(AWS)
- 実際運用して感じた課題
なお本連載を通じて構築したパイプラインで収集したデータが一般公開されます(正式なプレスリリースは来月あたり出る予定です)。データセットの詳細や公開の背景については、別途どこかで解説しようと思います。
Part4からずいぶん間が空きましたが、その間にはデータ公開にまつわるもろもろの調整などがあったという。
Airflowを採用しなかった理由
最終的にAirflowを採用しなかった理由は2つあります。
- 運用コスト
- 開発コスト
運用コスト
Part3でも触れましたが、Airflowのホスティングは結構高くつきます。ホスティングサービスを提供しているのはGCPのCloud ComposerとAstronomerの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をなかなかできていないので。
