Amazon OpenSearch本番運用Vol1｜Serverless・ベクトル検索・ログ分析

1. この記事について — なぜマネージド検索基盤を自前で運用するのか

Amazon OpenSearch Service は、オープンソースの OpenSearch（Apache-licensed fork of Elasticsearch）をマネージド形式で提供する AWS の検索・分析プラットフォームです。クラスターの構築・パッチ適用・スナップショット・スケーリングを AWS が担うため、エンジニアはインデックス設計・クエリチューニング・ビジネスロジックに集中できます。

マネージドを選ぶ理由

Elasticsearch をセルフホストする場合、クラスターのノード追加・ローリングアップグレード・スナップショット管理・証明書の更新などのオペレーションが継続的に発生します。Amazon OpenSearch Service ではこれらを AWS が自動化します。

• バージョンアップグレード: コンソールまたは API から数クリックでインプレースアップグレード（ブルーグリーンデプロイ）が可能
• 自動スナップショット: 時間単位で S3 に取得され、ポイントインタイムリストアに対応
• Auto-Tune: クラスターの JVM ヒープ使用量・クエリレイテンシを分析し、インデックス設定を自動最適化
• サービス統合: IAM・VPC・CloudTrail・CloudWatch と AWS エコシステムとのネイティブ統合

このサービスが注目を集める背景には、検索の用途が急速に多様化していることがあります。従来の全文検索に加え、LLM を活用した RAG アーキテクチャのベクトルストア、マイクロサービス化による大規模ログ分析プラットフォームとしても採用が広がっています。1 つのサービスで 3 つのユースケースを扱えることが、AWS における OpenSearch の大きな強みです。

要件別サービス選択マトリックス

どのサービスを選ぶべきか迷ったときのための判断軸を表にまとめます。

ユースケース 1 — 全文検索・アプリ検索基盤

BM25 を使った転置インデックスによる全文検索は、OpenSearch の最も基本的な用途です。N-gram / kuromoji（日本語形態素解析）などのアナライザーを組み合わせることで、日本語のあいまい検索・同義語展開・タイポ補正に対応した検索体験を構築できます。EC サイトの商品検索・ドキュメント管理システム・コンテンツポータルの記事検索など、幅広いアプリケーション検索に活用されています。

ユースケース 2 — ベクトル検索（k-NN）

テキストや画像を embedding モデルでベクトル化し、コサイン類似度や内積で最近傍探索（k-Nearest Neighbor）を行うユースケースです。LLM を活用した RAG（Retrieval-Augmented Generation）アーキテクチャにおけるベクトルストア、類似商品・類似画像の推薦、セマンティック検索（意味検索）などに使用します。OpenSearch は NMSLIB・FAISS・Lucene の 3 つの ANN エンジンを持ち、ベクトル次元数・データ規模・精度要件に応じて選択できます。

ユースケース 3 — ログ分析・Observability

Fluent Bit・Kinesis Firehose・OpenSearch Ingestion 経由で収集したアプリケーションログ・セキュリティログ・インフラログを全文検索し、Dashboards で可視化するユースケースです。CloudWatch Logs では難しい複数サービスにまたがる横断的な全文検索、Anomaly Detection による異常値の自動検知、SIEM（Security Information and Event Management）としてのセキュリティイベント分析に活用されています。

1-1. 本記事のゴール

本記事では、Amazon OpenSearch Service を使った検索基盤の本番運用に必要な設計・構成の知識を体系的に解説します。

§2 ドメイン設計 では、マネージドクラスターを構成するノードタイプ（m6g/r6g/c6g）の選択指針、マルチ AZ による可用性設計、専用マスターノードの役割、プライマリ・レプリカシャード数の決定方法、スナップショット戦略を取り上げます。インスタンスタイプとシャード数の誤りが本番障害の主因となるため、特に丁寧に解説します。

§3 OpenSearch Serverless では、マネージドクラスターと対比しながら Serverless の collection 種別（time-series / search / vector）と OCU（OpenSearch Compute Unit）の容量設計を解説します。scale-to-zero の仕組みと間欠型ワークロードへの適性、コスト比較の観点からマネージドクラスターとの使い分け基準を整理します。

§4 ベクトル検索 k-NN では、Bedrock などの embedding モデルと組み合わせた k-NN ベクトル検索の本番運用に焦点を当てます。NMSLIB・FAISS・Lucene の ANN エンジン選択、インデックス mapping の設計、BM25 全文検索と k-NN を組み合わせるハイブリッド検索まで踏み込んだ設計指針を示します。

§5 と §6 では、ログ分析・可視化基盤を扱います。Fluent Bit・Kinesis Firehose・OpenSearch Ingestion の 3 つの取り込み経路、ISM ポリシーによる時系列インデックスのライフサイクル管理、OpenSearch Dashboards でのダッシュボード構築・アラート・Reporting まで一気通貫で解説します。

§7 と §8 では、OpenSearch Ingestion（マネージド Data Prepper）によるパイプラインと UltraWarm・Cold Storage を活用した階層型コスト最適化を取り上げた後、シャード設計の失敗・Serverless OCU 上限・k-NN メモリ不足など、本番運用でよく直面する詰まりポイントとアンチパターンをまとめます。

1-2. 読者像

本記事の対象読者は、以下のいずれかに当てはまるエンジニアです。

アプリ開発者・プラットフォームエンジニア

EC サイトの商品検索、コンテンツポータルの記事検索、社内ドキュメント検索など、アプリケーション向けの全文検索基盤を自前で構築・運用したい方。「Elasticsearch をセルフホストしていたがオペレーション負荷を下げたい」「クラウドネイティブな検索基盤に移行したい」という方にも役立ちます。

ML エンジニア・データサイエンティスト

RAG（Retrieval-Augmented Generation）や類似画像検索のベクトルストアとして OpenSearch k-NN を直接運用したい方。Bedrock Knowledge Bases のマネージド構成ではカスタマイズが難しい場合の代替設計を探している方。ANN エンジンのチューニングや recall/speed トレードオフを自前でコントロールしたい方。

データ基盤・SRE 担当エンジニア

大規模ログの全文検索・集計・可視化を CloudWatch Logs だけでは賄えず、OpenSearch でのログ分析基盤構築を検討している方。OpenSearch Dashboards によるリアルタイム監視ダッシュボードと Anomaly Detection を活用した可観測性プラットフォームを構築したい方。

前提知識

AWS の基本操作（VPC・サブネット・セキュリティグループ・ロールポリシーの概念）を理解していることを前提としています。OpenSearch または Elasticsearch の利用経験があれば、§2 のクラスター設計を中心に読み進めるとスムーズです。JSON 形式のクエリ DSL（例: GET index/_search {...}）の基本的な読み方を理解していると §4・§5 の理解が深まります。

AWS でのコスト管理の観点から、EC2 インスタンスタイプ間の料金比較に慣れていると §2 のノードタイプ選定で判断がしやすくなります。ドメイン作成の実操作は AWS マネジメントコンソールを使って進められます。Terraform / CloudFormation による自動化は本シリーズの対象外ですが、設定の概念を理解したうえで IaC に落とし込むことは十分可能です。

1-3. 本シリーズの位置づけと既存記事との棲み分け

本シリーズは「OpenSearch を直接運用する検索プラットフォーム」を扱います。類似する AWS サービスとの役割分担を整理しておきます。

Q Business（SaaS 型企業検索）との違い

Q Business は、S3・Confluence・Salesforce など複数のデータソースをコネクタで接続し、自然言語クエリで検索できるターンキー型の企業向け検索サービスです。インデックス設計・クエリチューニング・スキーマ変更を自前でコントロールしたい場合や、アプリケーションに組み込む形の検索 API を構築したい場合は、本シリーズ（OpenSearch 直接運用）が適しています。「RAG のバックエンドを自前構築したい」という要件も OpenSearch が担います。

Bedrock Knowledge Bases（マネージド RAG）との違い

Bedrock Knowledge Bases は、ドキュメントの embedding とベクトルストア（OpenSearch Serverless を含む複数オプション）の管理を自動化するマネージド RAG サービスです。ドキュメントアップロード → embedding → ベクトルインデックス登録 → 検索クエリ応答までをコードなしで実現できます。一方、OpenSearch k-NN インデックスを直接設計・チューニングしたい場合、独自の embedding パイプラインを組み合わせたい場合、または Bedrock Knowledge Bases 以外のパイプラインとベクトルストアを統合したい場合は §4 が参考になります。

CloudWatch Logs との違い

CloudWatch Logs は AWS リソースのログ転送・メトリクス抽出・Logs Insights クエリに強みを持ちます。Lambda・ECS・RDS などの AWS サービスはデフォルトで CloudWatch Logs にログを書き込むため、AWS サービスのオペレーションログを手軽に確認する用途では CloudWatch Logs が最適です。対して OpenSearch は、大規模ログの全文検索・複雑な集計・Dashboards による柔軟な可視化・Random Cut Forest を使った Anomaly Detection に強みがあります。両者を補完的に使い分けることが本番運用の定石であり、§5 ではこの組み合わせ設計を詳しく解説します。

なお、本シリーズで扱うのは「マネージドクラスター型」の OpenSearch Service ドメインです。同じサービス名で提供される「Serverless 型」については §3 で詳しく取り上げます。

マネージドRAG編：Bedrock Knowledge Bases(OpenSearchをKBバックエンドに使う)を読む

2. ドメイン設計 — マネージドクラスターの本番構成

2-1. 前提環境とドメイン構成要素

Amazon OpenSearch Service のマネージドクラスターは「ドメイン」という単位で管理します。ドメインを作成する前に、次の環境要件を確認します。

AWS 環境と対応バージョン

ドメイン作成時の主要設定項目

ドメインを作成する際は以下のパラメータを事前に整理します。

暗号化（保存時）・ノード間暗号化・Fine-grained access control はドメイン作成後に変更できないため、初期設定時に必ず有効化します。

ドメイン構成ノードタイプ

OpenSearch クラスターは用途の異なる複数のノードタイプで構成します。

1. データノード
   インデックスデータの格納とクエリ処理を担当します。インスタンスファミリーは以下の 3 系統が主力です。

具体的なサイズ例を挙げると、日次 50 GB のログを 30 日間保持するクラスター（計 1.5 TB）では m6g.xlarge.search（32 GB RAM）× 6 台程度が出発点になります。k-NN ベクトル検索クラスターでは、ベクトルインデックスがメモリに乗ることがパフォーマンスの前提となるため、r6g.2xlarge.search（64 GB RAM）以上を選択します。実際の選定は §8 の詰まりポイントで補足します。

1. 専用マスターノード（Dedicated Master Node）
   クラスター状態の管理・ノード間のオーケストレーションを担当します。本番環境では 3 台の専用マスターノードを設定することが強く推奨されます。データノードと分離することで、クエリ負荷がクラスター安定性に影響するリスクを排除できます。マスターノードはデータを保持しないため、m6g.large.search など比較的小さいインスタンスで十分です。

データノードが 10 台を超える大規模クラスターでは、マスターノードを 5 台に増やしてクラスター状態管理の負荷分散を検討します。

1. UltraWarm ノード
   参照頻度が低い過去データを低コストで保持するウォームティアです。S3 をバックエンドとして使用し、データノードの約 1/7〜1/10 のコストで運用できます。ログ分析や時系列データの長期保持に有効です（§7 で詳述）。UltraWarm ノードは ultrawarm1.medium.search / ultrawarm1.large.search の 2 サイズのみです。

2. Cold Storage
   UltraWarm よりさらに低コストの最終ティアです。アクセス頻度が月に数回以下のインデックスを移行し、必要時だけ UltraWarm に復元して参照します。コスト感の目安として、ホットデータ（EBS SSD）: UltraWarm: Cold = 10 : 1 : 0.03 程度です。

2-2. マルチAZ・シャード設計

マルチ AZ 可用性設計

本番クラスターは必ず 2 AZ 以上、推奨は 3 AZ で構成します。マルチ AZ を有効にすると、OpenSearch はレプリカシャードを異なる AZ のノードに自動配置し、単一 AZ 障害時もクエリを継続できます。

専用マスターノードは奇数台（3 台または 5 台）に設定します。3 台の場合、1 台が障害を起こしてもスプリットブレインを防止できます。

フェイルオーバーの仕組み

AZ 障害が発生すると、OpenSearch はプライマリシャードを残存ノード上のレプリカシャードへ自動昇格させます。その後、クラスターが回復すると、シャードの再割り当てが自動実行されます。マルチ AZ + レプリカ 1 以上の構成であれば、AZ レベルの障害に対して無停止で運用を継続できます。

シャード設計の基本原則

シャード設計の計算例

日次 10 GB のログを 90 日間保持する場合の計算例を示します。

• 総データ量: 10 GB × 90 日 = 900 GB
• レプリカ込みの実ストレージ（レプリカ 1）: 900 GB × 2 = 1,800 GB
• シャード 1 個あたりの目標サイズ: 30 GB
• 必要プライマリシャード数: 900 GB ÷ 30 GB = 30 シャード

ただし、時系列ログの場合は日次インデックスに分割するため、1 インデックスあたりのプライマリシャード数は ceil(10 GB ÷ 30 GB) = 1 になります。30 日分のインデックスがホットデータとして存在する場合、合計プライマリシャード数は 30 個です。

シャード設計の注意点

プライマリシャード数はインデックス作成後に変更できません（_split / _shrink API による再インデックスが必要）。データの増加見込みと検索パフォーマンスのバランスを考慮して初期設計を慎重に行います。

インデックスを作成する際は settings でシャード数とレプリカ数を明示します。

PUT /my-index
{
  "settings": {
 "number_of_shards": 3,
 "number_of_replicas": 1,
 "index.refresh_interval": "30s"
  }
}

refresh_interval を延ばすと書き込みスループットが向上します。リアルタイム検索が不要なバルクインデックス時は -1（無効化）に設定し、完了後は元の値へ戻すのが一般的なチューニングパターンです。

ログ分析など時系列データを扱う場合は、インデックスをロールオーバー（日次・月次）し、古いインデックスを UltraWarm へ移行する設計が長期コスト最適化につながります（§7 で詳述）。

スナップショットとバックアップ

OpenSearch はデフォルトで時間単位の自動スナップショットを S3 に取得します（保持期間デフォルト 14 日）。カスタムスナップショットリポジトリを追加すると、任意の S3 バケットへの手動スナップショットや、クロスリージョンバックアップが実現します。本番環境では以下を確認します。

• 自動スナップショットが正常に完了していることを定期確認する
• カスタムリポジトリを設定し、長期保管が必要なスナップショットは自動削除対象から外す
• 開発環境へのリストアを事前にテストし、RTO（目標復旧時間）の見積もりを確認する

クラスター監視と CloudWatch メトリクス

Amazon OpenSearch Service は主要なメトリクスを CloudWatch に自動公開します。本番運用で監視すべき主なメトリクスを以下に示します。

ClusterStatus.red アラームを CloudWatch Alarms で設定し、SNS 経由で即時通知を受け取る運用が推奨されます。

2-3. アクセス制御と運用ゴール状態

OpenSearch ドメインへのアクセスは、ネットワーク境界制御とユーザー/権限制御の 2 層で設計します。

ネットワーク境界：VPC 配置

本番環境では、ドメインをパブリックエンドポイントではなく、VPC 内のプライベートサブネットに配置することを強く推奨します。VPC エンドポイントを利用することで、インターネット経由の直接アクセスを遮断し、セキュリティグループで通信元を絞り込めます。

VPC 配置後は、アプリケーション側（EC2 / Lambda / ECS）も同一 VPC または VPC ピアリング経由でアクセスする設計になります。外部ツールとの連携が必要な場合は、IP ベースのポリシーと組み合わせて利用します。

ユーザー・ロール管理：Fine-grained access control

OpenSearch の Fine-grained access control（FGAC）を有効化すると、内部ユーザーデータベースまたは外部 ID プロバイダーーを使ったユーザー単位のロール管理が可能になります。

FGAC が提供する主な機能は以下のとおりです。

サービス間連携のポリシー設計

Lambda や Kinesis Firehose などの AWS サービスから OpenSearch へデータを書き込む場合は、リソースポリシーを用いてサービスプリンシパルを許可します。FGAC と組み合わせる場合は、Lambda に付与した実行ロールを OpenSearch のバックエンドロールにマッピングすることで権限を管理します。この構成により、ハードコードされた認証情報なしにサービス間連携を実現できます。

外部 IdP との統合（SAML）

Dashboards（管理・可視化画面）へのログインに SAML を利用すると、既存の社内 IdP（Okta・Azure AD など）と統合したシングルサインオン運用が実現します。SAML の設定は FGAC 有効化が前提条件です。グループとロールのマッピングを定義することで、IdP のグループ管理が OpenSearch の権限管理と連動します。

SAML 設定の大まかな流れは以下のとおりです。

1. IdP 側で OpenSearch Dashboards を SP（Service Provider）として登録し、メタデータ XML を取得
2. AWS マネジメントコンソールの「Security configuration」→「SAML authentication」でメタデータをアップロード
3. アサーションに含まれるロール属性（roles）を定義し、OpenSearch 内部ロールとマッピング
4. Dashboards にアクセスして IdP ログイン画面にリダイレクトされることを確認

監査ログの取得

本番環境では FGAC と組み合わせた監査ログ（Audit Logging）を有効化することを推奨します。インデックスへの読み書き・管理操作・ログイン試行をすべて記録し、セキュリティインシデント時の追跡を可能にします。監査ログは OpenSearch インデックス（opensearch-security-auditlog-*）または S3・CloudWatch Logs に転送できます。

運用ゴール状態

• VPC 内専用サブネットにドメインを配置し、外部からの直接アクセスを完全に遮断できている
• Fine-grained access control でアプリ・管理者・分析担当を役割別に権限分離できている
• データ書き込みサービスとのロールマッピングが設定され、最小権限の原則が保たれている
• SAML または内部ユーザーによる Dashboards へのシングルサインオンが設定されている
• 監査ログが有効化されており、不審なアクセスの事後追跡が可能な状態になっている
• CloudWatch アラームで ClusterStatus.red と FreeStorageSpace の監視が設定されている

3. OpenSearch Serverless — collection と OCU

本セクションは OpenSearch Serverless を直接構築・運用するケースを解説します。Bedrock Knowledge Bases がバックエンドとして OpenSearch Serverless を自動プロビジョニングするマネージドRAGパスとは異なる観点を扱います。マネージドRAGパスをお探しの方は下記のリンクからご参照ください。

マネージドRAGをお探しの場合：Bedrock Knowledge Bases 編を読む

3-1. collection 種別と OCU 容量設計

OpenSearch Serverless では、データの特性と用途に応じて3種類の collection を作成します。collection は OpenSearch Serverless のリソース単位であり、それぞれ独立したインデックス空間を持ちます。

Time-series collection

タイムスタンプ付きのログ、メトリクス、イベントストリームの取り込みに最適化された collection タイプです。時系列インデックスの自動ローテーションをサポートしており、ログ分析や Observability 基盤として幅広く利用されます。アプリケーションログや各種サービスの操作履歴を大量に受け入れるシナリオに特に適しています。

Search collection

全文検索・フレーズ検索・ファセット検索など、読み取りレイテンシーが重要なアプリケーション向けの collection タイプです。e-コマースの商品検索システム、ドキュメント管理システム、社内ナレッジベースの検索インターフェースなどに適しています。クエリ応答速度を優先した設計になっています。

Vector search collection

k-NN ベクトル類似検索向けに最適化された collection タイプです。セマンティック検索や RAG(Retrieval-Augmented Generation)のベクトルストアとして活用します。§4 で詳しく解説するベクトルインデックスはこの collection タイプで動作します。

OCU(OpenSearch Compute Unit)の仕様

OpenSearch Serverless のコンピューティングリソースは OCU 単位で管理されます。1 OCU が提供するリソースは以下のとおりです。

• 1 vCPU
• 6 GB メモリ
• 120 GB ストレージ

最小単位として 0.5 OCU(half OCU)も利用可能です。開発環境やテスト環境ではこの最小構成からスタートし、コストを抑えた運用ができます。

OpenSearch Serverless の OCU は indexing OCU と search OCU に分離されており、それぞれ独立してスケールします。indexing OCU はデータ取り込みとインデックス更新を処理し、search OCU は検索クエリの処理を担当します。この分離設計により、ワークロードの特性に合わせた効率的なスケールが可能です。たとえば、データ取り込みが多い夜間バッチ処理では indexing OCU を多めに割り当て、日中の検索ピーク時間帯には search OCU を増やす、といった柔軟な運用が実現できます。

auto-scaling の動作特性

OpenSearch Serverless のオートスケールは以下の特性を持ちます。

• scale-to-zero: アイドル状態が一定期間続くと、リソースをゼロまでスケールダウンします。使用していない時間帯のコストを大幅に削減できますが、コールドスタート時(リクエストが来てからリソースが起動するまで)のレイテンシーが増加します。リアルタイム性が求められる本番サービスでは、コールドスタートの影響を考慮した設計が必要です。
• 最大1,700 OCU: indexing と search それぞれで最大1,700 OCU までスケールアウトできます。大規模な取り込みバーストが発生するシナリオにも対応できる上限値です。
• 高速オートスケール: 前世代と比べて20倍高速なオートスケールを実現しています。急激なトラフィックの増加に対して、数十秒以内でリソースを拡張できます。

OCU コスト設計のチェックリスト

OCU は時間単位で課金されます。コスト見積もりの際は以下の手順で進めます。

1. indexing ピーク時のスループット(ドキュメント数/秒)を見積もり、必要な indexing OCU を算出します。
2. search ピーク時のクエリスループット(QPS)とレイテンシー要件から、必要な search OCU を算出します。
3. scale-to-zero のコールドスタートレイテンシーを許容できるかどうかを確認します。
4. アイドル時間が少ない常時高負荷のワークロードでは、次の 3-2 で解説するマネージドクラスターとコストを比較し、有利な方を選択します。

3-2. マネージドクラスター vs Serverless の使い分け

OpenSearch Serverless とマネージドクラスターの選択は、ワークロードの特性、コスト、運用要件を総合的に判断して決定します。

マネージドクラスターを選ぶ場合

以下のいずれかに該当するワークロードでは、マネージドクラスターが適しています。

• 24時間365日安定したリクエスト量があり、常時稼働の固定コストのほうが安くなる(scale-to-zero の恩恵が受けにくい)
• カスタムプラグインの追加や詳細なシャードチューニングが必要
• UltraWarm / Cold Storage を活用したデータライフサイクル管理でコスト最適化を行う
• SAML 連携や Fine-grained access control の詳細設定が必要

Serverless を選ぶ場合

以下のいずれかに該当するワークロードでは、Serverless が適しています。

• 間欠的なワークロードで、稼働していない時間帯が長くコスト削減効果も高い
• 開発環境・ステージング環境でコストを最小化したい
• インフラ管理のオーバーヘッドをなくし、アプリケーション開発に集中したい
• バーストが読めない新規サービスの立ち上げ期に、スモールスタートから始めたい

4. ベクトル検索 k-NN — RAG のベクトルストア

本セクションは OpenSearch に k-NN ベクトルインデックスを直接構築・運用するケースを解説します。Bedrock Knowledge Bases がマネージドにベクトルインデックスを自動作成・管理するパスとは異なります。マネージドRAGパスをお探しの方は下記のリンクからご参照ください。

マネージドRAGをお探しの場合：Bedrock Knowledge Bases 編を読む

4-1. k-NN エンジン選択(NMSLIB / FAISS / Lucene)

OpenSearch の k-NN プラグインは、3種類の ANN(Approximate Nearest Neighbor)エンジンを提供しています。エンジンの選択は、データ規模、レイテンシー要件、フィルタリングの複雑さに応じて行います。

NMSLIB(Non-Metric Space Library)

NMSLIB は OpenSearch k-NN のデフォルトエンジンです。HNSW(Hierarchical Navigable Small World)アルゴリズムを採用しており、中規模データセット(数千万ベクトル程度)で高精度かつ安定した ANN 検索を提供します。設定のシンプルさとパフォーマンスのバランスが良く、初めてベクトル検索を導入する場合の入り口として適しています。

主な設定パラメータ:
– ef_construction: インデックス構築時のビーム幅です。大きいほど高品質なグラフが生成されますが、インデックス作成時間が増加します(推奨範囲: 128〜512)。
– m: グラフ内の各ノードが持つ最大エッジ数です。値を大きくすると検索精度が向上しますが、インデックスサイズが増加します(推奨範囲: 16〜64)。

FAISS(Facebook AI Similarity Search)

FAISS は大規模データセット(数億ベクトル以上)向けの高性能エンジンです。IVF(Inverted File Index)アルゴリズムによるクラスターリングにより、インデックス全体をスキャンせずに高速な ANN 検索を実現します。

主な特性と設定:
– nlist: IVF クラスター数です。データ量に応じて sqrt(n) を目安に設定します。
– nprobes: 検索時に参照するクラスター数です。大きいほど精度が向上しますが速度は低下します。
– PQ(Product Quantization)をサポートしており、ベクトルデータを大幅に圧縮してメモリ使用量を削減できます。

Lucene

Lucene エンジンは小〜中規模データセットに適しており、特にスマートフィルタリングに優れています。ベクトル検索条件とメタデータによるフィルタを組み合わせた場合でも、精度を高く保てます。OpenSearch のベース検索エンジンを直接活用するため、フィルタとベクトル検索の統合がシームレスです。インデックスサイズもコンパクトになる傾向があります。

エンジン選択の判断基準

ベクトルインデックスの設計パラメータ

k-NN インデックスのマッピング設定で重要なパラメータを以下に示します。

• dimension: 使用する embedding モデルの出力次元数です。Amazon Titan Embeddings V2 は1,024次元、Cohere Embed Multilingual は1,024次元(または1,536次元)を提供しています。次元数が大きいほど表現力は高まりますが、ストレージとメモリの消費量も比例して増加します。
• ef_search: 検索時の候補ノード数(ビーム幅)です。大きいほど精度が向上しますが、レイテンシーも増加します。本番環境では512〜1,024を目安に負荷テストで調整します。
• space_type: ベクトル間の距離計算方法を指定します。Cosine 類似度(cosinesimil)、L2 ユークリッド距離(l2)、内積(innerproduct)から選択します。embedding モデルが推奨する距離指標に合わせて設定します。

インデックスのマッピング設定例:

{
  "mappings": {
 "properties": {
"vector_field": {
  "type": "knn_vector",
  "dimension": 1024,
  "method": {
 "name": "hnsw",
 "engine": "nmslib",
 "parameters": {
"ef_construction": 256,
"m": 32
 }
  }
},
"text": {"type": "text"},
"metadata": {"type": "object"}
 }
  },
  "settings": {
 "index.knn": true
  }
}

コスト最適化: disk-optimized vector search と量子化

k-NN インデックスはデータ量が増えるにつれてメモリを多く消費するため、コスト最適化が重要な課題になります。

• disk-optimized vector search: ベクトルデータをメモリではなくディスクに保存します。ストレージ費用はメモリと比べて大幅に安価なため、同じデータ量でもコストを約1/3に削減できます。レイテンシーはやや増加しますが、リアルタイム性が厳しくないユースケースに適しています。
• 量子化(Quantization): float32(4バイト)のベクトルを int8(1バイト)に変換します。精度の低下を最小限に抑えながら、メモリ使用量を約1/4に削減できます。FAISS エンジンの PQ をさらに組み合わせると、より高い圧縮率が実現できます。

4-2. Bedrock embedding 連携とハイブリッド検索

Bedrock embedding との直接連携フロー

OpenSearch を RAG のベクトルストアとして直接運用する場合、以下のフローでベクトルインデックスを構築します。

1. ドキュメントのチャンク分割: 知識ベースとなるドキュメントを適切なサイズに分割します。一般的なチャンクサイズは512〜1,024トークンが目安です。チャンクが小さすぎると文脈が失われ、大きすぎると検索精度が低下します。
2. embedding 生成: Amazon Bedrock の Titan Embeddings V2(1,024次元)や Cohere Embed Multilingual を呼び出してベクトルを取得します。各チャンクを個別にベクトル化します。
3. OpenSearch への登録: OpenSearch REST API を使用して、ベクトルとともにメタデータ(ドキュメントID、ソースURL、タイトル、更新日時など)を同一ドキュメントとして PUT します。
4. 検索クエリのベクトル化: ユーザーからのクエリを同じ embedding モデルで変換し、k-NN 検索します。
5. コンテキストとして活用: 取得した上位N件の類似チャンクを LLM のプロンプトに含め、回答を生成します。

Python による基本実装例を示します。

import boto3
import json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

def get_embedding(text):
 body = json.dumps({"inputText": text, "dimensions": 1024})
 response = bedrock.invoke_model(
  modelId="amazon.titan-embed-text-v2:0",
  body=body
 )
 return json.loads(response["body"].read())["embedding"]

def build_document(doc_id, text, metadata):
 vector = get_embedding(text)
 return {
  "vector_field": vector,
  "text": text,
  **metadata
 }

ハイブリッド検索(BM25 + k-NN)

ベクトル検索単体では、固有名詞や専門用語の完全一致に弱い場合があります。OpenSearch のハイブリッド検索は、BM25(全文検索スコア)と k-NN(ベクトル類似スコア)を組み合わせることで、セマンティックな意図と具体的なキーワードの両方をカバーします。

ハイブリッド検索を使用するには、まず検索パイプラインを設定します。

PUT /_search/pipeline/hybrid-search-pipeline
{
  "description": "Hybrid BM25 and k-NN pipeline",
  "phase_results_processors": [
 {
"normalization-processor": {
  "normalization": {"technique": "min_max"},
  "combination": {
 "technique": "arithmetic_mean",
 "parameters": {"weights": [0.3, 0.7]}
  }
}
 }
  ]
}

weights の配列は [BM25の重み, k-NNの重み] に対応します。ベクトル検索を重視する場合は [0.3, 0.7]、キーワードマッチを重視する場合は [0.7, 0.3] のように調整します。ユースケースに合わせて重みを設定し、本番前に評価データセットでチューニングすることを推奨します。

ハイブリッド検索のクエリ例を示します。

GET /my-index/_search?search_pipeline=hybrid-search-pipeline
{
  "query": {
 "hybrid": {
"queries": [
  {
 "match": {
"text": {"query": "OpenSearch ベクトル検索 RAG"}
 }
  },
  {
 "knn": {
"vector_field": {
  "vector": [0.1, 0.2, 0.3],
  "k": 10
}
 }
  }
]
 }
  }
}

ハイブリッド検索は OpenSearch 2.10以降のマネージドクラスターおよび OpenSearch Serverless の Vector collection で利用できます。

インデックス更新と差分管理

知識ベースのドキュメントが更新された場合、対応するベクトルも再生成してインデックスを更新する必要があります。ドキュメントIDをソースIDと一致させておくと、PUT 操作による上書き更新が可能です。大規模な全量再インデックスが必要な場合は、index alias を使ったゼロダウンタイム切り替えを検討します。新しいインデックスに全データを投入した後、エイリアスを切り替えることで、検索サービスを止めることなくインデックスを更新できます。

マネージドRAGで自動構築したい場合：Bedrock Knowledge Bases 編を読む

5. ログ分析・Observability — 全文検索による可視化

5-1. ログ取込とインデックス設計

OpenSearch Service へのログ取込経路は主に 3 つあります。用途とインフラ構成に応じて使い分けることが重要です。

Fluent Bit による直接送信

Fluent Bit は軽量なログコレクターで、EC2 インスタンスや ECS タスクのサイドカーとして稼働させ、アプリケーションログを OpenSearch へ直接送信できます。Fluent Bit の OpenSearch output プラグインを使うと、インデックス名・バルク送信サイズ・TLS/IAM 認証を YAML で定義できます。

[OUTPUT]
 Nameopensearch
 Match  app.*
 Hostvpc-my-domain-xxxx.ap-northeast-1.es.amazonaws.com
 Port443
 TLS On
 AWS_Auth  On
 AWS_Regionap-northeast-1
 Index  app-logs
 Logstash_Format On
 Logstash_Prefix app-logs
 Logstash_DateFormat %Y.%m.%d
 Retry_Limit  5

Logstash_Format On を指定すると app-logs-2026.06.04 のような日付付きインデックスが自動生成されます。これにより古いインデックスを一括削除する日次ローテーション運用が容易になります。AWS_Auth On で IAM 署名 v4 を自動付与するため、OpenSearch ドメインのアクセスポリシーを IAM ベースに統一できます。

CloudWatch Logs Subscription Filter → Kinesis Firehose → OpenSearch

Lambda や ECS が CloudWatch Logs にログを書き込む構成では、Subscription Filter を使って Kinesis Data Firehose 経由で OpenSearch へ転送するパターンが一般的です。

1. CloudWatch Logs グループにサブスクリプションフィルターを作成（フィルターパターンでノイズを除外）
2. 送信先に Kinesis Data Firehose デリバリーストリームを指定
3. Firehose の転送先に Amazon OpenSearch Service ドメインを設定
4. バッファサイズ(1〜128 MB)とバッファ間隔(60〜900 秒)でリアルタイム性を調整
5. S3 バックアップを有効化して変換失敗時の再処理パスを確保

Firehose は Lambda 変換・圧縮・S3 バックアップをセットで提供するため、長期保管コストの削減と障害時の再取込を同時に実現できます。CloudWatch Logs に既に集まっているログを最小構成で OpenSearch へ流す場合に最適です。

OpenSearch Ingestion（Data Prepper パイプライン）

OpenSearch Ingestion はマネージドの Data Prepper パイプラインです。詳細は §7 で取り上げますが、ログ分析フローとの関係を整理しておきます。

S3 に蓄積された大量ログを一括取込する場合は、OpenSearch Ingestion の s3 ソースプラグインを使うとパーティション設計に合わせた並列取込が可能です。リアルタイムストリームには otel_logs_source(OpenTelemetry Logs)や http ソースを選択します。取込前の grok/date/geoip による構造化変換が可能で、パイプライン側がフィールド正規化を担うためインデックス設計をシンプルに保てます。

時系列インデックス設計とローテーション

ログデータは典型的な時系列データです。インデックス設計がコストと検索性能を大きく左右します。

Index State Management(ISM)ポリシーを使うと、インデックスの経過日数や容量に基づいてホット→UltraWarm→削除の自動ローテーションを定義できます。

{
  "policy": {
 "description": "ログインデックスのライフサイクル管理",
 "states": [
{
  "name": "hot",
  "actions": [],
  "transitions": [
 {
"state_name": "warm",
"conditions": { "min_index_age": "30d" }
 }
  ]
},
{
  "name": "warm",
  "actions": [
 { "warm_migration": {} }
  ],
  "transitions": [
 {
"state_name": "delete",
"conditions": { "min_index_age": "90d" }
 }
  ]
},
{
  "name": "delete",
  "actions": [
 { "delete": {} }
  ]
}
 ]
  }
}

ISM ポリシーをインデックステンプレートに紐付けると、新規インデックス作成時に自動適用されます。rollover アクションを追加すれば、サイズ超過時にインデックスを自動分割もできます。

取込量が多い本番環境では、インデックスエイリアス(app-logs-write)を経由して書き込み先インデックスを切り替える運用が推奨されます。これにより、ローテーション中もアプリケーション側の設定変更なしに継続して書き込めます。

5-2. 全文検索・異常検知と CloudWatch Logs の棲み分け

クエリ DSL による全文検索と集計

OpenSearch のクエリ DSL(Domain Specific Language)は、JSON 構造でクエリを記述します。bool クエリの must(AND)と should(OR・スコアリング)を組み合わせることで、複雑なログ検索を直感的に表現できます。

GET app-logs-*/_search
{
  "query": {
 "bool": {
"must": [
  { "match": { "level": "ERROR" } },
  {
 "range": {
"@timestamp": {
  "gte": "now-1h/h",
  "lt": "now/h"
}
 }
  }
],
"should": [
  { "match": { "message": "connection refused" } },
  { "match": { "message": "timeout" } }
],
"minimum_should_match": 1
 }
  },
  "aggs": {
 "error_per_service": {
"terms": { "field": "service_name.keyword", "size": 10 }
 }
  },
  "highlight": {
 "fields": { "message": {} }
  }
}

aggs(集計)と組み合わせることで、エラー件数のサービス別内訳を 1 リクエストで取得できます。highlight を追加すると、一致キーワードをタグ付きで返却するため、大量のログから問題箇所を素早く特定できます。

クエリ DSL のほかに、SQL や PPL(Piped Processing Language)でもクエリを記述できます。PPL は Unix パイプ風の記法で、データ分析者が馴染みやすい形式です。

source=app-logs-* | where level = "ERROR" | stats count() by service_name

異常検知（Anomaly Detection / ML Commons）

OpenSearch の Anomaly Detection プラグインは Random Cut Forest(RCF)アルゴリズムを使った教師なし異常検知を提供します。事前にしきい値を決める必要がなく、時系列指標の季節性や傾向変化に自動適応します。

設定の流れは次のとおりです。

1. Detector の作成: 監視対象インデックス・フィーチャー(集計値)・検知間隔(1〜60 分)を定義
2. 学習期間: Detector 作成後の最初の 32 サイクルが学習フェーズ。この期間はアラートが発生しない点に注意
3. 異常結果の確認: opensearch-anomaly-detection-* インデックスに検知結果が蓄積される
4. Dashboards 連携: Anomaly Detection 専用ウィジェットで異常スコアと時系列グラフを可視化

監視指標の例：

- 1 分間のエラーレート(rate aggregation)
- レスポンスレイテンシの 95 パーセンタイル(percentile aggregation)
- ログ取込量の急減(sum aggregation)

ML Commons プラグインを組み合わせると、k-means や Linear Regression などほかの ML アルゴリズムをクラスター内で直接実行でき、ログの分類や予測にも応用できます。

CloudWatch Logs との棲み分け

CloudWatch Logs と OpenSearch は競合関係ではなく補完関係です。両者の強みを踏まえた役割分担が重要です。

推奨アーキテクチャ

本番環境では両者を組み合わせる構成を推奨します。

• Lambda / ECS のアプリログ → CloudWatch Logs(まず一次収集)
• 重要サービスのログ → CloudWatch Subscription Filter → Kinesis Firehose → OpenSearch(全文検索・可視化)
• セキュリティイベント → Security Analytics 機能で分析・SIEM として活用

この設計により、CloudWatch Logs を中継点として活用しながら、長期的な検索・分析は OpenSearch に委ねる役割分担が明確になります。コストを抑えたい場合は Subscription Filter に絞り込みフィルターを設定し、重要度の高いログのみを OpenSearch へ転送するとよいでしょう。

ログ転送・メトリクス側：CloudWatch Logs Insights 編を読む

6. Dashboards・可視化 — ダッシュボードとアラート

6-1. ダッシュボード構築と可視化

OpenSearch Dashboards は Kibana 互換の Web UI で、インデックスのデータを多彩な形式で可視化できます。

インデックスパターンの作成

Dashboards を使い始める最初のステップは、インデックスパターンの設定です。

1. Dashboards の左メニューから「Stack Management」→「Index Patterns」を選択
2. インデックスパターン(例: app-logs-*)を入力して作成
3. タイムスタンプフィールド(通常は @timestamp)を指定
4. フィールドリストが自動検出されることを確認

複数の用途に合わせてインデックスパターンを複数作成できます(アプリログ用・アクセスログ用・異常検知結果用など)。フィールドのデータ型が keyword か text かによってフィルタリングの挙動が変わるため、マッピング設計時に意識しておくことが重要です。

Discover によるリアルタイム探索

Discover 画面はログを時系列で一覧表示するインタラクティブな探索ツールです。

• 時間範囲セレクター(Last 15 minutes / Custom range)で表示期間を調整
• フィールドリストから表示カラムを選んでテーブルビューをカスタマイズ
• KQL(Kibana Query Language)または Lucene クエリで素早いフィルタリング
• 検索結果を Saved Search として保存し、ビジュアライゼーションや他ダッシュボードで再利用

可視化タイプの選択

「Visualize」メニューから作成できる主な可視化タイプは以下のとおりです。

TSVB は複数インデックスを横断した複合グラフを作成できるため、リクエスト数とエラーレートを同一グラフへ重ねるような運用ダッシュボードに最適です。Maps 可視化は GeoIP データと組み合わせると、不審な国・地域からのアクセスを地図上で即座に把握できます。

ダッシュボードの構築と共有

個別ビジュアライゼーションを組み合わせてダッシュボードを構築します。

1. 「Dashboard」→「Create new」でキャンバスを開く
2. 「Add」からビジュアライゼーション・Saved Search を追加
3. パネルをドラッグ＆ドロップで配置・リサイズ
4. Controls パネル(ドロップダウン・スライダー)を追加してインタラクティブフィルターを実装
5. 「Share」でパーマリンク生成・PDF エクスポート・iframe 埋め込みを選択

テナント機能を使うと、チームごとにダッシュボードを分離管理できます。マルチテナント環境でのアクセス制御と組み合わせれば、開発チームには開発用インデックスのみを参照させるといった権限設計が可能です。

ダッシュボードはJSONとしてエクスポート・インポートできるため、GitOps パターンでバージョン管理しながら複数ドメインへ展開もできます。

Security Analytics Dashboards

OpenSearch 2.x 以降で利用できる Security Analytics 機能は、SIEM ユースケースに特化したダッシュボードを提供します。

• OWASP Top 10 などの既製ルールを適用してセキュリティイベントを自動検出
• 相関ルールエンジンで複数のログソースを横断した脅威検知
• Findings ダッシュボードで検知済みイベントをトリアージ・ステータス管理

WAF ログ・VPC Flow Logs・CloudTrail をそれぞれ別インデックスに取込み、相関ルールで紐付けることで、単一ログソースでは見えにくいラテラルムーブメントや権限昇格パターンを検知できます。

6-2. アラートとレポート

Alerting プラグインの設定構造

OpenSearch の Alerting プラグインは Monitor / Trigger / Action の 3 層構造で、しきい値アラートと異常検知アラートの両方に対応します。

Monitor(監視対象の定義)

Monitor には「クエリレベル Monitor」と「バケットレベル Monitor」の 2 種類があります。

• クエリレベル Monitor: クエリ全体の結果件数や集計値をしきい値で評価します。例: 1 分間のエラーログ件数が 50 件を超えたら発報
• バケットレベル Monitor: グループ化された各バケットにしきい値を適用します。例: サービス別に 1 分間のレイテンシを監視し、いずれかのサービスが 2000 ms を超えたら発報

クエリレベル Monitor の設定例：

{
  "name": "high-error-rate-monitor",
  "type": "monitor",
  "monitor_type": "query_level_monitor",
  "schedule": {
 "period": { "interval": 1, "unit": "MINUTES" }
  },
  "inputs": [
 {
"search": {
  "indices": ["app-logs-*"],
  "query": {
 "query": {
"bool": {
  "must": [
 { "match": { "level": "ERROR" } },
 { "range": { "@timestamp": { "gte": "now-1m" } } }
  ]
}
 }
  }
}
 }
  ]
}

Trigger(発報条件の定義)

Trigger は Painless スクリプトで条件を記述します。

ctx.results[0].hits.total.value > 50

重大度レベル(1 = 最重要 / 5 = 最軽微)を設定することでアラートの優先度管理が可能です。スロットリング設定を追加すると、同じ条件での繰り返し発報を抑制できます。

Action(通知先の設定)

Action はアラート発報時の通知先を定義します。対応している通知チャネルは以下のとおりです。

通知メッセージは Mustache テンプレートでカスタマイズできます。

アラート: {{ctx.monitor.name}}
発報時刻: {{ctx.periodEnd}}
検知件数: {{ctx.results.0.hits.total.value}}

Anomaly Detector との連携アラート

Anomaly Detection で検知した異常スコアをトリガーとして Alerting プラグインから通知を組み合わせることができます。この設定により、事前にしきい値を定めることなく統計的異常をリアルタイムで通知できます。Anomaly Detector と Monitor を関連付ける「Anomaly Detector Monitor」を作成し、スコアが一定値(例: 0.9)を超えたら発報する設定が一般的です。

Reporting プラグインによる定期レポート

OpenSearch Dashboards の Reporting 機能を使うとダッシュボードを PDF または CSV 形式でエクスポートできます。

• PDF レポート: ダッシュボードの現在の表示を PNG → PDF 変換して出力。共有リンクやダウンロードで配布
• CSV レポート: Saved Search を元にデータを CSV 形式でエクスポート。BI ツールやスプレッドシートへの連携に活用

レポートのスケジュール設定手順：

1. Dashboards 右上メニューの「Reporting」→「Create report definition」を選択
2. レポート名・形式(PDF/CSV)・ソース(Dashboard/Visualization/Saved Search)を設定
3. スケジュール(毎日/毎週/毎月・実行時刻)を設定
4. 配信先(ダウンロード/メール送信)を指定

毎朝 9:00 に前日のエラーサマリーを PDF で送信するレポートを設定しておくと、日次の定常確認作業を自動化できます。

まとめ: Dashboards 活用のベストプラクティス

• インデックスパターンは用途別に分けて作成し、不要なフィールドをフィルタリングして Discover のパフォーマンスを高めます
• 運用ダッシュボード(リアルタイム監視)と分析ダッシュボード(週次・月次レポート)を分離し、権限管理と表示要件を明確にします
• Monitor のスケジュールはデータ取込遅延を考慮し、取込間隔より少し長い間隔(例: 取込 1 分→Monitor 2 分)に設定します
• Reporting の PDF 出力はヘッドレスブラウザを使うため、Dashboards ノードのメモリを十分に確保します(推奨: 16 GB 以上)

7. Ingestion Pipeline・実戦統合 — 取込と階層コスト最適化

7-1. OpenSearch Ingestion(Data Prepper)パイプライン

OpenSearch Ingestion は、AWS が提供するフルマネージドのデータパイプラインサービスです。内部実装には OSS の Data Prepper を採用しており、セルフホスト版 Data Prepper と互換性のある YAML 定義でパイプラインを記述できます。EC2 や ECS でのインフラ管理・スケーリング設定・可用性確保をすべて AWS に委ねられるため、運用負荷を大幅に削減できます。

マネージド vs セルフホスト Data Prepper の比較

セルフホスト版はカスタム Plugin や細かな JVM 設定が必要なエンタープライズ環境向けです。標準的なログ・トレース・メトリクスの取り込みであれば、マネージドの OpenSearch Ingestion が推奨されます。

パイプライン定義の基本構造

パイプラインは source → processor → sink の 3 要素で構成する YAML を記述します。以下は S3 + SQS 経由でアクセスログを取り込み、Grok でフィールド抽出してから OpenSearch に出力する構成例です。

version: "2"
s3-log-pipeline:
  source:
 s3:
notification_type: sqs
sqs:
  queue_url: https://sqs.ap-northeast-1.amazonaws.com/123456789012/my-log-queue
aws:
  region: ap-northeast-1
  sts_role_arn: arn:aws:iam::123456789012:role/OpenSearchIngestionSourceRole
  processor:
 - grok:
  match:
 log: ['%{COMMONAPACHELOG}']
 - date:
  from_time_received: true
  destination: "@timestamp"
 - delete_entries:
  with_keys: ["log"]
  sink:
 - opensearch:
  hosts:
 - https://my-domain.ap-northeast-1.es.amazonaws.com
  index: application-logs-%{yyyy.MM.dd}
  aws:
 region: ap-northeast-1
 sts_role_arn: arn:aws:iam::123456789012:role/OpenSearchIngestionSinkRole

IAM ロールは source 用と sink 用で分離し、最小権限を付与してください。source ロールには S3 の s3:GetObject と SQS の sqs:ReceiveMessage・sqs:DeleteMessage、sink ロールには OpenSearch の es:ESHttpPut と es:ESHttpPost が必要です。

OpenTelemetry (OTEL) 対応

OpenSearch Ingestion は OpenTelemetry Protocol (OTLP) をネイティブでサポートしています。Fluent Bit・OpenTelemetry Collector・AWS Distro for OpenTelemetry (ADOT) から OTLP/gRPC または OTLP/HTTP でデータを受信し、トレース・メトリクス・ログを統合的に処理できます。

otel-trace-pipeline:
  source:
 otel_trace_source:
port: 21890
request_timeout: 10
  processor:
 - otel_traces: {}
 - service_map_stateful:
  window_duration: PT5M
  sink:
 - opensearch:
  hosts:
 - https://my-domain.ap-northeast-1.es.amazonaws.com
  index_type: trace-analytics-raw
  aws:
 region: ap-northeast-1
 sts_role_arn: arn:aws:iam::123456789012:role/OpenSearchIngestionSinkRole

トレースデータは trace-analytics-raw インデックスタイプで出力すると、OpenSearch Dashboards の Trace Analytics UI と連携して分散トレースを可視化できます。

バックプレッシャー設定の重要性

Ingestion Pipeline で最も見落とされやすいのがバックプレッシャー設定です。http ソースや otel_trace_source の blocking_timeout がデフォルト 30 秒のままだと、OpenSearch 側の書き込みが追いつかない場合に接続元への応答が遅延し、上流サービスでタイムアウトが連鎖します。

  source:
 http:
port: 2021
blocking_timeout: 60s
request_timeout: 30s
max_request_length: 50mb
  buffer:
 bounded_blocking:
buffer_size: 4096
batch_size: 512

buffer_size を大きくするとメモリ消費が増えますが、バースト時のデータロストを防げます。本番では負荷試験を実施し、buffer_size と batch_size を実測値に基づいて調整してください。Dead Letter Queue (DLQ) を S3 に設定することで、パイプライン障害時のデータロストを防ぐことも推奨されます。

7-2. UltraWarm/Cold 階層とコスト最適化

3 階層ストレージの全体像

Amazon OpenSearch Service は 3 つのストレージ階層を提供しており、データのアクセス頻度に応じて使い分けることでコストを大幅に削減できます。

ホット層は EBS に直接データを保持するため、書き込み・全文検索・集計のすべてで最速のレスポンスを発揮します。UltraWarm は S3 をバックストアにしつつローカルキャッシュを組み合わせ、読み取り専用アクセスを低コストで提供します。Cold は S3 のみで、クエリ実行前にインデックスを attach する操作が必要なため、アーカイブデータの定期参照に適しています。

Index State Management (ISM) ポリシーによる自動移行

階層移行の自動化には ISM ポリシーを使用します。以下は 7 日でホット→UltraWarm、30 日で UltraWarm→Cold へ移行する設定例です。

{
  "policy": {
 "description": "hot-warm-cold lifecycle policy",
 "default_state": "hot",
 "states": [
{
  "name": "hot",
  "actions": [],
  "transitions": [
 {
"state_name": "warm",
"conditions": { "min_index_age": "7d" }
 }
  ]
},
{
  "name": "warm",
  "actions": [
 {
"warm_migration": { "wait_for": true }
 }
  ],
  "transitions": [
 {
"state_name": "cold",
"conditions": { "min_index_age": "30d" }
 }
  ]
},
{
  "name": "cold",
  "actions": [
 {
"cold_migration": {
  "timestamp_field": "@timestamp",
  "ignore": false
}
 }
  ],
  "transitions": []
}
 ]
  }
}

ISM ポリシーはインデックステンプレートに紐付けることで、新規インデックス作成時に自動適用されます。ポリシーの適用状態は OpenSearch Dashboards の Index Management UI または REST API で確認できます。

k-NN インデックスの UltraWarm/Cold 移行 (OpenSearch 2.17+)

OpenSearch 2.17 以降では k-NN ベクトルインデックスも UltraWarm および Cold へ移行できるようになりました。これにより RAG ワークロードでも古いベクトルデータをウォーム・コールドストレージに退避してコストを削減できます。ただし、UltraWarm 上の k-NN インデックスはクエリ時にキャッシュロードが発生するため、サブ秒のリアルタイム類似検索には向きません。バッチ検索・低頻度アクセスのアーカイブデータ・定期的な再インデックスを前提とするユースケースに限定して活用してください。

コスト最適化の要点

1. ノードタイプ選択: データ量が少ない場合は汎用ノード (m6g.large.search) から始め、CPU バウンドなら c6g シリーズ、メモリバウンドなら r6g シリーズへ移行します。UltraWarm の最小構成は ultrawarm1.medium.search です。

2. シャード数とサイズ設計: シャード 1 つあたりのサイズを 10〜50 GB に収めることが推奨です。シャード数はインデックス作成後に変更できないため、将来のデータ量を見込んで設計してください。過剰なシャード数はマスターノードの負荷を増やし、クラスター全体のパフォーマンスを低下させます。

3. Serverless の OCU 最適化: OpenSearch Serverless では indexing OCU と search OCU を独立してスケールします。書き込み集中ワークロードでは indexing OCU を増やし、検索集中ワークロードでは search OCU を増やすことで、不要なコストを抑えられます。最大 1,700 OCU まで自動スケールし、scale-to-zero にも対応しています。

4. 予約インスタンス活用: 常時稼働するマネージドクラスターには 1 年または 3 年の予約インスタンスを活用することで、オンデマンド比最大 63% のコスト削減が見込めます。UltraWarm ノードも予約インスタンスの対象です。

5. disk-optimized ベクトル検索: k-NN インデックスで disk-optimized モードを有効にすると、量子化によってメモリ使用量を約 1/3 程度に削減できます。検索精度と引き換えにコストを下げる選択肢として有効です。

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント(7 選以上)

Amazon OpenSearch Service を本番導入したエンジニアが実際に詰まりやすいポイントをまとめます。設計段階で把握しておくことで、後戻りコストを大幅に削減できます。

詰まり 1: シャード数を後から変更できない

OpenSearch では number_of_shards はインデックス作成時に固定され、後から変更できません。少なすぎるとデータ増加時に 1 シャードが肥大化してクエリが遅くなり、多すぎるとマスターノードのメモリ消費が増えてクラスターが不安定になります。

対処法: インデックス作成前に想定データ量 ÷ 30 GB を目安にシャード数を計算してください。将来の 2〜3 倍のデータ量を見込んで余裕を持たせます。既存インデックスを再シャードする場合は _reindex API で新インデックスへデータを移行します。ダウンタイムなし再シャードには _split または _shrink API を活用できますが、事前のインデックス設定変更が必要です。

詰まり 2: Serverless OCU 見積もり失敗でコスト爆発

OpenSearch Serverless は scale-to-zero に対応していますが、minimum_index_capacity_units と minimum_search_capacity_units のデフォルト値が 2 OCU に設定されているため、アイドル時でも最小課金が発生します。バースト時に OCU が急増すると月額コストが想定の 10 倍以上になるケースがあります。

対処法: まず CloudWatch メトリクス SearchOCUUtilization と IndexingOCUUtilization を監視し、実際の消費 OCU を計測してください。開発環境では最小値を 0.5 OCU (half OCU) に設定することでコストを抑えられます。本番環境では負荷試験で最大 OCU を測定し、AWS Cost Explorer でアラートを設定してください。

詰まり 3: k-NN インデックスのメモリ不足で OOM

k-NN ベクトルインデックスはデフォルトで NMSLIB または FAISS のグラフ構造をメモリに保持します。ベクトル数 × 次元数 × バイト数分のメモリが必要で、100 万件 × 1,536 次元 (Titan Embeddings) だと約 6 GB のメモリが必要です。JVM ヒープとは別に OS レベルのメモリが消費されるため、ノードのメモリが不足すると OOM でシャードが Unassigned になります。

対処法: k-NN エンジンを lucene に切り替えると JVM ヒープ内で管理されるためメモリ管理が容易になりますが、100 万件を超える大規模インデックスでは検索性能が低下します。大規模では faiss + disk-optimized モード (量子化) を組み合わせてメモリ使用量を削減してください。また knn.memory.circuit_breaker.limit (デフォルト 50%) を適切に設定し、k-NN 専用ノードを分離することも有効です。

詰まり 4: UltraWarm への移行タイミング誤りでクエリ遅延

ISM ポリシーで warm_migration を設定しても、移行中はインデックスが読み取り専用になります。移行処理は数時間かかることがあり、その間に大量のクエリが殺到すると応答遅延が発生します。また UltraWarm ノードのキャッシュが空の状態では初回クエリが著しく遅くなるウォームアップ問題もあります。

対処法: 移行タイミングをトラフィックが少ない深夜帯に設定してください。ISM の min_index_age を利用して深夜 2 時頃に移行が始まるよう調整します。高頻度アクセスが見込まれる場合は移行後に代表クエリを事前発行してキャッシュをウォームアップするスクリプトを用意してください。

詰まり 5: Fine-grained access control と Dashboards の認証競合

Fine-grained access control (FGAC) を有効にすると、OpenSearch Dashboards へのログインに OpenSearch の内部ユーザー管理または SAML 認証が必要になります。Cognito 認証と FGAC を同時に設定すると、認証フローが競合して Dashboards にログインできないケースがあります。

対処法: Cognito 認証を使用する場合は FGAC の internal_user_database_enabled を false に設定してください。SAML と Cognito の同時利用は非対応のため、どちらかに統一します。FGAC を有効にした後はマスターユーザーを必ず作成し、管理アクセスを確保してから他のユーザー設定を変更してください。マスターユーザーを作成し忘れてロックアウトされた場合は AWS サポートへの問い合わせが必要になります。

詰まり 6: Ingestion Pipeline のバックプレッシャー設定不足でデータロスト

OpenSearch Ingestion のソースの blocking_timeout がデフォルト (30 秒) のままだと、OpenSearch 側の書き込みが追いつかない場合に上流サービスでタイムアウトが発生し、データロストが起きます。特に大量ログのバースト取り込み時 (例: デプロイ直後のアクセス急増) に顕在化します。

対処法: blocking_timeout を 60〜120 秒に延ばし、buffer.bounded_blocking.buffer_size を大きめに設定してバースト吸収力を高めてください。ただしバッファサイズ増加はメモリ消費増につながるため、Ingestion Pipeline のインスタンスサイズも合わせて見直します。また Dead Letter Queue (DLQ) を S3 に設定することで、パイプライン障害時のデータロストを防げます。

詰まり 7: マルチ AZ 設定漏れによる単一障害点

コスト削減を目的としてシングル AZ でクラスターを構築すると、AZ 障害時にクラスター全体がダウンします。マネージドクラスターのデフォルトはマルチ AZ 対応ですが、zone_awareness_enabled: false を明示設定するとシングル AZ になります。

対処法: 本番クラスターでは必ず zone_awareness_enabled: true を設定し、availability_zone_count を 2 または 3 に設定してください。専用マスターノード (dedicated master) も 3 台構成を標準とします。奇数台にすることで過半数クォーラムが確保され、Split Brain を防げます。Terraform や CloudFormation でクラスターを管理する場合は、レビュープロセスでマルチ AZ 設定の確認をチェックリストに追加してください。

詰まり 8: ISM ポリシーのインデックスパターンが未適用

ISM ポリシーを作成しても、既存インデックスや新規インデックスに自動適用されない場合があります。ポリシーの ism_template 設定が不足していると、インデックスを手動で割り当てるまで移行が始まりません。

対処法: ISM ポリシーに ism_template フィールドを追加し、インデックスパターン (例: application-logs-*) を設定してください。既存インデックスには API で手動適用が必要です。適用状態は OpenSearch Dashboards の Index Management 画面で確認できます。

8-2. アンチパターン → 正解変換(5 選以上)

OpenSearch 運用で繰り返し見られる設計判断ミスと、その正解パターンをまとめます。

アンチパターン 1: 全データをホット層に保持し続ける

❌ アクセスがほぼない 30 日以上前のログを EBS ホット層に保持し続け、ストレージコストが膨らんでいる。

✅ ISM ポリシーで UltraWarm/Cold 階層に自動移行する。7 日以降はホット→UltraWarm、30 日以降は UltraWarm→Cold に自動移行する ISM ポリシーを設定します。コールドデータのクエリ頻度が低ければ Cold 移行でホット比最大 20 分の 1 のコストになります。

アンチパターン 2: シャード数 = ノード数 で設定する

❌ 「ノードが 3 台だからシャードも 3 つ」という思い込みで設定し、後からデータが増えて 1 シャードが 200 GB に膨らんでいる。

✅ データ量基準でシャード数を設計する (1 シャード 10〜50 GB)。インデックス作成時に将来のデータ量 ÷ 30 GB を目安にシャード数を決定します。例えば 1 日 3 GB のログが 1 年分 (約 1 TB) ならプライマリシャード 20〜30 が妥当です。シャード数はノード数と独立した設計パラメータです。

アンチパターン 3: データノードをマスターノード兼用にする

❌ クラスター規模が小さい段階から専用マスターノードを省略し、データノードがマスター選出を兼任している。データノードの負荷が高まると選出プロセスが遅延し、クラスターが不安定になります。

✅ 専用マスターノード 3 台を標準構成にする。データノードとは独立した専用マスターノード (dedicated_master) を 3 台配置します。マスターノードはクラスター状態管理のみを担当するため、データノードの負荷変動に影響されません。推奨インスタンスは m6g.large.search です。

アンチパターン 4: k-NN と BM25 のいずれか一方だけで検索する

❌ ベクトル検索 (k-NN) のみを使うと意味的に近い文書が返るが、特定のキーワードを含む文書が漏れる。BM25 のみだと意味的に近い同義語・別表現が見つかりません。

✅ ハイブリッド検索 (BM25 + k-NN) で recall を向上させる。hybrid_search クエリを使い、BM25 スコアと k-NN スコアを正規化して合算します。キーワード検索と意味検索の長所を組み合わせることで、ベクトル検索単独比で recall が 10〜30% 向上するケースが報告されています。

{
  "query": {
 "hybrid": {
"queries": [
  { "match": { "content": { "query": "OpenSearch 設定" } } },
  { "knn": { "content_embedding": { "vector": [0.1, 0.2], "k": 10 } } }
]
 }
  }
}

アンチパターン 5: Serverless を定常負荷ワークロードに使う

❌ 「サーバーーレスなら楽」という思い込みでトラフィックが一定のアプリ検索基盤を Serverless に移行し、マネージドクラスター時より月額コストが 3 倍になった。

✅ 定常負荷はマネージドクラスター + 予約インスタンス、間欠負荷は Serverless。Serverless は間欠的なワークロード (夜間バッチ・開発環境・イベント対応) に適しています。常時リクエストがあるアプリ検索基盤では、マネージドクラスター + 予約インスタンスの方が最大 63% コストを削減できます。判断基準は 1 日あたりの有効リクエスト時間で、8 時間以上常時稼働するならマネージドクラスターが優位です。

アンチパターン 6: Fine-grained access control を有効化せずに VPC アクセスのみで本番稼働する

❌ IP ベースのアクセスポリシーだけで運用し、インデックスレベル・フィールドレベルのアクセス制御が実装されていない。内部の誤操作で本番インデックスを削除するリスクがあります。

✅ FGAC + ロールベースのアクセス制御 (RBAC) を本番標準にする。Fine-grained access control を有効化し、アプリケーション・管理者・読み取り専用の 3 ロールを最小権限で分離します。インデックスパターンごとにロールを設定することで、誤操作による本番データの削除・上書きを防止できます。

8-3. まとめと Vol2 予告

Vol1 では Amazon OpenSearch Service を自前の検索プラットフォームとして本番運用するために必要な知識を網羅的に解説しました。

Vol1 で習得した内容の総括

• ドメイン設計 (§2): マルチ AZ・専用マスターノード 3 台・シャード設計・Fine-grained access control による本番クラスターの基本構成を理解しました。
• OpenSearch Serverless (§3): collection 種別・OCU の indexing/search 分離スケール・scale-to-zero の仕組みと、マネージドクラスターとの使い分け判断軸を習得しました。
• k-NN ベクトル検索 (§4): NMSLIB/FAISS/Lucene のエンジン特性・Bedrock embedding との連携・ハイブリッド検索での recall 向上・disk-optimized によるコスト削減を学びました。
• ログ分析・Dashboards (§5・§6): Ingestion/Fluent Bit/Firehose による取り込みから全文検索・Anomaly Detection・Dashboards 可視化・CloudWatch Logs との棲み分けまでを把握しました。
• Ingestion Pipeline と階層コスト最適化 (§7): マネージド Data Prepper によるパイプライン設計・OTEL 対応・バックプレッシャー設定・UltraWarm/Cold 階層の ISM 自動移行・k-NN インデックスの階層移行 (2.17+) によるコスト最適化を実装できるようになりました。

Vol1 到達状態の確認チェックリスト

• [ ] マルチ AZ・専用マスター 3 台のドメインを Terraform で定義できる
• [ ] シャード数をデータ量基準で設計し、ISM でライフサイクルを自動化できる
• [ ] Serverless とマネージドクラスターを用途・コストで使い分けられる
• [ ] k-NN インデックスを作成し、Bedrock embedding と連携してハイブリッド検索を実装できる
• [ ] Ingestion Pipeline で S3/SQS からログを取り込み、UltraWarm/Cold に自動移行できる
• [ ] FGAC でロールベースのアクセス制御を設定できる

Vol2 予告: 高度な運用・監視・チューニング

Vol2 では本番クラスターの継続運用フェーズに焦点を当てます。CloudWatch メトリクスによるパフォーマンス監視・アラート設定、スロークエリの分析と検索チューニング、バージョンアップグレードの無停止移行手順、セキュリティ設定の監査と強化、そして複数クラスターをまたぐクロスクラスター検索 (CCS) の構成を扱う予定です。OpenSearch を単なるインデックスエンジンとして使うだけでなく、エンタープライズレベルの可観測性・セキュリティ・スケーラビリティを備えた検索プラットフォームとして成熟させる手順を解説します。

Vol1 設計判断フロー

本番 OpenSearch 環境を新規構築する際の主要な判断ポイントを整理します。

ワークロード分類
├─ 常時稼働 + 予測可能な負荷
│└─ → マネージドクラスター (予約インスタンス推奨)
└─ 間欠負荷 / 開発環境 / 小規模
 └─ → OpenSearch Serverless

クラスター設計
├─ 専用マスターノード: 必ず 3 台 (奇数・専用インスタンス)
├─ マルチ AZ: zone_awareness_enabled: true / AZ 数 = 2 or 3
└─ シャード設計: 1 シャード 10〜50 GB 基準で設計

ストレージ階層
├─ 直近 7 日: ホット層 (EBS)
├─ 7〜30 日: UltraWarm (S3 + キャッシュ)
└─ 30 日以降: Cold (S3) or 削除

ベクトル検索
├─ < 100 万件: Lucene エンジン (JVM 管理・シンプル)
├─ > 100 万件: FAISS エンジン + disk-optimized (大規模)
└─ 検索精度優先: BM25 + k-NN ハイブリッド検索

アクセス制御
└─ 本番必須: Fine-grained access control + RBAC
 ├─ アプリケーション用ロール (書き込み限定インデックス)
 ├─ 管理者ロール (全権限)
 └─ 分析者ロール (読み取りのみ)

次のステップ

Vol1 の内容をひととおり理解したら、実際の AWS 環境での動作確認を推奨します。まずは AWS マネジメントコンソールから開発用ドメインを作成し、サンプルデータを取り込んでクエリを試してください。Terraform を使ったインフラコード化、ISM ポリシーの設定、k-NN インデックスの作成と類似検索の動作確認まで体験することで、本番環境への移行判断が容易になります。

IAM ロールや VPC 設定のトラブルシュートには OpenSearch Service のスロークエリログとエラーログが役立ちます。CloudWatch Logs への転送を有効化しておくことで、初期構築時の問題解決が格段に速くなります。

関連：Bedrock RAG / Knowledge Bases 編を読む