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

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

Amazon OpenSearch Service の UltraWarm ストレージ

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

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

OpenSearch では、ウォームインデックスは他のインデックスと同じように動作します。同じ API を使用してそれらのクエリを行うことも、OpenSearch Dashboards で可視化を作成することもできます。

前提条件

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

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

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

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

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

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

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

注記

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

アクセス許可を設定する

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

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

  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 Service 予約済み領域という大きなオーバーヘッドが発生します。例えば、1 つのレプリカシャードを持つ 20 GiB プライマリシャードには、約 58 GiB のホットストレージが必要です。

UltraWarm では Amazon S3 を使用するため、このオーバーヘッドは発生しません。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 および WarmJVMMemoryPressure UltraWarm メトリクスをモニタリングして、インスタンスがワークロードをどのように処理するかを理解してください。

検索が広範または頻繁である場合、インデックスをホットストレージに残すことを検討してください。他の 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」を参照してください。

UltraWarm は、AWS CLI または設定 API を使用して有効にすることもできます。具体的には、ClusterConfig の WarmEnabled、WarmCount、WarmType オプションを使用します。

注記

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

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 Service は、一度に 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 セグメントで構成されています。強制マージオペレーションは、削除対象としてマークされたドキュメントをパージし、ディスク領域を節約します。デフォルトでは、UltraWarm はインデックスを 1 つのセグメントにマージします。

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 Service は、移行リクエストをキューに入れられた順序で一度に 1 つずつ処理します。現在の個数を確認するには、WarmToHotMigrationQueueSize メトリクスをモニタリングします。

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

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

UltraWarm では、自動スナップショット用の標準リポジトリに加えて、ウォームインデックス用の 2 つ目のリポジトリである 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 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 を無効にする最も簡単な方法は、コンソールを使用することです。ドメインを選択し、[アクション] から [クラスター設定の編集] を選択します。[Enable UltraWarm data nodes] (UltraWarm データノードを有効化) の選択を解除し、[Save changes] (変更の保存) を選択します。AWS CLI および設定 API で WarmEnabled オプションを使用することもできます。

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