リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか：Elasticsearch＋Hadoopベースの大規模検索基盤大解剖（1）（1/2 ページ）

リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。初回は全体的なアーキテクチャ、採用技術、開発体制について。

[五味和人，リクルートテクノロジーズ]

連載目次

大規模BtoCサービスで求められる検索基盤は、どうあるべきなのか

　カスタマー（消費者）が求めるものが日々変わっていく現在において、BtoCの検索基盤はどうあるべきなのでしょうか。

　例えば、リクルートで使われている検索基盤の「Qass（Query analyze search system）」は単に全文検索機能を提供するのではなく、以下を軸としています。

• サービスごとに最適化されたクエリの自動変換（Query Rewriter）
• ユーザー行動に基づく検索結果の最適化
• 分析基盤からのフィードバックをシステムに取り込み、検索品質の自動的な向上

　これには、リクルートが提供する全てのサービスの根底には「集客を求めるクライアントと商品を求めるカスタマーをつなぐ」というマッチングビジネスモデルがあるからです（図1）。

図1　リクルートのビジネスモデル

　「『クライアント』から“情報や商品を集めて”、『カスタマー』に“購買してもらう（動いてもらう）”」を成立させるためには、下記のことが重要です。検索基盤は、そんなマッチングビジネスの中心的な役割を担う重要領域として、リクルートでは位置付けています。

• クライアントが提供する商材をカスタマーの元に届ける
• カスタマーが容易に目的の商材を見つけられるようにする
• カスタマーとクライアントを新たに巡り合わせ、両者に気付きを届ける

　そして外部環境変化を自身の成長モデルに取り込むと同時に、サービスAで得た成果と知見を、サービスBの入力として使う。その反対もしかり。すなわち、リクルートが有する100を超えるサービス間の相互作用によってサービスを成長させる、その源泉となる検索エコシステムを目指しています。それを支えているのがQassなのです。

　本連載では、このQassを例にして、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説していきます。

　筆者が所属するリクルートテクノロジーズは、IT・ネットマーケティングテクノロジの開発・提供を通してリクルートグループのサービスを支える機能会社です。リクルートテクノロジーズでは、テクノロジをソリューション単位にまとめてグループ各社に提供しており、本連載で紹介するQassも、その一つです。Qassはリクルートテクノロジーズで開発・運用を行っている成長型検索基盤であり、2014年3月より運用しています。

　第1回の今回は、リクルート検索領域の変遷とQassのシステム構成やQassが目指しているもの、そして開発体制などの全体概要を紹介します。

リクルートにおける検索基盤の変遷

　リクルートでは、もともと商用検索エンジンをベースに検索基盤を構築していましたが、環境変化に早期に対応するためには技術力を内部留保することが必須と考え、外部ソリューションを使い続けるよりもオープンソースソフトウエア（以下、OSS）を流用した自社ソリューションを構築することが重要と判断し、「Apache Solr」（以下、Solr）への移行を行いました。

　Solrへの移行は社内技術力の向上、およびコスト面で非常に大きな成果を上げましたが、下記のような課題がありました。

• サジェストなどの周辺機能はサービスごとに独自に実装され、ソフトウエア品質特性にバラつきがある
• 辞書メンテナンスが人力なので手間が掛かる
• Solr単体ではクラスタリング周りが弱く、更新性能、または耐障害性を犠牲にしなければならなかった
• 「SolrCloud」などを併用するとアーキテクチャが複雑になり、運用が大変になる

　新検索基盤は、これらの課題を解決すること、既存サービスへの影響を最小限にすること、そして運用に手間が掛からない自己成長型であることをテーマとして構築し、現在リクルートグループのいくつかのサービスに導入、今後の展開を進めています。

Qassの構成

　今回構築した新検索基盤では検索のコアエンジンに「Elasticsearch」を採用し、Hadoopによる機械学習を組み合わせることでカスタマーの検索行動に基づいた自己成長型の検索ソリューションを実現し、最適な検索結果に向けて日々改善活動を行っています。

　Qassのシステム構成は以下のようになっています。

図2

　インフラは自社オンプレとAWS（Amazon Web Services）を組み合わせていて、商品や広告、原稿などの商材に関わる重要なインデックスはオンプレ上に、サジェスト表出用のインデックスはトレンドのリアルタイム反映、負荷分散、レイテンシを考慮してAWS上にストアしています。

　また、ElasticsearchにQass独自のプラグインを差し込み、検索クエリを書き換える（Rewrite）などして、アプリケーションの改修なしに検索結果の最適化を図れるようにしています。プラグインはQass独自のクラスローダーによって読み込まれ、Elasticsearchの再起動なしに差し替えられるようにして高頻度のエンハンスを可能にしています。

　Elasticsearchを採用したポイントは以下の通りです。

1. Solrと同じApache Luceneベースなので既存サービスを新検索基盤に移行しやすい
2. クラスター構築が容易なので、高い耐障害性を確保できスケールしやすい
3. 洗練された分散モデルにより短スパンでのデータ更新が可能

　ElasticsearchとHadoop以外の主要な技術要素として以下のものが挙げられますが、これら以外にもChefやRSpec、ServerSpecなどを使用して、属人性を排除した短サイクルでのリリースを実現しています。詳細については後の連載で紹介します。

• 開発言語
  • Java 8
  • Go
  • Clojure
• 開発、運用環境
  • Git
  • Jenkins
  • Zabbix
  • Pacemaker
• 分析環境
  • Kibana 4
  • Embulk