CDK管理下のRDSをBlue/Greenでメジャーバージョンアップする｜ダウンタイム約10秒で移行した手順

RDS のメジャーバージョンアップは、長時間の停止を覚悟して深夜メンテナンスウィンドウを確保する — というのが、これまでの一般的なイメージだったと思います。

今回、CloudFormation / CDK で管理している RDS を MySQL 8.0 → 8.4 へメジャーバージョンアップする機会があり、AWS の Blue/Green Deployment を使って移行しました。結果として、実測ダウンタイムは約10秒。切替そのものは一瞬で終わりました。

ただし一つだけ厄介な問題があります。Blue/Green は AWS コンソール側の操作であり、CloudFormation の管理外で DB の実体が変わるという点です。CDK でそのまま engineVersion を上げると Blue/Green は使われず、in-place アップグレード（＝長時間停止）が走ってしまいます。

この記事では、CDK 管理下の RDS を壊さずに Blue/Green でメジャーバージョンアップし、そのあと CDK 側を実体に整合させ直すまでの一連の手順をまとめます。

CDK管理下のRDSメジャーバージョンアップの課題

Blue/Green デプロイメントは、稼働中の DB（Blue）とは別に新バージョンのレプリカ（Green）を立て、検証してから一気に切り替える仕組みです。これは AWS コンソールや CLI から直接操作するもので、CloudFormation のテンプレートには一切現れません。

一方で CDK は、あくまで「テンプレートに書かれた状態」を正としてインフラを操作するツールです。ここで単純に CDK の engineVersion プロパティを新バージョンへ書き換えてデプロイすると、CDK は Blue/Green の存在を知らないため、通常の ModifyDBInstance（in-place アップグレード）として処理してしまいます。これは長時間の停止を伴います。

つまり、「Blue/Green でダウンタイムを抑えたい」という要求と、「CDK でインフラを管理し続けたい」という要求は、そのままでは両立しません。Blue/Green は CDK の外で先に実体を変え、CDK はあとからその実体に追従させる、という順序を意図的に設計する必要があります。

対応方針

そこで、次の3段構成で進めることにしました。

CDK で新しい DB バージョン用のパラメータグループだけを先に用意する
CDK は使わず、手動で Blue/Green デプロイメントを実行して切り替える
CDK を「変わってしまった実体」に合わせて整合させる
- 旧バージョンのインスタンスを手動削除する
- CDK で旧バージョンのパラメータグループを削除する

ポイントは、CDK での変更を「準備」と「後片付け」だけに絞り、切替そのものは CDK の外（手動）で行うことです。これにより、Blue/Green の検証ステップを挟みながら、CDK の管理下から一時的に離れる区間を最小限にできます。

手順

Phase 0: 事前確認

まず、切替後にロールバックできるよう 手動スナップショットを取得しておきます。Blue/Green は切替前であれば無停止で撤回できますが、切替後に問題が見つかった場合の保険として、このスナップショットが最後の砦になります。

Phase 1: 【CDK】新しいパラメータグループを追加

パラメータグループには family（対応するエンジンバージョンの系統）があり、メジャーバージョンをまたぐと使い回せません。そのため、既存のパラメータグループは書き換えず、別の論理 ID で新規追加します。

// 既存の 8.0 用はこの時点では残す
new CfnDBParameterGroup(this, "RDSParameterGroup84", {
  family: "mysql8.4",
  parameters: {
    time_zone: "Asia/Tokyo",
    // MySQL 8.4 で native 認証を維持する場合はこれ（後述）
    authentication_policy: "*:mysql_native_password",
  },
});

この時点ではリソースの追加のみなので、稼働中の DB には一切影響しません。cdk diff を実行し、「パラメータグループの追加だけで、DB インスタンス自体には変更がない」ことを確認してからデプロイします。

Phase 2: 【手動】Blue/Green の作成・検証・切替

ここからは AWS コンソールでの手動操作です。対象の RDS インスタンスに対して「アクション → Blue/Green デプロイの作成」を選び、アップグレード先のエンジンバージョンと、Phase 1 で作成したパラメータグループを指定します。

Green（新バージョン側）が available になったら、切替（Switchover）の前に必ず検証します。ここを手厚くできることこそが、Blue/Green を選ぶ最大の理由です。

SELECT VERSION();                            -- 目的のバージョンか
SELECT user, host, plugin FROM mysql.user;   -- 認証プラグインが維持されているか
SHOW DATABASES;                              -- スキーマの欠落がないか

バージョン確認だけでなく、アプリケーション用ユーザーで実際にログインできること、主要テーブルへの SELECT が通ることまで確認します。特に認証プラグイン（mysql_native_password など）は、メジャーバージョンアップで既定の挙動が変わることがあるため要注意です。

すべて問題なければ、Switchover を実行します。切替後は Green 側が本番の DB 識別子とエンドポイントをそのまま引き継ぐため、アプリケーション側の接続設定を変更する必要はありません。旧 Blue のインスタンスは -old1 のようなサフィックス付きの名前へ自動的にリネームされ、しばらくの間は残ります。

Phase 3: 【AWS】後片付け

切替が完了したら、AWS 側で不要になったリソースを片付けます。

Blue/Green デプロイ定義を削除する
旧 Blue インスタンスを削除する
インスタンスが完全に消えるまで待つ

Phase 4: 【CDK】実体に合わせて整合

最後に、CDK のテンプレートを実際のインフラ状態へ追いつかせます。engineVersion を新バージョンに、パラメータグループの参照を新しいものに書き換え、不要になった旧パラメータグループの定義を削除してデプロイします。これで、Blue/Green によって生じていた CloudFormation のドリフトが解消されます。

注意点

1. 旧 Blue を消してから旧パラメータグループを消す

使用中のパラメータグループは削除できません。旧 Blue インスタンスが残ったまま Phase 4 のデプロイを実行すると、8.0 用パラメータグループの削除でエラーになります。Phase 3 → Phase 4 の順序を必ず守ります。

2. cdk diff の "may be replaced" は落ち着いて読む

Phase 4 のデプロイ前に cdk diff を実行すると、次のような出力が出ることがあります。

[~] AWS::RDS::DBInstance RDS may be replaced
 ├─ [~] DBParameterGroupName (may cause replacement)
 └─ [~] EngineVersion  [-] 8.0  [+] 8.4.10

may be replaced という表示だけを見ると、インスタンスが作り直される（＝再度長時間停止する）かのように見えて身構えてしまいますが、これは「条件次第で置換になり得る（Conditional）」という意味であり、実際にはほとんどのケースで ModifyDBInstance として処理され、インスタンスは作り直されません。表示に驚いて作業を止めず、実際の変更種別まで確認することが大切です。

ロールバック

Blue/Green のもう一つの利点は、切替前後でロールバックの重さがまったく違うことです。

タイミング	方法	影響
切替前	Blue/Green デプロイメントを削除するだけ	無影響（Blue は無傷のまま稼働し続ける）
切替後	スナップショット / PITR から復元	長時間停止

切替前であれば、検証で問題が見つかってもワンクリックで撤回でき、本番の Blue には一切影響しません。逆に、切替後に問題が発覚した場合は、Phase 0 で取得したスナップショットや PITR からの復元が必要になり、相応の停止時間を伴います。だからこそ Phase 2 の検証を、切替前にどれだけ丁寧にやれるかが全体の安全性を左右します。

まとめ

Blue/Green は AWS 側の操作で CloudFormation の外に実体を作るため、CDK で engineVersion を上げるだけでは in-place アップグレード（長時間停止）になってしまう
対応は「CDK でパラメータグループだけ先行追加 → 手動で Blue/Green を切替 → CDK を実体に整合」という3段構成にする
切替前の検証（バージョン・認証プラグイン・スキーマ・アプリ接続）を丁寧に行うことが、Blue/Green を選ぶ意味そのもの
後片付けは「旧 Blue インスタンスの削除」→「CDK での旧パラメータグループ削除」の順を守らないと、使用中エラーでデプロイが失敗する
ロールバックは切替前なら無停止、切替後はスナップショット/PITR復元で長時間停止という非対称性がある。判断の重みは切替前に寄せておく

MySQL 8.0 → 8.4 という組み合わせでは、この手順で実測ダウンタイム約10秒に収まりました。エンジンやバージョンの組み合わせによって挙動が変わる可能性はあるため、実施前には必ず検証環境で一度リハーサルすることをおすすめします。

CSエージェントで顧客対応を自動化しませんか？

デモ・無料相談・資料請求を承っています。

デモをみる無料相談する資料請求する