[AWS][RDS]プロビジョンドIOPSから汎用SSDにダウンタイムなしで変更できるのか検証

f:id:nishi-comcom:20200908112607p:plain

最近AWSのRDS（MySQL）のストレージタイプをプロビジョンドIOPS SSDから汎用SSDに変更しました。
コスト削減が目的なのですが、変更時にダウンタイムが発生するかということを検証せずには実行できなかったので、検証してみました。

結論
現在のデータベース設定
変更後のデータベース設定
変更にあたって考慮したこと
ダウンタイム検証
検証開始

結論

結論から申しまして、ダウンタイムなしでAWSのRDSのストレージタイプをプロビジョンドIOPSから汎用SSDに変更することができました。

現在のデータベース設定

マルチAZ：YES
インスタンスサイズ：db.t.2.medium （$150/月）
ストレージタイプ：プロビジョンドIOPS (SSD)
ストレージサイズ：1000GB （$300USD/月）
プロビジョンドIOPS:3000 IOPS（$720USD/月）
スナップショット：9世代（$60/月）

合計 $1,230/月

このDBにはあまり当初想定したほどのアクセスがないので、コスト削減するためにストレージタイプを汎用SSDに変更したいと思っています。

変更後のデータベース設定

インスタンスサイズ：db.t.2.medium（$150/月）
ストレージタイプ：汎用SSD
ストレージサイズ：1,000GB（$276USD/月）
スナップショット：9世代（$60USD/月）

合計 $486/月

となりまして、月額$744の削減を目指します。

変更にあたって考慮したこと

こうしてみるといかにプロビジョンドIOPSが高いかわかるかと思います。
もちろん既存のストレージタイプを変更せずに、プロビジョンドIOPS自体を下げたり、ストレージサイズを下げるという手段も考えました。
まずAWSによると

ストレージを割り当てた後に DB インスタンスのストレージ容量を減らすことはできません。

とのこと。EBSと一緒ですね。
Amazon RDS DB インスタンスのストレージを使用する - Amazon Relational Database Service

ではIOPSはどうかというと、下げることはできるのですが、パフォーマンスに影響を出るのを恐れました。
日常では数百IOPS程度しか使っていないのですが、週一回くらいバーストして2,000IOPS程度まで一瞬上がることがあります。
果敢に攻めて1,000IOPSまで下げることはできるのですが、バーストを考えると少々怖いです。クレジットもありますので、多分大丈夫なんでしょうけども。

調べると汎用SSDではストレージ1GBあたり3IOPSが付いてくるとのことで、1,000GB分でしたら3,000IOPSがベースラインとなります。
コスト的にもこちらが優位ですので、ストレージタイプの変更を試みることにしました。

詳細な料金についてはこちらで確認してください。
aws.amazon.com

ダウンタイム検証

さて変更しようとしたときにまず考えるのは、ダウンタイムが発生するのかということです。
これに関する信用できる情報がないのか、かなり探しました。

SSDとHDD間の変更はダウンタイムが発生するという検証した人もいましたが、プロビジョンドIOPSから汎用SSDへの検証をした人は見つかりませんでした。
AWSの公式ドキュメントにもこのストレージタイプ変更についてのダウンタイムについては、はっきりと言及されているのを見つけられませんでした。
stackoverflowでは「ダウンタイムはないよ」とのコメントがあったのですが、そのAWSドキュメントのリンク先は内容が修正されており、かなり悩みました。

以下がもっとも近しい公式ドキュメントだとは思うのですが、どうにも表現が煮え切らないんです。

Amazon RDS DB インスタンスのストレージを使用する - Amazon Relational Database Service

結論として、ダウンタイムがあるのかないのかについての信用できそうな情報がみつからなかったので、実際に検証してみることにしました。

現在稼働中のRDBのスナップショットから同様の設定でデータベースを作成します。
死活監視にはmysqladmin pingを利用します。これにより、DBコネクションを貼っておきます。

踏み台サーバーにmysqlclientをインストールしまして、以下で確認します。RDBを再起動した際には、connectionが切れたので動作確認OKです。

mysqladmin -h xxxxxx.cnllmnmpnfrx.ap-northeast-1.rds.amazonaws.com ping -u dbuserid -ppassword -r -i 10
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqld is alive
mysqladmin: mysqld doesn't answer to ping, error: 'Lost connection to MySQL server during query'

検証開始

では実際に変更検証を初めたいと思います。

ここでストレージタイプを変更しようとすると脅しが出ます。それぞれのリンクですが、

初期の汎用 (SSD) I/O クレジットを消費し、変換により長い時間がかかるようになります

が
Amazon RDS DB インスタンスストレージ - Amazon Relational Database Service
でして、

変換が完了するまで、インスタンスのパフォーマンスに影響します。

が
Amazon RDS DB インスタンスのストレージを使用する - Amazon Relational Database Service

となってまして、中身読んでもピンとくるようなこと書いてないんです。

実験ですので進みます。確認画面でも「予期しないダウンタイム」と言われます。このダウンタイムがあるかどうかが今回の検証ポイントですので、検証のため即時変更を実施します。

本当は、ダウンタイムだけではなくパフォーマンスが落ちるかどうかも検証したほうがいいのでしょうが、そもそもIOPSに相当余裕がある状態でしたので、割愛しました。

終了までにはかなり時間がかかりました。利用しているボリュームは300GBだったのですが、変更完了まで約５時間を要しました。

さてダウンタイムはというと私の未熟さゆえにキレイな線にはなりませんでした。途中コンソールログアウト(18:45時点)したり、別からmysqladmin ping打ったりしてコネクションが２本になったりなど。すいません。
ですが、結論として開始直後からダウンすることはありませんでした。

さて興味深いのですが、書き込みIOPSです。変更中は一貫して約1,000IOPSを記録していました。3,000IOPSまでは確保できているので、書き込み2,000IOPSが常に空いている状態です。また読み込みは約550IOPSを記録していました。ベースラインまでは余裕ある状態ですが、このあたりがAWSのドキュメントにある「パフォーマンスへの影響」なのかなと思います。