☃️

Auroraアップグレード時のBlue/Green Deploymentsの利用

2023/12/03に公開

AWS

RDS

アップグレード

tech

このエントリーは3-shake Advent Calendar 2023 4日目の記事です。
株式会社スリーシェイクのメンバーが各々自由に技術・非技術ネタを投稿するカレンダーとなります。

はじめに

Amazon Aurora2系について、標準サポート終了日(2024/10/31)まで1年を切りました。

依然として、Aurora2系を利用しているシステムは多いのではないでしょうか。アプリケーションのテストや検証を考えると早めに動いていかなければならない時期となりました。

本記事では、アップグレード方式・方針の一つとして、AWSからも推奨されているRDS Blue/Green Deploymentsの基本、利用方法、利点などについてご紹介いたします。

また、検証時に実施した具体的な設定手順やオペレーションについてもご紹介いたします。
そして最後には、その他のアップグレード方式・方針との比較をします。
本記事は、2023/12時点での記事となります。

対象読者

RDS Blue/Green Deploymentsの基礎知識、ワークフローを知りたい方
RDS Blue/Green Deploymentsの注意点を知りたい方
RDS Blue/Green Deploymentsの具体的な設定手順,オペレーションを知りたい方
可能な限りダウンタイムが少なくメンテナンスを実施したい方
可能な限りメンテナンス時間を短く実施したい方
Aurora3系へのアップデートに向けて、RDS Blue/Green Deploymentsの利用を検討している方

RDS Blue/Green Deployments for Auroraについて

前提

本記事は、Amazon RDS for Auroraの内容であり、Amazon RDS for MySQLの仕様は一部異なるのでご注意ください。

RDS Blue/Green Deployments for Auroraとは

Amazon RDS Blue/Green Deploymentsを利用すると、本番環境と論理レプリケーションされたステージング環境が作成できます。
既存でも実装可能な一連の技術をマネージドな形で、機能として提供しています。

動作要件

RDS
- RDS for MySQL5.7 以降
- RDS for MySQL 8.0.15 以降
- RDS for MariaDB 10.2 以降
Aurora
- Aurora MySQL全バージョン
  - Blue環境でAurora MySQLを利用する場合は,binlogを有効にする必要あり

特徴

本番環境(Blue環境)に対応したステージング環境(Green環境)を簡単に作成できる
データベースの変更を本番環境(Blue環境)からステージング環境(Green環境)に、論理レプリケーションする
Green環境でデータベースの変更のテストができる
Green環境で起動したインスタンスは、データベースパッチとシステムアップデートを最新の状態に保てる
Green環境で新しいデータベース機能を実装してテストができる
本稼働環境(Blue環境)とGreen環境で、自動でエンドポイントが切り替わるため、新しい本番環境に切り替え可能
ワークロード次第だが、通常は 1分以内 にすばやく切り替えが可能

ユースケース

DBスキーマ変更

テーブルへのカラム追加やインデックスを作成するようなスキーマの変更などが可能
列名の変更やテーブル名の変更などのレプリケーションが貼れなくなってしまうスキーマ変更はできないので注意

バージョンアップ

異なるバージョン間でのBlue/Green Deploymentsが可能

制約事項

Aurora MySQL バージョン 2.08 と 2.09では利用できない
Blue環境に tmp という名前のデータベースを含められない
以下の機能ではサポートされていない
- Amazon RDS Proxy
- クロスリージョンリードレプリカ
- Aurora Serverless v1 DB クラスター
- Aurora Global Database の一部である DB クラスター
- AWS CloudFormation
RDS Blue/Green Deploymentsの変更に関する制約事項
- 暗号化されていない DB クラスターを暗号化された DB クラスターに変更はできない
- 暗号化された DB クラスターを暗号化されていない DB クラスターに変更はできない
- Blue環境 DB クラスターを、対応するGreen環境の DB クラスターよりも上位のエンジンバージョンに変更することはできない
- Blue環境とGreen環境のリソースは同じ AWS アカウントにある必要がある
- 切り替え時、Blue環境 DB クラスターを外部レプリケーションのターゲットにすることはできない

Blue/Green Deploymentsの利用

基本的な特徴やユースケース、制約事項をみていただきました。

ここからは、具体的なイメージが掴めるように、一般的なBlue/Green Deployments設定時のワークフローと DBアップグレードの検証を見ていきます。

検証環境

Blue環境
- クラスター : XXXXX-sre-mysql-bk-cluster
  - ライターインスタンス : XXXXX-sre-mysql-bk
  - リーダーインスタンス : XXXXX-sre-mysql-bkr
- バージョン : Amazon Aurora 2.07.3
- インスタンスサイズ : db.r5.4xlarge
Green環境
- クラスター : XXXXX-sre-mysql-bk-cluster-green-XXX
  - ライターインスタンス : XXXXX-sre-mysql-bk-green-XXX
  - リーダーインスタンス : XXXXX-sre-mysql-bkr-green-XXX
- バージョン : Amazon Aurora 2.07.9
- インスタンスサイズ : db.r5.4xlarge

1.Blue/Green Deploymentsを設定する本番環境を用意

構成イメージとしては下記となります。

Blue環境クラスター構成図

[検証手順]

Blue環境 DB クラスターおよびインスタンスを作成する

クラスター : XXXXX-sre-mysql-bk-cluster
- ライターインスタンス : XXXXX-sre-mysql-bk
- リーダーインスタンス : XXXXX-sre-mysql-bkr

2. Blue/Green でレプリケーションができるようにセキュリティグループを設定する

Blue環境とGreen環境では、論理レプリケーションを構築するため、お互いのセキュリティグループに 3306ポートで相互に通信できるような設定を追加しておく必要があります。

[検証手順]

お互いのセキュリティグループに 3306ポートで相互に通信できるような設定を追加

3. 本番環境のバイナリログ(binlog)を有効にする

Blue/Green Deploymentsは、レプリケーションが必要なため Blue環境でバイナリログの有効化が必要となります。バイナリログのフォーマットは、ROW が推奨されています。
ROWフォーマットは行ベースでのログであり、不整合のリスクを減らすことが可能ですが行ベースのためログへの書き込みが増えます。バイナリログの肥大化やディスク容量やI/O速度(IOPS)には注意しましょう。また、バックアップやリストア時にも影響する可能性があります。
なお、binglog有効にするためには、Auroraクラスターの再起動が必要です。

[検証手順]

binglogフォーマットを MIXED に変更し、Blue環境用のクラスターパラメータグループ(XXXXX-sre-mysql-bk)を用意
Blue環境 DB クラスターパラメータグループをXXXXX-sre-mysql-bkに「今すぐ適用」で変更
クラスタパラメーターグループの変更に「再起動を保留中」がスケジュールされていることを確認
Blue環境を再起動する

Binlogが有効になっていることを確認

MySQL > SHOW BINARY LOGS;
+----------------------------+-----------+
| Log_name                   | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 |       154 |
| mysql-bin-changelog.000002 |       154 |
| mysql-bin-changelog.000003 |       154 |
+----------------------------+-----------+
3 rows in set (0.00 sec)

MySQL > SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000003 |      154 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

4. Blue環境に接続をして、INSERT/UPDATEなどの更新系クエリを実行する

バイナリログを有効後に、INSERT/UPDATEなどの更新系クエリが実行されていない状態で、即座にデプロイメントを有効にし、レプリケーションを開始すると、 $\textcolor{red}{1つ目のバイナリログが消失し正常にレプリケーションが失敗するバグが存在}$ します。 ※2023.06 時点

Could not find first log file name in binary log index file

そのため、ワークアラウンドとして、バイナリログを有効後にINSERT文やUPDATE文を実行する必要があります。 なお、バイナリログを有効後に更新がある場合は対応不要です。

ワークアラウンドの検証結果
1. テストテーブルに対して、INSERT文を実行 → 成功
  ※その他の回避方法があるか検証したが、他に回避する方法は見つかりませんでした。
2. 何もしない -> 失敗
3. バイナリログをFLUSHする -> 失敗
4. バイナリログのリテンション(保持期間)を設定する -> 失敗

[検証手順]

INSERT/UPDATE などの更新系クエリの実行をする

INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2);
UPDATE t1 SET col1 = col1 + 1;

5. Blue/Green Deploymentsを作成

本番環境のBlue/Green Deploymentsの構成図です。Auroraクラスタ全体の構成全体をコピーしてGreen環境を作成されます。構成イメージとしては下記となります。作成タイミングで別バージョンのクラスタを作成することが可能です。
なお、Blue環境で保留されているメンテナンスは、バージョンアップや、OSパッチ適用が存在する場合は、Green環境作成するタイミングで、自動でアップグレードやパッチが適用されます。

Blue/Green 構成図

[検証手順]

Green環境の作成をする
- バージョンは、2.07.9 で作成
- binlog_format は OFFのクラスターパラメータグループで作成する
Green環境の初期作成 -> 2.07.3 で作成される
アップグレードが実行される - 2.07.3 -> 2.07.9
OSのパッチが適用される
利用可能

AWSマネジメントコンソール全体

Blue/Green 構成-AWSマネジメントコンソール全体

デプロイメント : XXXXX-bg-bk-deployment
Blue環境
- クラスタ : XXXXX-sre-mysql-bk-cluster
- ライターインスタンス : XXXXX-sre-mysql-bk
- リーダーインスタンス : XXXXX-sre-mysql-bkr

Blue/Green 構成AWSマネジメントコンソール-Blue環境

Green環境
- クラスタ : XXXXX-sre-mysql-bk-cluster-green-d9adzs
- ライターインスタンス : XXXXX-sre-mysql-bk-green-ulhvod
- リーダーインスタンス : XXXXX-sre-mysql-bkr-green-lbwddm

Blue/Green 構成AWSマネジメントコンソール-Green環境

6. Green環境に変更を加える

このタイミンングで、テーブルへのカラム追加やインデックスを作成するようなスキーマの変更やDBインスタンスクラスの変更が可能です。なお、列名の変更やテーブル名の変更などのレプリケーションが貼れなくなってしまうスキーマ変更はできないです。
※本記事の検証では、アップグレード時の利用検証を実施しているため、実施しておりません。

[検証手順]

スキーマの変更
- テーブルへのカラム追加
  - ALTER TABLE <table-name> ADD COLUMN <column-name> <data> <option>;
- インデックスを作成する
  - CREATE INDEX
DB インスタンスクラスを変更

7. Green環境のテストをする

Green環境に対してアプリケーションなどのテストをします。なお、Green環境にレプリケーションエラーとなるような更新が走ってしまう懸念があるためテスト中は、Green環境のデータベースを読み取り専用に保っておくことが推奨されています。

8. 切り替えの実施

切り替えを行うと、Green環境 DBクラスターは、DBインスタンスを含めて切り替えが始まり、本番環境のDBクラスターになります。
切り替え前は、本番環境のトラフィックはBlue環境 DB クラスターにルーティングされます。
切り替え後、本番環境のトラフィックはGreen環境 DBクラスターにルーティングされます。

理想的な条件下の推定所要時間は、ダウンタイムが1分程度、オペレーション含めると3分程度です。
※切替前にBlue環境への更新トランザクションが多く、Green環境へ未反映のトランザクションが多い場合(=レプリカラグが大きい) 場合は、差分の反映により、時間がかかる

なお、Blue/Green Deploymentsの制約として、Blue環境のエンジンバージョンは Green環境のエンジンバージョンよりも上位にすることができません。
そのため、再度Blue/Green Deploymentsを作って切り戻すようなことはできません。

[内部での切り替えの仕組み]

Blue/Green DBクラスターでのDB コネクション切断 (ダウンタイム開始)
切替事前チェックの実行
Green環境 DBクラスターへのレプリカラグがゼロになるまで待機(差分なしの状態になるまで待機)
Green環境 DBクラスターへのDB 名および、エンドポイントの切り替え
Green環境 DBクラスターでのDB コネクション受け入れ再開(ダウンタイム終了)

※COMMITを停止しておけば、レプリカラグ(差分)がもともと少ない状態となるので、所要時間が短くなる

[検証手順]

レプリケーションが正常か、遅延がないか確認する
```
SHOW (SLAVE|REPLICA) STATUS \G
```
クラスタを選択して、アクションから切り替えを実施
- AWSマネジメントコンソール
- アクションから「切り替え」を選択
- この例では、エンジンバージョンが異なる、Blue環境とGreen環境の切り替えを実施している
切り替えを実施するとステータスが全て「切り替えステータス」となる
切り替え完了

切り替えが完了するとデプロイメントのステータスが「切り替え完了となる」

Green環境=Blue環境のエンドポイントとなる
- Green環境のDBクラスターXXXXX-sre-mysql-bk-cluster-green-d9adzsは、本番DBクラスターXXXXX-sre-mysql-bk-clusterになる
- Green環境のDBインスタンスXXXXX-sre-mysql-bk-green-ulhvodは、本番DBインスタンスXXXXX-sre-mysql-bkになる
- Green環境の本番DBインスタンスXXXXX-sre-mysql-bkr-green-lbwddmは、本番DBインスタンスXXXXX-sre-mysql-bkrになる
Blue環境=old1識別子がつくようになる
- Blue環境のDBクラスターXXXXX-sre-mysql-bk-clusterは、ステージングDBクラスターXXXXX-mysql-bk-cluster-old1になる
- Blue環境のDBインスタンスXXXXX-sre-mysql-bkは、ステージングDBインスタンスXXXXX-sre-mysql-bk-old1になる
- Blue環境のDBインスタンスXXXXX-sre-mysql-bkrは、ステージングDBインスタンスXXXXX-sre-mysql-bkr-old1になる

9. 不要になったBlue/Green Deploymentsは削除

Blue/Green Deploymentsは、切り替え前または切り替え後に削除できます。

[検証手順]

XXXXX-sre-bg-bk-deploymentの削除を実施。
XXXXX-sre-mysql-bk-cluster-old1の削除
- XXXXX-sre-mysql-bk-old1 を削除
- XXXXX-sre-mysql-bkr-old1 を削除

[参考]アップグレード方式の比較

ここで、私が比較したアップグレード方式ごとの所要時間の比較とメリット・デメリットを参考として記載いたします。

	方法1:インプレースアップグレード	方法2:スナップショットからリストア	方法3:クローンを作成しアップグレード	方法4:RDS Blue/Green Deployments
アップグレード所要時間	67m	122m	120m	65m
差し戻し所要時間	55m	30m	30m	3m
メリット	オペレーションが少ない	---	---	アップグレードうまくいかない場合でも、切り替えの必要がない/事前にバイナリログを設定しておけば3分で切り替えが完了する
デメリット	バグによりうまくいかないリスクがある/うまくいかなった場合に解消を待たなければならない・差し戻しに一番時間がかかる	スナップショットはクローンよりも時間がかかる・切り替えタイミングで、2倍のコストがかかる	切り替えタイミングで、2倍のコストがかかる	バイナリログの設定時にRDS再起動が必要/切り替えタイミングで、2倍のコストがかかる

※db.r5.4xlargeの負荷がほぼ存在しない環境での、マイナーバージョンアップ時の比較
※性能・負荷・インスタンスサイズ/ メンテナンスの種類(マイナー or メジャーバージョンアップ)の違いにより正確な時間は異なりますので、あくまで目安としてご参考ください

Blue/Green Deploymentsのまとめ

事前にバイナリログを有効化できるのであれば、ダウンタイムが1分程度、オペレーション含めると3分程度で切り替え可能 (※理想的な条件下の推定所要時間)
事前にバイナリログを有効化する際は、有効化した際のログの容量,コストが発生することを考慮する
切り替えタイミングで、バイナリログを有効にする必要がある場合、更新系クエリを実行しないとレプリケーションできないバグが存在するので、注意が必要

まとめ

Amazon RDS Blue/Green Deploymentsについてご紹介させていただきました。
メリット・デメリットや注意点は存在しますが、うまく利用すれば、アップグレード作業時の所要時間の短縮、差し戻し時間の短縮につながるかと思います。制約事項や一時的なコスト増について問題がなければ、メリットが大きいので積極的に使っていくと良いなと思いました。

はじめに

対象読者

RDS Blue/Green Deployments for Auroraについて

前提

RDS Blue/Green Deployments for Auroraとは

動作要件

特徴

ユースケース

DBスキーマ変更

バージョンアップ

制約事項

Blue/Green Deploymentsの利用

検証環境

1.Blue/Green Deploymentsを設定する本番環境を用意

[検証手順]

2. Blue/Green でレプリケーションができるようにセキュリティグループを設定する

[検証手順]

3. 本番環境のバイナリログ(binlog)を有効にする

[検証手順]

4. Blue環境に接続をして、INSERT/UPDATEなどの更新系クエリを実行する

[検証手順]

5. Blue/Green Deploymentsを作成

[検証手順]

6. Green環境に変更を加える

[検証手順]

7. Green環境のテストをする

8. 切り替えの実施

[検証手順]

9. 不要になったBlue/Green Deploymentsは削除

[検証手順]

[参考]アップグレード方式の比較

Blue/Green Deploymentsのまとめ

まとめ

参考

Discussion