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

ソーシャルゲーム
スケールアウトの歴史
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

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


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

More Related Content

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