ブルー/グリーンデプロイのベストプラクティス

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

一般的なベストプラクティス

• 切り替える前に、Aurora DB クラスターをグリーン環境で十分にテストしてください。

• グリーン環境のデータベースは読み取り専用のまま維持してください。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作の有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。

• ブルー/グリーンデプロイを使用してスキーマの変更を実装する場合は、レプリケーション互換の変更のみを行ってください。

  例えば、ブルーデプロイからグリーンデプロイへのレプリケーションを中断することなく、テーブルの最後に新しい列を追加することができます。ただし、列名の変更やテーブル名の変更などのスキーマの変更は、グリーンデプロイへのレプリケーションを中断させます。

  レプリケーションと互換性のある変更の詳細については、MySQL ドキュメントの「ソースとレプリカのテーブル定義が異なるレプリケーション」と PostgreSQL 論理レプリケーションドキュメントの「制限」を参照してください。

• 両方の環境のすべての接続に、クラスターエンドポイント、リーダーエンドポイント、またはカスタムエンドポイントを使用します。静的リストまたは除外リストのあるインスタンスエンドポイントやカスタムエンドポイントは使用しないでください。

• ブルー/グリーンデプロイメントを切り替えるときは、切り替えのベストプラクティスに従ってください。詳しくは、「切り替えのベストプラクティス」を参照してください。

Aurora PostgreSQL のベストプラクティス

• Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュをモニタリングし、必要に応じてキャッシュバッファを調整します。詳しくは、「Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング」を参照してください。

• データベースが に十分な空きメモリがある場合は、ブルー環境の logical_decoding_work_mem DB パラメータの値を増やします。そうすることで、ディスク上でのデコード回数が減り、代わりにメモリを消費します。FreeableMemory CloudWatch メトリクスを使用して空きメモリをモニタリングできます。詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。

• ブルー/グリーンデプロイを作成するときには、すべての PostgreSQL 拡張機能を最新バージョンに更新してください。詳細については、「PostgreSQL 拡張機能のアップグレード」を参照してください。

• aws_s3 拡張機能を使用している場合は、グリーン環境が作成された後に、必ず IAM ロールを通じてグリーン DB クラスターに Amazon S3 へのアクセスを許可してください。これにより、インポートコマンドとエクスポートコマンドは、スイッチオーバー後も機能し続けることができます。手順については、「Amazon S3 バケットへのアクセスを設定する」を参照してください。

• グリーン環境でより上位のエンジンバージョンを指定する場合は、すべてのデータベースに対して ANALYZE オペレーションを実行して pg_statistic テーブルを更新します。Optimizer の統計情報はメジャーバージョンのアップグレード時に転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。メジャーバージョンアップグレード時のその他のベストプラクティスについては、「メジャーバージョンアップグレードの実行」を参照してください。

• ソースでトリガーを使用してデータを操作している場合は、トリガーを ENABLE REPLICA または ENABLE ALWAYS として設定しないでください。レプリケーションシステムが変更を伝播してトリガーを実行し、重複を引き起こします。

• トランザクションの実行時間が長いと、レプリカの遅延が大きくなる可能性があります。レプリカの遅延を減らすには、以下を検討します。

  • グリーン環境がブルー環境に追いつくまで、遅延が発生する可能性があり長時間実行されるトランザクションを減らします。

  • ブルー/グリーンデプロイを作成する前に、ビジーテーブルで手動バキュームフリーズオペレーションを開始します。

  • PostgreSQL バージョン 12 以降では、大きなテーブルまたはビジーテーブルで index_cleanup パラメータを無効にして、ブルーデータベースの通常のメンテナンスのレートを高くします。

• レプリケーションが遅い場合、送信者と受信者が頻繁に再起動し、同期が遅れる可能性があります。送信者と受信者が再起動しないようにするには、ブルー環境で wal_sender_timeout パラメータを 0 に設定し、グリーン環境で wal_receiver_timeout パラメータを 0 に設定してタイムアウトを無効にします。

• ソース 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 クラスターパラメータグループ設定」を参照してください。