Amazon OpenSearch サービス用コールドストレージ - Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス)

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

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

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

Prerequisites

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

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

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

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

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

  • ドメインがきめ細かなアクセスコントロールを使用する場合、管理者以外のユーザーは、コールドインデックスを管理するために 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. [作成] を選択します。

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

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

コールドストレージは Amazon S3 を使用するため、レプリカ、Linux 予約容量、Amazon ES 予約容量など、ホットストレージのオーバーヘッドは発生しません。コールドストレージには、コンピューティング性能がアタッチされていないため、特定のインスタンスタイプはありません。コールドストレージには、任意の量のデータを保存できます。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 ダッシュボードでのインデックスの管理」を参照してください。

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

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

パラメータ サポートされている値 説明
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

ウォームストレージからコールドストレージには 10 のバッチ数でインデックスを移行でき、同時リクエスト数は最大 100 です。移行プロセスには次の状態があります。

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

ドメインがきめ細かなアクセスコントロールを使用している場合、このリクエストを行うには indices:admin/ultrawarm/migration/cancel 許可が必要です。

コールドインデックスの一覧表示

クエリを実行する前に、コールドストレージ内のインデックスを一覧表示して、詳細な分析のために UltraWarm に移行するインデックスを決定できます。次のリクエストは、すべてのコールドインデックスをインデックス名でソートして一覧表示します。

GET _cold/indices/_search

Filtering

プレフィックスベースのインデックスパターンと時間範囲のオフセットに基づいて、コールドインデックスをフィルタリングできます。

次のリクエストは、event-* のプレフィックスパターンに一致するインデックスをリストします。

GET _cold/indices/_search { "filters":{ "index_pattern": "event-*" } }

次のリクエストは、2019-03-012020-03-01 の間の start_timeend_time のメタデータフィールドを持つインデックスを返します。

GET _cold/indices/_search { "filters": { "time_range": { "start_time": "2019-03-01", "end_time": "2020-03-01" } } }

Sorting

コールドインデックスは、インデックス名やサイズなどのメタデータフィールドでソートできます。次のリクエストは、降順にサイズでソートされたすべてのインデックスを一覧表示します。

GET _cold/indices/_search { "sort_key": "size:desc" }

その他の有効なソートキーは、start_time:asc/descend_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" }

移行のステータスを確認して移行 ID を取得するには、次のリクエストを送信します。

GET _cold/migration/_status

インデックス固有の移行情報を取得するには、インデックス名を含めます。

GET _cold/migration/my-index/_status

インデックスを指定するのではなく、現在の移行ステータス別にインデックスを一覧表示できます。有効な値は、_failed_accepted_all です。

次のコマンドは、単一の移行リクエスト内のすべてのインデックスのステータスを取得します。

GET _cold/migration/_status?migration_id=my-migration-id

ステータスリクエストを使用して移行 ID を取得します。移行の詳細については、&verbose=true を追加します。

コールドストレージからウォームストレージには 10 のバッチ数でインデックスを移行でき、同時リクエスト数は最大 100 です。移行プロセスには次の状態があります。

ACCEPTED_MIGRATION_REQUEST - Migration request is accepted and queued. RUNNING_INDEX_CREATION - Migration request is picked up for processing and will create warm indices 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 indices 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.

スナップショットからのコールドインデックスの復元

ドメイン全体が誤って削除された場合など、自動スナップショットからコールドインデックスを復元する必要がある場合は、AWS Support に連絡してください。OpenSearch Service は、コールドインデックスが削除された後、それらを 14 日間保持します。

コールドストレージからウォームストレージへの移行のキャンセル

コールドストレージからウォームストレージへのインデックスの移行がキューに追加されているか、失敗状態にある場合は、次のリクエストを用いてそれをキャンセルできます。

POST _cold/migration/my-index/_cancel

インデックスのバッチ (一度に最大 10 個) の移行をキャンセルするには、移行 ID を指定します。

POST _cold/migration/_cancel?migration_id=my-migration-id

ステータスリクエストを使用して移行 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

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

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

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

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