# Amazon Aurora ブルー/グリーンデプロイの概要
Amazon Aurora ブルー/グリーンデプロイを使用すると、データベースに加えた変更をテストしてから、本番稼働環境に実装できます。*ブルー/グリーンのデプロイ*は、本稼働環境をコピーするステージング環境を作成します。ブルー/グリーンデプロイでは、*ブルー環境*が現在の本稼働環境です。*グリーン環境*はステージング環境であり、現在の本番環境との同期を維持します。
本稼働環境のワークロードに影響を与えずに、グリーン環境の Aurora DB クラスターに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、、またはデータベースパラメータの変更をステージング環境で行うことができます。グリーン環境での変化を徹底的にテストできます。準備ができたら、環境を*スイッチオーバー*して、グリーン環境を新しい本番稼働環境に移行できます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。
グリーン環境は本稼働環境のトポロジのコピーであるため、DB クラスターとそのすべての DB インスタンスはデプロイにコピーされます。グリーン環境には、DB クラスタースナップショット、パフォーマンスインサイト、拡張モニタリング、Aurora Serverless v2 など、DB クラスターで使用される機能も含まれています。
**注記**
ブルー/グリーンデプロイは、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 クラスターの例を示しています。
![\[ブルー/グリーンデプロイの本稼働 (ブルー) Aurora DB クラスター\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png)
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**) も含まれています。
![\[Amazon Aurora のブルー/グリーンデプロイ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png)
ブルー/グリーンデプロイを作成すると、グリーン環境で 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` に設定します。
1. 準備ができたら、スイッチオーバーして、ステージング環境を新しい本番稼働環境に移行します。手順については、「[Amazon Aurora でのブルー/グリーンデプロイの切り替え](blue-green-deployments-switching.md)」を参照してください。
切り替えによりダウンタイムが発生します。ダウンタイムは通常 1 分未満ですが、ワークロードによってはさらに長くなることもあります。
次の図は、切り替え後の DB クラスターを示しています。
![\[Amazon Aurora ブルー/グリーンデプロイの切り替え後の DB クラスターと DB インスタンス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png)
切り替え後、グリーン環境の Aurora DB クラスターが新しい実稼働 DB クラスターになります。現在の本番稼働環境内の名前とエンドポイントは、スイッチオーバー後の新しい本番稼働環境に割り当てられるため、アプリケーションを変更する必要はありません。その結果、本稼働トラフィックが新しい本稼働環境に流れるようになります。ブルー環境の DB クラスターと DB インスタンスは、現在の名前に `-oldn` を付加することで名前が変更されます (`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)」を参照してください。
切り替え後も以前の本稼働環境は削除されないため、必要に応じてリグレッションテストに使用できます。
# Amazon Aurora のブルー/グリーンデプロイオペレーションへのアクセスの承認
ブルー/グリーンデプロイに関連する操作を実行するには、ユーザーは必要なアクセス許可があることが求められます。指定されたリソースに対して特定の API 操作を実行するために必要なアクセス許可をユーザーとロールに付与する IAM ポリシーを作成できます。その後、これらのポリシーを、それらのアクセス許可を必要とする IAM アクセス許可セットまたはロールにアタッチできます。詳細については、「[Amazon Aurora での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。
ブルー/グリーンデプロイを作成するユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource`
+ `rds:CreateDBCluster`
+ `rds:CreateDBInstance`
+ `rds:CreateDBClusterEndpoint`
ブルー/グリーンデプロイを切り替えるユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBCluster`
+ `rds:PromoteReadReplicaDBCluster`
ブルー/グリーンデプロイを削除するユーザーには、次の RDS オペレーション (複数可) を実行するアクセス許可が必要です。
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBCluster`
+ `rds:DeleteDBInstance`
+ `rds:DeleteDBClusterEndpoint`
Aurora は、お客様に代わってステージング環境のリソースをプロビジョニングおよび変更します。これらのリソースには、内部で定義された命名規則を使用する DB インスタンスが含まれます。したがって、アタッチされた IAM ポリシーには、`my-db-prefix-*` のような部分的なリソース名パターンを含めることはできません。ワイルドカード (\$1) のみがサポートされています。一般的に、これらのリソースへのアクセスを制御するには、ワイルドカードではなく、リソースタグやその他のサポートされている属性を使用することをおすすめします。詳細については、「[Amazon RDS のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html)」を参照してください。
## Aurora グローバルデータベースのブルー/グリーンデプロイの追加アクセス許可
Aurora Global Database クラスターのブルー/グリーンデプロイを作成する場合、ユーザーは上記のアクセス許可に加えて、グローバルクラスタートポロジを管理するオペレーションを実行するために次のアクセス許可が必要です。
ブルー/グリーンデプロイを作成するユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。
+ `rds:CreateGlobalCluster`
ブルー/グリーンデプロイを切り替えるユーザーには、次の RDS オペレーションを実行するアクセス許可が必要です。
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`
ブルー/グリーンデプロイを削除するユーザーには、次の RDS オペレーション (複数可) を実行するアクセス許可が必要です。
+ `rds:DeleteGlobalCluster`
# Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項
Amazon RDS のブルー/グリーンデプロイでは、レプリケーションスロット、リソース管理、インスタンスのサイズ設定、データベースのパフォーマンスへの潜在的な影響などの要素を慎重に検討する必要があります。以下のセクションでは、データベース環境の最小限のダウンタイム、シームレスな移行、効果的な管理を実現するために、デプロイ戦略を最適化するガイダンスを提供します。
**Topics**
+ [ブルー/グリーンデプロイの制限事項](#blue-green-deployments-limitations)
+ [ブルー/グリーンデプロイの Aurora Global Database の制限](#blue-green-deployments-limitations-agd)
+ [ブルー/グリーンデプロイの考慮事項](#blue-green-deployments-consider)
## ブルー/グリーンデプロイの制限事項
ブルー/グリーンデプロイには、次の制約事項が適用されます。
**Topics**
+ [ブルー/グリーンデプロイの一般的な制約事項](#blue-green-deployments-limitations-general)
+ [ブルー/グリーンデプロイの Aurora MySQL の制限](#blue-green-deployments-limitations-mysql)
+ [Aurora PostgreSQL のブルー/グリーンデプロイの制限事項](#blue-green-deployments-limitations-postgres-logical)
### ブルー/グリーンデプロイの一般的な制約事項
ブルー/グリーンデプロイには、次の一般的な制約事項が適用されます。
+ ブルー/グリーンデプロイの一部であるクラスターを停止および開始することはできません。
+ ブルー/グリーンデプロイでは、AWS Secrets Manager を使用したマスターユーザーのパスワード管理はサポートされていません。
+ ブルー DB クラスターでバックトラックを強制実行しようとすると、ブルー/グリーンデプロイが中断され、スイッチオーバーがブロックされます。
+ 切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。
+ ブルー/グリーンデプロイを作成するときには、グリーン環境でイベントスケジューラー (`event_scheduler` パラメーター) を無効にする必要があります。これにより、グリーン環境でイベントが生成されて不整合が発生するのを防ぐことができます。
+ ブルー DB クラスターで設定されている Auto Scaling ポリシーはグリーン環境にコピーされません。最初にブルー環境またはグリーン環境でセットアップされたかにかかわらず、スイッチオーバー後に再設定する必要があります。
+ 暗号化されていない DB クラスターを暗号化された DB クラスターに変更することはできません。さらに、暗号化された DB クラスターを暗号化されていない DB クラスターに変更することはできません。
+ ブルーの DB クラスターを、対応するグリーンの DB クラスターよりも上位のエンジンバージョンに変更することはできません。
+ ブルー環境とグリーン環境のリソースは同じ AWS アカウント にある必要があります。
+ ブルー/グリーンデプロイは、以下の機能ではサポートされていません。
+ Amazon RDS Proxy
+ クロスリージョンリードレプリカ
+ Aurora Serverless v1 DB クラスター
+ CloudFormation
### ブルー/グリーンデプロイの Aurora MySQL の制限
Aurora MySQL ブルー/グリーンデプロイには、以下の制限事項が適用されます。
+ ソース DB クラスターには `tmp` という名前のデータベースを含めることはできません。この名前のデータベースはグリーン環境にコピーされません。
+ ブルーの DB クラスターを外部のバイナリログレプリカにすることはできません。
+ バックトラックが有効になっているソース DB クラスターの場合、グリーン DB クラスターはバックトラックのサポートなしで作成されます。バックトラックは、ブルー/グリーンデプロイに必須のバイナリログ (binlog) レプリケーションでは機能しないためです。詳細については、「[Aurora DB クラスターのバックトラック](AuroraMySQL.Managing.Backtrack.md)」を参照してください。
+ ブルー/グリーンデプロイは MySQL 用の AWS JDBC ドライバーをサポートしていません。詳細については、GitHub の「[既知の制限事項](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)」を参照してください。
### Aurora PostgreSQL のブルー/グリーンデプロイの制限事項
Aurora PostgreSQL のブルー/グリーンデプロイには、次の制限が適用されます。
+ ブルー DB クラスターで `rds.logically_replicate_unlogged_tables` パラメータが `1` に設定されていない限り、[ログに記録されていない](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED)テーブルはグリーン環境にレプリケートされません。ブルー/グリーンデプロイを作成した後は、ログに記録されていないテーブルでレプリケーションエラーが発生するのを避けるため、このパラメータ値を変更しないでください。
+ ブルー DB クラスターを論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。
+ ブルー DB クラスターが外部データラッパー (FDW) 拡張機能の外部サーバーとして設定されている場合は、IP アドレスの代わりにクラスターエンドポイント名を使用する必要があります。これにより、スイッチオーバー後も設定は機能し続けます。
+ ブルー/グリーンデプロイでは、各データベースに論理レプリケーションスロットが必要です。データベースの数が増えると、特に DB クラスターが十分にスケーリングされていない場合、リソースのオーバーヘッドが増加し、レプリケーションの遅延につながる可能性があります。影響は、データベースワークロードや接続数などの要因によって異なります。影響を軽減するには、DB インスタンスクラスをスケールアップするか、ソースクラスターのデータベース数を減らすことを検討してください。
+ Babelfish for Aurora PostgreSQL の場合、ブルー/グリーンデプロイはバージョン 15 (15.7 以降) とバージョン 16 (16.3 以降) でのみサポートされています。
+ Aurora Replicas で実行プランをキャプチャする場合は、`apg_plan_mgmt.create_replica_plan_capture` 関数を呼び出すときにブルー DB クラスターエンドポイントを指定する必要があります。これにより、プランのキャプチャはスイッチオーバー後も引き続き機能します。詳細については、「[レプリカでの Aurora PostgreSQL 実行プランのキャプチャ](AuroraPostgreSQL.QPM.Plancapturereplicas.md)」を参照してください。
+ グリーン環境の論理的なレプリケーション[適用プロセス](https://www.postgresql.org/docs/current/logical-replication-architecture.html)は、シングルスレッドです。ブルー環境が大量の書き込みトラフィックを生成した場合、グリーン環境は維持できない可能性があります。これにより、特に書き込みスループットが継続的に高いワークロードでは、レプリケーションの遅延や障害が発生する可能性があります。ワークロードを徹底的にテストしてください。メジャーバージョンのアップグレードが必要で、大量の書き込みワークロードを処理するシナリオでは、[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) や[セルフマネージド論理レプリケーション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html)などの代替アプローチを検討してください。
+ Aurora のブルー/グリーンデプロイでは、パーティションテーブルでの新しいパーティションの作成はサポートされていません。新しいパーティションの作成には `CREATE TABLE` などのデータ定義言語 (DDL) オペレーションが含まれますが、これらはブルー環境からグリーン環境にレプリケートされません。ただし、既存のパーティションテーブルとそのデータはグリーン環境にレプリケートされます。
+ 以下の制約事項が PostgreSQL 拡張機能に適用されます。
+ ブルー/グリーンデプロイを作成するときは、ブルー環境で `pg_partman` 拡張機能を無効にする必要があります。この拡張機能は `CREATE TABLE` などの DDL オペレーションを実行します。これは、ブルー環境からグリーン環境への論理レプリケーションを中断します。
+ ブルー/グリーンデプロイを作成した後は、すべてのグリーンデータベースで `pg_cron` 拡張機能を無効のままにしておく必要があります。この拡張機能には、スーパーユーザーとして実行されるバックグラウンドワーカーがあり、グリーン環境の読み取り専用設定をバイパスするため、レプリケーションの競合が発生する可能性があります。
+ ブルー環境で同じプランが取り込まれた場合、プライマリキーの競合が発生しないように、`apg_plan_mgmt` 拡張機能の `apg_plan_mgmt.capture_plan_baselines` パラメータをすべてのグリーンデータベースで `off` に設定する必要があります。詳細については、「[Aurora PostgreSQL のクエリプラン管理の概要](AuroraPostgreSQL.Optimize.overview.md)」を参照してください。
+ ブルー/グリーンデプロイを作成するときには、ブルー環境で `pglogical` および `pgactive` 拡張機能を無効にする必要があります。グリーン環境を新しい本番稼働環境にスイッチオーバーしたら、拡張機能を再度有効にできます。また、ブルーデータベースは外部インスタンスの論理サブスクライバーにはなれません。
+ `pgAudit` 拡張機能を使用している場合は、ブルー DB インスタンスとグリーン DB インスタンスの両方のカスタム DB パラメータグループの共有ライブラリ (`shared_preload_libraries`) に残っている必要があります。詳細については、「[pgAudit 拡張機能のセットアップ](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)」を参照してください。
#### ブルー/グリーンデプロイの論理レプリケーション固有の制限事項
PostgreSQL には、論理レプリケーションに関連する特定の制約事項があります。これは、Aurora PostgreSQL DB クラスター のブルー/グリーンデプロイを作成する際の制約となります。
次の表では、Aurora PostgreSQL のブルー/グリーンデプロイメントに適用される論理レプリケーションの制約事項について説明しています。詳細については、PostgreSQL の論理レプリケーションドキュメントの「[制限](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)」を参照してください。
| 制限 | 説明 |
| --- | --- |
| CREATE TABLE や CREATE SCHEMA などのデータ定義言語 (DDL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。 | Aurora がブルーの環境で DDL の変更を検出すると、**グリーンデータベース**はレプリケーションが低下した状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。 |
| GRANT や REVOKE などのデータ制御言語 (DCL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。 | Aurora がブルー環境で DCL ステートメントを実行しようとすると、警告メッセージが表示されます。この動作はブルー/グリーンデプロイプロセスの制限であるため、変更できる設定や API はありません。 |
| シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。 | スイッチオーバー中、Aurora はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。 |
| ブルー環境のラージオブジェクトは、グリーン環境にはレプリケートされません。これには、既存のラージオブジェクトと、ブルー/グリーンデプロイプロセス中に新しく作成または変更したラージオブジェクトの両方が含まれます。 | Aurora が、`pg_largeobject` システムテーブルに保存されているブルー環境でラージオブジェクトの作成または変更を検出すると、グリーンデータベースは**レプリケーションが低下した**の状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。 |
| マテリアライズドビューを更新すると、レプリケーションが中断されます。 | ブルー環境でマテリアライズドビューを更新すると、グリーン環境へのレプリケーションが中断されます。ブルー環境でマテリアライズドビューを更新しないようにします。スイッチオーバー後、[REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) コマンドを使用して手動で更新することも、更新をスケジュールすることもできます。 |
| UPDATE および DELETE オペレーションは、プライマリキーのないテーブルでは許可されません。 | ブルー/グリーンデプロイを作成する前に、すべてのテーブルにプライマリキーがあるか、または `REPLICA IDENTITY FULL` を使用していることを確認してください。ただし、プライマリキーまたは一意のキーが存在しない場合は、レプリケーションのパフォーマンスに影響するため、`REPLICA IDENTITY FULL` のみを使用してください。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)をご参照ください。 |
## ブルー/グリーンデプロイの Aurora Global Database の制限
上記の一般的な制限とエンジン固有の制限に加えて、Aurora Global Database のブルー/グリーンデプロイには以下の制限が適用されます。
+ すべてのオペレーションは、グローバルデータベースのライタークラスターと同じリージョンから開始する必要があります。
+ グローバルスイッチオーバーまたはグローバルフェイルオーバーを実行すると、アクティブなブルー/グリーンデプロイが無効になります。ブルー/グリーンデプロイは、新しいプライマリリージョンから削除して再作成する必要があります。
+ Aurora PostgreSQL の場合、本番環境でグローバル書き込み転送を有効にし、ブルー/グリーンデプロイを作成すると、書き込み転送はグリーンクラスターで無効になります。これは、ブルー/グリーンスイッチオーバー後、グリーン環境が新しい本番環境になったときにのみ、グリーン環境で有効になります。スイッチオーバー後、書き込み転送は `-old1` クラスターで無効になります。
+ ブルー/グリーンデプロイの作成後にグローバルデータベースのトポロジを変更すると、アクティブなブルー/グリーンデプロイが無効になります。ブルー/グリーンデプロイは、新しいプライマリリージョンから削除して再作成する必要があります。
+ 自動スナップショットは、古いブルー環境で最初に設定されたバックアップ保持日数ごとに保持されます。古いブルークラスターの自動スナップショットはグリーンにコピーされません。
+ グローバルフェイルオーバーはブルー/グリーンスイッチオーバー中にサポートされますが、グローバルスイッチオーバーはブルー/グリーンスイッチオーバー中にサポートされません。
+ グリーン環境の DB クラスターと DB パラメータグループが、すべてのセカンダリリージョンに同じ名前で存在することを確認します。任意のリージョンのパラメータグループが使用できない場合、リージョンのデフォルトのパラメータグループが使用されます。
+ ブルー/グリーンデプロイのスイッチオーバー中は、グローバルデータベースメンバーで RDS Proxy を使用しないでください。
## ブルー/グリーンデプロイの考慮事項
Amazon RDS は、ブルー/グリーンデプロイのリソースを各リソースの `DbiResourceId`および `DbClusterResourceId` で追跡します。このリソース ID は、リソースの AWS リージョン 固有のイミュータブルな識別子です。
*リソース* ID は、DB *クラスター*** ID とは異なります。それぞれが RDS コンソールのデータベース設定に一覧表示されます。
ブルー/グリーンデプロイを切り替えると、リソースの名前 (クラスター ID) は変わりますが、各リソースは同じリソース ID を保持します。例えば、DB クラスター識別子がブルー環境で `mycluster` であったとします。切り替え後、同じ DB クラスターの名前が `mycluster-old1` に変更されたとします。ただし、DB クラスターのリソース ID は切り替え中に変更されません。そのため、グリーンリソースを新しい本番稼働リソースにスイッチオーバーすると、そのリソース ID は以前に本番稼働環境にあったブルーリソース ID と一致しません。
ブルー/グリーンデプロイをスイッチオーバーしたら、本番稼働リソースで使用していた統合機能やサービスのリソース ID を、新しく移行した本番稼働リソースの ID に更新することを検討してください。具体的には、次のような更新を検討してください。
+ RDS API とリソース ID を使用してフィルタリングを実行する場合は、切り替え後にフィルタリングに使用されるリソース ID を調整します。
+ CloudTrail をリソースの監査に使用する場合は、切り替え後に新しいリソース ID を追跡するように CloudTrail のコンシューマーを調整します。詳細については、「[AWS CloudTrail での Amazon Aurora API コールのモニタリング](logging-using-cloudtrail.md)」を参照してください。
+ ブルー環境のリソースにデータベースアクティビティストリームを使用する場合は、切り替え後に新しいストリームのデータベースイベントをモニタリングするようにアプリケーションを調整します。詳細については、「[データベースアクティビティストリームでサポートされているリージョンと Aurora DB エンジン](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md)」を参照してください。
+ パフォーマンスインサイト API を使用する場合は、切り替え後に API への呼び出しでリソース ID を調整します。詳細については、「[Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。
切り替え後に同じ名前のデータベースをモニタリングできますが、切り替え前のデータは含まれていません。
+ IAM ポリシーでリソース ID を使用する場合は、必要に応じて新しく移行したリソースのリソース ID を追加してください。詳細については、「[Amazon Aurora での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。
+ DB クラスターに IAM ロールが関連付けられている場合は、スイッチオーバー後にそれらを再度関連付けます。アタッチされたロールはグリーンの環境に自動的にコピーされません。
+ [IAM データベース認証](UsingWithRDS.IAMDBAuth.md)を使用して DB クラスターを認証する場合は、データベースアクセスに使用する IAM ポリシーの `Resource` 要素の下にブルーとグリーンのデータベースの両方が表示されていることを確認してください。これは、スイッチオーバー後にグリーンのデータベースに接続するために必要です。詳細については、「[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)」を参照してください。
+ ブルー/グリーンデプロイに含まれていた DB クラスターの手動 DB クラスタースナップショットを復元する場合は、スナップショットが取られた時間を調べて、正しい DB クラスタースナップショットを復元します。詳細については、「[DB クラスタースナップショットからの復元](aurora-restore-snapshot.md)」を参照してください。
+ 切り替え後は、ブルー環境のチェックポイントがグリーン環境で無効であるため、AWS Database Migration Service (AWS DMS) レプリケーションタスクを再開できません。レプリケーションを続行するには、新しいチェックポイントで DMS タスクを再作成する必要があります。
+ Amazon Aurora は、基盤となるブルー環境の Aurora ストレージボリュームを*クローニング*することでグリーン環境を作成します。グリーンのクラスターボリュームには、グリーン環境に加えられた増分変更のみが保存されます。ブルー環境の DB クラスターを削除すると、グリーン環境の基盤となる Aurora ストレージボリュームのサイズは、フルサイズまで増大します。詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。
+ ブルー/グリーンデプロイのグリーン環境の DB クラスターに DB インスタンスを追加すると、切り替え時にブルー環境の DB インスタンスが新しい DB インスタンスに置き換わることはありません。ただし、新しい DB インスタンスは DB クラスターに残り、新しい本稼働環境の DB インスタンスになります。
+ ブルー/グリーンデプロイのグリーン環境で DB クラスターの DB インスタンスを削除すると、ブルー/グリーンデプロイで代わりになる新しい DB インスタンスを作成することはできません。
削除した DB インスタンスと同じ名前と ARN で新しい DB インスタンスを作成する場合、`DbiResourceId` が異なるため、グリーン環境には含まれません。
グリーン環境で DB クラスター内の DB インスタンスを削除すると、次のような動作になります。
+ ブルー環境に同じ名前の DB インスタンスが存在する場合、グリーン環境の DB インスタンスに切り替わりません。この DB インスタンスの名前は、DB インスタンス名に `-oldn` を付加することによって変更されません。
+ ブルー環境の DB インスタンスを参照するアプリケーションは、切り替え後も同じ DB インスタンスを引き続き使用します。
+ アクセスコントロールまたは運用管理にリソースタグを使用する場合は、スイッチオーバーまでタグの変更がブルー環境とグリーン環境の間で同期されないことを理解する必要があります。ブルー/グリーンデプロイを作成すると、ブルー環境のタグがグリーン環境にコピーされます。作成後、いずれかの環境に行ったタグの変更は自動的に同期されません。スイッチオーバー中、ブルー環境タグはグリーン環境内のすべてのタグを置き換えます。ブルー/グリーンデプロイを作成する前にブルー環境にすべての必要なタグを適用するか、スイッチオーバー後に新しい本番環境に必要なタグを再適用します。タグの詳細については、[Amazon Aurora および Amazon RDS リソースのタグ付け](USER_Tagging.md)を参照してください。
# Amazon Aurora のブルー/グリーンデプロイのベストプラクティス
ブルー/グリーンデプロイのベストプラクティスを以下に示します。
**Topics**
+ [ブルー/グリーンデプロイの一般的なベストプラクティス](#blue-green-deployments-best-practices-general)
+ [Aurora MySQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-mysql)
+ [Aurora PostgreSQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-postgres)
+ [Aurora Global Database のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-agd)
## ブルー/グリーンデプロイの一般的なベストプラクティス
ブルー/グリーンデプロイを作成するときは、次の一般的なベストプラクティスを考慮してください。
+ 切り替える前に、Aurora DB クラスターをグリーン環境で十分にテストしてください。
+ グリーン環境のデータベースは読み取り専用のまま維持してください。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作の有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。
+ ブルー/グリーンデプロイを使用してスキーマの変更を実装する場合は、レプリケーション互換の変更のみを行ってください。
例えば、ブルーデプロイからグリーンデプロイへのレプリケーションを中断することなく、テーブルの最後に新しい列を追加することができます。ただし、列名の変更やテーブル名の変更などのスキーマの変更は、グリーンデプロイへのレプリケーションを中断させます。
レプリケーションと互換性のある変更の詳細については、MySQL ドキュメントの「[ソースとレプリカのテーブル定義が異なるレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html)」と PostgreSQL 論理レプリケーションドキュメントの「[制限](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)」を参照してください。
+ 両方の環境のすべての接続に、クラスターエンドポイント、リーダーエンドポイント、またはカスタムエンドポイントを使用します。静的リストまたは除外リストのあるインスタンスエンドポイントやカスタムエンドポイントは使用しないでください。
+ ブルー/グリーンデプロイメントを切り替えるときは、切り替えのベストプラクティスに従ってください。詳細については、「[切り替えのベストプラクティス](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices)」を参照してください。
## Aurora MySQL のブルー/グリーンデプロイのベストプラクティス
Aurora MySQL DB クラスターからブルー/グリーンデプロイを作成するときは、次のベストプラクティスを考慮してください。
+ グリーン環境でレプリカの遅延が発生した場合は、以下の点を考慮します。
+ バイナリログ保持が不要な場合は無効にするか、レプリケーションが追い付くまで一時的に無効にします。これを行うには、`binlog_format` DB クラスターパラメータを `0` に戻し、グリーンライター DB インスタンスを再起動します。
+ グリーン DB パラメータグループで `innodb_flush_log_at_trx_commit` パラメータを一時的に `0` に設定します。レプリケーションが追い付いたら、スイッチオーバーの前にデフォルト値 `1` に戻します。一時的なパラメータ値で予期しないシャットダウンやクラッシュが発生した場合は、検出されないデータ破損を避けるためにグリーン環境を再構築します。詳細については、 を参照してください。[ログバッファをフラッシュする頻度の設定](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)
## Aurora PostgreSQL のブルー/グリーンデプロイのベストプラクティス
Aurora PostgreSQL DB クラスターからブルー/グリーンデプロイを作成するときは、次のベストプラクティスを考慮してください。
+ Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュをモニタリングし、必要に応じてキャッシュバッファを調整します。詳細については、「[Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache)」を参照してください。
+ ブルー環境で `logical_decoding_work_mem` DB パラメータの値を増やします。そうすることで、ディスク上でのデコード回数が減り、代わりにメモリを消費します。詳細については、「[論理デコード用のワーキングメモリの調整](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)」を参照してください。
+ `ReplicationSlotDiskUsage` CloudWatch メトリクスを使用して、ディスクに書き込まれるトランザクションのオーバーフローをモニタリングできます。このメトリクスは、レプリケーションスロットのディスク使用状況に関するインサイトを提供し、トランザクションデータがメモリ容量を超えてディスクに保存されるタイミングを特定するのに役立ちます。`FreeableMemory` CloudWatch メトリクスを使用して空きメモリをモニタリングできます。詳細については、「[Amazon Aurora のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)」を参照してください。
+ Aurora PostgreSQL バージョン 14 以降では、`[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` システムビューを使用して論理オーバーフローファイルのサイズをモニタリングできます。
+ ブルー/グリーンデプロイを作成するときには、すべての PostgreSQL 拡張機能を最新バージョンに更新してください。詳細については、「[PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)」を参照してください。
+ `aws_s3` 拡張機能を使用している場合は、グリーン環境が作成された後に、必ず IAM ロールを通じてグリーン DB クラスターに Amazon S3 へのアクセスを許可してください。これにより、インポートコマンドとエクスポートコマンドは、スイッチオーバー後も機能し続けることができます。手順については、「[Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md)」を参照してください。
+ グリーン環境でより上位のエンジンバージョンを指定する場合は、すべてのデータベースに対して `ANALYZE` オペレーションを実行して `pg_statistic` テーブルを更新します。Optimizer の統計情報はメジャーバージョンのアップグレード時に転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。メジャーバージョンアップグレード時のその他のベストプラクティスについては、「[メジャーバージョンアップグレードの実行](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)」を参照してください。
+ ソースでトリガーを使用してデータを操作している場合は、トリガーを `ENABLE REPLICA` または `ENABLE ALWAYS` として設定しないでください。レプリケーションシステムが変更を伝播してトリガーを実行し、重複を引き起こします。
+ トランザクションの実行時間が長いと、レプリカの遅延が大きくなる可能性があります。レプリカの遅延を減らすには、以下を検討します。
+ グリーン環境がブルー環境に追いつくまで遅延する可能性がある、実行時間の長いトランザクションとサブトランザクションを減らします。
+ グリーン環境がブルー環境に追いつくまで、ブルー環境での一括オペレーションを減らします。
+ ブルー/グリーンデプロイを作成する前に、ビジーテーブルで手動バキュームフリーズオペレーションを開始します。手順については、「[手動バキュームフリーズの実行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html)」を参照してください。
+ PostgreSQL バージョン 12 以降では、大規模なテーブルやビジー状態のテーブルで `index_cleanup` パラメータを無効にし、ブルーデータベースの定期メンテナンスの効率を向上させます。詳細については、「[テーブルをできるだけ早くバキューム処理する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)」を参照してください。
**注記**
バキューム中にインデックスのクリーンアップを定期的にスキップすると、インデックスが肥大化し、スキャンパフォーマンスが低下する可能性があります。ベストプラクティスとして、このアプローチはブルー/グリーンデプロイの使用時にのみ使用してください。デプロイが完了したら、インデックスの定期的なメンテナンスとクリーンアップを再開することをお勧めします。
+ ブルー DB インスタンスとグリーン DB インスタンスが、ワークロードのサイズより小さい場合、レプリカの遅延が発生する可能性があります。DB インスタンスがインスタンスタイプのリソース制限に達していないことを確認します。詳細については、「[Amazon CloudWatch メトリクスを使用して Aurora PostgreSQL のリソース使用状況を分析する](AuroraPostgreSQL_AnayzeResourceUsage.md)」を参照してください。
+ レプリケーションが遅い場合、送信者と受信者が頻繁に再起動し、同期が遅れる可能性があります。送信者と受信者が再起動しないようにするには、ブルー環境で `wal_sender_timeout` パラメータを `0` に設定し、グリーン環境で `wal_receiver_timeout` パラメータを `0` に設定してタイムアウトを無効にします。
+ UPDATE ステートメントと DELETE ステートメントのパフォーマンスを確認し、WHERE 句で使用する列にインデックスを作成することで、これらのクエリを最適化できるかどうかを評価します。これにより、グリーン環境でオペレーションを再生するときのパフォーマンスを向上させることができます。詳細については、 を参照してください。[待機を生成するクエリの述語フィルターをチェックする](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters)
+ トリガーを使用する場合は、名前が「rds」で始まる `pg_catalog.pg_publication`、`pg_catalog.pg_subscription`、`pg_catalog.pg_replication_slots` オブジェクトの作成、更新、削除を妨げないようにしてください。
+ ソース DB クラスターで Babelfish が有効になっている場合、グリーン環境のターゲット DB クラスターパラメータグループで、次のパラメータは、ソース DB クラスターパラメータグループと同じ設定になっている必要があります。
+ rds.babelfish\$1status
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1precision
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1scale
+ babelfishpg\$1tsql. default\$1locale
+ babelfishpg\$1tsql.migration\$1mode
+ babelfishpg\$1tsql.server\$1collation\$1name
これらのパラメータの詳細については、「[Babelfish の DB クラスターパラメータグループ設定](babelfish-configuration.md)」を参照してください。
## Aurora Global Database のブルー/グリーンデプロイのベストプラクティス
上記の一般的なベストプラクティスとエンジン固有のベストプラクティスに加えて、Aurora Global Database の以下のベストプラクティスを検討してください。
+ 次の CloudWatch メトリクスをモニタリングして、本番環境でのアクティビティが少ない期間を特定します。
+ `DatabaseConnections`
+ `ActiveTransactions`
ブルー/グリーンスイッチオーバーは、計画されたメンテナンスウィンドウ中またはアクティビティが少ない期間にスケジュールします。
+ ブルー/グリーンスイッチオーバー期間は、ワークロードとセカンダリリージョンの数によって異なります。ブルー/グリーンスイッチオーバーを開始すると、サービスはレプリカの遅延がゼロになるまで待機してから続行します。スイッチオーバーを開始する前に、レプリカの遅延を確認することをお勧めします。
+ グリーン環境のデフォルト以外の DB パラメータまたは DB クラスターパラメータグループを使用する場合は、ブルー/グリーンデプロイを開始する前に、すべてのセカンダリリージョンで同じ名前の必要なパラメータグループを作成します。