ゲーム運用を行っていると避けては通れない負荷対策 いかににリリース前に負荷対策を行うか、運用中サーバメンテから復帰直後の集中したアクセスからのサーバダウン立ち上げ後即サーバダウンの負のスパイラルからの脱却等、運用事例をあげながらこれまで行ってきた負荷対策のノウハウを纏めたいと思います。

1. 負荷がたかいいんだから～♪（仮）
Cygames
サーバーサイドエンジニア 濱田 洋平

2. 自己紹介
濱田洋平
サーバーサイドエンジニア
２０１０年からCAグループ内の会社で
ソーシャルゲームを作っています。

3. アジェンダ
１．失敗事例と対応方法
CASE１ memcached
CASE２ DB垂直分割
２．弊社サーバー構成
３．検証中のサーバー構成
４．まとめ
５．伊藤さんより負荷テストの話し
※前職での事例になります。

4. CASE１ memcached
memcachedとは？
メモリーキャッシュシステムです。
利用方法
DBクエリーの結果をキャッシュして
いました。

5. CASE１ memcached
MySQL
memcashed
Web Server1
Linux (Cent OS)
PHP
Webサーバーとmemcashedは別ラック
にありました。

6. CASE１ memcached
障害発生
Webサーバーからmemcashedへの
レイテンシーが悪化
原因
ラック間の通信量が５倍に増えて帯域を
圧迫してました。

7. CASE１ memcached
MySQLはメモリーにのっていたら早いです
適時キャッシュと使い分けましょう。
サーバーメンテナンス明けの負荷が急激に
上がる場合を想定してユーザーデータを
３秒間キャッシュするだけでもMySQLの
負荷が下がります。

8. CASE１ memcached
memcashed の分割
ロードバランサー
MySQL
memcashed
Web Server1
memcashed
memcashed
memcashed
Web Server2 Web Server3
１．ローカルとグローバルキャッシュで分割
２．グローバルキャッシュの水平分割
memcashed memcashed

9. CASE２ DB垂直分割
MySQL
（master）
Web Server1
MySQL
（slave）
masterからslaveにレプリケーション
されます。
masterは書き込みslaveは読みこみ専用に
すれば負荷分散ができる！

10. CASE２ DB垂直分割
障害発生
レイドイベント中カスタマーサポートから
倒したはずのレイドボスが倒した事に
なってないって問い合わせが着信してます！
原因
レプリケーション遅延が発生していました。
今回はupdateの回数が秒間あたり
普段の○○倍に・・・・
ピークタイムおそろしす

11. CASE３ DB垂直分割
MySQL0
（master）
Web Server1
MySQL0
（slave）
MySQL1
（master）
MySQL1
（slave）
MySQL2
（master）
MySQL3
（slave）
DBの水平分割
boss_id Hit_point
3 500
6 350
9 400
boss_id%3=格納DB
MySQL0
boss_id Hit_point
1 1000
4 2000
7 300
MySQL1
boss_id Hit_point
2 600
5 400
8 300
MySQL2
トランザクション処理でatomicなデータは
DBを増やして分割しました。

12. CASE３ DB垂直分割
DBの水平分割時の制約（今回の場合）
joinができなくなります。
スケールしようとするとキーを元にレコード
を再振り分けしなければならない。。

13. データベース水平分割
構成を纏めると
１．マスターデータなどサーバー間で値が変わらない
データはローカルにキャッシュする
２．クエスト進捗情報などサーバー間で値が変化するデーターは
グローバルキャッシュにキャッシュする
３．トランザクション処理が入りatomicなデーターは水平分割
したDBに格納する。
ロードバランサー
memcashed
Web Server1
memcashed
memcashed
memcashed
Web Server2 Web Server3
MySQL0
（master）
MySQL1
（master）
MySQL2
（master）
memcashed memcashed

14. こんな構成を検討しています
Web Server1
Linux (Cent OS)
memcashed1
memcashed2
memcashed3
NoSQL NoSQL
memcached
MySQL
(Master)
データベース水平分割 Data Storage Cluster
NoSQL NoSQL
NoSQL NoSQL NoSQL NoSQL
twemproxy
Node.js
Expres4
MySQL
(Master)
MySQL
(Master)

15. NoSQL
NoSQL（Not only SQL）
リレーショナルデーターベース以外のデーターベースを指します
特徴
・水平分割がしやすい
・データーの取得/格納が高度に最適化している
・リレーションされてない
・トランザクションが苦手（できないものもある）
Hbase MongoDB Cassandra DynamoDB

16. こんな構成を検討しています
水平分割が必要になるデーターはData Storage Clusterに格納する
atomicな操作が必要なデーターはRDSに格納する
Web Server1
Linux (Cent OS)
memcashed1
memcashed2
memcashed3
NoSQL NoSQL
memcached
MySQL
(Master)
データベース水平分割 Data Storage Cluster
NoSQL NoSQL
NoSQL NoSQL NoSQL NoSQL
twemproxy
Node.js
Expres4
MySQL
(Master)
MySQL
(Master)

17. まとめ
１．マスターデータなどサーバー間で値が変わらない
データはローカルにキャッシュする
２．クエスト進捗情報などサーバー間で値が変化するデーターは
グローバルキャッシュにキャッシュする
３．トランザクション処理が入りatomicなデーターは水平分割
したDBに格納する。
４．DBのスケールが必要になるデーターはNoSQLに格納する。
５．キャッシュはあくまでキャッシュ使いどころに注意する。

18. 今回ご紹介した事例
リリースしてから障害が発生した例ばかりです・・・
コーディング中に注意していたら・・・
負荷テストをしっかりしていたら防げた事象でもあります。
今回は伊藤さんにも資料を用意してもらったのでここからは
伊藤さんより負荷テストの話をお聞きください。