ゆるふわMLOps入門 - Re:ゼロから始めるML生活

MLOpsに関してちゃんと勉強中でして、色々事例とか調べてました。とは言うものの、現在ではMLOpsを様々な観点から語られて、MLOpsという言葉にいろんな意味が含まれています。

という事情から色々探していたら、こちらをお見かけしました。

medium.com

書籍へのリンクはこちらです。

n月刊ラムダノート Vol.1, No.1(2019)（紙書籍＋PDF版） – 技術書出版と販売のラムダノート

こちらの書籍では基本的な背景からきれいに整理されていました。こちらを参考にしつつ、頑張ってMLOpsの動向について整理してみたので、そのメモです。

それでは張り切って書いていきます。

tl;dr;
背景・問題設定
MLOps：機械学習システム固有の問題を解決するための開発手法やツールなどを含めた枠組み
- 機械学習システムの全体像
- 具体的な技術要素
先進企業の対応状況
その他、参考資料
感想

tl;dr;

機械学習システムには、通常のシステムにない固有の問題意識がある
- 役割の溝、組織の溝をどう埋めるか
- 機械学習システムの振る舞いを決めるデータの扱い
- 決定的なテストの難しさ
- 本番環境への適用
- 再現性をどうやって確保するか
- 何をバージョン管理すべきか
これらに対応するためにMLOpsという考えのもと各社機械学習プラットフォームを開発しているのが今の状況
- そのために実にさまざまな機能について検討がなされている
参考で注目する企業の事例
- Google
- Facebook
- Netflix
- Airbnb
- Uber
- ThoughtWorks

背景・問題設定

昨今では"AI"や"機械学習"がバズワードになっていて、機械学習に関するシステムの構築に関する話も多く耳にするようになりました。ただし、機械学習に関するシステムには機械学習固有の問題が存在し、通常のシステム開発・運用に比べてより難しいものになっています。

機械学習は学習のアルゴリズムよりその周辺のほうが大きい

この手の話で必ずと言っていいほど登場する"Hidden Technical Debt in Machine Learning Systems"という論文があります。その論文で、機械学習システム全体の機能としては下記の様になっていると指摘されています。

f:id:nogawanogawa:20200301094637j:plain:w600 — Hidden Technical Debt in Machine Learning Systems より

図からわかるように、機械学習システムは学習アルゴリズムに目が行きがちですが、実運用を考える場合には学習アルゴリズムよりその周りの仕組の規模のほうが大きいということがわかります。 そのため、機械学習のシステムはアルゴリズムだけではなく、その周辺の機能開発に非常に工数がかかるということが分かります。

機械学習システムに携わる人の役割の違いによってうまくいかないことがある

"Continuous Delivery for Machine Learning"によれば、昨今の機械学習のシステムを構築する際に、ワークフローとそれらに対応する業種について、下記のようになるかと思います。

f:id:nogawanogawa:20190918083258p:plain:w500

上図のように、機械学習システムを構築することを考えた際、これらには属性の異なる複数の業種が関わることになっていきます。 そして、この役割の違いに起因して、開発に制約が加わってしまうことがあります。

実際にUber Engineeringのブログにも

Before Michelangelo, we faced a number of challenges with building and deploying machine learning models at Uber related to the size and scale of our operations. While data scientists were using a wide variety of tools to create predictive models (R, scikit-learn, custom algorithms, etc.), separate engineering teams were also building bespoke one-off systems to use these models in production. As a result, the impact of ML at Uber was limited to what a few data scientists and engineers could build in a short time frame with mostly open source tools. Meet Michelangelo: Uber's Machine Learning Platform

とあり、複雑なツールを使って良いモデルを作ろうとするデータサイエンティストと、それらすべての要望に対応し切れないエンジニアの間でズレが生じていることがわかります。このように、機械学習システムの開発に関わる人間すべてがストレスなくこなせる環境を整備することがビジネスのグロースにつながることがわかります。

機械学習システムの構築・運用する上で課題も多い

GoogleのTFXの論文によれば、機械学習システムを考える際に特に問題になってくる特徴は下記の４点としています。

1つのプラットフォームで複数のタスクに対応する
継続的な学習・配信
Human-in-the-loop (人間参加型)
プロダクションレベルでの信頼性とスケーラビリティ

一口に機械学習と言っても様々なタスクがあり、それらは求められる機能・性能が異なってきたりします。これら全てに柔軟に対応できなければなりません。また、モデルは一つ作って終わりというわけではなく、最新のモデルを学習・運用していくことが必要になります。モデルの構築には、多くの実験の結果を踏まえて最良のモデルを比較によって導く必要がありますが、そのためには各実験の状況を管理する必要があります。機械学習はデータによって振る舞いが変化するCACEの原則(the CACE principle)があるため、コードの管理だけでは再現性には不十分です。さらに、機械学習のシステムには、様々な形で人間が関わってきます。エンジニアによってデプロイされたり、実際に運用されているモデルについて監視を行ったり、異なる専門家がその状況を分析できるようになっていなければなりません。そして、それらは実運用に耐えられるレベルで安定稼働が必要になり、分散処理などで適切にスケールすることが求められます。

問題設定

ここまで、機械学習システムの構築によるビジネス上のインパクトの大きさに反して、多くの課題があることを確認しました。様々な観点で機械学習システムには難しさがありますが、「MLOpsの歩き方」によれば、MLOpsの問題意識は下記だとしています。

役割の溝、組織の溝をどう埋めるか
機械学習システムの振る舞いを決めるデータの扱い
決定的なテストの難しさ
本番環境への適用
再現性をどうやって確保するか
何をバージョン管理すべきか

これらを解決するため、機械学習システムを構築・運用していく枠組みの必要性が叫ばれ始め、これらを解決するために登場したのがMLOpsをいう考え方です。

MLOps：機械学習システム固有の問題を解決するための開発手法やツールなどを含めた枠組み

上で挙げたようにMLOpsという言葉にある問題意識が複数あり、異なる文脈でMLOpsという言葉が使われています。そのため、どのような文脈かによってMLOpsが指す内容が異なることに注意が必要です。

機械学習システムの全体像

まずは、一般的な機械学習システムについて構成とそれに関わるエンジニアの種類を確認します。機械学習システムを実際に運用しようとした際に一般的なワークフローはこのようになるかと思います。

f:id:nogawanogawa:20200301100311j:plain — TFX: A TensorFlow-Based Production-Scale Machine Learning Platform より

適用する業務によって多かれ少なかれ違いはあるとは思いますが、それでも大筋はこのような構成になるかと思います。 MLOpsに取り組む際には、この流れ全体を意識しながら考えていく必要があります。

具体的な技術要素

MLOpsとしての取り組みには様々ありますが、各取り組みについて確認していきます。

データ収集と特徴量管理

まずはデータの収集から学習に使用する特徴量の管理について確認していきます。

中央管理のデータアクセス

機械学習システムを構築する上で、データの中央管理は非常に重要です。

データが中央管理されていないと学習を開始するまでに大変な労力を必要とします。これが中央管理されていれば、ユーザーはデータについて複雑な探索をすることなく使用することができるため、開発効率が格段に向上します。さらにデータウェアハウスなどは、生データから特徴量を計算した結果を保存しておく先としても非常に有効です。

主に使用されるのはAWSのRedShiftやGCPのBigQuery、AzureのCosmosDBやSnowflakeなどがあります。

データパイプラインの再利用

実務で必要な形式でデータ保存されていることは稀で、ほとんどの場合生データからクレンジングや正規化などを通じて必要な形にデータへの成形が行われます。モデルが本番環境に配信されれば、この同じデータ加工処理は推論にも必要になります。

この様に、データを有効な形に加工するパイプラインは、将来でも使用されることがあることが分かります。そのため、開発効率のためにもデータパイプラインを標準化して共有することは有効です。 このような処理にはApache AIrflowなどのワークフローライブラリがよく使用されます。実際、Uberなどでも実際にワークフローの再利用が行われています。

データのラベリング

多くの機械学習のシステムは教師あり学習を採用している場合が非常に多いですが、その学習のためには教師データのラベリングが必要になります。このラベリングは手作業で行うことが多く、非常にコストが高く、機械学習のフローとは切り離されて考えることが多いです。

しかし、最近ではactive learningやsemi-supervised learningによって、効率よく教師データを生成できる場合があります。 これらの技術によって、機械学習のフローの中にラベル付きのデータ生成を含めることが可能になる場合があり、ML基盤として検討する価値はあります。

Alegion、Figure8、Mighty AIやScaleなどがラベリングやアノテーションにツールを提供しており、Explosion AIやAlectioはactive learningに基づいたツールを提供しています。

特徴量リポジトリ

組織の中で使用される機械学習モデルは、同じ特徴量を使用していることが多いかと思います。これらの特徴量の生成は車輪の再発明になりやすく、共通化することが求められます。また、共通化した特徴量を検索できるような仕組みも合わせて必要になります。このように特徴量に関する変換と、変換した特徴量を組織で共有できる仕組みは、機械学習モデルの開発効率を向上に繋がります。 実際にUberやAirbnbはこのような特徴量を効率よく共有できるリポジトリの開発を行っています。

モデルの構成管理

適切なデータの中央管理やパイプラインの共通化、特徴量リポジトリがあれば、モデルについて推論結果や使用した特徴量だけでなく、推論プロセスや学習など、生い立ちについても管理することが可能になります。

Backfill

機械学習のモデルは日々新しいものが作られていき、その過程で新しい特徴量を開発・使用することもあります。 当然、これまでにない特徴量なので、古いデータについてそれを適用させていく必要が出てきます。

こうしたモデルをプロダクションにしていくには、データウェアハウス内のデータなどに特徴量を自動で事前計算していくことが望まれます。 このbackfillについては、Airflowのようなワークフローライブラリで整備していくことが現状では有望だと考えられます。

データのバージョン管理

機械学習では、度々過去のデータにさかのぼって検証したい状況が発生します。この時、各モデルが学習されたときの正確な状況をそのまま管理しておかないと、モデルの再現性が取れなくなってしまいます。 そのため、モデルのコードだけでなくデータについても適切にバージョン管理することが求められます。

Pachyderm や DVCなどはデータのバージョン管理を実行できるツールとして知られています。

実験管理とモデルのデプロイ

機械学習の開発においては、多数の実験が行われます。こうした実験について適切に管理を行い、優れたモデルを正しく本番環境に適用していくことには、それなりに手間と時間がかかり、MLプラットフォームに求められる大きな機能と考えられます。

実験のトラッキングと可視化

機械学習モデルの開発には、モデルの最適なパラメータを探索するために膨大な量の実験が行われます。これらの実験結果を管理することは非常にコストが大きく、機械学習モデルの開発のボトルネックになりかねません。

そのため、実験のパラメータとその時の結果をセットで管理して、それらを可視化する機能がMLOpsプラットフォームとして提供される場合が多いです。 実際Uberやfacebook、Airbnb、Netflixなどでも、形は違えど実験に関する管理は行われており、開発効率向上のために使用されています。

モデルのバージョンコントロール

実験管理と合わせて、モデル自体のバージョン管理も行われることも多いです。 モデルをバージョン管理すると、データサイエンティストや機械学習エンジニアは過去のモデルについて再現を行うことができる様になります。

管理の仕方は様々で、Pythonのpkl形式で管理する場合もあれば、Dockerコンテナを管理する場合もあり、これらは自動で管理されます。

分散学習

エンタープライズ向けのシステムでは、学習にかかる負荷は非常に大きく、分散処理の必要性は非常に大きくなります。モデル学習の実行を自動で分散処理を適用する仕組みは、モデルを構築するデータサイエンティストやエンジニアから複雑性を排除することに繋がり、開発効率に貢献します。この仕組には、多くの場合Kubernetesによる分散学習が採用され、SparkやHadoopなどのフレームワークによって分散処理が実行されます。

特徴量の自動生成

特徴量エンジニアリングは、機械学習モデルの開発において非常に時間のかかるタスクです。ただ、多くの場合、これに時間がかかるのはデータ収集やその変換に非常に時間がかかっています。この作業のいくつかはデータサイエンティストの勘と経験、ドメイン知識が必要になりますが、その他の特徴量については自動化することが可能になる場合があります。この作業を自動化することで、時間のかかる特徴量エンジニアリングの負担を軽減することができます。

ハイパーパラメータの自動調整

機械学習のモデルには一般にハイパーパラメータによって精度が左右されます。このハイパーパラメータを自動設定するためのソフトウェアは、単純にパラメータをランダムな探索によって設定するものから、ベイズ最適化のような複雑なアルゴリズムを使用するものまで様々存在しています。 ハイパーパラメータの自動調整ツールがプラットフォームに組み込まれていれば、ユーザーはよりモデルリングに集中することができます。

また、AutoMLなども登場しており、特徴量エンジニアリングの自動化とハイパーパラメータの自動設定を同時に行うこともできるようになってきています。こちらについても、シンプルなモデルについては非常に強力なツールで、ユーザーからモデリングの手間を削減することが可能かもしれません。

workflow管理

学習では膨大な数の実験を行い、その過程で中間生成物を作成し、それらを評価することになります。これらは規模が大きくなるにつれ、管理する工数も大きくなり、不具合を生み出す原因になります。そのため、Apache AirflowやKubeflowに代表され自動化されたワークフローは効率と信頼性のために非常に重要な機能になります。 優れたMLプラットフォームには必ず強力なワークフローの概念があり、これらを取り込むことは非常に重要なことです。

コーディング環境の整備と標準化

プラットフォームでサポートしている機械学習モデルとフレームワーク、モデルのコーディング環境については明確な指針があるべきです。一般にNotebookをデータサイエンティストは好み、エンジニアはプロダクションレディな標準コードを好む傾向があり、これらの乖離は早期に解決することが望ましいです。

NetflixやAirbnbではNotebook環境のままプラットフォームでデプロイまで実行できるようにしており、これらの問題を解決しています。どちら側に寄せるにせよ、避けては通れない問題です。

フレームワークのサポート

フレームワークのサポートについては組織ごとにまちまちです。多くのツールをサポートするべきと考える組織もあれば、限られたツールを深く使っていくことを良しとする組織もあります。これは組織がどの様な機能を必要としているかに依存するので、一概に言うことはできません。

例として、Airbnbはフレームワークに対してなるべく柔軟に対応する方針を示していますし、TwitterはTensorflowを重点的に活用していく方針でいたりします。この様に、各社の方針に委ねられています。

モデルのデプロイと性能監視

ここまでで、モデルを構築するまでについてのMLOpsの観点で必要な機能についてみていきました。実際には、モデルの精度だけでなく実行速度であったり信頼性、その他制約が発生します。現実のトラフィックで問題なく稼働しているか、そして想定した予測精度を達成できているかを監視する必要があります。

モデル配信

MLプラットフォームは基本的にスケーラブルで最初から最後まで一貫して管理できるように構成されるべきです。マルチテナントの環境でライブラリの依存関係を再現することは難しく、デプロイの機能を整備することが求められます。多くの場合、デプロイはpklやコード、コンテナなどの形式でデプロイされ、これら一般的にgRPCやRESTやその他のメッセージング形式によって、APIとして動作するようになっています。

モデル配信には多くの場合、ルーティングやロードバランシングなどの機能ができることから、Kubernetesが使われることが多く、例としては、Algorithmiaや Seldonなどがあります。

モデル編成と評価

通常、モデルは時間とともに精度が低下していくため、そのパフォーマンスをモニタリングする必要があります。この基本的な性能監視機能はデフォルトで提供されるべきで、開発サイドとしてはこれをモデルやアプリケーションに応じて自由に拡張可能なようにAPIとして提供することが望ましいです。

基本的には、すべての特徴と予測のログとあとで行われるであろう分析のために記録しておきます。これらをダッシュボードとして表示し、長期間に渡ってそのパフォーマンスを監視できるようにする必要があります。

データバリデーション

予測だけでなく、データに対しても監視が必要です。モデルが学習時に使用したデータと本番環境で予測に使用しているデータの特徴量の分布は監視し、データの傾向の変化について監視する必要があります。データの傾向が著しく変化した際には、モデルについて再学習などのアクションを取ることが求められます。

段階的デプロイとオンライン実験の管理

オンラインの実験の管理も安全なモデルの配信には必要になります。 これにはBlue-Green テストによってモデル配信の動作不良に対するロールバックを可能にしたり、カナリアリリースの機能によって少量のデータで効果を確認してから徐々に展開することが可能になります。 A/Bテストの機能によって、実際のトラフィックに応じてモデルを判断する機構が必要になることもあります。こうした柔軟なデプロイの際の柔軟なオンラインテストの機能も必要になる場合が多いです。

バッチスコアリング

一部のアプリケーションでは扱うデータ量の関係でモデルのスコアリングをオンラインではなく、バッチ処理で行う必要がある場合があります。 その際には、バッチ処理での対応ができるようにしていく必要があります。

先進企業の対応状況

最後に、海外の先進企業がどのようなことに取り組んでいるかについてまとめたいと思います。なんとなく目についた文献についてメモっておきます。

正直一つ一つも結構重たいので、触りだけ確認します。

n月刊ラムダノート Vol.1, No.1(2019)（電子書籍のみ） – 技術書出版と販売のラムダノート

THE DEFINITIVE GUIDE TO Machine Learning Platforms

感想

機械学習ってアルゴリズムに注目が行きがちなんですが、実は通常のシステムに比べて多くの難しい問題をはらんでいたりします。そういった問題に対して先人がなんとか自動化していった結果が、現在のMLOpsの姿になっていると思っています。実際には今回確認した以外にも、たくさんの事例があるでしょうし、多分2020年になった今ではもっと進んだ事例が出てきていると思います。

今回は、あくまで短期間で調べられる範囲ではありますが、事例やレポートを見つつMLOps、MLプラットフォームはどう作っていけばいいかを考えてみました。短期間で調べられる範囲でも、これだけ大量のことを考えないといけないということが分かっただけでも良かったです。

私の周りでも、こういったモダンな開発環境にしていきたいなーとか野望はありますが、私の力ではどうにもならないところがありますね。ここまでの規模になると、結構大掛かりな開発になるので、しばらくは先進的な企業だけが対応していくことになるかと思いますが、いつかこういうのもやりたいですね。

何はともあれ、勉強になりました。