# Amazon Aurora ブルー/グリーンデプロイの概要
Amazon Aurora ブルー/グリーンデプロイを使用すると、データベースに加えた変更をテストしてから、本番稼働環境に実装できます。*ブルー/グリーンのデプロイ*は、本稼働環境をコピーするステージング環境を作成します。ブルー/グリーンデプロイでは、*ブルー環境*が現在の本稼働環境です。*グリーン環境*はステージング環境であり、現在の本番環境との同期を維持します。
本稼働環境のワークロードに影響を与えずに、グリーン環境の Aurora DB クラスターに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、、またはデータベースパラメータの変更をステージング環境で行うことができます。グリーン環境での変化を徹底的にテストできます。準備ができたら、環境を*スイッチオーバー*して、グリーン環境を新しい本番稼働環境に移行できます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。
グリーン環境は本稼働環境のトポロジのコピーであるため、DB クラスターとそのすべての DB インスタンスはデプロイにコピーされます。グリーン環境には、DB クラスタースナップショット、パフォーマンスインサイト、拡張モニタリング、Aurora Serverless v2 など、DB クラスターで使用される機能も含まれています。
Amazon Aurora ブルー/グリーンデプロイは、Amazon RDS Proxy とスマートドライバーをサポートしています。これらのソリューションは、トポロジの変更を検出し、DNS の伝播を待たずに接続を新しい本番環境にリダイレクトすることで、スイッチオーバー中のライターノードのアップグレードのダウンタイムを短縮します。
**注記**
ブルー/グリーンデプロイは、Aurora MySQL、Aurora PostgreSQL、Aurora Global Database でサポートされています。Amazon RDS の可用性については、「*Amazon RDS ユーザーガイド*」の「[Amazon RDS ブルー/グリーンデプロイの概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)」を参照してください。
**Topics**
+ [リージョンとバージョンの可用性](#blue-green-deployments-region-version-availability)
+ [Amazon RDS ブルー/グリーンデプロイを使用する利点](#blue-green-deployments-benefits)
+ [ブルー/グリーンデプロイのワークフロー](#blue-green-deployments-major-steps)
+ [Amazon Aurora のブルー/グリーンデプロイオペレーションへのアクセスの承認](blue-green-deployments-authorizing-access.md)
+ [Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項](blue-green-deployments-considerations.md)
+ [Amazon Aurora のブルー/グリーンデプロイのベストプラクティス](blue-green-deployments-best-practices.md)
## リージョンとバージョンの可用性
機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。詳細については、「[ブルー/グリーンデプロイでサポートされているリージョンと Aurora DB エンジン](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md)」を参照してください。
## Amazon RDS ブルー/グリーンデプロイを使用する利点
Amazon RDS ブルー/グリーンデプロイを使用すると、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短い予測可能なダウンタイムで新しいデータベース機能を導入できます。ブルー/グリーンデプロイでは、エンジンのメジャーバージョンまたはマイナーバージョンのアップグレードなど、データベース更新のリスクとダウンタイムが軽減されます。
ブルー/グリーンデプロイには次の利点があります。
+ 本稼働環境に対応したステージング環境を簡単に作成できます。
+ データベースの変更を本稼働環境からステージング環境に自動的にレプリケートします。
+ 本稼働環境に影響を与えずに、安全なステージング環境でデータベースの変更をテストします。
+ データベースパッチとシステムアップデートを最新の状態に保ちます。
+ 新しいデータベース機能を実装してテストします。
+ アプリケーションを変更することなく、ステージング環境を新しい本稼働環境に切り替えます。
+ 組み込みの切り替えガードレールを使用して安全に切り替えることができます。
+ 切り替え中のデータ損失をなくします。
+ ワークロードにもよりますが、通常は 1 分以内にすばやく切り替えることができます。
## ブルー/グリーンデプロイのワークフロー
Aurora DB クラスターの更新にブルー/グリーンデプロイを使用する場合は、次の主要なステップを実行します。
1. 更新が必要な本稼働 DB クラスターを特定します。
次の図は、本稼働 DB クラスターの例を示しています。
1. ブルー/グリーンデプロイを作成します。手順については、「[Amazon Aurora でのブルー/グリーンデプロイの作成](blue-green-deployments-creating.md)」を参照してください。
以下の図は、ステップ 1 の本稼働環境のブルー/グリーンデプロイの例を示しています。ブルー/グリーンデプロイを作成する際、RDS は Aurora DB クラスターのトポロジと構成全体をコピーしてグリーン環境を作成します。コピーされた DB クラスターと DB インスタンスの名前には `-green-{{random-characters}}` が付加されます。図のステージング環境には DB クラスター (auroradb-green-{{*abc123*}}) が含まれています。また、DB クラスター内の 3 つの DB インスタンス (auroradb-instance1-green-{{*abc123*}}、auroradb-instance2-green-{{*abc123*}}、auroradb-instance3-green-{{*abc123*}}) も含まれています。
ブルー/グリーンデプロイを作成すると、グリーン環境で DB クラスターにより高い DB エンジンのバージョンと別の DB パラメータグループを指定できます。DB クラスター内の DB インスタンスに別の DB パラメータグループを指定することもできます。
RDS は、ブルー環境のプライマリ DB インスタンスからグリーン環境のプライマリ DB インスタンスへのレプリケーションも設定します。
**重要**
Aurora MySQL バージョン 3 では、ブルー/グリーンデプロイを作成すると、グリーン環境の DB クラスターはデフォルトでは書き込み操作を許可しません。ただし、これは、Aurora マスターユーザーなど、`CONNECTION_ADMIN` 権限を持つユーザーには適用されません。この権限を持つユーザーは、`read_only` 動作をオーバーライドできます。詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。
1. ステージング環境に変更を加えます。
例えば、グリーン環境の 1 つ以上の DB インスタンスが使用する DB インスタンスクラスを変更できます。
DB クラスターの変更の詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。
1. ステージング環境をテストします。
テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。Aurora MySQL の書き込み操作を有効にするには、`read_only` パラメータを `0` に設定し、DB インスタンスを再起動します。Aurora PostgreSQL の場合、セッションレベルで `default_transaction_read_only` パラメータを `off` に設定します。Amazon RDS Proxy でグリーン環境をテストする必要がある場合は、新しい Amazon RDS Proxy を作成し、グリーンクラスターを登録する必要があります。これにより、本番環境のブルー環境のトラフィックに影響を与えることなく、グリーン環境を個別にテストできます。テストが完了したら、テストプロキシを削除します。
1. 準備ができたら、スイッチオーバーして、ステージング環境を新しい本番稼働環境に移行します。手順については、「[Amazon Aurora でのブルー/グリーンデプロイの切り替え](blue-green-deployments-switching.md)」を参照してください。
切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。
次の図は、切り替え後の DB クラスターを示しています。
切り替え後、グリーン環境の Aurora DB クラスターが新しい実稼働 DB クラスターになります。現在の本番稼働環境内の名前とエンドポイントは、スイッチオーバー後の新しい本番稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。ブルー環境の DB クラスターと DB インスタンスは、現在の名前に `-old{{n}}` を付加することで名前が変更されます (`{{n}}` は数字です)。例えば、ブルー環境の DB インスタンスの名前が `auroradb-instance-1` であるとします。切り替え後、DB インスタンス名は `auroradb-instance-1-old1` になります。
図の例では、切り替え中に次の変更が行われます。
+ グリーン環境の DB クラスター `auroradb-green-abc123` は、`auroradb` という名前の付いた本稼働用 DB クラスターになります。
+ グリーン環境の `auroradb-instance1-green-abc123` という名前の DB インスタンスは、本稼働 DB インスタンス `auroradb-instance1` になります。
+ グリーン環境の `auroradb-instance2-green-abc123` という名前の DB インスタンスは、本稼働 DB インスタンス `auroradb-instance2` になります。
+ グリーン環境の `auroradb-instance3-green-abc123` という名前の DB インスタンスは、本稼働 DB インスタンス `auroradb-instance3` になります。
+ ブルー環境の `auroradb` という名前の DB クラスターは `auroradb-old1` になります。
+ ブルー環境の `auroradb-instance1` という名前の DB インスタンスは `auroradb-instance1-old1` になります。
+ ブルー環境の `auroradb-instance2` という名前の DB インスタンスは `auroradb-instance2-old1` になります。
+ ブルー環境の `auroradb-instance3` という名前の DB インスタンスは `auroradb-instance3-old1` になります。
1. 不要になったブルー/グリーンデプロイは削除できます。手順については、「[Amazon Aurora でのブルー/グリーンデプロイの削除](blue-green-deployments-deleting.md)」を参照してください。
切り替え後も以前の本稼働環境は削除されないため、必要に応じてリグレッションテストに使用できます。