# Amazon Aurora でのブルー/グリーンデプロイの切り替え
*スイッチオーバー*は、グリーン環境の DB クラスター (DB インスタンスを含む) を本番稼働用 DB クラスターに移行します。切り替え前は、本稼働環境のトラフィックはブルー環境のクラスターにルーティングされます。切り替え後、本稼働環境のトラフィックはグリーン環境の DB クラスターにルーティングされます。
ブルー/グリーンデプロイの切り替えは、ブルー/グリーンデプロイ内のグリーン DB クラスターの昇格とは異なります。******[アクション]** メニューで **[昇格]** を選択してグリーン DB クラスターを手動で昇格させると、ブルー環境とグリーン環境間のレプリケーションが中断され、ブルー/グリーンデプロイは **[無効な設定]** の状態になります。
**Topics**
+ [
## 切り替えタイムアウト
](#blue-green-deployments-switching-timeout)
+ [
## 切り替えガードレール
](#blue-green-deployments-switching-guardrails)
+ [
## 切り替えアクション
](#blue-green-deployments-switching-actions)
+ [
## 切り替えのベストプラクティス
](#blue-green-deployments-switching-best-practices)
+ [
## 切り替え前に CloudWatch メトリクスを確認する
](#blue-green-deployments-switching-over-cloudwatch)
+ [
## スイッチオーバー前のレプリカラグのモニタリング
](#blue-green-deployments-monitor-replica-lag)
+ [
## ブルー/グリーンデプロイの切り替え
](#blue-green-deployments-switching-over)
+ [
## 切り替え後
](#blue-green-deployments-switching-after)
## 切り替えタイムアウト
切り替えのタイムアウト期間は、30 秒から 3,600 秒 (1 時間) まで指定できます。切り替えに指定された期間より長くかかる場合、変更はすべてロールバックされ、どちらの環境にも変更は加えられません。デフォルトのタイムアウト期間は 300 秒 (5 分) です。
## 切り替えガードレール
切り替えを開始すると、Amazon RDS はいくつかの基本的なチェックを実行して、ブルー環境とグリーン環境が切り替えの準備が整っているかテストします。これらのチェックは*切り替えガードレール*と呼ばれます。これらの切り替えガードレールは、準備が整っていない環境の切り替えを防ぎます。そのため、予想以上に長いダウンタイムが回避され、切り替えが開始された場合に発生する可能性のあるブルー環境とグリーン環境間のデータ損失を防ぐことができます。
Amazon RDS は、グリーン環境で以下のガードレールチェックを実行します。
+ **レプリケーションの状態** – グリーン DB クラスターのレプリケーションステータスが正常かどうかをチェックします。グリーン DB クラスターは、ブルー DB クラスターのレプリカです。
+ **レプリケーションラグ** – グリーン DB クラスターのレプリカラグがスイッチオーバーの許容範囲内にあるかどうかをチェックします。許容限度は、指定されたタイムアウト期間に基づきます。レプリカラグは、グリーン DB クラスターがブルー DB クラスターよりどれだけ遅れているかを示します。詳細については、「[スイッチオーバー前のレプリカラグのモニタリング](#blue-green-deployments-monitor-replica-lag)」を参照してください。
+ **アクティブな書き込み** – グリーン DB クラスターにアクティブな書き込みがないことを確認します。
Amazon RDS は、ブルー環境で以下のガードレールチェックを実行します。
+ **外部レプリケーション** — Aurora PostgreSQL では、ブルー環境がセルフマネージド論理ソース (パブリッシャー) でもレプリカ (サブスクライバー) でもないことを確認します。その場合は、ブルー環境のすべてのデータベースでセルフマネージドレプリケーションスロットとサブスクリプションを削除し、スイッチオーバーを続行してからそれらを再作成してレプリケーションを再開することをお勧めします。Aurora MySQL の場合は、ブルーデータベースが外部のバイナリログレプリカではないことを確認してください。その場合、アクティブにレプリケートされていないことを確認してください。
+ **実行時間の長いアクティブな書き込み** — レプリカラグが増える可能性があるため、ブルー DB クラスターに実行時間の長いアクティブな書き込みがないことを確認します。
+ **実行時間が長い DDL ステートメント** – レプリカラグを増加させる可能性があるため、ブルー DB クラスターに実行時間が長い DDL ステートメントがないことを確認します。
+ **サポートされていない PostgreSQL の変更** – Aurora PostgreSQLでは、ブルー環境で DDL の変更や大きなオブジェクトの追加や変更が行われていないことを確認します。詳細については、「[ブルー/グリーンデプロイの論理レプリケーション固有の制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)」を参照してください。
Amazon RDS がサポートされていない PostgreSQL の変更を検出すると、レプリケーションの状態が `Replication degraded` に変更され、ブルー/グリーンデプロイではスイッチオーバーができないことが通知されます。スイッチオーバーを続行するには、ブルー/グリーンデプロイとすべてのグリーンデータベースを削除して再作成することをお勧めします。そのためには、**[アクション]**、**[グリーンデータベースで削除]** を選択します。
## 切り替えアクション
ブルー/グリーンデプロイを切り替えると、RDS は次のアクションを実行します。
1. ガードレールチェックを実行して、ブルー環境とグリーン環境を切り替える準備ができているかどうかを確認します。
1. 両方の環境で DB クラスターでの新しい書き込みオペレーションを停止します。
1. 両方の環境で DB インスタンスへの接続を切断し、新しい接続を許可しません。
1. グリーン環境がブルー環境と同期するように、レプリケーションがグリーン環境で追いつくのを待ちます。
1. 両方の環境の 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 はグリーン環境のエンドポイントの名前を、ブルー環境の対応するエンドポイントと一致するように変更するため、アプリケーションを変更する必要はありません。
1. 両方の環境でデータベースへの接続を許可します。
1. 新しい本稼働環境の DB クラスターへの書き込みオペレーションを許可します。
スイッチオーバー後、以前の本番 DB クラスターは、DB クラスターで書き込みを有効にしても、ブルー/グリーンデプロイを削除するまで読み取り専用のままになります。
Amazon EventBridge を使用してスイッチオーバーのステータスをモニタリングできます。詳細については、「[ブルー/グリーンデプロイイベント](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)」を参照してください。
スイッチオーバー中、ブルー環境のタグは、グリーン環境のリソースのすべてのタグを置き換えます。グリーン環境リソースに直接追加したタグは、このプロセス中に上書きされます。タグの詳細については、[Amazon Aurora および Amazon RDS リソースのタグ付け](USER_Tagging.md)を参照してください。
切り替えが開始され、終了する前に何らかの理由で停止した場合、変更はすべてロールバックされ、どちらの環境にも変更は加えられません。
## 切り替えのベストプラクティス
スイッチオーバーの前に、次のタスクを実行してベストプラクティスに従うことを強くお勧めします。
+ グリーン環境でリソースを徹底的にテストします。適切かつ効率的に機能することを確認してください。
+ 関連する Amazon CloudWatch メトリクスをモニタリングします。詳細については、「[切り替え前に CloudWatch メトリクスを確認する](#blue-green-deployments-switching-over-cloudwatch)」を参照してください。
+ 切り替えに最適なタイミングを特定します。
切り替え中は、両方の環境でデータベースからの書き込みが遮断されます。本稼働環境でトラフィックが最も少ない時間を特定します。アクティブな DDL など、トランザクションの実行時間が長い場合、切り替え時間が長くなり、本稼働環境のワークロードのダウンタイムが長くなる可能性があります。
DB クラスターおよび DB インスタンス に多数の接続がある場合は、ブルー/グリーンデプロイを切り替える前に、アプリケーションに必要な最小限の接続数に手動で減らすことを検討してください。これを実現する 1 つの方法は、ブルー/グリーンデプロイのステータスを監視し、ステータスが `SWITCHOVER_IN_PROGRESS` に変わったことを検出すると接続のクリーンアップを開始するスクリプトを作成することです。
+ 両方の環境の DB クラスターと DB インスタンスが `Available` 状態にあることを確認します。
+ グリーン環境の DB クラスターが正常でレプリケートしていることを確認します。
+ ネットワークとクライアントの設定で、DNS キャッシュの存続可能時間 (TTL) が 5 秒を超えないようにしてください。これは Aurora DNS ゾーンのデフォルトです。そうしないと、アプリケーションはスイッチオーバー後に書き込みトラフィックをブルー環境に送信し続けます。
+ Aurora PostgreSQL ブルー/グリーンデプロイの場合は、以下を実行します。
+ スイッチオーバーの前に論理レプリケーションの制約事項を確認し、必要なアクションをすべて実行します。詳細については、「[ブルー/グリーンデプロイの論理レプリケーション固有の制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)」を参照してください。
+ `ANALYZE` 操作を実行して `pg_statistics` テーブルを更新します。これにより、スイッチオーバー後のパフォーマンス上の問題のリスクが軽減されます。
+ ブルー/グリーンデプロイのスイッチオーバーを開始する前に、アプリケーションがセッションレベルで `default_transaction_read_only` パラメータを上書きしないことを確認します。スイッチオーバー中、昇格が完了するまで書き込みが行われないように、このパラメータはグリーン環境ライターで `on` に設定されます。アプリケーションまたはトランザクションがこの設定を `off` に上書きする場合、アプリケーションはスイッチオーバープロセス中にグリーン環境にデータを書き込むことがあります。スイッチオーバーをロールバックする必要がある場合、これらの書き込みはブルー環境で使用できないため、データの不整合を手動で解決する必要があります。スイッチオーバーに進む前に、アプリケーションクエリを監査して `default_transaction_read_only` 設定を優先することを強くお勧めします。
**注記**
切り替え中は、切り替えに含まれる DB クラスターを変更することはできません。
## 切り替え前に CloudWatch メトリクスを確認する
ブルー/グリーンデプロイを切り替える前に、Amazon CloudWatch で次のメトリクスの値を確認することをお勧めします。
+ `DatabaseConnections` — このメトリクスを使用して、ブルー/グリーンデプロイのアクティビティレベルを推定し、スイッチオーバー前に、その値がデプロイにとって許容可能なレベルであることを確認します。Performance Insights がオンになっている場合、`DBLoad` は、より正確なメトリクスになります。
+ `ActiveTransactions` — いずれかの DB インスタンスの DB パラメータグループで `innodb_monitor_enable` が `all` に設定されている場合、このメトリクスを使用して、切り替えを妨げる可能性のあるアクティブなトランザクションの数が多いかどうかを確認します。
詳細については、「[Amazon Aurora の Amazon CloudWatch メトリクス](Aurora.AuroraMonitoring.Metrics.md)」を参照してください。
## スイッチオーバー前のレプリカラグのモニタリング
ブルー/グリーンデプロイを切り替える前に、ダウンタイムを減らすために、レプリカラグがゼロに近いことを確認します。
### Aurora MySQL
MySQL ブルー/グリーンデプロイでは、グリーン環境の `AuroraBinlogReplicaLag` CloudWatch メトリクスをチェックして、現在のレプリカラグを特定します。詳細については、「[リードレプリカ間の遅延の診断と解決](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)」を参照してください。
### Aurora PostgreSQL
PostgreSQL ブルー/グリーンデプロイの場合は、ブルー環境の `OldestReplicationSlotLag` CloudWatch メトリクスをチェックして、現在のレプリカラグを特定します。詳細については、「[Amazon Aurora のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)」を参照してください。
さらに、ブルー環境で次の 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_wal_lsn` はデータベースの現在の位置を表します。`lsn_distance` が 0 のとき、レプリカが追いついたことを意味します。
## ブルー/グリーンデプロイの切り替え
ブルー/グリーンデプロイは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して切り替えることができます。
### コンソール
**ブルー/グリーンデプロイを切り替えるには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択し、切り替えるブルー/グリーンデプロイを選択します。
1. **[Actions]** (アクション) で、**[Switch over]** (切り替え) を選択します。
**[Switch over]** (切り替え) ページが表示されます。
![\[ブルー/グリーンデプロイを切り替える\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switch-over-aurora.png)
1. **[Switch over]** (切り替え) ページで、切り替えの概要を確認します。両方の環境のリソースが期待どおりであることを確認します。一致しない場合は、**[Cancel]** (キャンセル) を選択します。
1. **[タイムアウトの設定]** に、スイッチオーバーの制限時間を入力します。
1. クラスターで Aurora PostgreSQL を実行している 場合は、スイッチオーバーの前の推奨事項を確認し、承認してください。詳細については、「[ブルー/グリーンデプロイの論理レプリケーション固有の制限事項](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)」を参照してください。
1. **[Switch over]** (切り替え) を選択します。
### AWS CLI
AWS CLI を使用してブルー/グリーンデプロイを切り替えるには、[switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) コマンドを次のオプションを指定して使用します。
+ `--blue-green-deployment-identifier` — 削除するブルー/グリーンデプロイのリソース ID を指定します。
+ `--switchover-timeout` — 切り替えの制限時間を秒単位で指定します。デフォルトは 300 です。
**Example ブルー/グリーンデプロイを切り替える**
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
```
### RDS API
Amazon RDS API を使用してブルー/グリーンデプロイを切り替えるには、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) オペレーションを以下のパラメータを指定して使用します。
+ `BlueGreenDeploymentIdentifier` — 削除するブルー/グリーンデプロイのリソース ID を指定します。
+ `SwitchoverTimeout` — 切り替えの制限時間を秒単位で指定します。デフォルトは 300 です。
## 切り替え後
切り替え後、以前のブルー環境の DB クラスターと DB インスタンスは保持されます。これらのリソースには標準費用が適用されます。ブルーとグリーンの環境間のレプリケーションとバイナリロギングは停止します。
RDS は、現在のリソース名に `-oldn` を付加することによって、ブルー環境の DB クラスターと DB インスタンスの名前を変更します。ここで、`n` は数字です。ブルー DB クラスターは読み取り専用状態に強制されます。書き込みオペレーションを有効にしても、ブルー/グリーンデプロイを削除するまで読み取り専用のままになります。RDS は、グリーン環境の DB クラスターと DB インスタンスを `-newn` と名付けます。
ブルー/グリーンデプロイリソースを削除すると、RDS は `-oldn` および `-newn` リソースを保持します。
![\[ブルー/グリーンデプロイの切り替えへの切り替え後\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-after-switchover-aurora.png)
### コンシューマーの親ノードの更新
RDS はフルマネージドリードレプリカを提供します。ただし、*外部レプリカ*とも呼ばれるセルフマネージドレプリカを設定するオプションも用意されています。外部レプリカを使用すると、レプリケーションターゲットとしてサードパーティのリソースを使用できます。
Aurora MySQL ブルー/グリーンデプロイを切り替えた後、スイッチオーバー前にブルー DB クラスターに外部レプリカまたはバイナリログコンシューマーがあった場合は、レプリケーションの継続性を維持するために、スイッチオーバー後に親ノードを更新する必要があります。
**親ノードを更新するには**
1. スイッチオーバー後、グリーン環境に以前存在していたライター DB インスタンスは、マスターログファイル名とマスターログの位置を含むイベントを発行します。イベントを見つけるには、RDS コンソールに移動し、左側のナビゲーションペインから **[イベント]** を選択します。
1. スイッチオーバー前の古いグリーンライター DB インスタンスの名前をソースとするイベントでフィルタリングします。
1. バイナリログ座標を含むイベントを見つけます。イベントメッセージは次のようになります: `Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`
1. コンシューマーまたはレプリカが古いブルー環境からすべてのバイナリログを適用していることを確認します。次に、提供されたバイナリログ座標を使用して、コンシューマーでのレプリケーションを再開します。例えば、EC2 で MySQL レプリカを実行している場合は、以下のコマンドを使用できます。
**MySQL 8.0.22 以前のメジャーバージョンとマイナーバージョン**
```
CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
```
**MySQL 8.0.23 以降のメジャーバージョンとマイナーバージョン**
```
CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
```