Amazon OpenSearch Service
Elasticsearch 互換のマネージド検索・分析エンジンで、全文検索、ログ分析、リアルタイムダッシュボードなど多様なユースケースに対応する。
概要
Amazon OpenSearch Service は、OpenSearch (Elasticsearch のオープンソースフォーク) をフルマネージドで提供する検索・分析サービスです。クラスタのプロビジョニング、パッチ適用、バックアップ、モニタリングを AWS が管理するため、運用負荷を大幅に削減できます。全文検索エンジンとしてのテキスト検索に加え、OpenSearch Dashboards によるログの可視化・分析、異常検知プラグインによるリアルタイム監視など、検索と分析の両面で活用されます。UltraWarm と Cold ストレージによる階層化で、大量のログデータを低コストに長期保存することも可能です。
インデックス設計がクエリ性能を決める
OpenSearch のパフォーマンスはインデックス設計で大部分が決まります。シャード数はインデックス作成後に変更できないため、初期設計が極めて重要です。1 シャードあたりの推奨サイズは 10 - 50 GB で、これを超えるとクエリレイテンシが悪化し、リカバリ時間も長くなります。たとえば日次で 100 GB のログを取り込む場合、日付ベースのインデックス (logs-2026-04-19 のような命名) を作成し、各インデックスに 3 シャードを割り当てるのが一般的です。マッピング定義ではフィールドの型を明示的に指定します。動的マッピングに任せると、数値が text 型として認識されて集計クエリが使えなくなるケースがあります。keyword 型と text 型の使い分けも重要で、完全一致フィルタリングには keyword、全文検索には text を使います。実務では Index Template を定義して、新規インデックスに自動的にマッピングとシャード設定を適用するのが定石です。Index State Management (ISM) ポリシーを設定すれば、一定期間経過後にインデックスを UltraWarm に移行し、さらに古いものを削除するライフサイクル管理を自動化できます。
UltraWarm と Cold - コスト最適化のための階層戦略
ログ分析のワークロードでは、直近のデータは頻繁にクエリされますが、数ヶ月前のデータへのアクセス頻度は急激に下がります。OpenSearch Service はこの特性に合わせた 3 階層のストレージを提供します。Hot ノードは SSD ベースのインスタンスストレージで、リアルタイムの書き込みと高速なクエリを処理します。UltraWarm は S3 をバックエンドとするウォームストレージで、Hot ノードと比較してストレージコストが約 90% 削減されます。読み取り専用ですがクエリは可能で、数秒から数十秒のレイテンシを許容できるユースケースに適しています。Cold ストレージはさらに低コストで、クエリ前にアタッチ操作が必要ですが、コンプライアンス要件で長期保存が求められるログの保管に最適です。Azure Cognitive Search にはこのような階層型ストレージの仕組みがなく、全データを同一のストレージ層で保持するため、大量のログデータを長期保存する場合のコスト効率では OpenSearch Service に優位性があります。ログ分析の関連書籍 (Amazon) では、こうした階層設計の考え方が実例とともに紹介されています。
マネージドクラスタと Serverless の選択基準
OpenSearch Service には従来のマネージドクラスタに加え、2022 年にリリースされた OpenSearch Serverless があります。Serverless はクラスタのサイジングやシャード管理が不要で、OCU (OpenSearch Compute Unit) の自動スケーリングによりトラフィックに応じたリソース調整が行われます。運用負荷は大幅に軽減されますが、トレードオフも存在します。Serverless ではカスタムプラグインが使えず、ISM ポリシーによるインデックスライフサイクル管理もサポートされていません。また最低 4 OCU (インデックス用 2 + 検索用 2) が常時課金されるため、小規模なワークロードではマネージドクラスタの方がコスト効率が良い場合があります。判断基準として、インデックス数が少なく運用チームのリソースが限られている場合は Serverless、シャード設計やプラグインの細かな制御が必要な大規模ワークロードではマネージドクラスタが適しています。マネージドクラスタを選択する場合は、マルチ AZ 配置と専用マスターノード (3 台) の構成が本番環境の推奨構成です。専用マスターノードはクラスタの状態管理に専念し、データノードの負荷がクラスタの安定性に影響するのを防ぎます。