2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY2021 アフターインタビュー」では、発表内容をさらに深堀りし、発表では触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「Lupus - MLOpsを加速させるためのモニタリングシステム」です。
LINEのMachine Learning室ではこれまで、スピーディーに高品質なML(機械学習)プロダクトをリリースするため、データ基盤の整備や学習パイプラインの開発を行ってきました。その結果として、Machine Learning室では現在、20以上の組織に対して100を超えるプロダクトを提供しています。しかし、扱うデータソースや運用するMLプロダクトが増えるにつれて、データドリフトやモデルの劣化を監視するためのコストが肥大化していきました。
こうした課題を解決するため、MLプロダクトに必要なメトリクス収集やアラートシステム、ダッシュボードなどの機能を実現するモニタリングシステム「Lupus」を開発しました。 このインタビューではセッションで語られた内容の裏話を、Machine Learning室 Machine Learning Developmentチームの石河 純輝が解説します。
可用性・信頼性の高いモニタリング基盤を構築するために
――Machine Learning室の役割や石河さんの業務内容を教えてください。
Machine Learning室は、機械学習の技術を用いてLINEのさまざまなサービスに貢献している組織です。担当する業務の代表例としては、ユーザーに商品やサービスをおすすめするレコメンドや、広告などのターゲティングに利用するユーザーの属性推定などがあります。
Machine Learning室のなかにも複数のチームがあり、私はMachine Learning Developmentチームに所属しています。このチームはMachine Learning室全体で用いられる技術的な共通基盤を構築したり、機械学習領域の新しい技術を活用してMachine Learning室の業務改善に結びつけたりといったことを担当しています。
私の業務内容を説明すると、機械学習関連ではLINEスタンプのレコメンドや表現学習分野の研究・開発、エンジニアリング関連ではモニタリングシステム「Lupus」の設計・開発に携わっています。
――「LINE DEVELOPER DAY 2021」のセッションでは、「Lupus」がサーバー・ライブラリ・SPAといった要素から構成されていることが語られていました。これらのアーキテクチャ設計において工夫されたことはあるでしょうか？
サーバーサイドの工夫としては、システムの可用性や信頼性を高めることを大切にしました。エンジニアからビジネスサイドのメンバーまで、モニタリング基盤はLINE社内の多くの人たちに利用されます。もしも「Lupus」がなにかしらの原因でダウンすると、各種の業務に支障が出ます。「Lupus」へのデータ投入が失敗したことにより、関連する他のシステムにも障害が起きてしまうかもしれません。
そこで、「Lupus」へのデータ投入の頻度や量が多くても確実にリクエストを受けつけることや、トラブルが発生してもデータを消失しないことを必須要件としてアーキテクチャを設計しました。
機械学習に関連したメトリクスを扱うからこその工夫
――具体的にはどのような流れでデータを処理するのでしょうか？
「Lupus」サーバーは、メトリクスの元データを受け取るとAmazon S3互換のオブジェクトストレージへと一時的にデータを配置します。その後、メトリクスの記録を行うジョブをジョブキューへと登録します。ワーカープロセスはジョブキューからジョブを取得して、Argo Workflowsで処理を実行します。
ワークフローではストレージからデータを取得してバリデーションを行います。正常な形式のデータであることを確認できたら、Apache Hive（以下、Hive）とElasticsearchへメトリクス情報を書き出します。この処理フローにおいて、大量のメトリクスデータが投入された場合でも、システムがダウンしないような工夫をしています。
ML室での機械学習モデルの学習・予測は、バッチ処理で実行されるケースが多いです。1日に数回の頻度で学習・予測のためのバッチが動き、それらから集計したメトリクスが「Lupus」に対して大量に投入されます。このとき、一定の件数ごとにデータを区切ってジョブキューへと流すようにして、なるべく高負荷にならないような設計にしています。
それから、「Lupus」はユーザー向けにライブラリを提供しているのですが、ライブラリ内部でもデータ投入を平準化するための仕組みを入れています。
――「Lupus」の開発において、他にも機械学習に関連するメトリクスを扱うからこそ生じる固有の課題や留意点はありましたか？
わかりやすい例としては、メトリクスに対する異常検知です。MLOpsにおいて「何をもって異常な数値であると判断するか」は、非常に難しいテーマです。
よくあるアラートシステムでは、一定の閾値を超えたらアラートを上げるとか、直近の値と比べて大きく変化があればアラートを上げるのが一般的です。しかし機械学習では、メトリクスが周期性やトレンドを持つことも少なくありません。そのため、数値変化のコンテクストを読み解く必要があります。周期的な変化からの大きな逸脱や、トレンドの変化を検出できることが望ましいです。
この問題に対してアプローチするため、「Lupus」には機械学習を活用した各種の異常検知の仕組みを実装しています。基本的な異常検知は、閾値ベースのものやウィンドウベースのものです。これに加えて、高度な異常検知としてProphetによる時系列予測を活用した仕組みやTwitter社がOSSとして公開しているライブラリを用いた仕組みを実装しています。これらの機能はすべて自分たちで開発しており、今後も継続的にロジックを追加していく予定です。その他にも、アーキテクチャにおいては複数の工夫をしています。詳細についてはセッション内で解説していますので、よろしければ動画をご覧ください。
モニタリング基盤の構築に携われるのは貴重な経験
――「Lupus」の今後のアーキテクチャ改善の予定を教えてください。
データ収集のアーキテクチャを大きく変えようとしています。先ほどサーバーサイドの構造として、メトリクスの元データをオブジェクトストレージへと一時的に配置し、ジョブをジョブキューへと登録し、ワーカープロセスが処理を実行すること。そして、最終的にHiveとElasticsearchへメトリクス情報を書き出すことを解説しました。
後者の処理ではHiveへのデータ投入のために、Sparkを実行するためのPython APIであるPySparkを使っています。メトリクス情報の投入が発生するたびにSparkのセッション取得をくり返し、Hiveにデータをリアルタイムで流すことになります。しかし、この処理の流れはSparkやHiveの設計思想から逸脱しており、あまり好ましくない設計だと考えています。そこで今後は、定期的にHiveへデータを同期する設計へと変えようとしています。
また、依存するコンポーネントをなるべく少なくする意図から、オブジェクトストレージとジョブキューをなくしてKafkaに置き換えるプロジェクトを進めています。Kafkaはその仕様上、大量データの投入に強く、仮に障害が起きても一定期間はデータを残してくれるため、私たちのユースケースにマッチしていると考えています。また、LINE社内には信頼性の高いマネージドのKafkaサービスがあるため、運用を省力化できるのも良い点です。
それから、異常検知の仕組みも今後さらに改善していきます。現在、異常検知の実行はユーザーのリクエストが起点になっています。ユーザーは異常検知の機能を利用する場合、メトリクスの範囲と異常検知機のパラメーターを指定します。この処理を実現するために、「Lupus」のライブラリにはインターフェースやクライアントが実装されています。
しかし、「異常検知のトリガーとなる情報はユーザー側ではなく、なるべくシステム運用者側で管理するほうが、ツールとしての利便性が向上するのではないか」という声を、複数の方からいただいています。そこで、なるべくユーザー側の負担を減らせるような形に、システムの仕様を変えようとしています。
――最後に、「Lupus」の開発・運用に携わることがエンジニアのキャリアにどのような好影響があるか、石河さんの考えを教えてください。
エンジニアのキャリアにおいて、モニタリング基盤を構築する機会はなかなかありません。その意味で、「Lupus」の開発に携われること自体が、エンジニアとして貴重な経験であると感じています。また、モニタリング基盤は高いサービスレベルが求められるため、システムの信頼性や可用性を考えつつ設計や実装に取り組むことで、エンジニアとしてより成長できると考えています。
また、MLOpsと呼ばれる技術領域は近年とても注目を集めています。自分が携わっているモニタリング基盤だけではなく、機械学習を用いたシステム全体のことを考えながら、改善のために尽力することは、非常に意義のある仕事ですし、キャリアアップにもつながると思います。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！
今回のインタビューと関連する募集ポジションはこちらです。