ソーシャルゲームスケールアウトの歴史

ソーシャルゲーム
スケールアウトの歴史
gussan@Drecom Co., Ltd.

Copyright © Drecom Co., Ltd.
12年2月20日月曜日

提供


自己紹介
• gussan
• ソーシャルゲーム事業本部 ※顔出しNG

• ICTグループ
• アーキテクト
• twitter: @gussan

仕事内容

• ミドルウェア選定・導入等
• ライブラリ開発
• トラブルシュート


ドリコムのソーシャルゲーム


2009/08 2010/01 2011/01 2012/01
なう

ドリコムが
ソーシャルゲームに参入して
2年半


2009/08 2010/01 2011/01 2012/01
なう

累計ユーザ数

1000万+


2009/08 2010/01 2011/01 2012/01
なう

2011/12実績

月間PV

50億+


2009/08 2010/01 2011/01 2012/01
なう

なう

サーバ台数

400+


2009/08 2010/01 2011/01 2012/01
なう

たった2年半

累計ユーザ数サーバ台数

1000万+ 400+
月間PV
50億+

2009/08 2010/01 2011/01 2012/01
なう

大規模トラフィック
に魅せられる毎日


2009/08 2010/01 2011/01 2012/01
なう

サービス安定稼働

ユーザさんが喜ぶ


2009/08 2010/01 2011/01 2012/01
なう

まさにソーシャルゲーム
の手口・・・ッ


2009/08 2010/01 2011/01 2012/01
なう

どのように
サービスをスケールして
いったのか


ソーシャルゲーム
スケールアウトの歴史


2009/08 2010/01 2011/01 2012/01
なう

ココ

2009年夏


2009/08 2010/01 2011/01 2012/01
なう

ココ

mixiアプリオープン


2009/08 2010/01 2011/01 2012/01
なう

ココ

合わせて我々も
アプリリリース


2009/08 2010/01 2011/01 2012/01
なう

ココ

万全の準備をした


2009/08 2010/01 2011/01 2012/01
なう

ココ
version 1.0
LB LB

Web Web • Apache 2.2
App App App App • mongrel
• Rails 2.3
M
• MySQL 5.0
S


2009/08 2010/01 2011/01 2012/01
なう

ココ

大丈夫だ、問題ない


2009/08 2010/01 2011/01 2012/01
なう

ココ

万全だと思っていた・・・


2009/08 2010/01 2011/01 2012/01
なう

ココ

　＊　　　　+　　　　巛ヽ
　　　　　　　　　　　　〒　!　　　
リリース。
　　　　　+　　　　。　 | 　|
　　　＊　　　　+　　 /　/　　　
　　　　　　 ∧＿∧ /　/
　　　　　　（´∀｀　/　/　+　　　
　　　　　　,-　　　　　ｆ
　　　　　 / ｭﾍ　　　　| ＊　　　
　　　　　〈＿｝）　　　|
　　　　　　　 /　　　　! +　　　　
　　　　　　 ./　　,ﾍ　 |
　ｶﾞﾀﾝ　||| j　　/　|　 | |||
――――――――――――

2009/08 2010/01 2011/01 2012/01
なう

ココ

次の瞬間


2009/08 2010/01 2011/01 2012/01
なう

ココ
繋がんなくね・・？

運営しっかりしろやゴルァ

サービス停止: :: :::: :: :: : :::::::::::::::::
. .: : : : : : :
　　　　. . : : : :: : : :: : ::: :: : :::: ::
繋がらないのでやめます
　　　.　. .... ..: : :: :: ::: :::::: :::::::::::
　　　　　　　 Λ＿Λ . . . .: : : :::
そんなことより野球やろうぜ　　　　　　/:彡ミ゛ヽ;）ー､　. . .:
　　　　　 / :::/:: ヽ、ヽ、 ::i . .:: :.
　　　　 / :::/;;: 　ヽ　ヽ ::ｌ　. :.
￣￣￣（_,ノ￣￣￣ヽ､_ノ￣￣

2009/08 2010/01 2011/01 2012/01
なう

ココ

100,000 install/day


2009/08 2010/01 2011/01 2012/01
なう

ココ

その後1週間眠れぬ
日々が続いた・・・


2009/08 2010/01 2011/01 2012/01
なう

ココ

一体何が起きていた
のか


2009/08 2010/01 2011/01 2012/01
なう

ココ
撃沈理由(1)

• 同じような種類のクエリが溜まる
• MyISAMのテーブルロック
• => InnoDB化することで解決


2009/08 2010/01 2011/01 2012/01
なう

ココ
撃沈理由(2)

•slowクエリ出まくり

•=> 地道に潰す


2009/08 2010/01 2011/01 2012/01
なう

ココ
撃沈理由(3)

•
特定のカラムへの更新が
多い

•=> Memcached,
TokyoTyrantへ逃す


2009/08 2010/01 2011/01 2012/01
なう

ココ
version 1.1
LB LB • Apache 2.2
Web Web • mongrel
App App App App • Rails 2.3
• MySQL 5.0
Mem M TT
• Memcached
S
• TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう

ココ
教訓

• 事前準備足りなかった
• 十分大きなデータを利用して負荷試験
を行うことができなかった

• => JMeterでの負荷試験をリリース手
順に追加


2009/08 2010/01 2011/01 2012/01
なう

ココ

2009/冬

2009/08 2010/01 2011/01 2012/01
なう

ココ

DBマスター負荷増


2009/08 2010/01 2011/01 2012/01
なう

ココ
DBマスタ
• 更新量増
• コストの高い参照処理が足を引っ
張る

• ランキング
• 同一レベル帯のユーザ検索

2009/08 2010/01 2011/01 2012/01
なう

ココ

コストの高い参照ク
エリをslaveへ


2009/08 2010/01 2011/01 2012/01
なう

ココ
version 1.2
Web Web • mongrel
• MySQL 5.0
Mem M TT
• Memcached
S
• TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう

ココ

どちらかが死んだ時
にキャパオーバ


2009/08 2010/01 2011/01 2012/01
なう

ココ
version 1.3
Web Web • mongrel
• MySQL 5.0
Mem M TT
• Memcached
S
S • TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう

ココ
結果

• masterの負荷下がった！
• slaveの負荷上がりすぎた・・
• クエリチューニングは引き続き


2009/08 2010/01 2011/01 2012/01
なう

ココ

2010/夏


2009/08 2010/01 2011/01 2012/01
なう

ココ

これまで騙し騙し
使ってきたMySQL


2009/08 2010/01 2011/01 2012/01
なう
ココ

MySQLがピンチ

• 更新量増によるIO Wait増
• BuﬀerPool溢れ
• CPU Usage増
• レプリケーション遅延


2009/08 2010/01 2011/01 2012/01
なう
ココ

重いよー
運営やる気あんの？

すでにキャパシティ
は限界・・・
繋がらないのでやめます

そんなことより野球やろうぜ


2009/08 2010/01 2011/01 2012/01
なう
ココ

チューニングも
手を尽くした


2009/08 2010/01 2011/01 2012/01
なう
ココ

よろしい、
ならば分散だ


2009/08 2010/01 2011/01 2012/01
なう
ココ

垂直か水平か


2009/08 2010/01 2011/01 2012/01
なう
ココ

垂直分散
• テーブルごとに使用するDBを分ける
• Railsではmodel毎に接続を切り替える
• 実装は簡単
• 関連が切れてしまう
• plugin: data_fabric, octopus

2009/08 2010/01 2011/01 2012/01
なう
ココ

version 2.0
Web Web • mongrel
• MySQL 5.0
Mem M1 M2
• Memcached
TT S S
S S • TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう
ココ

version 2.1
Web Web • mongrel
• MySQL 5.0
Mem M1 M2 M3
• Memcached
TT S S S
S S S • TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう
ココ

version 2.2
Web Web • mongrel
• MySQL 5.0
Mem M1 M2 M3 M4
• Memcached
TT S S S S
S S S S • TokyoTyrant

2009/08 2010/01 2011/01 2012/01
なう
ココ

垂直分散の結果
• 5分割まで突入
• ある程度負荷は分散できた
• 運用コスト増
• メンテナンス大変
• 限界が見えてきた

2009/08 2010/01 2011/01 2012/01
なう
ココ

2010/秋

2009/08 2010/01 2011/01 2012/01
なう
ココ

比較的サービスが
安定している日々


2009/08 2010/01 2011/01 2012/01
なう
ココ

突如


2009/08 2010/01 2011/01 2012/01
なう
ココ

レスポンスが遅くなる


2009/08 2010/01 2011/01 2012/01
なう
ココ

遅くなる原因
• サービス内部要因
• Datastoreが遅い
• 処理内容が大きい
• サービス外部要因
• 外部APIの応答が遅い

2009/08 2010/01 2011/01 2012/01
なう
ココ

それResqueでできるよ


2009/08 2010/01 2011/01 2012/01
なう
ココ

非同期処理導入
• 時間のかかる処理をリクエスト処理と
分離

• Resque gem
• github内で使われている
• キューとしてRedisを使用

2009/08 2010/01 2011/01 2012/01
なう
ココ

version 3.0
Web Web • mongrel
• Redis+Resque
Mem M1 M2 Redis

• MySQL 5.0
S S worker
S S • Memcached

2009/08 2010/01 2011/01 2012/01
なう
ココ

Resque
• ヘビーな処理を後ろに回せるように
なった

• Redisの安定運用は意外と難しい
• クセやハマりどころを知っていれば。
• Resque workerは1job 1forkしている
のでそれなりにコスト高い


2010/冬


2009/08 2010/01 2011/01 2012/01
なう
ココ

フロントの構成を
刷新した


2009/08 2010/01 2011/01 2012/01
なう
ココ

version 4.0
LB LB • Nginx 1.0.x
Web Web Web Web • Unicorn
App App App App
• Rails 3.0
• Redis+Resque
Mem M1 M2 Redis

• MySQL 5.1
S S worker
S S • Memcached

2009/08 2010/01 2011/01 2012/01
なう
ココ

モダンな構成（＾ω＾）


2009/08 2010/01 2011/01 2012/01
なう
ココ

2011/夏


2009/08 2010/01 2011/01 2012/01
なう
ココ

3度目の夏


2009/08 2010/01 2011/01 2012/01
なう
ココ

ヒットアプリも
増えて迎えた夏


2009/08 2010/01 2011/01 2012/01
なう
ココ

カードバトルシステムに
洗礼を受ける


2009/08 2010/01 2011/01 2012/01
なう
ココ

カードバトルのPV
•農園系など

• 150 250PV/Day/User

•カードバトル

• 350 750PV/day/user

2009/08 2010/01 2011/01 2012/01
なう
ココ

•150 250PV/Day/User

•350 750PV/day/user

( ﾟдﾟ)


2009/08 2010/01 2011/01 2012/01
なう
ココ

(つд )ｺﾞｼｺﾞｼ


2009/08 2010/01 2011/01 2012/01
なう
ココ

•150 250PV/Day/User

•350 750PV/day/user

( ﾟдﾟ)三倍・・？


2009/08 2010/01 2011/01 2012/01
なう
ココ

平均30ポチ/1h

2009/08 2010/01 2011/01 2012/01
なう
ココ

_, ._
（；ﾟ Дﾟ）


2009/08 2010/01 2011/01 2012/01
なう
ココ

ギリギリの運用


2009/08 2010/01 2011/01 2012/01
なう
ココ

SQLチューニングが
続くある日


2009/08 2010/01 2011/01 2012/01
なう
ココ

MySQLが悲鳴を上げ
る


2009/08 2010/01 2011/01 2012/01
なう
ココ

あれ？つながらない
またかよー・・

数時間置きに
運営はやくしろ
数分アクセス
できなくなる事象


2009/08 2010/01 2011/01 2012/01
なう
ココ

通称
「ちゅどる」※社内呼称


根本的解決には
数週間を要した


そしてあろうことか


あれーまたかーしょうがないなぁ
５分待つか・・・

ユーザさんが障害に
馴れてしまった・・
別なゲームやっとくか


2009/08 2010/01 2011/01 2012/01
なう
ココ

調査の結果


2009/08 2010/01 2011/01 2012/01
なう
ココ

MySQLが
ある処理を行なっている
ことが判明した


2009/08 2010/01 2011/01 2012/01
なう
ココ

full checkpointing

http://www.mysqlperformanceblog.com/
2008/11/13/adaptive-checkpointing/

2009/08 2010/01 2011/01 2012/01
なう
ココ

full checkpointing

• 更新処理が数時間に一回、数分ほど更
新が完全に停止する

• 更新量に応じて発生
• データ領域へのﬂush処理


2009/08 2010/01 2011/01 2012/01
なう
ココ

解決策を探していた


2009/08 2010/01 2011/01 2012/01
なう
ココ

誰かが言った


2009/08 2010/01 2011/01 2012/01
なう
ココ

「Percona使おうぜ」


2009/08 2010/01 2011/01 2012/01
なう
ココ

Percona Server

• MySQLをベースにしている
• 特にInnoDB部分に多数のpatchが当
たっている

• ﬂush処理の高速化、SSD最適化等


2009/08 2010/01 2011/01 2012/01
なう
ココ

Percona Server

• innodb_ﬂush_neighbor_pages = 0
• innodb_adaptive_checkpoint =
keep_avarage

• innodb_io_capacity = xxxx;


2009/08 2010/01 2011/01 2012/01
なう
ココ

しかし


2009/08 2010/01 2011/01 2012/01
なう
ココ

導入したとしても
先が見えない


2009/08 2010/01 2011/01 2012/01
なう
ココ

IOは既に限界突破


2009/08 2010/01 2011/01 2012/01
なう
ココ

また誰かが言った


2009/08 2010/01 2011/01 2012/01
なう
ココ

「Fusion-io 使おう」


2009/08 2010/01 2011/01 2012/01
なう
ココ

Fusion-io ioDrive


2009/08 2010/01 2011/01 2012/01
なう
ココ

Fusion-io ioDrive

• 200,000+iops >> 600 iops(RAID10)
• レイテンシ低
• 弊社の検証でPercona Server5.5 +
ioDrive では、MySQL5.1+RAID10の
約5倍の性能(参照:更新=10:1)


2009/08 2010/01 2011/01 2012/01
なう
ココ

version 5.0
LB LB • Nginx 1.x
Web Web Web Web • unicorn 4.1
App App App App
• Rails 3.0
• Percona Server
Mem M1 M2 Redis 5.5

S S worker • Memcached,
S S Redis...


2009/08 2010/01 2011/01 2012/01
なう
ココ

Percona + ioDrive
• 問題は解決
• Fusion-ioは甘え
• キャパシティに余裕ができた
• なんとコストが下がった (5cluster =>
1 2cluster)


2009/08 2010/01 2011/01 2012/01
なう

ココ

そして現在に至る


未来への投資


スケーラブルで安定した
システムを作るため


2009/08 なう

投資

•
稼働率の向上

•スケーラビリティの向上


2009/08 なう

稼働率の向上

• シングルポイントを潰す
• 自動フェイルオーバー


シングルポイント
LB LB

Web Web Web Web
App App App App

Mem M1 M2 Redis

S S worker
S S


2009/08 なう

CacheサーバのHA化
• Memcached

• マシンのメンテができない

• Replication

• kyototycoonのmemcached protocol

• dual master構成

• monit+keepalived


RedisサーバのHA化

• Redis
• replication
• 多少のデータロストは諦める


2009/08 なう

DBサーバのHA化

• Semi-Sync Replication(on
MySQL5.5)

• スペアサーバが自動的にスレーブに


現在の構成
LB LB

Web Web Web Web
App App App App

KT M1 M2 Redis Redis

KT S S worker worker
S S


2009/08 なう

スケーラビリティ

• 水平分散
• MySQL Spiderを検討していたが、
更新性能、JOIN性能の部分で断念

• ActiveRecord Sharding pluginの検
討


2009/08 なう

Turntable(仮)
• ActiveRecord Sharding plugin
• MySQL Spiderにインスパイアされた
• shardingはほぼ自動化されているた
め、本質的なコードに集中できる

• 他のpluginに比べ、コードの変更が少
ない


2009/08 なう

Turntable(仮)は
本年度内に公開予定


ドリコムでは、
このような取り組みを
行なって


想定しうるトラフィック
への対応を進めています


まとめ


話したこと
• ソーシャルゲーム怖い
• ドリコムのサービススケーリングのこれ
まで

• ドリコムのサービススケーリングの未来

これからも引き続き


ユーザさんに
満足頂けるサービス
を提供


ご清聴ありがとうございました。


Thank you

ドリコムでは、
大規模トラフィックが大好きな
仲間を募集しています


ソーシャルゲームスケールアウトの歴史

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from Drecom Co., Ltd.

More from Drecom Co., Ltd. (20)

Recently uploaded

Recently uploaded (9)

ソーシャルゲームスケールアウトの歴史