Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項 - Amazon Aurora
制限考慮事項

Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項

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

ブルー/グリーンデプロイの制限事項

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

ブルー/グリーンデプロイの一般的な制約事項

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

  • ブルー/グリーンデプロイの一部であるクラスターを停止および開始することはできません。

  • ブルー/グリーンデプロイでは、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 クラスター

    • Aurora Global Database の一部である DB クラスター。

    • AWS CloudFormation

ブルー/グリーンデプロイの Aurora MySQL の制限

Aurora MySQL ブルー/グリーンデプロイには、以下の制限事項が適用されます。

  • ソース DB クラスターには tmp という名前のデータベースを含めることはできません。この名前のデータベースはグリーン環境にコピーされません。

  • ブルーの DB クラスターを外部のバイナリログレプリカにすることはできません。

  • バックトラックが有効になっているソース DB クラスターの場合、グリーン DB クラスターはバックトラックのサポートなしで作成されます。バックトラックは、ブルー/グリーンデプロイに必須のバイナリログ (binlog) レプリケーションでは機能しないためです。詳細については、「Aurora DB クラスターのバックトラック」を参照してください。

  • ブルー/グリーンデプロイは MySQL 用の AWS JDBC ドライバーをサポートしていません。詳細については、GitHub の「既知の制限事項」を参照してください。

Aurora PostgreSQL のブルー/グリーンデプロイの制限事項

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

  • ブルー DB クラスターで rds.logically_replicate_unlogged_tables パラメータが 1 に設定されていない限り、ログに記録されていないテーブルはグリーン環境にレプリケートされません。ブルー/グリーンデプロイを作成した後は、ログに記録されていないテーブルでレプリケーションエラーが発生するのを避けるため、このパラメータ値を変更しないでください。

  • ブルー 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 実行プランのキャプチャ」を参照してください。

  • グリーン環境の論理的なレプリケーション適用プロセスは、シングルスレッドです。ブルー環境が大量の書き込みトラフィックを生成した場合、グリーン環境は維持できない可能性があります。これにより、特に書き込みスループットが継続的に高いワークロードでは、レプリケーションの遅延や障害が発生する可能性があります。ワークロードを徹底的にテストしてください。メジャーバージョンのアップグレードが必要で、大量の書き込みワークロードを処理するシナリオでは、AWS Database Migration Service (AWS DMS) やセルフマネージド論理レプリケーションなどの代替アプローチを検討してください。

  • Aurora のブルー/グリーンデプロイでは、パーティションテーブルでの新しいパーティションの作成はサポートされていません。新しいパーティションの作成には CREATE TABLE などのデータ定義言語 (DDL) オペレーションが含まれますが、これらはブルー環境からグリーン環境にレプリケートされません。ただし、既存のパーティションテーブルとそのデータはグリーン環境にレプリケートされます。

  • 以下の制約事項が PostgreSQL 拡張機能に適用されます。

    • ブルー/グリーンデプロイを作成するときは、ブルー環境で pg_partman 拡張機能を無効にする必要があります。この拡張機能は CREATE TABLE などの DDL オペレーションを実行します。これは、ブルー環境からグリーン環境への論理レプリケーションを中断します。

    • ブルー/グリーンデプロイを作成した後は、すべてのグリーンデータベースで pg_cron 拡張機能を無効のままにしておく必要があります。この拡張機能には、スーパーユーザーとして実行されるバックグラウンドワーカーがあり、グリーン環境の読み取り専用設定をバイパスするため、レプリケーションの競合が発生する可能性があります。

    • ブルー環境で同じプランが取り込まれた場合、プライマリキーの競合が発生しないように、apg_plan_mgmt 拡張機能の apg_plan_mgmt.capture_plan_baselines パラメータをすべてのグリーンデータベースで off に設定する必要があります。詳細については、「Aurora PostgreSQL のクエリプラン管理の概要」を参照してください。

    • ブルー/グリーンデプロイを作成するときには、ブルー環境で pglogical および pgactive 拡張機能を無効にする必要があります。グリーン環境を新しい本番稼働環境にスイッチオーバーしたら、拡張機能を再度有効にできます。また、ブルーデータベースは外部インスタンスの論理サブスクライバーにはなれません。

    • pgAudit 拡張機能を使用している場合は、ブルー DB インスタンスとグリーン DB インスタンスの両方のカスタム DB パラメータグループの共有ライブラリ (shared_preload_libraries) に残っている必要があります。詳細については、「pgAudit 拡張機能のセットアップ」を参照してください。

ブルー/グリーンデプロイの論理レプリケーション固有の制限事項

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

次の表では、Aurora PostgreSQL のブルー/グリーンデプロイメントに適用される論理レプリケーションの制約事項について説明しています。詳細については、PostgreSQL の論理レプリケーションドキュメントの「制限」を参照してください。

制限 説明
CREATE TABLE や CREATE SCHEMA などのデータ定義言語 (DDL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。

Aurora がブルーの環境で DDL の変更を検出すると、グリーンデータベースはレプリケーションが低下した状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。
GRANT や REVOKE などのデータ制御言語 (DCL) ステートメントは、ブルー環境からグリーン環境にはレプリケートされません。

Aurora がブルー環境で DCL ステートメントを実行しようとすると、警告メッセージが表示されます。この動作はブルー/グリーンデプロイプロセスの制限であるため、変更できる設定や API はありません。
シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。

スイッチオーバー中、Aurora はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。
ブルー環境のラージオブジェクトは、グリーン環境にはレプリケートされません。これには、既存のラージオブジェクトと、ブルー/グリーンデプロイプロセス中に新しく作成または変更したラージオブジェクトの両方が含まれます。

Aurora が、pg_largeobject システムテーブルに保存されているブルー環境でラージオブジェクトの作成または変更を検出すると、グリーンデータベースはレプリケーションが低下したの状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。

マテリアライズドビューを更新すると、レプリケーションが中断されます。

ブルー環境でマテリアライズドビューを更新すると、グリーン環境へのレプリケーションが中断されます。ブルー環境でマテリアライズドビューを更新しないようにします。スイッチオーバー後、REFRESH MATERIALIZED VIEW コマンドを使用して手動で更新することも、更新をスケジュールすることもできます。

UPDATE および DELETE オペレーションは、プライマリキーのないテーブルでは許可されません。

ブルー/グリーンデプロイを作成する前に、すべてのテーブルにプライマリキーがあるか、または REPLICA IDENTITY FULL を使用していることを確認してください。ただし、プライマリキーまたは一意のキーが存在しない場合は、レプリケーションのパフォーマンスに影響するため、REPLICA IDENTITY FULL のみを使用してください。詳細については、PostgreSQL ドキュメントをご参照ください。

ブルー/グリーンデプロイの考慮事項

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 コールのモニタリング」を参照してください。

  • ブルー環境のリソースにデータベースアクティビティストリームを使用する場合は、切り替え後に新しいストリームのデータベースイベントをモニタリングするようにアプリケーションを調整します。詳細については、「データベースアクティビティストリームでサポートされているリージョンと Aurora DB エンジン」を参照してください。

  • パフォーマンスインサイト API を使用する場合は、切り替え後に API への呼び出しでリソース ID を調整します。詳細については、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

    切り替え後に同じ名前のデータベースをモニタリングできますが、切り替え前のデータは含まれていません。

  • IAM ポリシーでリソース ID を使用する場合は、必要に応じて新しく移行したリソースのリソース ID を追加してください。詳細については、「Amazon Aurora での Identity and Access Management」を参照してください。

  • DB クラスターに IAM ロールが関連付けられている場合は、スイッチオーバー後にそれらを再度関連付けます。アタッチされたロールはグリーンの環境に自動的にコピーされません。

  • IAM データベース認証を使用して DB クラスターを認証する場合は、データベースアクセスに使用する IAM ポリシーの Resource 要素の下にブルーとグリーンのデータベースの両方が表示されていることを確認してください。これは、スイッチオーバー後にグリーンのデータベースに接続するために必要です。詳細については、「IAM データベースアクセス用の IAM ポリシーの作成と使用」を参照してください。

  • ブルー/グリーンデプロイに含まれていた DB クラスターの手動 DB クラスタースナップショットを復元する場合は、スナップショットが取られた時間を調べて、正しい DB クラスタースナップショットを復元します。詳細については、「DB クラスタースナップショットからの復元」を参照してください。

  • 切り替え後は、ブルー環境のチェックポイントがグリーン環境で無効であるため、AWS Database Migration Service (AWS DMS) レプリケーションタスクを再開できません。レプリケーションを続行するには、新しいチェックポイントで DMS タスクを再作成する必要があります。

  • Amazon Aurora は、基盤となるブルー環境の Aurora ストレージボリュームをクローニングすることでグリーン環境を作成します。グリーンのクラスターボリュームには、グリーン環境に加えられた増分変更のみが保存されます。ブルー環境の DB クラスターを削除すると、グリーン環境の基盤となる Aurora ストレージボリュームのサイズは、フルサイズまで増大します。詳細については、「Amazon Aurora DB クラスターのボリュームのクローン作成」を参照してください。

  • ブルー/グリーンデプロイのグリーン環境の DB クラスターに DB インスタンスを追加すると、切り替え時にブルー環境の DB インスタンスが新しい DB インスタンスに置き換わることはありません。ただし、新しい DB インスタンスは DB クラスターに残り、新しい本稼働環境の DB インスタンスになります。

  • ブルー/グリーンデプロイのグリーン環境で DB クラスターの DB インスタンスを削除すると、ブルー/グリーンデプロイで代わりになる新しい DB インスタンスを作成することはできません。

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

    グリーン環境で DB クラスター内の DB インスタンスを削除すると、次のような動作になります。

    • ブルー環境に同じ名前の DB インスタンスが存在する場合、グリーン環境の DB インスタンスに切り替わりません。この DB インスタンスの名前は、DB インスタンス名に -oldn を付加することによって変更されません。

    • ブルー環境の DB インスタンスを参照するアプリケーションは、切り替え後も同じ DB インスタンスを引き続き使用します。