FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会
https://connpass.com/event/91736/
Twitterハッシュタグ：#ゲームサーバ勉強会
アカツキ：大規模環境におけるRuby on Rails on AWSでの最適化事例
大規模キャンペーンによるリスエスト数増加
- アクセス数が想定以上
- DBのスケールアップを限界まで行ったが対応できず
モバイルゲームのインフラ的問題点
- モバイルゲームはユーザーが何かする度にサーバへアクセスするため、アクセス数が膨大
- イベント等でアクセススパイクが発生しやすい
- ユーザーデータが膨大
- キャラ数、育成状況、イベントのクリア状況など（処理も複雑になる）
- Write Intensive
- アイテムの取得など、書き込みが多くcacheし辛い
インフラ構成
- User |
- Load Balancer |
- EC2（c4.8xlarge）Auto Scaling * 数十台 |
- ゲームデータ：RDS（Aurora）r4.8xlarge * 数台
- ユーザー：RDS（MySQL）r4.4xlarge * 数十台
- セッションとレスポンスキャッシュ：Memchached m4.2xlarge
- ランキングや永続化したいデータ：Redis r3.xlarge 混在 数十台
Resharding
既存のインスタンスをコピーして作成。
別DBに同一レコードが存在。
更新可能なSlaveを作成し、重複レコードを別EC2から削除。
削除が完了したらSlaveをMasterに昇格。
ディライトワークス：これで怖くない！？大規模環境で体験するDB負荷対策 〜垂直から水平の彼方へ〜
なぜ今垂直分割から水平分割なのか？
2016年5月、1台だったDBを分割
データの肥大化により、DBのインデックスがメモリに乗らなくなった
検討時間が十分に無く、垂直分割で対応
2018年1月、テーブルの肥大化により参照クエリのレイテンシが増大
当時の環境
- MySQL（5.6）
- db.r4.16xlarge 18台 （Master6台、Slave12台）
- Redis（2.8）
- cache.r3.4xlarge 2台
- memccached
- cache.r32xlarge
垂直・水平分割の移行課題
何をキーとして分割するか
ユーザーIDをキーとする。
更新を1つのトランザクションで行いデータ不整合を防ぐ。
何分割か
20分割。
これまでのデータ量の増加などから今後分割をしなくて良い数を計算した。
どう移行するか
AWS DMSを利用する。
https://aws.amazon.com/jp/dms/
移行中でもソースDBを利用可能。
Aurora間でも移行可能。
ダウンタイムをどうするか
AWS DMSを利用するため、DB切替の数時間のみ。
切り戻しをどうするか
ダブルライト方式を採用。
AWS DMSでリカバリ環境を準備する。
移行
どのように移行したか
MasterCluster → SlaveCluster → AWS DMS → 移行後のDB → AWS DMS → リカバリ環境
移行プロセス
2018年7月のFGO3周年を耐えることをターゲットに。
全期間は2018年3月～7月。
AWS DMSによる移行方法の確立
全テーブルを精査し再設計した。
AWS DMSのタスク機能を以下の様に使用する。
1. 既存データの全ロード
2. キャッシュされた変更の適用
3. 継続的なレプリケーション
AWS DMSを利用するには
レプリケーションサーバを作成。
データのソースエンドポイントとターゲットのエンドポイントを設定。
移行用のタスクを作成。
Indexを定義せず、移行先DBへスキーマを流す。
フルロードし、Indexを作成。
CDC（Change Data Capture）レプリケーション。
最初にスキーマだけを流しておくと、AWS DMSが全て移行してくれる。
また、Indexを先に作成してしまうと時間がかかる。
DMSのタスクによる移行では、
ソースエンドで関数をサポートしていない。
20分割用のカラムを追加する。
FastDDL（lab mode）でカラムを追加した。
本番環境での使用は推奨されておらず、十分な検証を実施。
メンテナンス時に追加を実施。
負荷試験
本番環境同様の環境を準備。
APIを準備。
負荷試験ツールで本番同様のシナリオを実施。
詳細はLT。
https://medium.com/shiguredo/fgo-%E3%81%AB%E6%8E%A1%E7%94%A8%E3%81%95%E3%82%8C%E3%81%9F%E8%B2%A0%E8%8D%B7%E8%A9%A6%E9%A8%93%E3%83%84%E3%83%BC%E3%83%AB-2fa3de337e20
DB分割による効果測定も実施。
リハーサル
Binlogスレッドが複数起動し、Mutexの奪い合いが発生。
これによりレプリケーションが遅延。
負荷をかけない環境で、Binlogスレッドを長めにすることで解決。
フィルタを利用するとソース・ターゲットの整合性がとれないので断念。
mysqldbcompareで比較するも高負荷のため、行数・スキーマの比較にのみ利用。
※ mysqldbcompare：定義以外にも件数や内容も確認可能
その他はCHECKSUM TABLEを利用。
移行後の障害テストもクリア。
移行本番
夜間計画メンテナンスを実施。
1. AWS DMS移行
2. ダブルライトに切替
3. 後日データ整合性チェック
4. ダブルライト停止
3実施時、リカバリ環境でデータ不整合が見つかった。
移行後のDBとリカバリ環境とのwait_timeoutが60秒と短かったことが原因。
28800秒にして再度リカバリ環境にデータ移行し問題なし。
整合性チェック完了。