見出し画像

AWS:【QA】OpenSearchのインスタンスタイプ変更とストレージ設定の消失

みなさん、こんにちは。ちゃみみです。

本日は、AWSで用意されているOpenSearchこと旧ElasticSearchなんですが(以下Osとします)、あるPJでこのOsについてインスタンスタイプを引き上げるなどのタイプ変更などを行った際にデータ移行含めた何かしらの対応が必要なのか?という疑問が出ました。

特段同じEBSボリュームを利用している場合は、単純に拡張されるだけなので問題ない認識なのですがとりわけこのOsですが、インスタンスタイプによってこのEBSの設定が消失するタイプがありそういったものに変更した場合にデータや中身のindexの構成変更などの対応が必要なのか?という回答が自分の中でも解決できず、AWSさんへ問い合わせをしてみました。


結論として、インスタンスタイプを変更(今回はEBS設定があるタイプ(t3系)→EBS設定がないタイプ(i3)へタイプを変更)する場合について以下が回答となります。

===原文ママ===
データノードのインスタンスタイプを t3.small.search から i3.large.search に変更しても、インデックスの設定やデータへの影響は無い見込みでございます。 i3 タイプは、モデル(i3.large.search、i3.xlarge.search ...)によりインスタンスストレージのサイズが異なります。 このため、データの移行、および移行した後のクラスターの動作に問題がないよう、現在のインデックスのデータサイズを考慮し、空き容量の比率が 15% 以上になるようなタイプをお選びいただければと存じます。 (t3.small.search の EBS ストレージサイズは 100 GiB であり、i3.large.search のインスタンスストレージのサイズは 475GB であるため、ノード数を極端に減らさない限りは問題ないかと存じます。)

===ここまで===

そのため、インスタンスタイプ変更自体は可能なようですが、変更するにあたっては最低限空き容量は全体の15%前後は確保しておきつつ変更しましょう。という結論になります。


また、インスタンスタイプによってEBSの設定があるもの、そうでないものについて確認をしました。
単にEBSボリュームをサポートするインスタンスタイプがあるもの、そうでないものがあるというだけなようですが、IaCでサポートしていないタイプを選択しつつEBSの設定を入れると間違いなくエラー(内容が解明不可)が出るので注意が必要となります。
なお、EBSをサポートしないタイプの最大のストレージボリュームの上限については、こちらのURLに記載となっています。

IaCでは、EBSサポートがないものはデフォルトで記載のストレージが備わる形となるのでコードセクションからは除外する(≒むしろしないとNG)形で記載をしていくことが正しい書き方となります。

引き続きAWSライフを楽しみましょう。

2022年07月07日

以下、宣伝です。
仲間も募集中なので、気になる方は↓の記事を覗いてみてくださいませ。
いい会社だと思いますよ。


いいなと思ったら応援しよう!