弊社で利用しているMySQLのバージョンをMySQL5.7からMySQL8にアップグレードを行いました。その際に Blue/Green Deploymentsを使って実施する際にに調べた事をまとめて紹介したいと思います。
Blue/Green Deploymentsとは
現状の本番環境（Blue）を別に新しい本番環境（Green）を構築した上で接続先を切り替えるなどして新しい本番環境をリリースする運用方法です。
利点として
システムのダウンタイムを短くできる
ロールバックが容易
が挙げられます。
Amazon RDS Blue/Green Deploymentsの仕組みとしては、本稼働環境(以下Blue環境)と本稼働環境のコピー(以下Green環境)を作成し、Blue環境とGreen環境は論理レプリケーションを使用し同期を行いBlue/Green環境を構築しています。
制限事項
公式情報
- MySQL バージョン 8.0.13 以前には、RDS がBlue/Green Deploymentsをサポートできないというコミュニティバグがあります。
- Blue/Green Deploymentsは、以下の機能ではサポートされていません。
- Amazon RDS Proxy
- カスケードリードレプリカ
- クロスリージョンリードレプリカ
- AWS CloudFormation
- マルチ AZ DB クラスター配置
- Blue/Green Deploymentsの変更に関する制約事項
- 暗号化されていない DB インスタンスを暗号化された DB インスタンスに変更することはできません。
- 暗号化された DB インスタンスを暗号化されていない DB インスタンスに変更することはできません。
- Blue環境の DB インスタンスを、対応するGreen環境の DB インスタンスよりも上位のエンジンバージョンに変更することはできません。
- Blue環境とGreen環境のリソースは同じ AWS アカウントにある必要があります。
- 切り替え時、Blueプライマリ DB インスタンス を外部レプリケーションのターゲットにすることはできません。
- ソースデータベースがカスタムオプショングループに関連付けられている場合、Blue/Greenデプロイを作成するときにメジャーバージョンアップグレードを指定することはできません。この場合、メジャーバージョンアップグレードを指定せずにBlue/Greenデプロイを作成できます。その後、Green環境のデータベースをアップグレードできます。
検証した方々の情報
- MyISAMを使っているとBlue/Greenを使用できない
- サブネットグループをアベイラビリティゾーン3azで定義していないとBlue/Greenの作成に失敗する
- 旧クラスタ・インスタンスを削除する際にBlue/Greenデプロイのロールから削除しないと消せなくなる
- 切り戻しはできない
- binlog_formatがMIXEDになっている必要がある
- バイナリログを使用したレプリケーションを伴うので、バイナリログ出力を有効にしておく必要がある
- Blue環境への書き込みがGreen環境に反映されないことがある
- Green環境の作成が終わらないことがある
- パラメータグループの適応がされていないと作成に失敗する
- db.t3.smallを使ったAuroraクラスターでV3へのバージョンアップを含めた環境構築はできない。
- Green環境作成前のBlue環境に対する何らかの書き込み操作が必要
- レプリケーション先（Green側）が参照しようとするバイナリログがレプリケーション元（Blue側）に存在しないことで起きてしまうエラーであり、Amazon RDS Blue/Green DeploymentsにおいてAWS側の内部動作上の問題
- バイナリログの出力を有効にしたのち、Green環境作成前にBlue側のデータベースに対して何かしらの書き込み処理を行う必要がある
- Green環境作成時にDBの停止は発生しない
- CPUの負荷は少し(5～10%)増加する
- Green環境作成時間は物による
- 切り替え時の停止時間について
- 書き込み2分、読み込みは数秒
参考文献
実際に検証をしてみてわかったこと
- MyISAMを使っているとBlue/Greenを使用できない
作成できなかった
- サブネットグループをアベイラビリティゾーン3azで定義していないとBlue/Greenの作成に失敗する
2azでも作成が可能
- 旧クラスタ・インスタンスを削除する際にBlue/Greenデプロイのロールから削除しないと消せなくなる
どちらからでも削除ができた
- 切り戻しはできない
切り戻す際に、旧RDSのパラメーターグループ項目のread_onlyを変更しないとReadOnly設定の解除ができない。 ※切り戻しのやり方に関しては本記事では割愛
- db.t3.smallを使ったAuroraクラスターでV3へのバージョンアップを含めた環境構築はできない。
db.t3.smallを使用しているクラスターでの環境構築はできなかった
- Green環境作成時にDBの停止は発生しない
発生しなかった
以下、弊社のユースケースで問題にはならなかった為検証をしていない。
- binlog_formatがMIXEDになっている必要がある
- Blue環境への書き込みがGreen環境に反映されないことがある
- Green環境の作成が終わらないことがある
- Green環境作成前のBlue環境に対する何らかの書き込み操作が必要
- Green環境作成時間は物による
- 切り替え時の停止時間について
以下、調査ではわからなかったが検証してみた結果判明した事 * バックアップの手段がAWSバックアップだとBlue/Green環境が作成できない
検証を踏まえて、実施する際にチェックする箇所
インスタンスタイプがdb.t3.smallかどうかをチェック【Aurora限定】
- db.t3.smallの場合はインスタンスタイプを変更する【Aurora限定】
対象のRDSのバイナリログが有効化されているかチェック
- 有効化されていない場合は有効化を行う（要再起動）
binlog_formatがMIXEDになっているかチェック
- MIXEDになっていない場合は変更をする（要再起動）
自動バックアップが有効であることをチェック
- 有効でない場合は有効化する（要再起動）
charactor_set系、collation系のパラメータ確認をする
- MySQL5.7のデフォルトはutf8mb4_general_ciで、MySQL8のデフォルトはutf8mb4_0900_aiなので切り替えるにあたってパラメータを調整する必要がある
まとめ
今回MySQLのアップグレードをBlue/Green Deploymentsでやってみようと言う事でいろいろと調査してみました。
事前の確認、設定が非常に大事だなと言うのが調査、検証してみてわかりました。
後日、実践編にてBlue/Green Deploymentsを使用してアップグレードを実際に行った際の手順や調査では発覚しなかった点を報告したいと考えています。
