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が好きなわけではない

• 最初は３人しかいなかった

• 高トラフィックの情報が圧倒的に少ない

• 結果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名在籍中！

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