Elasticsearch は全文検索エンジンの定番で、Elastic Cloud はそのマネージド版だ。「RDB の検索では役不足になったとき」に登場するツールで、逆に言えばそこに至るまでは導入しなくてよい。
いつ Elasticsearch が必要になるか
数千件程度のデータを検索したいだけなら、RDB の LIKE や FULLTEXT インデックスで十分に足りる。Elasticsearch が効いてくるのは、データ量が大きく、日本語の表記ゆれや形態素解析を踏まえた検索精度が求められ、ファセット（絞り込み件数の集計）をリアルタイムに返したい、という条件が重なったときだ。サイト内検索や大量ログのリアルタイム分析（ELK スタック）が代表例になる。
近年はベクトル検索（kNN / ANN）も実装され、全文検索とセマンティック検索を同じインデックスで扱える。RAG の検索基盤として、キーワード一致と意味的近さを組み合わせたハイブリッド検索を組める。
運用とコストのトレードオフ
セルフホスト版（OSS）は無料だが、ノードの冗長化・スナップショット・バージョンアップといった運用負荷が丸ごと自分に乗る。Elastic Cloud はリソースサイズ × 時間の従量課金で、その運用をお金で買う形になる。検索基盤の運用に専任を置けないなら、マネージド版の方が結果的に安いことが多い。
スケール時に効いてくる落とし穴
導入時のつまずきはマッピング設計だ。日本語アナライザの設定や項目型の指定を後から変えるとインデックスの再構築が要る。最初の設計で精度の大枠が決まる。
スケールしてから顕在化するのがシャード設計とメモリ管理だ。インデックスを細かく切りすぎるとシャードが乱立してオーバーヘッドが増え、逆に巨大な単一インデックスは再配置が重くなる。ヒープメモリの上限も性能に直結するため、データ量の伸びを見越したノードサイジングを最初に握っておかないと、運用中盤で苦しくなる。
日本語検索はアナライザー設定がすべて
Elasticsearch は標準設定のままだと日本語を適切に分割できず、期待した検索結果にならない。形態素解析（kuromoji）や N-gram を用いたアナライザーを設定して初めて実用になる。さらに、表記ゆれの吸収（全角半角、カタカナひらがな）、同義語辞書、ユーザー辞書による固有名詞の登録まで含めて、検索品質は設定の作り込みで決まる。「入れれば検索できる」製品ではない。
既存インデックスのアナライザー設定は後から変更できません。設定を変えるにはインデックスを作り直してデータを入れ直す必要があります。データ量が大きいほどこの作業は重くなるため、エイリアスを使って新旧インデックスを切り替えられる構成にしておくと、無停止で入れ替えられます。
検索を止めないための冗長性
検索がサービスの中核機能なら、クラスタの障害がそのまま機能停止になる。マネージドサービスを使う理由の大半はここにあり、ノードの冗長化やバックアップを自前で設計せずに済む。ただしマネージドでも設定次第で単一障害点は作れるため、可用性の要件に応じたノード構成を選ぶ必要がある。コストと可用性はここで直接トレードオフになる。