この記事は Akatsuki Games Advent Calendar 2022 の22日目の記事です。昨日はKazuma Sakamotoさんの「UE5でMMDを踊らせるぞ！」でした。こうした興味などでやってみたいことを実験してみてブログまで書くのは大事ですね！
はじめに
はじめまして、アカツキゲームスでサーバーエンジニアをやっています柴原です。今回は自分の担当しているモバイルゲームのプロジェクトにてAurora MySQL lab modeの機能の1つであるFast DDLを使った高速なmigrationを試してみました。
経緯
モバイルゲームの様な運用型のゲームでは、運用年数に比例してユーザデータの量が増えていきます。加えて、新機能追加に伴うテーブルへのカラム追加などが必要になる場面があります。そして、このような構造変更はデータ量に比例して時間がかかります。私の所属するプロジェクトでは、こうしたDBの構造変更の作業はメンテナンス時間を設けて、その時間内で行っています。メンテナンスの時間はゲームをプレイすることができないため、短ければ短いほど良いです。そのため、メンテナンス時間を短くできる可能性のあるFast DDLに着目しました。
Fast DDLとは
Fast DDL は、AWSが提供している機能の一つでALTER TABLE tbl_name ADD COLUMN col_name column_definitionの操作をほぼ瞬時に実行できる機能です。以下３つの制約を満たしている時にFast DDLを利用できます。
- デフォルト値を持たないこと
- nullableなカラムであること
- 末尾挿入であること
しかし、ドキュメントにあるようにAWSは本番DBクラスターでの運用を推奨していません。本番環境で導入を検討する際には注意してください。
Fast DDLが使えるのは、Aurora MySQL version1とversion2(MySQL5.6もしくはMySQL5.7相当)です。Aurora MySQL version3ではFast DDLは廃止され、MySQL8系で導入されたinstant DDLが使用できるようになります。
設定
ゴールとしては、RDSクラスターのaurora_lab_modeの設定パラメータが1になっている状態です。設定手順を以下に示します。
- aurora_lab_modeを有効化したDBクラスターパラメータグループを用意します(これはすでに適用しているDBクラスターパラメータグループの値を変更して使用しても問題ありません)
- このパラメータグループを該当RDSに適用します(この段階ではまだ適用が終わってません)
- パラメータグループを完全に適用するためRDSの再起動を実施します
- 念のためにaurora_lab_modeが有効化されているか確認する(Optional: cli経由でも確認できますし、select @@aurora_lab_mode;でも確認できます)
検証してみた
本番のRDSをクローンした環境で実験を行いました。実際のメンテナンスにて行う予定のDB構造の変更に対して、Fast DDLの効果を比較検証しました。今回行うDBの構造変更は、通常のカラムとVirtual Generated カラムの追加です。この2点について検証を行いました。
通常のカラム追加の結果を以下に示します。
- Fast DDLなし：2時間程かかる
- Fast DDLあり：2秒 程かかる
結果は一目瞭然ですね。単純な比較ではありますが、3600倍高速になります。(恐らくどんなにデータ量が多くても数秒で終わるような仕組みだとは思います。)
続いてVirtual Generated カラム追加の結果を以下に示します。
- Fast DDLなし：0.20秒
- Fast DDLあり：2.80秒
結果としては、多少遅くなりました。この時間差であれば誤差なので、特に気にすることなくこの機能を有効化して作業ができそうなことが確認できました。
まとめ
今回は、Fast DDLを用いた高速なmigrationを検証しました。本番環境での利用にはリスクがあるものの、十分検討に足りうるものであると思います。本記事は、この機能を本番で使うことをお勧めしている訳ではないです。十分な事前検証を行った上で検討してみてください。
明日のAkatsuki Games Advent Calendar 2022 は、itmさんの「JenkinsのLog Parser触ってみた」です！お楽しみに！！
最後に、アカツキでは一緒に働くエンジニアを募集しています。
カジュアル面談もやっていますので、まずは雑談からいかがでしょうか。
