Aurora MySQL を、v2（MySQL 5.7 互換）から v3 (MySQL 8.0 互換) へアップデートした記録。
私が開発に携わっている SaaS はデータストアとして Aurora MySQL を利用している。 Aurora MySQL v2 の EOL が 2024年10月に迫っているので、アップデートを行った。
タスクの洗い出し
まずはアップデートに必要なタスクを洗い出した。
ざっくり以下のようなタスクがあるだろうということになった。
アップデート手順の確立
- アップデート手法の検証（AWS Blue/Green Deploy の検証）
- 切り戻しの計画の検討
- アップデート手順書の作成と試験実施
アップデートによる影響の検証
調査
- MySQL バージョン間の動作の違いの洗い出し
- アプリケーションへの影響調査
動作確認
- 全SQLの動作確認
- アプリケーションの動作確認と修正
- AWS Lambda などアプリケーション以外の動作確認と修正
パフォーマンス検証
- 各 SQL ごとのパフォーマンス検証
- サービス全体のパフォーマンス検証
その他
- ローカル開発環境の MySQL アップデート更新
アップデートの実施
- アップデートの計画・スケジュール作成
- SaaS 利用ユーザへのメンテナンスの告知
- 全環境のアップデート実施
- 片付け作業
アップデート手法の確立
AWS Blue/Green Deploy によるアップデート手法の検証
アップデートによるダウンタイムをできるだけ短くしたいため、AWS Blue/Green Deploy によるアップデート手法を検証した。
事前に、binlog_format を ROW に変更するなど準備しておく必要がある。
Blue/Green 環境は AWS コンソールから画面ですぐに作成することができる。 作成すると、
- Blue 環境が既存の v2 の RDSクラスター
- Green 環境が新しい v3 の RDSクラスター
となり、Blue - Green 間で binlog によるレプリケーションが貼られる。
Blue 環境を Green 環境へ切り替えることで、アップデートが完了する。
検証環境では、1分未満のダウンタイムで切り替えることができることがわかった。
実際に本番環境でもこの程度の時間で切り替えが可能だった。
ダウンタイムはリーダーインスタンスでもライターインスタンスでも発生する。
切り戻しの計画の検討
Blue 環境と Green 環境を切り替えた後、Green 環境(新ver)をソースDB、Blue 環境(旧ver)をターゲットDBとして、binlog によるレプリケーションを貼ることで、切り戻しを行うことができる。
ただし、MySQL では、8.0 のデータベースから 5.7 のデータベースへのレプリケーションは可能であるが、動作保証はされていない。
このため、切り戻しはほぼ不可能と考え、できるだけ事前の検証に時間をかけて、切り戻す必要がないところまで検証することにした。
アップデート手順書の作成と試験実施
AWS Blue/Green Deploy によるアップデートで要件を満たせることがわかったので、開発環境のデータベースをアップデートする手順書を作成し、試験実施した。
いくつか細かい手順の見直しが必要であったが、問題なく実施ができた。
アップデートによる影響の検証
調査
まずは AWS や MySQL の公式ドキュメントをあさって、MySQL バージョン間の動作の差分の洗い出しを行った。
など。
その後、該当の差分がアプリケーションに影響を及ぼす可能性がある場所を洗い出した。
いくつか影響があった差分があった。
GROUP BYの暗黙的な並び替えの廃止
暗黙的な GROUP BY の並び替えが廃止されたため、GROUP BY 後に明示的に並び替えが必要になった。SQL に ORDER BY を明示することで解決した。
クエリキャッシュが削除される
Aurora MySQL v3 では、クエリキャッシュが削除された。これにより、クエリのパフォーマンスが低下する可能性があるため、MySQL v3 の RDS クラスターを使って、クエリのパフォーマンスを検証した。
検証した結果、パフォーマンスの低下はあったが、アプリケーションの動作に致命的な影響がでほどではなかった。
db.t3.smallクラスのインスタンスが使えなくなったAurora MySQL v3 では、開発環境のDBで使っていた
db.t3.smallクラスのインスタンスが使えなくなった。db.t3.mediumに変更した。
全SQLの動作確認
アプリケーションのリポジトリ層の SQL のテストとして、オンメモリのDBへ接続し SQL を実行する結合テストがすでにあった。
これを Aurora MySQL v3 の RDS クラスターに対して実行し、全ての SQL が正常に動作することを確認した。
なお、全ての SQL に対してテストがあるか不明だったので、テストカバレッジを調べて、足りないところは新たにテストを追加した。
アプリケーションの動作確認と修正
開発環境の RDS はすでに Aurora MySQL v3 にアップデートしていたので、そこでアプリケーションの e2e テストを実行して、アプリケーションが正常に動作することを確認した。
AWS Lambda などアプリケーション以外の動作確認と修正
他に影響があるところを洗い出して、動作確認を行った。以下が影響した。
- GitHub Actions から実行する DB マイグレーション処理
- AWS Lambda から実行する MySQL パーティションの作成処理
パフォーマンス検証
各 SQL ごとのパフォーマンス検証
複雑なクエリを洗い出して、一個ずつ実行して、パフォーマンスが低下していないことを確認した。
サービス全体のパフォーマンス検証
Locust を使って負荷試験を実施し、パフォーマンスが低下していないことを確認した。
アップデートの実施
ここまでで、実際にアップデートできる状態が整ったので、アップデートの計画・スケジュールを作成し、SaaS 利用ユーザへのメンテナンスの告知を行い、全環境のアップデートを実施した。
アップデートは深夜帯に行った。
AWS Blue/Green Deploy により、1分未満のダウンタイムで実施することができた。
振り返り
検証に時間をかけた
アップデートによる影響の検証に時間がかかったが、アップデート自体は AWS Blue/Green Deploy によりスムーズに実施することができた。
検証に時間をかけたことで、特に問題なくアップデートを実施することができた。
テストがあったことが大きかった
SQLのテストカバレッジが高かったことと、e2e テストがあったことが、アップデートによる影響の検証をスムーズに進めることができた。テストが通ったことで、問題なくアップデートできることの自信にもつながった。
テスト大事。
かかった時間
だいたい 4ヶ月くらいはかかった。
- 2023 / 10 : 検証
- 2023 / 11 : 試験環境でのアップデート, パフォーマンス検証
- 2024 / 01 : ステージング環境のアップデート
- 2024 / 02 : 本番環境のアップデート