サービス開発部スケールアーキテクトチームの inosy22 と nghr と shgx です。
本記事では、Blue/Green Deployments を利用してAmazon Aurora MySQLを5系から8系へバージョンアップする際に直面した注意すべきポイントについて、トラブルシューティング形式で解説していきます。
1. 経緯
2024年8月現在、Amazon RDSとAurora MySQL 5.7のサポート終了が発表されています。具体的には、Amazon Aurora MySQL 互換エディション バージョン 2（MySQL 5.7互換）は、2024年10月31日に標準サポートを終了する予定です。
Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換) は 2024 年 10 月 31 日に標準サポートを終了する予定
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL57.EOL.html
これに伴い、今後は旧バージョンの使用継続が困難になる可能性が高まっている状況です。
GameWithでもMySQL 5系を利用したサービスがあり、このバージョンアップの対応が急務となりました。そこで、バージョンアップの作業を実施することにしました。
今回のバージョンアップの作業においては、運用中のサービスにできる限り影響を与えずに安全に移行するため、Blue/Green Deployments という手法を採用しました。この手法を用いることで、トラフィックを段階的に新バージョンへ移行させ、問題が発生した際には迅速にロールバックすることが可能です。こちらについても併せて注意点などを書いていきたいと思います。
2. トラブルシューティング
binlog_formatの設定
Blue Green Deployments requires writer instance to be in-sync with cluster parameter group.
Blue/Green Deployments を利用する場合は、パラメーターグループでbinlogを記録する設定にする必要があります。
binlog_format の設定値を OFF 以外の値にします。
特に理由がなければ MIXED にするのが処理効率がよさそうです！
デフォルトのパラメーターグループでは設定が存在しなかったり OFF に設定されていたりするので、カスタムパラメーターグループを作成して設定します。
カスタムパラメーターグループの統一化
The current DB cluster parameter group aurora-mysql57 is custom. You must explicitly specify a new DB cluster parameter group, either default or custom, for the engine version upgrade.
元のパラメーターグループがカスタムの場合は、Blue/Green Deployments を作成される新しい環境のパラメーターグループもデフォルトではなくカスタムで作る必要があります。
上記で、 binlog_format の設定を行うために、旧バージョン環境にカスタムパラメーターグループを設定した場合は、新バージョン環境用のカスタムパラメーターグループも同様の設定で作成する必要があります。
現状は手動で同様の設定を作るしかないみたいです！
クラスターとインスタンスのパラメーターグループの優先順位
パラメータグループがクラスターとインスタンスでそれぞれあるので混乱しやすいですが、個別のインスタンスに適用する"インスタンスパラメータ"が優先になっています。
インスタンスパラメータがデフォルトの設定になっている際はクラスターパラメータが適用されるようになっていそうです！
インスタンス毎に変えないなら、クラスターパラメーターグループで一律設定すればOK！
インスタンスクラスの制限
Aurora MySQL 8（バージョン3.01.0以降）では、利用可能なインスタンスタイプに制限があります。特に、開発環境でよく使用されるdb.t3.smallインスタンスタイプが利用できなくなっている点に注意が必要です。
t3.small で Blue/Green Deployments の設定をすると、次のようなエラーがでます：
RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.t3.small, Engine=aurora-mysql, EngineVersion=8.0.mysql_aurora.3.06.1, LicenseModel=general-public-license. For supported combinations of instance class and database engine version, see the documentation.
AWS 公式ドキュメントを確認すると、次のようなサポート状況になっています：
詳しくは次のインスタンスクラスのサポートされている DB エンジンをご確認ください。
Amazon Aurora DB DB インスタンスクラスでサポートされている DB エンジン
db.t3.small からの変更先は db.t3.medium や db.t4g.medium が候補になりそう！
Green環境に書き込み処理は推奨されない
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
上記のエラーは、Green環境に書き込み処理を行った場合に発生するものです。
Green環境は、Blue環境をレプリケーションして作られているため、切り替え前のGreen環境への書き込みは推奨されません。
Blue環境での書き込みを行わない前提であったり、Blue環境からのレプリケーションによるIDが重複しないような書き込みであれば問題ないので、書き込み可能に設定することもできますが、基本的には行わない方がよさそうです。
参考： 【RDS Blue/Greenデプロイ】Green環境でスキーマ変更や書き込みをする方法と注意点
Green環境への書き込みはレプリケーションの邪魔になるから、できるだけ避けましょう！
3.最後に
今回、Blue/Green Deployments を活用してDBエンジンのアップデートを行いました。便利な手法ではありますが、ダウンタイムが完全にゼロにはならない点や、Green環境への書き込みに制限があるといった短所もある、ということが理解できました。
本記事では、GameWithでのインフラ作業で発生したトラブルとその解決方法をお伝えしましたが、同じ課題に直面している方の力になれれば幸いです！
現在、GameWithではエンジニアを積極的に募集しています！インフラに挑戦したいサーバーエンジニアの方はもちろん、フロントエンジニア、AIに興味がある方、Unityでの開発に関心のある方も、お気軽にカジュアル面談にお申し込みください！
