2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
提供: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つのデータサイエンスチームがあって、各チームはサービスを提供する事業組織や開発組織とは独立していながら、サービス横断で集約したデータを活用し、基礎分析はもちろんのこと、高度な分析や機械学習を用いたソリューションなどを各部署に提供しています。
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と呼んでいます。これらの詳細については、後ほど説明させていただきたいと思います。
全体像を紹介しましたところで、なぜこのようなかたちで運用をしているのかという疑問を抱く方もいらっしゃると思いますので、その背景について簡単に説明したいと思います。そのために、まずは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処理や特徴量エンジニアリングを切り分けることで開発効率が上がった、特徴量の追加などの修正があった場合にコンポーネント側の修正が不要になったため補修コストが下がった、そして各コンポーネントが必要な特徴量を読み込んで、必要な場合だけ計算コストが比較的低い追加処理を行うことで計算リソースの効率が上がった、などの改善につながりました。
LINE株式会社
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには