Zenn
📖

未経験が本番DBのアップデートを行った話

2024/12/23に公開
AWS
DB
RDS
aurora
記事投稿コンテスト「今年の最も大きなチャレンジ」
tech

【AWS Aurora MySQL 5.7 → 8.0 アップデート手順書】

新卒入社から2年目のバックエンドエンジニアが任された案件で、AWS Aurora MySQL 5.7 のサポート切れによるコスト増を解消するために、MySQL 8.0 へアップデートします。
また、インスタンスクラスを db.t3.small から t4g.medium へ変更し、サポート料金を削減する狙いがあります。

1. 今回の課題概要

  • Aurora MySQL 5.7 サポート終了 → 追加費用発生
    • 2024年11月から、サポート料金が月々 $173 (約 26,556円) 発生。
  • 証明書の期限切れ
    • 期限が迫っているため、証明書の更新も必要。
  • インスタンスクラス変更
    • 現状 db.t3.small。
    • 新たに db.t4g.medium に変更することで、サポート料金を削減。

2. 対応方針

  • Aurora MySQL のバージョンアップ（5.7 → 8.0）
  • インスタンスクラスを変更
    • db.t3.small → db.t4g.medium
  • Laravel 側のバージョンやドライバ互換性を確認
    • Laravel 9 の場合は、MySQL 8.0 に対応可能。
  • ダウンタイム見込み
    • 5日間程度を上限として想定（実際は短縮の可能性あり）。

3. アップデート手法の検討

インプレース方式

  • 特徴: ダウンタイムが長いが、手順はシンプル。
  • 切り戻し: スナップショットを使って復元。
  • DB エンドポイント: 同じ。

ダンプ＆リストア方式

  • 特徴: ダウンタイムは普通、手順もそれなり。
  • 切り戻し: 旧環境へ切り戻す。
  • DB エンドポイント: 別になる。

レプリケーション方式

  • 特徴: ダウンタイムは短いが、手順は複雑。
  • 切り戻し: 旧環境へ戻す。
  • DB エンドポイント: 別になる。

4. 全体フロー

以下では、インプレース方式＋クローンを使用した切り戻し準備を想定しています。

  1. （事前連絡）サービス停止の告知
  2. Aurora MySQL バージョン確認
  3. Laravel バージョン確認
  4. RDS スナップショット取得
  5. クラスタークローン作成（切り戻し用）
  6. インスタンスタイプ変更（t3.small → t4g.medium）
  7. Fargate（本番・Stage）停止
  8. Aurora MySQL を 5.7 → 8.0 にアップデート
  9. Stage 環境のみ起動してテスト
  10. テスト完了後、本番を起動
  11. クローン RDB の削除

切り戻しが必要な場合は、作成済みのスナップショットかクラスタークローンを活用。

5. 詳細手順

0. 事前連絡（サービス停止告知）

  • 5日程度の停止を想定し、ユーザーや社内に通知。

1. Aurora MySQL のバージョン確認

  1. AWS マネジメントコンソール → RDS → 対象データベース
  2. 現在のエンジンバージョン を確認
    • 例: 5.7.mysql_aurora.2.11.5

2. Laravel バージョン確認

  1. SSH などでサーバーに接続
  2. php artisan --version または composer.json を確認
    • Laravel 9 系なら MySQL 8 との互換性があるか要チェック。

3. RDS スナップショット取得

  1. RDS → Snapshots → Take Snapshot
  2. 対象クラスターを選択し、スナップショット名を付与
  3. 障害時の切り戻し用に確保。

4. クラスタークローン作成（切り戻し用）

AWS ドキュメント:
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html

  1. RDS → データベース → クラスターを選択
  2. アクション → クローンの作成
  3. 設定（インスタンス識別子や容量など）を入力
  4. クローンの作成 を実行
  5. クローン作成後、使用可能になっているか確認。

5. インスタンスタイプ変更（db.t3.small → db.t4g.medium）

  1. RDS → データベース → 対象インスタンスを選択
  2. Modify（変更） → インスタンスクラスを db.t4g.medium に変更
  3. 必要なオプションを確認
  4. Immediately apply（すぐ適用） を選択（必要に応じて）
  5. Modify DB instance を押下し、保存。

6. Fargate（本番・Stage）の停止

  1. ECS → 対象サービス → サービスの更新
  2. タスク数を 0 にして更新。
  3. アプリケーション側のアクセスが止まる。

7. Aurora MySQL を 5.7 → 8.0 にアップデート

参考: https://qiita.com/leomaro7/items/68251f78d5cfd9f0f10b

  1. RDS → データベース → 変更
  2. DBエンジンバージョン を 5.7 から 8.0 に変更
  3. 続行 → 適用

8. Stage のみ再起動・テスト

  1. ECS → Stage サービス → サービスの更新
  2. タスク数を 1 に変更して更新
  3. テスト環境のみ起動し、動作確認を実施。

9. テスト（2～4日想定）

  • API 単体テスト
  • E2E テスト
  • フロント/バックエンド疎通テスト
  • 問題があれば修正。

10. 本番再起動

  1. ECS → 本番サービス → サービスの更新
  2. タスク数を 1 にして更新
  3. 正常稼働を確認。

11. クローン RDB の削除

  • 不要になったクローンインスタンスを削除し、リソースを解放。

6. 切り戻し方針

切り戻し条件

  • 重大な不具合（APIレベルの修正では対応できない）
  • システム主要機能が停止し、緊急対応が数日内に終わらない場合

切り戻し手順

1. スナップショットからの復元

  1. RDS → Snapshots → スナップショットを復元
  2. DBエンジンバージョンを 5.7 に指定
  3. 新たな DBインスタンス識別子 で復元
  4. Laravel 側の DB_HOST などを変更 → 再デプロイ。

2. クラスタークローンを利用

  1. 事前に作成したクローンインスタンスのエンドポイントを取得
  2. Systems Manager Parameter Store (.env) の DB_HOST をクローンエンドポイントに変更
  3. Fargate の再デプロイで接続先を切り替え。

7. コスト面

  • 現状 (db.t3.small)
    • DB: 約 $48 / 月（7,400円）
    • サポート料金: $173 / 月（26,556円）
  • 移行後 (t4g.medium)
    • DB: 約 $84 / 月（14,000円）
    • サポート料金は発生しない見込み

サポート料金を削減するために、早めの t4g.medium 移行が望ましいです。

8. まとめ

  • Aurora MySQL 5.7 のサポート終了による追加コストを抑えるため、MySQL 8.0 へのアップデートを実施。
  • 併せてインスタンスタイプを t4g.medium に変更し、サポート料金をゼロ化。
  • バージョンアップ後のテストや障害対応を見据えて、スナップショット取得 と クラスタークローン を使った切り戻しを準備。
  • ダウンタイムの予定・リスクを考慮し、慎重に計画的に進めることが重要。

新卒2年目のバックエンドエンジニアとして、初めての大規模アップデート作業になりましたが、
上記の手順と切り戻し方法をしっかり押さえれば、無事に移行が可能です。
ぜひ参考にしてください。

メールの確認きちんとすることって大切ですね。。。
もっと早くこの対応行っていればこんなに焦らないで済んだのに。。。。

Discussion