駅メモ！開発基盤チームです。
今回はサービスで利用している Amazon Aurora MySQL を v2 から v3 へ移行したときのことを書きます。
概要
駅メモ！をはじめとする弊社のサービスでは、データストアとして Amazon Aurora MySQL(以降 Aurora MySQL) を利用しています。すでにアナウンスされている通り、Aurora MySQL v2 は 2024 年 10 月 31 日に 標準サポート終了を迎えるため、Aurora MySQL v3 への移行が重要な課題になっていました。これに対し、駅メモ！開発基盤チームでは綿密な計画を立て、今年の初め頃に無事に移行を完了させることができました。このエントリはその時にどんな手法を取ったかを書きます。誰かの参考になればと思います。
やったこと
最初にざっくりとした流れを示します。
調査
- 新機能・廃止された機能の調査
- 非推奨事項の調査
- 移行手段の調査
設計
- パラメータグループの設計
- 移行手順の設計
- 動作確認・負荷試験の設計
- 開発環境で利用している MySQL の移行手順の設計
事前準備
- 廃止された機能を v2 の段階で無効化
- 動作確認・負荷試験の実装と実施
- v3 に向けてアプリケーション・スキーマの最適化
- 移行手順の実装
- MySQL 5.7/8.0 の両バージョンで CI を実行できるように
移行実施
- 深夜メンテナンスにて移行実施
1. 調査
まずは移行対象の調査を行いました。MySQL や AWS のドキュメントを読み、サービスに影響がありそうな変更を重点的に深堀りしていきました。 調査したものの内、移行前にやることと移行後にやることを分類しました。以下にいくつかの例を示します。
- 移行前にやること
- 整数型の表示幅変更
- クエリキャッシュの無効化と代替の検討
- 移行後にやること
- utf8mb3 から utf8mb4 への変更
分類はそのタスクが必須であるかや、重さ・難易度で決めました。例えば、クエリキャッシュの無効化は廃止となってしまうため、必ず移行前に対応する必要があります。一方、MySQL 8.0.12 で追加されたALGORITHM=INSTANTで実行可能な ALTER は、INPLACE や COPY よりも高速に実行できるので、作業の簡単化のために移行後の実施としました。
などです。
2. 設計
調査内容を元にパラメータ、移行手順などの設計を行いました。ここは並行で設計できる部分があったので、チームで手分けして行うことにしました。
それぞれの設計では様々な工夫をしましたが、ここでは移行手順の設計について書きます。
移行手順の設計
Aurora MySQL v2 から Aurora MySQL v3 への移行手順を設計するうえで特に気を使ったのは切り戻しに関する部分です。移行メンテナンス中やサービスイン後など、どのタイミングで問題が発覚しても最悪の手段として Aurora MySQL v2 へ切り戻すことができるように考える必要がありました。最初はAurora Blue/Green Deploymentsを利用することでうまく切り戻しを実現できないかを考えましたが、後述の理由からこれだけでは要件を満たせないことがわかりました。しかしながら、それ以外の Blue/Green Deployments の利点は採用したいものが多い状況でした。
チームで考えた最終的な構成を以下に示します。
1. Blue/Green Deployments と 復旧用クラスターを構成
まずは普通に Aurora Blue/Green Deployments を構成します。これは AWS のドキュメントに従って作業を行います。 次に復旧用クラスターを Green 環境のレプリカとして作成します。
この時点で Green 環境と復旧用クラスターに Blue 環境からの変更が同期されていることを確認します。
2. Green 環境を Aurora MySQL v3 にアップグレード
一通りの確認ができた後は Green 環境をアップグレードします。 アップグレード中にはあらかじめレプリケーションを停止しておきます。理由はいくつかありますが、Green 環境が期待通りになっていることを確認してから再開したいというのが主なものです。
Green 環境のアップグレードが完了した後はレプリケーションを再開と動作確認を行います。今回は経過観察としてこの構成のまま数日稼働させました。ここまでの作業はサービスを止めること無く実施できます。
3. 切り替え
サービスをメンテナンスモードにし、切り替えを実施します。切り替え後の旧 Blue クラスターは不要になるので削除します。昇格した Green のクラスターエンドポイントは変更になるので、復旧用クラスターへのレプリケーション設定を適切に変更する必要があります。
動作確認が終わればメンテナンスを解除、サービスを再開します。サービス再開後、特に問題がなければ復旧用クラスターは不要になるので削除します。
4. 切り戻し
メンテナンス中、Blue/Green Deployments 切り替え前に問題がわかった場合は、Blue/Green Deployments を解除することで切り戻しを行います。
そうでなく、メンテナンス後や Blue/Green Deployments 切り替え後に切り戻しが必要になった場合は、復旧用クラスターをプライマリに昇格させることで切り戻しを実現します。
3. 事前準備
設計が終わったのであとはそこに向かって作業をするだけです。ここもチームで分担して行いました。
負荷試験では Locust を使った負荷試験環境を構築しました。これについてはいずれ別記事で紹介できればと思います。
4. 移行実施
移行計画通り深夜メンテナンスにて切り替えを実施しました。 入念な準備の甲斐もあってか、復旧用クラスターが必要になるような問題・パフォーマンス劣化は見つかりませんでした。
今またやるなら
現在また同じようなメンテナンスを行う場合は、下記 AWS ブログで紹介されているように Blue/Green Deployments 切り替え後の旧 Blue クラスターを再利用するのが簡単だと考えています。
私達の設計初期段階でもこの旧 Blue を使えないか？と模索していました。調査の結果、切り替え後のログファイル名とポジションを特定できないと判断しました。先に Blue/Green Deployments だけでは要件を満たせないと書いたのはこのためです。実際には、AWS のブログにもある通り、ログファイル名とポジションを含むイベントが発行されるのでそれを利用すれば良いことになります。
このエントリで紹介した方法であれば事前にほぼすべての準備をすることができるので、メンテナンス中手順が減らせるという利点が一応あります。しかし 1 クラスター分の費用が追加でかかってしまうので一長一短です。
まとめ
この記事では駅メモ！で利用している Amazon Aurora MySQL v2 クラスターを v3 にアップグレードした手法について述べました。また、今またやるならどうするかについても述べました。
DB のマイグレーション、アップグレードはかなり慎重になるタスクですよね。大きな問題が起こらなくてとても安心したのを覚えています。 今後は Aurora MySQL v3 移行後に実施しようとしていたものをひとつずつ進めていく計画です。また書けそうなことがあったら書こうと思います。
以上です。
参考文献
- GitHub.com を MySQL 8.0 にアップグレード
- Implement a rollback strategy after an Amazon Aurora MySQL blue/green deployment switchover
モバファクでは中途採用・新卒採用ともに絶賛募集中です。
会社の情報については、モバファクブログでも発信しています。
技術好きな方、モバファクにご興味をお持ちの方は、ぜひご応募ください！
・モバファクブログ：https://corpcomn.mobilefactory.jp/
・採用サイト：https://recruit.mobilefactory.jp/
