RDSを短いダウンタイムでgp2へ移行する方法

はじめに

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日RDSでGeneral Purpose (SSD) Storage、通称gp2が選択可能になったのでベンチマークをしましたが、ストレージの違いだけでMagneticの4倍程度のスループットが出ました。

既存のMagneticで構成しているRDSもgp2へ移行してスループットを向上するために、移行方法を検討してみました。

どんな移行方法があるか？

既存インスタンスをそのままディスク変更

これが、一番簡単な方法です。各RDSインスタンスのModifyでStorage Typeを変更するだけで実行できます。 しかし、注意点も有ります。Modify画面でStorage Typeをgp2へ変更すると以下の注意書きが表示されます。

つまり、Multi-AZだとフェイルオーバーを伴って変更するので60~120秒の間RDSへアクセスが出来ないという事です。変換にはバックグラウンドで数時間かけて移行し、パフォーマンスへの影響が有るようです。 RDSの停止時はModifyの実行直後ではなく、諸々の準備が出来た後に行われます。そのため、切換え時間が気になる場合にはシステムを長時間メンテナンスに設定する必要が有ります。

リードレプリカまで有るとメンテナンス時間が読めなくなりますね。

システムのメンテナンス時間を短くするには？

RDSの停止時間を短くするのは難しそうですが、システムのメンテナンス時間は短くしたいですよね？

ということで、サービス提供時間を短くする移行方法を検討してみました。

リードレプリカがある事を前提とした手順のため、MySQL限定となります

移行方法は以下の様な流れです。

移行前の状態

マスタと複数のリードレプリカで構成されているRDSを想定します。

移行１

ここに次のマスタとなるインスタンスをストレージをgp2にしてリードレプリカとして追加します。

注意点として、作成したインスタンスの自動バックアップを有効にする為に、Backup Retention Periodを1以上に設定して下さい。自動バックアップが無効の状態だと『移行２』でリードレプリカが作成できません。

移行２

次のマスタとなるインスタンスに対して、さらにリードレプリカを作成します。こちらのストレージもgp2で作成します。

移行３

アプリケーションで見ているリードレプリカを移行先のリードレプリカへ変更します。移行先のリードレプリカでもマスタのデータ更新が反映されます。 リードレプリカの切換えを行いますが、システム全体としてのダウンタイムは発生しないはずです。

各RDSのエンドポイントをDNSで別名を設定しておくと、アプリケーションを変更せずに切換えが可能となります。Route 53のにパブリックなドメインを設定しておくとAWSの設定だけで切換えできます。

移行４

ここでRDSのサービス停止が発生します。

メンテナンス設定システム

システムのメンテナンスを設定しましょう。

旧マスタへの書込み停止

マスタ昇格を行う前に、全てのトランザクションを完了させる必要があります。誤って書き込まない様に、セキュリティグループでアプリケーションからアクセスできない設定を行いましょう。

マスタ昇格

次のマスタをマスタ昇格させて、本当のマスタへ切り替えます。

アプリケーションの接続先切換え

アプリケーションで接続しているマスタを切り替えましょう。 『移行３』と同様にDNSで別名を設定しておくと切換えが容易になります。

メンテナンス解除

RDSへ書込みが可能になっているので、メンテナンスを解除します。

マスタにHA構成が必要な場合は、ここでMulti-AZへ変更しましょう。Single-AZからMulti-AZへの切換えにダウンタイムは発生しないので、メンテナンス解除後でも良いと思います。

移行５

システムの稼働を確認した後で、ゆっくり不要になったRDSを削除しましょう。

まとめ

かなり面倒な手順でした。しかし、そのおかげでRDSの停止時間が『移行４』の間だけとなるので、システム全体のダウンタイムが極小化できました。

おまけ

もっとダウンタイムを短くできるかもしてません。 かなり無理矢理ですが、提案した構成にMySQL on EC2を挟むとマスタ昇格を待つための時間が無くなるのでダウンタイムが短くなるかもしれません。 RDS→RDSではマスタ同士でレプリケーションで来ませんが、MySQL on EC2とはRDSのマスタとレプリケーションできるため、下図の様な構成が出来るかもしれません。