UltraWarm Amazon OpenSearch サービス用ストレージ - Amazon OpenSearch サービス
前提条件UltraWarm ストレージ要件とパフォーマンスに関する考慮事項UltraWarm 価格設定有効化 UltraWarmインデックスをストレージに移行 UltraWarm 移行を自動化する移行の調整移行をキャンセルするホットインデックスとウォームインデックスを一覧表示するウォームインデックスをホットストレージに戻すスナップショットからのウォームインデックスの復元ウォームインデックスの手動スナップショットウォームインデックスをコールドストレージへ移行する無効化 UltraWarm

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

UltraWarm Amazon OpenSearch サービス用ストレージ

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

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

では OpenSearch、ウォームインデックスは他のインデックスと同じように動作します。同じ API を使用してクエリを実行したり、ダッシュボードでビジュアライゼーションを作成したりできます。 OpenSearch

前提条件

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

  • UltraWarm Elasticsearch OpenSearch 6.8 以降が必要です。

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

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

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

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

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

  • ドメインがきめ細かなアクセス制御を使用している場合、API ultrawarm_manager OpenSearch 呼び出しを行うにはユーザーをダッシュボード内のロールにマッピングする必要があります。 UltraWarm

注記

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

許可の設定

UltraWarm OpenSearch 既存のサービスドメインで有効化しても、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_read、ultrawarm_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 and is report _cat/indices UltraWarm はすべてのプライマリシャードとレプリカシャードの合計インデックスサイズであることに注意してください。

例えば、各 ultrawarm1.medium.search インスタンスには 2 つの CPU コアがあり、S3 で最大 1.5 TiB のストレージに対応できます。これらのインスタンスのうちの 2 つには、3 TiB のストレージが組み合わされており、各シャードが 50 GiB の場合、約 62 のシャードになります。クラスターへのリクエストがこれらのシャードのうちの 4 つしか検索しない場合、パフォーマンスが優れている可能性があります。リクエストが広範で、それらの 62 すべてを検索する場合、4 つの CPU コアがオペレーションを実施しにくくなる可能性があります。WarmCPUUtilizationWarmJVMMemoryPressureUltraWarm とメトリクスを監視して、インスタンスがワークロードをどのように処理するかを把握してください。

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

UltraWarm 価格設定

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

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

有効化 UltraWarm

コンソールは、ウォームストレージを使用するドメインを作成する最も簡単な方法です。ドメインを作成するときに、[ UltraWarm データノードを有効にする] を選択し、必要なウォームノードの数を指定します。前提条件を満たしていれば、既存のドメインでも同じ基本プロセスを使用できます。ドメインの状態が [処理中] から [アクティブ] に変わっても、 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 サービス 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 ホットインデックスとウォームインデックスの管理に役立つ_all、と同様の 2 つのオプションが追加されました。すべてのウォームインデックスまたはホットインデックスのリストについては、次のリクエストを実行します。

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_patternrename_replacementやなどのオプションは指定できます。 OpenSearch スナップショット復元オプションの概要については、OpenSearch ドキュメントを参照してください。

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

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

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

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 分待ってから無効化を試みてください。