2017年10月4日水曜日

AWS Summit Tokyo 2016 | 【ディライトワークス様登壇】Fate/Grand Order における、ディライトワークス流 AWS 導入&活用術

【ディライトワークス様登壇】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頻発

前部れのないサーバダウンが1ヶ月に3回(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に設定したら、スレッド詰まって死亡した。適切に上限設定しておく
公式ドキュメントをよもう! ブログは理由が書かれてないことあるので注意

0 件のコメント:

コメントを投稿