この記事はポート株式会社 サービス開発部 Advent Calendar 2025の7日目の記事です。
はじめに
ポート株式会社で SRE 業務をしている井上です！
普段の業務では AWS や Terraform などを使っていますが、中でも特に緊張感の高かった「本番環境での RDS (MySQL) → Aurora MySQL 移行に伴うメンテナンス作業」についてお話ししたいと思います。
本記事では実際に私が実施した手順と学びを共有します。環境によって手順は異なりますので、必ず事前検証を行うようにしてください。
より効率的な方法や、改善点などがありましたらご指摘いただけますと幸いです！
移行の流れ
移行作業は、「事前準備 → メンテナンス作業 → 後始末」の流れで対応しました。
メンテナンス当日は、事前に作成しておいた Aurora クラスターを昇格させ、RDS から独立させる方式を採用しました。この方式により、メンテナンス時のダウンタイムを約80分に抑え、大きなトラブルなく移行を完了することができました。
移行前の構成
最初の状態は Primary に対して Read Replica が紐づく RDS のみの構成です。
RDS-Primary
└─ RDS-Replica
次に、メンテナンス実施日の前日などに、RDS からデータをレプリケーションする、新しい Aurora クラスターを作成しておきます。
この状態からメンテナンスを開始します。
RDS-Primary
├─ Aurora-Cluster
│ ├─ Aurora-Writer
│ └─ Aurora-Reader
└─ RDS-Replica
移行後の構成
メンテナンス中は主に以下の作業を行います。
- Aurora クラスターを昇格させ、RDS から切り離す
- アプリケーションからの接続を全て Aurora に向ける
メンテナンス直後は以下の構成になります。この状態でユーザーアクセスの受け付けを再開します。
RDS-Primary
└─ RDS-Replica
Aurora-Cluster
├─ Aurora-Writer
└─ Aurora-Reader
最後に、RDS へのルーティングがないことを確認した上で RDS を削除します。
Aurora-Cluster
├─ Aurora-Writer
└─ Aurora-Reader
移行手順の詳細
では、実際に私が対応した一連の手順について紹介したいと思います。
事前準備
1. Aurora 用パラメータグループ作成 & 調整
Aurora 用のパラメータグループを作成します。
既存の RDS パラメータグループでデフォルト値から変更されてる部分のうち、Aurora にも適用した方が良さそうなパラメータは調整しました。
2. ユーザーへのメンテナンス告知
Aurora 移行はユーザーからのサービスへのアクセスを止めて行うため、ユーザーに向けてメンテナンス実施の告知を行います。
3. Aurora クラスターの作成
メンテナンス実施日の前日などに、RDS からデータをレプリケーションする新しい Aurora クラスターを作成しておきます。
こうすることで、RDS へ書き込まれたデータは、順次 Aurora にも同期されるようになります。
4. 定期ジョブの停止
本番環境への影響を防ぐため、以下のような定期ジョブを事前に停止しておきます。
- バッチ処理
- データインポート処理
- 集計処理
- メール送信処理
5. DNS の準備
今回 Aurora へ移行するサービスでは、アプリケーションの DB 接続情報には、RDS エンドポイントを直接記述せず、Route 53 で設定した独自の CNAME レコードを使用しています。
このように接続を抽象化することで、アプリケーションの設定ファイル (database.yml など) を変更することなく、CNAME レコードの参照先のみを Aurora のエンドポイントへ変更するだけで、DB 接続先を Aurora へ瞬時に切り替えることが可能になるからです。
ここで CNAME レコードの TTL (Time To Live) を事前に短縮 (60秒→5秒) しておき、DNS 切り替えがすぐに反映されるようにしておきます。
移行当日の手順
ここからがいよいよ本番です。
ユーザーアクセスの少ない早朝にメンテナンスを入れて移行を行いました。
1. メンテナンスモード開始
準備が整ったらメンテナンスモードを開始します。
今回の場合は、社内 IP のみ許可した以下のような WAF に切り替えることでメンテナンスを実現しました。
- デフォルトアクションは Block
- ユーザーには Status: 503でメンテナンス画面を表示する
- 社内 IP のみ Allow
- 社員は社内 IP 経由でアクセスすれば、通常のサービス画面で動作確認ができる
2. レプリケーション確認
メンテナンスモードに切り替わったら、Aurora に問題なくデータがレプリケーションされているか確認します。
もし RDS に書き込まれたデータが Aurora に同期される前に移行してしまうと不整合が発生してしまうためです。
具体的には、Aurora に接続し、以下のコマンドを実行して Seconds_Behind_Master が 0 であることを確認しました。
SHOW SLAVE/REPLICA STATUS\G
3. Aurora クラスター昇格
AWS CLI またはマネジメントコンソールで Aurora クラスターの昇格を実行し、RDS から切り離します。
この昇格自体はすぐに終わりました。
この時点での構成は以下のように RDS と Aurora が独立した状態です。
4. スナップショット作成
念の為 RDS, Aurora 両方のスナップショットを作成しておきます。
何かあった時最悪このスナップショットから DB を復元するためです。
- RDS: 40分
- Aurora: 5分 (早い！)
ダウンタイムの時間を短縮するために、スナップショットの作成を待つ間、次の「5. エンドポイント切り替え」作業を並行で行います。
5. DB エンドポイント参照先切り替え
現時点ではまだ RDS を参照している状態のため、アプリケーション接続の参照先を全て Aurora へ切り替えます。
5-1 参照先更新
RDS を参照している以下の接続先を Aurora のエンドポイントに更新します。
- アプリケーションの DB 接続情報 (Route53 CNAME レコードの参照先)
- データ連携ツール (Google Cloud Datastream)
5-2 アプリケーション接続再起動
- コネクションプールを強制的に再起動するため、アプリケーションの空デプロイを実行
- 動作検証
- 新しい Aurora エンドポイントへの接続確認
- DB への書き込みが Aurora 側のみに行われていることを確認
6. メンテナンスモード終了
切替後の動作検証で問題がなければメンテナンスモードを解除し、本番サービスへのアクセスを再開します。
- DNS TTL を元に戻す (5秒→60秒)
- 元の WAF に戻し、メンテナンスモードを解除
移行後の作業
1. 定期ジョブの再開
停止していた定期ジョブを順次再開します。
2. データ同期の確認
Aurora リーダーインスタンスから分析用のデータが問題なく同期されているか確認します。
- Datastream による BigQuery への同期状況確認
- 必要に応じてバックフィル実行
3. 旧 RDS の削除
しばらく様子見て問題なければ RDS を完全に削除します。
まとめ
今回の RDS から Aurora への移行は、適切な事前準備と並行作業により、ダウンタイム約80分で完了することができました。
本番環境でのメンテナンス作業は非常に緊張感がありましたが、この成功は以下の要因に支えられました。
- ステージングでの事前検証
- 本番メンテナンス前の事前準備
- 詳細な手順書の作成 & レビュー
- 作業の並行化による時間短縮
また、Aurora 移行によりバックアップ時間の大幅短縮 (40分→5分) や運用性向上など、期待していたメリットを得ることができました。
同様の移行を検討している方の参考になれば幸いです！
参考資料
ポート株式会社は、「社会的負債を、次世代の可能性に。」をパーパスに掲げ、人材領域およびエネルギー領域を主力事業とした事業を展開しています。人材領域では、「キャリアパーク！」「就活会議」「みん就」などのサービスを提供しています。
Discussion