# Amazon RDS のブルー/グリーンデプロイのベストプラクティス
ブルー/グリーンデプロイのベストプラクティスを以下に示します。
**Topics**
+ [ブルー/グリーンデプロイの一般的なベストプラクティス](#blue-green-deployments-best-practices-general)
+ [RDS for MySQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-mysql)
+ [RDS for MySQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-agd)
+ [ブルー/グリーンデプロイの PostgreSQL レプリケーション方法](blue-green-deployments-replication-type.md)
## ブルー/グリーンデプロイの一般的なベストプラクティス
ブルー/グリーンデプロイを作成するときは、次の一般的なベストプラクティスを考慮してください。
+ 切り替える前に、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)」を参照してください。
**注記**
この制限は、物理レプリケーションを使用する RDS for PostgreSQL ブルー/グリーンデプロイには適用されません。詳細については、「[物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)」を参照してください。
+ ブルー/グリーンデプロイを作成した後、必要に応じて遅延読み込みを処理します。切り替える前に、データの読み込みが完了していることを確認してください。詳細については、「[ブルー/グリーンデプロイの遅延読み込みとストレージの初期化](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading)」を参照してください。
+ ブルー/グリーンデプロイメントを切り替えるときは、切り替えのベストプラクティスに従ってください。詳細については、「[切り替えのベストプラクティス](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices)」を参照してください。
## RDS for MySQL のブルー/グリーンデプロイのベストプラクティス
RDS for MySQL DB インスタンスからブルー/グリーンデプロイを作成するときは、次のベストプラクティスを考慮してください。
+ MyISAM など、レプリケーション用に最適化されていない非トランザクションストレージエンジンの使用は避けてください。
+ リードレプリカとグリーン環境をバイナリログレプリケーション用に最適化します。DB エンジンでサポートされている場合は、ブルー/グリーンデプロイを作成する前に、GTID、並列、クラッシュセーフレプリケーションを有効にして、データの整合性と耐久性を確保します。詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
+ グリーン環境でレプリカの遅延が発生した場合は、以下の点を考慮します。
+ グリーン DB パラメータグループで `innodb_flush_log_at_trx_commit` パラメータを一時的に `2` に設定します。レプリケーションが追い付いたら、スイッチオーバーの前にデフォルト値 `1` に戻します。一時的なパラメータ値で予期しないシャットダウンやクラッシュが発生した場合は、検出されないデータ破損を避けるためにグリーン環境を再構築します。詳細については、
+ 書き込みレイテンシーを短縮し、レプリケーションスループットを向上させるには、一時的にグリーンマルチ AZ DB インスタンスをシングル AZ DB インスタンスに変更します。スイッチオーバーの直前にマルチ AZ を再度有効にします。
## RDS for MySQL のブルー/グリーンデプロイのベストプラクティス
上記の一般的なベストプラクティスとエンジン固有のベストプラクティスに加えて、RDS for MySQL DB インスタンス の以下のベストプラクティスを検討してください。
+ 次の CloudWatch メトリクスをモニタリングして、本番環境でのアクティビティが少ない期間を特定します。
+ `DatabaseConnections`
+ `ActiveTransactions`
ブルー/グリーンスイッチオーバーは、計画されたメンテナンスウィンドウ中またはアクティビティが少ない期間にスケジュールします。
+ ブルー/グリーンスイッチオーバー期間は、ワークロードとセカンダリリージョンの数によって異なります。ブルー/グリーンスイッチオーバーを開始すると、サービスはレプリカの遅延がゼロになるまで待機してから続行します。スイッチオーバーを開始する前に、レプリカの遅延を確認することをお勧めします。
+ グリーン環境のデフォルト以外の DB パラメータまたは DB クラスターパラメータグループを使用する場合は、ブルー/グリーンデプロイを開始する前に、すべてのセカンダリリージョンで同じ名前の必要なパラメータグループを作成します。
### RDS for PostgreSQL のブルー/グリーンデプロイのベストプラクティス
RDS for PostgreSQL DB インスタンスからブルー/グリーンデプロイを作成するときは、次のベストプラクティスを考慮してください。
**Topics**
+ [RDS for PostgreSQL のブルー/グリーンデプロイの一般的なベストプラクティス](#blue-green-deployments-best-practices-postgres-general)
+ [物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-postgres-physical)
+ [論理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイのベストプラクティス](#blue-green-deployments-best-practices-postgres-logical)
#### RDS for PostgreSQL のブルー/グリーンデプロイの一般的なベストプラクティス
RDS for PostgreSQL DB インスタンスからブルー/グリーンデプロイを作成するときは、次の一般的なベストプラクティスを考慮してください。
+ ブルー/グリーンデプロイを作成するときには、すべての PostgreSQL 拡張機能を最新バージョンに更新してください。詳細については、「[RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)」を参照してください。
+ トランザクションの実行時間が長いと、レプリカの遅延が大きくなる可能性があります。レプリカの遅延を減らすには、以下を検討します。
+ グリーン環境がブルー環境に追いつくまで、遅延が発生する可能性があり長時間実行されるトランザクションを減らします。
+ グリーン環境がブルー環境に追いつくまで、ブルー環境での一括オペレーションを減らします。
+ ブルー/グリーンデプロイを作成する前に、ビジーテーブルで手動バキュームフリーズオペレーションを開始します。
+ PostgreSQL バージョン 12 以降では、大きなテーブルまたはビジーテーブルで `index_cleanup` パラメータを無効にして、ブルーデータベースの通常のメンテナンスのレートを高くします。詳細については、「[テーブルをできるだけ早くバキューム処理する](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)」を参照してください。
**注記**
バキューム中にインデックスのクリーンアップを定期的にスキップすると、インデックスが肥大化し、スキャンパフォーマンスが低下する可能性があります。ベストプラクティスとして、このアプローチはブルー/グリーンデプロイの使用時にのみ使用してください。デプロイが完了したら、インデックスの定期的なメンテナンスとクリーンアップを再開することをお勧めします。
+ レプリケーションが遅い場合、送信者と受信者が頻繁に再起動し、同期が遅れる可能性があります。送信者と受信者が再起動しないようにするには、ブルー環境で `wal_sender_timeout` パラメータを `0` に設定し、グリーン環境で `wal_receiver_timeout` パラメータを `0` に設定してタイムアウトを無効にします。
+ ブルー環境からログ先行書き込み (WAL) セグメントが削除されないようにするには、PostgreSQL バージョン 13 以前では `wal_keep_segments` パラメータを 15625 に設定します。バージョン 14 以降では、十分な空きストレージ容量がある場合は、`wal_keep_size` パラメータを 1 TiB に設定します。
#### 物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイのベストプラクティス
物理レプリケーションを使用して、Amazon RDS はソース DB インスタンスのリードレプリカを作成します。関連するパラメータ、モニタリング、チューニング、トラブルシューティングについては、「[Amazon RDS for PostgreSQL でのリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.md)」を参照してください。
ブルー/グリーンデプロイが論理レプリケーションではなく物理レプリケーションを使用する状況については、「[ブルー/グリーンデプロイの PostgreSQL レプリケーション方法](blue-green-deployments-replication-type.md)」を参照してください。
#### 論理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイのベストプラクティス
論理レプリケーションを使用するブルー/グリーンデプロイを作成するときは、次のベストプラクティスを考慮してください。ブルー/グリーンデプロイが物理レプリケーションではなく論理レプリケーションを使用する状況については、「[ブルー/グリーンデプロイの PostgreSQL レプリケーション方法](blue-green-deployments-replication-type.md)」を参照してください。
+ データベースが に十分な空きメモリがある場合は、ブルー環境の `logical_decoding_work_mem` DB パラメータの値を増やします。そうすることで、ディスク上でのデコード回数が減り、代わりにメモリを消費します。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)をご参照ください。
+ `ReplicationSlotDiskUsage` CloudWatch メトリクスを使用して、ディスクに書き込まれるトランザクションのオーバーフローをモニタリングできます。このメトリクスは、レプリケーションスロットのディスク使用状況に関するインサイトを提供し、トランザクションデータがメモリ容量を超えてディスクに保存されるタイミングを特定するのに役立ちます。`FreeableMemory` CloudWatch メトリクスを使用して空きメモリをモニタリングできます。詳細については、「[Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス](rds-metrics.md#rds-cw-metrics-instance)」を参照してください。
+ RDS for PostgreSQL バージョン 14 以降では、`[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` システムビューを使用して論理オーバーフローファイルのサイズをモニタリングできます。
+ `aws_s3` 拡張機能を使用している場合は、グリーン環境が作成された後に、必ず IAM ロールを通じてグリーン DB インスタンスに Amazon S3 へのアクセスを許可してください。これにより、インポートコマンドとエクスポートコマンドは、スイッチオーバー後も機能し続けることができます。手順については、「[Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md)」を参照してください。
+ UPDATE ステートメントと DELETE ステートメントのパフォーマンスを確認し、WHERE 句で使用する列にインデックスを作成することで、これらのクエリを最適化できるかどうかを評価します。これにより、グリーン環境でオペレーションを再生するときのパフォーマンスを向上させることができます。
+ トリガーを使用する場合は、名前が「rds」で始まる `pg_catalog.pg_publication`、`pg_catalog.pg_subscription`、`pg_catalog.pg_replication_slots` オブジェクトの作成、更新、削除を妨げないようにしてください。
+ グリーン環境でより上位のエンジンバージョンを指定する場合は、すべてのデータベースに対して `ANALYZE` オペレーションを実行して `pg_statistic` テーブルを更新します。Optimizer の統計情報はメジャーバージョンのアップグレード時に転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。メジャーバージョンアップグレード時のその他のベストプラクティスについては、「[RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)」を参照してください。
+ ソースでトリガーを使用してデータを操作している場合は、トリガーを `ENABLE REPLICA` または `ENABLE ALWAYS` として設定しないでください。レプリケーションシステムが変更を伝播してトリガーを実行し、重複を引き起こします。
# ブルー/グリーンデプロイの PostgreSQL レプリケーション方法
Amazon RDS for PostgreSQL は、ブルー/グリーンデプロイに主に物理レプリケーションを使用します。ただし、ブルー/グリーンデプロイの作成時にメジャーバージョンアップグレードをリクエストし、ソース DB インスタンスが次の表に示す PostgreSQL バージョンのいずれかを実行する場合、Amazon RDS は代わりに論理レプリケーションを使用します。
次の表は、Amazon RDS が PostgreSQL ブルー/グリーンデプロイで物理レプリケーションを使用する状況と論理レプリケーションを使用する状況を示しています。
| ソース PostgreSQL DB インスタンスのバージョン | ブルー/グリーンデプロイのアップグレードアクション | レプリケーション方法 |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-replication-type.html) | メジャーバージョンアップグレード(ブルーより上位のメジャーエンジンバージョンのグリーンインスタンス) | 論理レプリケーション |
| サポートされている全バージョン | マイナーバージョンアップグレード、またはアップグレードなし(ブルーと同じメジャーエンジンバージョンのグリーンインスタンス) | 物理レプリケーション。 |
**注記**
メジャーバージョンのアップグレードは、ソース RDS for PostgreSQL バージョン 15.3 以前、14.8 以前、13.11 以前、12.15 以前、11.20 以前のブルー/グリーンデプロイではサポートされていません。
物理レプリケーションと論理レプリケーションを使用するブルー/グリーンデプロイの制限については、以下のセクションを参照してください。
+ [物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)
+ [論理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-logical)