Amazon OpenSearch Serviceの検索基盤とシャード設計

検索と分析のクラスターをAWSで運用する

Amazon OpenSearch Serviceは、オープンソースの検索・分析エンジンOpenSearchをAWS上で利用するマネージドサービスです。ドメインを作成すると、検索クラスターのデプロイ、監視、スケーリングなどをAWSの管理機能と組み合わせて運用できます。全文検索、ログ分析、アプリケーションの監視、時系列データの調査など、大量のドキュメントから条件に合う情報を素早く探したい場面に向いています。

たとえば、オンラインチケットサービスがAPIの応答時間やエラー情報を継続的に記録し、運用担当者が時間帯や処理種別で絞り込んで傾向を調べる構成を考えられます。Amazon Data FirehoseからOpenSearch Serviceへデータを届け、OpenSearch Dashboardsで検索・可視化すれば、ログの取り込み経路と分析画面をつなげられます。

OpenSearchはElastic社が公開していたElasticsearch 7.10.2を基礎に、Apache License 2.0で提供されるプロジェクトとして2021年に始まりました。同年9月、Amazon Elasticsearch ServiceはAmazon OpenSearch Serviceへ改称され、Kibanaに代わるオープンソースの可視化ツールはOpenSearch Dashboardsと呼ばれるようになりました。

サービス名の変更は、Elasticsearchというエンジンの名前が一律にOpenSearchへ変わったことを意味しません。OpenSearch ServiceはOpenSearchに加え、旧来のElasticsearch OSSバージョンを使うドメインもサポートしています。新しいドメインを設計するときは、サービス名と選択するエンジン・バージョンを分けて確認してください。

ドキュメントとインデックス

OpenSearchのデータは、検索対象となるドキュメントの集まりとして扱います。ドキュメントは通常JSON形式で、項目名と値の組み合わせによって、対象のオブジェクトやイベントを表します。

{
  "station_id": "reef-27",
  "observed_at": "2026-10-24T09:15:00Z",
  "salinity": 34.8,
  "status": "normal"
}

この例では、観測地点、観測時刻、塩分濃度、状態がそれぞれフィールドです。OpenSearchはフィールドの型やマッピングを基に、文字列検索や数値範囲の絞り込み、集計などを行います。アプリケーションから登録・取得・更新・削除するデータ単位はドキュメントです。

インデックスは、関連するドキュメントを格納して検索する論理的なまとまりです。関係データベースのテーブルにたとえると全体像をつかみやすく、ドキュメントは行、フィールドは列に似ています。ただし、インデックスはリレーショナルデータベースのテーブルと完全に同じ機能や制約を持つものではありません。インデックスは検索・分析用のデータ構造であり、ドキュメントのフィールドやマッピングを設計して利用します。

ドキュメントはインデックス内で一意なIDを持ちます。IDを明示しなければ登録時にOpenSearchがIDを割り当てることもできます。同じインデックスで同じIDを再利用すると、操作方法に応じて該当ドキュメントを上書き・更新する対象になるため、IDの一意性と書き込み方法をアプリケーション側で設計します。

シャードでデータを分割し、複製する

大きなインデックスは複数のシャードに分割して、クラスター内のデータノードへ配置します。各プライマリーシャードは、インデックス全体のデータの一部を受け持つ独立した検索・保存単位です。複数シャードに処理を分散することで、データ量や検索負荷を複数ノードで扱えるようになります。

シャードには次の2種類があります。

シャード	役割
プライマリーシャード	インデックスの分割データを保持し、ドキュメントの書き込みを最初に受け取る
レプリカシャード	対応するプライマリーシャードのコピーを保持し、障害時の冗長性と検索処理の分散を助ける

レプリカはバックアップそのものではありません。プライマリーが失われた場合にレプリカを昇格できる一方、誤った更新や削除もレプリカへ反映されます。長期保管やポイントインタイムの復元には、スナップショットなどのバックアップ手段も別に検討します。

ドキュメントは、既定ではそのIDを基に計算されるルーティング値によって、インデックス内のプライマリーシャードへ振り分けられます。同じIDの読み書き先を決定できるため、対象ドキュメントを特定のシャードへ効率よく届けられます。明示的なカスタムルーティング値を使う構成もありますが、その場合は登録時と検索・更新時に整合するルーティング値が必要です。

プライマリーシャードの数は、インデックス作成時にデータ量と並列度を踏まえて決めます。レプリカ数は運用中に調整できますが、プライマリーシャード数の変更には通常、新しいインデックスを作ってデータを再登録する設計が必要です。シャードが多過ぎると管理や検索の負荷が増え、少な過ぎるとデータや処理を十分に分散できません。最初に極端な値を選ばず、将来のデータ量と検索条件を見積もります。

データノードとクラスターマネージャー

OpenSearch Serviceのクラスターでは、データを保持してクエリを実行するデータノードと、クラスターの状態を管理する専用クラスターマネージャーノードの役割を分けられます。旧来のAWS用語では専用マスターノードとも呼ばれます。

ノード	主な役割	通常は担当しない処理
データノード	シャードとインデックスデータを保持する。ドキュメントの書き込み、検索、集計を処理する	クラスター全体の管理状態を単独で決める
専用クラスターマネージャーノード	ノードやインデックスの状態を追跡し、クラスター状態の更新、シャードの配置などを管理する	インデックスデータを保持すること、通常のデータ要求を処理すること

クラスターマネージャーは、どのノードがクラスターに参加しているか、インデックスやシャードがどこにあるかなどのメタデータを管理します。専用ノードにこの役割を任せることで、検索や取り込み負荷が高いときもクラスター管理処理を分離し、安定性を高められます。可用性を考慮する本番クラスターでは、複数AZに専用クラスターマネージャーを配置する設計が推奨されます。

クライアントからの要求は、データノードが調整役（coordinator）として受け取り、対象シャードを持つノードへ転送することがあります。この要求処理上の調整役と、クラスター状態を管理するクラスターマネージャーは別の役割です。検索要求やドキュメントの書き込み先を考えるときに混同しないようにします。

Multi-AZでコピーを分散する

Multi-AZ構成では、データノードを複数のアベイラビリティーゾーン（AZ）へ分散します。さらに、プライマリーシャードと対応するレプリカシャードが別のノード、可能なら別のAZに置かれるように構成することで、単一ノードやAZの障害による影響を抑えます。レプリカがなければ、別AZに昇格可能なデータコピーを配置できません。

現在は本番ドメイン向けに、3つのAZを使い、そのうち1つのデータノード群を待機系として確保するMulti-AZ with Standbyが推奨されています。待機AZは通常時に検索要求を処理せず、障害時に稼働系として切り替わります。この構成では、サービス側の配置要件に沿ってデータノード数やレプリカ数などを設定します。Standbyを使わないMulti-AZも選べますが、その場合は障害時の再配置に必要な容量や、レプリカの配置バランスを設計する必要があります。

「AZを複数選択すれば自動的に十分な冗長性が得られる」とは限りません。レプリカ数、データノード数、シャード総数の組み合わせによっては、負荷が一部のノードに偏ることがあります。データのコピーをAZにまたがって配置し、障害中にも検索や書き込みを続けられる容量があるか確認します。

クラスターの大きさを負荷から決める

データノード数やインスタンスタイプを、インデックス数だけから決めることはできません。保存するデータ量、1秒あたりの取り込み量、更新頻度、検索の同時実行数、集計範囲、保持期間、レプリカ数などが必要容量を左右します。保持期間の長いログを保存するなら、日付単位のインデックス設計やストレージ階層の移行も合わせて考えます。

設計時には、代表的なデータ量とクエリを使った負荷試験を行います。通常時だけでなく、ピーク時の取り込みと検索が同時に発生する状況、ノードやAZが一時的に利用できない状況も評価します。測定結果に基づいてノード数、CPU・メモリ・ストレージ容量、シャード数、レプリカ数を調整します。

運用中はCPU使用率、JVMメモリ圧力、ストレージ空き容量、書き込み拒否や検索レイテンシーなどを監視します。ストレージ容量に余裕があっても、CPUやメモリが不足すれば検索が遅くなることがあります。反対に、ノードを増やせば必ず性能が上がるわけでもなく、シャード数や配置の偏りを含めて確認します。

Hot、UltraWarm、Coldのストレージ階層

時系列データやログは、時間の経過とともに検索頻度や更新頻度が下がることがあります。OpenSearch Serviceでは、利用頻度や要求性能に応じてデータをHot、UltraWarm、Coldの階層に移し、検索性と保管コストのバランスを取れます。

階層	保存方法と性能	主な用途と制約
Hot	データノードに接続されたEBSボリューム、またはインスタンスストアを使う。書き込みと検索の性能を優先する	新しく取り込むデータ、頻繁に検索・更新するデータ
UltraWarm	UltraWarmノードがS3上のデータとキャッシュを使って保持する。Hotより低コストで大きな読み取り専用データを検索できる	更新頻度が低く、検索頻度や性能要件もHotほど高くない履歴データ。書き込みにはHotへの移行が必要
Cold	S3を利用し、専用のコンピューティング容量を常時割り当てずに保管する	普段はアクセスしない長期履歴。検索するときは対象インデックスを既存のUltraWarmノードへ接続する

UltraWarmはS3を基盤とするものの、OpenSearchのクエリから利用できるようにキャッシュを組み合わせます。インデックスを読み取り専用の状態で保管し、通常のHotストレージよりアクセス頻度の低いデータを保持できます。書き込みや更新を続けるインデックスはHotに置き、変更が落ち着いた後にUltraWarmへ移すのが基本です。検索頻度が高いデータや広範囲の集計を多く行うデータは、実際の性能を測ってHotに残すか判断します。

ColdストレージもS3を使いますが、Coldのデータに専用の検索コンピューティング容量は常時割り当てられません。過去の監査ログなどを必要時に調べるとき、対象インデックスをUltraWarmノードへ接続して検索します。Cold上のインデックスをそのまま日々更新する使い方には向かず、変更が必要ならHotなどの利用可能な階層へ戻してから処理します。ColdはUltraWarmを有効にしたドメインで使い、専用クラスターマネージャーノードなどの前提条件も満たす必要があります。

階層間の移行は、インデックスの経過日数などに応じて**Index State Management（ISM）**で自動化できます。たとえば、直近の運用ログをHotに保ち、一定期間後にUltraWarmへ移し、長期保管分をColdへ移行する方針を定義できます。保存期間を過ぎたインデックスを削除するルールも設定できます。移行状態や前提条件を監視し、目的の階層へ実際に移動したことを確認します。

料金は、Hotではデータノードやプロビジョニングしたストレージ、UltraWarmではUltraWarmノードと保存データ、ColdではColdに保存するデータ量などが関係します。必要性能と検索頻度に合った階層を選び、最新の課金単位はAmazon OpenSearch Serviceの料金ページで確認してください。

学習時に区別するポイント

• 全文検索・ログ分析・運用データの可視化には、検索と分析のエンジンであるAmazon OpenSearch Serviceを使います。
• データを取り込んで配信先へ届ける役割はAmazon Data Firehoseが担い、OpenSearch Serviceは届いたドキュメントをインデックス化して検索・分析します。
• ドキュメント、インデックス、シャードはそれぞれデータ単位、論理的な集合、分割保存・処理の単位です。
• プライマリーとレプリカは同じノードへ置かず、Multi-AZでは別AZへの分散によって障害耐性を高めます。レプリカはバックアップではありません。
• データノードはシャードやクエリを扱い、専用クラスターマネージャーはクラスターの状態とシャード配置を管理します。
• Hot、UltraWarm、Coldは保存場所の違いだけではなく、データの更新可否、検索頻度、検索時に必要となる計算容量が異なります。

公式ドキュメント

• Amazon OpenSearch Serviceとは
• Amazon OpenSearch Serviceのベストプラクティス（シャード戦略）
• 専用クラスターマネージャーノード
• Multi-AZドメインの構成
• UltraWarmストレージ
• Coldストレージ
• Index State Management
• Amazon Data FirehoseからOpenSearch Serviceへの配信
• Amazon OpenSearch Serviceの料金