Aurora V2（MySQL5.7互換）のバージョンアップ方法についてまとめてみた。
概要
Auroraのバージョンアップ、してますか？
本家のMySQL5.7は2023年10月にEOLを迎えます。
AuroraV2(MySQL5.7互換)エンジンについては2024年10月にEOLです。
そこでAuroraのバージョンアップについて色々調べていくと、方法が何個かあることに気づくと思います。
調査していくうちに、"方法とメリット・デメリットを比較しながら検討したい！" という欲求にかられました。なので、メモがてらまとめたものをシェアします。
あくまでAuroraのバージョンアップ手法についてまとめているので、MySQLのバージョンアップに伴う差分については都度ご自身でも調査してくださいね。
バージョンアップ方法
結論から言うと、バージョンアップの方法は主要なもので
- インプレースデプロイ
- Bule/Greenデプロイ
- スナップショットからの復元
の3択かなと思いました。以下で一つずつ解説していきます。
インプレースデプロイ
現行で動いているDBインスタンスそのものを洗い替えるデプロイ手法です。
昨年Aurorav2->v3(MySQL5.7→8.0)にも対応したので、コンソール画面からAurora Clusterの設定をポチッと変えるだけで反映されます。
メリット👍
- エンドポイントが変わらない
- 作業が圧倒的に楽
デメリット
- 作業がメンテ作業時間にしか行えない
- 時間がかかる
- 問題が生じて切り戻しが発生した際、snapshotからDBを復元する必要がある。（要メンテナンス前snapshot）
Blue/Greenデプロイ
こちらは機能そのものが昨年発表されたものになります。
その名の通り新環境を予め作成して作業時に環境の切り替えを行います。
Green環境はBlue環境の論理レプリケーションとなっているので、差分は自動的に反映されていきます。
Green環境のエンドポイントへ接続して動作確認をして、問題が生じなければGreenをデプロイします。
その時、Greenのエンドポイントが自動的にBlue環境のエンドポイントに切り替わるため、アプリケーションの修正なしにDBをアップデートすることができます。
メリット👍
- エンドポイントが変わらない
- Green環境を事前に作成しておけば、移行時の作業はGreen環境の確認とデプロイだけで作業が完了する。
デメリット
- デフォルトのパラメーターグループでは有効になっていない、
binlog_format = mixedという設定を有効化しないと使えない- さらにこちらの設定を有効化するためにDBの再起動が必須
スナップショットからの復元
Auroraはスナップショットを簡単に取得することができて、そのスナップショットからインスタンスの復元もコンソール上から簡単に行うことができます。
メンテナンス直後にスナップショットを取得→インスタンスの作成を行うことで現状のインスタンスとは別に新たなAuroraクラスターを作成できます。
あらたなAuroraクラスターを作成時にAuroraのバージョンを選択できるので、ここで新しいバージョンのクラスターを作成すれば新環境の完成です。アプリケーションの参照DBを新環境に向ければ今のインスタンスを生かしつつ新しい環境が完成します。
メリット👍
- 新環境デプロイ後も、旧環境・新環境のAuroraクラスターが共存できる。
デメリット
- DBのデータサイズによっては新Auroraクラスター作成に時間がかかる
- メンテナンス前に確認することをおすすめします。
- また、リードレプリカが必要な場合クラスター作成後に追加で時間がかかります。
- DBのエンドポイントが変更されるため、アプリケーションにも修正が必要。
まとめ
ここで紹介したもの以外にも、DMSなどのマイグレーションツールを使った方法があるかと思いますが、主要な選択肢は紹介できたかなと思っています。
総じて、完全ノンマネージドなデータベースをアップデートするよりかは簡単になっているのかな？というのが新米エンジニアの正直な感想です。
マネージドサービスとはいえ、バージョンアップは避けられない過大なので、チームで相談しながらしっかりとやっていきたいですね。
参考記事
ちょっと古いです。
Discussion