【TECH BLOG #49】RDS Aurora MySQLのアップグレード対応

グリーエンターテインメント株式会社 エンジニア部TAです。

今回は運営タイトルで行ったゲームにおけるRDS Aurora MySQL (MySQL 5.6 互換)からRDS Aurora MySQL (MySQL 5.7 互換)へアップグレードする際の作業内容について説明します。
このアップグレードの実作業は別のチームで実施してくださったのですが、実施する前の確認作業について説明したいと思います。

前提

私が所属しているチームで運営しているサービスではAmazon Web ServiceのAmazon RDSを用いてデータベースの構築、運用を行っています。
このデータベースのエンジンはAurora MySQLであるのですが、MySQL5.6のサポートが終了するため、5.7へアップグレードしなければならなくなりました。
※アップグレードしない場合、サービスが稼働中でも強制的にアップグレードされてしまいます。

今回、アップグレードするにあたってどのように対応したのか説明させていただきたいと思います。

全体流れ

まず今回のアップグレード作業を行うにあたって以下の流れで実施いたしました。

1.　開発環境での検証
　ー開発環境のデータベースのバックアップ（スナップショット）取得
　ーバックアップからデータベースを作成してMySQL5.6から5.7へアップグレード
　ーMySQL5.6と5.7のクラスタパラメータグループ/パラメータグループの差分を確認
　ー差分のパラメータの内容を精査して適当な値に設定する
2.　サービスの動作検証、QA検証を実施
　ー本番環境での作業準備
　ー作業時間見積もり
　ー作業手順の作成
3.　本番環境でアップグレード作業を実施
　ーデータベースに対してMySQL5.6から5.7へアップグレード

この作業の中で、特に「クラスタパラメータグループ/パラメータグループの設定」と「アップグレード作業時間」について特に注意すべき内容ですので、説明したいと思います。

アップグレードするにあたっての注意点

クラスタパラメータグループ/パラメータグループの設定

パラメータグループとは
Amazon Aurora DBにおけるクラスタは、一つ以上のDBインスタンスと、そのDBインスタンス郡のデータを管理する1つのボリュームとして構成されています。
そして、このクラスタ単位、さらに構成するDBインスタンス単位でパラメータグループが設定されています。
このパラメータグループは、決められたパラメータ名に対して値を設定することで、MySQLの設定やクラスタの構成用の設定をすることが可能になります。

パラメータグループを更新
今回、MySQL5.6から5.7へメジャーアップグレードするにあたって、これらパラメータグループのパラメータも名前が変更されたり、設定を削除されたり、新規で追加し新しい設定が可能になったりと変更点が多く、それらを設定しなければいけません。

そのため、開発環境のデータベースを複製し、MySQL5.6と5.7のデータベースを用意してクラスタパラメータグループ/パラメータグループを比較し、何のパラメータが追加、削減、数値変更されているのか把握する必要があります。

以下の手順でMySQL5.6と5.7のパラメータグループ/クラスターパラメータグループの差分を確認し、パラメータの理解、どのような設定値にすればいいのかを確認しました。

1.　開発環境のDBインスタンスのスナップショットを作成してバックアップする
2.　スナップショットから作成したインスタンスのMySQLを5.6から5.7へアップグレードする
3.　5.6と5.7のクラスターパラメータグループ、パラメータグループのリストを作成
4.　クラスターパラメータグループの5.6と5.7の差分、パラメータグループの5.6と5.7の差分を作成
5.　差分があるパラメータの名前からどういうパラメータなのか確認し、妥当な値を設定する

実際に私が差分を確認する際は、以下のように新/旧バージョンのパラメータグループの差分を出力し、パラメータの値に問題ないか、新しく追加された他パラメータのデフォルト設定に問題ないか、一つずつパラメータを調べて検証致しました。

青いセルはアップグレードによって増えたパラメータ、赤いセルは削除されたパラメータ、黄色いセルは編集があったパラメータで、アップグレード前後の差分をExcelやGoogleのスプレッドシートに出力することで調査対象のパラメータをわかりやすくしました。

パラメータグループにはどのようなパラメータがあるのかというと、あくまで一例ですが、スロークエリのログの保存先ディレクトリの指定をパラメータでできたり、テーブル作成や操作といったデータベース変更を記述するバイナリログの設定もパラメータで設定可能です。

アップグレード作業時間の見積もり

アップグレード作業を洗い出した結果、以下のようになります。

1.　データベースバックアップ（スナップショット）作成
2.　MySQLのアップグレード作業
3.　アップグレードの確認作業

まずはじめにバックアップできるようスナップショットの取得を行います。
データベースの使用容量が大きければ大きいほど時間がかかるため、事前に容量について確認するのが良いです。

そしてアップグレード作業を実施するのですが、こちらも使用容量が大きければ大きいほど時間がかかりますので注意してください。
さらにアップグレードが失敗した時のことを考え、

バックアップから元に戻す作業も洗い出したところ、以下のようになりました。

・スナップショットからデータベースの復元
・復元したデータベースからリーダーインスタンスを作成
・データベースの設定変更（インスタンス名修正/タグ付与/AutoScalingポリシー等の設定）
・データベースの接続先設定であるDNS切り替え
・動作確認

アップグレード作業ももちろん時間がかかるのですが、大規模な容量のデータベースを管理しているサービスではバックアップを用いた復元作業も時間がかかることを念頭に置いて、参考にしていただけると幸いです。

今回私のプロダクトではアップグレード作業時間の見積もりは1.5時間で、もし何かしらのトラブルが発生しバックアップからデータベースを元に戻す作業が発生した場合は、3.5時間作業にかかる想定でメンテナンスの時間を見積もりました。

見積もり方としては、

1.　事前に一番容量の大きいデータベースインスタンスのスナップショットを作成する
　ー一番大きいスナップショットの容量は454GiBだった
2.　スナップショットからデータベースサーバーを復元する
　ー復元してもとに戻すのに2時間かかることがわかった
3.　アップグレードを行いアップグレードにかかる時間を確認する
　ーアップグレード作業と差し戻し作業で1.5時間かかることがわかった

となり、結果的に3.5時間かかることがわかりました。
このように作業手順の確認、作業時間の見積もりを行うことで、余計にメンテナンス時間が長引く、もしくは短すぎて延長するといった調整をせずに無事メンテナンスを終わらせることができました。

最後に

サービスを運用するにあたって、使用しているライブラリやサービスをアップグレードしなければいけないことが多々あります。
その度に時間の見積もりを行うのですが、バックアップや復元等の影響で時間がとられ、もう少し時間を確保できれば良かった等、反省する点も多かったです。
たくさんのお客様がプレイしている環境下で、必要以上にお客様のプレイ時間を削らないよう、インフラ作業を行う際は時間の見積もりを行い、正確な時間を算出し、健全なサービス運営ができるよう、今後も安全な運用をできるよう努めていきたいと思います。