はじめに

オープンワークのインフラはAWSで構築しており、データベースの多くはAmazon Aurora (MySQL互換)を利用しております。
Amazon Aurora v1（MySQL 5.6互換）が2023年2月末を持ってサポート期限となる事をうけて、v3（MySQL 8.0互換）へバージョンアップをしました。
稼働中サービスのデータベースバージョンアップという事でそれほど頻繁には経験できない事なので、実施した内容を共有できればと思います。

バージョンアップの全体像

今回のバージョンアップではAuroraと合わせてアプリケーションの言語、フレームワークもバージョンアップしています。全体像については下記記事をご確認ください。 techblog.openwork.co.jp

データベースバージョンアップの準備と検証

バージョンアップ方法の検討

稼働中のサービスのバージョンアップであることから利用ユーザーへの影響が最小となるように、確実/安全にデータを移行し、できる限りリリースの所要時間が短くなる方法を検討しました。

下記の移行方法を検討/検証しています。

Auroraのインプレースアップグレード
mysqlshによるDump&Load
binlogによるレプリケーション

インプレースアップグレードはv2(5.7) to v3(8.0)が検討時にサポートされていなかったので不採用、mysqlshを利用したDump&Loadは1時間程度でデータ移行ができたので選択の余地はありましたが、より所要時間が短くなるbinlogレプリケーションを採択しました。
これによりアプリケーションが接続しているエンドポイント切り替えによりバージョンアップができるので、リリース時の作業時間を短くすることができました。

レプリケーションによる移行の検証

MySQLレプリケーションは次の上位リリースへのレプリケーションはサポートされていますが、今回のように2バージョン（v5.6 to v8.0）の場合はサポート外となります。 dev.mysql.com

弊社の環境において2バージョン間でのレプリケーションで問題無く移行できるか、実際のデータを用いて検証を実施しました。

v1からDumpしたデータを構築したv3クラスターにLoad
v1からv3へのレプリケーションを設定
v1, v3 それぞれでスキーマ情報とデータをDump
Dumpした情報を比較して差分を確認

データ更新が頻繁に行われているのでレプリケーションとDumpのタイミングによる差分は発生しましたが、上記の手順で問題なく移行できることが確認できました。
データが大きくファイルサイズが大きくなりすぎるとdiffコマンドでの比較ができなくなってしまうので、Dumpをテーブル毎に出力、一定サイズに分割してから比較するなど少し考慮が必要となります。

バージョンアップによる変更点の調査&アプリケーションの修正

バージョンアップによる影響を把握し対処するために、MySQLのリリースノートから重要な変更をピックアップして影響有無を判断しました。 dev.mysql.com dev.mysql.com

ピックアップした変更点の例としては下記の様なものがあります。

デフォルトのキャラクタセット、照合順序の変更
予約語の追加
優先認証プラグインの変更

影響のありそうな変更点はWeb開発チームと共有、インフラWeb開発チームでそれぞれ必要な検証と修正を実施しています。

負荷検証

負荷検証はk6cloudを利用して実際のサイトへの大量アクセスを想定してリクエストをしています。
検証の結果、サイトの応答速度に大きな影響はありませんでしたが、AuroraのCPU負荷がバージョンアップ前と比較して高い事が確認されました。
インスタンスタイプの変更、パラメータチューニングなどによる解消を試みましたが改善には至らず。一部の高負荷となっているクエリの改善により、稼働に影響ないと判断しリリースすることとなりました。

本番リリースで発生した問題

本番環境の考慮不足による作業遅延

リリース時の作業をエンドポイント切り替えだけにするため、事前にv3クラスターの構築とレプリケーションを設定を実施しましたが、開発/ステージングと比較してデータ量が多く、作業全般で時間が掛かりました。
また、データ更新頻度が非常に高い影響でレプリケーション設定時にbinlog positionのズレによるエラーが発生するなど想定外のエラーもありました。
少しタイトなスケジュールであったこともあり、リリースに間に合わせるために直前の業務負荷が高くなってしまったので、作業ボリュームの想定ができていると良かったと反省しております。

データベースのエンドポイントの変更漏れ

データベースが複数のアプリケーションから参照されているため、接続先の設定箇所が多岐にわたるという問題がありました。事前に調査をしてリリース後に順次変更対応をしましたが、調査漏れが発覚して慌てて対応した部分もありました。
今回のバージョンアップに合わせてAuroraのエンドポイントを直接参照するのではなく、Route53レコードを挟むことでレコードの値変更で接続先が切り替えられるようにしています。
また、オープンワークでは以前からIaC化を進めており、ほとんどのリソースがコード化されつつあります。
接続先切り替えがDNSレコードの値変更で済むようになったこと、コードのgrep等により利用箇所の調査が容易になったことで同様の問題は抑制できたのではと考えています。

今後に向けて

サイト停止を必要としない移行方法の検討　

レプリケーションを利用することでリリース時の作業時間を少なくすることができましたが、依然として下記の課題があります。

サイト停止をせざるを得なかった
運よく問題は起きなかったが切り戻しとなった場合はかなりの手間が想定された

利用ユーザーへの影響をより少なくし、自分たちも安心してバージョンアップができるように検討進めたいと思います。

データベースに関する知識向上

負荷検証でCPU負荷の情報が確認されていながら、根本的な原因究明、解決に至れなかったというインフラとして少し悔しい部分がありました。
短期的に解決できる課題ではないですが、チームとして解決の幅が広げられるように知識を蓄えていければと考えています。

さいごに

インフラグループとしては調査開始からリリースまで半年程に及ぶ対応となり大変な面もありましたが、弊社では実績のなかったレプリケーションによる移行など新たな挑戦ができ非常によい経験となりました。
既存リソースの保守という避けられない業務が多くなりがちですが、そんな中でも新しいことを取り入れながらサービスの成長に貢献していきたいと思います。

当社ではインフラエンジニアを募集しています。ご興味を持たれましたら是非。 www.openwork.co.jp