本発表で想定されている視聴者とアジェンダ
石河純輝氏：それでは、「Lupus - MLOpsを加速させるためのモニタリングシステム」の発表を始めます。本発表で想定されている視聴者は、このような方々になります。まずはじめに、現在MLプロダクトを管理、運用している方々です。
本発表では、MLプロダクトを運用する上で欠かせないものではありますが、少し面倒で、フォーカスされづらいモニタリングに関する話をします。モニタリングの改善を中心に、MLプロダクトをより安定的に運用していく方法を、一緒に考えていけたら幸いです。
次は、MLを用いたサービスを展開していて、今後さらなる成長が見込まれている組織に所属している方々です。
LINEのMachine Learning室は、前身の組織から数えると、発足から長い年月が経っています。そして現在、膨大な数のMLプロダクトを運用しており、モニタリングコストの肥大化に直面しています。本発表では、我々がこれまでに経験した、モニタリング不足に関連した障害や、それらに対処していくソリューションを共有いたします。
最後に「MLOps」に興味のある方々です。MLOpsとは、近年注目されているMLプロダクトを運用する上での方法論です。本発表では、MLOpsとは何かという部分や、Machine Learning室が実施しているMLOpsについても紹介するので、ぜひ最後まで視聴してください。
それではこちらが、本発表のアジェンダになります。
最初に、MLOpsにおけるモニタリングとは、についてお話しします。次に、LINEのMachine Learning室におけるMLOpsの全体像を紹介いたします。その後、我々が直面しているモニタリングに関する課題についてお話しして、その課題に向けて開発しているモニタリング基盤「Lupus」を紹介いたします。
発表の前に、自己紹介します。私は、Machine Learning室のMachine Learning Developmentチームに所属している石河純輝と申します。昨年（2020年）の4月に、新卒として入社しました。業務としては、LINEスタンプなどの推薦や、内製ライブラリの開発、またLupusを含む社内ツールの開発などを行っています。プライベートでは、2羽の文鳥と一緒に暮らしています。
MLOpsとは何か
それではまず、メインの内容について話す前に、MLOpsとは何か、そして、MLOpsにおけるモニタリングとは何かを紹介します。
MLOpsとは、MLとDevOpsを融合させた単語で、MLプロダクト開発におけるDevOpsを指します。昨今、MLを基礎技術としたサービスが多く開発されていますが、MLプロダクト開発では、従来のDevOpsの枠組みでカバーできない要件があることが明らかになってきました。そのため、MLOpsに関して、さまざまなところで議論がなされています。
それでは、DevOpsから見たMLOpsの特殊性とは、どのようなところでしょうか？まずMLOpsでは、通常のDevOpsに加えて、MLモデルの設計、検証部分が存在します。ここでは機械学習モデルを設計し、実験を通して性能評価を行い、必要な要件を満たすロジックを開発します。
ほかにも、データをどう収集するかなどといったモデル開発以外の要件もあります。この部分は、一般的に専門性が高く、サービスを提供する上で、MLエンジニアやデータサイエンティスト、アノテーターなどと協業する必要があるところが、通常のDevOpsとは異なる部分です。
また、DevOpsのサイクルの中にも、いくつか独自の要件が含まれてきます。例えば、サービスとしてデプロイするためにどのようにリソースを確保し、どこでモデルを学習させるのかや、どのようにリリース、デプロイするか。そして運用時には、モデルの精度劣化をトリガーに再学習を促す、といったようなことも行われます。
そして、このライフサイクルを回すために重要なのが、モニタリングです。MLOpsでは、データやモデルといったコードでは管理されない不確実な要素をはらみます。またこれらは、時間経過とともに変化し得る要素です。
そのためMLOpsにおけるモニタリングでは、通常のDevOpsにはない要件が発生します。それでは、MLOpsではどのようなメトリクスを収集する必要があるのでしょうか？これを考えるために、まず通常のDevOpsではどのようなモニタリングが行われるのかを見ていきます。
MLOpsではどのようなメトリクスを収集する必要があるのか
通常のDevOpsでは、CPU、メモリといったリソースの使用率や、ディスクI/O、トラフィック、またシステムのハートビートなどを収集します。また、ビジネスKPIや、DevOpsのKPIもモニタリングすることが好ましいとされています。
DevOpsではこのように、システムの稼働情報を中心に監視を行いますが、MLOpsではこれに加えて、扱うデータや機械学習モデルを監視する必要があります。
まず、扱うデータに対するモニタリングが必要です。例えば入力されるデータの分布が、時間が経っても変化しないという保証はありません。時間経過によって、学習時に想定していた分布から大きく乖離してしまい、サービスの品質が低下してしまうことがあります。
このような現象は、データドリフトと呼ばれます。データの欠損なども、データドリフトの特殊なケースと考えることができるかもしれません。
そのほか、予測対象となる目的変数とその入力データの関係性が、変化してしまうこともあります。このような現象は、コンセプトドリフトと呼ばれます。
そのためMLOpsでは、扱うデータの統計量などを日々監視することが望ましいです。また、機械学習モデルがどのような出力を行っているかも監視する必要があります。例えば一般的に、モデルの予測精度を監視して、一定以上の精度劣化が見られたら、モデルの再学習を促すといったような運用方法が用いられています。
そのほか、タスク特有のメトリクスも存在します。例えば推薦システムの多様性は、長期的なサービス改善に大きく影響すると言われています。また近年では、モデルの予測が差別的でないかを表すfairnessなども、重要な指標とされています。
異なる点は、ほかにも考えられます。例えばDevOpsでは、クラウドを活用したりすることで、ある程度自動化されたメトリクス収集ができます。一方、MLOpsにおけるメトリクスは、サービスを取り巻く環境に強く依存するため、自動的に収集することが困難なことが多いです。
収集頻度にも少し違いがあります。DevOpsにおける計算リソースのモニタリングでは、かなり高頻度でメトリクスを収集します。一方MLOps特有のデータやモデルに関しては、その変化が緩やかなことが多いです。
またこれらのメトリクスは、多くのデータを必要とし、集計コストが高いことが多いです。そのため、数時間や数日といった単位で収集されることが多いです。
また、アラートに対しても違いがあります。MLOpsにおけるメトリクスには、周期性やトレンドが存在することが多く、単純な閾値ベースのアラートなどでは、要件を満たせないことも多いです。
これらを踏まえると、MLOpsのための十分なモニタリング環境を整備することは、思っていたよりもコストがかかることがわかります。さらにこれは、運用するプロダクトが増えていくにつれて、どんどん肥大化していきます。
LINEのMachine Learning室では、非常に多くのMLプロダクトを運用しています。本発表では、各プロダクトに十分なモニタリング環境を整備するための我々のアプローチを紹介します。
LINEのMachine Learning室におけるMLOpsの全体感
ではまず、その規模感や課題感の説明を兼ねて、LINEのMachine Learning室におけるMLOpsの全体感について紹介します。Machine Learning室は、横断組織として各事業部と連携しながら、さまざまなサービスへMLプロダクトを提供しています。例えば、LINEユーザーの属性推定や単行本のレコメンド、また広告の最適化などにも携わっています。
Machine Learning室では現在、20以上の組織と連携して業務を行っています。これらの組織へ提供しているMLプロダクトの数は、合計すると現在100を超えています。また、これらを運用する上で、数多くのデータソースを取り扱っています。例えば外部組織から提供されているHiveテーブルの数は、現在500を超えています。
自分たちの管理下にないデータソースの参照は、障害の起点になりやすいです。そのようなデータソースが大量にある環境を想像してもらえると、Machine Learning室が日々運用しているプロダクトの規模感や複雑さを理解してもらえるかと思います。
もう1つ、規模感を伝えるためのデータを紹介します。LINEアプリは、ユーザーに適したコンテンツを表示する「Smart Channel」という枠を持っています。視聴者のみなさまも、トーク一覧の上部にスタンプやニュースのおすすめが表示されているのを見たことがあるのではないでしょうか。
Smart Channelの裏側には、コンテンツを表示するためのロジックが数多くあり、それらの中から、ユーザーに適したものがバンディットによって選ばれるという仕組みになっています。
Machine Learning室では、この裏側のロジックの提供も数多く行っています。右側のグラフは、Smart Channelで扱っているロジックの数がどのように推移しているのかを表しています。おおよそ2年で、10倍ほどの数になっていることがわかるかと思います。
Smart Channelに関して、Machine Learning室が抱えるプロダクトも、これに比例して増加しています。こちらは1例ですが、Machine Learning室ではこのような速度感でMLプロダクト数が増加しています。
Machine Learning室でのインフラ環境や内製ツールの整備
このような速度感で製品開発を進めるためには、環境やツールの整備が重要です。Machine Learning室では、迅速な開発と安定的な運用のために、これまで多くのインフラ環境や内製ツールを整備してきました。こちらも軽く紹介します。
まず、主要な計算環境としては「Kubernetes」と「Hadoop」を用いています。LINEは「IU（Information Universe）」と呼ばれる巨大なHadoopクラスタを運用しており、各サービスのデータは、日々IUへダンプされていきます。
データの分析や実験などは、社内の「Jupyter」サーバーを用いて行っています。バッチジョブは、各種ワークフローエンジンを活用していて、CI/CDツールでのリリース管理も標準になっています。
次に、内製のものを紹介していきます。まず1つ目は、「Feature vector」です。ユーザーの行動ログや、アイテムのメタ情報といった特徴量は、汎用的に多くのプロダクトで使いまわすことができます。なので、それを集計して、効率的に利用できるようにしています。
また、内製ライブラリの開発も数多く行っています。これらによって、LINEの複雑かつ大規模なデータを安定して扱うことができています。ライブラリだけでなく、施策を円滑に進めるための補助ツールの開発も行っています。例えばA/Bテストの管理システムや、推薦デモを作成するWebアプリなどがあります。
これらのツールは、Machine Learning室内でのプロダクト開発において、このような箇所をカバーしています。MLプロダクトのライフサイクルの各ステップをサポートしていることがわかるかと思います。
しかしこれまで、モニタリングの部分を効率化するツールというものはありませんでした。正確に言うと、「Prometheus」などを使って計算環境のモニタリングは行っていますが、MLに関するモニタリングは、各プロジェクトが独自で構築するような運用でした。そのため、バッチが落ちたアラートをもとに、障害に気づくことも少なくありませんでした。
このような運用のまま、急速にプロダクトが増えていった結果、モニタリングに関する課題感が、徐々に大きくなっていきました。
ここまで、多数のプロダクトを抱えるMachine Learning室が、実際に実施しているMLOpsの概観についてお話ししました。また、モニタリング部分に関しては、プロジェクトごとに独立して運用されており、大きな課題感を持っていることもお話ししました。
もしかしたら、ご視聴のみなさまの中にも、同じような課題感を持っている方がいるかもしれません。ここからは、モニタリングに関するMachine Learning室の課題や、実際に発生した障害について詳しくお話しします。
（後半につづく）
