インデックス：log-aws-cloudtrail-2020-07-26
KibanaのDevToolsから実施
ウォーム層(UltraWarm)に移動
事前確認
事前にドキュメントの書き込みと削除が出来ることを確認
POST log-aws-cloudtrail-2020-07-26/_doc/
{
"user_name": "John Smith",
"date": "2019-10-06T15:09:45",
"message": "Hello Elasticsearch world"
}
GET log-aws-cloudtrail-2020-07-26/_search
{
"query": {
"match": {
"message": "Hello Elasticsearch world"
}
}
}
DELETE log-aws-cloudtrail-2020-07-26/_doc/LrhtM3QBGUwCsWOWv4Mh
ウォーム層に移動
インデックスをUltraWarmのウォーム層に移動
POST _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_warm
GET _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_status
GET _warm
GET _cat/indices/_warm
GET _cat/indices/_hot
GET _ultrawarm/migration/_status?v
データ量によってはしばらくステートが"RUNNING_SHARD_RELOCATION"のまま
GET _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_status
{
"migration_status" : {
"index" : "log-aws-cloudtrail-2020-07-26",
"state" : "RUNNING_SHARD_RELOCATION",
"migration_type" : "HOT_TO_WARM",
"shard_level_status" : {
"running" : 0,
"total" : 6,
"pending" : 6,
"succeeded" : 0
}
}
}
遷移するステートの種類はこちら
force_mergeもされてますね
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
このタイミングでホット層に戻そうとしても、「ウォーム層に移動中だよ」とエラーになる
POST _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_hot
{
"error" : {
"root_cause" : [
{
"type" : "illegal_argument_exception",
"reason" : "Rejecting migration request for index [log-aws-cloudtrail-2020-07-26] because it is already in migration [HOT2WARM] state"
}
],
"type" : "illegal_argument_exception",
"reason" : "Rejecting migration request for index [log-aws-cloudtrail-2020-07-26] because it is already in migration [HOT2WARM] state"
},
"status" : 400
}
しばらく"RUNNING_SHARD_RELOCATION"が続いたあと、"FINISHED_SHARD_RELOCATION"の表示を確認したかったが、以下のようにエラーになった。FINISHEDのステータスは一瞬だったのかな・・
GET _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_status
{
"error" : {
"root_cause" : [
{
"type" : "illegal_argument_exception",
"reason" : "Index [log-aws-cloudtrail-2020-07-26] has no active migrations"
}
],
"type" : "illegal_argument_exception",
"reason" : "Index [log-aws-cloudtrail-2020-07-26] has no active migrations"
},
"status" : 400
}
こっちのコマンドで確認してみる。問題なくウォーム層に行ってるよう
GET _cat/indices/_warm
green open log-aws-cloudtrail-2020-07-26 j8xepNRES3izjgviSaoF4Q 3 1 20743 2 80.8mb 40.4mb
UltraWarmは読み込みオンリーなことを確認
## ワーム層でドキュメントポスト確認
POST log-aws-cloudtrail-2020-07-26/_doc/
{
"user_name": "John Smith",
"date": "2019-10-06T15:09:45",
"message": "Hello Elasticsearch world"
}
想定通りエラー。読み取り専用なのでOKです。read-onlyだよと出てますね。
{
"error" : {
"root_cause" : [
{
"type" : "cluster_block_exception",
"reason" : "index [log-aws-cloudtrail-2020-07-26] blocked by: [TOO_MANY_REQUESTS/12/index read-only / allow delete (api)];"
}
],
"type" : "cluster_block_exception",
"reason" : "index [log-aws-cloudtrail-2020-07-26] blocked by: [TOO_MANY_REQUESTS/12/index read-only / allow delete (api)];"
},
"status" : 429
}
ホット層に戻す
## インデックスをワーム層からホット層に移動(戻す)
POST _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_hot
{
"acknowledged" : true
}
ステータス見るまもなく一瞬でホット層に移り完了した。早い。
以下のステータス見てももう終わってるのでエラーです。
多分、このブログのこの箇所の通り、ホットに戻す際は自動スナップショットから戻してるから早いっぽい(?)
https://aws.amazon.com/jp/blogs/news/retain-more-for-less-with-ultrawarm-for-amazon-elasticsearch-service/
インデックスに再度書き込みを行う必要が生じた場合、UltraWarm には独自の自動スナップショットリポジトリがあり、そこからインデックスをホットストレージに復元できます。
GET _ultrawarm/migration/log-aws-cloudtrail-2020-07-26/_status
インデックス単位でウォーム層に移ったかの確認は以下で
「"box_type" : "warm"」
GET log-aws-cloudtrail-2020-07-26/_settings
{
"log-aws-cloudtrail-2020-07-26" : {
"settings" : {
"index" : {
"mapping" : {
"total_fields" : {
"limit" : "3000"
},
"ignore_malformed" : "true"
},
"refresh_interval" : "-1",
"auto_expand_replicas" : "false",
"blocks" : { },
"provided_name" : "log-aws-cloudtrail-2020-07-26",
"creation_date" : "1595740159391",
"unassigned" : {
"node_left" : {
"delayed_timeout" : "5m"
}
},
"number_of_replicas" : "1",
"uuid" : "j8xepNRES3izjgviSaoF4Q",
"version" : {
"created" : "7040299",
"upgraded" : "7070099"
},
"routing" : {
"allocation" : {
"require" : {
"box_type" : "warm"
}
}
},
"number_of_shards" : "3"
}
}
}
}
ドキュメント追加して消してみる
成功しました。ホット層に戻ってます。
POST log-aws-cloudtrail-2020-07-26/_doc/
{
"user_name": "John Smith",
"date": "2019-10-06T15:09:45",
"message": "Hello Elasticsearch world"
}
GET log-aws-cloudtrail-2020-07-26/_search
{
"query": {
"match": {
"message": "Hello Elasticsearch world"
}
}
}
DELETE log-aws-cloudtrail-2020-07-26/_doc/LrhtM3QBGUwCsWOWv4Mh
IndexManagementによるウォーム層への移動
Index State Management
ここに注意書きがあるようにポリシーアタッチ後のジョブ作成と実行にもジッターがあって、ちょっと確認するのには時間がかかる。
ポリシーをインデックスにアタッチすると、ISM は 30～48 分ごとに実行されるジョブを作成し、ポリシーアクションを実行して条件を確認してから、インデックスを別の状態に移行します。このジョブを実行する基本時間は 30 分ごとです。さらに、0～60% のランダムなジッターが追加され、すべてのインデックスから同時にアクティビティが急増しないようにします。
Kibanaの画面から
IndexManagement->Index Policies->[Create Policy]
以下の値を入れて[create]をクリックし、次の画面で[Apply]をクリック
Policy ID:hot_to_warm1
Define policy:↓
{
"policy": {
"policy_id": "hot_to_warm1",
"description": "Demonstrate a hot-warm-delete workflow.",
"last_updated_time": 1598608063164,
"schema_version": 1,
"error_notification": null,
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "warm",
"conditions": {
"min_index_age": "30m"
}
}
]
},
{
"name": "warm",
"actions": [
{
"timeout": "1h",
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"warm_migration": {}
}
],
"transitions": []
}
]
}
}
Indexにポリシーアタッチ
任意のIndexにチェックを入れ、右上の[Apply policy]をクリックし、"hot_to_warm1"を選択して[Apply]をクリック
イニシャライズが始まる
ここからはちゃんと時間を計ってないが、1時間くらいするとイニシャライズが終わり、ステートがhotで表示される
もうさらに時間が経過すると、ステートがwarmに変化する
今回は30m以上前のインデックスであればローテーションする設定で、選択したインデックスは30m以上前のものであった。
前の手順と同様、以下のコマンドでウォーム層に移ったことを確認
GET log-aws-cloudtrail-2020-08-03/_settings
他にも公式ドキュメントにあるように、以下のようなちゃんとしたローテーションも入れられます
7 日後にホットストレージから UltraWarm ストレージにインデックスを移動し、90 日後にそのインデックスを削除します
他にもISMのインデックスポリシーでは、以下のようなオペレーションをサポートしている(一部openやcoleseなどAWSでは未サポート)
一定期間経ったらインデックスのレプリカ数を減らしたり、ロールオーバーでエイリアス付け替えたり、ウォーム層に移したり、削除したり。
notificationでSlack通知などもできる
※残念ながらAmazonESではOpen, Close, Snapshotに対応してない。ここで定期的にスナップショットを取ることはできない
force_merge
read_only
read_write
replica_count
close
open
delete
rollover
notification
snapshot
index_priority
参考ドキュメント
公式ドキュメント
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/ultrawarm.html
IndexManagementのIndexPlicyの書き方
https://opendistro.github.io/for-elasticsearch-docs/docs/ism/policies/