RDS Blue/Green Deployment完全解説：ダウンタイムゼロへの挑戦

1. そもそもBlue/Green Deploymentとは

Blue/Green Deploymentは新しい概念でも Aurora 専用の手法でもありません。
これは、アプリケーションの新バージョンをリリースする際に広く使用される一般的なデプロイメント戦略です。
最近はインフラエンジニアにとってはもはや当たり前になってきました。

アプリケーションレイヤーでのBlue/Green Deploymentに関する特徴

• 2つの同様の環境を用意
  • Blue環境: 現行の本番環境
  • Green環境: 新バージョンをデプロイする環境
• Green環境に新バージョンをデプロイし、テストを実施
  • デフォルトはトラフィックが直ちに徐々にBlueからGreenに切り替える設定ですが、待機時間(待機期間でテストを実施)を設定することも可能
• トラフィックを徐々にBlueからGreenに切り替え　
• 問題があればBlue環境に素早くロールバック可能
• 完全に切り替わって、特に問題が発生しない場合は、Blue環境を削除

主なメリット:

• ダウンタイムの最小化
• リスクの軽減
• 素早いロールバック

AWSでアプリケーションレイヤーでBlue/Green Deploymentを実施する場合、主にECSとCodeDeployを組み合わせて使用する方法が一般的です。

2. 従来のデータベースBlue/Green Deployment

• データベースではBlue/Green Deploymentはそもそも可能なのか？
  Blue/Green Deploymentは同時に新旧バージョンを稼働させるため、基本的にはステートレスなアプリケーション・サーバーでしか利用できず、データベースでは実現不可能だという固定観念を持つエンジニアは少なくありません。しかし実際には、RDS Blue/Green Deploymentがリリースされる以前から、データベースにおいて擬似的にBlue/Green Deploymentを実現するための手法がいくつか存在していました。

2.1 手動バイナリログレプリケーション

1. 本番環境(Blue)と同じ構成の新環境(Green)を手動作成
2. バイナリログレプリケーションを手動で設定し、継続的なデータ同期を確立(MySQLにそれなりに詳しくないエンジニアでないかぎりではちょっとハードル高そう)
3. Green環境で必要な変更を実施
4. テストを行いながら、レプリケーションを継続
5. 準備が整ったら、短時間のダウンタイムを取ってレプリケーションを停止し、手動でアプリケーションの接続先を切り替え

バイナリログレプリケーションを手動で設定する方法：

2.2 RDSのread replicaを利用

RDSのread replicaを利用したBlue/Green Deploymentの具体的な手順:

1. 本番環境(Blue)のRDSインスタンスのread replicaを手動作成する
2. read replicaのread_onlyパラメータを0に設定し、書き込み可能にする
   • パラメータグループを新規作成し、 read_onlyを0に設定
   • read replicaにこのパラメータグループを適用し再起動
3. read replica(Green環境)で必要な変更を実施
   • スキーマ変更
   • バージョンアップグレード
   • パラメータ変更など
4. Green環境でテストを実施
5. 切り替え準備
   • アプリケーションを一時停止
   • Blue環境への書き込みを停止
6. レプリケーションの遅延がなくなるまで待機
7. read replicaをプロモートして独立したインスタンスにする
8. 手動アプリケーションの接続先をGreen環境に変更
9. アプリケーションを再開
10. 動作確認後、旧Blue環境を削除

ただし、この方法には以下の注意点があります:

• レプリケーションの整合性が損なわれる可能性がある
• プロモート後は元のマスターとの同期が失われる
• AWSの公式なBlue/Green Deployment機能ではないため、サポート対象外となる可能性がある
  一応AWS documentでは以下の内容が書かれているが、実際にRDS read replicaを利用してonline DDLサポートしていないDDLを実施するユースケースってなかなか少ないようですね。
  というこごで技術的には可能ですが、多くのリスクを伴い、一般的には推奨されません。

Perform DDL operations: DDL operations such as creating/re-building indexes etc. 
could take a long time and impose significant performance penalty on your DB Instance. 
You can perform these operations on a Read Replica, and once the operations are 
complete and the updates are caught up with the Source DB Instance, 
you can promote the Read Replica, and point your applications to it.

• Auroraは共有ストレージアーキテクチャであり、スキーマ変更を直接行うことはできません。とうことでこの方法は、標準のMySQLレプリケーションには適用できる場合がありますが、Auroraには適用できません

2.3 AWS DMSを使用した継続的レプリケーション

詳細プロセス:

1. 手動で新しいGreen環境のクラスターを作成
2. DMS(AWS Database Migration Service)を使用してBlueからGreenへの継続的なレプリケーションを設定
   • DMSレプリケーションインスタンスの作成:
     • 適切なインスタンスタイプとネットワーク設定でDMSレプリケーションインスタンスを作成
   • ソースとターゲットのエンドポイント設定:
     • ソース（Blue環境）とターゲット（Green環境）のエンドポイントをDMSで設定
   • マイグレーションタスクの作成と実行:
     • フルロード＋CDCモードでマイグレーションタスクを作成
     • タスクを開始し、初期データロードと継続的な変更のレプリケーションを実行
3. Green環境で必要な変更（スキーマ変更、バージョンアップグレードなど）を実施
4. テストを行いながら、DMSによるデータ同期を継続
5. 切り替え:
   • 手動でアプリケーション側の接続先をBlue環境からGreen環境に変更
6. DMSタスクを停止
7. クリーンアップ:
   • 問題がないことを確認後、旧Blue環境とDMSリソースを削除

特徴：

• DMSは多くの手動設定と管理が必要で、DMSに慣れていない方にとってはハードルがかなり高い
• 手動でアプリケーション側の接続先する必要があるから、切り替え時のダウンタイムが長くなりそう
• カスタマイズの自由度が高い(例えば特定のデータベースや特定のテーブルだけ同期するなどもできる)
• 異なるデータベースエンジン間の移行にも使用可能(MySQl⇒PostgreSQLなど)

3. RDS Blue/Green Deployment

3.1 RDS Blue/Green Deploymentの仕組み

以前からデータベースにおいて擬似的にBlue/Green Deploymentを実現するための手法がいくつか存在していました。しかし、これらの手法は操作が複雑で、リスクも伴い、広く普及するには至っていませんでした。このような課題を解決し、マネージドサービスとして提供されているのがRDS Blue/Green Deploymentです。

1. 数クリックだけで、現本番環境(Blue環境)のコピー(Green環境)を自動的に作成してくれる

   • Blue環境のバージョンアップ or CloneからGreen環境を作成
     • Green環境の作成時に、Blue環境で保留中のメンテナンス（バージョンアップやOSパッチ適用など）がある場合、それらは自動的にGreen環境に適用
   • 単なる特定時点のデータのコピーではなく、Blue環境とGreen環境の間では論理レプリケーションが自動的に設定される。これにより、Blue環境に書き込まれるデータは、すべてリアルタイムでGreen環境に継続的に同期
     

2. Green環境で気軽に以下のような各種変更のテストできる

   • データベースエンジンのバージョン アップグレード:メジャーまたはマイナーバージョンのアップグレードを行う際に、事前にGreen環境でテストできる
   • パラメータグループの変更:データベースパラメータの変更をGreen環境で試し、本番環境に影響を与えないようにすることが可能
   • 新機能のテスト: 新しいアプリケーション機能やデータベース設定変更を本番環境へ適用する前に、Green環境で検証できる

3. 環境の切り替えを実施(切り替えは通常1分以内で完了)

   • webコンソールからボタンを数クリックするだけで簡単に環境切り替えできる
     
   • 切り替え後の状態：もともとのデータベースエンドポイントが自動的にGreen環境に向けられ、アプリケーションの変更も一切不要
     

4. 切り替え後もBlue環境は保持されます。しかし、Blue環境には切り替え時点のデータしか残っておらず、ユーザーからのトラフィックを停止しない限り、Blue環境とGreen環境の間にデータの差分が発生します。そのため、切り替え後に簡単にBlue環境に戻すことはできません。Blue環境が不要となった場合は、手動で削除しても構いません。

主な利点:

• データベースの変更リスクを軽減
• ダウンタイムの最小化
• テストと検証が容易
• 素早いロールバック可能

通常のオンラインDDLでは対応が難しいが、RDS Blue/Green Deploymentを使用することでBlue環境で実行可能なDDLのリスト：

• ALTER TABLE文を使用したカラムのデータ型変更
  • 例: INT型からBIGINT型への変更
• ALTER TABLE文を使用したカラムの追加
  • 例: 新しいカラムをテーブルに追加する
• インデックスの作成 (CREATE INDEX)
  • 例: 大規模なテーブルに新しいインデックスを追加する
• インデックスの削除 (DROP INDEX)
  • 例: 不要になったインデックスを削除する
• テーブルのパーティション化
  • 例: 既存の大規模テーブルをパーティション化する
• カラムのデフォルト値の変更
  • 例: ALTER TABLE文を使用してカラムのデフォルト値を変更する
• NULL制約の追加または削除
  • 例: ALTER TABLE文を使用してカラムにNOT NULL制約を追加する

これらのDDL操作は、通常のオンラインDDLでは本番環境に大きな影響を与える可能性がありますが、RDS Blue/Green Deploymentを使用することで、Blue環境で安全に実行し、テストした後に本番環境（Green環境）に適用することができます。

3.2 注意点

• Blue環境でバイナリログを有効にする必要があります。バイナリログのフォーマットはROWが推奨されますが、以下のことが注意したほうがよい。

  • ログの肥大化によるディスク容量の増加
  • I/O速度(パフォーマンスへの影響):通常5%未満

• クラスタの再起動が必要：
  クラスターパラメータグループの変更が適用されていないと、グリーン環境を作成できない。変更後はクラスタの再起動が必要です。

• 書き込み操作の制限: デフォルトでは、グリーン環境のDBクラスターは書き込み操作を許可しません

• 一時的に2つの環境を維持する必要があるため、コストが倍増する期間がある。

3.3 制限

• 利用できるエンジン
  • RDS for MySQL
  • RDS for PostgreSQL
  • RDS for MariaDB
  • Aurora MySQL：　Blue環境でbinlogを有効にする必要がある
  • Aurora PostgreSQL

• 対応していないDDL

However, schema changes, such as renaming columns or renaming tables, break replication to the green deployment.

RDS Blue/Green Deploymentは、論理レプリケーションを使用してBlue環境からGreen環境へのデータ同期を行います。Blue環境では破壊的な変更を実行する場合は、レプリケーションエラーになってしまいます。

• 列名の削除
• 列名の変更
• テーブルの削除
• テーブル名の変更

具体的な例：
green環境である列を削除したとします。blue環境では継続的に該当の列に新しいデータを入れています。レプリケーションでblue環境からgreen環境にデータを同期しようとすると、該当の列がないから、レプリケーションエラーが発生し、レプリケーションが止まってしまう。
対応方法：アプリケーション側であらかじめ該当のカラムに対してデータを入れないようにする修正をする必要がある

3.4 4つの案の比較

特徴	手動binlog replication	RDS read replica利用	AWS DMS	RDS Blue/Green Deployment
replicationの責任	ユーザー自身	RDS	DMS	RDS
複雑さ	高	中	中	低
技術的専門知識の必要性	高	中	中	低
コスト	低 管理コスト高	中	中	高 管理コスト低
ダウンタイム	高	中	低	最小 通常1分未満
異種DB間の移行	制限あり	不可	可能	不可
自動化レベル	低	中	中	高
green環境の作成	手動	半自動	手動	自動
ロールバックの容易さ	難しい	中程度	中程度	容易
AWSサポート	なし(完全自己責任)	部分的	あり	完全サポート

この比較から、RDS Blue/Green Deploymentが最も使いやすく、リスクが低い方法であることがわかります。ただし、特定の要件や制約がある場合は、他の方法が適している可能性もあります。

切り替え時間：
自分はテストしていないが、AWSさん公開している動画によると1分も経たずにに切り替えできた。

https://youtu.be/7CuyE2M8jBY?t=964

テスト用のスクリプト：
https://github.com/euno7/rds-bgdeploy-demo/blob/main/main.go

4. RDS Blue/Green Deployment対応できる課題のまとめ

1. メジャー/マイナーバージョンアップ時のダウンタイム削減：
   メジャーまたはマイナーバージョンのアップグレードを行う際に、事前にGreen環境でテストできる

2. スキーマ変更などのデータベース変更作業における長いダウンタイムの削減
   MySQLの新バージョンでは、以前はオフラインでしか実行できなかったDDL操作の多くがオンラインDDLとして実行可能になりました。これにより、ダウンタイムなし、あるいは極めて短いダウンタイムだけで多くのスキーマ変更が実施できるようになりました。しかし、カラムの削除やデータ型の変更など、依然としてオンラインDDLでサポートされていない操作も存在します。

参考記事：