# Amazon RDS のブルー/グリーンデプロイの制限と考慮事項
<a name="blue-green-deployments-considerations"></a>

Amazon RDS のブルー/グリーンデプロイでは、レプリケーションスロット、リソース管理、インスタンスのサイズ設定、データベースのパフォーマンスへの潜在的な影響などの要素を慎重に検討する必要があります。以下のセクションでは、データベース環境の最小限のダウンタイム、シームレスな移行、効果的な管理を実現するために、デプロイ戦略を最適化するガイダンスを提供します。

**Topics**
+ [ブルー/グリーンデプロイの制限事項](#blue-green-deployments-limitations)
+ [ブルー/グリーンデプロイの考慮事項](#blue-green-deployments-consider)

## ブルー/グリーンデプロイの制限事項
<a name="blue-green-deployments-limitations"></a>

ブルー/グリーンデプロイには、次の制約事項が適用されます。

**Topics**
+ [ブルー/グリーンデプロイの一般的な制約事項](#blue-green-deployments-limitations-general)
+ [ブルー/グリーンデプロイの RDS for MySQL の制限](#blue-green-deployments-limitations-mysql)
+ [物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項](#blue-green-deployments-limitations-postgres-physical)
+ [論理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項](#blue-green-deployments-limitations-postgres-logical)

### ブルー/グリーンデプロイの一般的な制約事項
<a name="blue-green-deployments-limitations-general"></a>

ブルー/グリーンデプロイには、次の一般的な制約事項が適用されます。
+ ブルー/グリーンデプロイでは、AWS Secrets Manager を使用したマスターユーザーのパスワード管理はサポートされていません。
+ ブルーデータベースで専用ログボリューム (DLV) が有効になっている場合は、リードレプリカを含む*すべての* DB インスタンスで有効にする必要があります。
+ 切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。
+ ブルー/グリーンデプロイを作成するときには、グリーン環境でイベントスケジューラー (`event_scheduler` パラメーター) を無効にする必要があります。これにより、グリーン環境でイベントが生成されて不整合が発生するのを防ぐことができます。
+ 暗号化されていない DB インスタンスを暗号化された DB インスタンスに変更することはできません。さらに、暗号化された DB インスタンスを暗号化されていない DB インスタンスに変更することはできません。
+ ブルーの DB インスタンスを、対応するグリーンの DB インスタンスよりも上位のエンジンバージョンに変更することはできません。
+ ブルー環境とグリーン環境のリソースは同じ AWS アカウント にある必要があります。
+ Amazon RDS Proxy を使用する場合は、ブルー/グリーンデプロイを作成する前に、ブルークラスターをプロキシに登録する必要があります。特定のブルークラスターにブルー/グリーンデプロイが既に存在する場合、そのブルークラスターを Amazon RDS Proxy に登録することはブロックされます。
+ Aurora Global Databases では、ブルー/グリーンデプロイの Amazon RDS Proxy はサポートされていません。
+ ブルー/グリーンデプロイは、以下の機能ではサポートされていません。
  + カスケードリードレプリカ
  + クロスリージョンリードレプリカ
  + CloudFormation
  + マルチ AZ DB クラスター配置

    マルチ AZ DB インスタンスのデプロイでは、ブルー/グリーンデプロイがサポートされます。マルチ AZ 配置については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」を参照してください。

### ブルー/グリーンデプロイの RDS for MySQL の制限
<a name="blue-green-deployments-limitations-mysql"></a>

RDS for MySQL ブルー/グリーンデプロイには、以下の制限事項が適用されます。
+ ブルーの DB インスタンスを外部のバイナリログレプリカにすることはできません。
+ ソースデータベースがカスタムオプショングループに関連付けられている場合、ブルー/グリーンデプロイを作成するときにメジャーバージョンアップグレードを指定することはできません。

  この場合、メジャーバージョンアップグレードを指定せずにブルー/グリーンデプロイを作成できます。その後、グリーン環境のデータベースをアップグレードできます。詳細については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
+ ブルー/グリーンデプロイは MySQL 用の AWS JDBC ドライバーをサポートしていません。詳細については、GitHub の「[既知の制限事項](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)」を参照してください。

### 物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項
<a name="blue-green-deployments-limitations-postgres-physical"></a>

物理レプリケーションを使用する RDS for PostgreSQL ブルー/グリーンデプロイには、次の制限が適用されます。ブルー/グリーンデプロイが論理レプリケーションではなく物理レプリケーションを使用する状況については、「[ブルー/グリーンデプロイの PostgreSQL レプリケーション方法](blue-green-deployments-replication-type.md)」を参照してください。
+ グリーン環境の作成後は、メジャーバージョンアップグレードを手動で実行することはできません。
+ 物理レプリケーションを使用するブルー/グリーンデプロイは、厳密に読み取り専用であるため、グリーン環境でのスキーマの変更をサポートしていません。
+ ブルー DB インスタンスを論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。
+ RDS for PostgreSQL で遅延レプリケーションを設定する場合、ブルー/グリーンデプロイには次の制限があります。
  + **グリーンソースインスタンス** – パラメータグループで設定されていても、`recovery_min_apply_delay parameter` は無視されます。グリーンソースインスタンスの遅延設定は有効になりません。
  + **グリーンレプリカインスタンス** – `recovery_min_apply_delay parameter` は完全にサポートされ、PostgreSQL 設定ファイルに適用されます。遅延設定は、スイッチオーバーワークフロー中に想定どおりに機能します。
  + 遅延レプリケーションは、メジャーバージョンアップグレードの RDS ブルー/グリーンデプロイデプロイと互換性がありません。

### 論理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項
<a name="blue-green-deployments-limitations-postgres-logical"></a>

論理レプリケーションを使用する RDS for PostgreSQL のブルー/グリーンデプロイには、次の制限が適用されます。ブルー/グリーンデプロイが物理レプリケーションではなく論理レプリケーションを使用する状況については、「[ブルー/グリーンデプロイの PostgreSQL レプリケーション方法](blue-green-deployments-replication-type.md)」を参照してください。
+ 。
+ ブルー DB インスタンスを論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。
+ ブルー DB インスタンスが外部データラッパー (FDW) 拡張機能の外部サーバーとして設定されている場合は、IP アドレスの代わりにインスタンスエンドポイント名を使用する必要があります。これにより、スイッチオーバー後も設定は機能し続けます。
+ ブルー/グリーンデプロイでは、各データベースに論理レプリケーションスロットが必要です。データベースの数が増えると、特に DB インスタンスが十分にスケーリングされていない場合、リソースのオーバーヘッドが増加し、レプリケーションの遅延につながる可能性があります。影響は、データベースワークロードや接続数などの要因によって異なります。影響を軽減するには、DB インスタンスクラスをスケールアップするか、ソースインスタンスのデータベース数を減らすことを検討してください。
+ グリーン環境の論理的なレプリケーション[適用プロセス](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) などの代替アプローチを検討してください。
+ RDS for PostgreSQL で遅延レプリケーションを設定する場合、ブルー/グリーンデプロイには次の制限があります。
  + **グリーンソースインスタンス** – パラメータグループで設定されていても、`recovery_min_apply_delay parameter` は無視されます。グリーンソースインスタンスの遅延設定は有効になりません。
  + **グリーンレプリカインスタンス** – `recovery_min_apply_delay parameter` は完全にサポートされ、PostgreSQL 設定ファイルに適用されます。遅延設定は、スイッチオーバーワークフロー中に想定どおりに機能します。
  + 遅延レプリケーションは、メジャーバージョンアップグレードの RDS ブルー/グリーンデプロイデプロイと互換性がありません。
+ RDS for PostgreSQL のブルー/グリーンデプロイでは、パーティションテーブルでの新しいパーティションの作成はサポートされていません。新しいパーティションの作成には `CREATE TABLE` などのデータ定義言語 (DDL) オペレーションが含まれますが、これらはブルー環境からグリーン環境にレプリケートされません。ただし、既存のパーティションテーブルとそのデータはグリーン環境にレプリケートされます。
+ 以下の制約事項が PostgreSQL 拡張機能に適用されます。
  + ブルー/グリーンデプロイを作成するときは、ブルー環境で `pg_partman` 拡張機能を無効にする必要があります。この拡張機能は `CREATE TABLE` などの DDL オペレーションを実行します。これは、ブルー環境からグリーン環境への論理レプリケーションを中断します。
  + ブルー/グリーンデプロイを作成した後は、すべてのグリーンデータベースで `pg_cron` 拡張機能を無効のままにしておく必要があります。この拡張機能には、スーパーユーザーとして実行されるバックグラウンドワーカーがあり、グリーン環境の読み取り専用設定をバイパスするため、レプリケーションの競合が発生する可能性があります。
  + ブルー/グリーンデプロイを作成するときには、ブルー環境で `pglogical` および `pgactive` 拡張機能を無効にする必要があります。グリーン環境を新しい本番稼働環境にスイッチオーバーしたら、拡張機能を再度有効にできます。また、ブルーデータベースは外部インスタンスの論理サブスクライバーにはなれません。
  + `pgAudit` 拡張機能を使用している場合は、ブルー DB インスタンスとグリーン DB インスタンスの両方のカスタム DB パラメータグループの共有ライブラリ (`shared_preload_libraries`) に残っている必要があります。詳細については、「[pgAudit 拡張機能のセットアップ](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)」を参照してください。

#### ブルー/グリーンデプロイの論理レプリケーション固有の制限事項
<a name="blue-green-deployments-limitations-postgres"></a>

PostgreSQL には、論理レプリケーションに関連する特定の制約事項があります。これは、 RDS for PostgreSQL DB インスタンスのブルー/グリーンデプロイを作成する際の制約となります。

次の表では、 RDS for PostgreSQL のブルー/グリーンデプロイメントに適用される論理レプリケーションの制約事項について説明しています。詳細については、PostgreSQL の論理レプリケーションドキュメントの「[制限](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)」を参照してください。


| 制限 | 説明 | 
| --- | --- | 
| CREATE TABLE や CREATE SCHEMA などのデータ定義言語 (DDL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。 |  Amazon RDS がブルーの環境で DDL の変更を検出すると、**グリーンデータベース**はレプリケーションが低下した状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。 | 
| GRANT や REVOKE などのデータ制御言語 (DCL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。 | Amazon RDS PostgreSQL がブルー環境で DCL ステートメントを実行しようとすると、警告メッセージが表示されます。この動作はブルー/グリーンデプロイプロセスの制限であるため、変更できる設定や API はありません。 | 
| シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。 | スイッチオーバー中、 Amazon RDS はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。 | 
| ブルー環境のラージオブジェクトは、グリーン環境にはレプリケートされません。これには、既存のラージオブジェクトと、ブルー/グリーンデプロイプロセス中に新しく作成または変更したラージオブジェクトの両方が含まれます。 |  Amazon RDS が、`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)をご参照ください。 | 

## ブルー/グリーンデプロイの考慮事項
<a name="blue-green-deployments-consider"></a>

Amazon RDS は、ブルー/グリーンデプロイのリソースを各リソースの `DbiResourceId` で追跡します。このリソース ID は、リソースの AWS リージョン 固有のイミュータブルな識別子です。

*リソース* ID は、DB ***インスタンス* ID とは異なります。それぞれが RDS コンソールのデータベース設定に一覧表示されます。

ブルー/グリーンデプロイを切り替えると、リソースの名前 (インスタンス ID) は変わりますが、各リソースは同じリソース ID を保持します。例えば、DB インスタンス識別子はブルー環境で `mydb` である可能性があります。切り替え後、同じ DB インスタンスの名前が `mydb-old1` になる場合があります。ただし、DB インスタンスのリソース ID は切り替え中に変更されません。そのため、グリーンリソースを新しい本番稼働リソースにスイッチオーバーすると、そのリソース ID は以前に本番稼働環境にあったブルーリソース ID と一致しません。

ブルー/グリーンデプロイをスイッチオーバーしたら、本番稼働リソースで使用していた統合機能やサービスのリソース ID を、新しく移行した本番稼働リソースの ID に更新することを検討してください。具体的には、次のような更新を検討してください。
+ RDS API とリソース ID を使用してフィルタリングを実行する場合は、切り替え後にフィルタリングに使用されるリソース ID を調整します。
+ CloudTrail をリソースの監査に使用する場合は、切り替え後に新しいリソース ID を追跡するように CloudTrail のコンシューマーを調整します。詳細については、「[AWS CloudTrail での Amazon RDS API コールのモニタリング](logging-using-cloudtrail.md)」を参照してください。
+ パフォーマンスインサイト API を使用する場合は、切り替え後に API への呼び出しでリソース ID を調整します。詳細については、「[Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。

  切り替え後に同じ名前のデータベースをモニタリングできますが、切り替え前のデータは含まれていません。
+ IAM ポリシーでリソース ID を使用する場合は、必要に応じて新しく移行したリソースのリソース ID を追加してください。詳細については、「[Amazon RDS での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。
+ DB インスタンスに IAM ロールが関連付けられている場合は、スイッチオーバー後にそれらを再度関連付けます。アタッチされたロールはグリーンの環境に自動的にコピーされません。
+ [IAM データベース認証](UsingWithRDS.IAMDBAuth.md)を使用して DB インスタンスを認証する場合は、データベースアクセスに使用する IAM ポリシーの `Resource` 要素の下にブルーとグリーンのデータベースの両方が表示されていることを確認してください。これは、スイッチオーバー後にグリーンのデータベースに接続するために必要です。詳細については、「[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)」を参照してください。
+ AWS Backup を使用してブルー/グリーンデプロイのリソースの自動バックアップを管理する場合は、切り替え後に AWS Backup で使用するリソース ID を調整します。詳細については、「[Amazon RDS の自動バックアップの管理に AWS Backup を使用する](AutomatedBackups.AWSBackup.md)」を参照してください。
+ ブルー/グリーンデプロイに含まれていた DB インスタンスの手動または自動 DB スナップショットを復元する場合は、スナップショットが取られた時間を調べて、正しい DB スナップショットを復元します。詳細については、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
+ 以前のブルー環境 DB インスタンスの自動バックアップを記述する場合や、ある時点に復元する場合は、操作のリソース ID を使用します。

  DB インスタンスの名前は切り替え中に変更されるため、以前の名前を `DescribeDBInstanceAutomatedBackups` または `RestoreDBInstanceToPointInTime` 操作に使用することはできません。

  詳細については、「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)」を参照してください。
+ ブルー/グリーンデプロイのグリーン環境の DB インスタンスにリードレプリカを追加する場合、切り替え時にブルー環境のリードレプリカが新しいリードレプリカに置き換えられることはありません。ただし、新しいリードレプリカは、切り替え後も新しい本稼働環境に保持されます。
+ 切り替え後は、ブルー環境のチェックポイントがグリーン環境で無効であるため、AWS Database Migration Service (AWS DMS) レプリケーションタスクを再開できません。レプリケーションを続行するには、新しいチェックポイントで DMS タスクを再作成する必要があります。
+ ブルー/グリーンデプロイのグリーン環境の DB インスタンスを削除すると、ブルー/グリーンデプロイで代わりになる新しい DB インスタンスを作成することはできません。

  削除した DB インスタンスと同じ名前と Amazon リソースネーム (ARN) で新しい DB インスタンスを作成した場合、`DbiResourceId` が異なるため、グリーン環境には含まれません。

  グリーン環境で DB インスタンスを削除すると、次のような動作になります。
  + ブルー環境に同じ名前の DB インスタンスが存在する場合、グリーン環境の DB インスタンスに切り替わりません。この DB インスタンスの名前は、DB インスタンス名に `-old{{n}}` を付加することによって変更されません。
  + ブルー環境の DB インスタンスを参照するアプリケーションは、切り替え後も同じ DB インスタンスを引き続き使用します。

  同じ動作が DB インスタンスとリードレプリカにも当てはまります。
+ アクセスコントロールまたは運用管理にリソースタグを使用する場合は、スイッチオーバーまでタグの変更がブルー環境とグリーン環境の間で同期されないことを理解する必要があります。ブルー/グリーンデプロイを作成すると、ブルー環境のタグがグリーン環境にコピーされます。作成後、いずれかの環境に行ったタグの変更は自動的に同期されません。スイッチオーバー中、ブルー環境タグはグリーン環境内のすべてのタグを置き換えます。ブルー/グリーンデプロイを作成する前にブルー環境にすべての必要なタグを適用するか、スイッチオーバー後に新しい本番環境に必要なタグを再適用します。タグの詳細については、[ Amazon RDS リソースのタグ付け](USER_Tagging.md)を参照してください。