ブルーグリーンデプロイメントは、冗長環境を使用して、ダウンタイムを最小限に抑えながらサービスをアップグレードするリリース戦略です。この戦略では、既存の本番環境 (ブルー環境) のクローンである同期済みのテスト環境 (グリーン環境) を作成し、テストとカナリア分析を行います。仮想 IP (VIP) をリアルサーバー (RS) に再マッピングすることで、本番環境とテスト環境の間でトラフィックを迅速に切り替えることができます。このアプローチではアプリケーション側の変更が不要で、サービスの中断を最小限に抑え、迅速なロールバックを可能にします。
ブルーグリーンデプロイメント機能は、現在ホワイトリストに登録されているユーザーのみが利用できます。この機能を使用するには、チケットを送信してください。
概要
概要
ブルーグリーンデプロイメントでは、サービスの旧バージョンと新バージョンに対応する、ブルー環境とグリーン環境という 2 つの同一環境を作成します。ブルー環境は本番トラフィックを処理し、グリーン環境はアップグレード前のテストに使用します。双方向の Data Transmission Service (DTS) リンクにより、グリーン環境はブルー環境と同期されます。ブルーグリーンデプロイメントでは、グリーンインスタンスはブルーインスタンスと同じ仕様になります。
ブルー環境：現在本番トラフィックを処理し、読み取りと書き込みの両方を実行できる本番環境です。
グリーン環境：読み取り専用のテスト環境です。
このアプローチにより、潜在的な欠陥を迅速に特定し、データベースのパフォーマンスを最適化し、更新されたデータベース機能を、最小限の、制御可能なダウンタイムで導入できます。
また、ブルーグリーンデプロイメントでは、問題が発生した場合に前のバージョンに迅速に戻すことができます。これにより、システムアップグレードの信頼性と柔軟性が向上し、リスクとビジネスへの影響を低減します。
ユースケース
ブルーグリーンデプロイメントの代表的なユースケースは、データベースのメジャーエンジンバージョンまたはマイナーエンジンバージョンのアップグレードです。アップグレードの手順は次のとおりです：
新バージョンのデプロイ：
グリーン環境を作成し、新しいデータベースバージョンを選択します。グリーン環境はテスト環境として機能し、本番トラフィックは処理しません。
グリーン環境で包括的な機能テストとパフォーマンステストを実施し、新バージョンの安定性を確保します。
ブルー環境とグリーン環境の切り替え：
新バージョンの検証後、ブルー環境からグリーン環境に切り替えます。
切り替え中および切り替え後も、ブルー環境のインスタンス ID とエンドポイントは変更されないため、手順を簡素化できます。
監視とロールバック：
新バージョンの公開後に重大な問題が発生した場合は、直ちに旧バージョンに切り替えることができます。
ロールバックは高速で、障害からの復旧時間を大幅に短縮できます。
問題の修正と再デプロイ：
新バージョンの問題を修正した後、グリーン環境に再デプロイして、再度検証します。
検証に成功したら、再度ブルー環境からグリーン環境に切り替えます。
メリット
ゼロダウンタイムリリース：アップグレードはトラフィックの切り替えによって実施します。本番環境のインスタンス ID とエンドポイントは変更されないため、アプリケーションを変更せずに接続を維持できます。
迅速なロールバック：新バージョンで問題が発生した場合、再デプロイや修正を行わずに旧バージョンに切り替えるだけで戻せます。
リソース分離：新旧バージョンは分離された別環境で稼働するため、相互干渉を防止できます。
高可用性：冗長デプロイにより、トラフィック切り替え中でもリクエストを処理するための十分なリソースを確保できます。
前提条件
ブルーグリーンデプロイメントを作成する場合、本番環境として機能するブルーインスタンスは次の要件を満たしている必要があります：
インスタンスが High-availability Edition であり、読み取り専用インスタンスまたは分析インスタンスがないこと。
インスタンスのストレージタイプが Premium Local SSD、高性能 ESSD、または ESSD であること。
インスタンスで次の機能が有効化されていないこと：データベースプロキシ、SSL encryption、disk encryption、列レベルの暗号化、storage compression、バッファープール拡張 (BPE)、I/O パフォーマンスバースト、または data archiving。
課金
ブルーインスタンス：ブルーグリーンデプロイメントを作成すると、既存のインスタンスがブルーインスタンス (本番環境インスタンス) として指定されます。このインスタンスは通常どおり課金されます。
グリーンインスタンス：ブルーグリーンデプロイメントを作成すると、新しいグリーンインスタンスが作成されます。このインスタンスは 従量課金 で課金されます。課金ルールは、通常の従量課金 RDS インスタンスと同じです。
2025 年 8 月 1 日から、ブルーグリーンデプロイメントを通じて作成されたグリーンインスタンスは、作成から 15 日間無料です。15 日経過後は従量課金で課金されます。このプロモーションの終了日は未定で、別途お知らせします。
グリーンインスタンスの課金方法をサブスクリプションに変更できます。ただし、15 日間の無料トライアルは、インスタンスが従量課金で課金される場合にのみ適用されます。課金方法をサブスクリプションに変更すると、変更直後からサブスクリプションのルールに基づいて課金されます。
制限事項
ブルーグリーンデプロイメントの作成後、ブルーインスタンスまたはグリーンインスタンスでは次の操作は サポートされません：
構成変更の制限：インスタンス仕様、ストレージ容量、ストレージタイプ、またはゾーンは変更できません。
機能使用の制限：
サポートされないデータ暗号化機能： SSL encryption、disk encryption、列レベルの暗号化、および 透過的データ暗号化 (TDE)。
サポートされない高性能 ESSD の機能：バッファープール拡張 (BPE)、I/O パフォーマンスバースト、および data archiving。
サポートされない機能：Global Active Database。
データベース操作の制限：データベースの作成または削除、およびデータベースのメジャーエンジンバージョンまたはマイナーエンジンバージョンのアップグレードはできません。
パブリックエンドポイントの制限：パブリックエンドポイントの申請または解放はできません。
ブルーグリーンデプロイメントの作成後に DTS リンクを削除 すると、ブルー環境とグリーン環境の間で切り替えができなくなります。この場合、まずブルーグリーンデプロイメントを削除し、その後で新しいブルーグリーンデプロイメントを作成する必要があります。
ブルーインスタンスの binlog が、DTS や Flink などのダウンストリームシステムで使用されている場合は、ブルーグリーンデプロイメントの使用を推奨しません。これは、ブルーインスタンスとグリーンインスタンスの GTID セットが一致せず、ダウンストリームの binlog 同期が中断される可能性があるためです。
データ同期中の DDL 操作の制限：データ同期中は、DDL 操作 (テーブルの作成、変更、削除、またはインデックスの作成、削除など) を実行しないでください。たとえば、メジャーバージョンをまたいでアップグレードする場合、DDL ステートメントは、文字セット、照合順序、構文などの非互換性により同期エラーを引き起こす可能性があります。結果として生じるデータ差分は、使用前に手動で確認してください。
ブルーグリーンデプロイメントを使用して メジャーエンジンバージョンをアップグレード する場合、現在サポートされているアップグレードパスは次のとおりです：
MySQL 5.6 から MySQL 5.7。
MySQL 5.6 から MySQL 8.0。
MySQL 5.7 から MySQL 8.0。
ブルーグリーンデプロイメントの作成
ブルーグリーンデプロイメントを作成する場合、ブルー環境の中核として機能するソースデータベースインスタンスを指定する必要があります。
RDS Instances ページに移動し、リージョンを選択して、対象インスタンスの ID をクリックします。このインスタンスが、ブルーグリーンデプロイメントのブルーインスタンスになります。
左側メニューで ブルーグリーンデプロイメント を選択し、左上隅の ブルーグリーンデプロイメントの作成 をクリックします。
グリーンインスタンス (テスト環境) の メジャーバージョン を選択します。
Authorize をクリックし、決定 をクリックして、サービスリンクロール (SLR) の承認を完了します。
グリーンインスタンスの マイナーエンジンバージョン を選択し、作成 をクリックします。
ブルーグリーンデプロイメント設定の確認 ダイアログボックスで、決定 をクリックします。
ブルーグリーンデプロイメントの切り替え
切り替え中、Premium Local SSD を使用するインスタンスでは 1 回、高性能 ESSD を使用するインスタンスでは 2 回の瞬断が発生します。この操作はオフピーク時間帯に実行し、アプリケーションに再接続メカニズムがあることを確認してください。
切り替え条件の確認：ブルーグリーンデプロイメントを切り替える前に、ブルーインスタンスとグリーンインスタンスの両方が次の要件を満たしている必要があります：
インスタンスが実行中状態であること。
読み取り専用インスタンスが存在しないこと。
データベースプロキシ機能が有効化されていないこと。
両インスタンスのデータベース数とデータベース名が同一であること。
両インスタンスのデータベースアカウント数とアカウント名が同一であること。
DTS 同期レイテンシが 5 秒未満であること。
ブルーグリーンデプロイメントの切り替え：
RDS Instances ページに移動し、リージョンを選択して、ブルーインスタンスの ID をクリックします。
左側メニューで ブルーグリーンデプロイメント を選択し、切り替え セクションで ブルーグリーンの同期情報 をクリックします。
情報を確認し、切り替え時間 を設定して、決定 をクリックします。システムが、ブルーインスタンスとグリーンインスタンスの状態と構成を確認します。
切り替え条件を満たしていない場合は、[チェック結果] に基づいて問題を解決し、切り替え操作を再度実行します。
切り替え条件を満たしている場合、インスタンスのステータスが [Blue-green Deployment Switching] に変わります。切り替えが完了すると、インスタンスのステータスは [実行中] に変わります。
ブルーグリーンデプロイメントの削除
ブルーグリーンデプロイメントは、次のいずれかの方法で削除できます：
ブルーグリーンデプロイ関係のみを削除する：
ブルーインスタンスとグリーンインスタンスはどちらも稼働を継続し、ブルーグリーンデプロイメントの制限事項は解除されます。
グリーンインスタンスは通常のインスタンスになります。従量課金の課金方法を継続して使用するか、[サブスクリプションに変更] できます。
[ブルーグリーンデプロイメント関係とグリーンインスタンスを削除]：
グリーンインスタンスは解放されます。
ブルーインスタンスには影響がなく、稼働を継続します。ブルーグリーンデプロイメントの制限事項は解除されます。
RDS Instances ページに移動し、リージョンを選択して、ブルーインスタンスの ID をクリックします。
左側メニューで ブルーグリーンデプロイメント を選択し、削除 セクションで ブルーグリーンの同期情報 をクリックします。
付録 1: エンドポイント切り替えの原理
エンドポイントの切り替えは、ブルーグリーンデプロイメントにおける中核的なステップであり、ユーザートラフィックを本番環境 (ブルー環境) からテスト環境 (グリーン環境) にスムーズに切り替えます。これは、次の図に示すように、仮想 IP (VIP) とリアルサーバー (RS) の間のマッピングを切り替えることで実現されます：
VIP：ユーザーがサービスにアクセスするためのエントリポイントです。
RS：サービスを提供する具体的なインスタンスです。
VIP と RS の間のマッピングを変更することで、トラフィックを新しい環境に向けることができます。たとえば、切り替えが発生すると、ブルーインスタンスを指していた VIP がグリーンインスタンスに再マッピングされます。
付録 2：切り替え前チェックとエラーメッセージ
チェック項目 | エラーメッセージ | 説明 |
Status check (Status-Check) | インスタンスのステータスは「実行中」である必要があります。 | ブルーインスタンスまたはグリーンインスタンスが「実行中」状態ではありません。 |
Table count (Table-Count) | ブルーインスタンスとグリーンインスタンス間でテーブル数が異なります。 | ブルーインスタンスとグリーンインスタンスでテーブル数が一致しません。 |
DTS status (DTS-Status) | DTS のステータスが同期中ではありません。 | DTS リンクが「同期中」状態ではありません。 |
DTS latency (DTS-Delay) | DTS の遅延が 5 秒を超えています。 | DTS 同期レイテンシが 5 秒以上です。切り替えを行うには、レイテンシが 5 秒未満である必要があります。 |
Read-only instances (ReadOnly) |
|
|
Database proxy |
|
|
Endpoints |
|
|
Databases (databases) |
|
|
Database accounts (accounts) |
|
|