こんにちは、エンジニアのタテノです。
ミラティブアプリを起動するとおすすめ配信の一覧が表示されます。 今回はこのおすすめ配信の仕組みについて解説しつつ、おすすめ配信の運用・改善を行う上でのポイントなどをまとめてみました。 システム面では機械学習などのトピックも含みますが、今回はサーバサイドの設計周り、特にパフォーマンスを考慮している部分にフォーカスしています。
おすすめ配信の役割
ユーザはすでにお気に入りの配信があれば、フォロータブから配信に入室しますが、ミラティブをはじめて初期の段階やお気に入りの配信がない場合は、そのほとんどはおすすめ配信から配信に入室します。おすすめ配信はユーザが配信に興味を持つきっかけとしてその役割を果たしており、とても重要です。
ミラティブでは常時、多数の配信が行われており一度に全ての配信を表示することはできません。たくさんある配信の中からそのユーザにおすすめの配信を表示しています。
おすすめ配信のポイントは大きく2点あります。1つ目はどのユーザにどの配信を表示するのか、すなわちレコメンデーションの精度、2つ目はその配信の魅力をいかに伝えるか、すなわち配信の表現力です。クラロワAPIを使ったイベントの記事では、おすすめ配信にプレイヤー情報を表示した取り組みを紹介しています。本記事では主に1つ目の話をしていきます。
おすすめ配信の処理概要
おすすめ配信を作成するにあたり、次のことを行っています。
- ユーザ毎の視聴傾向や配信傾向を示す特徴量の算出
- 配信毎の特徴量の算出と、特徴量に基づく配信リストの作成
- 独自のレコメンドモデルを用いて、ユーザの特徴量と配信リストから、ユーザ毎のおすすめ配信リストを作成
- おすすめ配信を表示する際に、APIレスポンスとしてこれを返す
上記を実装するにあたりポイントとなるのは次の内容です。
- ユーザ毎に異なるおすすめ配信を作成するには計算量が膨大となること
- アプリトップで表示されるおすすめ配信はもっともよくアクセスされるAPIの一つであること
都度計算する内容が多くなるほどAPIの応答時間は伸びます。APIの応答時間が長いと、ユーザ体験が悪くなったりウェブサーバ全体が不安定になりやすくなります。
おすすめ配信は、次のように負荷を分散する、計算量を減らすことで、安定して動作しています。
- デーモンプロセスによる非同期処理、事前計算
- 中間データの生成とDB負荷を下げるためのメモリキャッシュ
- 機械学習サーバなどで大規模解析することで一括でユーザの特徴量を算出
システムにおいて各種サーバがどのような処理を行っているか、下記にて説明します。
- ウェブサーバ、デーモンサーバは定常的にシステムログをログサーバに送っている
- 機械学習サーバは定期的にログサーバのシステムログを参照して、ユーザの特徴量を算出
- デーモンサーバは定期的に機械学習サーバからユーザの特徴量を取得し、DBに保存
- デーモンサーバは定期的に配信の特徴量を算出し、特徴量に基づく配信リストを作成、それらをDB、Cacheに保存
- ウェブサーバはミラティブアプリからのおすすめ配信API呼び出し時にDB、Cacheからおすすめ配信リストを生成しつつCacheに保存
- ウェブサーバはおすすめ配信リストをもとにDB、Cacheから必要な配信情報を取得し、応答を返す
おおよその処理内容は上記の通りで、ほかにもウェブサーバでのおすすめ配信レスポンス作成時には、配信に固有な値を配信ごとにキャッシュしてDB負荷を下げるなどしています。一方で、おすすめ配信に表示されている情報の中でもフォローしているかなど、ユーザ毎に変わるもの、変化しやすいものがあり、それらはキャッシュせずに都度計算しています。
また、先日 Envoy導入 の記事を公開しましたが、おすすめ配信のエンドポイントへのアクセスはEnvoy経由で専用クラスタにアクセスを振り分けており、負荷分散しています。
おすすめ配信の開発サイクル
おすすめ配信の開発サイクルは次の通りです。
- ユーザの行動観察や大規模なデータ分析から示唆を抽出する
- 抽出した示唆からユーザの好ましい行動を再現する施策を導き出す
- 施策を実装可能な仕様に落とし込み、実装する
- 結果を評価し、1. に戻る
おすすめ配信の開発はユーザに表示する配信を決定するパラメータを導き出す部分、すなわち 1, 4 の示唆の抽出と結果の評価の部分に時間と工数がかかります。レコメンデーションの精度向上は特にそうです。
たとえば、おすすめ配信の評価指標として単に配信にユーザが入室すればいいというKPIをおいてしまうと、施策を実施しても入室はするけどすぐ離脱してしまう、といったことがおきます。このような場合、長くミラティブを遊んでいるユーザに見られる相互に配信を行き来するような関係までは至らない、長期で定着しないなど、局所最適なものとなりがちです。
おすすめ配信はあくまでユーザが配信に入室するまでをサポートするものにすぎません。おすすめ配信の施策を実施する際には、ユーザが相互に配信を行き来するか、ギフトを贈り合う関係になるかといったミラティブ体験の深いファネルのKPIまで改善するかまで見る必要があります。
私は主に実装担当として関わっていますが、1, 4 が可能な限りスムーズに行えるよう可用性を維持しつつすばやく実装したり、適切に分析ログを仕込むといったところを意識して開発に取り組んでいます。
おすすめ配信の開発で注意するポイント
施策や評価について
おすすめ配信はミラティブ体験の出発点であり、配信視聴の体験の前段でその役割を果たすものです。そのためちょっとしたレコメンドロジックの修正でも、実施した施策の効果を適切に測定するのに数日程度の時間が必要な場合が多いです。施策を段階的に展開していく場合にはサービス全体に展開するのに1ヶ月かかることもあり、修正量の割に時間がかかります。
また、実感として少し変更したくらいでは何も変化が起きないことが多いです。深いKPIの改善につながった施策は、大規模なデータ分析や本質的な示唆に基づいたものでした。分析や示唆だしが不十分だったり、施策が局所最適なものだったりすると、施策を実施しても効果が出ないといったことが起きてしまいます。
要件管理、技術負債管理について
各種KPIはサービス全体の各断面を表すものであり、要件個々の良し悪しを表したものではなく複合的に捉える必要があります。そのため、時間の経過とともに現在のKPIを実現している要件がなんなのかが曖昧になっていきます。そんななか、新しい要件を追加していく際に、優先されたり捨てられたりする要件が出てくるのですが、それらを刷新するか改めて判断したい場合、新しい要件の評価と同じくらい工数がかかります。
新しい要件を追加で実装する際に、競合する古い要件を維持しつつ新しい要件を足していくのか、古い要件を効用が少ないと判断してばっさり捨て去って新しい要件を足すのか、判断が難しい場合があります。古い要件を維持するか、新しい要件をどの程度のスピードで展開していくかで全体の開発期間がかなり伸び縮みします。
古い要件を捨てるとKPIが大きく変化する懸念があるので、それらを維持しつつ新しい要件を足すのが正しそうなものの、それだとユーザへの影響が小さく意味のある効果となるまで至らないといったことが起きます。新しい要件を試した結果、優位な結果が得られることがわかったら、古い要件はばっさり捨て去ってしまうことで予定期間内に大きくKPIを改善させられたといったこともありました。
おわりに
おすすめ配信の開発においては、データ解析やユーザ観察からレコメンドロジックを考え、それを実装することでKPIが変化していくとき、作り手としてとてもやりがいを感じます。効果がなかったり時間がかかったりしてなかなか結果がでないときもある分、結果が出たときはなおさら嬉しいですね。今回、詳細に紹介していませんが、おすすめ配信に機械学習で算出した特徴量を利用するにあたり分析チームが様々な取り組みを行っています。機会があればそのような内容の記事をアップロードするかもしれません。
We are hiring!
おすすめ配信は、ミラティブでユーザが配信に興味を持つきっかけとして大きな役割を果たしており、今後も継続しておすすめ配信の改善を行っていきます。興味を持っていただけた方は、ぜひ下の採用サイトもチェックしてみてください。
- 大規模なデータ解析やユーザ観察を通してユーザに楽しんでもらえる機能を提供したい！
- パフォーマンスを考慮して要件をシステムに反映するのが得意！
- 機械学習を使って新しい価値を創造し、実用例を世に出していきたい！
といった方、ご応募お待ちしております！
