Chapter 03

移行計画の立て方

hmatsu47
hmatsu47
2022.09.29に更新

この章について

移行計画を立てる上でのポイントを記します。

移行のステップ

一部、順番に前後があるかもしれませんが、概ね以下のようなステップを考えます。

  1. Aurora MySQL v1 → v3 の変更点と移行方法に関する情報を調査する
  2. アプリケーションコードと Aurora MySQL クラスタ・インスタンス等の設定から、変更点に該当する箇所を洗い出す
  3. 調査結果をもとに、v3 への移行を進めるか一旦 v2 までの移行に止めるかを決める
  4. v3 への移行を進める場合、必要があれば変更点を修正する
  5. 同様に、必要に応じてコーディングルールやテーブル設計ルール、サーバ等設定ルールを調整する
  6. 検証環境を構築し、動作検証(性能検証・移行手段の検証を含む)を行う
  7. 動作検証の結果をもとに、v3 への移行を進めるか一旦 v2 までの移行に止めるかを最終決定する
  8. v3 への移行を進める場合、アプリケーションコードの可能であれば移行前にリリースする
  9. 10.〜15. を実施するための手順書を作成する
  10. 移行作業のリハーサルを行う(移行手順に問題があれば修正して再度リハーサル)
  11. メンテナンス停止日を決定し、ユーザにアナウンスする
  12. 移行の事前作業を行う(スナップショット復元で v3 クラスタを立てて DMS レプリケーション開始)
  13. メンテナンス停止を行い、移行(DB バージョンアップ)する
  14. 移行の事後作業を行う(DMS 逆方向レプリケーション開始)
  15. 一定期間経過後、切り戻し不要と判断したら切り戻し用のリソースを削除する(DMS 逆方向レプリケーション停止・旧クラスタ削除)

移行ステップの調整

移行対象システムの規模やメンテナンス停止が許容される時間の長さによって一部のステップを省略・簡略化するか、v2 までの移行に止めます。

ケース 1 : DB アクセスをすべて ORM 経由の単純な CRUD 操作で行っており、SQL 文を直接記述していない場合

変更の影響範囲が予約語やデータ型中心になるので、5. 以前を簡略化しても良いでしょう。

ケース 2 : 移行対象のデータ容量が少ない(数十 GB 程度)か、長時間(1 日以上)のメンテナンス停止が許容される場合

DB のバージョンアップは、v1 → v2 をスナップショット取得からの復元またはインプレースアップグレード、v2 → v3 をスナップショット取得からの復元で行うことになるでしょう。結果として 9. 以降の作業が簡略化されます。

ケース 3 : 移行対象のデータ容量が多いか(数 TB)、短時間のメンテナンス停止しか許容されない場合

DB のバージョンアップには、事前に移行先の v3 のクラスタを立てておくとともに v1 クラスタ → v3 クラスタの DMS レプリケーション(後述)が必要になります。

ケース 4 : Global Database を導入している場合

v2 → v3 のインプレースアップグレードが未サポートのため、クラスタの移行が大掛かりになります。一旦 v2 までの移行に止めるのが良いでしょう。

注意点

主なものを挙げます。

無理な計画を立てない

v1(MySQL 5.6)→ v2(MySQL 5.7)と比べると移行の難易度は高いです。調査の結果アプリケーションの修正点が大量に発見された、性能検証で思うような結果が出なかった等の場合は、無理せず一旦 v2 への移行に止めましょう。

動作検証・性能検証を怠らない

動作検証をせずいきなり v3 へ移行するケースが散見されますが、プロダクト環境の移行は慎重に行いましょう。

また、v3 は v2 以前と内部構造が大きく変わっているので、性能検証も省略しないようにしましょう。

さらに、移行に DMS レプリケーションを併用する場合、DMS レプリケーション(CDC)にはいくつか制約があるので、動作検証の段階で必ず DMS レプリケーションの利用可否の検証も行うようにしましょう(必要があれば DMS レプリケーションの制約に合わせてアプリケーションや設定を変更します)。

必要な材料が揃ってから移行を正式決定する

先に挙げたようなアプリケーションの修正や動作検証を行った上で移行を正式決定しましょう。

また、メンテナンス停止が必要な時間(12. の作業の中でのアプリケーション動作確認やデータの整合確認などに必要な時間)を把握した上で 9. の手順書を作成し、メンテナンス停止日のアナウンスを行いましょう。