翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service 用コールドストレージ
コールドストレージでは、アクセス頻度の低いデータや履歴データを Amazon OpenSearch Service ドメインに保存し、他のストレージ階層よりも低コストで、オンデマンドで分析できます。古いデータに対して定期的な調査や法医学分析を行う必要がある場合は、コールドストレージが適しています。コールドストレージに適したデータの実際的な例としては、アクセス頻度の低いログ、コンプライアンス要件を満たすために保存する必要があるデータ、履歴価値のあるログなどがあります。
[UltraWarm](ultrawarm.md) ストレージと同様に、コールドストレージは Amazon S3 によってバックアップされます。コールドデータをクエリする必要がある場合は、既存の UltraWarm ノードに選択的にアタッチできます。コールドデータの移行とライフサイクルは、手動で、またはインデックスステート管理ポリシーを使用して管理できます。
**Topics**
+ [前提条件](#coldstorage-pp)
+ [コールドストレージの要件とパフォーマンスに関する考慮事項](#coldstorage-calc)
+ [コールドストレージの料金](#coldstorage-pricing)
+ [コールドストレージを有効にする](#coldstorage-enable)
+ [OpenSearch Dashboards でのコールドインデックスの管理](#coldstorage-dashboards)
+ [コールドストレージへのインデックスの移行](#coldstorage-migrating)
+ [コールドストレージへの移行の自動化](#coldstorage-ism)
+ [コールドストレージへの移行のキャンセル](#coldstorage-cancel)
+ [コールドインデックスの一覧表示](#coldstorage-list)
+ [ウォームストレージへのインデックスの移行](#coldstorage-migrating-back)
+ [スナップショットからのコールドインデックスの復元](#cold-snapshot)
+ [コールドストレージからウォームストレージへの移行のキャンセル](#coldtowarm-cancel)
+ [コールドインデックスメタデータの更新](#cold-update-metadata)
+ [コールドインデックスの削除](#cold-delete)
+ [コールドストレージを無効にする](#coldstorage-disable)
## 前提条件
コールドストレージには、次の前提条件があります。
+ コールドストレージには、OpenSearch または Elasticsearch バージョン 7.9 以降が必要です
+ OpenSearch Service ドメインでコールドストレージを有効にするには、同じドメインでウォームストレージも有効にしておく必要があります。
+ コールドストレージを使用するには、ドメインに[専用のマスターノード](managedomains-dedicatedmasternodes.md)がある必要があります。
+ ドメインでデータノードに T2 または T3 インスタンスタイプが使用されている場合、コールドストレージを使用することはできません。
+ インデックスが近似 k-NN (`"index.knn":true`) を使用している場合、バージョン 2.17 以降ではインデックスをコールドストレージに移動できます。2.17 以前のバージョンのドメインの場合、 2.17 にアップグレードしてこの機能を使用することはできますが、2.x 以前のバージョンで作成された KNN インデックスをコールドストレージに移動することはできません。
+ ドメインが[きめ細かなアクセスコントロール](fgac.md)を使用する場合、管理者以外のユーザーは、コールドインデックスを管理するために OpenSearch Dashboards の `cold_manager` ロールに[マッピングされている](fgac.md#fgac-mapping)必要があります。
**注記**
`cold_manager` ロールが既存の OpenSearch Service ドメインに存在しない可能性があります。Dashboards にロールが表示されない場合は、[それを手動で作成する](#coldstorage-create-role)必要があります。
### 許可の設定
既存の OpenSearch Service ドメインでコールドストレージを有効にした場合、`cold_manager` ロールが定義されていない可能性があります。ドメインが[きめ細かなアクセスコントロール](fgac.md)を使用する場合、管理者以外のユーザーは、コールドインデックスを管理するためにこのロールにマッピングされている必要があります。`cold_manager` ロールを手動で作成するには、以下のステップを実行します。
1. OpenSearch Dashboards で、**[セキュリティ]** に進み、**[許可]** を選択します。
1. [**アクショングループの作成**] を選択し、以下のグループを設定します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/cold-storage.html)
1. [**ロール**]、[**ロールの作成**] の順に選択します。
1. ロールに **cold\$1manager** という名前を付けます。
1. [**クラスターの許可**] の場合、作成した `cold_cluster` グループを選択します。
1. [**インデックス**] の場合、`*` と入力します。
1. **インデックスの許可**] の場合、作成した `cold_index` グループを選択します。
1. **[作成]** を選択します。
1. ロールを作成したら、コールドインデックスを管理する任意のユーザーまたはバックエンドロールに[それをマッピング](fgac.md#fgac-mapping)します。
## コールドストレージの要件とパフォーマンスに関する考慮事項
コールドストレージは Simple Storage Service (Amazon S3) を使用するため、レプリカ、Linux 予約容量、OpenSearch Service 予約容量など、ホットストレージのオーバーヘッドは発生しません。コールドストレージには、コンピューティング性能がアタッチされていないため、特定のインスタンスタイプはありません。コールドストレージには、任意の量のデータを保存できます。Amazon CloudWatch の `ColdStorageSpaceUtilization` メトリクスをモニタリングして、使用しているコールドストレージ容量の量を確認します。
## コールドストレージの料金
UltraWarm ストレージと同様に、コールドストレージでは、データストレージに対してのみ課金されます。コールドデータにはコンピューティングコストはないので、コールドストレージにデータがない場合、課金されることはありません。
コールドストレージとウォームストレージ間でデータを移動する場合、転送料金は発生しません。インデックスがウォームストレージとコールドストレージ間で移行されている間、インデックスの 1 つのコピーに対してのみ、継続して料金が発生します。移行が完了すると、インデックスは、移行先のストレージ階層に従って課金されます。コールドストレージの料金の詳細については、「[Amazon OpenSearch Service の料金](https://aws.amazon.com/opensearch-service/pricing/)」を参照してください。
## コールドストレージを有効にする
コンソールは、コールドストレージを使用するドメインを作成する最も簡単な方法です。ドメインの作成中に、まず **[ウォームデータノードを有効にする]** を選択します。これは、同じドメインでウォームストレージを有効にしておく必要があるためです。次に、**[コールドストレージを有効にする]** を選択します。
[前提条件](#coldstorage-pp)を満たしている限り、既存のドメインでも同じプロセスを使用できます。ドメインの状態が [**処理中**] から [**アクティブ**] になっても、コールドストレージが使用可能になるには数時間かかることがあります。
[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) を使用して、コールドストレージを有効にすることもできます。
### CLI コマンドの例
次の AWS CLI コマンドは、3 つのデータノード、3 つの専用マスターノード、コールドストレージが有効で、きめ細かなアクセスコントロールが有効になっているドメインを作成します。
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version Opensearch_1.0 \
--cluster-config ColdStorageOptions={Enabled=true},WarmEnabled=true,WarmCount=4,WarmType=ultrawarm1.medium.search,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,InstanceCount=3 \
--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}' \
--region us-east-2
```
詳細については、「[AWS CLI コマンドのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/)」を参照してください。
### 設定 API リクエストの例
設定 API に対する次のリクエストにより、3 つのデータノード、3 つの専用マスターノード、有効になっているコールドストレージ、および有効になっているきめ細かなアクセスコントロールがあるドメインが作成されます。
```
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": 4,
"WarmType": "ultrawarm1.medium.search",
"ColdStorageOptions": {
"Enabled": true
}
},
"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"
}
```
詳細については、「[Amazon OpenSearch Service API リファレンス](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)」を参照してください。
## OpenSearch Dashboards でのコールドインデックスの管理
OpenSearch Service ドメインの既存の Dashboards インターフェイスを使用して、ホット、ウォーム、およびコールドインデックスを管理できます。Dashboards を使用すると、CLI や設定 API を使用することなく、ウォームストレージとコールドストレージ間でインデックスを移行し、インデックスの移行ステータスをモニタリングできます。詳細については、[OpenSearch Dashboards でのインデックスの管理](dashboards.md#dashboards-indices)を参照してください。
## コールドストレージへのインデックスの移行
インデックスをコールドストレージに移行する場合、データの時間範囲を指定して簡単に検出できるようにします。インデックス内のデータに基づいてタイムスタンプフィールドを選択するか、開始タイムスタンプと終了タイムスタンプを手動で指定するか、それを指定しないように選択することができます。
| パラメータ | サポートされている値 | 説明 |
| --- | --- | --- |
| timestamp\$1field | インデックスマッピングの日付/時刻フィールド。 | 指定されたフィールドの最小値と最大値が計算され、コールドインデックスの `start_time` および `end_time` メタデータとして保存されます。 |
| start\$1time: および end\$1time | 以下の形式のいずれか。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/cold-storage.html) | 指定された値は、コールドインデックスの `start_time` および `end_time` メタデータとして保存されます。 |
タイムスタンプを指定しない場合は、代わりに `?ignore=timestamp` をリクエストに追加します。
次のリクエストは、ウォームインデックスをコールドストレージに移行し、そのインデックスのデータの開始時刻と終了時刻を提供します。
```
POST _ultrawarm/migration/my-index/_cold
{
"start_time": "2020-03-09",
"end_time": "2020-03-09T23:00:00Z"
}
```
次に、移行のステータスを確認します。
```
GET _ultrawarm/migration/my-index/_status
{
"migration_status": {
"index": "my-index",
"state": "RUNNING_METADATA_RELOCATION",
"migration_type": "WARM_TO_COLD"
}
}
```
OpenSearch Service は、一度に 1 つのインデックスをコールドストレージに移行します。キューには最大 100 の移行を設定できます。制限を超えるリクエストは拒否されます。キュー内の移行の現在の個数を確認するには、`WarmToColdMigrationQueueSize` [メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage)をモニタリングします。移行プロセスには次の状態があります。
```
ACCEPTED_COLD_MIGRATION - Migration request is accepted and queued.
RUNNING_METADATA_MIGRATION - The migration request was selected for execution and metadata is migrating to cold storage.
FAILED_METADATA_MIGRATION - The attempt to add index metadata has failed and all retries are exhausted.
PENDING_INDEX_DETACH - Index metadata migration to cold storage is completed. Preparing to detach the warm index state from the local cluster.
RUNNING_INDEX_DETACH - Local warm index state from the cluster is being removed. Upon success, the migration request will be completed.
FAILED_INDEX_DETACH - The index detach process failed and all retries are exhausted.
```
## コールドストレージへの移行の自動化
インデックスが特定の経過時間に達した後、または他の条件を満たした後の移行プロセスは、[インデックスステート管理](ism.md)を使用して自動化することができます。[ポリシーの例](ism.md#ism-example-cold)を参照してください。これは、インデックスをホットストレージから UltraWarm へ、またコールドストレージへと自動的に移行する方法を示しています。
**注記**
インデックスステート管理ポリシーを使用してインデックスをコールドストレージに移動するには、明示的な `timestamp_field` が必要です。
## コールドストレージへの移行のキャンセル
コールドストレージへの移行がキューに追加されているか、失敗状態にある場合は、次のリクエストを使用して移行をキャンセルできます。
```
POST _ultrawarm/migration/_cancel/my-index
{
"acknowledged" : true
}
```
ドメインがきめ細かなアクセスコントロールを使用している場合、このリクエストを行うには `indices:admin/ultrawarm/migration/cancel` 許可が必要です。
## コールドインデックスの一覧表示
クエリを実行する前に、コールドストレージ内のインデックスを一覧表示して、詳細な分析のために UltraWarm に移行するインデックスを決定できます。次のリクエストは、すべてのコールドインデックスをインデックス名でソートして一覧表示します。
```
GET _cold/indices/_search
```
**レスポンス例**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 3,
"indices" : [
{
"index" : "my-index-1",
"index_cold_uuid" : "hjEoh26mRRCFxRIMdgvLmg",
"size" : 10339,
"creation_date" : "2021-06-28T20:23:31.206Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-2",
"index_cold_uuid" : "0vIS2n-oROmOWDFmwFIgdw",
"size" : 6068,
"creation_date" : "2021-07-15T19:41:18.046Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-3",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
### フィルタリング
プレフィックスベースのインデックスパターンと時間範囲のオフセットに基づいて、コールドインデックスをフィルタリングできます。
次のリクエストは、`event-*` のプレフィックスパターンに一致するインデックスを一覧表示します。
```
GET _cold/indices/_search
{
"filters":{
"index_pattern": "event-*"
}
}
```
**レスポンス例**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "events-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
次のリクエストは、`2019-03-01` および `2020-03-01` の間の `start_time` と `end_time` のメタデータフィールドを持つインデックスを返します。
```
GET _cold/indices/_search
{
"filters": {
"time_range": {
"start_time": "2019-03-01",
"end_time": "2020-03-01"
}
}
}
```
**レスポンス例**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 1,
"indices" : [
{
"index" : "my-index",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2019-05-09T00:00Z",
"end_time" : "2019-09-09T23:00Z"
}
]
}
```
### ソート
コールドインデックスは、インデックス名やサイズなどのメタデータフィールドによって並べ替えることができます。次のリクエストは、サイズを降順で並べ替えたすべてのインデックスを一覧表示します。
```
GET _cold/indices/_search
{
"sort_key": "size:desc"
}
```
**レスポンス例**
```
{
"pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY",
"total_results" : 5,
"indices" : [
{
"index" : "my-index-6",
"index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA",
"size" : 32263273,
"creation_date" : "2021-08-18T18:25:31.845Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-9",
"index_cold_uuid" : "mbD3ZRVDRI6ONqgEOsJyUA",
"size" : 57922,
"creation_date" : "2021-07-07T23:41:35.640Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
},
{
"index" : "my-index-5",
"index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ",
"size" : 32403,
"creation_date" : "2021-07-08T00:12:01.523Z",
"start_time" : "2020-03-09T00:00Z",
"end_time" : "2020-03-09T23:00Z"
}
]
}
```
その他の有効なソートキーは、`start_time:asc/desc`、`end_time:asc/desc`、および `index_name:asc/desc` です。
### Pagination (ページ分割)
コールドインデックスのリストをページ分割できます。`page_size` パラメータを使用して、ページごとに返されるインデックスの数を設定します (デフォルトは 10)。コールドインデックスのすべての `_search` リクエストは、後続の呼び出しに使用できる `pagination_id` を返します。
次のリクエストは、コールドインデックスの `_search` リクエストの結果をページ分割で表示し、次の 100 件の結果を表示します。
```
GET _cold/indices/_search?page_size=100
{
"pagination_id": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY"
}
```
## ウォームストレージへのインデックスの移行
前のセクションでフィルタリング基準を用いてコールドインデックスのリストを絞り込んだ後、それらを UltraWarm に移行してデータのクエリを行い、それを使用して可視化を作成できます。
次のリクエストは、2 つのコールドインデックスをウォームストレージに移行します。
```
POST _cold/migration/_warm
{
"indices": "my-index1,my-index2"
}
{
"acknowledged" : true
}
```
移行のステータスを確認して移行 ID を取得するには、次のリクエストを送信します。
```
GET _cold/migration/_status
```
**レスポンス例**
```
{
"cold_to_warm_migration_status" : [
{
"migration_id" : "tyLjXCA-S76zPQbPVHkOKA",
"indices" : [
"my-index1,my-index2"
],
"state" : "RUNNING_INDEX_CREATION"
}
]
}
```
インデックス固有の移行情報を取得するには、インデックス名を含めます。
```
GET _cold/migration/my-index/_status
```
インデックスを指定するのではなく、現在の移行ステータス別にインデックスを一覧表示できます。有効な値は、`_failed`、`_accepted`、`_all` です。
次のコマンドは、単一の移行リクエスト内のすべてのインデックスのステータスを取得します。
```
GET _cold/migration/_status?migration_id=my-migration-id
```
ステータスリクエストを使用して移行 ID を取得します。移行の詳細については、`&verbose=true` を追加します。
コールドストレージからウォームストレージには 10 またはそれ未満のバッチ数でインデックスを移行できます。最大で 100 インデックスを同時に移行できます。制限を超えるリクエストは拒否されます。現在、移行中の個数を確認するには、`ColdToWarmMigrationQueueSize` [メトリクス](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-coldstorage)をモニタリングします。移行プロセスには次の状態があります。
```
ACCEPTED_MIGRATION_REQUEST - Migration request is accepted and queued.
RUNNING_INDEX_CREATION - Migration request is picked up for processing and will create warm indexes in the cluster.
PENDING_COLD_METADATA_CLEANUP - Warm index is created and the migration service will attempt to clean up cold metadata.
RUNNING_COLD_METADATA_CLEANUP - Cleaning up cold metadata from the indexes migrated to warm storage.
FAILED_COLD_METADATA_CLEANUP - Failed to clean up metadata in the cold tier.
FAILED_INDEX_CREATION - Failed to create an index in the warm tier.
```
## スナップショットからのコールドインデックスの復元
削除されたコールドインデックスを復元する必要がある場合は、「[スナップショットからのウォームインデックスの復元](ultrawarm.md#ultrawarm-snapshot)」の手順に従ってから、そのインデックスを再度コールド階層に移行することで、ウォーム層に復元できます。削除されたコールドインデックスをコールド階層に直接復元することはできません。OpenSearch Service は、コールドインデックスが削除された後、それらを 14 日間保持します。
## コールドストレージからウォームストレージへの移行のキャンセル
コールドストレージからウォームストレージへのインデックスの移行がキューに追加されているか、失敗状態にある場合は、次のリクエストを用いてそれをキャンセルできます。
```
POST _cold/migration/my-index/_cancel
{
"acknowledged" : true
}
```
インデックスのバッチ (一度に最大 10 個) の移行をキャンセルするには、移行 ID を指定します。
```
POST _cold/migration/_cancel?migration_id=my-migration-id
{
"acknowledged" : true
}
```
ステータスリクエストを使用して移行 ID を取得します。
## コールドインデックスメタデータの更新
コールドインデックスの `start_time` および `end_time` フィールドを更新できます。
```
PATCH _cold/my-index
{
"start_time": "2020-01-01",
"end_time": "2020-02-01"
}
```
コールドストレージのインデックスの `timestamp_field` を更新することはできません。
**注記**
OpenSearch Dashboards は PATCH メソッドをサポートしていません。[curl](https://curl.haxx.se/)、[Postman](https://www.getpostman.com/)、または他のメソッドを使用して、コールドメタデータを更新します。
## コールドインデックスの削除
ISM ポリシーを使用していない場合は、コールドインデックスを手動で削除できます。次のリクエストは、コールドインデックスを削除します。
```
DELETE _cold/my-index
{
"acknowledged" : true
}
```
## コールドストレージを無効にする
OpenSearch Service コンソールは、コールドストレージを無効にする最も簡単な方法です。ドメインを選択し、[**アクション**] から [**クラスター設定の編集**] を選択し、[**コールドストレージを有効にする**] の選択を解除します。
CLI または設定 API AWS を使用するには、 で `ColdStorageOptions`を設定します`"Enabled"="false"`。
コールドストレージを無効にする前に、すべてのコールドインデックスを削除するか、ウォームストレージに移行する必要があります。そうしないと、無効アクションは失敗します。