Aurora MySQLのBlue/Green Deploymentでマイナーバージョンアップした手順と注意点
概要
先日AWS Aurora MySQLのBlue/Green Deploymentを用いてエンジンのバージョンアップを行ったので、振り返りも兼ねて手順をまとめます。
違った認識があれば教えていただけると幸いです。
ステージでのテストなど、バージョンアップ作業全体の手順は未記載です。
ちなみに今回私は、Aurora MySQLの3.04系から3.10系のマイナーバージョンアップを行いました。
あくまで自分の用意した手順になるので参考までに。
Blue/Green Deploymentとは
現状の環境（Blue環境）と切り替え先の環境（Green環境）を用意し、最終的にルーティングを変えることでダウンタイムを最小限にして反映するデプロイ手法です。
AuroraではこのBlue/Green Deploymentが機能として用意されているので、これらを使うことで簡単にバージョンアップを行うことができます。
手順
- バージョンアップ対象の確認
- クラスタのパラメータを確認し、必要であればパラメータを更新
- クラスタのアクションからBlue/Green Deploymentの作成を行う
- 切り替えを行う
- 旧リソース削除
1. バージョンアップ対象の確認
対象のリソースを確認します。
また、これらのバージョンアップ先を把握しておきます。
2. クラスタのパラメータを確認し、必要であればパラメータを更新
現在動いている環境のクラスタ（対象の環境Blue環境となるクラスタ）のパラメータグループから、binlog_formatの値を確認します。
このbinlog_formatがROWかMIXEDにする必要があります。
これはレプリケーションを行うために必要な設定になるので必須となります。
AWSではROWを推奨していますが、メリデメあるので状況次第ではMIXEDでも良いと思います。
※パラメータ自体はstaticになるので、DBを一度再起動する必要があります。
3. クラスタのアクションからBlue/Green Deploymentの作成を行う
作成画面では、Green環境の設定を行います。バージョンアップ先などを入力します。
作成が完了すると設定したバージョンのクラスタとインスタンスが立ち上がります。
Blue/Green Deployの枠の中にBlue環境とGreen環境ができる状態となると思います。
このGreen環境は自動でBlue環境のレプリケーション設定がされています。
必要であればGreen環境に接続し、レプリケーションを確認します。（例えばBlue環境に書き込みを行い、Green環境でもその変更が確認できるかどうか。など）
ここでREADのクエリであればテスト可能です。
4. 切り替えを行う
Blue/Green Deployのアクションから「切り替え」を選択します。
タイムアウト時間の設定（切り替え作業がうまく行かず、時間がかかったときにタイムアウトとする時間）など切り替え時の設定ができるので、これらの値を決め、開始します。
開始すると、AuroraがDBへ接続するためのエンドポイントをBlueとGreenで入れ替えてくれます。
同時にBlue環境をread onlyに変更し、Green環境のread onlyを解除します。
そのため、アプリケーションからは自動でGreen環境に接続されます。
注意点としては、アプリケーション側でBlue環境のIPをキャッシュしている可能性があることです。
切り替えはエンドポイントのみなので、IPで接続していた場合はそのままBlue環境に接続してしまいます。
そのため、Blue環境はread onlyにされるので、書き込みクエリが発生した場合はエラーとなります。
また、Green環境のレプリケーションを受けない状態になるのでデータが不整合となる可能性があります。
アプリケーションサーバーを再起動するなどしてGreen環境に接続できるようにしましょう。
5. 旧リソース削除
反映を行い問題なさそうであれば、旧リソースの削除を行っていきます。
まずBlue/Green Deployの枠を削除します。
そして、Blue環境（旧環境）を削除します。
切り替え後、Blue環境は実質使われていない環境なので、コスト削減のためにも早めの削除をおすすめします。
私の場合はロールバックの可能性があると思い、数日様子を見た後に削除しました。
ロールバックについて
接続が出来ないなどの場合はロールバックを行います。
※実際に行ったわけではないので、用意している手順になります。
- Blue/Green deployの枠を削除します
- Blue環境のread onlyを解除します
- Blue環境のDBへのエンドポイントを元々のBlueのものに戻します（重複できないので、Greenを適当なものに変更し、Blueを元のものにします。）
Blue環境は切り替え後にGreenのレプリケーションを行っていないので、切り替え時からのデータは損失してしまいます。
反映後は本番環境をウォッチ
Blue/Green Deploymentではないですが、DBバージョンアップ後の注意点です。
今回はAurora MySQLのマイナーバージョンアップでしたが、このエンジンで動いているMySQL自体はパッチバージョンが上がっています。
この影響で、パフォーマンス問題で一部処理が落ちてしまっていました。
（その後クエリ改善を素早く行い、改善しました。）
本番同等のデータ量やトラフィックを用意するのはかなりコストがかかるため、私は行いませんでした。
できる場合はテストしまくれば良いのですが、難しい場合ややらない判断をした場合はしっかり本番の状況を監視しましょう。
テストした場合でも想定外のことは起こるので監視するに越したことはありません。
詳細
ある処理がすべてエラーと落ちしていたため気づきました。
エラー内容: Mysql2::Error: Out of sort memory, consider increasing server sort buffer size
これはレコード数が多いテーブルへの検索でDISTINCTとORDER BYを使っていたため、sort_buffer_sizeが不足したというものでした。
オプティマイザの挙動変更が原因と推測しています。
実際に使われている処理では最終的にcountを使っているだけだったので、order byは不要と判断し、これらを除外することでエラーを回避しました。
まとめ
実は約一年前にも別プロダクトのAurora MySQLのマイナーバージョンアップを行いました。
このときに手順をまとめていたのですが、パラメータの更新やBlue/Green Deployment機能を理解しきれていませんでした。
手順も不安だったので、これが誰かの役に立てば嬉しいです。
といってもとても簡単にでき、ダウンタイムも最小限なのでとても嬉しい機能です。
ありがとうございます。
Discussion