🤗

[AWS]Amazon Aurora Blue/Green Deployments を試したら幾つかハマった、がしかし最高の機能だと実感した

zenn_kurara

2023/07/25に公開

目的

Amazon Aurora Blue/Green Deployments を実際に触ってどういう機能か実体験する

環境

Aurora MySQL 3.03.1 (compatible with MySQL 8.0.26)
db.t4g.medium
１クラスター１インスタンス
RDS Proxy　なし
- ２０２３年７月現在、対応してない

さわってみる

想定ケース

MySQL５系からMySQL８系へのアップロードを想定
５系と８系で以下を変更する
- MySQLエンジンバージョン
- クラスターパラメータグループ
- インスタンスパラメータグループ
Blue/Green Deployments 稼働中に以下を実施し検証を行う
4. 5系に新規テーブルを追加
5. 5系に新規カラムを追加

検証用クラスターおよびインスタンス作成

構成

項目	値
エンジンタイプ	Aurora MySQL
エンジンバージョン	Aurora (MySQL 5.7) 2.11.3
インスタンス	db.t3.small
クラスターパラメータグループ	default.aurora-mysql5.7
インスタンスパラメータグループ	default.aurora-mysql5.7
暗号化	有効
ログのエクスポート(CloudWatch Log)	監査, エラー, 全般, スロークエリ

上記構成をベースにクラスターおよびインスタンスを作成

検証用データベースおよびテーブルの作成

事前に踏み台サーバー用に使用するEC2をセットアップ
- 詳細設定は割愛

データベース

CREATE DATABASE test_db;

テーブル

use test_db;

create table user (
	id int NOT NULL AUTO_INCREMENT,
	name varchar(20) NOT NULL,
	PRIMARY KEY (id)
);
create table item (
	id int NOT NULL AUTO_INCREMENT,
	name varchar(20) NOT NULL,
	PRIMARY KEY (id)
);
create table order_history (
	id int NOT NULL AUTO_INCREMENT,
	user_id int,
	item_id int,
	price int,
	PRIMARY KEY (id)
);

初期データ

use test_db;

insert into user (name)
values ('user1'), ('user2'), ('user3');

insert into item (name)
values ('item1'), ('item2'), ('item3');

insert into order_history (user_id, item_id, price)
values ('1', '1', 100),('2', '2', 200), ('3', '3', 300);

Blue/Green Deployments 作成

クラスター画面を開く
「アクション」から「ブルー/グリーンデプロイの作成 - 新規」を選択
「ブルー/グリーンデプロイ識別子」に任意の名前を入力
- ex) mybgdeployment
「グリーンデータベースのエンジンバージョン」は 8.0.mysql_aurora.3.03.1 - 推奨 を選択
「グリーンデータベースの DB クラスターパラメータグループ」は default.aurora-mysql8.0 を選択
「グリーンデータベースの DB パラメータグループ」は default.aurora-mysql8.0 を選択
「ステージング環境の作成」を押下

作成出来なかった・・・・
エラーは以下

機械翻訳

Blue/Green デプロイメントでは、論理レプリケーションが有効になっている DB クラスターが必要です。 
DB クラスターの Blue/Green デプロイメントを作成する前に、
論理レプリケーションを有効にするカスタム DB クラスターパラメーターグループに DB クラスターを関連付けます。

レプリケーション元となるクラスターの「バイナリログONにしろよ！」ってことですね
自分が書いた記事の「作成条件」にもまとめてました

バイナリログ有効化

どうやってバイナリログを有効化するか
「クラスターパラメータグループ」の binlog_format を変更する
設定後インスタンスの再起動が必要

クラスターパラメータグループの作成

メニューから「パラメータグループ」を選択
「パラメータグループの作成」を押下
「パラメータグループファミリー」は aurora-mysql5.7 を選択
DB Cluster Parameter Group を選択
「グループ名」に任意の名前を入力
- ex) test-cluster-parameter-group
「説明」に任意に入力
「作成」を押下

binlog_format　の変更

パラメータグループ一覧を表示
作成した「test-cluster-parameter-group」にチェックを入れる
「アクション」から「編集」を選択
検索窓に binlog_format を入力
「値」に ROW を入力
ラジオボタンにチェックをいれて　「Save Changes」を押下
binlog_format を検索して値が変更されていること

クラスターインスタンスのパラメータグループ変更

データベース一覧を表示
変更対象のクラスターにチェックを入れる
「変更」ボタンを押下
「DB クラスターのパラメータグループ」にて上記で作成したパラメータグループを選択
「続行」を押下
「変更のスケジュール」を「すぐに適用」に変更
「クラスターの変更」を押下
クラスターの「設定」タブで「DB クラスターのパラメータグループ」が変更されていることを確認

インスタンスの再起動

データベース一覧を表示
再起動対象のインスタンスにチェックを入れる
「アクション」から「再起動」を押下
「確認」を押下

※本稼働インスタンスで実施する場合はもっと慎重に行いましょう
※再起動すると一時的にダウンタイムが発生する可能性が高くサービス影響出るので要注意

再度 Blue/Green Deployments 作成

上の方の手順で再度 Blue/Green Deployments 作成を行う

はい、またエラーになりました！！！

db.t3.small はダメですって！！！

機械翻訳

RDS は、
DBInstanceClass=db.t3.small、
Engine=aurora-mysql、
EngineVersion=8.0.mysql_aurora.3.03.1、
LicenseModel=general-public-license の組み合わせでの 
DB インスタンスの作成をサポートしていません。
サポートされているインスタンス クラスとデータベース エンジンのバージョンの組み合わせについては、ドキュメントを参照してください。

しょうがないので、記事時点で８系がサポートしている最小インスタンスサイズ db.t3.medium に上げます。・

インスタンスサイズ変更

データベース一覧を表示
インスタンスサイズ変更対象のインスタンスにチェックを入れます
「変更」ボタンを押下
「DB インスタンスクラス」にて db.t3.medium を選択
「続行」を押下
「変更のスケジュール」を「すぐに適用」に変更
「DB インスタンスを変更」を押下

※本稼働インスタンスで実施する場合はもっと慎重に行いましょう

再再度 Blue/Green Deployments 作成

上の方の手順で再度 Blue/Green Deployments 作成を行う
- ここまでで以下の対応を実施
  - クラスターパラメータグループを変更
  - インスタンスサイズの変更

今度はエラーなく成功！！

作成完了すると以下のようになる

Blue/Green　Deploymentsの下にコピーされたクラスター、インスタンスが作成される

Blue/Green 間のレプリケーション確認

Blue : レプリケーション元
Green : レプリケーション先

Greenの状態確認

Blue/Green Deployments 作成直後のDB状態を確認する

-- 踏み台サーバー
-- GreenのAuroraインスタンスにログイン
mysql -h xxxx -u xxx -pxxx

use test_db;

select * from user;
select * from item;
select * from order_history;

Blueのデータが全てコピーされていることを確認した

レプリケーションの確認

データ追加、テーブル追加などを行いレプリケーションされることを確認

-- BlueのAuroraインスタンスにログイン
mysql -h xxxx -u xxx -pxxx

use test_db;

-- データ追加
insert into user (name)
values ('user4');

insert into item (name)
values ('item4');

insert into order_history (user_id, item_id, price)
values ('4', '4', 400);

-- テーブル追加
create table user_address (
	id int NOT NULL AUTO_INCREMENT,
	user_id int NOT NULL,
	address varchar(100) NOT NULL,
	PRIMARY KEY (id)
);

-- カラム追加
ALTER TABLE user_address ADD post_number int NOT NULL AFTER address;

-- GreenのAuroraインスタンスにログインしてデータレプリケーションされているか確認

追加したデータ、テーブル、カラムはGreenにちゃんとレプリケーションされていることを確認した
今回追加したデータ、テーブル、カラムの数であれば「一瞬」でGreenにレプリケーションされる
レプリケーション遅延はCloudWatchメトリクス AuroraBinlogReplicaLag で確認可能
- 今回の検証ではメトリクスは常に「0」となっていた

切り替え

切り替え前の確認（ベストプラクティス）は以下を参照

切り替え手順

データベース一覧を表示
Blue/Green Deployments にチェックを入れる
「アクション」から「切り替え」を選択
切り替え前のBlue/Greenそれぞれの設定が確認できるので最終確認する
５. 「タイムアウトの設定」の設定はデフォルト
- １つクエリ実行実感が長く「レプリカラグ」が長くなるケースはタイムアウトを伸ばして対処する
- タイムアウトすると切り替えがロールバックされる
「切り替え」ボタンを押下

切り替え実行して暫くするとBlueの接続が切れる
Blueのクラスター/インスタンス名には末尾に -old が付加される
Greenのクラスター/インスタンス名はBlueの元の名前に変更される

切り替えが完了すると以下の様になる
今回の検証では「１分程度」で切り替えが完了した

切り替え後確認

CLI接続でのコネクションはどうなるか
- Blueに接続していたものは切り替え実行してすぐに切断された（クラスターエンドポイントで接続中）
- Greenに接続していたものは接続維持された
ダウンタイム時間はどれくらいだったか
- １分程度
- レプリケーションラグが長くなるとその分時間がかかる
データは全てレプリケーションされているか
- レプリケーションされた
エンドポイントはどうなるか
- GreenのエンドポイントはBlueのエンドポイントに切り替わる
- アプリケーションからはエンドポイントを意識する必要はない
Blueはどうなるか？
- 名前変更されてそのまま残る
- お金もかかっている
- なので切り替えが完了したら計画的に早めに削除するのが良さそう

Blue/Green Deployments 削除

切り替えが完了したので削除する
Blue/Green Deployments を削除してもクラスター/インスタンスはそのまま残る

削除手順

データベース一覧を表示
Blue/Green Deploymentsにチェックを入れる
「アクション」から「削除」を選択
delete me を入力し「削除」を押下

削除は数分で終わる

Blueクラスター/インスタンスの削除

残していても２倍お金かかるので削除する

削除手順

データベース一覧を表示
Blueのインスタンスにチェックを入れる
「アクション」から「削除」を選択
「最終スナップショットを作成」は適宜チェックを入れる
delete me を入力して「削除」を押下

インスタンスが全て削除されたらクラスターも一緒に消える

Blue/Green Deployments をやってみて

ハマりどころ

Blueとなるクラスターでは事前に binlog_format の設定が必要
- 要再起動
MySQL８系にする場合インスタンスサイズの最小は db.t3.meduim （２０２３年７月現在）
その他幾つか制限事項があるので要注意
- 制限事項抜粋

所感

数クリックで完全コピーされたクラスター/インスタンスが出来上がるのは感動
- ちまちま設定を確認して同じインスタンスを立てる事を考えたら失敗リスク/作業工数が激減
データレプリケーションが自動構築されるのは神！！！！マジ神！！！！
- 自分で構築すること考えたら本当に再考
レプリケーションがほぼ即時反映なのでよっぽどじゃない限り切り替え時間も数分以内で終わるんじゃなかろうか

本当に最高の機能であると実感しました。
今後、機会があれば本稼働しているサービスで活用したいと思います。

株式会社THIRD エンジニアブログPublication

IT化が遅れがちなレガシー産業の一つである不動産管理に対して、原価削減・業務効率化・利益創出を実現するSaaSプロダクトを開発しています。実際に利用している技術を中心に投稿していく予定です

目的

環境

さわってみる

想定ケース

検証用クラスターおよびインスタンス作成

構成

検証用データベースおよびテーブルの作成

データベース

テーブル

初期データ

Blue/Green Deployments 作成

バイナリログ有効化

クラスターパラメータグループの作成

binlog_format の変更

クラスターインスタンスのパラメータグループ変更

インスタンスの再起動

再度 Blue/Green Deployments 作成

インスタンスサイズ変更

再再度 Blue/Green Deployments 作成

Blue/Green 間のレプリケーション確認

Greenの状態確認

レプリケーションの確認

切り替え

切り替え手順

切り替え後確認

Blue/Green Deployments 削除

削除手順

Blueクラスター/インスタンスの削除

削除手順

Blue/Green Deployments をやってみて

ハマりどころ

所感

Discussion

binlog_format　の変更