Elasticsearchの用途と、知っておくべきこと

はじめに

Foundは、Elasticsearchのさまざまなユースケースを多数確認しています。よく「Elasticの典型的なお客様像はどのようなものか」と聞かれますが、「大量のクラスターを操作するよりも、何かを構築することに時間を使いたい方々です」と答える以外に明確な答えはありません。これまで、Elasticsearchがさまざまな素晴らしいユースケースで使用され、またいくつかの驚くべきユースケースにも使用されるのを見てきました。

Elasticsearchはまだ比較的新しく、お客様は特定のプロジェクトでElasticsearchを使いはじめ、その後、ログや分析用にクラスターを追加していく傾向があります。

一般的な開発過程は、Webサイトやドキュメントの集合を対象としたシンプルな検索機能を構築することから始まります。その後、ファセットナビゲーション、スペルチェック、「もしかして〜ですか？」の応答などが追加されていきます。あいまい検索が必要になったり、オートコンプリートや「逐次検索」機能が追加される場合もあります。関連性が重要であることから、最終的にはユーザー本人、その場所、人間関係に基づくより高度な順位付けスキームが追加される可能性が高くなります。また当然、ユーザーの実際の用途を把握するために使用状況を記録する必要があり、さらにメトリックを保存して、すべてのパフォーマンスが良好なことを確認する必要もあります。

Elasticsearchはこれらすべてを含むさまざまな用途で使用できますが、それぞれの用途に応じて複雑度やリソース要件は異なります。

まずは検索（と集計）

当然のことながら、Elasticsearchはたいてい「検索」機能を実装するために利用されます。検索機能とは、一般には虫眼鏡アイコンが付いた入力ボックスがあることを表します。「検索」の意味が曖昧になる可能性があるため、ここではさまざまな種類の検索を「シンプルな検索」、「あいまい検索」、「集約」などと呼ぶことにします。シンプルとは、単純なmatchクエリで達成できるものを表します。

Elasticsearchで実現できるタスクのうち、リソース負荷が特に低いタスクの1つがシンプルな検索であることは、多くの人に驚きを持って受け止められます。あいまい検索ではない通常のmatchクエリで上位10件の結果を得るだけでよければ、数千万件のドキュメントの集合が対象でも、安価なハードウェアで1秒あたり数百件の検索に対応できます。ただし、あいまい検索やファセットナビゲーションが要件に加わると、かなりのCPUとメモリーが必要になります。

モダンな検索インターフェイスでは、ユーザーが検索結果の分布をすばやく把握できる機能など、何らかのファセットナビゲーションが求められるのが一般的です。特定の作者による、特定の価格帯の、特定の評価の本が何冊あるかなどの疑問に答える検索は、Elasticsearchの集約機能を使用して実装され、さまざまな形で提供されます。用語、数値範囲、日付範囲、地理的な距離、その他多くの切り口で集約できます。

何百万件ものドキュメントをふるいにかけて一致を見つけるほうが、さまざまな方法で一致を数えて集約するよりも労力が少ないというのは、多くのユーザーの直感に反することです。とはいえ、「これらの条件に一致（および最も関連）する10件のドキュメントはどれか」という情報検索の問題と比較すると、集約は高コストです。最適なドキュメントを見つけるためにスコアを付ける場合、Luceneでは"このドキュメントセットは、これらの他のドキュメントが一致するすべての項目に一致していないため最適ではないと思われるため、単純にスキップする"というテクニックが使用されます。 フィルタリングする際、Elasticsearchはフィルターキャッシュを大いに活用します。ElasticsearchとLuceneは可能な限り作業を軽減することに優れていますが、集約においては常にすべての一致項目をカウントする必要があります。

「ゼロからのElasticsearch」では、転置インデックスのしくみや、辞書とポスティングリストを使用してシンプルな検索を行う方法について解説しました。この記事と、テキスト分析についての記事を読めば、検索を行う際にテキストを正確に処理することが非常に重要な理由を明確に理解できるはずです。「Sizing Elasticsearch」（Elasticsearchのサイジング」と「Elasticsearch in Production（Elasticsearchの運用）」の記事は、どちらも想定されるメモリー使用量について詳細に解説しています。

分析

分析のワークロードでは、一般的に項目をカウントし、データを要約します。このデータは、ビッグデータ（その定義はともかく）を含むさまざまなデータの可能性があります。これらのワークロードはElasticsearchの集約機能に依存しており、集約は通常、Kibanaのようなツールによって生成されます。

すでに述べたとおり、これらの集約はCPUとメモリーの両方において、かなりコストがかかる場合があります。メモリーの要求が大きくなる理由は、Elasticsearchが提供されたドキュメントに対してすばやく値を検索する必要があり、これを行うにはすべてのドキュメントのすべてのデータをメモリーの"フィールドキャッシュ"に読み込む必要があるためです。この問題は"ドキュメント値"を使用することで軽減できる可能性があります。ドキュメント値は、ドキュメントをインデックスする前にマッピングで有効化する必要があります。

さらに、分析検索は通常タイムスタンプ付きのデータに対して実行されます。このようなデータは、日次または月次のインデックスに区分することが理にかなっています。時間単位あたり1つのインデックスを設定すれば検索領域を削減し、古いデータをクリーンアップしてアーカイブするのが容易になります。

あいまい検索

あいまい検索は、スペルエラー（誤字）に寛容な検索機能です。たとえば、Levensteinと検索してもLevenshteinが見つかります。あいまい検索に関する記事では、あいまい検索の使用方法とそのしくみについて詳しく解説しています。

あいまい検索は簡単に有効化でき、"再現率"を大いに強化できますが、実行にかなりのコストがかかる場合もあります。デフォルトでは、入力された用語がフィールドあたり50件の用語（それぞれ、ORを使って列挙したもの）に書き換えられます。これをmulti_fieldと組み合わせると、書き換えられたクエリの結果の用語が組み合わせ爆発を起こす可能性があります。

本番運用に移行する前に、検索機能の変更と改良を現実的なデータ量でテストすることが重要です。このことはfuzzinessパラメーターを追加する場合に特に当てはまります。有効にするのは簡単ですが、検索のコストが桁違いに高くなるためです。

あいまい検索はCPUに負荷がかかります。追加する際は注意する必要があり、すべてのフィールドに追加することはおすすめしません。

自動入力とインスタント検索

ユーザーの入力中の検索には多くの形態があります。たとえば単純に既存のタグを提案する場合、検索履歴に基づいて検索を予測する場合、すべての（スロットルされた）キー操作に対してまったく新しい検索を行う場合などがあります。

Elasticsearchには、これらの機能の構築を支援するprefixクエリ、match_phrase_prefix、nグラムのインデックス、各種入力予測といったさまざまな機能が多数用意されています。

このような検索は、遅延の影響を非常に受けやすくなります。"インスタント"と感じられなくなるしきい値は、一般に100ミリ秒と考えられています。ほぼすべてのキー操作に対して検索を行うことは、検索スループットがかなり高くなることも意味します。そのため、検索が安価でこれらのインデックスがメモリーに収まることが重要です。

Googleのように、検索用語を自動入力しながら、最も可能性の高い完全な検索の結果を表示することは、検索における2つの個別の問題としてとらえる必要があります。以前の検索を自動入力する場合に検索するデータ量は、検索されるコンテンツの量よりもずっと少なくなります。そのため、すべてをメモリー内に収め、あいまい検索に対応するのは難しくありません。自動入力の検索は、全文検索よりもかなり検索の負荷がかかるため、2つの問題を（たとえば完全に異なるElasticsearchクラスターに）分けると、個別に拡張することも可能になります。

Soundcloudが検索機能を改良した際は、検索用語の提案に多くの労力を費やしました。この機能を適切に実装したことで、検索の精度が向上しただけでなく、全文検索を支えるインフラストラクチャーの負荷を大幅に削減することもできました。ユーザーの検索対象は通常、ジップ分布に従っています。つまり、上位10%の検索が検索量の90%を占めているのが一般的です。そのため、最適な検索用語の提案の結果はいずれもすでに（アプリケーションレイヤーに）キャッシュされている可能性が高く、"即座に"表示できます。

Soundcloudの検索用語の提案の背後にある設計の多くは、Elasticsearchの入力予測とつながっています。ミュアーとウィルノアーによる素晴らしいプレゼンテーション「Query Suggestions with Lucene（Luceneを利用するクエリの提案）」をぜひご覧ください。

マルチテナンシー

通常、お客様やユーザーはそれぞれ個別のドキュメントの集合を保有しており、ユーザーは自分の保有するドキュメント以外は決して検索できません。多くの場合、このことは各ユーザーが独自のインデックスを保有する設計へとつながります。

これはたいていの場合、インデックスが多すぎるという事態を招きます。ユーザーごとのインデックスが実装されているほとんどのケースでは、実際は1つの大規模なElasticsearchインデックスのほうが優れています。小規模なインデックスが大量にあると、次のような重大な欠点を招きます。

• メモリーのオーバーヘッドが無視できなくなります。小規模なインデックス数千件もあるような状況は、大量のヒープ領域を消費します。ファイル記述子の数も爆発的に増えます。
• 多くの重複が発生する可能性があります。転置インデックスのしくみとLuceneがセグメント内で記述や圧縮を行う方法を考慮してください。
• スナップショット/復元は現在シリアルプロセスであり、インデックスあたりのオーバーヘッドが発生します。何千件もの小規模なインデックスのスナップショットを作成するのは、数件の大規模なインデックスのスナップショットを作成するよりも、桁違いに長い時間がかかります。

「Sizing Elasticsearch（Elasticsearchのサイジング）」には、シャーディングとパーティショニング戦略についての詳細と、多くの参照情報が記載されています。最適ではないインデックス設計のアプリケーションを修正するのは非常に手間がかかるため、さまざまなアプローチを理解するのに時間をかける価値は十分にあります。

マルチテナントアプリケーションでは、ユーザーごとに1つのインデックスを作成することはおすすめできません。

スキーマフリー/ユーザー定義のスキーマ

複数の個別のお客様がいることに関連して、異なるユーザーがまったく異なるドキュメントを保持しているユースケースもよく見受けられます。たとえば、ユーザーアンケートをサービスとして提供している場合、それぞれのアンケートにはまったく異なるフィールドがあるでしょう。

多くの場合、このことはElasticsearchの"動的マッピング"を使用することにつながり、Elasticsearchはスキーマレスであると宣伝されることがあります。しかし、Elasticsearchはその裏でマッピングを作成しており、これが大きくなりすぎると"マッピング爆発"につながり、問題となる可能性があります。代わりに、ドキュメント内の値を個別のフィールドではなく、値のままにすることが重要です。詳細については、「Key/Value Woes（キー/値の問題）。

Elasticsearchにはインデックステンプレート、動的テンプレート、マルチフィールドなど、汎用性に優れたマッピング機能があります。ぜひご利用ください。

マッピングを使用しない場合でも、Elasticsearchが作成するマッピングを把握しておきましょう。

ユーザー定義の検索

ユーザー定義のスキーマと関連することが多いのが、エンドユーザーがカスタムフィルター、スコアリング、集計を利用して独自の検索を定義できるようにするニーズです。一般的なアプローチの1つは、検索リクエストを特定のインデックスに制限したり、フィルターを使用してユーザーのクエリをまとめたりすることです。

このようなことを行った場合でも、カスタム検索リクエストを定義できる場合にはユーザーが大混乱を引き起こすことがあります。たとえば、ユーザーがCPU負荷の高い、メモリーを圧迫する、あるいは、Elasticsearchのクラッシュを招くような検索を定義することがあります。これらのトピックについては、「Six Ways to Crash Elasticsearch（Elasticsearchのクラッシュを招く6つの要因）」と「無料の暗号化とユーザー認証で、Elasticsearchクラスターを安全に保つ」を参照してください。

ユーザー定義の検索リクエストには注意してください。

クローリングとドキュメントの処理

Elasticsearchにデータを取り込む方は多数あります。

"リバー"はElasticsearchの概念の一種で、データベース（JDBC経由）、メッセージキュー、Twitterストリーム、Webサイトのクローリングなどのソースからデータを取り込むためのものです。このアプローチは、はじめは比較的シンプルですが、すぐに拡張したり本番環境で運用したりするのが困難になります。このようなことからリバーは非推奨となっており、ユーザーはElasticsearch外で問題の解決を図る必要があります。Logstashはより多くのシステムに対応しており、多くのリバーの代わりを務めることができます。カスタムアプリケーションについては、Elasticsearchにデータを同期したりElasticsearchドキュメントを用意したりするうえで多くの課題があり、リバーのようなシンプルで一般的な方法では十分に対応できません。クローリングについては、ユーザーはScrapyとNutchの両方をElasticsearchと組み合わせて使用しています。

これに関連するのがWord文書やPDFなどのドキュメントを、Elasticsearchでインデックスできるプレーンテキストに変換処理することです。Elasticsearch内でこの変換に使用できるものとしては、"マッパーアタッチメント"のプラグインがあります。このプラグインは便利ですが、ドキュメントの変換はElasticsearchに送信する前に行うことをおすすめします。これにより、ドキュメントの変換および調整の方法を最大限に制御できます。このようなドキュメント変換は、通常"コンテンツ調整"の"ドキュメント/テキスト処理パイプライン"における最初のステップとなります。Elasticsearchに送信するドキュメントは、この"コンテンツ調整/準備"の結果であり、最終的なテキスト処理とインデックスはElasticsearchが行います。ドキュメントの変換はかなりCPUに負荷がかかりますが、容易に並行処理が可能です。Elasticsearchではインデックスと検索に時間をかけ、ドキュメントの変換は"アップストリーム"のクライアントに行ってもらうことをおすすめします。

Elasticsearchには処理済みのデータをプッシュし、データをElasticsearchからプルしたりElasticsearch内で処理したりしないようにします。

まとめ

Elasticsearchについて学ぶことはたくさんあり、何を学ぶ必要があるのかを把握するのが困難な場合もあります。

この記事では、一般的なユースケースを多数紹介し、これらすべてについて認識すべき重要な項目について解説しました。皆さまがご自身のニーズに関連する新しい情報を習得でき、Elasticsearchアプリケーションの本番移行に近付くことができたのなら幸いです。