Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

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

フォーカスモード
Amazon RDS のブルー/グリーンデプロイの制限と考慮事項 - 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 配置については、「Amazon RDS でのマルチ AZ 配置の設定と管理」を参照してください。

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

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

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

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

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

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

物理レプリケーションを使用した RDS for PostgreSQL のブルー/グリーンデプロイの制限事項

物理レプリケーションを使用する RDS for PostgreSQL ブルー/グリーンデプロイには、次の制限が適用されます。ブルー/グリーンデプロイが論理レプリケーションではなく物理レプリケーションを使用する状況については、「ブルー/グリーンデプロイの PostgreSQL レプリケーション方法」を参照してください。

  • グリーン環境の作成後は、メジャーバージョンアップグレードを手動で実行することはできません。

  • 物理レプリケーションを使用するブルー/グリーンデプロイは、厳密に読み取り専用であるため、グリーン環境でのスキーマの変更をサポートしていません。

論理レプリケーションを使用したRDS for PostgreSQL のブルー/グリーンデプロイの制限事項

論理レプリケーションを使用する RDS for PostgreSQL のブルー/グリーンデプロイには、次の制限が適用されます。ブルー/グリーンデプロイが物理レプリケーションではなく論理レプリケーションを使用する状況については、「ブルー/グリーンデプロイの PostgreSQL レプリケーション方法」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

Amazon RDS がブルーの環境で DDL の変更を検出すると、グリーンデータベースはレプリケーションが低下した状態になります。ブルー/グリーンデプロイとすべてのグリーンデータベースを削除してから再作成する必要があります。

シーケンスオブジェクトに対する NEXTVAL オペレーションは、ブルー環境とグリーン環境では同期されません。

スイッチオーバー中、 Amazon RDS はグリーン環境のシーケンス値をブルー環境のシーケンス値と一致するようにインクリメントします。シーケンスが数千ある場合、スイッチオーバーが遅れる可能性があります。

ブルー環境での大きなオブジェクトの作成や変更は、グリーン環境にはレプリケートされません。

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

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

ブルー環境でマテリアライズドビューを更新しても、グリーン環境では更新されません。スイッチオーバー後、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 を調整します。詳細については、「Amazon RDS の自動バックアップの管理に AWS Backup を使用する」を参照してください。

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

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

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

    詳細については、「Amazon RDS の DB インスタンスを特定の時点に復元する」を参照してください。

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

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

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

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

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

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

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

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

このページの内容

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.