OpenSearch検索可能スナップショットによる検索
クラスタの効率を高め、コスト効率の高いスケーラブルなリモート・ストレージからデータを直接問い合せます。
OpenSearch検索可能なスナップショット機能を使用すると、オブジェクト・ストレージ・バケットに格納されている索引スナップショットを、ライブ検索可能な索引としてマウントできます。プライマリ・ノードにデータをリストアするかわりに、検索可能なスナップショットは、頻繁に問い合せられるセグメントの軽量ローカル・キャッシュを維持します。検索可能なスナップショットにより、クラスタは、コスト効率が高くスケーラブルなリモート・ストレージからデータを直接問い合せながら、パフォーマンスを向上させることができます。
検索可能なスナップショットを使用すると、次のような利点があります。
- コスト効率: 古いデータやアクセス頻度の低いデータをリモート・ストレージにオフロードできるため、プライマリ・クラスタでの高コストな高パフォーマンス・ストレージの必要性が軽減されます。
- 管理の簡素化: ダウンタイムなしで索引をホット・ストレージからコールド・ストレージに遷移するポリシーを使用して、履歴データを自動的に管理できます。
- スケーラビリティの向上: 専用検索ノードにキャッシュすることで、ほぼリアルタイムの検索機能を提供しながら、オブジェクト・ストレージのほぼ無制限の容量を活用できます。
- 最適化されたパフォーマンス: データの最も頻繁にアクセスされる部分のみをキャッシュすることで、検索可能なスナップショットは、ほとんどのデータがリモートに格納されている場合でも、高速な問合せレスポンス時間を維持します。
専用検索ノードと索引状態管理(ISM)ポリシーを組み合せることで、組織のコスト効率、検索パフォーマンスおよび自動化を実現できます。
次の各項では、OpenSearchで検索可能なスナップショットを構成および使用する方法について説明します。
専用検索ノードを使用したOpenSearchクラスタの作成
OpenSearchを使用した検索では、検索ノードが検索可能なスナップショットを処理します。たとえば、オブジェクト・ストレージのみからではなくディスク/メモリーから検索を実行できるように、ローカルにデータをキャッシュします。OpenSearchクラスタを作成する場合、次のような検索ノード構成を指定する必要があります。
- 検索ノードで使用されるシェイプ。
- 検索ノードとして指定するデータノードの数。
- 検索ノードOCPUの数。
- 検索ノードのメモリー量。
- 検索ノードのストレージの量。
すべての検索ノードのホスト・タイプがFLEXである必要があります。
クラスタ内の検索ノードの構成の詳細は、「OpenSearchクラスタを使用した検索の作成」を参照してください。
検索ノード数の決定
検索ノードとしてデータ・ノードを20%から40%の間で指定することをお薦めします。次の表に、データ・ノード数に基づく最小範囲と最大範囲の例を示します。
| データ・ノード | 最小検索ノード | 最大検索ノード数 |
|---|---|---|
| 1-2 | 1 | 1 |
| 3-5 | 1 | 2 |
| 6-7 | 2 | 3 |
| 8-10 | 2 | 4 |
| 11-12 | 3 | 5 |
| 13-15 | 3 | 6 |
| 50 | 10 | 20 |
| 100 | 20 | 40 |
スナップショットのオブジェクト記憶域リポジトリの登録
検索可能なスナップショットを実行するには、オブジェクト・ストレージを指すスナップショット・リポジトリが必要です。OpenSearchでは、通常、S3互換のプラグイン・エンドポイントを使用してリポジトリを登録します。
次の例は、リポジトリを登録する方法を示しています。オブジェクト・ストレージ構成のパラメータ値を調整します。
PUT _snapshot/my_snapshot_repository
{
"type": "oci",
"settings": {
"client": "default",
"endpoint": "<region-endpoint>",
"bucket": "<object-storage-bucket>",
"namespace": "<object-storage-namespace>",
"authType": "RESOURCE_PRINCIPAL",
"bucket_compartment_id": "<bucket_compartment_ocid>"
}
}自動検索可能スナップショットのISMポリシーの定義
- 暑い状態で90日待ちます。
- 索引のスナップショットを取得します。
- (構成した専用検索ノードを使用して)索引をリモート検索可能なスナップショットに変換します。
次の例は、90日トリガーを持つISMポリシーを示しています。
PUT _plugins/_ism/policies/searchable_snapshots_policy
{
"policy": {
"description": "Policy to snapshot and convert index to remote searchable snapshot after 90 days",
"default_state": "hot_state",
"states": [
{
"name": "hot_state",
"actions": [],
"transitions": [
{
"state_name": "snapshot_state",
"conditions": {
"min_index_age": "90d"
}
}
]
},
{
"name": "snapshot_state",
"actions": [
{
"snapshot": {
"repository": "my_snapshot_repository",
"snapshot": "{{ctx.index}}"
}
}
],
"transitions": [
{
"state_name": "cold_state",
"conditions": {}
}
]
},
{
"name": "cold_state",
"actions": [
{
"convert_index_to_remote": {
"repository": "my_snapshot_repository"
}
}
],
"transitions": []
}
]
}
}ここで、索引はホット状態では90日間この状態のままです。90日後、ISMは索引のスナップショットを取得した後、コールド状態に遷移し、索引はリモート検索可能なスナップショットに変換されます。現在は主にオブジェクト・ストレージに存在しますが、検索ノードを使用して検索できます。
索引へのポリシーの適用
ポリシーの作成後、次の例に示すように、その索引の設定を更新することで、新規または既存の任意の索引に適用できます。
PUT my_index/_settings
{
"opendistro.index_state_management.policy_id": "searchable_snapshots_policy"
}
Or you can try to create index template so that ism policy can be applied throughout all index patterns that it matches.
PUT _index_template/<template_name>
{
"index_patterns": [
"index_name-*"
],
"template": {
"settings": {
"opendistro.index_state_management.policy_id": "policy_id"
}
}
}ポリシー・アプリケーションを確認するには、次を確認します。
GET my_index/_settings検証および監視
OpenSearchクラスタを定期的に監視して、検索ノードがアクティブであることを確認します。オブジェクト・ストレージ・リポジトリをチェックして、スナップショットが作成されていることを確認します。
ISMの遷移を確認するには、次のコマンドを実行して索引の現在の状態を確認します。
GET _plugins/_ism/explain/my_index90日後、索引はホット状態からコールド状態に遷移する必要があります。