概要
RDS の Blue/Green デプロイは、本番（Blue）のレプリカとして別バージョンの環境（Green）を作り、同期させたうえでエンドポイントを切り替える機能。バージョン移行のダウンタイムを短くする目的で使う。
実停止時間は「書き込み停止1秒」ではない
最も重要な実測値がここにある。RDS 側の書き込み停止が1秒でも、アプリから見た停止は24秒になった。差分の原因は DNS 伝播である。
切替時にエンドポイントの向き先が変わるため、アプリケーション側の DNS キャッシュが切れるまで旧インスタンスを見続ける。移行計画のダウンタイム見積りは、RDS が公表する切替時間ではなく DNS TTL とコネクションプールの挙動を含めた実測で立てる必要がある。
| 対象 | 方式 | RDS の書き込み停止 | アプリから見た停止 |
|---|---|---|---|
| stage | in-place | — | 約5分 |
| 20GB / Multi-AZ | Blue/Green | 約1秒 | 18秒（完全停止15秒 + 部分障害3秒） |
| 200GB / db.m6g.2xlarge | Blue/Green | 約1秒 | 24秒（完全停止15秒 + 部分障害9秒） |
切替時にアプリが返すエラーは「接続不能」ではなく 1290 read-only になる。旧インスタンスを見続けたまま書き込もうとするためで、エラーハンドリングと監視のパターンをこれに合わせる。
流入を止めるなら web ではなく job 側
ALB で流入を遮断するのは逆効果だった。 16秒の障害を回避するために4分の全断を作ることになる。止めるべきは web ではなく job / celery のような書き込みワーカー側である。
「復旧」の判定をポーリングだけで行うと停止時間を短く見積もる。ヘルスチェックの余裕の計算式も事前に検証しておく。
Terraform state が壊れる
Blue/Green 切替は Terraform state を壊す。 切替で DbiResourceId が変わるため、state rm + import のやり直しが必須になる。移行手順書にこの工程を明示的に入れておく。
事前に潰しておく前提条件
- MEMCACHED は「8.4 に無い」だけでなく事前アンインストールが必要
- カスタムオプショングループを使っていると、Blue/Green 作成時にメジャーバージョンを指定できない
- クロスバージョンレプリケーション（blue 8.0 → green 8.4）は動く。だから green 側にスキーマ変更を先行適用できない
- Performance Insights の SQL は途中で切られるため EXPLAIN に流せない。切替後の PI 比較は時間帯の交絡で簡単に嘘になる
- リハーサルの provisioning 時間は本番には当てはまらない
Terraform 側の設計 — family 差し替えではなく「併設」
パラメータグループを新バージョン用の family に差し替える形で書くと、Blue/Green の途中状態を表現できない。新旧のパラメータグループを併設しておき、切替後に不要な側を消す設計にする。
切替後は実質ロールバックできない
Green へ切り替えた時点で、旧 Blue へ戻す現実的な経路は失われると考えたほうがよい。切替前の検証と、切替後に発覚した問題を前進で直す準備の両方が要る。
効果が大きかった準備
- 事前に本番同等データで Green を作り、アプリケーションから実際に接続して検証する
- DNS TTL とコネクションプールの再接続挙動を事前に確認する
- 切替のタイムラインを分単位で書き出し、各ステップの判断者を決めておく
公式の事前資料に載っていない落とし穴が複数あるため、リハーサルを1回通すことが最も効く。
Extended Support 課金を避けるための期日管理
標準サポート終了日を超えると Extended Support 課金が始まる。終了日当日に移行を完了させれば課金は $0 に抑えられる（実例では下限見積り約 $1,022/月 を回避）。逆に言えば、この期日が移行スケジュールを規定する。
関連ページ
- Terraform で IaC — インフラ定義側
- AWS Compute Optimizer — 移行後のサイジング見直し
- インシデントレスポンス — 切替失敗時の体制