gumistudy#1 kvs 発表資料
TRANSCRIPT
ソーシャルアプリにおけるKVSの利用事例
株式会社gumi堀内康弘
株式会社gumi CTOTwitter: horiuchi10年くらいウェブアプリ作ってます。Perl 10年、Python 1年ゲームが好きです。モンハン3予約しました!
ランニング、筋トレにはまってます。
自己紹介
会社紹介
35タイトル以上のアプリを開発・運用延べユーザ数10,000,000人多プラットフォーム展開mixi、モバゲ、GREE
ソーシャルゲームはもちろん、ソーシャルライフ分野のアプリも作ってます
ソーシャルゲーム x ソーシャルライフ
ソーシャルライフ系
ソーシャルゲーム系
サポートツール系
・空飛ぶ →マイミク通
信簿 340万
Rekoo 650万 →サンシャイン牧場 460万Rakoo 380万 →みんなの農園 160万 →みんなの動物広場 140万
・DeNA →怪盗ロワイヤル 250万
・ ウノウ →まちつく 270万
・ ベクター 190万 →恋する私の王子様 150万
・ GPS連動アド ・ リワードプラス（アドウェイズ）
・ poncan（ドリコム）
・ Facebook connect
・ mixi connect ・ connect with
twitter ・ gree connect
ファンクラブ
同級生掲示板
卒業アルバム
同級生を探せ
幕末英雄伝キャバウォーズ刑事ハードボイルド現在開発中×２
占い診断系×４０＋
ソーシャルライフ
ファンクラブ 220,000
人
同級生掲示板 520,000人
卒業アルバム おとなver. 300,000
人
同級生をさがせ！ 120,000人
占い、診断系アプリ
SM診断〜あなたの本性暴きます浮気性チェック！その愛本物？ﾆｾﾓﾉ？
犬タイプｖｓ猫タイプ草食系 vs 肉食系ザ★おバカ検定むっつり度ちぇ〜っ
く!!Ａ型度判定〜本当にＡ型ですか？常識・非常識〜あなた常識人？KY診断〜空気読めてる？ナルシスト★診断モテ↑非モテ↓診断Ｂ型度判定〜ジーマーで型Ｂ
？じじばば検定〜若さ保ってる？フリ派？フラれ派？ＡＢ型度判定〜ＡＢですが何か？
Ｏ型度判定〜う〜んＯ型かなぁ？２人のラブラブ度診断恋の成就度診断のだめカンタービレ進級試験初
級戦国雑学王決定戦★立志編
のだめマエストロコンクールノーマル？orアブノーマル？のだめカンタービレ進級試験中級のだめカンタービレ進級試験上級戦国クイズ王全国ランキング
合計 約600万ユーザー
ソーシャルゲーム
2010年2月 幕末英雄伝 670,000人2010年3月 キャバウォーズ 1,320,000人2010年4月 刑事ハードボイルド 600,000人2010年5,6,7 月 多プラットフォーム展開2010年8 月 ハッピー☆モデル 70,000人
file:///home/pptfactory/temp/src/police/ryoma/static_police_gree/images/mobile/240/landing/header.gif
file:///home/pptfactory/temp/src/cabaret/ryoma/static_cabaret/images/mobile/240/caba_top_plus.gif
file:///home/pptfactory/temp/src/sweet/ryoma/static_sweet/images/mobile/240/logo.gif
ソーシャルアプリの特徴
従来のウェブアプリとほとんど変わりません
ソーシャルアプリと従来のウェブアプリとの違い
やりとりする相手が違う。ユーザー認証の方法が違う。APIが用意されている。アクセス量が半端ない。データの更新頻度が高い(ゲーム)
やりとりする相手が違う
相手はプロバイダ(mixi,モバゲ,GREE)
ユーザー認証
Oauth signagureで身元保証QueryStringからユーザーID取得
opensocial_owner_id
GET /m/?opensocial_app_id=1234&opensocial_viewer_id=5678&opensocial_owner_id=5678
APIが用意されている
PeopleAPIユーザー情報、友達情報を取得ActivityAPIユーザーの行動履歴を更新PaymentAPI課金を行う招待を送れる仕組み位置情報を送信する仕組みひと言を送信する仕組み
膨大なアクセス量
リリース直後に数万人1ゲームで3000万PV/日
最初から負荷を考慮した設計が必要
どこがボトルネックになるの?
どこを考慮したらいいの?
ずばりDBです。
なぜDBがボトルネックになるの?
Writeのスケールが難しいテーブル毎にDBを分けたりテーブル自体を分割したり
SQLによっては時間がかかるたくさんの行を一度に読むようなSQL大きいテーブル同士をjoinするようなSQL
解決策は?
遅いクエリの見直し主キーによる参照を意識するManyToManyは基本使わないFilterもあまり使わないJoinもほとんど使わない
テーブル設計の見直し更新の多いカラムは別テーブルにする
それでもだめなら
DBへのアクセス自体を減らす
どうやってDBへのアクセスを減らすか?
そこで登場するのがKVSです
gumiで活用しているKVS
Memcached (Readを減らす)オンメモリなハッシュテーブルスケーラブルサーバを再起動するとデータは消えるDjango標準機能で簡単に使える
TokyoTyrant (Read Writeを減らす)モダンなDBMでデータの永続性ありMySQLより高速に読み書きできる読み書き20000qpsくらい
memcachedの使いどころ
毎回取得するようなモデルをキャッシュPlayerインスタンスをキャッシュ
リアルタイム性の低いページをまるごと@cache_pageデコレータ
2度押し対策の軽いセッション管理に
キャッシュ実装例
def get_player(id):
"""
idからプレイヤーインスタンスを取得 """
path = "/player/"+str(id)
player = cache.get(path, None)
if player is None: # キャッシュに存在しない try:
player = Player.objects.get(id=id)
cache.set(path, player) # インスタンスをsetできる except Player.DoesNotExist:
player = None
return player
TokyoTyrantの使いどころ
更新頻度の高いデータの管理プレイヤーの現在のパラメータ経験値、所持金
取得コストの高いSQLを発行するようなデータを管理する自分の近況一覧全国ランキング最大攻撃力貢ぎ物総額
サーバ構成
まとめ
memcached + TokyoTyrant
でDBのボトルネックをすっきり解消!
それでもだめなら「okuyama」で
ご静聴ありがとうございました。
