Amazon CloudSearch

解決する課題

ECサイトの商品検索、ドキュメント管理、社内ポータルのサイト内検索など、「キーワードであいまい検索したい」「ヒット件数を絞り込みながら探したい」という要求は多くのアプリに共通します。これをリレーショナルデータベースのLIKE検索だけで実装すると、表記ゆれや日本語の分かち書きへの対応が難しく、件数が増えると速度も落ちます。一方で検索エンジンを自前で立てると、サーバー構築・スケーリング・冗長化といった運用負荷が重くのしかかります。Amazon CloudSearch なら：

• 検索エンジンのサーバー構築・スケーリング・冗長化をAWSが代行する
• ドキュメントをアップロードするだけで、全文検索・ハイライト・候補補完・ファセット絞り込みといった機能を使える
• トラフィックやデータ量の増加に応じて、検索ドメインが自動でスケールする

検索エンジンの専門知識がなくても、アプリに検索機能を比較的短期間で組み込めるのが特徴です。

主要概念と用語

• 検索ドメイン: CloudSearch における検索機能の単位。ドキュメントの集合・インデックス設定・検索エンドポイントをまとめたもの
• ドキュメント: 検索対象となる1件のデータ。JSON や XML 形式でアップロードし、各項目がフィールドとして格納される
• インデックスフィールド: ドキュメントの各項目をどう扱うかの定義。テキスト・数値・日付などの型と、検索可・返却可・ソート可といった属性を指定する
• ファセット: カテゴリやブランドなどの軸ごとに件数を集計し、絞り込み候補として提示する機能
• 検索インスタンス: 検索処理を担うリソースの単位。データ量と負荷に応じてタイプ数や台数が変化する
• 検索エンドポイント / ドキュメントエンドポイント: 検索クエリを送る先と、ドキュメントをアップロードする先のそれぞれのURL
• サジェスト（候補補完）: 入力途中の文字列から検索候補を返し、入力支援を行う機能

仕様・制限・クォータ

• ドキュメントは JSON または XML のバッチとしてアップロードし、インデックスへの反映は非同期で行われる
• インデックスフィールドには型（テキスト・リテラル・数値・日付・位置情報など）と属性を設定でき、定義を変更した場合はインデックスの再構築が必要になる
• データ量と検索負荷に応じて検索インスタンスのタイプと台数が変化し、必要に応じて事前にスケールさせることもできる
• 1アカウントあたりの検索ドメイン数や、1ドメインあたりのインスタンス数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• 検索クエリでは全文検索に加え、ファセット集計・ソート・ハイライト・サジェストなどを利用できる

内部の仕組み

CloudSearch は転置インデックスを中心とした全文検索の仕組みを提供します。アップロードされたテキストを解析（トークン化）し、語ごとに「どのドキュメントに出現するか」を索引化しておくことで、キーワード検索を高速に処理します。

• アップロードしたドキュメントのバッチは非同期に処理され、インデックスへ反映されてから検索結果に現れる
• データ量や検索負荷が増えると、CloudSearch が検索インスタンスを追加・スケールアップして処理能力を確保する
• 可用性のために検索インスタンスを複製する構成をとることができ、これにより負荷分散と冗長性を両立させる
• 検索とドキュメントのアップロードは別々のエンドポイントに分かれ、それぞれの役割に応じてアクセスする

設計パターン / ベストプラクティス

• 検索に必要な項目だけをインデックス化: すべての項目を検索対象にせず、検索・絞り込み・ソートに使うフィールドを見極めて定義する
• ファセットで絞り込み体験を高める: カテゴリ・価格帯・ブランドなどをファセットに設定し、件数を見せながら段階的に絞り込めるようにする
• アップロードはバッチでまとめる: ドキュメントの更新は1件ずつではなくバッチにまとめて投入し、反映効率を高める
• 再インデックスを見越した設計: フィールド定義の変更が再構築を伴う点を踏まえ、初期のスキーマ設計を丁寧に行う
• 新規構築では用途を見極める: ログ分析や可視化、複雑なクエリまで求める場合は OpenSearch Service を、シンプルなサイト内検索に絞るなら CloudSearch を、という観点で選ぶ

運用・監視

• CloudWatch で検索リクエスト数・インデックス済みドキュメント数・検索インスタンスのリソース状況などを監視する
• 検索レイテンシやエラー率を監視し、しきい値を超えた場合にアラートを出すよう設定する
• ドキュメントのアップロード結果（成功・失敗件数）を確認し、反映漏れがないかを点検する
• フィールド定義の変更や再インデックスは、検索品質への影響を見極めて計画的に実施する
• CloudTrail でドメインの設定変更などの操作履歴を追跡できる

コスト

• 主に稼働している検索インスタンスのタイプと台数に対して課金され、ドメインを稼働させている限り費用が発生する
• データ量や検索負荷が増えてインスタンスが追加・スケールアップすると、その分コストも上がる
• ドキュメントのアップロード（バッチ処理）やデータ転送など、付随する費用も別途見込む
• 不要になったドメインは削除し、検証用ドメインを稼働させたままにしないことで無駄なコストを防ぐ
• 検索対象とするフィールドを絞ることでインデックスの規模を抑え、必要なインスタンス容量を小さくできる

セキュリティ

• 検索エンドポイントとドキュメントエンドポイントへのアクセスは、IAMポリシーやアクセスポリシーで制御できる
• 通信はTLSで保護し、検索クエリやアップロードを暗号化された経路で行う
• 検索結果に機微な項目を含めないよう、返却対象のフィールドを設計段階で絞る
• CloudTrail でドメイン設定の変更履歴を記録し、誰がどの操作を行ったかを追跡できる
• アプリ側で利用者の権限に応じた検索範囲の制御を行い、見せてよい結果だけを返すよう実装する

関連サービス・比較

同じく全文検索を担う Amazon OpenSearch Service とよく対比されます。どちらも検索機能を提供しますが、シンプルなサイト内検索を手早く組み込むか、検索に加えてログ分析・可視化や高度なクエリまで扱うか、で選び分けます。新規構築では OpenSearch Service を選ぶケースが増えています。

ハンズオン / CLI例

# 検索ドメインを作成する
aws cloudsearch create-domain --domain-name my-search

# インデックスフィールドを定義する（テキスト型の例）
aws cloudsearch define-index-field \
  --domain-name my-search \
  --name title \
  --type text

# 定義を反映するためにインデックスを再構築する
aws cloudsearch index-documents --domain-name my-search

# ドメインの状態とエンドポイントを確認する
aws cloudsearch describe-domains --domain-names my-search \
  --query "DomainStatusList[0].{DocService:DocService.Endpoint,Search:SearchService.Endpoint,Processing:Processing}"

# 取得したエンドポイントへドキュメントを投入し、検索する
# 例: aws cloudsearchdomain upload-documents --endpoint-url https://<doc-endpoint> --content-type application/json --documents docs.json
# 例: aws cloudsearchdomain search --endpoint-url https://<search-endpoint> --query-options ... --query "keyboard"