背景

開始から9年間稼働中のサービスで利用しているRDS for MySQL 5.7の標準サポートが2024年2月末に終了となるため、RDS for MySQL 8.0へアップグレードすることになりました。
また、RDSと比較するとインスタンスの耐障害性が高く、インスタンスの選択や構成を工夫することでコスト面でメリットがある（約100万円/年のコストが削減できる）ことから、併せてAurora MySQL 3（MySQL 8.0 互換）へ移行することになりました。

Aurora MySQL 3（MySQL 8.0 互換）への移行方法の検討

これらのドキュメントなどを参考に移行方法を検討し、DB クラスターのスナップショットからの復元の方法を採用することにしました。

「RDS for MySQL 8.0へアップグレード」→「RDS for MySQL 8.0からAurora MySQL 3へ移行」の2つの対応をおこないます。

移行スケジュール

契約更新の関係上、Aurora MySQL 3への移行は2024年1月に実施することが決まっていました。
「RDS for MySQL 8.0へアップグレード」と「Aurora MySQL 3への移行」を同時に行うか検討しましたが、実施中に問題が発生した場合の対応（調査や切り戻しなど）が複雑になる可能性を考慮して別々に行うことにしました。
別々に実施することでサービス停止が2回必要になってしまいますが、より確実・安全に実施することを優先しました。

MySQL 8.0へのアップグレードにおける変更点の確認

こちらのドキュメントにSQLの変更がまとめられています。

ローカル環境でMySQL 8.0における変更点を確認し、必要な対応をおこないました。 また、各アプリケーションの動作も確認しました。

予約後の追加（MySQL 8.0 の新しいキーワードおよび予約語）

「lead」という単語が予約語に追加されていました。既存のテーブルのカラム名に「lead」を使用していたため、カラム名を変更する対応をおこないました。

暗黙的ソートの変更（ORDER BYの最適化）

GROUP BY句、DISTINCT句の暗黙的ソートが廃止になり、ORDER BY句を使う必要が生じました。
こちらについては元々ORDER BY句を使うようにしていたので影響はありませんでした。
お客様の別のサービスでは、この影響による修正にかなり手間取ったそうです。

検証環境でRDS for MySQL 8.0へアップグレード

次は検証環境でアップグレードをおこない、各アプリケーションの動作を確認します。

手順は以下の通りです。
本番環境で計画通りに実施できるようにするため、検証環境での確認は非常に重要だと考えています。

  1. 各アプリケーションの停止
  2. RDS for MySQL 5.7のスナップショットの取得
  3. RDS for MySQL 8.0用のパラメータグループの作成および内容の変更
  4. RDS for MySQL 8.0へアップグレード
  5. 各アプリケーションの起動

RDS for MySQL 8.0へのアップグレードはスムーズにおこなうことができました。

本番環境でRDS for MySQL 8.0へアップグレード

ローカル環境、検証環境で確認ができたので、本番環境でRDS for MySQL 8.0へアップグレードを行います。
予定したメンテナンスの時間内にサービスへの影響もなく、無事にアップグレードを完了させることができました。

検証環境でAurora MySQL 3へ移行

次は検証環境でAurora MySQL 3へ移行します。

手順は以下の通りです。
こちらも本番環境で計画通りに実施できるように意識しながら実施します。

  1. 各アプリケーションの停止
  2. RDS for MySQL 8.0のスナップショットの取得
  3. Aurora MySQL 3のリードレプリカを作成
  4. Aurora MySQL 3のリードレプリカの昇格
  5. Route 53 のDB接続用レコードのエンドポイントをRDS for MySQL 8.0からAurora MySQL 3に変更
  6. 各アプリケーションの起動

この手順でAurora MySQL 3への移行を進めていきます。

「3. Aurora MySQL 3のリードレプリカを作成」を実行すると以下のメッセージが表示されました。

「Cannot upgrade from mysql 8.0.35 to aurora-mysql8.0.mysql_aurora.3.05.1.Specify a current active database version, the latest active minor version for mysql 8.0 is 8.0.33.」

RDS MySQL 8.0へアップグレードしたときにバージョンを当時の最新である「8.0.35」にしました。
ですが、当時のAurora MySQL 3では「8.0.35」へのサポートがされていませんでした。
ちなみに、現在はサポートされています。（Amazon Aurora MySQL 3.06 (MySQL 8.0.34 互換) の一般提供が開始）

事前の調査・確認が足りていませんでした。 AWSのドキュメントをしっかり確認すべきでした。

どうやってAurora MySQL 3へ移行するか

Aurora MySQL 3へ移行するためにはRDS for MySQL 8.0のバージョンを「8.0.32」にする必要がありました。
AWSのコンソールではRDS for MySQLのダウングレード（「8.0.35」から「8.0.32」）はできません。
そこでRDS for MySQL 8.0へアップグレードした時に取得したRDS for MySQL 5.7のスナップショットを利用してRDS for MySQL 8.0（8.0.32）へアップグレードすることにしました。
スナップショットから別インスタンスとして復元させるため、本来なら必要がないインスタンスを一時的に作成することになりますが、やむを得ない状況でした。

また、RDS for MySQL 5.7から再実施するため、RDS for MySQL 8.0（8.0.35）の最新データを取得しておき、RDS for MySQL 8.0（8.0.32）へアップグレードした後にインポートする必要があります。
マイナーバージョンが下がるため MySQL 8.0 Release Notes を確認し、ローカル環境で適用可能であることを確認しました。
インポートについては差分インポートも考えましたが、手順や確認が複雑になることや本番環境のデータでどれくらい時間が短縮できるかわからないといった懸念点があったため、全量インポートにすることにしました。

以下の手順でAurora MySQL 3へ移行することができました。

  1. 各アプリケーション、バッチを停止
  2. RDS for MySQL 8.0（8.0.35）のdumpを取得（最新データを復元するため）
  3. RDS for MySQL 5.7のスナップショットから別インスタンスとして復元（RDS for MySQL 8.0（8.0.32）へアップグレードするため）
  4. RDS for MySQL 8.0（8.0.32）へアップグレード（Aurora MySQL 3（3.05.1）のサポート対象）
  5. 2.で取得したデータをインポート（RDS for MySQL 8.0（8.0.35）の最新データを復元）
  6. Aurora MySQL 3（3.05.1）へ移行（リードレプリカを作成、昇格）
  7. Route 53 のDB接続用レコードのエンドポイントをRDS for MySQL 8.0からAurora MySQL 3に変更
  8. 各アプリケーション、バッチを起動

本番環境への対応は稼働中のサービスを停止させる必要があり、サービス停止時間を決定するために各作業の所要時間を計測します。
9年間運用してきましたが、本番環境の全データのインポートは実施したことがなく、どれくらい時間がかかるか見当がつきませんでした。
そこで本番環境と同等のインスタンスを検証環境に用意して確認したところ、本番環境の全データのインポートは約40分かかることがわかりました。
事前に検証する作業工数やAWSの利用コストは発生してしまいますが、稼働中のサービスで問題を発生させてしまう方が損害になりうると考え、お客様にもその必要性を理解していただきました。

本番環境でAurora MySQL 3へ移行

検証環境で確認できたので、本番環境でAurora MySQL 3への移行を実施します。
稼働中のサービスなので、サービスの停止時間は極力短くすることを意識します。
「スナップショットから復元」と「RDS MySQL 8.0（8.0.32）へアップグレード」は別インスタンスとして実施できるため、別途事前対応としました。
朝4時から準備・事前対応を開始、4時30分から移行作業を実施し、予定通り7時30分にサービスを開始することができました。

本番環境での実施時間は以下の通りでした。

準備・事前対応

  1. RDS for MySQL 5.7のスナップショットから別インスタンスとして復元（約10分）
  2. RDS for MySQL 8.0（8.0.32）へアップグレード（約15分）

Aurora MySQL 3への移行作業

  1. 各アプリケーション、バッチを停止（約10分）
  2. RDS for MySQL 8.0（8.0.35）のdumpを取得（約15分）
  3. 2.で取得したデータをインポート（約45分）
  4. Aurora MySQL 3（3.05.1）へ移行（約60分）
  5. Route 53 のDB接続用レコードのエンドポイントをRDS for MySQL 8.0からAurora MySQL 3に変更（約5分）
  6. 各アプリケーション、バッチを起動（約10分）

最後に

今回はRDS for MySQL 5.7をRDS for MySQL 8.0にアップグレードし、その後にAurora MySQL 3に移行したお話でした。
いろいろと対応することはありましたが、それぞれしっかり確認しながら進めれば恐れることはないと思います。
ドキュメントの確認不足という反省点はあったので、今後に生かしたいです。

対応コストはかかりますが、本番環境での実施を想定した検証環境での事前の検証や懸念点を解消することは重要だと考えます。
そのため、検証の重要性をお客様に説明することも欠かせません。
今回、検証のコストや環境を用意することへ理解していただいたことに改めて感謝しています。

これからも様々な運用保守対応や追加改修が続いていきますが、しっかりと対応していきたいと思います。