MySQL5.7から8.0へAmazon RDS ブルー/グリーンデプロイを使って移行する

こんにちは。エキサイトでエンジニアをしている吉川です。

私が担当しているサービスで使用しているMySQL DBについて、先日5.7系から8.0系にバージョンアップを行いましたので、ご紹介させていただきます。

環境

・Amazon RDS Aurora　
・旧エンジンバージョン：5.7.mysql_aurora.2.11.2
・新エンジンバージョン：8.0.mysql_aurora.3.04.0
・クラスターの状態：1DBクラスターに、1リーダーインスタンス、1ライターインスタンスが紐付く

Amazon RDS ブルー/グリーンデプロイとは、RDSを移行する際のダウンタイムを1分かからない（=移行中に抜け漏れるデータをほぼなくせる）ようにできるサービスです。

以下のようなステップをマネジメントコンソールからポチポチで作業できます

早速やっていきます。

以下のような状態になればOKです。

なおステージング環境に旧環境のデータがコピーされるので、この切り替え前の時点ではそこそこ時間がかかります。手元の環境で空のDBで試したところ1時間弱かかっていました。全部まとめて数分で終わる話かなと最初思っていましたが勘違いでした。。。（流石にそんなオイシイ話はないですね）

現在使用しているDBクラスター用のパラメータグループについて、binlog_format=ROW（またはMIXED）にしておく必要があります
現在使用しているパラメータグループが同期できていないとステージング環境を作成できません
- もしbinlog_format=ROW（またはMIX）になっていない、またはパラメータグループを変更しても同期できていない場合は、DBインスタンスを再起動する必要があります（この再起動にはダウンタイムが発生します）
ステージング環境を作る時点で、そこで使用する新しいパラメータグループが必要になります。デフォルトでもOKですが、旧環境でパラメータをデフォルトから変更していたので、新規でaurora-mysql8.0用のパラメータグループを作成しました。
旧環境のインスタンスクラスが新環境で使えない場合、ステージング環境を作る前にクラスを上げる必要があります
- 5.7系ではdb.t3.smallを使っていましたが、8.0系ではdb.t3.mediumから使用可能なので、先に上げることになりました

以下のような状態になればOKです。

私のチームでは「ライブラリ改善タイム」というのを設けていて、業務時間内にMySQLや開発言語のバージョンアップの調査・実施を行えるようにしています。頻繁にやるものではないので、必要になった際に週1回3、4時間間隔で実施する形をとっています。

今回の移行はその時間を使って行いました。またMySQL5.7系→8.0系はそこそこ破壊的な変更があり、プロダクトにどこまで影響があるかチェックするのもこの時間に行なっていました（Blue/Greenデプロイとは主旨がずれるので今回は割愛します）。

個人的に、このような機能開発とは別だけど必要なタスク、というのは専用の時間をとって一気にやった方が進むなと思いました。チーム全体でライブラリ改善を行うので、コード書いてなくても後ろめたさがないとも感じました。

また「ライブラリ改善タイムで行ったことはドキュメントにまとめる」というルールがあるので、本番環境で実施する際や、このように社外に公開するときに役立つとも思います。

旧環境を残しておくのは料金的にはあまりよろしくないです。インスタンスを停止させることはできますが、1週間で再起動されてしまいます。継続して停止させたい場合は、EventBridgeなどを使って明示的に停止し続けさせることになります。

停止させ続ける必要も特にないので、今回は移行完了後1週間をメドにクラスター、インスタンスを削除するようにしました。（念のため削除前に最終スナップショットはとっています）

いかがだったでしょうか？これから5.7系->8.0系の移行作業を行う方、また今後のバージョンアップの際の助けとなれば幸いです。 Blue/Greenデプロイ自体は本当に簡単に済んだので、個人的には今後の破壊的変更はあまりないといいなと思っています（笑）

今年のアドベントカレンダーも見どころ満載でお届けしますので、明日以降の記事もぜひお楽しみください！

またエキサイトではデザイナー、エンジニアを絶賛募集しております！ご興味があればこちらからご連絡ください！