Amazon Elasticsearch Service の UltraWarm - Amazon Elasticsearch Service

英語の翻訳が提供されている場合で、内容が矛盾する場合には、英語版がオリジナルとして取り扱われます。翻訳は機械翻訳により提供されています。

Amazon Elasticsearch Service の UltraWarm

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

UltraWarm ノードは、接続されたストレージではなく、Amazon S3 と高度なキャッシュソリューションを使用してパフォーマンスを向上させます。アクティブに書き込みを行っていないインデックスやクエリの頻度が低いインデックスについては、UltraWarm により、データの GiB あたりのコストが大幅に削減されます。Elasticsearch では、これらのウォームインデックスは他のインデックスと同じように動作します。同じ API を使用してクエリを実行することも、Kibana でダッシュボードを作成することもできます。

Prerequisites

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

  • UltraWarm には Elasticsearch 6.8 以上が必要です。

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

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

UltraWarm ストレージ要件の計算

ストレージ要件の計算 で説明されているように、ホットストレージ内のデータには、レプリカ、Linux の予約済み領域、Amazon ES 予約済み領域という大きなオーバーヘッドが発生します。たとえば、1 つのレプリカシャードを持つ 10 GiB プライマリシャードには、約 26 GiB のホットストレージが必要です。

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

ヒント

UltraWarm では、最大シャードサイズを 50 GiB にすることをお勧めします。

UltraWarm 価格設定

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

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

UltraWarm を有効にする

コンソールは、ウォームストレージを使用するドメインを作成する最も簡単な方法です。ドメインの作成中に、[Enable UltraWarm data nodes (UltraWarm データノードを有効にする)] と必要なウォームノード数を選択します。前提条件を満たしていれば、既存のドメインでも同じ基本プロセスを使用できます。ドメインの状態が [Processing (処理中)] から [Active (アクティブ)] になっても、UltraWarm が使用可能になるには数時間かかることがあります。

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

注記

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

CLI コマンドの例

次の AWS CLI コマンドは、制限されたアクセスポリシーを持つ、3 つのデータノード、3 つの専用マスターノード、6 つのウォームノードのドメインを作成します。

aws es create-elasticsearch-domain --domain-name my-domain --elasticsearch-cluster-config InstanceCount=3,InstanceType=r5.large.elasticsearch,DedicatedMasterEnabled=true,DedicatedMasterType=c5.large.elasticsearch,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.elasticsearch --elasticsearch-version 6.8 --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-east-1:123456789012:domain/my-domain/*"}]}' --region us-east-1

詳細については、AWS CLI Command Referenceを参照してください。

設定 API リクエストの例

設定 API に対する次のリクエストは、すべての暗号化機能が有効で制限されたアクセスポリシーを持つ、3 つのデータノード、3 つの専用マスターノード、6 つのウォームノードのドメインを作成します。

POST https://es.us-east-2.amazonaws.com/2015-01-01/es/domain { "ElasticsearchClusterConfig": { "InstanceCount": 3, "InstanceType": "r5.large.elasticsearch", "DedicatedMasterEnabled": true, "DedicatedMasterType": "c5.large.elasticsearch", "DedicatedMasterCount": 3, "ZoneAwarenessEnabled": true, "ZoneAwarenessConfig": { "AvailabilityZoneCount": 3 }, "WarmEnabled": true, "WarmCount": 6, "WarmType": "ultrawarm1.medium.elasticsearch" }, "EBSOptions": { "EBSEnabled": true, "VolumeType": "gp2", "VolumeSize": 11 }, "EncryptionAtRestOptions": { "Enabled": true }, "NodeToNodeEncryptionOptions": { "Enabled": true }, "DomainEndpointOptions": { "EnforceHTTPS": true, "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07" }, "ElasticsearchVersion": "6.8", "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 Elasticsearch Service 設定 API リファレンス」を参照してください。

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

ホットストレージからウォームストレージへの移行は、最大 25 個まで同時に行うことができます。現在の個数を確認するには、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": "1572886951679", "unassigned": { "node_left": { "delayed_timeout": "5m" } }, "number_of_replicas": "1", "uuid": "3iyTkhXvR8Cytc6sWKBirg", "version": { "created": "6080099" }, "routing": { "allocation": { "require": { "box_type": "warm" } } }, "number_of_shards": "5" } } } }
  • number_of_replicas は、ディスク領域を消費しないパッシブレプリカの数です。

  • routing.allocation.require.box_type は、インデックスが標準データノードではなくウォームノードを使用するように指定します。

ウォームストレージのインデックスは、ホットストレージに復元しない限り、読み取り専用です。インデックスをクエリして削除できますが、個々のドキュメントを追加、更新、削除することはできません。再試行すると、次のエラーが表示されることがあります。

{ "error": { "root_cause": [{ "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" }], "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" }, "status": 403 }

移行を自動化する

インデックスが特定の経過時間に達した後、または他の条件を満たした後の移行プロセスは、Index State Management を使用して自動化することをお勧めします。このサンプルポリシーで、そのワークフローを説明します。

ホットインデックスとウォームインデックスのリスト表示

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

GET _warm GET _hot

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

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

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

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

POST _ultrawarm/migration/my-index/_hot

ウォームストレージからホットストレージへの移行は、最大 10 個まで同時に行うことができます。現在の個数を確認するには、WarmToHotMigrationQueueSize メトリクスをモニタリングします。

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

自動スナップショットからのウォーム・インデックスのリストア

自動スナップショットの標準リポジトリに加えて、UltraWarmは2つ目のリポジトリを追加します。 cs-ultrawarm。 のスナップショット cs-ultrawarm は、他の自動スナップショットと同じ14日間の保存期間を持ちます。

他の自動スナップショットとは異なり、このリポジトリ内の各スナップショットには 1 つのインデックスしか含まれていません。cs-ultrawarm からスナップショットを復元すると、ホットストレージではなくウォームストレージに復元されます。cs-automated-enc リポジトリと cs-automated リポジトリのスナップショットは、ホットストレージに復元されます。

UltraWarm スナップショットをウォームストレージに復元するには

  1. 復元するインデックスを含む最新のスナップショットを特定します。

    GET _snapshot/cs-ultrawarm/_all { "snapshots": [{ "snapshot": "snapshot-name", "version": "6.8.0", "indices": [ "my-index" ] }] }
  2. インデックスがすでに存在する場合は、それを削除します。

    DELETE my-index

    インデックスを削除したくない場合は、 ホット・ストレージに戻す および 再インデックス 考えます。

  3. スナップショットを復元します。

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

    UltraWarmはこのリストア要求で指定したインデックス設定を無視しますが、 rename_pattern および rename_replacement。 概要については、 Elasticsearch スナップショット リストア オプションについては、 Elasticsearchドキュメント用のOpen Distro.

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

あなた できる ウォームインデックスのスナップショットを手動で作成しますが、推奨しません。自動化された cs-ultrawarm リポジトリには、各ウォーム インデックスのスナップショットがすでに追加費用なしで含まれています。

デフォルトでは、 Amazon ES には、手動スナップショットにウォームインデックスは含まれません。たとえば、次の呼び出しにはホットインデックスのみが含まれます。

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 を無効にする最も簡単な方法は、コンソールを使用することです。ドメインを選択し、[Edit domain (ドメインの編集)] を選択して、[Enable UltraWarm data nodes (UltraWarm データノードを有効にする)] をオフにしてから、[Submit (送信)] を選択します。AWS CLI および設定 API で WarmEnabled オプションを使用することもできます。

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