UltraWarm Amazon OpenSearch Service の ストレージ - Amazon OpenSearch サービス

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

UltraWarm Amazon OpenSearch Service の ストレージ

UltraWarm は、大量の読み取り専用データを Amazon OpenSearch Service に保存するための費用対効果の高い方法を提供します。標準データノードは「ホット」ストレージを使用します。このストレージは、各ノードにアタッチされたインスタンスストアまたは Amazon EBS ボリュームの形をとります。ホットストレージは、新しいデータのインデックス作成と検索において、可能な限り高速なパフォーマンスを提供します。

UltraWarm ノードは、アタッチされたストレージではなく、Amazon S3 と高度なキャッシュソリューションを使用してパフォーマンスを向上させます。アクティブに書き込んでいないインデックス、クエリの頻度が低く、同じパフォーマンスを必要としないインデックスの場合、 UltraWarm はデータ 1 GiB あたりのコストを大幅に削減します。ウォームインデックスはホットストレージに戻さない限り読み取り専用であるため、 UltraWarm はログなどのイミュータブルなデータに最適です。

では OpenSearch、ウォームインデックスは他のインデックスと同じように動作します。同じ APIs、それらを使用して OpenSearch Dashboards で視覚化を作成したりできます。

前提条件

UltraWarm にはいくつかの重要な前提条件があります。

  • UltraWarm には、 OpenSearch または Elasticsearch 6.8 以降が必要です。

  • ウォームストレージを使用するには、ドメインに専用のマスターノードが必要です。

  • スタンバイドメインでマルチ AZ を使用する場合、ウォームノードの数は、使用するアベイラビリティーゾーンの数の倍数である必要があります。

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

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

  • ドメインがきめ細かなアクセスコントロール を使用している場合、ユーザーは API コールを行うには OpenSearch Dashboards の ultrawarm_manager ロールにマッピングされている必要があります。 UltraWarm

注記

ultrawarm_manager ロールは、既存の一部の OpenSearch サービスドメインで定義されていない場合があります。Dashboards にロールが表示されない場合は、それを手動で作成する必要があります。

許可の設定

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

  1. OpenSearch ダッシュボードで、セキュリティに移動し、アクセス許可 を選択します。

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

    グループ名 許可
    ultrawarm_cluster
    • cluster:admin/ultrawarm/migration/list

    • cluster:monitor/nodes/stats

    ultrawarm_index_read
    • indices:admin/ultrawarm/migration/get

    • indices:admin/get

    ultrawarm_index_write
    • indices:admin/ultrawarm/migration/warm

    • indices:admin/ultrawarm/migration/hot

    • indices:monitor/stats

    • indices:admin/ultrawarm/migration/cancel

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

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

  5. [クラスターの許可] では、ultrawarm_cluster および cluster_monitor を選択します。

  6. [インデックス] では、* と入力します。

  7. [インデックスの許可] では、ultrawarm_index_readultrawarm_index_write、および indices_monitor を選択します。

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

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

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

で説明されているようにストレージ要件の計算、ホットストレージ内のデータには、レプリカ、Linux リザーブドスペース、 OpenSearch サービスリザーブドスペースという大きなオーバーヘッドが発生します。例えば、1 つのレプリカシャードを持つ 20 GiB プライマリシャードには、約 58 GiB のホットストレージが必要です。

Amazon S3 を使用するため、 ではこのオーバーヘッド UltraWarm は発生しません。 UltraWarm ストレージ要件を計算するときは、プライマリシャードのサイズのみを考慮します。S3 のデータの耐久性はレプリカの必要性を排除し、S3 はオペレーティングシステムやサービスの考慮事項を抽象化します。同じ 20 GiB シャードには、20 GiB のウォームストレージが必要です。ultrawarm1.large.search インスタンスをプロビジョニングする場合、プライマリシャードには最大ストレージの 20 TiB すべてを使用できます。インスタンスタイプの概要と、それぞれが対応できるストレージの最大容量については、「UltraWarm ストレージクォータ」を参照してください。

では UltraWarm、最大シャードサイズを 50 GiB にすることをお勧めします。各 UltraWarm インスタンスタイプに割り当てられる CPU コアの数と RAM の量によって、同時に検索できるシャードの数を把握できます。プライマリシャードのみが 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 および WarmJVMMemoryPressureUltraWarm メトリクスをモニタリングして、インスタンスがワークロードをどのように処理するかを理解します。

検索が広範または頻繁である場合、インデックスをホットストレージに残すことを検討してください。他の OpenSearch ワークロードと同様に、ニーズ UltraWarm が満たされているかどうかを判断するための最も重要なステップは、現実的なデータセットを使用して代表的なクライアントテストを実行することです。

UltraWarm 料金

ホットストレージでは、プロビジョニングした分に対して料金を支払います。インスタンスにはアタッチされた Amazon EBS ボリュームが必要で、インスタンスストアが含まれるインスタンスもあります。そのストレージが空かいっぱいかに関係なく、同じ料金を支払います。

UltraWarm ストレージでは、使用した分に対して料金が発生します。ultrawarm1.large.search インスタンスは S3 で最大 20 TiB のストレージに対応できますが、1 TiB のデータを格納する場合、1 TiB のデータに対してのみ課金されます。他のすべてのノードタイプと同様に、 UltraWarm ノードごとに時間単位の料金も支払います。詳細については、「Amazon OpenSearch Service の料金」を参照してください。

の有効化 UltraWarm

コンソールは、ウォームストレージを使用するドメインを作成する最も簡単な方法です。ドメインの作成時に、 UltraWarm データノードを有効にすると、必要なウォームノードの数を選択します。前提条件を満たしていれば、既存のドメインでも同じ基本プロセスを使用できます。ドメインの状態が Processing から Active に変わった後でも、数時間は使用できない UltraWarm 場合があります。

スタンバイドメインでマルチ AZ を使用する場合、ウォームノードの数は、使用するアベイラビリティーゾーンの数の倍数である必要があります。詳細については、「Multi-AZ with Standby」を参照してください。

AWS CLI または 設定 API を使用して UltraWarm、 、特に の WarmEnabledWarmCount、および WarmTypeオプションを有効にすることもできますClusterConfig

注記

ドメインはウォームノードの最大数をサポートします。詳細については、「Amazon OpenSearch サービスクォータ」を参照してください。

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

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

インデックスを 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 サービスは、一度に 1 つのインデックスを に移行します UltraWarm。キューには最大 200 の移行を設定できます。制限を超えるリクエストは拒否されます。キュー内の移行の現在の個数を確認するには、HotToWarmMigrationQueueSize メトリクスをモニタリングします。インデックスは、移行プロセス全体を通して使用でき、ダウンタイムは発生しません。

移行プロセスには次の状態があります。

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 ルなデータに最適です。インデックスのクエリを行ってそれらを削除することはできますが、個々のドキュメントを追加、更新、削除することはできません。それらを行おうとすると、次のエラーが発生する場合があります。

{ "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 でのインデックス状態管理 を使用して自動化することをお勧めします。このワークフローを示すサンプルポリシーを参照してください。

移行の調整

インデックスを UltraWarm ストレージに移行するには、強制マージが必要です。各 OpenSearch インデックスはいくつかのシャードで構成され、各シャードはいくつかの Lucene セグメントで構成されます。強制マージオペレーションは、削除対象としてマークされたドキュメントをパージし、ディスク領域を節約します。デフォルトでは、 はインデックスを 1 つのセグメントに UltraWarm マージします。

index.ultrawarm.migration.force_merge.max_num_segments 設定を使用して、この値を最大 1,000 のセグメントに変更することができます。値を大きくすると、移行プロセスが高速になりますが、移行終了後のウォームインデックスのクエリレイテンシーが長くなります。設定を変更するには、次のリクエストを行います。

PUT my-index/_settings { "index": { "ultrawarm": { "migration": { "force_merge": { "max_num_segments": 1 } } } } }

移行プロセスのこの段階でかかる時間を確認するには、HotToWarmMigrationForceMergeLatency メトリクスをモニタリングします。

移行をキャンセルする

UltraWarm は、キュー内で移行を順番に処理します。移行がキューに入っていても、まだ開始していない場合は、次のリクエストを使用して移行をキューから削除できます。

POST _ultrawarm/migration/_cancel/my-index

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

ホットインデックスとウォームインデックスを一覧表示する

UltraWarm では、ホットインデックスとウォームインデックスの管理に役立つ のような _all2 つのオプションが追加されています。すべてのウォームインデックスまたはホットインデックスのリストについては、次のリクエストを実行します。

GET _warm GET _hot

これらのオプションは、インデックスを指定する次のようなリクエストで使用できます。

_cat/indices/_warm _cluster/state/_all/_hot

ウォームインデックスをホットストレージに戻す

インデックスに再度書き込む必要がある場合は、ホットストレージに移行し直します。

POST _ultrawarm/migration/my-index/_hot

ウォームストレージからホットストレージへのキュー移行は、一度に最大 10 個まで実行できます。 OpenSearch サービスは、キューに入れられた順序で、移行リクエストを一度に 1 つずつ処理します。現在の個数を確認するには、WarmToHotMigrationQueueSize メトリクスをモニタリングします。

移行が完了したら、インデックス設定をチェックして、ニーズを満たしていることを確認します。インデックスはホットストレージに戻り、1 つのレプリカが作成されます。

スナップショットからのウォームインデックスの復元

自動スナップショットの標準リポジトリに加えて、 はウォームインデックスの 2 番目のリポジトリ UltraWarm を追加します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/<repo> オペレーションは、リポジトリ内の各スナップショットの開始時間、終了時間、期間などの詳細なデータ情報を表示します。GET _snapshot/<repo> オペレーションは、リポジトリ内の各スナップショットのファイルから情報を取得します。開始時間、終了時間、期間は不要で、スナップショットの名前とインデックス情報のみが必要な場合、処理時間を最小限に抑えてタイムアウトを防ぐために、スナップショットを一覧表示する際に verbose=false パラメータを使用することをお勧めします。

  2. インデックスがすでに存在する場合は、それを削除します。

    DELETE my-index

    インデックスを削除しない場合は、それをホットストレージに戻し、それの再インデックスを行います。

  3. スナップショットの復元:

    POST _snapshot/cs-ultrawarm/snapshot-name/_restore

    UltraWarm は、この復元リクエストで指定したインデックス設定を無視しますが、 rename_patternや などのオプションを指定できますrename_replacement。 OpenSearch スナップショットの復元オプションの概要については、「」のOpenSearch ドキュメントを参照してください。

ウォームインデックスの手動スナップショット

ウォームインデックスの手動スナップショットを取得できますが、推奨されません。自動化された cs-ultrawarm リポジトリには、移行中に取得された各ウォームインデックスのスナップショットがすでに含まれており、追加料金は発生しません。

デフォルトでは、 OpenSearch サービスには手動スナップショットにウォームインデックスは含まれません。例えば、次の呼び出しには、ホットインデックスしか含まれていません。

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 クエリの頻度が低い にデータがある場合は、コールドストレージへの移行を検討してください。コールドストレージは、ときどきしかアクセスしないデータや、使用されなくなったデータを対象としています。コールドインデックスを読み書きすることはできませんが、クエリを行う必要があるときはいつでも無償でウォームストレージに移行できます。手順については、「コールドストレージへのインデックスの移行」を参照してください。

無効化 UltraWarm

コンソールは、 を無効にする最も簡単な方法です UltraWarm。ドメインを選択し、[アクション] から [クラスター設定の編集] を選択します。データ UltraWarm ノードを有効にする を選択し、変更の保存 を選択します。 AWS CLI および設定 API で WarmEnabled オプションを使用することもできます。

を無効にする前に UltraWarm、すべてのウォームインデックスを削除する、ホットストレージ に戻す必要があります。ウォームストレージが空になったら、 を無効にする前に 5 分待ちます UltraWarm。