翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service の UltraWarm ストレージ
UltraWarm は、大量の読み取り専用データをコストパフォーマンスに優れた方法で Amazon OpenSearch Service に保存できます。標準データノードは「ホット」ストレージを使用します。このストレージは、各ノードにアタッチされたインスタンスストアまたは Amazon EBS ボリュームの形をとります。ホットストレージは、新しいデータのインデックス作成と検索において、可能な限り高速なパフォーマンスを提供します。
UltraWarm ノードは、接続されたストレージではなく、Amazon S3 と高度なキャッシュソリューションを使用してパフォーマンスを向上させます。アクティブに書き込みを行っていないインデックス、クエリの頻度が低いインデックス、および同じパフォーマンスが必要とされないインデックスについては、UltraWarm により、データの GiB あたりのコストが大幅に削減されます。ウォームインデックスはホットストレージに戻されない限り読み取り専用であるため、UltraWarm はログなどのイミュータブルなデータに最適です。
OpenSearch では、ウォームインデックスは他のインデックスと同じように動作します。同じ API を使用してそれらのクエリを行うことも、OpenSearch Dashboards で可視化を作成することもできます。
**Topics**
+ [前提条件](#ultrawarm-pp)
+ [UltraWarm ストレージの要件とパフォーマンスに関する考慮事項](#ultrawarm-calc)
+ [UltraWarm 料金設定](#ultrawarm-pricing)
+ [UltraWarm を有効にする](#ultrawarm-enable)
+ [UltraWarm ストレージへのインデックスの移行](#ultrawarm-migrating)
+ [移行を自動化する](#ultrawarm-ism)
+ [移行の調整](#ultrawarm-settings)
+ [移行をキャンセルする](#ultrawarm-cancel)
+ [ホットインデックスとウォームインデックスを一覧表示する](#ultrawarm-api)
+ [ウォームインデックスをホットストレージに戻す](#ultrawarm-migrating-back)
+ [スナップショットからのウォームインデックスの復元](#ultrawarm-snapshot)
+ [ウォームインデックスの手動スナップショット](#ultrawarm-manual-snapshot)
+ [ウォームインデックスをコールドストレージへ移行する](#ultrawarm-cold)
+ [KNN インデックスのベストプラクティス](#ultrawarm-recommendations)
+ [UltraWarm を無効にする](#ultrawarm-disable)
## 前提条件
UltraWarm には、重要な前提条件がいくつかあります。
+ UltraWarm には、OpenSearch または Elasticsearch 6.8 以降が必要です。
+ ウォームストレージを使用するには、ドメインに[専用のマスターノード](managedomains-dedicatedmasternodes.md)が必要です。
+ [スタンバイ付きマルチ AZ](managedomains-multiaz.md#managedomains-za-standby) ドメインを使用する場合、ウォームノードの数は、使用するアベイラビリティーゾーンの数の倍数である必要があります。
+ ドメインでデータノードに T2 または T3 インスタンスタイプが使用されている場合、ウォームストレージを使用することはできません。
+ インデックスが近似 k-NN (`"index.knn":true`) を使用している場合、バージョン 2.17 以降であれば、ウォームストレージに移すことができます。2.17 より前のバージョンのドメインは、2.17 にアップグレードすればこの機能を利用できますが、2.x より前のバージョンで作成された KNN インデックスについては、UltraWarm ストレージに移行することはできません。
+ ドメインで[きめ細かなアクセスコントロール](fgac.md)が使用されている場合、UltraWarm API 呼び出しを行うには、ユーザーが `ultrawarm_manager` ロールにマッピングされている必要があります。
**注記**
`ultrawarm_manager` ロールは、既存の OpenSearch Service ドメインによっては定義されない場合があります。Dashboards にロールが表示されない場合は、[それを手動で作成する](#ultrawarm-create-role)必要があります。
### 許可の設定
既存の OpenSearch Service ドメインで UltraWarm を有効した場合、`ultrawarm_manager` ロールがドメインで定義されない場合があります。きめ細かなアクセスコントロールを使用してドメインのウォームインデックスを管理するには、管理者以外のユーザーがこのロールにマッピングされている必要があります。`ultrawarm_manager` ロールを手動で作成するには、以下のステップを実行します。
1. OpenSearch Dashboards で、**[セキュリティ]** に進み、**[許可]** を選択します。
1. [**アクショングループの作成**] を選択し、以下のグループを設定します。
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ultrawarm.html)
1. **[ロール]**、**[ロールの作成]** の順に選択します。
1. ロールに **ultrawarm\_manager** という名前を付けます。
1. [**クラスターの許可**] では、`ultrawarm_cluster` および `cluster_monitor` を選択します。
1. [**インデックス**] では、`*` と入力します。
1. [**インデックスの許可**] では、`ultrawarm_index_read`、`ultrawarm_index_write`、および `indices_monitor` を選択します。
1. **[作成]** を選択します。
1. ロールを作成したら、任意のユーザーまたは UltraWarm インデックスを管理するバックエンドロールに[それをマッピング](fgac.md#fgac-mapping)します。
## UltraWarm ストレージの要件とパフォーマンスに関する考慮事項
[ストレージ要件の計算](bp-storage.md) で説明されているように、ホットストレージ内のデータには、レプリカ、Linux の予約済み領域、OpenSearch Service 予約済み領域という大きなオーバーヘッドが発生します。例えば、1 つのレプリカシャードを持つ 20 GiB プライマリシャードには、約 58 GiB のホットストレージが必要です。
UltraWarm では Amazon S3 を使用するため、このオーバーヘッドは発生しません。UltraWarm ストレージ要件を計算するときは、プライマリシャードのサイズのみを考慮します。S3 のデータの耐久性はレプリカの必要性を排除し、S3 はオペレーティングシステムやサービスの考慮事項を抽象化します。同じ 20 GiB シャードには、20 GiB のウォームストレージが必要です。`ultrawarm1.large.search` インスタンスをプロビジョニングする場合、プライマリシャードには最大ストレージの 20 TiB すべてを使用できます。インスタンスタイプの概要と、それぞれが対応できるストレージの最大容量については、「[UltraWarm ストレージのクォータ](limits.md#limits-ultrawarm)」を参照してください。
UltraWarm では、最大シャードサイズを 50 GiB にすることをお勧めします。[各 UltraWarm インスタンスタイプに割り当てられる CPU コアの数と RAM の量](#ultrawarm-pricing)は、同時に検索できるシャードの数のアイデアを提供します。S3 の UltraWarm ストレージにはプライマリシャードのみがカウントされますが、OpenSearch Dashboards および `_cat/indices` は、すべてのプライマリシャードとレプリカシャードの*合計*として UltraWarm インデックスサイズを引き続きレポートすることに注意してください。
例えば、各 `ultrawarm1.medium.search` インスタンスには 2 つの CPU コアがあり、S3 で最大 1.5 TiB のストレージに対応できます。これらのインスタンスのうちの 2 つには、3 TiB のストレージが組み合わされており、各シャードが 50 GiB の場合、約 62 のシャードになります。クラスターへのリクエストがこれらのシャードのうちの 4 つしか検索しない場合、パフォーマンスが優れている可能性があります。リクエストが広範で、それらの 62 すべてを検索する場合、4 つの CPU コアがオペレーションを実施しにくくなる可能性があります。`WarmCPUUtilization` および `WarmJVMMemoryPressure` [UltraWarm メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)をモニタリングして、インスタンスがワークロードをどのように処理するかを理解してください。
検索が広範または頻繁である場合、インデックスをホットストレージに残すことを検討してください。他の OpenSearch ワークロードと同様に、UltraWarm がニーズを満たしているかどうかを判断する最も重要なステップは、現実的なデータセットを使用して代表的なクライアントテストを実施することです。
## UltraWarm 料金設定
ホットストレージでは、プロビジョニングした分に対して料金を支払います。インスタンスにはアタッチされた Amazon EBS ボリュームが必要で、インスタンスストアが含まれるインスタンスもあります。そのストレージが空かいっぱいかに関係なく、同じ料金を支払います。
UltraWarm ストレージでは、使用した分に対して料金を支払います。`ultrawarm1.large.search` インスタンスは S3 で最大 20 TiB のストレージに対応できますが、1 TiB のデータを格納する場合、1 TiB のデータに対してのみ課金されます。他のすべてのノードタイプと同様に、UltraWarm ノードごとに時間料金も支払います。詳細については、「[Amazon OpenSearch Service の料金](what-is.md#pricing)」を参照してください。
## UltraWarm を有効にする
コンソールは、ウォームストレージを使用するドメインを作成する最も簡単な方法です。ドメインの作成時に、**[ウォームデータノードを有効にする]** を選択し、必要なウォームノード数を設定します。[前提条件](#ultrawarm-pp)を満たしていれば、既存のドメインでも同じ基本プロセスを使用できます。ドメインの状態が [**処理中**] から [**アクティブ**] になっても、UltraWarm が使用可能になるには数時間かかることがあります。
スタンバイ付きマルチ AZ ドメインを使用する場合、ウォームノードの数は、アベイラビリティーゾーンの数の倍数である必要があります。詳細については、「[Multi-AZ with Standby](managedomains-multiaz.md#managedomains-za-standby)」を参照してください。
UltraWarm は、[AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html) または[設定 API](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html) を使用して有効にすることもできます。具体的には、`ClusterConfig` の `WarmEnabled`、`WarmCount`、`WarmType` オプションを使用します。
**注記**
ドメインはウォームノードの最大数をサポートします。詳細については、「[Amazon OpenSearch Service クォータ](limits.md)」を参照してください。
### CLI コマンドの例
次の AWS CLI コマンドは、3 つのデータノード、3 つの専用マスターノード、6 つのウォームノード、およびきめ細かなアクセスコントロールが有効になっているドメインを作成します。
```
aws opensearch create-domain \
--domain-name {{my-domain}} \
--engine-version Opensearch_1.0 \
--cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.search \
--ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \
--node-to-node-encryption-options Enabled=true \
--encryption-at-rest-options Enabled=true \
--domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \
--advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName={{master-user}},MasterUserPassword={{master-password}}}' \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":["{{123456789012}}"]},"Action":["es:*"],"Resource":"arn:aws:es:{{us-west-1}}:{{123456789012}}:domain/{{my-domain}}/*"}]}' \
--region {{us-east-1}}
```
詳細については、「[AWS CLI コマンドのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/)」を参照してください。
### 設定 API リクエストの例
設定 API に対する次のリクエストは、有効にされたきめ細かなアクセスコントロールおよび制限されたアクセスポリシーを持つ、3 つのデータノード、3 つの専用マスターノード、および 6 つのウォームノードを持つドメインを作成します。
```
POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain
{
"ClusterConfig": {
"InstanceCount": 3,
"InstanceType": "r6g.large.search",
"DedicatedMasterEnabled": true,
"DedicatedMasterType": "r6g.large.search",
"DedicatedMasterCount": 3,
"ZoneAwarenessEnabled": true,
"ZoneAwarenessConfig": {
"AvailabilityZoneCount": 3
},
"WarmEnabled": true,
"WarmCount": 6,
"WarmType": "ultrawarm1.medium.search"
},
"EBSOptions": {
"EBSEnabled": true,
"VolumeType": "gp2",
"VolumeSize": 11
},
"EncryptionAtRestOptions": {
"Enabled": true
},
"NodeToNodeEncryptionOptions": {
"Enabled": true
},
"DomainEndpointOptions": {
"EnforceHTTPS": true,
"TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
},
"AdvancedSecurityOptions": {
"Enabled": true,
"InternalUserDatabaseEnabled": true,
"MasterUserOptions": {
"MasterUserName": "{{master-user}}",
"MasterUserPassword": "{{master-password}}"
}
},
"EngineVersion": "Opensearch_1.0",
"DomainName": "{{my-domain}}",
"AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"{{123456789012}}\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:{{us-east-1}}:{{123456789012}}:domain/{{my-domain}}/*\"}]}"
}
```
詳細については、「[Amazon OpenSearch Service API リファレンス](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)」を参照してください。
## UltraWarm ストレージへのインデックスの移行
インデックスへの書き込みが終了し、可能な限り高速な検索パフォーマンスを必要としなくなった場合は、インデックスをホットから UltraWarm に移行します。
```
POST _ultrawarm/migration/{{my-index}}/_warm
```
次に、移行のステータスを確認します。
```
GET _ultrawarm/migration/{{my-index}}/_status
{
"migration_status": {
"index": "{{my-index}}",
"state": "RUNNING_SHARD_RELOCATION",
"migration_type": "HOT_TO_WARM",
"shard_level_status": {
"running": 0,
"total": 5,
"pending": 3,
"failed": 0,
"succeeded": 2
}
}
}
```
移行を実施するには、インデックスヘルスが緑である必要があります。複数のインデックスを連続してすばやく移行する場合、`_cat` API と同様に、すべての移行の概要をプレーンテキストで取得できます。
```
GET _ultrawarm/migration/_status?v
index migration_type state
{{my-index}} HOT_TO_WARM RUNNING_SHARD_RELOCATION
```
OpenSearch Service は、一度に 1 つのインデックスを UltraWarm に移行します。キューには最大 200 の移行を設定できます。制限を超えるリクエストは拒否されます。キュー内の移行の現在の個数を確認するには、`HotToWarmMigrationQueueSize` [メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)をモニタリングします。インデックスは、移行プロセス全体を通して使用でき、ダウンタイムは発生しません。
移行プロセスには次の状態があります。
```
PENDING_INCREMENTAL_SNAPSHOT
RUNNING_INCREMENTAL_SNAPSHOT
FAILED_INCREMENTAL_SNAPSHOT
PENDING_FORCE_MERGE
RUNNING_FORCE_MERGE
FAILED_FORCE_MERGE
PENDING_FULL_SNAPSHOT
RUNNING_FULL_SNAPSHOT
FAILED_FULL_SNAPSHOT
PENDING_SHARD_RELOCATION
RUNNING_SHARD_RELOCATION
FINISHED_SHARD_RELOCATION
```
これらの状態が示すように、スナップショット、シャード再配置、強制マージ中に移行が失敗する可能性があります。スナップショットまたはシャード再配置中の障害は、通常、ノードの障害または S3 接続の問題が原因です。通常、ディスク領域の不足は、強制マージ失敗の根本的な原因です。
移行が完了すると、同じ `_status` リクエストでエラーが返されます。その時点でインデックスをチェックすると、ウォームインデックスに固有の設定が表示されます。
```
GET {{my-index}}/_settings
{
"{{my-index}}": {
"settings": {
"index": {
"refresh_interval": "-1",
"auto_expand_replicas": "false",
"provided_name": "{{my-index}}",
"creation_date": "1599241458998",
"unassigned": {
"node_left": {
"delayed_timeout": "5m"
}
},
"number_of_replicas": "1",
"uuid": "GswyCdR0RSq0SJYmzsIpiw",
"version": {
"created": "7070099"
},
"routing": {
"allocation": {
"require": {
"box_type": "warm"
}
}
},
"number_of_shards": "5",
"merge": {
"policy": {
"max_merge_at_once_explicit": "50"
}
}
}
}
}
}
```
+ `number_of_replicas` は、ディスク領域を消費しないパッシブレプリカの数です。
+ `routing.allocation.require.box_type` は、インデックスが標準データノードではなくウォームノードを使用するように指定します。
+ `merge.policy.max_merge_at_once_explicit` は、移行中に同時にマージするセグメントの数を指定します。
ウォームストレージのインデックスは、[ホットストレージに戻され](#ultrawarm-migrating-back)ない限り読み取り専用です。これにより、UltraWarm はログなどのイミュータブルなデータに最適となります。インデックスのクエリを行ってそれらを削除することはできますが、個々のドキュメントを追加、更新、削除することはできません。それらを行おうとすると、次のエラーが発生する場合があります。
```
{
"error" : {
"root_cause" : [
{
"type" : "cluster_block_exception",
"reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
}
],
"type" : "cluster_block_exception",
"reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"
},
"status" : 429
}
```
## 移行を自動化する
インデックスが特定の経過時間に達した後、または他の条件を満たした後の移行プロセスは、[Amazon OpenSearch Service でのインデックスステート管理](ism.md) を使用して自動化することをお勧めします。このワークフローを示す[サンプルポリシー](ism.md#ism-example-cold)を参照してください。
## 移行の調整
UltraWarm ストレージへのインデックスの移行には、強制マージが必要です。各 OpenSearch インデックスは、ある数のシャードで構成され、各シャードはある数の Lucene セグメントで構成されています。強制マージオペレーションは、削除対象としてマークされたドキュメントをパージし、ディスク領域を節約します。デフォルトでは、UltraWarm はインデックスを 1 つのセグメントにマージしますが、k-NN インデックスは例外となり、セグメント数のデフォルト値には 20 が使用されます。
`index.ultrawarm.migration.force_merge.max_num_segments` 設定を使用して、この値を最大 1,000 のセグメントに変更することができます。値を大きくすると、移行プロセスが高速になりますが、移行終了後のウォームインデックスのクエリレイテンシーが長くなります。設定を変更するには、次のリクエストを行います。
```
PUT {{my-index}}/_settings
{
"index": {
"ultrawarm": {
"migration": {
"force_merge": {
"max_num_segments": {{1}}
}
}
}
}
}
```
移行プロセスのこの段階でかかる時間を確認するには、`HotToWarmMigrationForceMergeLatency` [ メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)をモニタリングします。
## 移行をキャンセルする
UltraWarm は、キュー内の移行を順次処理します。移行がキューに入っていても、まだ開始していない場合は、次のリクエストを使用して移行をキューから削除できます。
```
POST _ultrawarm/migration/_cancel/{{my-index}}
```
ドメインできめ細かなアクセスコントロールを使用する場合は、このリクエストを行うための `indices:admin/ultrawarm/migration/cancel` 許可を持っている必要があります。
## ホットインデックスとウォームインデックスを一覧表示する
UltraWarm では、ホットインデックスとウォームインデックスの管理に役立つ `_all` と同様の 2 つのオプションが追加されています。すべてのウォームインデックスまたはホットインデックスのリストについては、次のリクエストを実行します。
```
GET _warm
GET _hot
```
これらのオプションは、インデックスを指定する次のようなリクエストで使用できます。
```
_cat/indices/_warm
_cluster/state/_all/_hot
```
## ウォームインデックスをホットストレージに戻す
インデックスに再度書き込む必要がある場合は、ホットストレージに移行し直します。
```
POST _ultrawarm/migration/{{my-index}}/_hot
```
ウォームストレージからホットストレージへの移行は、一度に最大 10 個までキューに入れることができます。OpenSearch Service は、移行リクエストをキューに入れられた順序で一度に 1 つずつ処理します。現在の個数を確認するには、`WarmToHotMigrationQueueSize` [メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)をモニタリングします。
移行が完了したら、インデックス設定をチェックして、ニーズを満たしていることを確認します。インデックスはホットストレージに戻り、1 つのレプリカが作成されます。
## スナップショットからのウォームインデックスの復元
UltraWarm では、自動スナップショット用の標準リポジトリに加えて、ウォームインデックス用の 2 つ目のリポジトリである `cs-ultrawarm` が追加されます。このリポジトリ内の各スナップショットには、1 つのインデックスしか含まれていません。ウォームインデックスを削除した場合、そのスナップショットは `cs-ultrawarm` リポジトリに 14 日間残ります。これは、他の自動スナップショットと同様です。
`cs-ultrawarm` からスナップショットを復元すると、ホットストレージではなくウォームストレージに復元されます。`cs-automated-enc` リポジトリと `cs-automated` リポジトリのスナップショットは、ホットストレージに復元されます。
**UltraWarm スナップショットをウォームストレージに復元するには**
1. 復元するインデックスを含む最新のスナップショットを特定します。
```
GET _snapshot/cs-ultrawarm/_all?verbose=false
{
"snapshots": [{
"snapshot": "{{snapshot-name}}",
"version": "1.0",
"indices": [
"{{my-index}}"
]
}]
}
```
**注記**
デフォルトでは、`GET _snapshot/` オペレーションは、リポジトリ内の各スナップショットの開始時間、終了時間、期間などの詳細なデータ情報を表示します。`GET _snapshot/` オペレーションは、リポジトリ内の各スナップショットのファイルから情報を取得します。開始時間、終了時間、期間は不要で、スナップショットの名前とインデックス情報のみが必要な場合、処理時間を最小限に抑えてタイムアウトを防ぐために、スナップショットを一覧表示する際に `verbose=false` パラメータを使用することをお勧めします。
1. インデックスがすでに存在する場合は、それを削除します。
```
DELETE {{my-index}}
```
インデックスを削除しない場合は、[それをホットストレージに戻し](#ultrawarm-migrating-back)、それの[再インデックス](https://docs.opensearch.org/latest/opensearch/reindex-data/)を行います。
1. スナップショットの復元:
```
POST _snapshot/cs-ultrawarm/{{snapshot-name}}/_restore
```
UltraWarm は、この復元リクエストで指定したインデックス設定をすべて無視しますが、`rename_pattern` および `rename_replacement` のようなオプションを指定することができます。OpenSearch スナップショットの復元オプションの概要については、「[OpenSearch ドキュメント](https://docs.opensearch.org/latest/opensearch/snapshot-restore/#restore-snapshots)」を参照してください。
## ウォームインデックスの手動スナップショット
ウォームインデックスの手動スナップショットを取得することは*可能*ですが、推奨されません。自動化された `cs-ultrawarm` リポジトリには、移行中に取得された各ウォームインデックスのスナップショットがすでに含まれており、追加料金は発生しません。
デフォルトでは、OpenSearch Service は手動スナップショットにウォームインデックスを含めません。例えば、次の呼び出しには、ホットインデックスしか含まれていません。
```
PUT _snapshot/{{my-repository}}/{{my-snapshot}}
```
ウォームインデックスの手動スナップショットを取得することを選択した場合は、いくつかの重要な考慮事項が適用されます。
+ ホットインデックスとウォームインデックスを混合することはできません。例えば、以下のコマンドは失敗します。
```
PUT _snapshot/{{my-repository}}/{{my-snapshot}}
{
"indices": "{{warm-index-1}},{{hot-index-1}}",
"include_global_state": false
}
```
ホットインデックスとウォームインデックスの混合が含まれている場合は、ワイルドカード (`*`) ステートメントも失敗します。
+ スナップショットあたり 1 つのウォームインデックスしか含めることができません。例えば、以下のコマンドは失敗します。
```
PUT _snapshot/{{my-repository}}/{{my-snapshot}}
{
"indices": "{{warm-index-1}},{{warm-index-2}},{{other-warm-indices-*}}",
"include_global_state": false
}
```
このリクエストは成功します。
```
PUT _snapshot/{{my-repository}}/{{my-snapshot}}
{
"indices": "{{warm-index-1}}",
"include_global_state": false
}
```
+ 手動スナップショットは、もともとウォームインデックスが含まれていても、常にホットストレージに復元されます。
## ウォームインデックスをコールドストレージへ移行する
クエリ頻度の低いデータが UltraWarm にある場合は、それをコールドストレージに移行することを検討してください。コールドストレージは、ときどきしかアクセスしないデータや、使用されなくなったデータを対象としています。コールドインデックスを読み書きすることはできませんが、クエリを行う必要があるときはいつでも無償でウォームストレージに移行できます。手順については、「[コールドストレージへのインデックスの移行](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html#coldstorage-migrating)」を参照してください。
## KNN インデックスのベストプラクティス
+ Ultrawarm/Cold 階層は、すべての KNN インデックスエンジンタイプで使用できます。Lucene エンジンおよびディスク最適化ベクトル検索を使用する KNN インデックスに推奨されます。これらは、グラフデータをオフヒープメモリに完全にロードする必要がないためです。FAISS や NMSLIB などのネイティブインメモリエンジンで使用する場合、アクティブに検索されるシャードのグラフサイズを考慮し、それに応じて UltraWarm インスタンス (`uw.large` インスタンスタイプが望ましい) をプロビジョニングする必要があります。例えば、2 つの `uw.large` インスタンスが設定されている場合、それぞれのインスタンスには約 `knn.memory.circuit_breaker.limit * 61` GiB のオフヒープメモリが利用可能になります。すべてのウォームクエリによって対象とされるシャードの累積グラフサイズが利用可能なオフヒープメモリを超えない場合、最適なパフォーマンスが得られます。利用可能なメモリがグラフのロードに必要な量よりも少ない場合、エビクションや、オフヒープメモリが利用可能になるまでの待機が発生するため、レイテンシーに影響します。そのため、インメモリエンジンが使用されているユースケースや、エンジンに関係なく検索スループットが高いユースケースには、`uw.medium` インスタンスを使用することは推奨されません。
+ KNN インデックスは、UltraWarm に移行する際に 1 つのセグメントに強制マージされることはありません。これにより、グラフサイズがインメモリエンジンにとって大きくなりすぎることが原因で、ホットノードやウォームノードで OOM 問題が発生する影響を回避できます。シャードあたりのセグメント数の増加により、ローカルキャッシュスペースの消費が増え、ウォーム階層に移行できるインデックスが少なくなる可能性があります。既存の設定を使用し、ウォーム階層への移行前にその設定値を上書きすることで、インデックスを 1 つのセグメントに強制マージすることもできます。詳細については、「[移行の調整](#ultrawarm-settings)」を参照してください。
+ インデックスの検索頻度が低く、レイテンシーの影響を受けやすいワークロードを処理しないユースケースがある場合は、それらのインデックスを UltraWarm 階層に移行することができます。そうすることで、このような優先度の低いインデックスへのクエリは UltraWarm 階層のコンピューティングに処理させて、ホット階層のコンピューティングインスタンスをスケールダウンすることができます。また、優先度の低いインデックスと高いインデックスのクエリで消費されるリソースを分離できるため、互いに影響を与えないようにすることができます。
## UltraWarm を無効にする
UltraWarm を無効にする最も簡単な方法は、コンソールを使用することです。ドメインを選択し、**[アクション]** から **[クラスター設定の編集]** を選択します。**[UltraWarm データノードを有効にする]** の選択を解除し、**[変更を保存する]** を選択します。 AWS CLI および設定 API で `WarmEnabled` オプションを使用することもできます。
UltraWarm を無効にする前に、[すべてのウォームインデックスを削除する](https://opensearch.org/docs/latest/opensearch/rest-api/index-apis/delete-index/) か、[ホットストレージに移行する](#ultrawarm-migrating-back) 必要があります。ウォームストレージが空になったら、5 分待ってから UltraWarm を無効にします。