Amazon OpenSearch Service 用コールドストレージ - Amazon OpenSearch サービス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon OpenSearch Service 用コールドストレージ

コールドストレージでは、アクセス頻度の低いデータや履歴データを Amazon OpenSearch Service ドメインに保存し、他のストレージ階層よりも低コストで、オンデマンドで分析できます。古いデータに対して定期的な調査や法医学分析を行う必要がある場合は、コールドストレージが適しています。コールドストレージに適したデータの実際的な例としては、アクセス頻度の低いログ、コンプライアンス要件を満たすために保存する必要があるデータ、履歴価値のあるログなどがあります。

UltraWarm ストレージと同様に、コールドストレージは Amazon S3 によってバックアップされます。コールドデータをクエリする必要がある場合は、既存の UltraWarm ノードに選択的にアタッチできます。コールドデータの移行とライフサイクルは、手動で、またはインデックスステート管理ポリシーを使用して管理できます。

前提条件

コールドストレージには、次の前提条件があります。

  • コールドストレージには、OpenSearch または Elasticsearch バージョン 7.9 以降が必要です

  • OpenSearch Service ドメインでコールドストレージを有効にするには、同じドメインで UltraWarm も有効にする必要があります。

  • コールドストレージを使用するには、ドメインに専用のマスターノードがある必要があります。

  • ドメインでデータノードに T2 または T3 インスタンスタイプが使用されている場合、コールドストレージを使用することはできません。

  • Zstandard 圧縮コーデック ("index.codec": "zstd" または "index.codec": "zstd_no_dict") を使用するインデックスをコールドストレージに移動することはできません。

  • インデックスがおおよその k-NN ("index.knn": true) を使用している場合、コールドストレージに移すことはできません。

  • ドメインがきめ細かなアクセスコントロールを使用する場合、管理者以外のユーザーは、コールドインデックスを管理するために OpenSearch Dashboards の cold_manager ロールにマッピングされている必要があります。

注記

cold_manager ロールが既存の OpenSearch Service ドメインに存在しない可能性があります。Dashboards にロールが表示されない場合は、それを手動で作成する必要があります。

許可の設定

既存の OpenSearch Service ドメインでコールドストレージを有効にした場合、cold_manager ロールが定義されていない可能性があります。ドメインがきめ細かなアクセスコントロールを使用する場合、管理者以外のユーザーは、コールドインデックスを管理するためにこのロールにマッピングされている必要があります。cold_manager ロールを手動で作成するには、以下のステップを実行します。

  1. OpenSearch Dashboards で、[セキュリティ] に進み、[許可] を選択します。

  2. [アクショングループの作成] を選択し、以下のグループを設定します。

    グループ名 許可
    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

  3. [ロール]、[ロールの作成] の順に選択します。

  4. ロールに cold_manager という名前を付けます。

  5. [クラスターの許可] の場合、作成した cold_cluster グループを選択します。

  6. [インデックス] の場合、* と入力します。

  7. インデックスの許可] の場合、作成した cold_index グループを選択します。

  8. [Create] (作成) を選択します。

  9. ロールを作成したら、コールドインデックスを管理する任意のユーザーまたはバックエンドロールにそれをマッピングします。

コールドストレージの要件とパフォーマンスに関する考慮事項

コールドストレージは Simple Storage Service (Amazon S3) を使用するため、レプリカ、Linux 予約容量、OpenSearch Service 予約容量など、ホットストレージのオーバーヘッドは発生しません。コールドストレージには、コンピューティング性能がアタッチされていないため、特定のインスタンスタイプはありません。コールドストレージには、任意の量のデータを保存できます。Amazon CloudWatch の ColdStorageSpaceUtilization メトリクスをモニタリングして、使用しているコールドストレージ容量の量を確認します。

コールドストレージの料金

UltraWarm ストレージと同様に、コールドストレージでは、データストレージに対してのみ課金されます。コールドデータにはコンピューティングコストはないので、コールドストレージにデータがない場合、課金されることはありません。

コールドストレージとウォームストレージ間でデータを移動する場合、転送料金は発生しません。インデックスがウォームストレージとコールドストレージ間で移行されている間、インデックスの 1 つのコピーに対してのみ、継続して料金が発生します。移行が完了すると、インデックスは、移行先のストレージ階層に従って課金されます。コールドストレージの料金の詳細については、「Amazon OpenSearch Service の料金」を参照してください。

コールドストレージを有効にする

コンソールは、コールドストレージを使用するドメインを作成する最も簡単な方法です。ドメインを作成している間に、[コールドストレージを有効にする] を選択します。前提条件を満たしている限り、既存のドメインでも同じプロセスを使用できます。ドメインの状態が [処理中] から [アクティブ] になっても、コールドストレージが使用可能になるには数時間かかることがあります。

AWS CLI または設定 API を使用して、コールドストレージを有効にすることもできます。

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 コマンドのリファレンス」を参照してください。

設定 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 リファレンス」を参照してください。

OpenSearch Dashboards でのコールドインデックスの管理

OpenSearch Service ドメインの既存の Dashboards インターフェイスを使用して、ホット、ウォーム、およびコールドインデックスを管理できます。Dashboards を使用すると、CLI や設定 API を使用することなく、ウォームストレージとコールドストレージ間でインデックスを移行し、インデックスの移行ステータスをモニタリングできます。詳細については、OpenSearch Dashboards でのインデックスの管理を参照してください。

コールドストレージへのインデックスの移行

インデックスをコールドストレージに移行する場合、データの時間範囲を指定して簡単に検出できるようにします。インデックス内のデータに基づいてタイムスタンプフィールドを選択するか、開始タイムスタンプと終了タイムスタンプを手動で指定するか、それを指定しないように選択することができます。

パラメータ サポートされている値 説明
timestamp_field インデックスマッピングの日付/時刻フィールド。

指定されたフィールドの最小値と最大値が計算され、コールドインデックスの start_time および end_time メタデータとして保存されます。

start_time: および end_time

以下の形式のいずれか。

  • strict_date_optional_time。例えば、yyyy-MM-dd'T'HH:mm:ss.SSSZyyyy-MM-dd などです。

  • エポック時間 (ミリ秒)

指定された値は、コールドインデックスの 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 メトリクスをモニタリングします。移行プロセスには次の状態があります。

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_timeend_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/descend_time:asc/desc、および index_name:asc/desc です。

ページ分割

コールドインデックスのリストをページ分割できます。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 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 メソッドをサポートしていません。curlPostman、または他のメソッドを使用して、コールドメタデータを更新します。

コールドインデックスの削除

ISM ポリシーを使用していない場合は、コールドインデックスを手動で削除できます。次のリクエストは、コールドインデックスを削除します。

DELETE _cold/my-index { "acknowledged" : true }

コールドストレージを無効にする

OpenSearch Service コンソールは、コールドストレージを無効にする最も簡単な方法です。ドメインを選択し、[アクション] から [クラスター設定の編集] を選択し、[コールドストレージを有効にする] の選択を解除します。

AWS CLI または設定 API を使用するには、ColdStorageOptions の下で、"Enabled"="false" を設定します。

コールドストレージを無効にする前に、すべてのコールドインデックスを削除するか、ウォームストレージに移行する必要があります。そうしないと、無効アクションは失敗します。