再考！エンタープライズサーチ(2) エンタープライズサーチの歴史的位置づけ【後編】

企業内のデータを検索する技術として登場した「エンタープライズサーチ」。その位置づけと役割は大きく変化し、今日では企業システムの稼働状況やユーザー体験（UX）を把握するためのソリューションとしての応用が進み、かつ、新たな進化も遂げようとしている。本連載では、そんなエンタープライズサーチにフォーカスを絞り、その仕組みがユーザー企業にどのようなベネフィットをもたらすかを明らかにしていく。今回は前回に引き続き、エンタープライズサーチのこれまでの役割と位置づけについて振り返る。

応用の幅を広げるエンタープライズサーチ

エンタープライズサーチの状況を変化させるきっかけとなったのは、2000年代中頃にGoogleが自社の検索エンジン（サーチエンジン）を搭載したアプライアンスを法人向けに発売したことだ。このアプライアンスは、企業内データに対してテキスト検索をかけるための仕組みで、相応の注目を集め、エンタープライズサーチの認知度を大きく押し上げた。加えて、このころは、企業の間で広く使われていたメールソフトウェアなどのコミュニケーションツールの検索機能が弱く、それを補完する目的でGoogleのアプライアンスを導入するという動きも出始めていたのである。

ただし、Googleのアプライアンスは決して安価な製品ではなかった。そのため、エンタープライズサーチのシステム導入コストを最小限に抑える目的のもと、オープンソースソフトウェア（OSS）の検索エンジンを使い、自前でシステムを構築するという手法も普及しはじめた。

ここまで読み進まれた方の中には「ビジネス上のデータを全社的に共有して、引き出したいのであれば、エンタープライズサーチの仕組みを使わずとも、データベースにデータをためて参照できるようにすれば良いのではないか」と考える人がいるかもしれない。

確かに、企業で主に使用されているリレーショナル構造のデータベース（SQLデータベース／以下、RDB）を使えば、SQLクエリ（問い合わせ文）を通じて、データベースのテーブルを結合し、必要なデータを取り出すことが比較的簡単に行える。

ただし、時間の経過とともにデータの件数が増え、データベース、あるいはテーブルが大きくなっていくと、クエリに対するレスポンスの性能は低下していく。そして、データの数が数百万件、数千万件の規模に及んだ場合、データベース操作が実施的に行えないような状況になる。しかも、RDBが扱えるのは基本的に正規化された構造化データのみであり、例えば、ドキュメントの全文検索などにRDBを使うことはできない。

それに対して、「Elasticsearch」のようなエンタープライズサーチの仕組みは、非構造化データや時系列データに対応しており、データの件数が数百万件、あるいは数千万件に及んでも、数秒で検索したり、集計したりすることができる。しかも、インデックスやドキュメント、フィールドなどを作成し、データをプッシュするだけで検索の準備が整うという手軽さもある。

実際、ある企業では、こうしたエンタープライズサーチの仕組みを生かして、数十種類のデータソースを集約している。結果として、数千万件に上るドキュメントの全文検索をリアルタイム（0.1秒）で処理できるようになったという。加えて、この企業では、構造化データや非構造データ、時系列データから成る40億件のデータを使ってエンタープライズサーチのベンチマークテストも行ったが、その結果、検索に要する時間はわずか1秒であったようだ。

今日では、人気の高い大規模ECサイトでも、エンタープライズサーチの仕組みが有効に使われはじめている。こうしたECサイトの場合、繁忙期、あるいは特売キャンペーンの期間中に商取引のトラフィックが大量に発生し、RDBだけではさばき切れなくなる。その問題を解決する手だてとして、大規模ECサイトの間で採用が進んでいるのが、データベースに対する（データの）読み取り操作と更新の操作を分離する「CQRS（コマンドクエリー責任分離）」のアーキテクチャだ。

このアーキテクチャに基づくかたちで、エンタープライズサーチの仕組みを使い「読み取り専用のデータストア」を構築し、下の図のようにRDBと連携させてデータ更新の処理を適宜行うようにする。こうすることで、商品の点数が数千万点になっても、大量のトラフィックを難なくさばき、当該のサイトで買い物をする顧客に良質な体験を提供することができるのである。