分析と検索

Amazon OpenSearch Serverless の実践ガイド - OCU 設計とコレクションタイプ別の最適化戦略

Amazon OpenSearch Serverless は、クラスターの運用管理を不要にしながら検索・分析ワークロードを自動スケーリングで処理するフルマネージドサービスです。OCU の課金モデルとコレクションタイプの選定基準、インデックス設計のベストプラクティスを実務視点で解説します。

約 4 分で読めます

クラスター管理からの解放 - OpenSearch Serverless が解決する運用課題

従来の Amazon OpenSearch Service では、ドメインのインスタンスタイプ選定、シャード数の調整、ノード障害時のリバランスといったクラスター運用が避けられなかった。特にトラフィックの変動が大きいワークロードでは、ピーク時に備えた過剰プロビジョニングか、スケーリングの遅延によるレイテンシ悪化のどちらかを受け入れる必要があった。OpenSearch Serverless はこの課題を根本から解消する。ユーザーはコレクションとインデックスの設計に集中し、コンピュートとストレージの管理は AWS 側が自動で行う。内部的にはインデックスとコンピュートが分離されたアーキテクチャを採用しており、検索リクエストの増減に応じて OCU (OpenSearch Compute Unit) が独立にスケールする。この分離設計により、大量のデータ取り込みと高頻度の検索クエリが同時に発生しても、互いのパフォーマンスに干渉しにくい構造になっている。従来型のクラスターでは、インデクシングと検索が同一ノードのリソースを奪い合う問題が頻発していたが、Serverless ではその心配が不要になる。

OCU の課金構造を正しく理解する - 最低コストと自動スケーリングの実態

OpenSearch Serverless のコストを左右するのが OCU (OpenSearch Compute Unit) の仕組みだ。1 OCU は 6 GiB の RAM と対応する vCPU を提供し、インデクシング用とサーチ用の 2 系統に分かれて割り当てられる。重要なのは、コレクションを作成した時点でインデクシング用に最低 2 OCU、サーチ用に最低 2 OCU の合計 4 OCU が常時確保される点だ。2026 年 4 月時点の東京リージョンでは 1 OCU あたり約 0.334 USD/時間であり、最低構成でも月額約 975 USD が発生する。この最低コストを見落として「サーバーレスだから安い」と判断すると、想定外の請求に直面する。一方、トラフィック増加時には最大数百 OCU まで自動スケールし、負荷が下がれば最低値まで縮退する。スケーリングの応答時間は数十秒から数分程度で、急激なスパイクにも比較的迅速に対応する。コスト最適化のポイントは、開発・検証環境では不要なコレクションを削除して最低 OCU の課金を止めること、そして本番環境では最大 OCU の上限を適切に設定してコスト暴走を防ぐことにある。

3 つのコレクションタイプ - ワークロード特性に応じた選定基準

OpenSearch Serverless は、検索 (Search)、時系列 (Time series)、ベクトル検索 (Vector search) の 3 つのコレクションタイプを提供する。それぞれ内部のインデックス戦略が異なるため、ワークロードに合わないタイプを選ぶとパフォーマンスとコストの両面で損をする。検索コレクションは、EC サイトの商品検索やドキュメント検索など、ランダムアクセスが中心のワークロードに適している。レプリカ配置が検索レイテンシの最小化に最適化されており、p99 で数十ミリ秒の応答を実現する。時系列コレクションは、ログ分析やメトリクス収集など、時間軸に沿った書き込みと範囲クエリが主体のワークロード向けだ。古いデータのセグメントマージが効率化されており、大量の追記書き込みに強い。ベクトル検索コレクションは、セマンティック検索や RAG のナレッジベースとして注目されている。k-NN インデックスを内部で最適管理し、1536 次元の埋め込みベクトルに対しても高速な近似最近傍検索を提供する。Azure AI Search もベクトル検索に対応しているが、OpenSearch Serverless ではコレクションタイプとして独立しておりベクトル専用の最適化が適用される。

インデックス設計の勘所 - シャード戦略とマッピング定義の実践

OpenSearch Serverless ではシャード数の手動設定が不要になったとはいえ、インデックスのマッピング設計は依然としてパフォーマンスに直結する。まず、フィールドのデータ型を明示的に定義するマッピングを必ず作成すること。動的マッピングに頼ると、数値として扱いたいフィールドが text 型で登録され、集計クエリの効率が大幅に低下する。keyword 型と text 型の使い分けも重要で、完全一致フィルタリングには keyword 型、全文検索には text 型を割り当てる。1 つのフィールドに両方の用途がある場合は multi-field 定義で対応する。時系列コレクションでは、インデックスの命名にタイムスタンプを含める (例: logs-2026-04) ことで、古いインデックスの削除が容易になる。検索コレクションでは、ドキュメントサイズを 100 KB 以下に抑えることが推奨される。巨大なドキュメントはインデクシングの OCU 消費を押し上げ、検索レイテンシも悪化させる。ベクトル検索コレクションでは、次元数とメトリクス (cosine, l2, dotProduct) の選択がリコール率と速度のトレードオフに直結するため、事前にベンチマークで検証すべきだ。

セキュリティとアクセス制御 - 暗号化ポリシーとデータアクセスポリシーの設計

OpenSearch Serverless のセキュリティモデルは、従来の OpenSearch Service とは根本的に異なる。きめ細かいアクセス制御 (FGAC) の代わりに、暗号化ポリシー、ネットワークポリシー、データアクセスポリシーの 3 層構造で管理する。暗号化ポリシーはコレクション作成前に定義が必要で、AWS 管理キーまたはカスタマー管理の KMS キーを選択する。コンプライアンス要件でキーのローテーション管理が求められる場合はカスタマー管理キーを選ぶ。ネットワークポリシーでは、コレクションへのアクセスをパブリックまたは VPC エンドポイント経由に制限できる。本番環境では VPC エンドポイント経由のアクセスに限定し、ダッシュボードへのアクセスも同様に制限することが推奨される。データアクセスポリシーは IAM プリンシパルに対してコレクションやインデックスレベルの操作権限を付与する仕組みで、JSON 形式のルールで定義する。ポリシーはコレクション名のワイルドカードパターンに対して適用できるため、命名規則を統一しておくと管理が容易になる。例えば、チームごとにプレフィックスを付けて team-a-* のようなパターンでアクセスを分離する設計が実務では有効だ。

導入判断のフレームワーク - Serverless と従来型クラスターの分岐点

OpenSearch Serverless と従来の OpenSearch Service の選択は、ワークロード特性とコスト構造で判断する。Serverless が向いているのは、トラフィック変動が大きく予測困難なワークロード、運用チームが少ない環境、迅速に検索基盤を立ち上げたいケースだ。一方、トラフィックが安定しコストを厳密に管理したい場合や、カスタムプラグインが必要な場合は従来型クラスターが適している。コスト面の分岐点として、月間負荷が常時 4 OCU 相当 (約 975 USD/月) を超えるなら Serverless のメリットが出やすく、小規模で安定したワークロードでは最低 OCU の固定費が割高になる。Azure AI Search はレプリカ・パーティション単位の課金でスケーリング粒度が異なる。検索エンジンの設計パターンについては関連書籍 (Amazon) も参考になります。

関連する記事

データ検索と分析の実践 - OpenSearch による全文検索と可視化基盤の構築Amazon OpenSearch Service を活用したデータ検索と分析の設計手法を解説し、全文検索、ログ分析、ダッシュボード可視化による分析基盤の構築方法を紹介します。Amazon OpenSearch Service で構築するログ分析基盤 - インデックス設計とダッシュボード構築ログ分析基盤を構築し、インデックスライフサイクル管理でコストを最適化する。OpenSearch Dashboards と Serverless モードの活用を紹介します。Amazon Kinesis で構築するリアルタイムデータパイプライン - Data Streams と Data Firehose の使い分けData Streams でリアルタイムデータを取り込み、Data Firehose で S3・Redshift・OpenSearch に自動配信する。シャード設計とオンデマンドモードの使い分けでストリーミングパイプラインを構築する方法を解説します。

同じテーマの記事

Amazon Quick の実践活用 - 部門別ユースケースとワークフロー自動化の設計パターン営業・IT・財務など部門ごとの活用シナリオと、Quick Flows による通知・承認・多段階ワークフローの設計パターンを具体的に紹介します。BI ダッシュボード可視化 - Amazon QuickSight で実現するデータドリブンな意思決定基盤Amazon QuickSight によるインタラクティブな BI ダッシュボードの構築と、Athena との連携によるサーバーレスデータ分析基盤を解説します。SPICE エンジンによる高速可視化と組織全体へのインサイト共有の実践手法を紹介します。ブロックチェーンネットワーク構築 - Amazon Managed Blockchain と QLDB による分散台帳の活用Amazon Managed Blockchain によるブロックチェーンネットワークの構築と、Amazon QLDB による検証可能な台帳データベースの活用方法を解説します。サプライチェーン管理や金融取引の透明性確保など、実践的なユースケースを紹介します。AWS Clean Rooms で実現するプライバシー保護型データコラボレーションデータを共有・コピーせずに複数企業間で共同分析を実行する。集計ルールによる個人特定防止と Cryptographic Computing による暗号化分析を紹介します。顧客 ID 統合 - AWS Entity Resolution で分散した顧客データを名寄せするAWS Entity Resolution を使った顧客データの名寄せ (エンティティ解決) を解説。ML ベースのマッチング、ルールベースのマッチング、プライバシー保護、Clean Rooms との統合を紹介します。AWS Data Exchange で活用するサードパーティデータ - データ調達とサブスクリプション管理サードパーティのデータ製品を Marketplace 経由で調達し、S3 への自動配信パイプラインを構築する。自社データの製品化と収益化の手法も紹介します。Amazon S3 と Lake Formation で構築するデータレイク - 設計パターンとガバナンスS3 をストレージ基盤とし Lake Formation できめ細かいアクセス制御を実現するデータレイクの設計パターンを紹介。ETL パイプラインとコスト最適化も解説します。データレイクガバナンス - AWS Lake Formation による一元的なアクセス制御AWS Lake Formation を使ったデータレイクの構築・アクセス制御・ガバナンスを解説。S3 ベースのデータレイクに対する列レベル・行レベルのきめ細かな権限管理と Glue ・ Athena との統合を紹介します。

内容が近い記事・サービス

Amazon OpenSearch ServiceElasticsearch 互換のマネージド検索・分析エンジンで、全文検索、ログ分析、リアルタイムダッシュボードなど多様なユースケースに対応する。データ検索と分析の実践 - OpenSearch による全文検索と可視化基盤の構築Amazon OpenSearch Service を活用したデータ検索と分析の設計手法を解説し、全文検索、ログ分析、ダッシュボード可視化による分析基盤の構築方法を紹介します。Amazon OpenSearch Serviceログ分析や全文検索を手軽に実現できるマネージド検索・分析サービスAmazon OpenSearch Service で構築するログ分析基盤 - インデックス設計とダッシュボード構築ログ分析基盤を構築し、インデックスライフサイクル管理でコストを最適化する。OpenSearch Dashboards と Serverless モードの活用を紹介します。Amazon Bedrock Knowledge Bases で構築する RAG アプリケーション - 検索拡張生成の実装S3 上のドキュメントを自動インデックス化し、RetrieveAndGenerate API で検索と生成を統合する。チャンキング戦略の選定と Guardrails による安全性確保を紹介します。