UltraWarm 用の Amazon Elasticsearch Service - Amazon Elasticsearch Service

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

UltraWarm 用の Amazon Elasticsearch Service

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

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

Prerequisites

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

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

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

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

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

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

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

では、最大シャードサイズを 50 UltraWarm にすることをお勧めします。GiB 各 インスタンスタイプに割り当てられた CPU コアの数と RAM の量UltraWarmは、同時に検索できるシャードの数を示します。

たとえば、各 ultrawarm1.medium.elasticsearch インスタンスには 2 つの CPU コアがあり、S3 で最大 1.5 TiB のストレージに対応できます。これらのインスタンスのうち 2 つは、合計 3 つの TiB ストレージを持っています。各シャードが 50 GiB の場合、シャードの動作は約 62 です。 クラスターへのリクエストがこれらのうち 4 つのシャードのみを検索する場合、パフォーマンスは優れている可能性があります。リクエストが広く、62 個のリクエストをすべて検索する場合、4 つの CPU コアが操作の実行を困難する可能性があります。

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

UltraWarm の料金

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

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

の有効化UltraWarm

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

また、AWS CLI または設定 API を使用して、、特に UltraWarm の WarmEnabledWarmCountWarmType オプションを有効にすることもできます。ElasticsearchClusterConfig

注記

ドメインはウォームノードの最大数をサポートします。詳細については、「」を参照してください。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

ホットストレージからウォームストレージへの移行は、最大 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 は、移行中に同時にマージするセグメントの数を指定します。

ウォームストレージのインデックスは、ホットストレージに復元.しない限り、読み取り専用です。インデックスのクエリと削除はできますが、個別のドキュメントを追加、更新、または削除することはできません。追加しようとすると、次のエラーが発生することがあります。

{ "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各 Elasticsearch インデックスは複数のシャードで構成され、各シャードはいくつかの Lucene セグメントで構成されます。強制マージ操作は、削除とマークされたドキュメントを消去し、ディスク領域を節約します。デフォルトでは、UltraWarm はインデックスを 1 つのセグメントにマージします。

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

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 個まで同時に行うことができます。現在の個数を確認するには、WarmToHotMigrationQueueSize メトリクス.をモニタリングします。

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

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

は、自動スナップショット用の標準リポジトリに加えて、ウォームインデックス用の 2 番目のリポジトリ UltraWarm を追加します。cs-ultrawarm このリポジトリ内の各スナップショットには、1 つのインデックスのみが含まれます。ウォームインデックスを削除すると、そのスナップショットは、他の自動スナップショットと同じように、cs-ultrawarm リポジトリに 14 日間保持されます。

cs-ultrawarm からスナップショットを復元すると、ホットストレージではなくウォームストレージに復元されます。cs-automated リポジトリと cs-automated-enc リポジトリのスナップショットは、ホットストレージに復元されます。

スナップショットをウォームストレージに復元するには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_patternrename_replacement などのオプションを指定できます。 スナップショットの復元オプションの概要については、ElasticsearchOpen Distro for Elasticsearch のドキュメントを参照してください。

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

ウォームインデックスの手動スナップショットは取得できますが、これはお勧めしません。自動 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] をオフにして、[Submit] を選択します。WarmEnabled および設定 API で AWS CLI オプションを使用することもできます。

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