本記事は、10月29日〜30日にかけて開催した「CyberAgent Developer Conference 2024」において発表した「ABEMA レコメンドシステムのアーキテクチャ変遷〜事業成長や大規模イベントと共に〜」に対して、社内の生成AI議事録ツール「コエログ」を活用して書き起こし、登壇者本人が監修役として加筆修正しました。
中野 修平 (株式会社AbemaTV ソフトウェアエンジニア)
2019年4月に株式会社サイバーエージェントに新卒入社。メディアサービスへの共通推薦基盤の開発の経験を経たのち、ABEMAの推薦システム、検索システムの開発に従事。
金光 雄佑 (株式会社AbemaTV ソフトウェアエンジニア)
サイバーエージェント入社後、ABEMAにて推薦基盤および検索基盤の刷新に従事。
「ABEMAレコメンドシステムのアーキテクチャ変遷～事業成長や大規模イベントと共に～」というタイトルで発表させていただきます。この発表は2名で行います。まず自己紹介から始めます。前半パートを担当する中野修平です。私は機械学習エンジニアとして活動しています。
本発表の全体構成についてご説明いたします。ABEMAの推薦システム「Yatagarasu」は、事業の成長に伴いアーキテクチャの見直しと再構築を繰り返してきました。このセッションでは、前半でABEMAにおける推薦システムの概要を説明し、後半でその時々の事業要件を満たすために行ってきたアーキテクチャの変遷について共有します。
1. ABEMAの推薦について
ABEMAの推薦についてご説明します。右側に表示されている画像がABEMAの画面です。この画面は、推薦という観点で見ると、2つの要素で構成されています。
1つ目は「コンテンツ」で、これは各番組を指し、推薦システムにおける最小構成要素となります。もう1つは「モジュール」で、特定の条件を満たすコンテンツの集合を指します。もう少し具体的に説明しましょう。ABEMAのアプリを開いた際に最初に表示される画面があり、これを「ホーム面」と呼びます。
例えば、「バラエティを選んだあなたへ」といった文字列の下に番組が横に並んで表示されていることがありますが、これが1つのモジュールです。また、何かの番組を再生した際、再生中の番組の隣に縦に並んでいる他の番組の集合もモジュールと呼びます。
ユーザーがABEMAの画面を見たとき、さまざまな番組の集合が表示されますが、これがモジュールです。つまり、ABEMAの画面はモジュールで構成されているといえます。
これらのモジュールはランダムに作成されているわけではなく、推薦システムによって生成されています。ABEMAの推薦システムは、各ユーザーに最適なモジュールをチューニングして提供しています。なお、ABEMAの推薦システムには複数のシステムが存在します。
複数の推薦システムが存在する理由は、用途ごとに推薦の目的が異なるからです。今回お話しする「Yatagarasu」は、視聴履歴を基にした機械学習を活用した推薦システムです。
2. 推薦システムについて
まず、一般的な推薦システムについて説明します。推薦システムとは、ユーザーに興味がありそうなコンテンツを推薦するシステムを指します。このシステムの処理は、オンライン処理とオフライン処理に分かれています。オフライン処理では、機械学習モデルの学習や推薦ロジックの処理を行います。一方、オンライン処理では、実際にユーザーがサービスにアクセスした際に、どのコンテンツを推薦するかを決定する処理が行われます。
ABEMAの推薦システムでは、特に「超大量のユーザー」「超高速」「超大量のコンテンツ」という3つの要素を意識する必要があります。つまり、大量のユーザーに対して、膨大なコンテンツの中から興味を持ちそうなものを高速に推薦することが求められます。この「超大量のユーザー」「超高速」「超大量のコンテンツ」という課題に対応するため、アーキテクチャを慎重に検討しなければなりません。
ここで「最適なアーキテクチャとは何か？」と考えるかもしれませんが、私たちは絶対的な解は存在しないと考えています。なぜなら、最適なアーキテクチャは状況によって異なるためです。例えば、ある条件AのもとではBが最適でも、別の条件CではBはむしろ避けるべき選択になる可能性もあります。こうした中で、私たちは事業、技術、人材の観点から、戦略的に推薦システムのアーキテクチャを変遷させてきました。今回の発表では、その変遷について詳しくご紹介していきます。
ABEMA の推薦システムのリアアーキテクチャが3回行われました。それらのリアアーキテクチャは超大量ユーザー、超高速、大量のコンテンツといった挑戦に対して事業・技術・人材の観点を考慮しながら解決した話になります。
第1回はオンプレ脱却 大規模イベントに向けて。第2回はシステム効率化。第3回は改善サイクル効率化になります。
3. アーキテクチャの変遷について
アーキテクチャの変遷についてご説明します。まず、第1回目の変更である「オンプレ脱却：大規模イベントに向けた対応」についてです。このアーキテクチャ変更は、主に「超大量ユーザー」に対応するために行われました。ABEMAの最初の推薦システムは、メディア共通の推薦システムを利用しており、Java製でオンプレミス基盤上で稼働していました。この変更により、オンプレミス基盤からGoogle Cloudに移行し、使用言語もJavaからPythonに変更しました。
アーキテクチャ変更の理由は、事業・技術・人材の観点で次の通りです。最も大きな理由は、事業の大きな成長に伴い、これまでには想定できなかったような国民的大規模イベントの番組を取り扱うようになったことです。
このため、より柔軟にリソースの変更ができるよう、クラウド基盤へ移行しました。次に技術面の理由ですが、機械学習が注目を集め、エコシステムがPythonに移行しつつあったため、主な使用言語をPythonに変更しました。
最後に人材の観点です。新しいアーキテクチャでは、推薦ロジックや機械学習モデルのすべてを機械学習エンジニアが担当できるように変更しました。これは、メディア共通の推薦基盤からABEMA専用の推薦基盤に移行することで、よりABEMA特化の推薦に関する知見を蓄積するためです。
これにより、機械学習エンジニアが一貫して多くの推薦施策を実施できるアーキテクチャとなっています。次に、第2回目の「システム効率化編」について説明します。このアーキテクチャ変更は、主に「超高速」への対応を目的として行われました。
V1ではサーバー部分はすべてPythonで実装されていましたが、V2ではPythonとGoのハイブリッド構成になりました。この変更が行われた理由は、V1の運用・開発を通じて、ABEMAに関する推薦の知見がある程度蓄積されたためです。推薦の精度が向上したことで、次のステップとしてシステムパフォーマンスを追求する必要が生じました。
最後に、第3回目の「改善サイクル効率化編」についてです。このアーキテクチャ変更は、主に「大量のコンテンツ」に対応するために行われました。
V2ではサーバー部分がPythonとGoのハイブリッド構成でしたが、V3ではすべてGoで実装されています。また、Vertex AIやAlloyDBといった技術も使用していますが、具体的な内容については後半で説明いたします。このアーキテクチャ変更は、主に「大量のコンテンツ」に対応するために行われたものです。
背景として、サービスの成長に伴い、自社制作番組や他のコンテンツとの連携が増加し、コンテンツの種類や数の変動が以前よりも激しくなりました。つまり、推薦環境が大きく変化し、従来よりも迅速に推薦システムの改良が求められるようになったのです。特に推薦精度に対する要求が厳しくなったため、機械学習エンジニアが推薦精度の向上に集中できるようなアーキテクチャ構成を採用し、機械学習モデルや推薦ロジックが一箇所に集約される構造になっています。
ここからは金光が担当いたします。
では、ここからは金光が担当いたします。まず自己紹介をさせていただきます。金光雄佑と申します。サイバーエージェントに入社後、ABEMAにて推薦基盤や検索基盤の刷新に携わってきました。
ABEMAの推薦システム「Yatagarasu」は、これまでに3回のアーキテクチャ見直しを経ており、2022年から2024年の期間で新アーキテクチャへの移行が完了しています。それぞれの世代のアーキテクチャをv1からv3と呼び、順に説明していきます。
まずはv1についてです。こちらがv1のアーキテクチャになります。ご覧の通り、Google Cloudを基盤としたシステム構成になっています。
ABEMAの推薦システムは当初オンプレミスで稼働していましたが、大規模イベントで注目を集める中でトラフィックへの対応が求められるようになり、また機械学習の学習や推論に必要なリソースの確保、そしてマネージドサービスによる運用の利便性を目的として基盤をGoogle Cloudへ移行しました。
さらに、使用する言語を機械学習やデータサイエンスの分野でなじみのあるPythonに統一することで、開発効率の向上を図っていました。次に、v2について説明します。こちらがv2のアーキテクチャです。
改めて、各世代のアーキテクチャで共通するYatagarasuの概要について説明します。リアルタイムでのユーザーリクエストは、まずBFFを通してGatewayに到達します。このGatewayでは、事前に生成された特徴量や推薦する候補のコンテンツを取得し、次にRerankerがその候補をRerankingして最適なコンテンツをユーザーに推薦します。よって、この一連の処理を低レイテンシで実現することが、Yatagarasuにとっての技術的な挑戦になります。
さらに、CronJobが非同期でFallback用のコンテンツを取得してCloud Storageに書き出し、BFFがそのFallback用のコンテンツを事前にインメモリでキャッシュすることで、高可用性を担保しています。ストリーム処理のレイヤーでは、ユーザーの属性や行動に関する情報を一元化し、DMP（データマネジメントプラットフォーム）としての責務を果たすための特徴量を生成しています。バッチ処理のレイヤーでは、推薦するコンテンツの候補と特徴量の生成、さらにRerankerの推論に必要なモデルの学習を担っています。
v2では、GatewayとRerankerの両方に改良を加えました。Gatewayについては、Pythonのマイクロサービスを経由せずに、Bigtableに格納した候補を直接Gatewayから取得するように変更しました。
また、v1ではコストを考慮し、MemorystoreのBasic TierでConsistent Hashingを形成していましたが、一部のキーでホットスポットが発生する可能性があったため、v2ではリードレプリカを有効にしたStandard Tierを採用しました。
Rerankerについては、使用言語をPythonからGoに変更し、Rerankingにおけるキャッシュを撤廃しましたが、推薦の性能を維持しつつレイテンシを改善できました。また、将来的に他のマイクロサービスからも参照されることを見越して、TensorFlow Servingを使用し、シンプルなインターフェースで複数モデルを利用可能な実装にしました。
v2の結果、99パーセンタイルのレイテンシを約50%改善することができました。
最後にv3について説明します。v2によってエンドユーザーへの信頼性が向上しましたが、バッチ処理のレイヤーではCloud Composerを利用していました。今後、チーム内でVertex AIを積極的に活用する方針となったため、これを機に再度アーキテクチャの変更を行いました。
こちらがv3のアーキテクチャです。
v3では、Vertex AIの活用に加え、Memorystoreの廃止とAlloyDBの採用が特徴となっています。ABEMAでは、PrometheusとGrafanaによる可観測性の基盤が整っており、Yatagarasuにおけるキャッシュのヒット率も計測していました。
そこで、運用を通して得られた傾向を分析し、キャッシュ戦略を見直すことで、キャッシュに必要な空間を最適化しました。その結果、Yatagarasuの低レイテンシを維持しながら、Memorystoreを撤退し、コスト削減に繋げることができました。
これまで、候補とコンテンツの特徴量はBigtableで管理していましたが、既にベクトル検索を実現するためにAlloyDBでpgvectorを使用していたため、Matrix Factorizationの結果もAlloyDBにインデックスし、ベクトル検索を担うマイクロサービスから取得するように変更しました。
この変更の背景には、ベクトル検索の運用でレイテンシに問題ないことを確認できたことがあります。実際、Memorystoreを廃止しオリジンへのリクエストが増えたにもかかわらず、レイテンシは以前と同水準を維持できました。
v3の結果、トータルコストを約75%削減することができました。
締めくくりとしてお話しします。推薦システムに関しては、一般的にアルゴリズムや理論的な部分に焦点が当たりがちですが、実際にサービス内での運用を考えると、多様な技術と知識が求められる「総合格闘技」のようなものです。
また、クラウド技術やAIの進化を考慮すると、現在ベストだと思われるものが数年後には陳腐化する可能性もあります。こうした技術的な難易度や過酷な競争の中で、常により良いものを追求していくことこそが、実サービスにおける推薦システムに携わるエンジニアとしての醍醐味であると考えています。