バーティカル検索プラットフォームABYSSの取り組み

検索は検索窓だけで行うわけではないことをご存じでしょうか？　ヤフーではレコメンドなど、さまざまな検索体験をユーザーに提供しています。

例えば、下図で示すYahoo! JAPANアプリでは、ウェブ検索の他にも検索技術が活かされています。未読メールの数、路線情報、天気情報などが代表的な例です。eコマースにおいては商品の検索やレコメンドにもこの技術が適用されています。まさに、検索技術は必要不可欠なものです。

ヤフー全体で使われている検索サービスは、ABYSSというプラットフォームによって支えられています。ABYSSは「Automated」「Building」「Yahoo!」「Search Sdk」の頭文字をとった名称です。末尾にSDKとありますが、現在はSDKは提供していません。2010年に「ABYSS 1.0」をリリースし、2014年からはコア技術をアップデートした「ABYSS 2.0」を提供しています。

ABYSSの誕生前は、内製の独自検索エンジンをパッケージ化して配布していました。サービス担当者はそのパッケージを実機サーバにインストールし、保守運用まで担っていた背景があります。サービスごとに検索結果の改善やパフォーマンスのチューニングなどのナレッジは蓄積しましたが、あるサービスでは最新のサーバを使用し、別のサービスでは異なるベンダーの古いサーバを使用しているなど、実行環境が異なるためにナレッジの共有は難しい状況でした。

こうした問題を解決するために、共通の検索プラットフォームとなるABYSSを構築しました。これによってナレッジの集約・共有が進み、成功事例を別のサービスにも展開可能になりました。その結果として、多くのサービスで検索体験を改善する土壌ができました。

また、ABYSSを使うようになったことで、サービスの担当者とプラットフォームの担当者の役割が明確になりました。結果として、サービス担当者はサービスの改善に、プラットフォーム担当者は運用コストの削減と最新技術の採用に注力できる体制を整えられました。

ABYSSを支える仮想化、SPOFの排除、オートヒーリング

現在、ABYSSはApache Solr（以下、Solr）をベースとしています。Solrはオープンソースの全文検索エンジンであり、Javaで書かれたものです。Javaのインターフェースを実装することで機能を拡張できるという特徴があります。

ABYSSはSolrを用いた共通の検索プラットフォームとしてマネージド環境を提供しています。B to B向けも含めるとヤフーにおける100以上のサービスで利用されており、1万以上の仮想マシン上で稼働しています。

ABYSSは自社のデータセンターにある内製の仮想環境上に構築しています。これによって社外のクラウド環境を利用するよりも、サーバの維持コストを抑えられます。また、コンテナ技術でSolrを独自にパッケージ化。同じバージョンのコンテナイメージはプラグインのバージョンも同じなので、別の仮想マシン上でも同じ環境を容易に再現できます。

フィード（検索対象に加えること）されたデータは、コンテナの外の仮想マシン上に保存されます。仮想マシン上に保存されたデータはコンテナを再作成しても消えません。そのため、担当者はプロセスの異常を検知したときに、データを消失することなくコンテナを再作成できます。

とはいえ、物理レイヤーが故障すれば仮想マシン上のデータが消えるリスクはあります。そこで万が一に備えてABYSSを1シャード当たり最低3つのレプリカを設けて冗長化しています。これによって仮想マシン1台のデータが消えたとしても、Solrのレプリケーション機能により、シャード全体のデータが消えることはありません。

しかし、これでもリスクを払しょくできたとは言えません。シャード内にある複数のレプリカが同じ物理レイヤーで稼働している状態はSPOFが存在するため危険だと判断できます。

シャード内全ての仮想マシンが同じ物理レイヤーで稼働している場合もさることながら、内2つの仮想マシンが同じ物理レイヤーだった場合も、その物理レイヤーが故障した場合、すべてのリクエストを残った1つの仮想マシンで処理する必要性が生じるためです。

こうした危険な状態を回避するために使われる「チェッカー」というコンポーネントが存在します。

チェッカーは、シャード内の物理レイヤーにSPOFが存在するかチェックするコンポーネントです。SPOFを見つけた場合は、ABYSS担当者が別の仮想マシンに差し替えるなどの対応策を講じます。

ここで、ABYSSの構成について説明します。

ユーザーからのリクエストは、ルーティングサーバを通してSolrに到達します。ユーザーとルーティングサーバの間には、サービスのWebサーバやAPIサーバが置かれているケースが多いです。サービス担当者はWeb UIから設定変更やログの閲覧を行います。この部分は一般的なクラウドサービスと同じです。

Solrの設定変更は全て内部API経由で行われます。内部APIは、変更の内容に応じてSolrのサブコンポーネントであるzookeeperを操作したり、Solrのクライアントライブラリを経由してSolrクラスタを操作したり、Solrサーバに直接httpリクエストを送って操作したりします。内部API経由で設定を変更することによりオペレーションミスを防ぐ狙いもあります。

ABYSSには、監視サーバ以外にも運用をサポートする「チェッカー」と「リペアラー」というコンポーネントが存在します。チェッカーは、先に触れたSOPFのチェックも含めてSolrクラスタ全体の健全性をチェックします。一方、リペアラーはオートヒーリングの役割を担います。具体的には、仮想マシンのベンダーが公開している障害情報のAPIをリクエストし、障害から復旧しているサーバがある場合は仮想マシンをリスタートします。

ABYSSでは仮想化、SPOFの排除、オートヒーリングによって、1万台のサーバを安心して稼働させられるプラットフォームとなっています。

最新技術を独自実装：ANNプラグイン、TPRプラグイン

次に、最新技術を採用する取り組みについてご紹介します。ABYSSの担当者には、年に何度か「この論文にある検索技術が実現できれば、ユーザーにもっと良い検索体験を届けられるのに」といった相談が寄せられます。

最新技術を採用したいという相談に対して、多くのエンジニアは「その機能が使えるソフトウェアのバージョンがリリースされ、こちらの動作確認が終わるまで待ってください」と答えるでしょう。しかし、そんなに長い時間待っていられないと思う人もいるはずです。そこでABYSSでは、プラットフォームチーム、サービスチーム、サイエンスチームがタッグを組んで、サービス担当者の要望を実現しています。

ABYSSが誕生した当初は、プラットフォームとサービスチームの2チームでしたが、現在ではサイエンスチームが加わって各チームが検索改善に取り組んでいます。サイエンスチームがSolrのプラグインとして拡張機能を独自実装し、プラットフォームチームがそれを取り込んだ環境をサービスチームに提供する流れです。サービスチームは、いち早く拡張機能を利用できます。

具体例として、ANNプラグインの話をご紹介しましょう。ANNとは、近似を用いてベクトル検索の処理を高速化する方法です。ベクトルの全件検索と比べると検索精度では少し劣りますが、レスポンスが得られるまでの時間を大幅に改善できます。

近年、画像検索や自然言語処理においてベクトル検索技術が注目されるとともに、Solrなど全文検索エンジンの分野でも、ベクトル検索やANNなどの機能追加が求められるようになりました。Solrでは2022年5月にリリースされた「Solr 9.0.0」でANN機能がサポートされました。

ヤフーでは、2020年中にサイエンスチームがSolrのプラグインとしてANNプラグインを開発、その後プラットフォームチームがSolrコンテナのイメージ上で動作確認や性能評価などを実施しました。その後、2021年6月にはサービスチームで性能評価やABテストなどを実施して優位性を確認し、同年10月にはANNプラグインへ切り替えました。このようにABYSSでは、自社で実装した拡張機能を多数活用しています。

中でも、よく使われている独自実装の機能を紹介します。Solrは日本語トークナイザーをサポートしていますが、ヤフーでは自社開発した日本語トークナイザーであるWebMA TokenizerとAsagi Tokenizerを利用しています。

その他にも自社開発したTPR（Two Phase Ranker）プラグインは、マルチフェーズランキングだけでなく密ベクトルも扱えます。TPRプラグインはSolrの処理の流れをうまく抽象化して実装しているため、1つのプラグインでいくつもの処理に対応できます。

また、先ほど紹介した近似を用いたベクトル検索のためのANNプラグイン、重複排除を行うDedupeプラグインなども独自実装しています。

利用事例：Yahoo! JAPANアプリのタイムライン

ここからは、ABYSSを使うサービスの事例を紹介します。

1つ目はYahoo! JAPANアプリのホーム画面をスクロールすると、記事が多数表示される「タイムライン」に関するものです。タイムラインにはABYSSによる検索結果が表示されています。タイムラインの機能要件は2つあります。1つ目は、各ユーザーにとって興味がある記事をレコメンドすること、2つ目は記事の鮮度を保つことです。5分ごと、10分ごとのバッチ処理ではこの要件を満たせません。

機能要件を実現する課題は3つありました。

1つ目はリクエスト数が多いことです。レコメンドされた記事の中には、すでに内容を知っているものもあるでしょう。そのような場合、ユーザーは何度も画面をスクロールします。結果としてリクエストの数が増えてしまいます。リクエストの数は平常時でも1秒間につき数千回、ピーク時に至ってはその2倍もの数に上ります。特に重大なニュースが通知されると、多くのユーザーが一度にYahoo! JAPANアプリを起動するので、さらに多くのリクエストが来ます。

2つ目は、ユーザーが画面をスクロールしたときに、次の記事をすぐ表示するレスポンスの速さです。前処理や後処理も考えると、平均で数十ミリ秒、99パーセンタイルでも数百ミリ秒以内に検索結果を返却する必要がありました。

3つ目は、機械学習を利用した高精度なレコメンドを実現したいという要件です。レコメンドの精度とレスポンス時間はトレードオフの関係にありますが、うまくバランスをとる必要がありました。

Yahoo! JAPANアプリのタイムラインではABYSSの外で2つの機械学習を回しつつ、ABYSSの内側ではシンプルなベクトル検索を行うことにしました。機械学習ではフィードされた記事から記事の特徴を抽出した「記事ベクトル」と利用者の好みを抽出した「ユーザーベクトル」が生成され、記事ベクトルとユーザーベクトルの類似度によってタイムラインを生成しています。

ABYSSチームはリクエストの数が多いという課題に対応するため、1つのクラスタでリクエストを処理するのではなく、多数のレプリカを持つクラスタを複数用意することでリクエストを分散しました。機械学習はABYSSの外側で実施しているため、仮想マシンはミドルスペックでクラスタを構築しました。

利用事例：Yahoo!知恵袋

ABYSSはYahoo!知恵袋の質問の検索と、質問にひも付く回答の検索の両方で利用されています。Yahoo!知恵袋は、良い回答が集まっている質問が何度も閲覧されるため、そういった質問を検索結果の上位に表示したいという要望がありました。しかし、良い回答が集まる質問かどうかを自然言語処理で判定するには限界があったので、機械学習の技術を用いています。

機能要件に関わる前提として、Yahoo!知恵袋には、膨大な量の質問と回答が存在し、日々増加しています。2004年のサービス開始以来、18年間蓄積された質問の量は2億5000万件に上り、回答は6億件にも達しています。またレスポンス速度に関しても、リクエスト数が平常時で1秒間に数千件ある中、レスポンスの速度は機械学習を用いても平均で数十ミリ秒、99パーセンタイルで数百ミリ秒以内に収める必要がありました。

Yahoo!知恵袋では、TPRプラグインを用いることで高速なレスポンスを実現しています。第1フェーズでは、形態素解析によるランキングを行います。検索クエリにヒットした質問を検索単語の出現数が多い順にランキングし、シャードごとにチューニングパラメーターで定められた上位N個を第2フェーズへ渡します。第2フェーズでは、N個とシャード数をかけた数の質問を機械学習でスコア化してリランキングを実施し、トップ10を検索結果として返却しています。

ABYSSチームはハイエンドスペックの仮想マシンを使った大規模クラスタを用意しました。Solrは全文検索エンジンなので、パフォーマンスを改善するには、検索するテキストが全てメモリ上になければならないため、巨大なメモリが必要でした。また、機械学習モデルでスコアを計算するため、ハイパフォーマンスのCPUも求められました。

ヤフーでは各サービスに合うSolrクラスタを提供、運用することで、今後も検索体験の改善に努めていきます。

アーカイブ動画

Apache®, Apache Solr™, 及びSolrのロゴは、米国および/またはその他の国におけるApache Software Foundationの商標または登録商標です。