Amazon Web Services ブログ

Amazon RDS ブルー/グリーン デプロイを使用した Amazon Aurora PostgreSQL アップグレードのロールバック戦略の実装

本記事は、2025 年 6 月 20 日に公開された Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments を翻訳したものです。翻訳は Cloud Support Engineer の野島 正就が担当しました。

Amazon Aurora PostgreSQL 互換エディション は、高いパフォーマンスと可用性を実現するために設計されたフルマネージドのリレーショナルデータベースエンジンで、更新時のダウンタイムの削減とリスクの最小化を支援するマネージドなブルー/グリーンデプロイをサポートしています。ブルー/グリーンデプロイは、論理レプリケーションを使用してフルマネージドのステージング環境を作成し、本番環境の変更を安全にデプロイおよびテストできるようにします。ブルー環境は現在の本番データベースです。グリーン環境には必要な更新や変更が含まれていますが、アプリケーションエンドポイントを変更する必要はありません。このアプローチにより、エンジンバージョンのアップグレードやシステムパッチなどの更新に伴うリスクとダウンタイムを最小限に抑えることができます。検証が完了したら、アプリケーションエンドポイントの変更なしにグリーン環境をシームレスに本番環境に昇格させることができます。

非本番環境で入念に計画とテストを行ったとしても、バージョンアップグレード後に予期しない問題が発生することがあります。例えば、新しいスキーマ変更がステージング環境では完璧に動作しても、本番環境では実際のデータパターンの違いやテスト中に実行されなかったアプリケーションクエリが原因でエラーが発生する場合があります。また、実際のトラフィックやワークロードによってパフォーマンスが低下することもあります。このような場合、サービスの安定性を迅速に復旧するためにロールバック計画を用意しておくことが不可欠です。ブルー/グリーンデプロイ機能には現在組み込みのロールバック機能はありませんが、バージョン管理のための代替ソリューションを実装することができます。

この記事では、Amazon RDS ブルー/グリーンデプロイの切り替え後に、セルフマネージドな論理レプリケーションを使用してロールバッククラスターを手動でセットアップし、新しいバージョンとの同期を維持する方法を紹介します。ロールバッククラスターは、元のバージョンに戻す必要がある場合のバックアップオプションとして機能します。

ソリューションの概要

次の図は、このソリューションの高レベルなワークフローを示しています。

スイッチオーバーの前には、2 つのクラスターがあります:

  • ブルークラスター – 既存の本番データベースクラスター
  • グリーンクラスター – ブルークラスターからミラーリングおよび同期されたステージング環境

スイッチオーバー後、3 つのクラスターが存在します:

  • 旧ブルークラスター – 元の本番クラスター (以前のブルークラスター)
  • 新ブルークラスター – 本番クラスターの新バージョンで、ワークロードが実行される場所 (以前のグリーンクラスター)
  • ブループライマリ (ロールバック) クラスター – 旧ブルークラスターのクローンで、新ブルークラスターのデータと同期されたもの (ロールバッククラスターとして使用されます)

ワークフローのステップは以下のとおりです:

  1. ブルー/グリーンデプロイを作成します
  2. ブルークラスターへのトラフィックを停止しグリーンクラスターへのスイッチオーバーを実行します
  3. ブルー/グリーンデプロイを削除します
  4. 旧ブルークラスターをクローンして、ブループライマリ (ロールバック) クラスターを作成します
  5. 新しいブルークラスターからブループライマリ (ロールバック) クラスターへの論理レプリケーションを設定します
  6. 新しいブルークラスターへのトラフィックを開始します

この記事では、Amazon Aurora PostgreSQL 互換エディション のメジャーバージョンアップグレード (バージョン 15.10 から 16.6 へ) をシミュレーションします。

制限事項

  1. Aurora ブルー/グリーンデプロイは DDL、シーケンス、マテリアライズドビューのリフレッシュ、ラージオブジェクトの作成や変更、プライマリキーのないテーブルでのデータの更新や削除をレプリケートしません。詳細については、Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項を参照してください。
  2. Aurora ブルー/グリーンデプロイはスイッチオーバー後にプライマリクラスターエンドポイントを自動的に管理しますが、以前のバージョンへのロールバックが必要な場合は、アプリケーションまたは DNS レベルでエンドポイントの変更を処理する必要があります。
  3. ロールバッククラスターのセットアップには追加のダウンタイムが発生します。

前提条件

このソリューションを実装するには、以下のコンポーネントが必要です:

注意: 論理レプリケーションパラメータを有効にするには、ライターインスタンスの再起動が必要です。詳細については、Aurora PostgreSQL DB クラスターの論理レプリケーションの設定を参照してください。

  • 新しいバージョンのデータベース用のクラスターパラメータグループ: 新しいバージョンから古いバージョンへの論理レプリケーションを設定するため、新しいバージョン (Aurora PostgreSQL 16) で論理レプリケーションが有効になっていることを確認する必要があります。以下の AWS CLI コマンドでクラスターパラメータグループを作成し、論理レプリケーションパラメータを有効にします。 
    aws rds create-db-cluster-parameter-group \ 
   --db-cluster-parameter-group-name pg16-blue-green \ 
   --db-parameter-group-family aurora-postgresql16 \ 
   --description "Parameter group that contains logical replication settings for Aurora PG 16" 

aws rds modify-db-cluster-parameter-group \ 
   --db-cluster-parameter-group-name pg16-blue-green \ 
   --parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot"
  • Aurora のクローン機能については Amazon Aurora DB クラスターのボリュームのクローン作成を参照してください。

ブルー/グリーンデプロイの作成

Amazon RDS ブルー/グリーンデプロイは AWS によって管理されます。内部的には、ブルー環境からグリーン環境にリソースを作成してミラーリングし、ネイティブの論理レプリケーションを使用してブルー環境からグリーン環境に DML の変更をレプリケートします。

AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで RDS ブルー/グリーンデプロイを作成できます。ここで source は本番データベースの Amazon Resource Name (ARN) です。以下の RDS コンソールのスクリーンショットは、論理レプリケーションが有効になっている既存のクラスター (ブルークラスター) を示しています。

以下のコマンドを使用して、Amazon Aurora PostgreSQL バージョン 16 のグリーンクラスターを持つブルー/グリーンデプロイを作成します。グリーンクラスターには、事前に作成した論理レプリケーション用の適切なパラメータグループをアタッチする必要があります。

aws rds create-blue-green-deployment \ 
   --blue-green-deployment-name my-blue-green-deployment \ 
   --source arn:aws:rds:{REGION}:{ACCOUNT_NUMBER}:cluster:{CLUSTER_ID} \ 
   --target-engine-version 16.6 \ 
   --target-db-cluster-parameter-group-name pg16-blue-green

すべてのインスタンスが利用可能になると、ブルークラスターとグリーンクラスターの両方がアタッチされたブルー/グリーンデプロイが完成します。

トラフィックの停止とスイッチオーバーの実行

グリーンクラスターを昇格させるには、スイッチオーバーアクションを開始する必要があります。スイッチオーバーを開始する前に、ブループライマリの作成中のデータ整合性を確保するために、ブルークラスターのデータベーストラフィックを停止してください。VPC セキュリティグループを使用して、インバウンドおよびアウトバウンドのデータベーストラフィックをブロックできます。スイッチオーバーが完了したら、RDS ブルー/グリーンデプロイの更新されたラベルを確認してください。

aws rds switchover-blue-green-deployment \ 
--blue-green-deployment-identifier {BG_RESOURCE_ID}  \ 
--switchover-timeout "300"

ブルー/グリーンデプロイの削除

ブループライマリ (ロールバック) クラスターを設定する前に、ブルー/グリーンデプロイを削除する必要があります。RDS ブルー/グリーンデプロイを削除すると、マネージド環境からクラスターが解放され、Amazon RDS ブルー/グリーンデプロイによって生成されたレプリケーションスロット、パブリケーション、サブスクリプション、論理レプリケーションコンポーネントなどのオブジェクトがクリーンアップされます。

aws rds delete-blue-green-deployment \ 
--blue-green-deployment-identifier {BG_RESOURCE_ID}\ 
--no-delete-target

次のスクリーンショットに示すように、apg-blue-green-demo (v16.6) と apg-blue-green-demo-old1 (v15.10) の 2 つの独立したクラスターが作成されました。

新しいブルークラスターをクローンしてブループライマリ (ロールバック) クラスターを作成

コンプライアンスや監査の目的で、元のブルークラスターを保持する必要がある場合があります。ロールバッククラスターをセットアップするには:

  1. 元のブルークラスターをクローンしてセルフマネージドのブループライマリ (ロールバック) クラスターを作成します
  2. 利用可能になったら、クローンしたクラスターで簡単な読み取り専用クエリを実行して、クラスターとデータへのアクセスを確認します
  3. ロールバックが必要になった場合に備えて、DNS またはアプリケーションのエンドポイント更新用にブループライマリ (ロールバック) クラスターのエンドポイントを記録します
aws rds restore-db-cluster-to-point-in-time  \ 
--db-cluster-identifier "apg15-blue-prime" \ 
--restore-type copy-on-write \ 
--use-latest-restorable-time \ 
--source-db-cluster-identifier "apg-blue-green-demo-old1" \ 
--db-subnet-group-name "{DB_SUBNET}" \ 
--vpc-security-group-ids "{VPC_SECUITY_GROUP}" \ 
--db-cluster-parameter-group-name "pg15-blue-green"
aws rds create-db-instance \ 
--db-instance-identifier "apg15-blue-prime" \ 
--db-instance-class "db.r6g.large" \ 
--db-cluster-identifier "apg15-blue-prime" \ 
--engine "aurora-postgresql" \ 
--engine-version "15.10"

次のスクリーンショットに示すように、ロールバック先となる新しい復元クラスター「apg15-blue-prime」を作成しました。

ブループライマリ (ロールバック) クラスターのセットアップ

ブループライマリのクローンが完了したら、新しいブルークラスター (パブリッシャー) からブループライマリクラスター (サブスクライバー) へのセルフマネージドな論理レプリケーションを設定します。データ同期の問題を防ぐため、書き込みアクティビティやスキーマ変更が行われないようにしてください。

  1. 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントを使用してデータベースに接続し、新しいパブリケーションを作成します: 
    CREATE PUBLICATION publication_name FOR ALL TABLES ;

    重要: 各テーブルにレプリケーションアイデンティティ (プライマリキーやユニークキーなど) があることを確認してください。同じクラスターに複数のデータベースがある場合は、新しく昇格した本番クラスター (新しいブルークラスター) の各データベースに対して以下の手順を繰り返してください。

  2. 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントに接続し、以下のコマンドを使用して ‘pgoutput’ プラグインを使用したレプリケーションスロットを作成します: 
    SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');
  3. ブループライマリクラスター (サブスクライバー) で、以下のコマンドを使用して、データのコピーや新しいスロットの作成を行わずに新しいサブスクリプションを作成します: 
    CREATE SUBSCRIPTION subscription_name
 CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name
 WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

    このコードには以下のパラメータが必要です:

    1. subscription_name – サブスクリプションの名前
    2. admin_user_name – rds_superuser 権限を持つ管理ユーザーの名前
    3. admin_user_password – 管理ユーザーに関連付けられたパスワード
    4. source_instance_URL – パブリケーションサーバーインスタンスの URL
    5. database – サブスクリプションサーバーが接続するデータベース
    6. publication_name – パブリケーションサーバーの名前
    7. replication_slot_name – ステップ 2 で作成したレプリケーションスロットの名前

    重要: ブループライマリクラスター上のすべてのパブリケーション (ステップ 1) に対して、この作業を繰り返す必要があります。

  4. ブループライマリクラスターで、以下のコマンドを使用してサブスクリプションを有効にします: 
    ALTER SUBSCRIPTION subscription_name ENABLE ;

    重要: ブループライマリクラスター上のすべてのサブスクリプションに対して、この作業を繰り返す必要があります。

論理レプリケーションのセットアップが完了し、新しいブルークラスターからブループライマリクラスターへのデータフローを確認した後、既存のクラスターエンドポイントを使用して新しいブルークラスターへのトラフィックを再開できます。Amazon RDS ブルー/グリーンデプロイが DNS の変更を自動的に処理するため、アプリケーションは同じエンドポイントを引き続き使用できます。

ブループライマリクラスターへのロールバック

ブループライマリクラスター (元のバージョン) にロールバックする必要がある場合は、以下の手順に従ってください。

  1. 移行中のデータ整合性を維持するためにアプリケーショントラフィックを停止します (Amazon Aurora VPC セキュリティグループを使用して受信トラフィックをブロックできます)
  2. アプリケーションまたは DNS レコードを更新して、ブループライマリクラスターのエンドポイントを指すようにします
  3. ブループライマリクラスターのサブスクリプションを削除します
  4. 該当する場合はシーケンス値を手動で更新します

この切り替えは自動ではありません。ブループライマリクラスターはマネージドサービスの管理下にないためです。実行時のエラーを最小限に抑えるために、ロールバック手順のランブックまたは自動化スクリプトを作成することをお勧めします。

この戦略はロールバックオプションを提供しますが、ブループライマリクラスターのセットアップ時に追加のダウンタイムが発生します。このアプローチを実装する際に考慮すべきトレードオフであり、本番環境に移行する前にステージング環境で十分にテストすることを推奨します。

クリーンアップ

本番環境では、すべてのアプリケーションが正常に移行されたことを検証する間、新しいブループライマリクラスターを維持する必要があります。両方の環境を同時に稼働させておくことで、新しいインフラストラクチャで何か不整合や予期しない動作が発生した場合にロールバックできることが保証されます。コンプライアンス目的で旧ブルークラスターをバックアップした後、コスト削減のためにクラスターを削除できます。すべてのクラスターは削除されるまで課金されます。

テスト目的でこれらのリソースを作成した場合は、追加料金が発生しないように、すべてのクラスター (ブルー、グリーン、ブループライマリ) を削除する必要があります。データベースクラスターをクリーンアップするには、以下の手順を実行してください。

  1. リードレプリカインスタンスがあれば、それぞれを削除します。
  2. プライマリインスタンスを削除します。
  3. データベースクラスターを削除します。

まとめ

この記事では、Amazon RDS ブルー/グリーンデプロイを使用してデータベースバージョンのアップグレードを行う際のロールバック戦略の作成方法を紹介しました。安全性を高めるために、ロールバック戦略として論理レプリケーションを設定しました。ブルー/グリーンデプロイは、ミラーリングされた同期済みのデータベースステージングバージョンの作成、ガードレールチェックの実行、スイッチオーバーの実施、DNS 変更の自動化など、多くの複雑なタスクを自動的に処理します。しかし、本番データベースの変更には、アプリケーションの非互換性などのリスクが伴う可能性があります。ロールバッククラスターを設定しておくことで、アップグレード後に問題が発生した場合に迅速にフォールバックできる追加の安全策が得られます。問題が解決されるまで、以前の本番バージョンに戻すことができます。

本番ワークロードを切り替える前に、本番レベルの負荷をかけた状態で新しいデータベースバージョンに対してアプリケーションを十分にテストしてください。アプリケーションが完全に互換性があり、パフォーマンスが安定していることを確認してください。これにより、ブルー/グリーンデプロイの切り替え後にアプリケーションの問題やパフォーマンス低下が発生する可能性を大幅に減らすことができます。このロールバック戦略を実装する前に、RDS ブルー/グリーンデプロイの仕組みと機能について確認することから始めることをお勧めします。

Chirag Dave

Chirag Dave

Chirag は マネージドな PostgreSQL を専門とする Amazon Web Services のプリンシパルソリューションアーキテクトです。セキュリティ、コスト、パフォーマンス、信頼性、効率的なオペレーション、アーキテクチャについてのベストプラクティスを通じてお客様と技術的な関係を構築しています。

Kovan Chandra

Kovan Chandra

Kovan は PostgreSQL データベースを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協業し、クラウドにおけるカスタマージャーニー、セキュリティ、レジリエンシー、コスト削減、およびオペレーショナルエクセレンスの改善に取り組んでいます。

Daxeshkumar Patel

Daxeshkumar Patel

Daxeshkumar は Amazon Web Services (AWS) のソリューションアーキテクトであり、主要なクラウド案件においてお客様やパートナーと密接に連携しています。概念実証（PoC）プロジェクトの設計・提供、実装支援、および AWS サービスを活用したアプリケーションの構築・移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。

Kamal Singh

Kamal Singh

Kamal は Amazon Web Services (AWS) のシニアデリバリーコンサルタントです。データベースの移行およびモダナイゼーションプログラムに重点を置き、お客様やパートナーの AWS クラウドへの移行を支援しています。

Jinesh Shah

Jinesh Shah

Jinesh は Amazon Web Services (AWS) のデリバリーコンサルタントです。レガシーデータベースおよびアプリケーションのモダンな AWS プラットフォームへの移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。