Aurora 用 Amazon RDS ブルー/グリーンデプロイの概要

更新が必要な本稼働 DB クラスターを特定します。

次の図は、本稼働 DB クラスターの例を示しています。

ブルー/グリーンデプロイを作成します。手順については、ブルー/グリーンデプロイの作成 を参照してください。

以下の図は、ステップ 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 インスタンスへのレプリケーションも設定します。

ステージング環境に変更を加えます。

例えば、データベースにスキーマの変更を加えたり、グリーン環境の 1 つ以上の DB インスタンスが使用する DB インスタンスクラスを変更したりすることができます。

DB クラスターの変更については、「Amazon Aurora DB クラスターの変更」を参照してください。

ステージング環境をテストします。

テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。Aurora MySQL の書き込み操作を有効にするには、read_only パラメータを 0 に設定し、DB インスタンスを再起動します。Aurora PostgreSQL の場合、セッションレベルで default_transaction_read_only パラメータを off に設定します。

準備ができたら切り替えて、ステージング環境を昇格させ、新しい本稼働データベース環境にします。手順については、ブルー/グリーンデプロイの切り替え を参照してください。

切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。

次の図は、切り替え後の DB クラスターを示しています。

切り替え後、グリーン環境の Aurora DB クラスターが新しい実稼働 DB クラスターになります。現在の本稼働環境の名前とエンドポイントは、新しく昇格した本稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。ブルー環境の DB クラスターと DB インスタンスは、現在の名前に -oldn を付加することで名前が変更されます (n は数字です)。例えば、ブルー環境の DB インスタンスの名前が auroradb-instance-1 であるとします。切り替え後、DB インスタンス名は auroradb-instance-1-old1 になります。

図の例では、切り替え中に次の変更が行われます。

不要になったブルー/グリーンデプロイは削除できます。手順については、ブルー/グリーンデプロイの削除 を参照してください。

切り替え後も以前の本稼働環境は削除されないため、必要に応じてリグレッションテストに使用できます。