【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた

#Amazon RDS

#AWS

植木和樹

2014.01.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹です。AWSでEC2と並んでよく使われているサービスがRDSだと思います。障害時のフェイルオーバーやバックアップも自動で行ってくれるため、データベースを手間をかけずに利用することができ本当に便利なサービスです。

さてRDSを用いたサービスをリリースしてしばらく経つと、徐々にCPUやメモリなどの使用率が増えていき、いよいよインスタンスタイプの見直しを検討しなければならなくなるかと思います。その時に気になるのが「インスタンスタイプ変更にはどれくらい時間がかかるのか？」「サービスの停止が必要なのか？」という点です。

本日はSingle-AZ/Multi-AZそれぞれのRDSについて、インスタンスタイプの変更にかかる時間や挙動を調べてみました。

今回のブログに記載したインスタンスタイプ変更の流れは、AWS公式のものでなくイベントログやDBの動きから筆者個人が「おそらくこういう処理が行われているのだろう」と推測したものです。今後AWSの仕様変更により挙動が変わる可能性がありますのでご注意ください。

環境

RDSは以下の環境で作成しました。

Engine	mysql(5.5.33)
Primary-AZ	ap-northeast-1c
Secondary-AZ	ap-northeast-1a（Multi-AZ時）
Storage	5GB
Instance-Type	m1.small -> m1.large

RDSスケールアップの動き

Single-AZ

RDSイベント

#	Time	System Notes
1	2014-01-25 18:08:34	Applying modification to database instance class
	（ここからDBに接続できなくなる）
2	2014-01-25 18:14:25	Finished applying modification to DB instance class
	（ここからDBに接続できるようになる）

インスタンスタイプ変更の流れ

Sigle-AZのRDSインスタンスがシャットダウンし、インスタンスタイプの変更が行われる。DBのセッションはクローズされ、接続もできなくなる。
インスタンスタイプ変更後、再びRDSが起動し接続できるようになる。

結果

インスタンスタイプの変更にはインスタンスのリブートが伴う。
サービス停止時間はインスタンスタイプの変更とリブート時間に依存する。
サービス停止は最低でも6分程度かかる。

Multi-AZ

RDSイベント

#	Time	System Notes
1	January 25, 2014 7:28:31 PM UTC+9	Applying modification to database instance class
2	January 25, 2014 7:35:22 PM UTC+9	Multi-AZ instance failover started
	（ここからDBに接続できなくなる）
3	January 25, 2014 7:35:32 PM UTC+9	DB instance restarted
4	January 25, 2014 7:36:37 PM UTC+9	Multi-AZ instance failover completed
	（ここからDBに接続できるようになる）
5	January 25, 2014 7:44:56 PM UTC+9	Finished applying modification to DB instance class

インスタンスタイプ変更の流れ

Multi-AZのセカンダリ側インスタンスのインスタンスタイプの変更が行われる。
アクティブ→スタンバイへのフェイルオーバーが行われる。DBのセッションはクローズされ、接続もできなくなる。
セカンダリ側AZでインスタンスが起動する。その後クラッシュリカバリプロセスが実行される。
フェイルオーバーが完了する。再びRDSが起動し接続できるようになる。
プライマリ側インスタンスのインスタンスタイプの変更が完了する。

結果

インスタンスタイプの変更にはインスタンスのフェイルオーバーが伴う。
サービス停止時間はフェイルオーバーの時間に依存する。
サービス停止は最低でも1分程度かかる。

まとめ

インスタンスタイプ変更にはSingle-AZの場合インスタンス再起動、Multi-AZの場合はフェイルオーバーが発生する
インスタンスタイプの変更そのもののプロセスは6〜8分ほどかかる。
フェイルオーバー（クラッシュリカバリプロセス）にかかる時間はRDSの状況次第。
（参考）【AWS】RDS for MySQLで共有テーブルスペースに構成変更する際の所要時間を実測してみた｜ Developers.IO
ユーザーがサービス使用中の影響を考えるとサービスを停止させての作業を推奨

RDSは更新処理のスケールアウトが設計しずらくボトルネックになりやすいサービスです。ユーザーの利便性をあげるためサービスに次々と機能を追加すれば、どうしてもDBの負荷もあがりがちです。しかし24x365でサービスを提供している場合は、なかなかスペックアップのためのメンテナンスのための時間もとりにくいと思います。サービスイン時、まずはインスタンスタイプ変更によるサービス停止時間が短くなるMulti-AZ構成にしておくようにしましょう。また1分程の停止も難しいサービスの場合は、あらかじめ少々大きめのインスタンスタイプを選択することも検討しておくのが良いかと思います。