システム開発本部のデータサイエンスユニットに所属している19新卒の豊原です。

巷で結構耳にするMLOpsですが、結構苦労していらっしゃる組織も多いと考えます。今回の記事では、マイクロアドで挑戦するMLOpsについての概要と、その挑戦について解説します。

機械学習システムが抱える根本的な問題
私たちの思うMLOpsとは
CEという概念
レコメンドシステムが抱える根本的な性質
マイクロアドが作るシステムの現状
MLOpsで実現すること
技術的詳細
- Airflowを用いて学習を同時並行で回す
- MLflowを用いて学習結果を保存する
機械学習エンジニア絶賛採用中

機械学習システムを構築する上で、他の通常のシステムと決定的に違うことがあります。
それはシステムの劣化の早さ*1と問題調査という点にあります。

機械学習システムが抱える根本的な問題

機械学習システムが抱える根本的な性質として、データを基に生成されたアルゴリズムであるということが挙げられます。
機械学習とはそもそも、「明示的にプログラミングすることなく、コンピュータに行動させるようにする科学」*2のことです。これはつまり、データが変わればアルゴリズムも変わってしまうのと同様に、教師データだけでなく推論データが変わればアルゴリズムが対応できなくなることを示唆しています。

これは劣化の早さに問題を抱えることになります。前提としてITシステムというものには、保守運用が必ずついてきます。作って終わりというわけではないのです。これはシステムというものが相対的に時間とともに劣化するということを示唆しています。さらに言えば、機械学習システムの分野では、推論データもどんどん変わっていくことが想定されます。外側の状況が変わってしまえば、機械学習システムは期待していたシステムのビジネスバリューを提供できないことになります。それはまずいので、日ごとに学習させていくバッチを構成すると、アルゴリズム自体が日々更新されていくため、昨日まではよく動いていたのに、急に精度が落ちてしまったとなりかねません。

さらに言えば、明示的なプログラミングをされていないアルゴリズムですので、問題調査に骨が折れるという部分が大きな特徴でしょう。急に精度が落ちたという結果だけしか表示されない中で、何が変わったのかという原因調査は、困難を極めます。

機械学習システムは、システムの対応力を高め、ビジネスバリューを高めてくれますが、同時に大きな負債である*3とも言えます。こういった負債をどうやって解消していくか、どうやって監視していくかというのがMLOpsの肝だと考えられます。 MLOpsではこうした問題点に対処することにより、リスクを低減し、システムの精度を高めていくことが活動の主な目的になります。

私たちの思うMLOpsとは

MLOpsの前に、もともとDevOpsという概念がビジネスにおいては存在して、Dev（開発）とOps（運用）の両輪を垣根を超えて回すことでビジネスアジリティ*4を改善して高めていくという活動でした。

DevOpsの活動としての改善活動例としては

Jenkinsや、GitLabに代表されるCI（Continuous Integration : 継続的統合）又はCD（Continuous Delivery：継続的デリバリー）ツールを用いて、コードビルドとテストの自動化、リリース自動化などにより開発スピードと運用精度を高める
AnsibleやTerraformなどのツールとパブリッククラウドを利用してIaCなアプローチをとる事で、Immutable Infrastructure*5を目指し、アプリ開発者がインフラを意識せず、Disposableなインフラを利用できる。

といったところでしょうか。

一方でマイクロアドが目指すMLOpsの形とは何かというと、DevOpsと似ていますが、
MLとOpsの両輪を回し、両者の垣根を超えることで、機械学習システムの精度を高めていく活動
だと考えています。
システム精度を高めることというのは、簡単にシステムの検証を行うことができ、精度低下時に即座に対応できるような、以下のような状態ができていなければいけません。

急な精度低下に備え、常に監視を行ってアラートを出したり、すぐに以前のモデルに切り替えられる準備を行う
学習サーバなどをTerraformなどで呼び出せるようにし、学習の度にインスタンスを立てて使い捨てられる環境構築を行う

といったことが考えられます

こうしてMLOpsを実現できた際には、常に観測ができるシステムが出来上がるわけですから、システムの安定稼働はもちろんのこと、システムの精度向上についても実現することができます。

CEという概念

MLOpsにはCIとCDの他に、CEという概念が存在します。それについて説明いたします。

MLOpsにはCI/CDと同じようにCE（Continuous Evaluation：継続的評価）という概念があります。*6 CEを実現することにより、新規モデルを本番デプロイする前に自動評価することになります。これにより急な機械学習システムの品質劣化を検知することを可能にします。つまり、新しく特徴量を追加するなどした際に、急な機械学習システムの精度低下などについても、素早く検知することができます。

継続的評価という文脈は、精度向上にも寄与します。継続的評価をするということは、システムの状態を継続的に観測することに他なりません。システムの精度向上という文脈は、システム状態の継続的観測がなければそもそも成り立ちません。

なので、研究的思想の上でも、こういったシステマティックな部分は必要となるため、こうしたCEの活動が必要となってきます。

レコメンドシステムが抱える根本的な性質

継続的観測というのは意外に難しい問題で、様々な機械学習システムの中でも、オフラインでの評価がそのままビジネス価値になるようなシステムであれば良いのですが、次に説明する、レコメンドシステムや広告システムにおいては、そうもいかない事情があります。

私たちが扱う機械学習の分野といえば、いわゆるレコメンドシステム、推薦の分野ということになりますが、推薦という分野ではオフラインで評価した性能を信じて良いかというと実はそうでない面も多くあります。具体的にいえば、おすすめ商品を提供するシステムを考えたとき、事前のテストでは高評価だった機械学習システムでも、蓋を開けてみればただ人気の高い商品を上から順に表示していたなんてケースもありえます。 *7

つまり、レコメンドの分野では、アルゴリズムの精度を考えるとき、事前の評価指標だけに注目していても、求められる品質を提供できない可能性があるわけです。これは、事前の評価指標、テストで良かったとしても、実際にシステムに適用してみたらビジネスバリューとしてはよくなかったということが実際に発生します。これが、レコメンドシステムが抱える根本的な性質といえるでしょう。

マイクロアドが作るシステムの現状

私たちが提供している広告システムにおいても、似たような性質の問題が存在します。

マイクロアドが提供しているBLADE*8やUNIVERSE*9の広告システムの話で言えば、オフライン評価やLossなどの指標だけでは機械学習システムの精度保証について制御しきれない部分があります。それは何かというと、RTB*10の入札額、実際の広告効果などについてです。 CTR*11 /CVR*12 予測値などはオフラインでも評価できますが、実際の広告効果まで探るとなると、様々な要因が重なるため、これらは到底オフラインで再現できるものではないということです。コアとなる機械学習システムはCTR/CVR予測だけだったとしても、その周辺システムなどの関係もあって単純にオフラインでの検証をそのまま信用していいことにはなりません。

しかし、現状では手動での運用になってしまい、広告効果などの観測については自動化されている訳でもなく、巻き戻しも手作業での修正となります。これではオペレーションミスや、保守作業の増加などの問題が発生します。

また、運用している機械学習システムはCTR/CVR予測以外にもありますので、それの運用となると人が足りなくなったり、作業の属人化が発生し、改善活動に参加することができないなどの問題が発生しています。

こうした現状の問題点を埋めるために、マイクロアドはMLOpsを導入することにしました。

MLOpsで実現すること

具体的な現状の問題とMLOpsに期待する改善を述べると以下のようになります。

精度低下などの問題の切り分けができない→常に監視をし、何が変化したのかを追跡できる学習システムを組む
精度低下時に、すぐにシステムを切り替え、リストアする。→精度の監視やアラーティングなど、またフェイルオーバーできる設計を組む
データサイエンティスト側がインフラに依頼したり、GCPを管理しながら学習を回さなければいけない→アプリ開発やインフラを意識しなくても効果検証ができる環境作る

問題の切り分けという文脈は、バッチのコード内のバグで不整合が起きたのか、偶発的なシステムエラーによるNULL値挿入、研究用データと本番で使用する学習用データとの乖離があったから精度が出ないのかの切り分けについて必要になっていきます。問題の切り分けという部分では、学習の自動化や、日ごとのバッチではGoogleのTFX*13システムなどにより、実現することができると考えます。そこで学習の自動化、CEという話が出てきます。現在そこに挑戦している最中です。

精度の監視やアラーティング、自動フェイルオーバーなどについても重要で、日ごとに学習しているバッチによって生成された重みの精度が悪くなった場合などにすぐに対応できる仕組みづくりが必要になってきます。同じくTFXではModelの精度が悪くなった際には以前の精度の良いモデルをServingするなど、その辺りが色々工夫されています。しかし、CTR予測の正解率やLossなどといったオフライン指標だけでは、入札額、戦略、実際の広告効果のチェックなどに関してはどうしても対応できないので、 TFXよりもより大きいスケールでのフェイルオーバーや精度低下の検知をしなければいけないのが実情です。

データサイエンティスト側がインフラを意識せずとも効果検証をできる環境に関しては、学習の自動化で対応中です。現在、Jenkins Pipeline*14の機能を用いて、GitHubリポジトリに置かれたTerraformのリソースを読むことで、学習用サーバがGCP上に自動で建てられ、その後Ansible(AWX)でDockerを構築し、その学習サーバ内にAirflow*15を用いて学習がキックされるという仕組みが出来上がりつつあります。

f:id:toyohara_suguru:20200305205440p:plain — 準備学習アーキテクチャ図

GitHubリポジトリ内にある、learningブランチにマージ（またはコミット）されるたび、学習が自動で走り、最終的にMLflow*16に結果と学習した重みやPickleデータなどを保存するようにし、結果を見られるようになっています。

f:id:toyohara_suguru:20200319174921p:plain — 学習アーキテクチャ図

こうすることで、自動的に結果を保存し、いつでも確認することができます。また学習し終わったインスタンスは自動で電源が落とされ、インフラコストも抑えることができます。 GCP含め、クラウドリソースは使った分だけ課金されるので、学習に必要なコストについても最小限のコストだけで済みます。

技術的詳細

次に、今回扱った技術についてその一部を説明していきます。

Airflowを用いて学習を同時並行で回す

Airflowでは、CeleryExecutorと呼ばれる方式で遠隔ノードにタスクを投げるといったことができます。CeleryExecutorは本来BrokerNodeを経由してタスクの分散処理などを行う機能ですが、今回のML基盤ではCeleryExecutorと学習を行うWorkerNodeとでQueueを一つに絞ることで、全タスクを同じノードに処理させることが可能となります。このようにして、同時並行で学習を回してもワークフローが混ざらないように設計しています。原理は簡単で、WorkerNode側のQueueの名前をコミットハッシュ入りの名前に変える操作をJenkins Pipelineで行い、共通化させることで実現しています。（とは言え、実現するのは難しいです...）

f:id:toyohara_suguru:20200319174314p:plain — CeleryExecutorのアーキテクチャ図

この技術により、コミットごとに学習を回してWorkerNodeが複数起動しても、独立に処理を回すことができます。

MLflowを用いて学習結果を保存する

MLflowでは、遠隔のサーバに実験結果を載せるといった方法が存在します。 MLflowのサーバは以下のymym氏が作成したDockerfileおよびdocker-composeにしたがって作成することができました。

github.com

こちらのコンテナを用いて、サーバを立てた後、学習コード側で以下のようなコードを挟むことで記録することができます。

import mlflow
mlflow.set_tracking_uri("http://YOUR-SERVER:4040")
mlflow.set_experiment("my-experiment")
# https://www.mlflow.org/docs/latest/quickstart.html#logging-to-a-remote-tracking-server よりコードを引用

こうすることにより、log_paramなどのfunctionを実行するとリモートサーバに記録されていきます。また、パラメータとLossなどのmetricについては、PostgreSQLが状態を保持するので、 AirflowのPostgreSQLと共有で使うという形が理想的ですね。

重みやPickleデータのようなアーティファクトデータはMLflowにGCPのストレージに記録する機能も存在するので、コンテナがデータを持つことはないのでクリーンな状態を保てると考えます。