コンテンツを投げ込めば最適にレコメンド　LINEのCRS開発チームが目指すもの

CRSとはなにか

萩原豪氏：みなさん、お疲れ様です。ではここからは、CRS開発チームの紹介をします。まず軽く自己紹介からしますと、私は萩原豪と言います。これまで関わってきた案件としては、LINE占い、LINEバイト、それからLINE LIVEといった、いわゆるLINEのファミリーサービスというものを担当してきました。

2019年からはCRS開発チームに参加して、今は開発のリードを担当しています。社内では、けっこうIDやニックネームを自分で使う方と、本名を通す方と分かれているんですが、私の場合はアメリカのオクラホマ州に住んでいたということもあって、Oklahomerとかホマーとか呼んでもらうことが多いですね。GitHubのIDもこれを使っています。

趣味は旅行で、右側の写真は去年タイに行ったときの写真です。半袖で夏っぽい格好ですが、実はこれ11月の終わりだったりします。このあたりのタイの気候は、このあとちょっと出てきますので覚えておいてください。

それではさっそくCRS開発チームについて紹介していきます。みなさんおそらく、CRSと言われてもピンとこない方が多いのではないかなと思います。そこで、こちらの画像を見てほしいのですが、この赤で囲われた部分、これらの領域に対してパーソナライズされたコンテンツを提供している、Smart Channelというプロダクトを開発しています。

1人ひとりのユーザーに対して、そのユーザーにとってその瞬間最も有益なコンテンツを届けるのがSmart Channelのミッションです。それを可能にするバックエンドのシステムがCRSで、Contents Recommender Systemの略となっています。

特徴その1:複数メディアのサポート

ここからはSmart Channelの開発について、いくつか特徴を紹介していこうと思います。まずはじめに、複数メディアのサポートであったり、グローバル対応といったプロダクト寄りの面から紹介していって、そのあとサービスの規模であったり、マシンラーニングとの関わり方、そして技術スタックについて紹介していきます。

まず1つ目の特徴は複数メディアのサポートですね。見るとわかるとおり、ホームタブ、トークタブ、そしてウォレットタブという、異なるメディアに対してレコメンドを提供しています。

それぞれのメディアで個別にレコメンデーションを開発するのと違って、Smart Channelが複数のメディアをサポートするプラットフォームになっています。それぞれのメディア上で起こっているインプレッションやクリックというイベントの集計であったり、また学習のデータを1ヶ所で管理できます。

またコンテンツを一元管理しておいて、それを最適なメディアに対して出し分けることもできるようになりますので、コンテンツデータを提供する各サービスの開発側にとっても大きな利点となっています。

その反面、メディアはそれぞれ特徴が異なりますので、それらに対して適切なコンテンツを提供するのがすごくチャレンジングな部分でもあります。例えばホームタブは、いろいろなサービスへの導線をもっている一種のポータルとして機能しますので、まだ使ったことのないサービスへの導線をおいて、それによって遷移を促し、そしてユーザーになってもらうことも重要な指標となります。

それに対してトークタブは、ユーザーが誰かと会話をしようとして開く画面になります。その画面の中の一番目立つ部分にコンテンツを表示するのは、明確な目的をもってそこに遷移してきているユーザーにとって、非常に邪魔なものになりかねないんですね。それでも、ユーザーにとって利益になるなにかを出す必要がありますので、既存のユーザーに対するターゲティングがこの画面では重要になります。

そして、ここまでのホームタブやトークタブは、さまざまなサービスのコンテンツを用意することが多いのに対して、ウォレットでは、クーポンやファイナンス系の情報、もしくはお金に関するお得な情報を表示することが多くなります。

こうしたさまざまな異なる特色をもつメディアをサポートするプラットフォームを設計するのは、すごくチャレンジングですし、同時にすごくやりがいのある部分です。

特徴その2:グローバル対応

そして2つ目の特徴がグローバル対応ですね。こちらの図にある緑の部分で、日本と台湾とタイをサポートしています。グローバル対応と言うと、すでにあるコンテンツをそのまま他言語対応すると考えられる方も多いと思いますが、実はそこまで単純でもありません。

見てもらうとわかるとおり、タイは日本よりもだいぶ南にあるんですね。自己紹介のスライドでも見てもらったとおり、11月の終わりでも非常に暑いです。基本的には1年中すごく暑くて、雨季と乾季が分かれているとはいっても、雨季でも1日の何時くらいに雨が降るかなというのは、だいたいわかってしまうんですね。

ですので、天気予報に対する需要があまりなかったりします。このあたりが日本や台湾との大きな違いになっているんですね。その反面、空気の汚染度を示すAQIの関心は非常に高いので、タイでは天気予報よりもAQIのコンテンツを配信することに重きを置いています。

このように、地域によって求められるコンテンツが大きく異なるので、Smart Channelの開発においては、それぞれの国にローカルPMというものを配置して、彼ら彼女らと密に連絡を取り合って、コンテンツのプランニングを行っています。このプランニングを通じて、国ごとの特色がだんだん見えてきたりするので、そういう部分は新しい発見が多くて、とても楽しい部分ですね。

特徴その3:サービス規模

そんなSmart Channelですが、サービスの規模はご覧のとおりです。ここにある数字は、トークタブに限ったグローバルでの数値ですね。まずデイリーで10億リクエスト、そしてユーザーでいうと1億2000万人のDAUトラフィックをさばいています。

それらのリクエストに対して、さまざまな連携サービスのコンテンツに適応されている、いろいろなレコメンデーションを合わせると、全部で50種類以上のレコメンデーションのパターンを提供しています。

これだけのトラフィックに対して、リアルタイムにレコメンドを返しますので、非同期にできる部分は非同期にしつつ、オンラインでの対応が必要な部分は高速に安定して提供するのが常に課題となっています。

特徴その4:マシンラーニングチームとの関わり

そしてここからは、アーキテクチャについて全体を見ていこうと思います。1つひとつのコンポーネントを見ようとするとすごく小さくなってしまいますので、色分けされている全体像をご覧ください。

Smart Channelはレコメンデーションを扱っているために、必然的にMachine Learningチームとの協業が重要になってきます。左の注釈にあるように、緑色の部分が私たちCRS開発チームの担当しているコンポーネントです。

そして青い部分がMachine Learningチームがもっているコンポーネントですね。見るとわかるとおり、まず左上にあるLINEアプリから直接リクエストを送っている部分はすべて緑色になっています。これは大量のトラフィックを高速に安定してさばく必要があるので、そういったサービス開発の知見をもっている開発チームのほうで、開発と運用を行っています。

そのうえで、例えば左下のコンポーネント、緑色の部分で送ったデータなんかは一度Kafkaへ流し込まれて、次のコンポーネントで使いやすい形式に加工したり、もしくはサマライズをしたうえで最終的に一番右のほうの青い部分であるマシンラーニングチームのコンポーネントへ出力されています。

そして、これらのマシンラーニングチームのコンポーネントで学習した結果は、ユーザーのリクエストに応じてリアルタイムでレコメンドを生成するとき参照しやすいよう、整形してRedisに保存されたりしています。

これらのコンポーネント郡では、要所要所でKafkaを挟んだりしていますので、それぞれのコンポーネント自体はすべて疎結合に保たれていて、チームをまたいだ開発や運用が行いやすくなっています。

特徴その5:RedisとMySQLの利用の比率が一般と違う

そしてこちらが技術スタックですね。弊社のサービス開発ではメジャーな構成なんですが、言語はJavaを使っていて、ストレージはRedisとMySQLを使っています。メッセージキューにはKafkaや、Kafkaベースで弊社からOSSとして公開しているDecatonを採用しています。

ちょっと一般的なサービス開発と違うかなと思うところを挙げると、RedisとMySQLの利用の比率ですね。だいたいのサービスだと、コンテンツやユーザーのデータはMySQLといった恒久的なストレージにもっていて、一部のデータをRedisなんかのストレージにキャッシュする方法が多いと思います。

しかしSmart Channelでは、それぞれのサービスから流れ込んでくる最新のコンテンツ情報をキャッシュしているだけでいいんですね。ですので、MySQLよりもRedisの利用が非常に多くなっています。

Redisクラスタに対しては、read/writeともに非常に多いので、例えばRedis Clusterを拡張するときのリシャーディングの細かな挙動だったり、あとはクライアントライブラリの挙動について知見が深まっていくのが、個人的にはすごくおもしろいですね。

現在の課題

それではざっくりとSmart Channel開発について紹介したところで、今後の方向性についてもちょっと触れてみたいと思います。まずこちらの図を見てほしいのですが、これが今現在の、それぞれのサービスからコンテンツを受け取って、それをユーザーへ提供するまでのフローになります。

まず左側にあるのが、Smart Channelに対してコンテンツを提供してくれているサービスで、そのコンテンツの情報を取り込むImporterが真ん中にあります。このImporterから取り込まれた情報をもとにして、ユーザーのリクエスト時にリアルタイムでレコメンドを生成して返すことをしているんですね。

ここで注目してほしいのが、赤い文字で書いてあるとおり、実は左と右のほうで2段階のレコメンデーションが行われているところです。まず第1段階の部分ですが、左側のサービスからはコンテンツのデータだけではなくて、ターゲティングデータと呼んでいるものも提供されています。

ターゲティングデータは、そのサービスでのユーザーのアクティビティログなどをもとにして、どのユーザーに対してどのコンテンツを表示するべきかという、ユーザーIDとコンテンツIDのマッピングを含んでいるんですね。

そしてユーザーから実際にアクセスが来たときには、そのようにして提供されてきたターゲティングデータをもとにして、レコメンドの候補一覧を作って、それら同士を競わせて、そして一番いいものを返すことを、第2段階目のレコメンドとしてSmart Channel内部で行っています。

この方法で課題になってくるのが、第1段階目のレコメンドの部分なんですね。それぞれのサービスのユーザーとコンテンツについて、誰が最も知識をもっているのかというと、結局それはサービス自身ということになります。このターゲティングデータをサービス側で提供するのは、たしかに合理的ではあります。

ですがこの場合、どのユーザーに対して何を届けたいかというロジックをサービス側で組んで、そしてデータ抽出を行うところまでできるようになる必要があるので、Smart Channelとの連携を進める前段階のプランニングの部分で、けっこう時間がかかってしまうんですね。

そんな課題がある中で、Smart Channel自身もローンチから1年以上運用する中で、さまざまな機能追加であったりレコメンデーションロジックの改善を続けてきて、レコメンデーションエンジンとしての性能も、ずっと上がってきています。