切り替えタイムアウト切り替えガードレール切り替えアクション切り替えのベストプラクティス切り替え前に CloudWatch メトリクスを確認するスイッチオーバー前のレプリカラグのモニタリングブルー/グリーンデプロイの切り替え切り替え後

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

切り替えを行うと、グリーン環境の DB クラスターは DB インスタンスを含めてプロモートされ、本稼働 DB クラスターになります。切り替え前は、本稼働環境のトラフィックはブルー環境のクラスターにルーティングされます。切り替え後、本稼働環境のトラフィックはグリーン環境の DB クラスターにルーティングされます。

トピック

切り替えタイムアウト
切り替えガードレール
切り替えアクション
切り替えのベストプラクティス
切り替え前に CloudWatch メトリクスを確認する
スイッチオーバー前のレプリカラグのモニタリング
ブルー/グリーンデプロイの切り替え
切り替え後

切り替えタイムアウト

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

切り替えガードレール

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

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

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

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

外部レプリケーション — Aurora PostgreSQL では、ブルー環境がセルフマネージド論理ソース (パブリッシャー) でもレプリカ (サブスクライバー) でもないことを確認します。その場合は、ブルー環境のすべてのデータベースでセルフマネージドレプリケーションスロットとサブスクリプションを削除し、スイッチオーバーを続行してからそれらを再作成してレプリケーションを再開することをお勧めします。Aurora MySQL の場合は、ブルーデータベースが外部のバイナリログレプリカではないことを確認してください。
実行時間の長いアクティブな書き込み — レプリカラグが増える可能性があるため、ブルー DB クラスターに実行時間の長いアクティブな書き込みがないことを確認します。
実行時間が長い DDL ステートメント – レプリカラグを増加させる可能性があるため、ブルー DB クラスターに実行時間が長い DDL ステートメントがないことを確認します。
サポートされていない PostgreSQL の変更 – Aurora PostgreSQL DB クラスターでは、ブルー環境で DDL の変更や大きなオブジェクトの追加や変更が行われていないことを確認します。詳細については、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。

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

切り替えアクション

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

ガードレールチェックを実行して、ブルー環境とグリーン環境を切り替える準備ができているかどうかを確認します。
両方の環境で DB クラスターでの新しい書き込みオペレーションを停止します。
両方の環境で DB インスタンスへの接続を切断し、新しい接続を許可しません。
グリーン環境がブルー環境と同期するように、レプリケーションがグリーン環境で追いつくのを待ちます。
両方の環境の DB クラスターと DB インスタンスの名前を変更します。

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

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

また、RDS はグリーン環境のエンドポイントの名前を、ブルー環境の対応するエンドポイントと一致するように変更するため、アプリケーションを変更する必要はありません。
両方の環境でデータベースへの接続を許可します。
新しい本稼働環境の DB クラスターへの書き込みオペレーションを許可します。

スイッチオーバー後、以前の本番 DB クラスターは、プライマリ DB インスタンスライターインスタンスが再起動されるまで読み取りオペレーションのみを許可します。DB クラスターで read_only パラメータを無効にしても、ブルー/グリーンデプロイを削除するまで読み取り専用のままになります。

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

ブルー環境でタグが設定されている場合、これらのタグは切り替え時に新しい本稼働環境に移動されます。以前の本稼働環境でも、これらのタグは保持されます。タグの詳細については、Amazon RDS リソースのタグ付けを参照してください。

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

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

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

グリーン環境でリソースを徹底的にテストします。適切かつ効率的に機能することを確認してください。
関連する Amazon CloudWatch メトリクスをモニタリングします。詳細については、「切り替え前に CloudWatch メトリクスを確認する」を参照してください。
切り替えに最適なタイミングを特定します。

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

DB クラスターおよび DB インスタンスに多数の接続がある場合は、ブルー/グリーンデプロイを切り替える前に、アプリケーションに必要な最小限の接続数に手動で減らすことを検討してください。これを実現する 1 つの方法は、ブルー/グリーンデプロイのステータスを監視し、ステータスが SWITCHOVER_IN_PROGRESS に変わったことを検出すると接続のクリーンアップを開始するスクリプトを作成することです。
両方の環境の DB クラスターと DB インスタンスが Available 状態にあることを確認します。
グリーン環境の DB クラスターが正常でレプリケートしていることを確認します。
ネットワークとクライアントの設定で、DNS キャッシュの存続可能時間 (TTL) が 5 秒を超えないようにしてください。これは Aurora DNS ゾーンのデフォルトです。  そうしないと、アプリケーションは切り替え後に書き込みトラフィックをブルー環境に送信し続けます。
スイッチオーバー後にブルー/グリーンデプロイをロールバックすることはできません。重要な本番ワークロードの場合は、切り替える前にバックアップ DB クラスターのプロビジョニングを検討してください。
Aurora PostgreSQL DB クラスターの場合は、次の操作を行います。
- スイッチオーバーの前に論理レプリケーションの制約事項を確認し、必要なアクションをすべて実行します。詳細については、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。
- ANALYZE 操作を実行して pg_statistics テーブルを更新します。これにより、スイッチオーバー後のパフォーマンス上の問題のリスクが軽減されます。

注記

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

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

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

DatabaseConnections — このメトリクスを使用して、ブルー/グリーンデプロイのアクティビティレベルを推定し、スイッチオーバー前に、その値がデプロイにとって許容可能なレベルであることを確認します。Performance Insights がオンになっている場合、DBLoad は、より正確なメトリクスになります。
ActiveTransactions — いずれかの DB インスタンスの DB パラメータグループで innodb_monitor_enable が all に設定されている場合、このメトリクスを使用して、切り替えを妨げる可能性のあるアクティブなトランザクションの数が多いかどうかを確認します。

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

スイッチオーバー前のレプリカラグのモニタリング

ブルー/グリーンデプロイを切り替える前に、ダウンタイムを減らすために、グリーンデータベースのレプリカラグがゼロに近いことを確認します。

Aurora MySQLの場合は、AuroraBinlogReplicaLag CloudWatch メトリクスを使用して、グリーン環境での現在のレプリケーションラグを特定します。

Aurora PostgreSQL の場合は、次の SQL クエリを使用します。


SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

confirmed_flush_lsn は、レプリカに送信されたログシーケンス番号 (LSN) の最大値を表します。pg_current_wall_lsn はデータベースの現在の位置を表します。lsn_distance が0 のとき、レプリカが追いついたことを意味します。

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

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

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

AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。
ナビゲーションペインで、[Databases] (データベース) を選択し、切り替えるブルー/グリーンデプロイを選択します。
[Actions] (アクション) で、[Switch over] (切り替え) を選択します。

[Switch over] (切り替え) ページが表示されます。
[Switch over] (切り替え) ページで、切り替えの概要を確認します。両方の環境のリソースが期待どおりであることを確認します。一致しない場合は、[Cancel] (キャンセル) を選択します。
[タイムアウトの設定] に、スイッチオーバーの制限時間を入力します。
クラスターで Aurora PostgreSQL を実行している場合は、スイッチオーバーの前の推奨事項を確認し、承認してください。詳細については、「ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項」を参照してください。
[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 クラスターと DB インスタンスは保持されます。これらのリソースには標準費用が適用されます。ブルーとグリーンの環境間のレプリケーションとバイナリロギングは停止します。

RDS は、現在のリソース名に -oldn を付加することによって、ブルー環境の DB クラスターと DB インスタンスの名前を変更します。ここで、n は数字です。DB クラスターは読み取り専用状態に強制されます。DB クラスターで read_only パラメータを無効にしても、ブルー/グリーンデプロイを削除するまで読み取り専用のままになります。

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

Aurora 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;

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ブルー/グリーンデプロイの表示

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

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

トピック

切り替えタイムアウト

切り替えガードレール

切り替えアクション

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

注記

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

スイッチオーバー前のレプリカラグのモニタリング

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

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

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

切り替え後

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

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