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

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

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

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

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

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

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

  • ブルー/グリーンデプロイでは、AWS Secrets Manager を使用したマスターユーザーのパスワード管理はサポートされていません。

  • ブルーデータベースで専用ログボリューム (DLV) が有効になっている場合は、リードレプリカを含むすべての DB インスタンスで有効にする必要があります。

  • 切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。

  • ブルー/グリーンデプロイを作成するときには、グリーン環境でイベントスケジューラー (event_scheduler パラメーター) を無効にする必要があります。これにより、グリーン環境でイベントが生成されて不整合が発生するのを防ぐことができます。

  • 暗号化されていない DB インスタンスを暗号化された DB インスタンスに変更することはできません。さらに、暗号化された DB インスタンスを暗号化されていない DB インスタンスに変更することはできません。

  • ブルーの DB インスタンスを、対応するグリーンの DB インスタンスよりも上位のエンジンバージョンに変更することはできません。

  • ブルー環境とグリーン環境のリソースは同じ AWS アカウント にある必要があります。

  • ブルー/グリーンデプロイは、以下の機能ではサポートされていません。

    • Amazon RDS Proxy

    • カスケードリードレプリカ

    • クロスリージョンリードレプリカ

    • AWS CloudFormation

    • マルチ AZ DB クラスターのデプロイ

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

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

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

  • MySQL バージョン 8.0.11 から 8.0.13 には、これらがブルー/グリーンデプロイをサポートできないというコミュニティバグがあります。

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

  • ソースデータベースがカスタムオプショングループに関連付けられている場合、ブルー/グリーンデプロイを作成するときにメジャーバージョンアップグレードを指定することはできません。

    この場合、メジャーバージョンアップグレードを指定せずにブルー/グリーンデプロイを作成できます。その後、グリーン環境のデータベースをアップグレードできます。(詳しくは、「DB インスタンスのエンジンバージョンのアップグレード」を参照してください。)

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

ブルー/グリーンデプロイの RDS for PostgreSQL の制限

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

  • アップグレードソースおよびターゲットバージョンとして、11.21 以降、12.16 以降、13.12 以降、14.9 以降、15.4 以降、16.1 以降のバージョンの RDS for PostgreSQL がサポートされています。下位バージョンでは、サポートされているバージョンへのマイナーバージョンアップグレードを実行できます。

  • 。

  • ブルーの DB インスタンスを自己管理の論理ソース (パブリッシャー) またはレプリカ (サブスクライバー) にすることはできません。

  • ブルー DB インスタンス が外部データラッパー (FDW) 拡張機能の外部サーバーとして設定されている場合は、IP アドレスの代わりにインスタンスエンドポイント名を使用する必要があります。これにより、スイッチオーバー後も設定は機能し続けます。

  • ブルー/グリーンデプロイでは、各データベースに論理レプリケーションスロットが必要です。データベースの数が増えると、特に DB インスタンスが十分にスケーリングされていない場合、リソースのオーバーヘッドが増加し、レプリケーションの遅延につながる可能性があります。影響は、データベースワークロードや接続数などの要因によって異なります。影響を軽減するには、DB インスタンスクラスをスケールアップするか、ソースインスタンスのデータベース数を減らすことを検討してください。

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

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

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

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

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

ブルー/グリーンデプロイでは、論理レプリケーションを使用してステージング環境と運用環境の同期を保ちます。PostgreSQL には、論理レプリケーションに関連する特定の制約事項があります。これは、 RDS for PostgreSQL DB インスタンスのブルー/グリーンデプロイを作成する際の制約となります。

次の表では、 RDS for PostgreSQL のブルー/グリーンデプロイメントに適用される論理レプリケーションの制約事項について説明しています。

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

Amazon RDS がブルーの環境で DDL の変更を検出すると、グリーンデータベースはレプリケーションが低下した状態になります。

ブルー環境での DDL の変更を緑の環境にレプリケートできないことを通知するイベントを受け取ります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。そうしないと、ブルー/グリーンデプロイに切り替えることができません。
シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。

スイッチオーバー中、 Amazon RDS はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。
ブルー環境での大きなオブジェクトの作成や変更は、グリーン環境にはレプリケートされません。

Amazon RDS が、pg_largeobject システムテーブルに保存されているブルー環境でラージオブジェクトの作成または変更を検出すると、グリーンデータベースはレプリケーションが低下したの状態になります。

RDS は、ブルー環境での大きなオブジェクトの変化をグリーン環境にレプリケートできないことを通知するイベントを生成します。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。そうしないと、ブルー/グリーンデプロイに切り替えることができません。

マテリアライズドビューはグリーン環境では自動的に更新されません。

ブルー環境でマテリアライズドビューを更新しても、グリーン環境では更新されません。スイッチオーバー後、REFRESH MATERIALIZED VIEW コマンドを使用して手動で更新することも、更新をスケジュールすることもできます。

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

ブルー/グリーンデプロイを作成する前に、 DB インスタンスのすべてのテーブルにプライマリキーがあることを確認してください。

詳細については、PostgreSQL の論理レプリケーションドキュメントの「制限」を参照してください。

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

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

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

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

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

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

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

  • AWS Backup を使用してブルー/グリーンデプロイのリソースの自動バックアップを管理する場合は、切り替え後に AWS Backup で使用するリソース ID を調整します。(詳しくは、「自動バックアップの管理に AWS Backup を使用する」を参照してください。)

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

  • 以前のブルー環境 DB インスタンスの自動バックアップを記述する場合や、ある時点に復元する場合は、操作のリソース ID を使用します。

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

    (詳しくは、「特定の時点への DB インスタンスの復元」を参照してください。)

  • ブルー/グリーンデプロイのグリーン環境の DB インスタンスにリードレプリカを追加する場合、切り替え時にブルー環境のリードレプリカが新しいリードレプリカに置き換えられることはありません。ただし、新しいリードレプリカは、切り替え後も新しい本稼働環境に保持されます。

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

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

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

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

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

    同じ動作が DB インスタンスとリードレプリカにも当てはまります。