【ディライトワークス様登壇】Fate/Grand Order における、ディライトワークス流 AWS 導入＆活用術 (今井 守生,田村 祐樹)
参加時のメモFate/Grand Order
ディライトワークス
500万DL
元々はMicroSrvice Azure
2015/07 リリース
2015/10 移行を決定
2015/12 移行を実施
会社の立ち上げ直後 （最初のプロダクト？
クライアントサイドはUnity(C#)
サーバサイドもC# コードの共通化、学習コスト
----
2,000-3000 r/s
10,000 qps (read)
4,000 qps(write
IIS(Game Server)
mysql 5.6
redis 2.8
----
ログイン時に同期
- ユーザアクションをトリガーで差分同期
- フレンド情報に関してのみ一定期間毎に同期
ボトルネックはMysql
- commit時に0.5sec slowquery
数秒おきにI/O性能が落ちていた
Premium Storage(P30)を使うことで解決
- レプリ遅延
salveをRAID 0に変更
I/Oバリア機能を無効化
I/Oスケジューラを cfg->noop
=> 参照をmasterに向ける
- DBサーバのメモリ枯渇でswap頻発
前部れのないサーバダウンが１ヶ月に３回(Redis 2回、Mysqlで1回)
- 冗長構成をとってなかった。。
- IaaS毎のダウンタイム比較するとAzureは結構長かった
------------------------
windows Server 12 R2
elastic beanstalk
30サーバ
3,000-5000 r/s
20,000 qps (read)
8,000 qps(write
スカイアーチネットワークに移管を助力。今も運用業務を
---------
Z-forward-forヘッダ
Azure依存コードの置き換え
iPhonのproxyでAWS環境に向けてリリーズ済バイナリでテストプレイ
深夜メンテ、Azure->AWSのレプリを逆に張り替える（切り戻し
innod_db_read_thread/write_thread を増やした。
-> ○○○○○(名前忘れた)のパラメータを0に設定したら、スレッド詰まって死亡した。適切に上限設定しておく
公式ドキュメントをよもう！ ブログは理由が書かれてないことあるので注意
