Amazon RDS Blue/Green Deployments を使ってみた

はじめに

最近 Amazon RDS Blue/Green Deployments なるものがリリースされました。今回は実際に Blue/Green のスイッチオーバーまでやってみました。

検証準備

Aurora MySQL クラスターの準備。最初 MySQL8.0系を選択しましたが、こちらは対応しておりませんでした。ちゃんとドキュメント読んでからやりましょう。今回は MySQL5.7系で起動しておきます。
パラメータグループを編集して、バイナリログを有効化します。(binlog_format → MIXED)

参考 : https://aws.amazon.com/jp/blogs/news/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/

検証開始

クラスターを選択し、「アクション」から「ブルー/グリーンデプロイの作成」をクリックする。

ブルー/グリーンデプロイの作成画面にて、「Blue-Green 環境識別子」を入力する。今回は推奨とあるので、MySQL8.0系へのスイッチオーバーを実施してみる。(失敗フラグ)

「Green DB インスタンスの月額料金の見積もり」も出してくれるのでとても安心できますね。内容に問題が無ければ、「ステージング環境の作成」をクリックします。

しばらくして、「Blue-Green 環境の作成に失敗しました」とエラーが表示されました。

エラーステータスでロールが「ブルー/グリーンデプロイ」となっているリソースを選択し、「ログとイベント」で確認してみると、今回ブルー環境で指定した t3.small は MySQL8.0系インスタンスがサポートしていないタイプなので起動できていない事がわかりました。(じゃあ、推奨で。と突き進み、無事フラグ回収)

ちなみに、起動している様に見えるグリーン環境は MySQL5.7系で起動されていました。笑
一旦「ブルー/グリーンデプロイ」ロールを削除し、ブルー環境と同バージョンで再挑戦。

次はうまく行ったようです。特にエラー無くグリーン環境が作成されたました。

グリーン環境のクラスターに MySQL クライアントで接続してみます。

MySQL > show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.23.15.0
Master_User: rdsrepladmin
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000004
Read_Master_Log_Pos: 154
Relay_Log_File: relaylog.000004
Relay_Log_Pos: 273
Relay_Master_Log_File: mysql-bin-changelog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table: mysql.rds_replication_status,mysql.rds_monitor,mysql.rds_sysinfo,mysql.rds_configuration,mysql.rds_history
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 592
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1770043869
Master_UUID: dd0bf094-bc87-3287-81fe-6c29fcc3c712
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.02 sec)

MySQL >

やはり、普通に MySQL レプリケーションが設定されていました。正常にレプリケーションができている事がわかったので、「アクション」から「切り替え」をクリックします。

切り替えの概要、レプリカ設定の詳細を確認します。タイムアウトの設定は、切り替えにかかる制限時間を指定できます。この時間をすぎるとスイッチオーバーはされません。では、切り替えをクリックします。

スイッチオーバーが完了すると、下記のよう状態になります。database-1 が database-1-old1 に名前変更され、staging-database-1 が database-1 に名前変更されるイメージでしょうか。これを手動でやると名前変更時にインスタンス再起動が走るので、そのあたりはブルー/グリーン両方で一時的に書き込みをロックし、データの整合性を保った上で名前変更処理をマネージドサービス内でうまいことやってくれてる感じなんですかね。