「Azure Search」は2015年に提供が開始された、Azureの全文検索サービスだ。検索対象のデータソースを指定しアプリケーションにクエリー文を追加するだけで、多機能な全文検索が利用できるという容易さが売りである。加えて、自然言語アナライザーや高負荷に対応可能な拡張性を備え、検索クエリーのチューニングや高可用性構成での運用が可能であるなど、大規模システムにも適用できる。
全文検索エンジンを選定する場合、現時点では選択肢として米Elasticが開発するオープンソースソフト（OSS）の「Elasticsearch」と、OSSの「Apache Solr」が挙がることが多い。どちらも内部にインデックス格納用のデータストアーを保持し、日本語などの自然言語アナライザーを用いた全文検索が可能だ。ElasticsearchはNoSQLデータストアーとしての側面を持ち、RESTful APIを用いてJSON（JavaScript Object Notation）ドキュメントを検索できる。Solrは、ファイルサーバーやリレーショナルデータベース（RDB）といった外部のデータストアーのインデックスを生成し、HTTP GETで検索する使い方が一般的だ。
Elasticsearchは、同じElasticの製品である「Logstash（データの収集）」や「Kibana（データの分析・可視化）」と組み合わせてログ分析ツールとして利用されることが多い。Solrは一般に、Webアプリケーションの検索機能としてアプリケーション（AP）サーバーと組み合わせて利用される。
Azure Searchは、Elasticsearchがベースであり、RESTful APIでの検索を備える。ただし、Elasticsearchから大幅に作り替えられており、豊富なインデクサー（クローラー）を持ち汎用性が高い。Solrを知っているエンジニアにとっては、「Azure向けのFess（オールインワンのSolrパッケージ）」というとイメージしやすいだろう。
2017年8月現在、国内では西日本リージョンのみで提供しており、東日本リージョンでは提供してない。ただし西日本と東日本リージョンを結ぶバックボーンネットワークは容量が大きく、東日本リージョンのユーザーにとって大きな問題にはならないだろう。
この記事では、最初にAzure Searchの重要な機能、検索機能の構築手順を解説し、そのうえでAzure Searchを使った実用性の高いアーキテクチャーパターンを示す。
Officeも対象のインデクサー
Azure Searchは、検索クエリーを実行する「検索処理」と、データからインデックスを作成する「インデクシング」という大きく二つの処理ブロックで構成されている（図1）。
一般に、全文検索の環境を構築する際に最初のハードルになるのが、対象データのインデクサー（クローラー）の準備だ。データから適切に検索インデックスを生成可能にするまでのハードルの高さは、経験者なら身に染みているだろう。Azure Searchではそのハードルを可能な限り下げるべく多様なインデクサーを装備している。
Azure SQL Databaseや仮想マシン上で稼働するSQL ServerといったRDB、Cosmos DBなどのNoSQLデータベースに加えて、Azure Blob Storageに格納されたPDF、Word、Excel、PowerPointといったOffice文書、HTML、CSV、JSON、プレーンテキスト、これらを含むZIP圧縮ファイルなどを標準でサポートする。具体的な構築手順は後述するが、接続先を指定するだけでインデックスの作成が可能だ。
設定によっては、インデックス更新データを自動作成できる「自動インデクサー」という機能も備える。
構文解析にLuceneを選べる
アプリケーション側から実行される検索処理の機能も多い。検索ボックスでの入力を補完するサジェスト機能、キーワードへのヒット数をカテゴリーごとに事前に集計しておくファセット機能、検索結果の絞り込みを行うフィルター機能、結果のソートやページングの機能を提供する。
自然言語構文解析については、複数のアナライザーから選択できるアーキテクチャーになっている。現時点ではApache LuceneアナライザーとMicrosoftアナライザーが選択可能だ。
前者のLuceneアナライザーはElasticsearchやSolrで採用されているもので、35の言語に対応する。後者のMicrosoftアナライザーはBingやOffice製品で利用されているもの。50言語に対応する。日本語環境では、日本語処理の洗練度や他製品とのチューニングノウハウの継承性から、実プロジェクトではLuceneの利用を推奨している。
検索結果のスコアリングも可能
Azure Searchでは検索精度向上のために対象ドキュメントのスコアリングとランク付けの機能も備える。
スコアリングとは、例えば検索対象ワードがHTMLの＜H1>などの見出しに含まれていたり、繰り返し使われたりしていれば高いスコアを付け、本文中に1回だけ使われているなら低いスコアを付ける、といったアルゴリズムで検索結果を評価する仕組みだ。標準のTF-IDF（Term Frequency - Inverse Document Frequency）アルゴリズムに加え、TAGブーストやDistanceブーストなどのスコアリングプロファイルを指定したチューニングも可能である。
チューニングの基礎データとして、検索待ち時間やQPS（1秒当たりの検索クエリー数）といったメトリクスに加え、ユーザーが発行した検索クエリーや検索結果の選択であるクリックイベントを収集し分析することが可能だ。
こうした機能を使うことにより、ユーザーの行動情報を収集・分析したうえでチューニングする、という検索エクスペリエンスの改善サイクルを、他のソフトやサービスを使わずにAzure Searchだけで回すことができる。
12パーティションまでスケール
Azure Searchは、インデックスサイズとクエリー負荷に応じてスケールアップとスケールアウトを組み合わせたクラスター構成を組むことができる。例えば検索対象のドキュメント数でスケールさせるなら、12パーティションの並列構成、最大1億4400万ドキュメントまで拡張できる。
クラスター構成を検討する際に注意すべき点が二つある。
一つはダウンタイムを最小化する高可用性（HA）構成を組むには、レプリカを3並列で構成する必要があることだ。
もう一つはCosmos DBやSQL Databaseなどと違い、地理冗長（GRS）に対応していないこと。そのため、リージョン横断の冗長構成を組む場合は、各リージョンでインデクシングを行う必要がある。
料金について簡単に説明する。料金プランは下位の価格レベルから、FREE、BASIC、STANDARD S1、STANDARD S2、STANDARD S3の5段階で構成される。このうち無料のFREEはストレージ容量が50MBしかなく、実質的に検証にしか使えないだろう。
BASIC、STANDAD S1、S2、S3はストレージ容量、ドキュメント数、インデックス数、パーティション数が異なり、上位プランほどキャパシティーが大きい。BASICとSTANDARDの最大の違いはパーティション数だ。BASICは1個でありスケールアウトできない。STANDARDは三つとも12パーティションまで拡張可能だ。
BASICのオンライン料金（西日本リージョンのオンライン価格、税別）は、最小構成で1時間当たり13.57円、月額換算すると約1万円であり、3並列のHA構成にするとその3倍である。
