翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service のコールドストレージ
コールドストレージを使用すると、アクセス頻度の低いデータや履歴データを Amazon OpenSearch Service ドメインに保存し、他のストレージ階層よりも低コストでオンデマンドで分析できます。古いデータに対して定期的な調査や法医学分析を行う必要がある場合は、コールドストレージが適しています。コールドストレージに適したデータの実際的な例としては、アクセス頻度の低いログ、コンプライアンス要件を満たすために保存する必要があるデータ、履歴価値のあるログなどがあります。
UltraWarm ストレージと同様に、コールドストレージは Amazon S3 によってバックアップされます。コールドデータをクエリする必要がある場合は、既存の UltraWarmノードにデータを選択的にアタッチできます。コールドデータの移行とライフサイクルは、手動で、またはインデックスステート管理ポリシーを使用して管理できます。
トピック
前提条件
コールドストレージには、次の前提条件があります。
-
コールドストレージには、 OpenSearch または Elasticsearch バージョン 7.9 以降が必要です。
-
OpenSearch サービスドメインでコールドストレージを有効にするには、同じドメイン UltraWarm で も有効にする必要があります。
-
コールドストレージを使用するには、ドメインに専用のマスターノードがある必要があります。
-
ドメインでデータノードに T2 または T3 インスタンスタイプが使用されている場合、コールドストレージを使用することはできません。
-
インデックスがおおよその k-NN (
"index.knn":true
) を使用している場合は、バージョン 2.17 以降からコールドストレージに移動できます。2.17 より前のバージョンのドメインではこの機能を使用するように 2.17 にアップグレードできますが、2.x より前のバージョンで作成されたKNNインデックスは Cold に移行できません。 -
ドメインがきめ細かなアクセスコントロールを使用している場合、管理者以外のユーザーは、コールドインデックスを管理するために OpenSearch Dashboards の
cold_manager
ロールにマッピングする必要があります。
注記
cold_manager
ロールは、既存の OpenSearch サービスドメインに存在しない場合があります。Dashboards にロールが表示されない場合は、それを手動で作成する必要があります。
許可の設定
既存の OpenSearch サービスドメインでコールドストレージを有効にすると、cold_manager
ロールがドメインで定義されていない可能性があります。ドメインがきめ細かなアクセスコントロールを使用する場合、管理者以外のユーザーは、コールドインデックスを管理するためにこのロールにマッピングされている必要があります。cold_manager
ロールを手動で作成するには、以下のステップを実行します。
-
OpenSearch ダッシュボードで、セキュリティに移動し、アクセス許可を選択します。
-
[アクショングループの作成] を選択し、以下のグループを設定します。
グループ名 許可 cold_cluster
-
cluster:monitor/nodes/stats
-
cluster:admin/ultrawarm*
-
cluster:admin/cold/*
cold_index
-
indices:monitor/stats
-
indices:data/read/minmax
-
indices:admin/ultrawarm/migration/get
-
indices:admin/ultrawarm/migration/cancel
-
-
[ロール]、[ロールの作成] の順に選択します。
-
ロールに cold_manager という名前を付けます。
-
[クラスターの許可] の場合、作成した
cold_cluster
グループを選択します。 -
[インデックス] の場合、
*
と入力します。 -
インデックスの許可] の場合、作成した
cold_index
グループを選択します。 -
[Create] (作成) を選択します。
-
ロールを作成したら、コールドインデックスを管理する任意のユーザーまたはバックエンドロールにそれをマッピングします。
コールドストレージの要件とパフォーマンスに関する考慮事項
コールドストレージは Amazon S3 を使用するため、レプリカ、Linux リザーブドスペース、 OpenSearch サービスリザーブドスペースなどのホットストレージのオーバーヘッドは発生しません。コールドストレージには、コンピューティング性能がアタッチされていないため、特定のインスタンスタイプはありません。コールドストレージには、任意の量のデータを保存できます。Amazon の ColdStorageSpaceUtilization
メトリクスをモニタリング CloudWatch して、使用しているコールドストレージ容量を確認します。
コールドストレージの料金
UltraWarm ストレージと同様に、コールドストレージではデータストレージに対してのみ料金が発生します。コールドデータにはコンピューティングコストはないので、コールドストレージにデータがない場合、課金されることはありません。
コールドストレージとウォームストレージ間でデータを移動する場合、転送料金は発生しません。インデックスがウォームストレージとコールドストレージ間で移行されている間、インデックスの 1 つのコピーに対してのみ、継続して料金が発生します。移行が完了すると、インデックスは、移行先のストレージ階層に従って課金されます。コールドストレージの料金の詳細については、「Amazon OpenSearch サービスの料金
コールドストレージを有効にする
コンソールは、コールドストレージを使用するドメインを作成する最も簡単な方法です。ドメインを作成している間に、[コールドストレージを有効にする] を選択します。前提条件を満たしている限り、既存のドメインでも同じプロセスを使用できます。ドメインの状態が [処理中] から [アクティブ] になっても、コールドストレージが使用可能になるには数時間かかることがあります。
AWS CLI
サンプル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
}' \ --regionus-east-2
詳細については、「AWS CLI コマンドのリファレンス」を参照してください。
サンプル設定APIリクエスト
設定に対する次のリクエストは、3 つのデータノード、3 つの専用マスターノード、コールドストレージが有効で、きめ細かなアクセスコントロールが有効になっているドメインAPIを作成します。
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 Reference」を参照してください。
OpenSearch Dashboards でのコールドインデックスの管理
OpenSearch サービスドメイン内の既存の Dashboards インターフェイスを使用して、ホットインデックス、ウォームインデックス、コールドインデックスを管理できます。ダッシュボードを使用すると、 CLIまたは 設定を使用せずに、ウォームストレージとコールドストレージの間でインデックスを移行し、インデックスの移行ステータスをモニタリングできますAPI。詳細については、 OpenSearch 「 Dashboards でのインデックスの管理」を参照してください。
コールドストレージへのインデックスの移行
インデックスをコールドストレージに移行する場合、データの時間範囲を指定して簡単に検出できるようにします。インデックス内のデータに基づいてタイムスタンプフィールドを選択するか、開始タイムスタンプと終了タイムスタンプを手動で指定するか、それを指定しないように選択することができます。
パラメータ | サポートされている値 | 説明 |
---|---|---|
timestamp_field |
インデックスマッピングの日付/時刻フィールド。 |
指定されたフィールドの最小値と最大値が計算され、コールドインデックスの |
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 サービスは、一度に 1 つのインデックスをコールドストレージに移行します。キューには最大 100 の移行を設定できます。制限を超えるリクエストは拒否されます。キュー内の移行の現在の個数を確認するには、WarmToColdMigrationQueueSize
メトリクスをモニタリングします。移行プロセスには次の状態があります。
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.
コールドストレージへの移行の自動化
インデックスが特定の経過時間に達した後、または他の条件を満たした後の移行プロセスは、インデックスステート管理を使用して自動化することができます。インデックスをホットストレージから 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
メトリクスをモニタリングします。移行プロセスには次の状態があります。
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.
スナップショットからのコールドインデックスの復元
削除されたコールドインデックスを復元する必要がある場合は、「スナップショットからのウォームインデックスの復元」の手順に従ってから、そのインデックスを再度コールド階層に移行することで、ウォーム層に復元できます。削除されたコールドインデックスをコールド階層に直接復元することはできません。 OpenSearch コールドインデックスは、削除されてから 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
を更新することはできません。
コールドインデックスの削除
ISM ポリシーを使用していない場合は、コールドインデックスを手動で削除できます。次のリクエストは、コールドインデックスを削除します。
DELETE _cold/
my-index
{ "acknowledged" : true }
コールドストレージを無効にする
コールドストレージを無効にする最も簡単な方法は、 OpenSearch サービスコンソールです。ドメインを選択し、[アクション] から [クラスター設定の編集] を選択し、[コールドストレージを有効にする] の選択を解除します。
または 設定を使用するには AWS CLIAPI、 で ColdStorageOptions
を設定します"Enabled"="false"
。
コールドストレージを無効にする前に、すべてのコールドインデックスを削除するか、ウォームストレージに移行する必要があります。そうしないと、無効アクションは失敗します。