RDSのブルー/グリーンデプロイメント、便利だけど気をつけたい2つのこと

はじめに

システムの可用性と信頼性が求められる現代のアプリケーション運用において、「ブルー/グリーンデプロイメント（以降ブルー/グリーンデプロイ）」は、ダウンタイムを最小限に抑えつつ安全にリリースを行うための有効な手法です。

AWSでは、Amazon RDS（Relational Database Service）においてもこのブルー/グリーンデプロイがサポートされており、とくに本番環境のデータベースアップグレードやパッチ適用時に活用されています。

しかし、実際に運用してみると「理論通りにはいかない」ことも多く、とくに以下の2点は見落とされがちな落とし穴です。

トラフィックが少ない時間帯でないと切り替えが難しい
一度切り替えると、基本的に切り戻しができない

この記事では、AWS RDSのブルー/グリーンデプロイの仕組みを解説しつつ、実際の運用で直面する課題とその対策について深掘りします。

RDSのブルー/グリーンデプロイとは？

AWSが提供するRDSのブルー/グリーンデプロイは、本番環境（Blue環境）と同一構成のクローン環境（Green環境）を作成し、切り替え操作によって新環境へトラフィックを移行するという仕組みです。

主な特徴

自動でクローン作成：Blue環境のスナップショットからGreen環境を作成します。
スキーマ変更やバージョンアップが可能：Green環境で事前に変更を適用できます。
切り替えは数クリックで完了：AWSコンソールまたはCLIで実行可能です。
切り替え時にDNSが更新される：アプリケーション側の接続先は変わりません。この仕組みにより、本番環境に影響を与えずにアップグレードや変更を検証できるという大きなメリットがあります。

実運用での注意点

トラフィックが少ない時間でないと切り替えが難しい理由

AWS RDSのブルー/グリーンデプロイは、一見すると「無停止で切り替えられる」ように見えますが、実際には数秒〜十数秒の接続断が発生する可能性があります。これは、切り替え時に内部で複数の重要な処理が行われるためです。

以下は、RDSブルー/グリーンデプロイの切り替え時にAWSが実行するアクションの概要です。

事前チェック（ガードレール）：切り替え前に、両環境が正常かどうかを自動でチェックします（レプリケーションの状態、書き込みの有無など）。
書き込みの停止：両方の環境で、新たな書き込み操作を一時的に停止します。
接続の遮断：両方の環境で、既存のDB接続を切断し、新しい接続も一時的に受け付けなくなります。
レプリケーションの同期待ち：Green環境がBlue環境と完全に同期するまで待機します。
DBインスタンス名の入れ替え：Green環境のDBインスタンスが、Blue環境の名前（例：mydb）を引き継ぎます。Blue環境のDBインスタンスはmydb-old1のようにリネームされます。
エンドポイント名の更新：Green環境のエンドポイント名も、Blue環境のものと同じに変更されるため、アプリケーション側の接続先は変更不要です。
接続の再開：両方の環境で、DBへの接続が再び許可されます。
新しい本番環境での書き込み再開：Green環境（新しい本番）での書き込みが許可されます。
旧環境は読み取り専用に：Blue環境（旧本番）は、再起動されるまで読み取り専用モードになります。

この一連の流れにより、アプリケーション側の設定変更なしに、安全に環境を切り替えることが可能になります。

AWSが提供する切り替え操作により、エンドポイントの向き先をBlueからGreenへ変更することでアプリケーション側の接続先は変えずに、裏側で環境を切り替えることができるのがRDSブルー/グリーンデプロイの大きな利点です。

ただし、切り替え中は一時的に接続が遮断される可能性があるため、トラフィックが少ない時間帯での実施が推奨されます。

切り替えタイムアウトの仕組み

AWSでは、切り替え操作に対して「切り替えタイムアウト」を設定できます。

設定可能な範囲：30秒〜3600秒（最大1時間）
デフォルト値：300秒（5分）
タイムアウトの挙動：指定時間内に切り替えが完了しない場合、すべての変更はロールバックされ、Blue/Green両環境には影響が残りません。

このタイムアウトは、以下のような状況に備えるための安全装置です。

Green環境のレプリケーションが追いつかない
ガードレールチェックに失敗する
内部処理が想定より長引く

切り戻しができないという現実

RDSのブルー/グリーンデプロイでは、一度Green環境に切り替えるとブルー/グリーンデプロイ機能を利用して元のBlue環境に切り戻すことはできません。

つまり、「やっぱり元に戻したい」という場合は手動で復旧する必要があります。
この仕様により、以下のようなリスクが生じます。

Green環境に想定外の不具合があった場合、即座に元に戻すことができない
アプリケーションの接続先を旧Blue環境に戻すなど、時間とコストがかかる
切り替え後にデータが書き込まれてしまうと、ロールバックはさらに困難そのため、切り替え前の段階で徹底的な検証とリハーサルが不可欠です。また、切り替え直前にスナップショットを取得しておくことで、最悪の事態に備えることができます。

安全なブルー/グリーンデプロイのためのベストプラクティス

RDSのブルー/グリーンデプロイは非常に便利な機能ですが、前述のように「切り戻しができない」「切り替え時に接続断がある」といった制約があります。
これらのリスクを最小限に抑えるために、以下の対策を実践することを強くおすすめします。

推奨アプローチ

ステージング環境での徹底検証：Green環境はBlueのクローンですが、デフォルトでは読み取り専用（書き込み不可）です。スキーマ変更の影響は事前にBlue環境で十分に検証を実施し、問題がないことを確認しましょう。
切り替え直前のスナップショット取得：切り替え前にBlue環境のスナップショットを取得しておくことで、万が一の際に復旧が可能になります。ただし、スナップショットからの復元には時間がかかるため、即時の切り戻しはできない点に注意が必要です。
切り替えタイムアウトの適切な設定：切り替えを開始する前に、グリーン環境のReplicaLag（ブルー環境とのデータ同期の遅延）を把握したうえで切り替え時間の見込みを立てておき、必要に応じて調整します。また、併せて具体的なワークロードにおけるダウンタイムの見積もりを把握しておくことも重要です。
アプリケーション側のリトライ設計：切り替え時に一時的な接続断が発生するため、アプリケーション側でDB接続のリトライ処理が実装されていない場合は再接続させる方法を検討しておく必要がありあます。とくに、トランザクションの再試行やコネクションプールの再初期化が重要です。
切り替え後のモニタリングとアラート設定：Green環境に切り替えた後は、CloudWatchなどでDBのパフォーマンスを監視しましょう。異常があれば即座に検知できるよう、アラートルールを事前に設定しておくことが重要です。
切り替えタイミングの調整：切り替えはトラフィックが少ない時間帯に行うのが理想です。可能であれば、ユーザーに事前告知を行い、影響を最小限に抑えましょう。