LINE社内でのサービス横断データ活用の取り組み「Feature as a Service」の全体像

「Feature as a Service」はLINEのデータ活用における要である

Chaerim Yeo 氏：みなさん、こんにちは。LINE Data Labsの機械学習チームでエンジニアをしています、Yeo Chaerimと申します。本日は「Feature as a Service at Data Labs」というタイトルで、LINE Data Labsにおける機械学習向け特徴量の運用、および開発に関してお話ししたいと思います。どうぞよろしくお願いします。

LINEはメッセージングアプリを筆頭にさまざまなサービスを世界各国に展開する巨大なプラットフォームとなっています。各サービスからは日々大量のデータが生成されていて、なかにはユーザの行動ログやサービス自体のコンテンツデータがあります。LINEでは、こういった膨大なデータを有効に活用してサービスの競争力の向上に取り組んできました。

その中でLINEのさまざまなデータ活用を組織横断的に推進するために、2016年にLINE Data Labsという組織が設立されました。現在LINE Data Labsには機械学習チームと4つのデータサイエンスチームがあって、各チームはサービスを提供する事業組織や開発組織とは独立していながら、サービス横断で集約したデータを活用し、基礎分析はもちろんのこと、高度な分析や機械学習を用いたソリューションなどを各部署に提供しています。

Feature as a Serviceでデータの社内標準化・民主化を実現し、サービスの競争力を上げる

Data Labsで提供している機械学習ソリューションに使われている特徴量は、我々が「Feature as a Service」と呼んでいる方法で運用しています。「〇〇 as a Service」という表現から大体の想像がつく方もいらっしゃると思いますが、Feature as a Serviceは一体どのようなものなのか、まずはその全体像についてご説明します。

まず、LINEの各サービスのデータは、大まかにユーザの行動ログとコンテンツデータの2種類に分けることができます。そして、これらのデータを分析や機械学習に使ってもいいか否かを定めたデータポリシーがサービスごとに定義されています。

Data Labsの機械学習チームでは、各サービスのデータポリシーに従って機械学習に使っていいデータだけをサービス横断で集約して、機械学習コンポーネントで利用できる一元化された特徴量を生成しています。

これらの特徴量は各組織から利用できるように、サービスとして提供されています。各々の組織はこれらの特徴量をさまざまな用途で活用しています。例えば機械学習チームでは全社規模で使えるコンポーネントを開発したり、サービス開発組織は担当のサービスに特化した機械学習コンポーネントを開発したりしています。

このように一元化された特徴量を社内のユーザ（＝機械学習を用いるシステム開発者）にサービスとして提供することが、Feature as a Serviceのコンセプトとなります。Feature as a Serviceは特徴量を一元化していることから、データの標準化をしています。そして機械学習チームが蓄積した特徴量エンジニアリングのノウハウを全社に提供することから、データの民主化を実現していて、究極的には開発効率を上げることで、サービスの競争力も上げることを図っています。

現在、Feature as a Serviceとして提供している特徴量は、ユーザ単位の特徴量と、それを難読化した特徴量、そしてコンテンツ別に用意した特徴量、の3種類があります。社内ではそれぞれをZ-Featuresと、Y-Features、そしてC-Featuresと呼んでいます。これらの詳細については、後ほど説明させていただきたいと思います。

Feature as a Serviceの導入に至った背景

全体像を紹介しましたところで、なぜこのようなかたちで運用をしているのかという疑問を抱く方もいらっしゃると思いますので、その背景について簡単に説明したいと思います。そのために、まずはLINEのシステムの概略から説明します。

LINEのシステム全体は大きく4つのコンポーネント群に分けることができます。左から順にクライアントアプリ群と、各サービスのサーバ群、そしてデータをサービス横断で扱うためのHadoopクラスタと、あとは機械学習に特化した処理を行うための機械学習コンポーネントがあります。

クライアントアプリ群は、LINEのメッセンジャーやLINE MUSIC、LINEマンガなどサービスによって複数のアプリに別れていて、各アプリにサーバが立っています。便宜上、図の中ではLINEのメッセンジャー以外のサービスをまとめてFamily Servicesと書いています。

ここからはHadoopクラスタに入ってくるデータの話となります。データがHadoopクラスタに流れ込んでくるフローは、大きく4つのパターンに分けることができます。

まずはクライアントのログです。例えばアプリ上のページビューやクリックといったイベントがあります。

次はLINEのメッセンジャーのログとなります。これは例えば各々のユーザのアプリの設定情報や友達関係、フォローしているLINE公式アカウントの情報などがあります。

続いてメッセンジャー以外のサービスからのログで、例えばどのLINEスタンプを買ったのか、どの広告に接触したのか、あとはどのニュース記事を読んだのかといった情報があります。

これらのログに関しては図に書いてあるとおり、適切なフィルターを経由して分析や機械学習に使っていいものだけがHadoopクラスタに入るようになっています。

最後はサービスのスナップショットです。各サービスのマスタデータとなっています。

ここからは機械学習クラスタの話となります。

多くの機械学習コンポーネントは、機械学習のタスクを効率良く処理させるために機械学習クラスタ上で動いています。ただし、データはHadoopクラスタ上に存在しているので、データのやり取りに関しては、主にSpark経由で行う場合が多いです。

度重なる問題発生から改善に向かって

Data Labsが設立された当時は、Hadoopクラスタから必要なデータを読み込んで用途に応じたETL処理やFeature Engineeringを行って特徴量を都度生成して、それらを用いて学習する感じの機械学習コンポーネントが多数ありました。しかし、こういった運用ではサービスの成長や拡張に伴って、さまざまな問題が発生しました。

実際にどのような問題が起きたかというと、まずデータ量の増加などによってHadoopクラスタへのデータ転送に遅延が起きました。当然、遅延したデータを参照している機械学習コンポーネントにも影響が及んでしまって、その対応にコストがかなり掛かりました。

そして、サービスログの仕様変更によってHadoopクラスタに格納されているデータのスキーマが変更される問題も起きました。多くの場合はコンポーネント側の修正も必要になったので、その補修コストも高くなっていました。

あと、大規模データからETL処理やFeature Engineeringを行うにあたって、計算コストがかなりかかる状況ですが、似たようなETL処理や特徴量エンジニアリングを行う機械学習コンポーネントが多くなっていて、計算リソースが無駄に使われてしまう問題も発生しました。

このような問題を解決するために、サービス横断のデータから一元化した特徴量を生成してコンポーネントに提供するといった、現在のFeature as a Serviceに近い形での運用を始めました。

その結果、散らかっていたデータの依存関係を一ヶ所にまとめておくことで耐障害性が上がった、各コンポーネントから重複したETL処理や特徴量エンジニアリングを切り分けることで開発効率が上がった、特徴量の追加などの修正があった場合にコンポーネント側の修正が不要になったため補修コストが下がった、そして各コンポーネントが必要な特徴量を読み込んで、必要な場合だけ計算コストが比較的低い追加処理を行うことで計算リソースの効率が上がった、などの改善につながりました。