# 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)を参照してください。