Amazon Aurora MYSQLのバージョン更新にBlue/Green Deploymentsを利用した話
# はじめに
Amazon Aurora MySQL 互換エディションバージョン 1(MySQL 5.6)から Aurora MySQL バージョン 2 (MySQL 5.7 互換)に更新した調査内容、実施した内容をまとめたものです。
実行の記録して残しているものなので、正確さに欠ける箇所もあるかと思いますでの参考程度に見てください。
# バージョン更新した経緯
バージョンを更新した理由としては現在利用しているバージョンのサポートが終了するためです。
2023 年 2 月 28 日 – これ以降、次のスケジュールされたメンテナンス期間内に Aurora MySQL バージョン 1 のクラスターを Aurora MySQL バージョン 2 のデフォルトバージョンに自動的にアップグレードする予定です。Aurora MySQL バージョン 1 DB スナップショットを復元すると、復元されたクラスターが Aurora MySQL バージョン 2 のこの時点のデフォルトバージョンに自動的にアップグレードされます。
Amazon Aurora MySQL 互換エディションバージョン 1 のサポート終了に向けて準備する - Amazon Aurora
上記の通り 2 月 28 日以降のメンテナス期間に自動でアップグレードされます。 事前に本番環境での動作確認、バージョン更新のタイミングをコントロールしたいため手動で更新することにしました。（aws も事前の確認を推奨しています。）
# Blue/Green Deployments を選んだ経緯
選択肢としてはインプレースアップグレードと Blue/Green デプロイメントがありました。
Aurora MySQL 1.x から 2.x へのアップグレード
今回は不特定多数のユーザーに使われているサービスでの db 更新だったためダウンタイムを短くしたいため、Blue/Green Deployments を選択しました。
ただ制約事項もあるので全てのケースで対応できるわけではないです。
Blue/Green Deployments 機能を利用せずにダウンタイムをなくす方法
Performing major version upgrades for Amazon Aurora MySQL with minimum downtime
自前で Green 環境（リードレプリカ）を作成し切り替える方法も紹介されています。 Blue/Green デプロイメントが利用できない環境下でもダウンタイムを短くしてアップグレード実行したいケースで利用できそうでした。
# バージョン更新の手順
新機能 – Amazon Aurora と Amazon RDS でのフルマネージド型 Blue/Green Deployments
# binlog_format を MIXED に更新
おそらくレプリケーションのために必要な設定かと思われます。 クラスターのパラメーターグループを更新することで変更可能です。 ただ、binlog_format は静的パラメーターのため再起動をして適用する必要があります。
# 更新バージョンに対応したパラメーターグループを用意する
- 自前で作成したパラメーターグループを利用している場合は,その変更箇所を特定して作成する必要がある
MySQL 5.6 で変更していた箇所
MySQL 5.7 で変更した箇所
MySQL のバージョンが変わると設定のデフォルト値が変更されていることもあり特に設定する必要のない項目などがあったので確認するといいと思いました。
- デフォルトのパラメーターグループの値で、デフォ値が変わっている箇所を調査する やった方がいいと思いつつ特に調査をしていないです。
# Green 環境の作成
特に特筆することなかったですが、binlog_format の設定が MIXED になっていないとエラーで作成できませんでした。
# Greee 環境へのデーターベースのレプリケートの確認
自動的にレプリケートされる仕様ですが、Green 環境を作成したときに同期されていませんでした。（新規作成したレコードが Green 環境に反映されていなかったのです。） 怪しそうな箇所としては、Green 環境を作成する際のバージョンの指定を更新前と合わせていませんでいた。 一度 Green 環境を削除して、バージョンを合わせて作り直したら無事同期されていることが確認できました。 ただ、これが直接的な原因は分からないです。
# Green 環境のバージョンを更新
特に特筆することなかったです。
# Green 環境のバージョン更新後のデーターベースのレプリケートの確認
特に特筆することなかったです。
# スイッチオーバー
切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。
公式のドキュメントには切り替えの時間は 1 分以内と書かれていましたが、実際に切りかえにかかった時間は 2〜3 分程度でした。（目視）
切り替え時にアプリケーションのログを見ていましたが、データベースの接続に失敗しているログが数件確認できました。（記憶ベース）
# 感想
Blue/Green Deployments が利用できる環境で少しでもダウンタイムの影響が気になるなら、Blue/Green Deploymentsを選択するのがいいと感じるぐらいお手軽に実行できました。