Amazon OpenSearch ServiceのIndex State Management（ISM）注意ポイント

はじめに

皆さんこんばんは。世間もそろそろ年の瀬ムードですね。
さて、先日のre:Invent2022にて、サーバーレス版が発表されたことでますますの盛り上がりを見せるAmazon OpenSearch Serviceですが、管理自動化機能としてIndex State Management（インデックスステート管理、ISMと略す）があるのをご存じでしょうか。これを利用すると、対象のインデックスをhotノードからUltraWarmノードに移動させるタスクや、レプリカ数を減少させるタスクなどを自動で実施することができます。
とても便利なISMですが、少し感覚と異なる挙動をする注意ポイントがありましたので、備忘録もかねて記事にしようと思います。

前提

これらのポイントは、私がAmazon OpenSearch Service バージョン1.2（東京リージョン）で試しているものです。
お使いのバージョンによって挙動が異なる場合がありますのでご注意ください。

また、ポリシーを簡易的に以下のように示しています。

これは、"hot", "warm", "cold"それぞれのconditionsのmin_index_ageを1dで指定している意味です。
以下のAWSドキュメントを見ると理解しやすいかと思います。
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ism.html

注意ポイント3つ

1. min_index_ageで指定する期間はIndexが作成されてからの期間である

"hot", "warm", "cold"でそれぞれmin_index_ageを指定するので、「それぞれのノードに入ってからの期間なのかな」と思っていましたが、これはIndexが新規作成されてからの期間を示すようです。
図で説明すると、以下のようになります。

hot, warm, coldでそれぞれ1dを指定した場合、それぞれ1日ずつ保持するのではなく、どのノードも1日たったら次のノードへ移動（または削除）するということになります。
そうなると、1日たった後にhot→warmに移動して、すぐにwarm→coldに移動、そして削除が行われてしまいます。

もし1日ずつ保持したい場合は、以下のようにポリシーを定義しましょう。

2. 途中でポリシー付与したときmin_index_ageを過ぎているとすぐにノード間移動が走る

OpenSearchでは、HotノードにあるIndexを指定して、ポリシーを新たに適用することができます。
以下の図の「Apply policy」ボタンがそれです。

1のポイントでお話ししたように、min_index_ageはIndexが作成されてからの期間です。ポリシーを付与してからの期間ではないことに気を付けてください。
以下の図で説明します。

作成して既に30日が経過しているIndexに、図のポリシーを途中で付与した場合です。
この場合、hot→warmの1d、warm→coldの2d、coldから削除の3d、全ての期間を既に過ぎています。そのため、ポリシーを付与するとすぐにhotからwarmの移動が始まり、削除まで行ってしまいます。

ポリシーを途中から付与する際はお気を付けください。

3. ノード間移動には少し時間がかかる

今までのポイントでは、min_index_ageを1dや2dと日にち単位で指定をしていましたが、実はh（時間）などもっと細かい単位でも指定ができます。

The minimum age required to roll over the index. Index age is the time between its creation and the present. Supported units are d (days), h (hours), m (minutes), s (seconds), ms (milliseconds), and micros (microseconds). See Important note above.
https://opensearch.org/docs/latest/im-plugin/ism/policies/#rollover

（実際に、transitionsのmin_index_ageにh,m,s,msを指定してみたら、エラー出ず設定できました）
例えば1h（1時間）を指定したら、Indexが作成されてきっかり1時間後にUltraWarmノードに移動する･･･ことを期待したいですが、ノード間の移動に少し時間がかかります。こちらも、図で説明します。

ここで記載している「+α」は、いくつかの原因から発生しますが、そのうちの1つはドキュメントに以下のように記載されています。

ポリシーをインデックスにアタッチすると、ISM は 30～48 分ごとに実行されるジョブを作成し、ポリシーアクションを実行して条件を確認してから、インデックスを別の状態に移行します。このジョブを実行する基本時間は 30 分ごとです。さらに、0～60% のランダムジッターが追加されることで、すべてのインデックスからのアクティビティが同時に急増することがなくなります。クラスターの状態が赤の場合、ISM はジョブを実行しません。
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ism.html

仕様として移行ジョブの実行タイミングが30~48分ほどかかるので、1時間と指定しても最短で1時間30分かかってしまいます。
また、hot→warmに移行できるIndexは1つです。並列して実行はできません。

OpenSearch Service は、一度に 1 つのインデックスを UltraWarm に移行します。キューには最大 200 の移行を設定できます。制限を超えるリクエストは拒否されます。
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ultrawarm.html#ultrawarm-migrating

これにより、さらに時間がかかる可能性があります。

もしすぐに移行させたい場合は、Dev Toolsで以下のコマンドを実行したほうが良いです。
それぞれ、index-nameという名前のIndexを対象にノード間移動させるコマンド例です。

• hot→warm

POST _ultrawarm/migration/index-name/_warm

• warm→cold

POST _ultrawarm/migration/index-name/_cold
  {
    "start_time": "2020-03-09",
    "end_time": "2020-03-09T23:00:00Z"
  }

• cold→warm

POST _cold/migration/_warm
 {
 "indices": "index-name"
 }
{
  "acknowledged" : true
}

• warm→hot

POST _ultrawarm/migration/index-name/_hot

おわりに

ISMは、運用管理を自動化するという意味でOpenSearchの運用には欠かせない機能です。
今回記事で取り上げたようなポイントを認識したうえで、設定していきましょう。
それでは、これからも良きOpenSearchライフを！