ブルー/グリーンデプロイの切り替え - Amazon Relational Database Service
切り替えタイムアウト切り替えガードレール切り替えアクション切り替えのベストプラクティス切り替え前に CloudWatch メトリクスを確認するブルー/グリーンデプロイの切り替え切り替え後

ブルー/グリーンデプロイの切り替え

切り替えを行うと、グリーン環境が新しい本稼働環境に昇格されます。グリーン DB インスタンスにリードレプリカがある場合、それらもプロモートされます。切り替え前は、本稼働環境のトラフィックはブルー環境の DB インスタンスとリードレプリカにルーティングされます。切り替え後は、本稼働環境のトラフィックはグリーン環境の DB インスタンスとリードレプリカにルーティングされます。

ブルー/グリーンデプロイの切り替えは、ブルー/グリーンデプロイ内のグリーン DB インスタンス の昇格とは異なります。[アクション] メニューで [昇格] を選択してグリーン DB インスタンス を手動で昇格させると、ブルー環境とグリーン環境間のレプリケーションが中断され、ブルー/グリーンデプロイは [無効な設定] の状態になります。

切り替えタイムアウト

切り替えのタイムアウト期間は、30 秒から 3,600 秒 (1 時間) まで指定できます。切り替えに指定された期間より長くかかる場合、変更はすべてロールバックされ、どちらの環境にも変更は加えられません。デフォルトのタイムアウト期間は 300 秒 (5 分) です。

切り替えガードレール

切り替えを開始すると、Amazon RDS はいくつかの基本的なチェックを実行して、ブルー環境とグリーン環境が切り替えの準備が整っているかテストします。これらのチェックは切り替えガードレールと呼ばれます。これらの切り替えガードレールは、準備が整っていない環境の切り替えを防ぎます。そのため、予想以上に長いダウンタイムが回避され、切り替えが開始された場合に発生する可能性のあるブルー環境とグリーン環境間のデータ損失を防ぐことができます。

Amazon RDS は、グリーン環境で以下のガードレールチェックを実行します。

  • レプリケーションの状態 – グリーンプライマリ DB インスタンス のレプリケーションステータスが正常かどうかをチェックします。グリーンプライマリ DB インスタンス は、ブループライマリ DB インスタンス のレプリカです。

  • レプリケーションラグ – グリーンプライマリ DB インスタンス のレプリカラグがスイッチオーバーの許容範囲内にあるかどうかをチェックします。許容限度は、指定されたタイムアウト期間に基づきます。レプリカラグは、グリーンプライマリ DB インスタンス がブループライマリ DB インスタンス よりどれだけ遅れているかを示します。詳細については、RDS for MySQL および レプリケーションプロセスのモニタリングとチューニング for RDS for PostgreSQL の リードレプリカ間の遅延の診断と解決 を参照してください

  • アクティブな書き込み – グリーンプライマリ DB インスタンスにアクティブな書き込みがないことを確認します。

Amazon RDS は、ブルー環境で以下のガードレールチェックを実行します。

  • 外部レプリケーション — RDS for PostgreSQL では、ブルー環境がセルフマネージド論理ソース (パブリッシャー) でもレプリカ (サブスクライバー) でもないことを確認します。その場合は、ブルー環境のすべてのデータベースでセルフマネージドレプリケーションスロットとサブスクリプションを削除し、スイッチオーバーを続行してからそれらを再作成してレプリケーションを再開することをお勧めします。RDS for MySQL および RDS for MariaDB の場合は、ブルーデータベースが外部のバイナリログレプリカではないことを確認してください。その場合、アクティブにレプリケートされていないことを確認してください。

  • 実行時間の長いアクティブな書き込み — レプリカラグが増える可能性があるため、ブループライマリ DB インスタンス に実行時間の長いアクティブな書き込みがないことを確認します。

  • 実行時間が長い DDL ステートメント – レプリカラグを増加させる可能性があるため、ブループライマリ DB インスタンス に実行時間が長い DDL ステートメントがないことを確認します。

  • サポートされていない PostgreSQL の変更 – RDS for PostgreSQL DB インスタンスでは、ブルー環境で DDL の変更や大きなオブジェクトの追加や変更が行われていないことを確認します。(詳しくは、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。)

    Amazon RDS がサポートされていない PostgreSQL の変更を検出すると、レプリケーションの状態が Replication degraded に変更され、ブルー/グリーンデプロイではスイッチオーバーができないことが通知されます。スイッチオーバーを続行するには、ブルー/グリーンデプロイとすべてのグリーンデータベースを削除して再作成することをお勧めします。そのためには、[アクション]、[グリーンデータベースで削除] を選択します。

切り替えアクション

ブルー/グリーンデプロイを切り替えると、RDS は次のアクションを実行します。

  1. ガードレールチェックを実行して、ブルー環境とグリーン環境を切り替える準備ができているかどうかを確認します。

  2. 両方の環境でプライマリ DB インスタンス での新しい書き込みオペレーションを停止します。

  3. 両方の環境で DB インスタンスへの接続を切断し、新しい接続を許可しません。

  4. グリーン環境がブルー環境と同期するように、レプリケーションがグリーン環境で追いつくのを待ちます。

  5. 両方の環境の DB インスタンスの名前を変更します。

    RDS は、グリーン環境の DB インスタンスが、ブルー環境の対応する DB インスタンスに一致するように名前を変更します。例えば、ブルー環境の DB インスタンスの名前が mydb であるとします。また、グリーン環境の対応する DB インスタンスの名前が mydb-green-abc123 であると仮定します。切り替え時、グリーン環境の DB インスタンスの名前は mydb に変更されます。

    RDS は、現在の名前に -oldn を追加して、ブルー環境の DB インスタンスの名前を変更します。ここで、n は数字です。例えば、ブルー環境の DB インスタンスの名前が mydb であるとします。切り替え後、DB インスタンス名は mydb-old1 になります。

    また、RDS はグリーン環境のエンドポイントの名前を、ブルー環境の対応するエンドポイントと一致するように変更するため、アプリケーションを変更する必要はありません。

  6. 両方の環境でデータベースへの接続を許可します。

  7. 新しい本稼働環境のプライマリ DB インスタンス への書き込みオペレーションを許可します。

    スイッチオーバーの後、以前の本番プライマリ DB インスタンス は、read_only パラメータを 0 に設定し、DB インスタンスが再起動されるまで読み取りオペレーションのみを許可します。

Amazon EventBridge を使用してスイッチオーバーのステータスをモニタリングできます。(詳しくは、「ブルー/グリーンデプロイイベント」を参照してください。)

ブルー環境でタグが設定されている場合、これらのタグはスイッチオーバー時に新しい本稼働環境にコピーされます。タグの詳細については、Amazon RDS リソースのタグ付けを参照してください。

切り替えが開始され、終了する前に何らかの理由で停止した場合、変更はすべてロールバックされ、どちらの環境にも変更は加えられません。

切り替えのベストプラクティス

スイッチオーバーの前に、次のタスクを実行してベストプラクティスに従うことを強くお勧めします。

  • グリーン環境でリソースを徹底的にテストします。適切かつ効率的に機能することを確認してください。

  • 関連する Amazon CloudWatch メトリクスをモニタリングします。(詳しくは、「切り替え前に CloudWatch メトリクスを確認する」を参照してください。)

  • 切り替えに最適なタイミングを特定します。

    切り替え中は、両方の環境でデータベースからの書き込みが遮断されます。本稼働環境でトラフィックが最も少ない時間を特定します。アクティブな DDL など、トランザクションの実行時間が長い場合、切り替え時間が長くなり、本稼働環境のワークロードのダウンタイムが長くなる可能性があります。

    DB インスタンス に多数の接続がある場合は、ブルー/グリーンデプロイを切り替える前に、アプリケーションに必要な最小限の接続数に手動で減らすことを検討してください。これを実現する 1 つの方法は、ブルー/グリーンデプロイのステータスを監視し、ステータスが SWITCHOVER_IN_PROGRESS に変わったことを検出すると接続のクリーンアップを開始するスクリプトを作成することです。

  • 両方の環境の DB インスタンスが Available 状態にあることを確認します。

  • グリーン環境のプライマリ DB インスタンス が正常でレプリケートしていることを確認します。

  • ネットワークとクライアントの設定で、DNS キャッシュの存続可能時間 (TTL) が 5 秒を超えないようにしてください。これは RDS DNS ゾーンのデフォルトです。
 そうしないと、アプリケーションは切り替え後に書き込みトラフィックをブルー環境に送信し続けます。

  • 切り替える前に、データの読み込みが完了していることを確認してください。(詳しくは、「ブルー/グリーンデプロイを作成する際の遅延読み込みの処理」を参照してください。)

  • RDS for PostgreSQL DB インスタンスの場合は、次の操作を行います。

    • スイッチオーバーの前に論理レプリケーションの制約事項を確認し、必要なアクションをすべて実行します。(詳しくは、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。)

    • ANALYZE 操作を実行して pg_statistics テーブルを更新します。これにより、スイッチオーバー後のパフォーマンス上の問題のリスクが軽減されます。

注記

切り替え中は、切り替えに含まれる DB インスタンスを変更することはできません。

切り替え前に CloudWatch メトリクスを確認する

ブルー/グリーンデプロイを切り替える前に、Amazon CloudWatch で次のメトリクスの値を確認することをお勧めします。

  • ReplicaLag — このメトリクスを使用して、グリーン環境での現在のレプリケーション遅延を特定します。ダウンタイムを減らすには、切り替え前に、この値がゼロに近いことを確認してください。

  • DatabaseConnections — このメトリクスを使用して、ブルー/グリーンデプロイのアクティビティレベルを推定し、スイッチオーバー前に、その値がデプロイにとって許容可能なレベルであることを確認します。Performance Insights がオンになっている場合、DBLoad は、より正確なメトリクスになります。

これらのメトリクスの詳細については、「Amazon RDS の Amazon CloudWatch メトリクス」を参照してください。

ブルー/グリーンデプロイの切り替え

ブルー/グリーンデプロイは、AWS Management Console、AWS CLI、または RDS API を使用して切り替えることができます。

ブルー/グリーンデプロイを切り替えるには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. ナビゲーションペインで、[Databases] (データベース) を選択し、切り替えるブルー/グリーンデプロイを選択します。

  3. [Actions] (アクション) で、[Switch over] (切り替え) を選択します。

    [Switch over] (切り替え) ページが表示されます。

    ブルー/グリーンデプロイを切り替える

  4. [Switch over] (切り替え) ページで、切り替えの概要を確認します。両方の環境のリソースが期待どおりであることを確認します。一致しない場合は、[Cancel] (キャンセル) を選択します。

  5. [タイムアウトの設定] に、スイッチオーバーの制限時間を入力します。

  6. インスタンスが RDS for PostgreSQL を実行している場合は、スイッチオーバーの前の推奨事項を確認し、承認してください。(詳しくは、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。)

  7. [Switch over] (切り替え) を選択します。

AWS CLI を使用してブルー/グリーンデプロイを切り替えるには、switchover-blue-green-deployment コマンドを次のオプションを指定して使用します。

  • --blue-green-deployment-identifier — 削除するブルー/グリーンデプロイのリソース ID を指定します。

  • --switchover-timeout — 切り替えの制限時間を秒単位で指定します。デフォルトは 300 です。

例 ブルー/グリーンデプロイを切り替える

Linux、macOS、Unix の場合:

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

Windows の場合:

aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

Amazon RDS API を使用してブルー/グリーンデプロイを切り替えるには、SwitchoverBlueGreenDeployment オペレーションを以下のパラメータを指定して使用します。

  • BlueGreenDeploymentIdentifier — 削除するブルー/グリーンデプロイのリソース ID を指定します。

  • SwitchoverTimeout — 切り替えの制限時間を秒単位で指定します。デフォルトは 300 です。

切り替え後

切り替え後、以前のブルー環境の DB インスタンスは保持されます。これらのリソースには標準費用が適用されます。ブルーとグリーンの環境間のレプリケーションとは停止します。

RDS は、現在のリソース名に -oldn を付加することによって、ブルー環境の DB インスタンスの名前を変更します。ここで、n は数字です。DB インスタンスは、read_only パラメータを 0 に設定しない限り、読み取り専用です。RDS は、グリーン環境の DB インスタンスを -newn と名付けます。

ブルー/グリーンデプロイリソースを削除すると、RDS は -oldn および -newn リソースを保持します。

ブルー/グリーンデプロイの切り替えへの切り替え後

コンシューマーの親ノードの更新

RDS for MariaDB または RDS for MySQL ブルー/グリーンデプロイを切り替えた後、スイッチオーバー前にブルー DB インスタンス に外部レプリカまたはバイナリログコンシューマーがあった場合は、レプリケーションの継続性を維持するために、スイッチオーバー後に親ノードを更新する必要があります。

スイッチオーバー後、グリーン環境に以前存在していた DB インスタンスは、マスターログファイル名とマスターログの位置を含むイベントを発行します。次に例を示します。

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

まず、コンシューマーまたはレプリカが古いブルー環境のすべてのバイナリログを適用していることを確認します。次に、提供されたバイナリログ座標を使用して、コンシューマーでアプリケーションを再開します。例えば、EC2 で MySQL レプリカを実行している場合は、CHANGE MASTER TO コマンドを使用できます。

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;
注記

コンシューマーが別の RDS for MariaDB または RDS for MariaDB DB インスタンスである場合は、mysql.rds_stop_replication、mysql.rds_reset_external_master、mysql.rds_set_external_master、および mysql.rds_start_replication の順序で次のストアドプロシージャを実行できます。