20120407 asp.net+c#で開発する大規模ソーシャルゲーム
DESCRIPTION
第77回codeseek勉強会&第17回日本C#ユーザー会 勉強会TRANSCRIPT
ASP.NET+C#で開発する大規模ソーシャルゲーム
株式会社gloops CTO
池田秀行
自己紹介
• 株式会社gloops CTO
• 前職ではJavaで金融向けSI
• 2007年に転職、Flexでnendo.tvを開発
• C#とJavaScriptが好き
• facebook.com/hikeda
アジェンダ
1. ソーシャルゲームとは?
2. 大規模サービスを支えるシステム構成
3. ソーシャルゲームの運用
1. ソーシャルゲームとは?
ソーシャルゲームについて
• SNSがプラットフォームとしてAPIを提供
• サードパーティがPF上にアプリを提供可能
• FBのオープン化から急速に拡大(日本では2009年から)
従来のゲームとの違い
• 友達とプレイすることを前提としたアプリ
• 1回のプレイ時間が5分程度でも成り立つ
• 終わりのないゲームデザイン
• 運営中は継続的な改善の繰り返し
• コミュニケーションサービス
ちょっとだけゲームを紹介
DEMO
システム的な特徴
• 実は従来のWebアプリと変わらない
• プラットフォームの提供するAPIを使う(OpenSocialAPI / OAuth)
• トラフィック量が半端ない
OpenSocialとは?
• 複数Webサイト間で使用可能なソーシャルアプリケーションのための共通API
• 2007年にGoogleが開発
• 国内ではMobage/GREE/mixiなどが実装
• WAP向けは日本独自の拡張
OpenSocial WAP Extension
ゲーム側ではproxyされたリクエストを処理してHTMLレスポンスを生成
リクエストの認証• 2-legged OAuthの仕様に準拠
• Gadgetサーバーがリクエストヘッダにaccess_tokenを付与
• access_tokenを元にAPIアクセスが可能
GET /index.aspx?opensocial_app_id=999999&opensocial_viewer_id=12345 HTTP/1.1User-Agent: DoCoMo/2.0 N901iS(c100;TB;W24H12;ser12345;icc1234567890)Authorization: OAuth realm="",oauth_consumer_key="xxx",oauth_signature="I%2BI...
APIの利用
• OpenSocial API
People / Message / Activity / AppData etc...
• Game API
Avatar / Payment / Ads / TextData etc...
• Service
Diary / Invite / Location etc...
国内SNSプラットフォーム規模
• 会員数(2011年9月時点)
• Mobage : 3200万人
• GREE : 2700万人
• mixi : 2500万人
2. 大規模サービスを支えるシステム構成
サービス規模
• 2010年2月よりゲーム提供を開始
• 提供タイトル:17本(2012年4月現在)
• 会員数 : 1500万人
• 月間PV : 146億
0
5,000
10,000
15,000
20,000
2010/02 2010/08 2011/02 2011/08 2012/02
PV(単位:百万) ユーザ数(単位:千人)
Q. どれくらいのトラフィックが来るの?
膨大なトラフィック量
• リリース後5時間で10万人が登録
• リリース後1ヶ月で100万人が登録
• 1タイトルで65万DAU(Daily Active User)
• 3.5億PV/日(単純計算でも4000req/sec)
• イベント開始直後に8万人同時アクセス
クラスターにかかる負荷
• 同時セッション数:40万以上
• HTTPリクエスト:15万req/sec
• 転送量:3Gbps (画像系は除く)
• DBサーバー:ピークでは20万query/sec
間違いなく国内でも最大規模!
システム構成
• 開発言語:ASP.NET + C#(.NET Framework 4)
• データベース:SQL Server 2008 R2
• Applicationサーバー:IIS7.5
• Load Balancer( Webサーバー):nginx
• KVS(Key Value Store):memcached, Redis
• 画像配信系:CDN + Varnish + nginx
Q. なんでWindows使ってるの?
• C#が好きだったから
• でもMicrosoftが好きなわけではない
• 最初は3人しかいなかった
• 高トラフィックの情報が圧倒的に少ない
• 結果Windows+Linuxのハイブリッド構成に
システム構成の背景
IIS + ASP.NETは速い!(Linuxサーバーエンジニア談)
インフラ構成
• シンプルな構成
• 台数は1年半で1000台+に...
...
IIS IIS IIS
memcached RedisSQL Server
nginx(LB)
LoadBalancer
nginx(LB) ...
1ゲームタイトルの規模例
• ロードバランサ:40台
• APサーバー:100台
FP用:40台、SP用:40台、Flash合成:20台
• memcached:4台、Redis:4台
• DBサーバー:3~5台
画像配信系
• とにかくキャッシュ
• スマホで画像も高解像度化
...Varnish Varnish
CDN(Akamai)
nginx nginx nginx
Varnish
高トラフィックをさばくには
1)アプリケーションの最適化
2)キャッシュの活用
3) DBチューニング & 処理の軽減
4)今後に向けて
1) アプリケーションの最適化
APサーバー
• ソーシャルゲームの処理はステートレス
• スケールは比較的容易
• 手を抜いた実装はボトルネックに
• 台数が多いためデプロイが手間
実装上での心がけ
• 冗長な処理をしない
• データアクセスの最適化
• 処理の非同期化
• ページサイズの最適化(100KB制限)
• C#でできることはC#で(LINQ使えば楽)
冗長な処理のモニタリング
• 1リクエスト内でのDBアクセス数
• KVSアクセス数
• 外部APIリクエスト数
• DataBind回数(WebFormなので‥)
処理の非同期化
• 外部APIへのアクセスは非同期処理で
PageAsyncTask / IHttpAsyncHandler
• C# 5.0の非同期処理に期待(async/await)
ASP.NET 4になって
• ViewState制御の改善(ViewStateMode)
• アプリケーションプールの Auto-Start
• ウォームアップ(IProcessHostPreloadClient)
• カスタムOutputCacheProvider
2) キャッシュの活用
様々なキャッシュ
• 変更のないマスタデータはオンメモリのDataTableに保持
• HttpContext.Itemsの利用
• ASP.NET Cacheの利用
• @OutputCacheディレクティブ
リクエスト毎 / プロセス毎 / アプリ全体あらゆる粒度でキャッシュを活用
KVSキャッシュサーバーも積極利用
3) DBチューニング & 処理軽減
前提として・・
• 更新処理が非常に多い
• ビッグデータ
• 気づけば6億件を超えるテーブルも
• ボトルネックは間違いなくDBになる
• DB処理をいかにさばけるかが勝負
DBの基本動作理解も大事
• Disk Readを発生させない
• シーケンシャル/ランダムアクセス
• インデックス動作
• ソート処理
• チェックポイント処理
DB負荷軽減のために
• KVSの利用
• 垂直分割と水平分割
• 高速フラッシュストレージの導入
KVS(Key Value Store)の利用
• 一意のkeyに対して任意のvalueを保存するデータ管理システム
• RDBMSに変わるNoSQLとして注目
• memcachedとRedisを利用
memcached
• オンメモリのハッシュテーブル
• データの永続性はない
• 読み込み/書き込みともに高速
• 複雑なデータ構造には向いていない
• 利用実績が豊富
Redis
• memcachedよりも機能が充実
• 様々なデータ構造(List/Set/SortedSet/Hash)
• ディスクへの非同期書き込み
• レプリケーション機能
• github/craigslist/digg/DISQUS/stackoverflow
などで実績
KVSの使いどころ
• Expireする一時的なデータストアとして
• 更新頻度の高いデータを管理経験値 / スタミナ / 達成率 など
• KVSを常時更新し、適切なタイミングでDB
に書き込むケースも
データの信頼性よりもトラフィックをさばくことの方が
圧倒的に重要
DBの分割について
• 垂直分割テーブルを機能毎に分割
JOINはしない
• 水平分割同一テーブルをキーにより分割
Range Partitioning / Hash Partitioning
DBのボトルネックはI/Oに
• 行きつく所はほとんどがディスクI/O
• CPU/DRAMの高速化、ストレージ大容量化
• 20年でCPUは数百万倍、ストレージは10倍
• 両者間のレイテンシが増大
高速ストレージの導入
• PCIe型のSSDを導入(FusionIO社ioDrive)
• 1.5K SAS DIsk × 6本(RAID 10): 5,500 IOPS
• ioDrive Duo × 1枚 : 120,000 IOPS
• ioDrive Duo × 2枚(Striping): 200,000 IOPS
近年のストレージは
進展が目覚ましい!
さらに上を行く製品も
• 2011/11 ioDrive Octalを発表
• PCIe 2スロット 容量10TB
• 1,300,000 IOPS
• read性能 6.7GB/s write性能 3.9GB/sec
4) 今後への取り組み
今取り組んでいること
• Windows Azureでの動作検証
• SQL Azure Federationのスケーラビリティ
• 海外展開するにはクラウド有利
3. ソーシャルゲームの運用
開発スタイル
• 2年間で17タイトルをリリース
• 開発期間は2ヶ月程度
• サービスはリリースしてからが始まり
継続的改善
• ideas→build→code→measure→data→learnの繰り返し
• Learn Fasterを心がける
• 実装することが目的ではない
• 最短命のアプリは1週間でクローズ
運用スタイル
• データ分析を重視した改善プロセス
• 各種KPI数値 ex) DAU, ARPU, 継続率
• 動向把握を最速で(Monthly/Daily/Hourly)
• 継続的デプロイ
高速PDCAを実現する開発
• ドキュメントは書かない
• 基本事項だけWikiに
• テーブル定義書もない
• 動くものが最新仕様
トラブルは尽きない...
• サービスが急成長し続けている限り、未知の問題は常に発生する
• ミスは必ず起こるが繰り返さなければ良い
• 失敗を通じて成長していくカルチャー
まとめ
• ソーシャルゲームの概要を紹介
• システム構成と高トラフィックへの取り組みを紹介
• ソーシャルゲームの運用スタイルを紹介
最後にちょっとだけ宣伝
C#エンジニア募集中!• 自社サービスの開発面白い!
• C#イケてるよ!ってのを広めたい!
• Microsoft MVPも2名在籍中!
ご清聴ありがとうございました