Machine Learning Infrastructureチーム
大東哲平氏（以下、大東）：大東です。よろしくお願いします。Data Scienceセンターという部門の中のMachine Learning Infrastructureチームに所属しています。
こちらがLINEの各サービスになりますが、この中で比較的データ量が多いところを担当していることが多いです。
これがLINEのアプリの5つのタブですが、だいたいこのようなところに機械学習が使われています。こちらはすべてがMachine Learning室の担当ではなく、社内の各組織で分担しています。
こちらがデータの流れです。私たちのチームが担当する部分は、この青い部分になります。他のチームが運用しているHadoop上でデータを処理することが多いです。
ログはクライアントやサーバーから流れてきますが、ログ以外のコンテンツも処理して、最終的に推薦したり、なんらかの出力をしています。
例えばLINEスタンプだと、使ったことがある人も多いかと思いますが、こちらの四角で囲った部分が、Machine Learning室で出力したものになります。
また、スタンプを送る時に、どのようなスタンプを使うかが提案されると思いますが、この部分にも関わっています。それ以外にも、A/Bテストを行うためのツールなどを作ったりしています。
Machine Learning Infrastructureチームは、実際先ほどの組織図の中の機械学習チームになりますが、その中で機械学習を行わないで、こういったツールを作ったり、あと実際に環境を整備することが仕事になっていて、機械学習自体は行っていません。
Machine Learning Infrastructureチームに求める人物像
大東：こちらが求める人物像です。大きなJobをGPUやCPUノードを複数台使って、お互い通信しながら長い時間計算するので、これらを安定して動かすクラスタを構築することが仕事になります。
ミドルウェアやKernelを試して、どうしてこれを選んだのかを明確に説明できて、そしてそれを必要に応じて直す能力。あとはそれらを便利にするツールを作ったり、継続的に改善していくことが非常に重要になります。最終的には、機械学習エンジニアに便利な環境を提供し続けて、そしてセキュリティを担保することが目標になります。
別のケースですが、こちらはMesosというミドルウェアからKubernetesに移行してきたばかりなので、まだ未実装のものが多くて、たくさん準備していかなきゃいけないところです。
機械学習エンジニアは、自由にモデリングがしたい。サーバーサイドエンジニアとだいぶ見ている部分が違うのですが、私たちとしても、最大限自由にさせてあげたいので、そのための環境を作っていく必要があります。
先ほどのA/Bテストの画面で、推薦結果を可視化するツールがありますが、こちらは計算結果に対してすぐデモを表示するような機能を持っています。こういったツールを作ったりして、結果をより早く、またサービスに対してすぐ提供できるように、見せられるようにするような機能も準備しています。あるいは再現性や安全性といったものを担保して、適切に表示していくなどといったことが求められます。
あとは、GPUノード1つで動くような小さなJobではないので、ドライバから複数のノードにソースを送りつけて実行するライブラリなども提供しています。
またそういったものを作って、Jupyter上でGPUノード上でそのまま試すのではなく、そういったツールを使うことによってどこででもGPUを使えるようになるので、非常に利便性を感じてもらっており、移植しやすいものも出てくるんじゃないかなと思います。
今はDevOpsエンジニアとサーバーサイドエンジニアを募集していますが、こちらはサーバーサイドエンジニアで、APIを作るのが仕事になります。
レスポンスはミリ秒で。例えば秒間5,000リクエストぐらい捌けるものを10台ぐらい並べて捌くものから、1リクエストに対して24時間計算し続けて、その結果を返すものもあります。
24時間ですと、たいていはキューに入れて、最終的に結果をコールバックしたり、あるいは別のキューに入れて相手に更新してもらったりすることになると思うんですけれども。そういったものを適切に実装する能力が必要になります。
また、APIをHTTPで提供するのではなく、UDFなどでSQLから叩けるようなものにして提供することで、多くの方が使えるのも、非常にいいと思います。
こちらに必要な能力は、スループットやレスポンス速度をよく見てボトルネックを特定したり、キューを使って適切にバランシングしたりする能力と、他にはあんまりto Cではないですが、この時間帯には落ちますということを利用者と話し合って決めて、適切なダウンタイムを設定したり。
また、ここにコールバックとありますが、もし仮にAPIが落ちた場合にどういった出力を返すか。例えば前日分で返したり、全体に対してある程度許されそうな結果を返すなど、そういったものを策定するのも必要になります。
それ以外にも、機械学習エンジニア自身に使ってもらうAPIでしたら、モデルとパラメーターを直接渡したり、サービスエンジニアであればログのスキーマを渡してもらえればそれに合わせて出力したり、サービス企画者であれば先ほどのUDFなどの利用を想定して、どういったものが便利かを自分で考えて提案して構築していくことが仕事になります。
これが一番重要なことですが、他のすべてにも関係するもので、監視項目とかアラートもすべてGitで管理されています。こちらのアラートはモデルの精度もあるので、監視項目とアラート方法を準備して、機械学習エンジニアに書いてもらうというケースも多いです。それ以外にも、もちろんクラスタやAPI自体の監視も必要になってきます。
こちらが使われている技術関連です。以上です。
司会者：はい、ありがとうございます。樋村さん、続いてお願いします。
「DSP MLチーム」がやっていること
樋村隆弘氏（以下、樋村）：DSP MLチームのマネージャーを務めています樋村と申します。私からは、DSP MLチームについて簡単に紹介したいと思います。よろしくお願いいたします。
DSP MLチームですが、先ほどの大東さんと同じく、Machine Learning室の下に所属するチームになります。このチームは2020年に発足した比較的新しいチームで、現在メンバーは私を含めて4名が所属しています。
Machine Learning室は、他のチームだと社内の各種サービスに対して機械学習を提供することが多いのですが、DSP MLチームはちょっと異色で、LINE広告という特定のサービスの改善に取り組むチームとなっています。
なのでDSP MLチームのミッションは非常にシンプルでして、機械学習を通じてLINE広告の競争力・利益に貢献するのが、私たちのミッションとなります。
最初に私たちが主に担当しているLINE広告について、簡単に紹介します。LINE広告は、その名の通りLINEに広告を配信するためのプラットフォームです。
LINEアプリの月間アクティブユーザーは、国内で8,800万人を突破しておりまして、国内最大規模の運用型広告プラットフォームになっています。
ここにきているみなさんは、LINEをインストールしたことがある人も多いと思うので、恐らく実際にLINE広告を見たことがあると思います。代表的なものとしては、LINEのトークのトップのヘッダーの部分やニュース面、あとはタイムライン面などがありますが、これらはどちらも非常にトラフィックが多いものになっています。
また、最近はLINEの中だけではなくて、LINEの外の、他社アプリについても広告を配信する「LINE広告ネットワーク」というアドネットワークがありまして、こちらに対しても、私たちが広告を配信できるようになっています。
私たちDSP MLチームでは、広告の機械学習におけるロジックの開発に加えて、サーバーサイドまで見ている、横断型の組織になっています。
「DSP MLチーム」のサーバーサイドのお仕事
樋村：今日はサーバーサイドエンジニアの説明会ということで、サーバーサイドを中心に紹介します。
さっそく広告のサーバーサイドに求められることをちょっと話したいと思います。広告は落ちないのは当然なんですが、広告業界では「50ms or die」という言葉がよく聞かれます。
ご存じの方も非常に多いと思いますが、「50ms or die」っていうのは、現在の広告配信は、リアルタイムビッディングという仕組みで成り立っています。
リアルタイムビッディングは、その名のとおり、広告を表示するタイミングで、リアルタイムで都度広告のリクエストをアプリから送るものです。
したがって、このレスポンスが悪いと、広告の表示のタイミングを逃してしまい、売り上げの毀損につながるといった影響があります。サーバーのレスポンス、パフォーマンス、レイテンシーについては、非常にシビアな運用が求められています。
ということを表して「50ms or die」とよくいわれますが、実際にはこのように、SSPといった広告枠側のプラットフォームや、広告主側のデマンドサイドプラットフォームといった多段構成になってつながっていることが多くて、50msとはいっても、プラットフォームによってはさらに短く20msを要求されることもあるかと思います。LINEの場合は、LINE社内で閉じていますので、50msを目標にがんばっている感じです。
この中で私たちDSP MLチームがどこを担当するかというと、名前のとおりDSP側の機械学習ロジックなどを担当しています。
LINEのDSP開発なんですが、実はもともと韓国側のチームが担当していまして、機械学習のロジックについても、韓国側のチームで行なっていました。2020年に私たちのチームが発足したことで、韓国側のMLチームと私たちが協力して、広告効果の改善に取り組んでいる状態になりました。
DSPには、クリックやコンバージョンを最大化するための予測モデルを始めとして、Auto Biddingといったような、予算ベースコントロールのためのモデルなど、さまざまなモデルが動いています。DSP MLチームでは、これらのモデルの改善や、特徴量の提供を主に行なっています。
先ほどもお話ししたとおり、50ms or dieといったように、DSPは非常にレイテンシーの制約が厳しいので、LINEのDSPのモデル自体は主にFactorization Machine（FM）をベースとした、シンプルなモデルが用いられています。
CVRについても、FM拡張して遅延などを入れたモデルが使われていますが、このあたりは2020年に韓国側のチームが発表していますので、もし興味がありましたら、そちらもご覧いただくといいかなと思います。
このモデルの開発や、モデルに入れる特徴量の提供などを行なっていますが、LINE DSPでは、特徴量についてはユーザーやAD、広告枠といったもの、いろいろな特徴量を用いて最適化しています。実際にどういったものを使っているかについては、ちょっとあまり詳しくは話せませんが、今日はその概略だけお話できればと思います。
実際DSP MLチームがどんなことをやっているかということですが、例えばユーザーやADといった単位だけではなく、ユーザーとADの組み合わせみたいな、そういったものに対して、フィーチャーを提供したり、そのパイプラインの設計などをしたりしていました。
ということで、実際どんな感じのもの作ったかを簡単に紹介できればと思います。
これは概略図ですが、このコンポーネントはap−workerと呼ばれていまして、実際にUser x Ad Similarityといった、特徴量の提供のために利用されているものになります。
このUser x Ad Similarityは、その名のとおりユーザーとADのペアでCTR予測するようなモデルなのですが、そのままユーザー×ADみたいなものを入れちゃうと、非常に膨大な量になってしまうので、ユーザーとAD、それぞれのembedding vectorを作って、その近さを特徴量として入れるようなモデルになっています。
このembedding vectorをリアルタイムで更新できると、ユーザーのアクションなどに基づいて即座に更新し最適化できるので良い、ということでこういったパイプラインを作っています。
ざっくりパイプラインについてお話しすると、アプリからきた広告表示やクリックとかのイベントが、Kafkaに流れてきますので、Kafkaからイベントをconsumeして、クリックをRedisに書いておいて、インプレッションをさらに遅延させてKafkaに流してジョインして、そのジョインしたイベントを用いて学習するフローになっています。
この構造自体は非常に一般的なもので、User x Ad Similarity以外でも使えますので、こちらは拡張可能コンポーネントとして作成しています。
User x Ad Similarityでは使っていませんが、他の特徴量の生成では、広告素材のテキストや画像の情報も必要になるのですが、そういったバッチ類についてはユーザーのクリックなどと比べると頻繁に更新しなくてもいいものなので、そういったバッチについてはKubernetes上のArgoを使って実装しています。
という感じで、その作った特徴量についてはバッチでHDFSなどに書き込んでWorkerから読み込んで使うような工夫になっています。
「DSP MLチーム」に求められる技術スタック
樋村：DSP MLチームとして求められる技術スタックについて、最後にお話ししたいと思います。DSP MLチームでは広告配信の最適化に必要な機械学習から特徴量生成のためのサーバーサイドまで一貫してやっているような感じです。特徴量を追加するにあたって、オフラインテストなどをガンガン回す感じなので、Pythonや機械学習系フレームワークの知識があると、うれしいです。
サーバーサイドとしては、Pythonに加えてap−workerを最初Javaで書いていたのですが、その後Kotlinに移植したりしたので、Java系の言語の知識や、JVM系の監視や運用の経験があると非常にうれしいと思います。
また、LINEのDSPはGoで書かれていますので、Goについてもある程度読めたり書いたりできるとうれしいという感じです。
またKubernetesについては、LINEのプライベートクラウドのVKS（Verda Kubernetes Service）というサービスを利用して構築しています。ですので、Kubernetes自体の構築は必要ないんですが、その上の設定やArgo Workflowの管理など、そういった部分については、私たちで行う必要がありますので、Kubernetesの知識が豊富にあると非常によいと思います。
また、その先ほどのap−workerといったそういったストリーム処理についても、Kafkaを利用しており、このKafka自体も運用は別途専門のチームがいまして、そちらで運用しています。
ただ、そういったストリーム処理の監視やトラフィック量の見積もりといった部分については、ある程度経験と知識があると、非常にうれしいかなというふうに思います。
DSP MLチームではそんな感じで、サーバーサイドとML両方やるチームになっていますので「両方やってみたい」「機械学習やったことないけどちょっと興味あるんだよね」っていう方でも、ぜひ応募いただければと思います。共に広告業界をよくしていけるとうれしいです。以上でDSP MLチームの紹介といたします。ご清聴ありがとうございました。
質疑応答
司会者：大東さん、樋村さん、ありがとうございました。それでは、質問に答えていきたいと思います。3つほど質問をもらっていまして、順番に回答したいと思います。
まず1つ目ですが、MLチームの中でサーバーサイドエンジニアが何人いて、どういう経歴の方がいるのですか。
大東：発表順で私から答えますと、サーバーサイドエンジニアは、現在4名か5名です。
それでどういった経歴かというと、広告出身の方もいらっしゃいますし、それから機械学習を学生時代行なっていたというような方もいますし、機械学習自体にまったく縁がなくて、コンピューターサイエンスの出身の方もいます。
司会者：はい、ありがとうございます。樋村さんのほうはいかがですか。
樋村：そうですね。DSP MLチームでは、みんな機械学習もやればサーバーサイドもやりますという感じなんですが、特に強いメンバーとなると2人ですかね。
広告出身というよりかは、他から来た人がけっこう多いですが、私はもともと動画の広告ネットワークを前職としています。
司会者：ありがとうございます。次の質問ですが、学習に用いる時間はどの程度かかりますか。
大東：本当にモノによりますが、長いものですと24時間程度やっているものもありますし、短ければ分単位のものとかもあります。
樋村：DSP MLチームについても同じで、モノによりますね。先ほどのap−workerについては、本当にストリーム処理なので、分単位で処理できないとまずいですし。バッチについては本当に1時間とか、1日とか、そういったものもあります。
司会者：ありがとうございます。次にエンジニアのキャリアについて質問がきていますね。キャリアをスタートする上で、サーバーサイドエンジニアでスタートするのがおすすめだったりしますか。これは、Machine Learningに限ったお話じゃないとは思うんですが、いかがでしょう。
大東：比較されているものがなにかによりますね。例えばiOSのエンジニアに比べると、リリース周期が短いからもう少し自分で制御しやすくてよいとか、そういった部分があるかもしれませんが、ちょっと好みになってしまうので、これぐらいで勘弁してください。
樋村：そうですね。広告についてもサーバーサイドエンジニアというと、けっこうリリースしたものがすぐ売上に直結しますので、そういった意味では非常に楽しいと僕は思っています。
ただ、もちろん何か失敗、というかサービスを落としてしまった時は、その影響がけっこう大きいので、そこはちょっとものによるかなという感じですね。
司会者：ありがとうございました。
