Amazon RDSからAurora MySQLへの移行手順まとめ 2025

自己紹介

こんにちは。
株式会社Sun Asteriskでインフラエンジニアとして従事しています渡邉というものです。

今回はジョインしたてのプロジェクトで、Amazon RDS (MySQL) から Amazon Aurora MySQL へ移行した際の手順をまとめます。
実際の本番環境で行った流れをベースにしていますが、特定のシステム名やホスト名などの固有情報は一般化してあります。Aurora 移行を検討している方の参考になれば幸いです。

なぜ Aurora へ移行したのか？

Aurora MySQL を選んだ理由は以下です。

• スケーラビリティ: 読み取り専用インスタンスを柔軟に追加できる
• 可用性: マルチ AZ 構成と自動フェイルオーバーが標準でサポート
• パフォーマンス: 通常の MySQL よりもスループットが高い
• RDS Proxy の利用: 接続プールを効率的に扱うことで、Lambda や Fargate からの大量の同時接続にも安定して対応可能
• ゼロダウンタイムパッチ: Aurora はインプレースでのマイナーバージョンアップをサポートしており、アプリへの影響を最小限にしながらアップデートできる

これらの特長により、既存の RDS MySQL を Aurora MySQL に移行することにしました。

軽い構成の変更image

以下のようなシンプルな構成で変更点はRDSがAuroraになるのみ。

移行作業の流れ

1. メンテナンスモードに移行
   • RDSからAurora MySQLの移行はスナップショットからの移行となるためサービスを停止する必要があります。よって深夜作業となりました。協力いただいた皆様へ感謝申し上げます。
   • 時間になりましたらアプリをメンテナンス画面へ切り替え、アクセスされユーザーにお知らせを表示し影響が出ないようにしました。
2. ECS サービスの一時的な停止
   • アプリケーションが古いDBにアクセスしないよう、ECSサービスのタスク数をゼロに変更。
   • その他、管理画面やバッチ処理等のサービスを止めていきます。
3. スナップショット取得
   • 元のRDS MySQLの最新スナップショットを取得。
   • これをベースにAuroraクラスタを作成します。
4. Aurora MySQL クラスタ作成
   • 以下の設定でクラスタを作成しました：
     • エンジン: Aurora MySQL 3.x (MySQL 8.0互換)
     • インスタンスタイプ: db.r7i.2xlarge
     • セキュリティグループ・サブネットグループは既存 VPC に合わせて設定
     • ログ出力とマイナーバージョン自動アップグレードを有効化
   • まず Writer インスタンスを作成し、その後 Reader インスタンスを追加しました。
5. 接続先の切り替え
   • 移行後のDBエンドポイントに合わせて、各種接続設定を変更しました。
     • パラメータストア: アプリが参照するDBエンドポイントの値を新しいものへ更新
     • ECSタスク定義: 環境変数のDBエンドポイントを新しいAuroraエンドポイントへ変更
     • Lambda: 環境変数を一括で更新するスクリプトでAuroraエンドポイントへ変更
6. サービス再起動
   • ECSサービスのタスク数を元に戻し、正常にアプリが動作することを確認しました。
   • 更新はデプロイ時に「強制的新しいデプロイ」を選択し、確実に環境変数が反映されるようにしました。
7. 動作確認
   • アプリ・管理画面・バッチ処理などを総合的にチェックし、問題がないことを確認しました。
   • メンテ終了

切り戻し手順も準備

移行に失敗した場合に備え、切り戻し用の手順も事前に用意していました。

• パラメータストアを元の値に戻す
• ECS / Lambda / Glue の接続先を旧 RDS に戻す
• サービスを再デプロイして再起動
  これにより、万一のトラブルにも迅速に対応できる状態を確保しました。

工夫したポイント

今回の移行において、いくつか工夫した点があります。

1. 手動作業を支援するスクリプトの用意
   • Terraform でリソース自体は管理しているものの、実際のメンテナンス作業は一時的に手動で実施せざるを得ない場面がありました。例えばECS / Lambda / GlueのDB接続先の切り替えや環境変数の変更などです。これらを都度手入力で行うのはヒューマンエラーのリスクが高いため、Bash スクリプトを作成し、定型的な操作を自動化しました。これにより、作業のスピードと正確性が大きく向上しました。
2. Terraform import をスムーズに実施
   • 移行作業後は、メンテナンス後のリソースを terraform import で IaC 管理下にする必要がありました。この際、特に役立ったのは、Terraform コードがあらかじめ モジュール化されていたことです（前任者に感謝）。リソースごとに散在していないため import の対象が明確で、作業手順をシンプルにできました。
     もちろん変更点が多かったため多少の調整は必要でしたが、モジュール化されていたおかげで「どのファイルにどのリソースを定義するか」を迷うことなく進められ、結果的に diff の最小化につなげることができました。

まとめ

本記事では、Amazon RDS (MySQL) から Aurora MySQL への移行手順を紹介しました。
単に手順を踏むだけでなく、手動作業を補助するスクリプト化や、Terraform import をスムーズに行うための工夫といった運用上の工夫も盛り込むことで、実際の現場でのリスク低減や効率化につなげられました。

Aurora 移行は一見シンプルに見えても、ECS・Lambda・Glue など複数サービスとの接続切り替えや IaC 管理との整合性確保が課題になりやすい部分です。今回の取り組みが、これから同様の移行を検討される方の参考になれば幸いです。