はじめに ─ RDS 延長サポート料金(Extended Support)は高い
ある日、AWS から 「あなたの AWS アカウントには RDS for MySQL 8.0 のインスタンスがあります」という主旨のメールが届きます。要約すると、MySQL 8.0 は 2026 年 4 月にコミュニティ EOL を迎え、RDS としても 2026 年 7 月 31 日で標準サポートが終了する、それ以降は Extended Support に自動で移行されて vCPU 時間単位の追加課金が発生する、というアナウンスです。
このメールで一番やってはいけないのは、「そのうち対応すればいい」と先送りにすることです。延命料(Extended Support)は 通常のインスタンス料金・ストレージ料金とは別枠の純増で、しかも小さな額ではありません。
MOOBON でも、自社で運用する本番 RDS(MySQL 8.0.44)が 3 台該当しました。だからこそ期限に余裕をもって、これらを 8.4 LTS へ上げ切ることにします。
バージョンアップの概要
本記事で実施した内容を、先に概要としてまとめます。詳細は以降の各章で扱います。
| アップデートする バージョン | MySQL 8.0.44 → 8.4.9。本番系は LTS の 8.4 を採用(コミュニティサポートが 2032 年 4 月までと長い。9.x は短サイクルで更新される Innovation Release のため本番には不向き)。8.0.44 からの経路 8.4.3〜8.4.9 のうち、最新マイナーの 8.4.9 を選択。 |
| アップデート方法 | Blue/Green Deployments。AWS マネージドで一時的に論理レプリケーションを張り、アップグレード済みの複製(Green)を用意してから本番を切り替える方式。in-place の major upgrade(数十分の停止)を避けられる。 |
| ダウンタイム | スイッチオーバー時の瞬断のみ(通常 1 分未満)。エンドポイント名は維持されるためアプリ側の接続先変更は不要。完全な無停止ではなく、切替の瞬間に既存コネクションが切れて再接続が走る。 |
Blue/Green Deployments とは
RDS のバージョンアップとして、設定変更で通常どおり DB エンジンバージョンを更新すると、インスタンスを書き換えるために 停止時間が 10 分〜30 分程度かかってしまい、一度変更すると引き返すことができません。
Blue/Green とは、ダウンタイムを最低限(1 分以内)に抑える方式であり、手順は以下の通りです。
| ① 複製 | 現行(Blue)のリードレプリカとして Green を作成。まず同じ 8.0 で複製し、Blue → Green のレプリケーションを張る。 |
| ② 8.4 化 | その Green だけを 8.4.9 へアップグレード。8.4 化した後も Green は Blue(8.0)から追従し続ける(下位→上位のレプリケーション)。 |
| ③ 検証 | 本番に影響を与えずに Green を検証(バージョン・認証・レプリ遅延・代表クエリ)。 |
| ④ 切替 | レプリが追いついた状態で スイッチオーバー。Green が本番に昇格し、エンドポイント名は維持される(アプリの接続先変更は不要)。 |
そもそも Blue/Green は、ソフトウェアのリリース技法(Continuous Delivery の文脈で 2010 年前後に普及)が由来です。Blue / Green という色自体は、どちらが本命かを示さない中立的なラベルとして選ばれたもの。そして「Blue = 現行(本番)、Green = 新しく用意する環境」という割り当ては技術的な必然ではなく「慣習」で、多くのツールがこう割り当て、AWS RDS もこの定義を採用しています。
事前準備 ─ binlog_format・8.4 用パラメータグループ・認証
① binlog_format を ROW に
Blue/Green はレプリケーション前提のため、binlog_format = ROW が必須です。RDS のエンジンデフォルトは MIXED なので、カスタム DB パラメータグループで ROW に明示設定します。この変更は動的パラメータなので、RDS インスタンスは再起動しませんのでご安心ください。
aws rds modify-db-parameter-group \
--db-parameter-group-name <your-pg> \
--parameters "ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=immediate"
# 反映後、各インスタンスで実効値を確認
# SHOW VARIABLES LIKE 'binlog_format'; -> ROW② バージョンアップ用(8.4)のパラメータグループを用意
Green(セカンダリ)は 8.4 family のパラメータグループを使うので、新規に作成して binlog_format=ROW を入れておきます。Blue/Green 作成時に --target-db-parameter-group-name で指定します。
③ 認証(mysql_native_password)は触らなくてよい
「8.4 で mysql_native_password が無効になる」という話を警戒していましたが、RDS for MySQL 8.4 のパラメータグループでは mysql_native_password が ON 固定(変更不可)であることを実環境で確認しました。素の MySQL 8.4 は OFF 既定ですが、RDS は互換性のため ON にしています。
mysql_native_password=ON に固定されていました。そのため、これまで mysql_native 認証で作成された DB ユーザーは、バージョンアップ(8.4)後もそのまま接続できました。④ 保護スナップショットを取る
なにか問題が発生したときのために、念のため切替作業前に手動スナップショットを取得しておきます。
本作業 ─ Blue/Green の作成と Green の検証
事前準備が済んだら、Blue/Green デプロイを作成して Green(セカンダリ)を構築し、本番に影響を与えないまま検証します。
① Blue/Green デプロイを作成する
ソース(Blue)の ARN、ターゲットのエンジンバージョン(8.4.9)、8.4 用パラメータグループを指定して作成します。
aws rds create-blue-green-deployment \
--blue-green-deployment-name <name>-84-bg \
--source <source-db-arn> \
--target-engine-version 8.4.9 \
--target-db-parameter-group-name <8.4-parameter-group>
作成リクエストを投げると、上図のような構成が作られます。
- 枠(一番上)：指定した Blue/Green デプロイの名前
- Blue：元々使っていた現行の RDS(本番)
- Green：レプリケーションのセカンダリとして起動する、新しいインスタンス
- Green のレプリケーションが完了するのを待ちます。
- Green のバージョンをアップグレードします(アクセスは Blue に向いているので、本番への影響はありません)。
- Green のバックアップが設定され、デプロイ全体のステータスが「利用可能(AVAILABLE)」になります。
レプリケーションの確立とアップグレードを含むため、移行の工程の中で最も時間がかかる箇所です(全体で 20〜40 分程度)。作成中はステータスが「プロビジョニング中」になります。
② Green を検証する(本番に影響なし)
Green が 8.4.9 になって「利用可能」状態になったら、Green のエンドポイントに直接つないで中身を確認します。まだ本番は Blue 側で動いているので、もし問題が見つかっても落ち着いて対処できます。確認したのは次の点です。
SELECT VERSION();が 8.4.9、binlog_formatがROW- 既存ユーザーが native 認証のまま接続できる(8.4 でも RDS は維持。事前準備③参照)
- 全テーブルが InnoDB(MyISAM が残っていないか)
- レプリケーション遅延ゼロ(
SHOW REPLICA STATUSのSeconds_Behind_Source = 0、IO/SQL スレッドが Yes) - 主要テーブルの件数が Blue と一致している
スイッチオーバー(セカンダリ→プライマリへ昇格)
Green が 8.4.9 で「利用可能」になり、検証(バージョン・認証・全テーブル InnoDB・レプリ遅延ゼロ・件数一致)が取れたら、スイッチオーバーを実行します。--switchover-timeout でレプリ追従の待ち時間を指定しておくと安全です。
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier <bgd-id> \
--switchover-timeout 300
# Status: SWITCHOVER_IN_PROGRESS -> SWITCHOVER_COMPLETED切替後は、エンドポイントが新本番(8.4.9)を指します。確認したのは次の点です。
SELECT VERSION();が 8.4.9、エンドポイント名が維持されていること- 各アプリが 新DBに接続して応答すること(ログイン・主要画面・代表的な書き込み)
- スロークエリログ・エラーログに新規異常がないこと。8.4 はオプティマイザの挙動が一部変わるため、重い一覧・検索系のプラン悪化に注意
移行で見落としやすい 3 つのポイント
ここまでが移行の流れです。最後に、Blue/Green で上げる際に 見落としやすいポイントを 3 つだけ補足します。いずれも事前に気づいて対処しておけば問題になりません。
ALTER TABLE ... ENGINE=InnoDB で変換しておきます(WordPress は公式にも InnoDB 推奨)。<元の名前>-old1)を消すとき、削除保護が ON だとそのまま削除できません。--no-deletion-protection で解除してから削除します。RDS 延長サポート(Extended Support)料金について再考
バージョンアップしないまま放置すると、Extended Support の追加課金が 「vCPU 時間単位」で乗ります。アジアパシフィック(東京)では Year 1・Year 2 が $0.12 / vCPU・時、Year 3 から $0.24 / vCPU・時(3 年目で倍)。インスタンスタイプは micro 〜 large まで 2 vCPU なので、micro インスタンス 1 台でも、月間 ¥28,000 の延長サポート料金が追加されます。Multi-AZ のスタンバイ機やリードレプリカでも課金対象になるため、さらに倍々になる可能性もあります。
以下は、インスタンスタイプごとの本体の利用料金と、延長サポート料金です。
| インスタンスクラス | vCPU | 本体(時 / 月) | 延長サポート(時 / 月) | 比率 |
|---|---|---|---|---|
| db.t3.micro | 2 | $0.025 (≈¥4) /時 ≈ ¥2,900 /月 | $0.24 (≈¥38) /時 ≈ ¥28,000 /月 | 約 9.6 倍 |
| db.t3.small | 2 | $0.05 (≈¥8) /時 ≈ ¥5,800 /月 | $0.24 (≈¥38) /時 ≈ ¥28,000 /月 | 約 4.8 倍 |
| db.t3.medium | 2 | $0.10 (≈¥16) /時 ≈ ¥11,700 /月 | $0.24 (≈¥38) /時 ≈ ¥28,000 /月 | 約 2.4 倍 |
| db.t3.large | 2 | $0.20 (≈¥32) /時 ≈ ¥23,400 /月 | $0.24 (≈¥38) /時 ≈ ¥28,000 /月 | 約 1.2 倍 |
※ 1 ドル 160 円で計算しています。
今回 8.4 へ上げたのは、弊社で運用する 3 台の RDS でした。冗長化(Multi-AZ)構成でもなかったのですが、それでも 単純に 3 台ぶんの延長サポート料金だけで、月 +84,000 円(3 年放置なら約 400 万円)の追加料金になってしまいます。
「なにもしていないのに」です。── いや、なにもしていないからこそ、かかってしまう料金なのです。
こんなことで月 84,000 円もの無駄な出費が出ると思うと、正直、悔しくて眠れません。
標準サポート期間内に 8.4 LTS へ上げ切れば、この追加課金はゼロ。Blue/Green の移行作業自体は、Green インスタンスが一時的に増える分のコスト(移行中の数十分〜数時間)で済みます。延命料と比べれば桁違いに小さい投資です。
※ 単価はリージョン・改定により変動します(上表はアジアパシフィック(東京)のプロビジョンドインスタンス単価ベース)。最新値は RDS for MySQL 料金ページ(延長サポート) でご確認ください。
あとがき
Blue/Green Deployments は、素朴な構成でも本番に近いダウンタイムでメジャーアップグレードを通せる、よくできた仕組みです。ただ本記事で一番お伝えしたいのは移行手順ではなく、RDS の延長サポート料金は割高で、しかも見落とされがちという点です。標準サポートの期限(7/31)までに 8.4 へ上げ切れば、この追加課金はゼロにできます。「いつかやる」で先送りにせず、早めに片付けておくことをおすすめします。
ちなみに、RDS for MySQL 8.4 が利用できるようになったのは 2024 年 11 月 21 日です。それ以前に作られたサービスは 8.0 のまま動いている可能性が高く、今回の標準サポート終了の対象になりやすいので注意が必要です。
特に micro のような小さいインスタンスで、AWS 費用が月 1〜2 万円ほどしかかかっていないようなケースほど、油断してメンテナンスを見落としがちです。延長サポートは本体料金の何倍も乗るので、気づかないうちに請求が 2 倍以上に増えていて、数か月経ってから気づく、ということも十分に起こり得ます。
無駄な料金は払わずに済むに越したことはありません。心当たりのある方は早めに確認を、そして周りで RDS を使っている方にも、ぜひ声をかけて注意喚起していただければと思います。日本のデジタル赤字を少しでも軽減するためにも、こうした費用はしっかり管理していきましょう。
MOOBON では、こうした AWS の保守・移行・コスト最適化を運用の一部としてお引き受けしています。「EOL 通知は来たが、自社の構成で何に気をつければいいか分からない」「停止時間を最小化して上げたい」といった場面で、本記事のような事前の棚卸しから切替・確認まで伴走します。お気軽にご相談ください。
よくある質問
QBlue/Green Deployments を使えば、本当に「無停止」でメジャーバージョンアップできますか?
厳密には「無停止」ではなく、スイッチオーバーの瞬間に既存コネクションが切断されるため、数秒〜十数秒の「切断と再接続」が発生します。AWS のドキュメントでは通常 1 分未満と案内されており、適切に準備すれば 1 リクエスト分が失敗する程度の影響に収まることが多いです。アプリ側のコネクションプールがリトライに対応していれば、エンドユーザーにはほぼ気付かれずに切替を完了できる場合もあります。所要時間は負荷や状態で変動するため、本番に近い環境で実測しておくことを推奨します。
QMySQL 8.4 と 9.x、どちらに上げるべきですか?
本番運用なら 8.4 LTS(Long Term Support)を推奨します。8.4 は MySQL として初の LTS シリーズで、コミュニティのサポート期間が 2032 年 4 月までと長く、RDS for MySQL の運用ライフサイクルもこれに準拠して長期化が見込まれます。一方の 9.x は Innovation Release で短サイクルでメジャーが更新される設計のため、本番でメンテナンス頻度を上げたくない運用には不向きです。新機能を検証したい開発環境では 9.x、本番系は 8.4 LTS で揃える、という棲み分けが現実的です。
QBlue/Green Deployments を有効化する条件は何ですか?
RDS for MySQL の場合、最低限の条件は (1) backup_retention_period が 1 日以上(自動バックアップ有効)、(2) binlog_format = ROW、(3) サポート対象のエンジンバージョン、の 3 つです。binlog_format はカスタム DB パラメータグループで ROW に明示設定する必要があり、エンジンデフォルトの MIXED のままだと Blue/Green の作成リクエストが拒否されます。加えて、メジャーバージョンアップの Blue/Green では、ソースインスタンスが『デフォルトのオプショングループ』を使っている必要があります(本文のポイント②参照)。
QMySQL 8.4 では mysql_native_password が無効になると聞きました。アプリの改修は必要ですか?
素の MySQL 8.4 では mysql_native_password がデフォルト無効ですが、RDS for MySQL 8.4 のパラメータグループでは mysql_native_password が ON 固定(変更不可)になっていることを実環境で確認しました。そのため、native 認証で作成された DB ユーザーは 8.4 化後もそのまま接続でき、アプリ側の改修は不要でした。AWS の事前互換性チェック(PrePatchCompatibility)が出す『mysql_native_password は deprecated』という警告は上流 MySQL 向けの一般案内で、RDS では loose_mysql_native_password=ON を別途設定する必要も手段もありません。なお caching_sha2_password への移行は、将来 native プラグインが削除されるメジャーバージョンへ上げる際に改めて検討すればよい、という整理にしています。
QDB 側を無停止にしても、アプリ側でエラーが出ることはありますか?
起こり得ます。Blue/Green は DB のエンジンバージョン切替を無停止に近い形で行う機能で、アプリのクライアントライブラリやクエリ・スキーマの互換性までは面倒を見ません。スイッチオーバー前に、対象 DB へ接続している経路を洗い出し、各アプリの MySQL クライアントライブラリのバージョンを確認しておくことを推奨します。特に 8.4 はオプティマイザの挙動が一部変わるため、重い一覧・検索・レポート系のクエリは切替後にプラン悪化が出ていないか、スロークエリログで確認しておくと安心です。
Qスイッチオーバー後に問題が見つかったら、元に戻せますか?
スイッチオーバー直後であれば、旧 Blue 環境が <元の名前>-old1 として残るため、当面はこれを保持しておくことで保険になります。ただし切替後に新 Blue(旧 Green)側で更新された書き込みは旧 Blue には反映されないため、時間が経つほど切り戻しは現実的でなくなります。動作確認が取れたら、旧 Blue と Blue/Green デプロイを削除して二重課金を止める、という流れにしています。切替直前に取得した保護スナップショットは、より深い復元ポイントとして残しておきます。
