# Amazon Aurora のブルー/グリーンデプロイのベストプラクティス
<a name="blue-green-deployments-best-practices"></a>

ブルー/グリーンデプロイのベストプラクティスを以下に示します。

**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)

## ブルー/グリーンデプロイの一般的なベストプラクティス
<a name="blue-green-deployments-best-practices-general"></a>

ブルー/グリーンデプロイを作成するときは、次の一般的なベストプラクティスを考慮してください。
+ 切り替える前に、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 のブルー/グリーンデプロイのベストプラクティス
<a name="blue-green-deployments-best-practices-mysql"></a>

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 のブルー/グリーンデプロイのベストプラクティス
<a name="blue-green-deployments-best-practices-postgres"></a>

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\_stat\_replication\_slots](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\_status
  + babelfishpg\_tds.tds\_default\_numeric\_precision
  + babelfishpg\_tds.tds\_default\_numeric\_scale
  + babelfishpg\_tsql. default\_locale
  + babelfishpg\_tsql.migration\_mode
  + babelfishpg\_tsql.server\_collation\_name

  これらのパラメータの詳細については、「[Babelfish の DB クラスターパラメータグループ設定](babelfish-configuration.md)」を参照してください。

## Aurora Global Database のブルー/グリーンデプロイのベストプラクティス
<a name="blue-green-deployments-best-practices-agd"></a>

上記の一般的なベストプラクティスとエンジン固有のベストプラクティスに加えて、Aurora Global Database の以下のベストプラクティスを検討してください。
+ 次の CloudWatch メトリクスをモニタリングして、本番環境でのアクティビティが少ない期間を特定します。
  + `DatabaseConnections`
  + `ActiveTransactions`

  ブルー/グリーンスイッチオーバーは、計画されたメンテナンスウィンドウ中またはアクティビティが少ない期間にスケジュールします。
+ ブルー/グリーンスイッチオーバー期間は、ワークロードとセカンダリリージョンの数によって異なります。ブルー/グリーンスイッチオーバーを開始すると、サービスはレプリカの遅延がゼロになるまで待機してから続行します。スイッチオーバーを開始する前に、レプリカの遅延を確認することをお勧めします。
+ グリーン環境のデフォルト以外の DB パラメータまたは DB クラスターパラメータグループを使用する場合は、ブルー/グリーンデプロイを開始する前に、すべてのセカンダリリージョンで同じ名前の必要なパラメータグループを作成します。