初めまして！Akatsuki Gamesのサーバーサイドエンジニアインターンシップに参加したreimeiです。本記事では私がインターンシップで取り組んだことについてご紹介します！
自己紹介
慶應義塾大学環境情報学部の3年生で普段はPython3/DjangoやGoを用いたWebアプリケーション開発を行なっており、主にサーバーサイドの開発をしています。
インターンシップについて
3週間の就業型インターンシップとなっており、私は8/15〜9/2の期間で参加しました。
詳しいインターンシップの情報については下記のリンクから見ることができます。
私が参加したコースの概要は下記になります。
ゲームアプリのバックエンドの開発と運用
APIやデータベースの設計や開発、パフォーマンスのチューニング、インフラの構築や設計、周辺ツールの開発など多岐に渡る範囲をご担当いただきます。関わる領域は一人一人の得意分野をベースに柔軟に決定します。
- Ruby on Rails を利用したアプリケーションコードの新規開発や改善
- AWSを利用した高負荷アクセスを支えるインフラ基盤の改修や改善
- ゲーム制作を効率的に進めるために必要となるツールの開発
参加動機
就活をする中で普段開発をしているWebバックエンドとゲームのバックエンドの業務はあまり変わらないという話を聞いたので、志望する会社の範囲を広げるために参加したいと思いました。また、インターンシップの機会を活用してゲーム業界のバックエンドエンジニアがどのように働いているのか、ゲームというドメインはトラフィックが多いと聞くが実際どのくらいなのかなどを体験してみたかったという側面もあります。
Amazon Aurora MySQL 2からAmazon Aurora MySQL 3への移行に関する調査・検証
今回のサマーインターンシップではAmazon Aurora MySQL 2(以下Aurora2)からAmazon Aurora MySQL 3(以下Aurora3)へ移行するために必要な調査や検証に取り組みました。
Amazon Auroraとは
Amazon Aurora はリレーショナルデータベースサービスで、高性能の商用データベースの可用性とスピード、およびオープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Aurora は、MySQL および PostgreSQL と完全な互換性があり、既存のアプリケーションやツールを変更することなく実行することができます。
移行に関する調査
Aurora2とAurora3を比較して何が違うのか，Aurora3で追加された新機能で役に立つものはないか，Aurora3でサポートされてない機能によって何かしらの影響がないかについて調査を行います。移行に際して影響が出てきそうな部分を懸念点とともに以下にいくつか抜粋しています。
Aurora2とAurora3の比較
- クエリキャッシュの削除
- キャッシュがなくなったことにより、パフォーマンスの低下につながる可能性がある
- デフォルトの文字コード
- Aurora2→latin1 (プロダクトではutf8を使用)
- Aurora3→utf8mb4 (MySQL8.0ではutf8はutf8mb3)
- DBの設定次第でデコードに失敗して文字化けする可能性がある
- インスタンスクラス
Aurora3でサポートされてるインスタンス サポートされていないインスタンス db.r5 db.r4 db.r6g db.r3 db.x2g db.t3.small db.t3 db.t2 db.t4g - インスタンスがサポートされていなくて、移行できない可能性がある
- AUTO_INCREMENT
- DBインスタンスを再起動する際、Auroraは各テーブルのAUTO_INCREMENT値を保持する
- 🚨スナップショットから復元する際はAUTO_INCREMENT値は保持されない
- スナップショットからの復元だとAUTO_INCREMENT値が保持されないので適切なIDを発行できない可能性がある
MySQL8.0の新機能
- 降順インデックス
- 降順で情報を取得しているAPIがあるなら高速化することができる可能性がある
- インスタントDDL
- 高速化できる可能性がある
- 読み取りロック
- 今よりも安全にデータの読み書きを行うことができる
- caching_sha2_passowrd
- よりセキュアなパスワード暗号化を実現できる
MySQL8.0の新機能や変更点等について詳しく知りたい場合はこちらをご参照下さい。
Aurora3ではサポートされていないMySQL8.0の機能
- TLS1.3
- caching_sha2_password
- MySQLプラグインの設定は変更できない
- リソースグループと関連づけられたSQLステートメント
- aurora_hot_page_contentionステータス可変は使用できない
Aurora2とAurora3の比較とAurora3ではサポートされていないMySQL8.0の機能の詳細についてはこちらをご参照下さい。
移行手順まとめ
当初はインプレースアップグレードを検討していましたが、現時点ではサポートされていないため、今回は一番簡単そうなスナップショットを使用してAuroraのバージョンをアップグレードするという以下の手順を試みました。
- Aurora2のインスタンスのスナップショットを取得
- 1. で取得したスナップショットを復元
- 利用可能なバージョンで「Aurora MySQL 3.02.0」を指定
- その他の設定は適宜利用に合わせた設定を行う
- envファイル等の接続先DBのエンドポイントを指定している箇所を新しいインスタンスのエンドポイントに指定し直す
- 不要なら以前使用していたAurora2のインスタンスを停止
現在、Amazon Relational Database Service (Amazon RDS) では、Aurora MySQL 2.x クラスターを Aurora MySQL 3.x にインプレースアップグレードすることを許可していません。
Aurora3への移行に関する検証
文字コード周りについて
前述した通りAurora2(MySQL5.7)とAurora3(MySQL8.0)ではデフォルトの文字コードが異なることに加えて、私が所属しているチームのプロダクトの文字コードはutf8だったので、どのような影響が発生するか確かめるために検証を行いました。
- $ rails c にて接続先DBのconfigを見てみると、encodingはutf8、charsetはutf8、collationはutf8_general_ciが設定されていた
- $ rails dbconsole にて詳細な文字コードの設定を見てみると、databaseとserverはutf8mb4なのに対してそのほかはutf8が設定されていた
- $ rails c にて幾つかデータをピックアップしてみて日本語のデータを見てみたが適切にデコードされていた
- $ rails dbconsoleでも適切にデコードされていた
- 新しいテーブルを作成して日本語と英語のテキストのデータを挿入、閲覧しても適切にデコードされていた
負荷試験
今回はAurora2を使用した環境とAurora3を使用した環境を対象にAuroraのバージョン以外は同じ条件で各1時間ほど負荷試験を行いました。
負荷試験の結果を読み解くと、DB関連のメトリクスでAurora2にくらべ、性能劣化を検知しました。
原因としては、Aurora2以前はクエリキャッシュの恩恵を享受できていたものの、Aurora3ではクエリキャッシュが廃止されたためと考えられます。今回の負荷試験ではAurora2の時の設定をそのままAurora3に適応していたため、Aurora3用に設定のチューニングを行うことで改善される可能性はあると思います。
やり残したこと
タスクを進めていく中で下記の課題が見つかりましたが、時間の関係で最後まで取り組むことができませんでした。これらの課題についてはプロダクトチームで取り組む予定となっています。
- aws-cli等を用いたAurora3への移行の自動化
- インスタントDDLの検証
- Aurora3用のチューニングを行った上での負荷試験
- 読み取りロック、降順インデックスの有効性調査
- 🍣や🍺をはじめとした4byteの文字の検証
感想
今までバックエンドを中心に開発してきた一方で、今回のインターンシップではほとんど経験がないインフラ周りのタスクに挑戦させていただきました。また、タスクとしてはAuroraという大規模サービスらしいサービスを触ることができる貴重な体験をさせていただくことができ、大規模サービスの開発に携わりたいという当初の目的を達成することができました。
一方で、今回のインターンシップでは「実績を残してやる」という気概で参加したのですが、実際は知識やスキル不足により全てが手探り状態で、むしろ自分の課題をたくさん発見することになりました。
最後に、現在大学3年生で就活について悩むことがたくさんありましたが、アカツキゲームスには多様なキャリアを歩んだ人が在籍しているので、「こんな人と話してみたいです」と人事の方に相談すると面談をセッティングしていただくことができ、キャリア相談に乗っていただくことができました。
3週間という長いようで短い期間でしたが、メンターの方をはじめチームの皆さんや人事の方々など大変お世話になりました。
ありがとうございました！
