リクルートの情報検索組織が検索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：テキスト検索