翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
UltraWarm は、大量の読み取り専用データを Amazon OpenSearch Service に保存するための費用対効果の高い方法を提供します。標準データノードは、各ノードにアタッチされたインスタンスストアまたは Amazon EBSボリュームの形式をとる「ホット」ストレージを使用します。ホットストレージは、新しいデータのインデックス作成と検索において、可能な限り高速なパフォーマンスを提供します。
UltraWarm ノードは、アタッチされたストレージではなく、Amazon S3 と高度なキャッシュソリューションを使用してパフォーマンスを向上させます。アクティブに書き込んでいないインデックス、クエリの頻度が低く、同じパフォーマンスを必要としないインデックスの場合、 UltraWarm はデータの GiB あたりのコストを大幅に削減します。ウォームインデックスはホットストレージに戻さない限り読み取り専用であるため、 UltraWarm はログなどのイミュータブルなデータに最適です。
では OpenSearch、ウォームインデックスは他のインデックスと同様に動作します。同じ を使用してクエリを実行するAPIsことも、ダッシュボードで視覚化を作成することもできます OpenSearch 。
トピック
前提条件
UltraWarm にはいくつかの重要な前提条件があります。
-
UltraWarm には、 OpenSearch または Elasticsearch 6.8 以降が必要です。
-
ウォームストレージを使用するには、ドメインに専用のマスターノードが必要です。
-
スタンバイ付きマルチ AZ ドメインを使用する場合、ウォームノードの数は、使用するアベイラビリティーゾーンの数の倍数である必要があります。
-
ドメインでデータノードに T2 または T3 インスタンスタイプが使用されている場合、ウォームストレージを使用することはできません。
-
インデックスがおおよその k-NN (
"index.knn":true) を使用している場合は、バージョン 2.17 以降からウォームストレージに移動できます。バージョン 2.17 より前のバージョンのドメインはこの機能を使用するように 2.17 にアップグレードできますが、2.x より前のバージョンで作成されたKNNインデックスは移行できません UltraWarm。 -
ドメインがきめ細かなアクセスコントロールを使用している場合、ユーザーは OpenSearch Dashboards の
ultrawarm_managerロールにマッピングされて呼び出しを行う必要があります UltraWarm API。
注記
既存の OpenSearch サービスドメインによっては、ultrawarm_managerロールが定義されていない場合があります。Dashboards にロールが表示されない場合は、それを手動で作成する必要があります。
許可の設定
既存の OpenSearch サービスドメイン UltraWarm で を有効にすると、ultrawarm_managerロールがドメインで定義されていない可能性があります。きめ細かなアクセスコントロールを使用してドメインのウォームインデックスを管理するには、管理者以外のユーザーがこのロールにマッピングされている必要があります。ultrawarm_manager ロールを手動で作成するには、以下のステップを実行します。
-
OpenSearch ダッシュボードで、セキュリティに移動し、アクセス許可を選択します。
-
[アクショングループの作成] を選択し、以下のグループを設定します。
グループ名 許可 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
-
-
[ロール]、[ロールの作成] の順に選択します。
-
ロールに ultrawarm_manager という名前を付けます。
-
[クラスターの許可] では、
ultrawarm_clusterおよびcluster_monitorを選択します。 -
[インデックス] では、
*と入力します。 -
[インデックスの許可] では、
ultrawarm_index_read、ultrawarm_index_write、およびindices_monitorを選択します。 -
[Create] (作成) を選択します。
-
ロールを作成したら、 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 インスタンスタイプRAMに割り当てられるCPUコアの数と量によって、同時に検索できるシャードの数を把握できます。プライマリシャードのみが S3 のストレージに UltraWarmカウントされますが、 OpenSearch は_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 データノードを有効にすると、必要なウォームノードの数を選択します。前提条件を満たしていれば、既存のドメインでも同じ基本プロセスを使用できます。ドメインの状態が処理中からアクティブに変わった後でも、数時間は使用できない UltraWarm 場合があります。
スタンバイ付きマルチ AZ ドメインを使用する場合、ウォームノードの数は、使用するアベイラビリティーゾーンの数の倍数である必要があります。詳細については、「Multi-AZ with Standby」を参照してください。
AWS CLIWarmEnabled、WarmCount、および WarmTypeオプションを有効にすることもできますClusterConfig。
注記
ドメインはウォームノードの最大数をサポートします。詳細については、「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 Reference」を参照してください。
インデックスを 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_RELOCATIONOpenSearch サービスは、一度に 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 マージします。ただし、デフォルト値の 20 が使用される kNN インデックスは除きます。
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 スナップショットをウォームストレージに復元するには
-
復元するインデックスを含む最新のスナップショットを特定します。
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パラメータを使用することをお勧めします。 -
インデックスがすでに存在する場合は、それを削除します。
DELETEmy-indexインデックスを削除しない場合は、それをホットストレージに戻し、それの再インデックス
を行います。 -
スナップショットの復元:
POST _snapshot/cs-ultrawarm/snapshot-name/_restoreUltraWarm は、この復元リクエストで指定したインデックス設定を無視しますが、
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 クエリの頻度が低いデータが にある場合は、コールドストレージへの移行を検討してください。コールドストレージは、ときどきしかアクセスしないデータや、使用されなくなったデータを対象としています。コールドインデックスを読み書きすることはできませんが、クエリを行う必要があるときはいつでも無償でウォームストレージに移行できます。手順については、「コールドストレージへのインデックスの移行」を参照してください。
KNN インデックスのベストプラクティス
-
Ultrawarm/Cold 階層は、すべてのKNNインデックスエンジンタイプで使用できます。グラフデータをオフヒープメモリに完全にロードする必要のない Lucene エンジンとディスク最適化ベクトル検索を使用するKNNインデックスに推奨されます。FAISS や などのネイティブインメモリエンジンで使用する場合NMSLIB、アクティブに検索されるシャードグラフのサイズを考慮し、インスタンスタイプが望ましい
uw.largeインスタンスをプロビジョニング UltraWarmする必要があります。例えば、お客様が 2 つのuw.largeインスタンスを設定している場合、それぞれ約knn.memory.circuit_breaker.limit * 61GiB のオフヒープメモリを使用できます。すべてのウォームクエリが、累積グラフサイズが使用可能なオフヒープメモリを超えないシャードを対象としている場合、最適なパフォーマンスが得られます。エビクションとオフヒープメモリが利用可能になるまでの待機により、使用可能なメモリがグラフのロードに必要なメモリよりも低い場合、レイテンシーに影響します。そのため、インメモリエンジンが使用されているユースケースや、エンジンに関係なく検索スループットが高いユースケースには、uw.mediumインスタンスを使用することはお勧めしません。 -
KNN に移行するインデックスは、単一のセグメントに強制マージ UltraWarm されません。これにより、インメモリエンジンではグラフサイズが大きすぎるため、OOM問題が発生するホットノードとウォームノードへの影響を回避できます。シャードあたりのセグメント数が増加するため、ローカルキャッシュ領域を消費し、ウォーム層に移行するインデックスの数を減らすことができます。既存の設定を使用してインデックスを 1 つのセグメントに強制マージし、ウォーム階層に移行する前に上書きすることを選択できます。詳細については、「移行の調整」を参照してください。
-
インデックスの検索頻度が低く、レイテンシーの影響を受けやすいワークロードを処理しないユースケースがある場合は、それらのインデックスを UltraWarm 階層に移行できます。これにより、ホット層のコンピューティングインスタンスをスケールダウンし、 UltraWarm 階層コンピューティングがこのような優先度の低いインデックスでクエリを処理できるようになります。これは、優先度の低いインデックスと高いインデックスのクエリ間で消費されるリソースを分離し、互いに影響しないようにするのに役立ちます。
の無効化 UltraWarm
コンソールを無効にする最も簡単な方法です UltraWarm。ドメインを選択し、[アクション] から [クラスター設定の編集] を選択します。データ UltraWarm ノードの有効化 を選択し、変更の保存 を選択します。 AWS CLI および 設定 で WarmEnabledオプションを使用することもできますAPI。
無効にする前に UltraWarm、すべてのウォームインデックスを削除する
