Amazon OpenSearch Service

解決する課題

大量のドキュメントやログを「キーワードであいまい検索したい」「直近のエラーを横断的に集計して可視化したい」という要求は多く、リレーショナルデータベースのLIKE検索やバッチ集計では速度・柔軟性ともに限界があります。OpenSearch/Elasticsearch を自前で立てると、ノード構成・シャード設計・バージョンアップ・スナップショット・ノード障害時の復旧まで運用負荷が重くのしかかります。Amazon OpenSearch Service なら：

• 全文検索エンジンのクラスタ構築・パッチ適用・スケーリング・バックアップをAWSが代行する
• アプリのログ、メトリクス、トレースなどを取り込み、検索と分析、可視化までを一貫して扱える
• マネージドの可視化ツール OpenSearch Dashboards がそのまま付属し、ダッシュボードを素早く作れる

商品検索やサイト内検索といった全文検索の用途と、運用ログ・セキュリティログを集約して分析する用途（オブザーバビリティやSIEM的な使い方）の両方で使われます。

主要概念と用語

• ドメイン: OpenSearch Service における1つのクラスタの単位。ノード・設定・エンドポイントをまとめたもの（プロビジョンド構成の場合）
• インデックス: ドキュメントの集合。RDBのテーブルに近い概念で、検索や集計の対象となる
• ドキュメント / フィールド: インデックスに格納する1件のデータと、その中の各項目。JSON形式で保持される
• シャード: インデックスを分割した実体。データを複数ノードに分散して並列処理するための単位
• レプリカ: シャードの複製。可用性の向上と読み取りスループットの確保に使う
• ノードの役割: データを保持するデータノード、クラスタ管理を担う専用マスターノードなどに役割を分けられる
• OpenSearch Dashboards: インデックスのデータを検索・集計し、グラフやダッシュボードとして可視化するUI
• サーバーレス: ノードやシャードを意識せず、需要に応じて容量が自動で伸縮する提供形態

仕様・制限・クォータ

• 提供形態は大きく、ノード構成を自分で決めるプロビジョンド（マネージドクラスタ）と、容量管理を任せるサーバーレスに分かれる
• プロビジョンドではインスタンスタイプ・ノード数・ストレージを選び、検索負荷やデータ量に合わせてサイジングする
• 1ドメインあたりのノード数やシャード数、1アカウントあたりのドメイン数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• データの耐久性確保のためにスナップショットを取得でき、自動・手動のいずれにも対応する
• バージョンは段階的に更新され、互換性を保ったアップグレード経路が用意される

内部の仕組み

OpenSearch は転置インデックスを中心とした検索エンジンです。テキストを解析（トークン化）して語ごとに「どのドキュメントに出現するか」を索引化しておくため、キーワード検索や全文検索を高速に処理できます。

• インデックスは複数のシャードに分割され、各シャードが複数ノードに分散配置される。これにより並列にインデックス作成・検索を行う
• 各シャードにレプリカを持たせると、ノード障害時もデータを失わず、読み取りを複数ノードへ振り分けられる
• 専用マスターノードを置くとクラスタ管理の安定性が増し、データノードの障害が全体に波及しにくくなる
• 複数のアベイラビリティゾーンにノードを分散配置する構成（Multi-AZ）にすると、ゾーン障害時にも可用性を保てる

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

• 用途で提供形態を選ぶ: 安定した定常負荷で細かくチューニングしたいならプロビジョンド、負荷が読みにくく運用を任せたいならサーバーレス
• 可用性を確保する: 本番ではMulti-AZ配置とレプリカを設定し、専用マスターノードでクラスタを安定させる
• シャードサイズを適正化: 1シャードを大きくしすぎず小さくしすぎず、データ量に見合った数にする
• 時系列データはインデックスを分割: ログなどは日付単位などでインデックスを分け、古いものは保存階層を移すか削除して肥大化を防ぐ
• 取り込みパイプラインを併用: ログはマネージドの取り込み機能やエージェント経由でバッファリングしながら投入し、急なスパイクを吸収する
• ストレージ階層の活用: アクセス頻度の低い古いデータは、より安価なストレージ階層へ移すことでコストを抑える

運用・監視

• CloudWatch でクラスタの健全性（緑・黄・赤の状態）、CPU・メモリ・ストレージ使用率、検索やインデキシングのレイテンシなどを監視する
• ストレージ使用率やJVMメモリ圧迫は性能劣化やノード停止の前兆になりやすく、しきい値を決めてアラートを設定する
• スナップショットを定期取得し、誤削除やインデックス破損からの復旧手段を確保する
• スロークエリやエラーは監査ログ・アプリケーションログとして出力し、CloudWatch Logs などへ送って調査できる
• バージョンアップやノード追加といった変更は、影響範囲を見極めて計画的に実施する

コスト

• プロビジョンドでは主にインスタンスの稼働時間とストレージ容量に対して課金され、ノードを止めない限り待機コストが発生する
• 安定稼働が前提の場合は、リザーブドインスタンス相当の割引購入で稼働コストを抑えられる
• サーバーレスでは消費した計算リソースとストレージ量に応じた課金となり、容量管理の手間が減る一方で負荷次第ではコストが変動する
• スナップショット保管やデータ転送など、付随する費用も別途見込む
• 古いデータを安価なストレージ階層へ移す、不要なレプリカを減らすなどで全体のコストを最適化できる

セキュリティ

• ドメインをVPC内に配置すると、インターネットに公開せずプライベートにアクセスできる
• アクセス制御はIAMポリシーと、OpenSearch内部のきめ細かなアクセス制御（ロールやインデックス・フィールド単位の権限）を組み合わせて行える
• 保存データはKMSの鍵で暗号化でき、通信はTLSで保護される
• Dashboards へのログインに認証を組み込み、利用者を識別したうえで権限を割り当てられる
• 操作の監査ログを有効化し、誰がどの検索・変更を行ったかを追跡できる

Well-Architected の観点

• パフォーマンス効率: シャードとレプリカの設計、適切なインスタンス選定で検索とインデキシングの性能を引き出す。負荷が読みにくいならサーバーレスで自動伸縮に任せる
• 運用上の優秀性: パッチ・スナップショット・スケーリングをマネージドに任せ、メトリクスとアラートで異常を早期に検知する
• 信頼性: Multi-AZ配置とレプリカ、定期スナップショットで可用性と復旧性を確保する
• セキュリティ: VPC配置、最小権限、保存・通信の暗号化、監査ログの活用
• コスト最適化: 負荷特性に合った提供形態の選択、ストレージ階層化、不要なレプリカ削減

試験で問われるポイント

関連サービス・比較

S3上のデータに標準SQLで問い合わせる Amazon Athena とよく対比されます。どちらも「貯めたデータを調べる」用途ですが、全文検索や低レイテンシのダッシュボードか、その場限りのSQL分析かで選びます。

ハンズオン / CLI例

# プロビジョンドのドメインを作成（Multi-AZ＋専用マスターの構成例）
aws opensearch create-domain \
  --domain-name my-search \
  --engine-version "OpenSearch_latest" \
  --cluster-config InstanceType=r6g.large.search,InstanceCount=3,ZoneAwarenessEnabled=true,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3 \
  --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=100 \
  --node-to-node-encryption-options Enabled=true \
  --encryption-at-rest-options Enabled=true

# ドメインの状態とエンドポイントを確認
aws opensearch describe-domain --domain-name my-search \
  --query "DomainStatus.{Endpoint:Endpoint,Processing:Processing,Created:Created}"

# 取得したエンドポイントへドキュメントを投入し、検索する（署名付きHTTPSで実行）
# 例: curl -XPUT "https://<endpoint>/products/_doc/1" -d '{"name":"keyboard"}' ...
# 例: curl "https://<endpoint>/products/_search?q=name:keyboard" ...