リクルートの情報検索組織が検索APIの基盤をIaaSからPaaS中心にした理由：リクルート事例で分かるIaaS→PaaS移行のコツ（1）

リクルートの情報検索組織において検索APIの基盤をどうやってPaaS中心のシステムに移行したかを紹介する連載。初回は、PaaS中心の世界観に至った歴史的いきさつ、理由について解説する。

[大杉直也，リクルート]

　本連載「リクルート事例で分かるIaaS→PaaS移行のコツ」では、リクルートの情報検索組織において検索APIの基盤をどうやってPaaS中心のシステムに移行したかを紹介します。

　テキスト検索やレコメンデーションなどに代表される情報検索機能では、できることや求められる役割、水準が年々上がり続けてきました。そのための開発も、計画通りにしっかり実施するよりも、たくさんの試行錯誤が求められるようになっています。そこでリクルートの情報検索組織では、機能のスコープを絞り、クラウドサービスを活用して“製造”を可能な限りテンプレート化することで、エンジニアが試行錯誤に集中できる状態を作りました。本連載の第1回ではそこに至った歴史的いきさつ、理由を述べます。

本連載の背景

想定読者

• クラウドサービスを使ったシステム構築を提案（営業）したい人
• 情報検索APIの良い感じの作り方について設計レベルのイメージが欲しい人

7年前との差分

　2015年に寄稿した＠ITでの連載から7年近くの月日がたちました。当時と比べて多くのことが変わりました。「Elasticsearch」という全文検索エンジンが中心なのは変わりませんが、例えば当時の連載タイトルにもなっていて、自前で運用していた「Apache Hadoop」は、その機能を「Google BigQuery」＋「Cloud Dataflow」で実現した方が容易、安価、安定なので、置き換えました。この7年の外界の変化を大胆に分類すると次の2つに集約されます。

1. 「要件を完全に満たす」開発以外の、ユーザー体験やアルゴリズムの試行錯誤を重視した開発の比重が大幅に高まった。いわゆる「AIプロダクト」のニーズが増えた
2. クラウドベンダーがサーバの提供だけでなく、サービスの提供に力を入れてきた。いわゆるIaaS中心からPaaS中心になってきた。例えば、7年前のわれわれはAmazon Web Services（AWS）の「Amazon EC2」の利用が多かったが、最近は「Amazon Elastic Container Service」（ECS）や「Amazon OpenSearch Service」などを利用することが増えた

　前者のニーズの変化からエンジニアに求められるスキルも、自然言語処理や機械学習や統計学などのいわゆるデータサイエンスの重要度が増え、「検索エンジニア」として覚えなければならないことが増えました。検索エンジニアは、ただでさえインフラやソフトウェアのレイヤーだけでなく検索エンジンといった特殊なミドルウェアも学ばなければならないので、初学者が開発に従事するハードルがかなり高いです。さらに、「何を作ったらよいのか」の試行錯誤まで求められ、かつ世の中の他の情報検索サービスも進化し続けているので、期待値は年々上がり続けてハードルが高くなる一方です。

　そういった初学者のハードルを下げたのがPaaS中心の世界観です。このおかげで、短期学生アルバイトや入社直後の新卒の方でも動くAPIを作ることができ、そのAPIの品質を向上させるための利用データやアルゴリズムの探索に集中できるようになりました。

　ただし、PaaSがあるから即ハードルが下がったのではありません。7年間の蓄積から適切な開発スコープを設定でき、そのスコープを実現する技術を継続的に選定したからこそ、この世界観を実現できました。どのようなものが作られ、それがどのように使われているかは第2回以降の連載で触れます。ここでは、「どのように開発スコープを設定したのか」や、今後の展望について述べます。

変わったヴィジョンと変わらないコンセプト

　もともと情報検索組織では、社内の多数のWebサービスの検索機能を置き換える検索基盤の提供を目指していました。これが初期のヴィジョンでした。ただ、この検索機能がリクルートのWebサービスで中心的な役割を担っており、そのため独自要件が多く、サービスレベル目標が非常に高いので、その機能を置き換える開発、運用のコストが多くなりました。また、サービスを運営している側からしても、機能がほとんど変わらない以上コストとリスクをかけてまで検索基盤を置き換えるモチベーションはありませんでした。

　一方で検索基盤そのものではなく検索お薦め順のアルゴリズム（ランキングアルゴリズム）や「Query Auto Complete」（検索キーワード）などの周辺機能は、レコメンデーション用途や一風変わったテキスト検索などの多種多様なビジネスニーズも増え、工夫の余地も大きかったのです。こちらも後述しますが、Elasticsearchを中心とした仕組みでだいたいのケースが実現可能でした。

　その結果、情報検索組織のヴィジョンが「さまざまなサービスの成長の源泉となる検索エコシステム」から「情報検索のニーズに対して適切な技術アセットやノウハウを提供する専門組織」に遷移していきました。

　このようにヴィジョンは変わっていきましたが、全文検索エンジン（Elasticsearchや「Apache Solr」）を使うといったコンセプトはブレることはありませんでした。この理由の一つには、ElasticsearchやSolrで採用されている「転置index」や「分散アプリケーション」の考え方自体は古くならず、これらの特性は情報検索関連のAPIを開発する際に非常に有益だからです。具体的にどんな情報検索が可能になるかを以下で簡単に見ていきます。Elasticsearchを例にしますが同じようなことはSolrでも実装可能です。詳細は本記事連載の第5回でも改めて触れます。

例1：テキスト検索

　転置indexに文章をトークン化したものを登録し、そこのindexにトークン完全一致で検索できるので、長文に対してテキスト検索する際のレスポンスが早いです。またトークン化する際に日本語の形態素解析辞書を使うことで、「京都」で検索した際に「東京都」でヒットさせないといった検索の品質を簡単に改善できます。さらに、リレーショナルデータベースで一般的に使われる「B-tree」と比べてindexを複数貼ってもパフォーマンスがほとんど劣化しないので、テキスト検索の他にも地域やジャンルなどで追加の検索絞り込み条件を追加しやすくなっています。ElasticsearchやSolrでは「filed」という概念で検索対象のindexが追加されます。

　ElasticsearchやSolrを採用した場合、このような使われ方が“王道”とされているので、このような複雑な処理が「どこで、どう実装されるか」の“お約束”があり、新規開発やエンハンス開発がやりやすいといった特性もあります。例えば、同意語（例：「焼きそば」と「焼そば」）に対応するために、「どこに、“寄せる処理”を入れるか」なども選択肢がしばられるので、設計の自由度が下がり、考えることが減る、道を大きく踏み外さないといった開発フレームワーク的なうれしさもあります。

　ElasticsearchやSolrでは「どこのfiledにヒットしたか」で、検索並び順を作るための「score」への加点度合いを変えられます。一般的には、このscoreの多い順を検索結果の並び順にします。このscoreへの加点度合いを、例えば形態素解析でトークン化されたテキストの方を「2-gram」でトークン化されたテキストよりも大きくすることで、よりそれっぽい検索結果一覧が得られやすくなるなどの工夫ができます。

　また、この加点のルールは「function score query」といった機能を使えば、かなり自由な条件や数式を表現できるようになり、よりそれっぽいお薦め順が作れます。検索キーワードが地名っぽい場合、「商品名」テキストが含まれたfieldよりも「販売店所在地」テキストが含まれたfieldのヒットを優先させたくなりますが、これはElasticsearchやSolr単体では実現できません（2022年3月現在）。これを実現するためにElasticsearchやSolrの外側に、そこへのqueryを動的に書き換える仕組みを導入する必要があります。この仕組みは2017年の＠ITでの連載記事で紹介したので、詳細はこちらを参照してください。

　この仕組みとfucntion score queryを組み合わせれば、例えば「水」で検索された場合に「ジャンル：飲料水」の商品を検索結果上位に表示させやすくするといった実装が簡単になり、運用も容易になります。

例2：検索キーワードサジェスト（Query Auto Complete）

　検索キーワードを入力ボックスに入力する途中に、完成系の検索キーワードが推薦される仕組みがあります。その背後にあるAPIもElasticsearchやSolrで作れます。これはテキスト検索とほぼ一緒の作りで実装可能です。queryが部分文字列になり、indexに完成系の検索キーワードを登録します。大きな差分は、（1）「快適なユーザー体験に求められるレスポンスタイムの水準がシビア」で、（2）「完全なキーワードではないので形態素解析よりも文字列前方一致が重要」の2点です。（1）のためにはindexをシンプルにした方が良く、indexに検索キーワードの人気度合いや流行度合いを検索ログなどから「事前計算」した値を入れ、scoreを作る際はその値を参照するだけにするなどの工夫で対処できます。（2）のためには例えば「Edge n-gram」のindexを作るなどで対応できます。

例3：レコメンデーション

　queryが、いわゆる検索入力画面からの情報だけでなく、ユーザーの過去アクションのログから作られると、レコメンデーション用途でも使えます。これはテキスト検索で紹介したfunction score query、query動的書き換えの仕組みと、検索キーワードサジェストで紹介した事前計算した結果をindexに入れる方式を組み合わせればかなり多くのことが達成できます。「協調フィルタリング」のような方法も、行列分解してベクトル化するなどの工夫をすることで、Elasticsearchの「ベクトルフィールド」やSolrの「Vector Math」を使って高速かつ安定的に実装できます。

例4：自動QAシステム

　普通の検索では、検索キーワードから文章を選びますが、Elasticsearchでは「Percolate query」という機能があり、この機能を使えば文章から検索キーワードを選ぶことができます。Elasticsearchを2つ用意することで、まず質問文から検索キーワードを抽出（Percolate queryを利用）し、その検索キーワードから回答文を検索（普通の検索）すると、自動QAシステムが作れます。ただし、この方法では形態素解析やn-gramを使って文章をキーワードに射影（token化）する必要があるので、昨今流行している「Bidirectional Encoder Representations from Transformers」（BERT）などのニューラルネットワークベースには使えません。

　このようにElasticsearchの機能を適切に選択し、queryやindexの設計を工夫すればかなり柔軟に情報検索APIを開発できます。この種の開発にElasticsearchを一種の制約としておけば、ひとまず動くものをすぐ作れます。初学者が転置indexや分散アプリケーションの概念を理解せずとも使えるので、手を動かしながら学ぶ方が向いている人には、Elasticsearchを前提とした開発がお勧めです。

スコープ選択と、その中での進化

　Elasticsearchを中心としたコンセプトの下、周辺機能の開発を続け、それらの案件を分析することで、次の性質は非常に重要であると再確認できました。

• 高速なレスポンス
• 柔軟な絞り込み
• 柔軟な並び順
• 大量アクセスに耐えられるインフラ
• 高度なテキスト検索

　これらの性質はElasticsearchを中心とした開発なら比較的容易に達成できます。

　一方で、次の性質は、多くの案件で求められないことも分かりました。

• 個人情報データ対応
• リアルタイム更新

　また、リクルート全体でBigQueryが導入される事例が増えるといった外界の変化もあり、各種データ連携の方法をBigQuery経由に絞るといった意思決定もしました。この結果、「csvファイルをAmazon S3経由で」「xmlファイルを仮想ディレクトリ経由で」といったデータ連携パターンの増加が大幅に抑制されたので、開発効率や保守性が上がりました。

　リアルタイムに更新しないと決めたので、当初は独自ビーコン＋「fluentd」で収集していたデータが（1）リアルタイム性が求められないindexに反映させるものはBigQueryに蓄積されたアクセスログに、（2）リアルタイム性が求められるパフォーマンスに関連するメトリクスは「Amazon CloudWatch」に載せ替えることができました。

　このようにスコープが限定されることで「どのようなクラウドサービスを採用すべきか」の要件が明確になってきました。このいきさつは連載第2回で詳細に解説します。

　スコープと利用技術が限定されたので、次にコストとデリバリーを改善するように工夫しました。そこで誰でも簡単に早く開発できる状態を目指し、開発プロセスをフォーマット化しました。こちらは連載第3回、第4回で詳説します。

　スコープが限定されて技術選定が明確になり、コストやデリバリーも改善されたので、次は品質の改善やスコープの再拡大に挑戦します。

品質の追求に向けて

　デリバリーが改善されたことで、開発者が“成果物を作ってはつぶす“試行錯誤に割ける時間を増やせました。また、「counterfactual machine learning」「unbiased learning to rank」といった分野の急速な発展から、品質に対して機械学習が貢献できる割合も着実に増え続けています。しかし、それでも「そもそも何をすべきか」「機械学習で解ける問題設定」「定量で評価しにくい場合や考慮漏れしていたエッジケースの発見」などは、まだまだ人間がやらなければならない仕事です。「実現したいこと」をqueryとindexの設計に落とすところも現在では人間の仕事です。これはクラウドサービスがいくら発展しても当面は担当した開発者が取り組む仕事だと思います。

　また、試行錯誤の時間が増えたとしても、その時間を有効に使えなければ意味がありません。以前と比べて人間がやらなければならない仕事は確かに減りましたが、品質の追求という点は、まだまだ人間の仕事です。そして、人間でやるためにはどんどん“ヒト“を育てなくてはなりません。今回の「製造を可能な限りテンプレート化する」ことによって初学者が学びやすい環境を作ることができ、今後は「開発者を強くする」ことに、より注力する予定です。結局は“ヒト“です。今後は「情報検索のニーズに対して適切な技術アセットやノウハウを提供する専門組織」として強くなります。

　次回の連載第2回では、われわれの技術的な変遷や「どのような課題に対してどのように技術を選定し、その結果どう良くなったのか」について詳細に解説します。

筆者紹介

大杉 直也

2005年、千葉大学文学部に飛び入学（高校は中退）。2009年、奈良先端科学技術大学院大学情報科学科に入学（博士前期課程、理学修士）。2011年、東京大学大学院総合文化研究科に入学（博士後期課程、単位取得満期退学）ならびに理化学研究所脳科学総合研究センターで大学院リサーチ・アソシエイトに採用。研究テーマはニホンザルの脳波のデータマイニング。2014年、株式会社リクルートホールディングスに入社。2017年、N高等学校に3年次編入（社会人高校生）。2留を経て2020年、同高校卒業。現在は株式会社リクルートの検索ソリューショングループのマネージャー