第77回codeseek勉強会＆第17回日本C#ユーザー会 勉強会

1. ASP.NET+C#で開発する
大規模ソーシャルゲーム
株式会社gloops CTO
池田秀行

2. 自己紹介
• 株式会社gloops CTO
• 前職ではJavaで金融向けSI
• 2007年に転職、Flexでnendo.tvを開発
• C#とJavaScriptが好き
• facebook.com/hikeda

3. アジェンダ
1. ソーシャルゲームとは？
2. 大規模サービスを支えるシステム構成
3. ソーシャルゲームの運用

4. 1. ソーシャルゲームとは？

5. ソーシャルゲームについて
• SNSがプラットフォームとしてAPIを提供
• サードパーティがPF上にアプリを提供可能
• FBのオープン化から急速に拡大（日本では
2009年から）

6. 従来のゲームとの違い
• 友達とプレイすることを前提としたアプリ
• 1回のプレイ時間が5分程度でも成り立つ
• 終わりのないゲームデザイン
• 運営中は継続的な改善の繰り返し
• コミュニケーションサービス

7. ちょっとだけゲームを紹介

9. DEMO

10. システム的な特徴
• 実は従来のWebアプリと変わらない
• プラットフォームの提供するAPIを使う
(OpenSocialAPI / OAuth)
• トラフィック量が半端ない

11. OpenSocialとは？
• 複数Webサイト間で使用可能なソーシャル
アプリケーションのための共通API
• 2007年にGoogleが開発
• 国内ではMobage/GREE/mixiなどが実装
• WAP向けは日本独自の拡張

12. OpenSocial WAP Extension
ゲーム側ではproxyされたリクエストを処理して
HTMLレスポンスを生成

13. リクエストの認証
• 2-legged OAuthの仕様に準拠
• Gadgetサーバーがリクエストヘッダに
access_tokenを付与
• access_tokenを元にAPIアクセスが可能
GET /index.aspx?opensocial_app_id=999999&opensocial_viewer_id=12345 HTTP/1.1
User-Agent: DoCoMo/2.0 N901iS(c100;TB;W24H12;ser12345;icc1234567890)
Authorization: OAuth realm="",oauth_consumer_key="xxx",oauth_signature="I%2BI...

14. APIの利用
• OpenSocial API
People / Message / Activity / AppData etc...
• Game API
Avatar / Payment / Ads / TextData etc...
• Service
Diary / Invite / Location etc...

15. 国内SNSプラットフォーム規模
• 会員数（2011年9月時点）
• Mobage : 3200万人
• GREE : 2700万人
• mixi : 2500万人

16. 2. 大規模サービスを支える
システム構成

17. サービス規模
• 2010年2月よりゲーム提供を開始
• 提供タイトル：17本（2012年4月現在）
• 会員数 : 1500万人
• 月間PV : 146億

18. 20,000
PV（単位：百万） ユーザ数（単位：千人）
15,000
10,000
5,000
0
2010/02 2010/08 2011/02 2011/08 2012/02

19. Q. どれくらいのトラフィックが来るの？

20. 膨大なトラフィック量
• リリース後5時間で10万人が登録
• リリース後1ヶ月で100万人が登録
• 1タイトルで65万DAU（Daily Active User）
• 3.5億PV/日（単純計算でも4000req/sec）
• イベント開始直後に8万人同時アクセス

21. クラスターにかかる負荷
• 同時セッション数：40万以上
• HTTPリクエスト：15万req/sec
• 転送量：3Gbps （画像系は除く）
• DBサーバー：ピークでは20万query/sec

22. 間違いなく国内でも最大規模！

23. システム構成
• 開発言語：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

24. Q. なんでWindows使ってるの？

25. システム構成の背景
• C#が好きだったから
• でもMicrosoftが好きなわけではない
• 最初は３人しかいなかった
• 高トラフィックの情報が圧倒的に少ない
• 結果Windows+Linuxのハイブリッド構成に

26. IIS + ASP.NETは速い！
（Linuxサーバーエンジニア談）

27. インフラ構成
LoadBalancer
nginx(LB) nginx(LB) ... • シンプルな構成
• 台数は1年半で
IIS IIS IIS ... 1000台+に
SQL Server ... memcached Redis

28. 1ゲームタイトルの規模例
• ロードバランサ：40台
• APサーバー：100台
FP用：40台、SP用：40台、Flash合成：20台
• memcached：4台、Redis：4台
• DBサーバー：3∼5台

29. 画像配信系
CDN(Akamai)
• とにかくキャッシュ
Varnish Varnish Varnish ... • スマホで画像も高解
像度化
nginx nginx nginx

30. 高トラフィックをさばくには
1) アプリケーションの最適化
2) キャッシュの活用
3) DBチューニング & 処理の軽減
4) 今後に向けて

31. 1) アプリケーションの最適化

32. APサーバー
• ソーシャルゲームの処理はステートレス
• スケールは比較的容易
• 手を抜いた実装はボトルネックに
• 台数が多いためデプロイが手間

33. 実装上での心がけ
• 冗長な処理をしない
• データアクセスの最適化
• 処理の非同期化
• ページサイズの最適化（100KB制限）
• C#でできることはC#で（LINQ使えば楽）

34. 冗長な処理のモニタリング
• 1リクエスト内でのDBアクセス数
• KVSアクセス数
• 外部APIリクエスト数
• DataBind回数（WebFormなので‥）

35. 処理の非同期化
• 外部APIへのアクセスは非同期処理で
PageAsyncTask / IHttpAsyncHandler
• C# 5.0の非同期処理に期待（async/await）

36. ASP.NET 4になって
• ViewState制御の改善（ViewStateMode）
• アプリケーションプールの Auto-Start
• ウォームアップ（IProcessHostPreloadClient）
• カスタムOutputCacheProvider

37. 2) キャッシュの活用

38. 様々なキャッシュ
• 変更のないマスタデータはオンメモリの
DataTableに保持
• HttpContext.Itemsの利用
• ASP.NET Cacheの利用
• @OutputCacheディレクティブ

39. リクエスト毎 / プロセス毎 / アプリ全体
あらゆる粒度でキャッシュを活用

40. KVSキャッシュサーバーも積極利用

41. 3) DBチューニング & 処理軽減

42. 前提として・・
• 更新処理が非常に多い
• ビッグデータ
• 気づけば6億件を超えるテーブルも
• ボトルネックは間違いなくDBになる
• DB処理をいかにさばけるかが勝負

43. DBの基本動作理解も大事
• Disk Readを発生させない
• シーケンシャル／ランダムアクセス
• インデックス動作
• ソート処理
• チェックポイント処理

44. DB負荷軽減のために
• KVSの利用
• 垂直分割と水平分割
• 高速フラッシュストレージの導入

45. KVS（Key Value Store）の利用
• 一意のkeyに対して任意のvalueを保存する
データ管理システム
• RDBMSに変わるNoSQLとして注目
• memcachedとRedisを利用

46. memcached
• オンメモリのハッシュテーブル
• データの永続性はない
• 読み込み／書き込みともに高速
• 複雑なデータ構造には向いていない
• 利用実績が豊富

47. Redis
• memcachedよりも機能が充実
• 様々なデータ構造(List/Set/SortedSet/Hash)
• ディスクへの非同期書き込み
• レプリケーション機能
• github/craigslist/digg/DISQUS/stackoverflow
などで実績

48. KVSの使いどころ
• Expireする一時的なデータストアとして
• 更新頻度の高いデータを管理
経験値 / スタミナ / 達成率 など
• KVSを常時更新し、適切なタイミングでDB
に書き込むケースも

49. データの信頼性よりも
トラフィックをさばくことの方が
圧倒的に重要

50. DBの分割について
• 垂直分割
テーブルを機能毎に分割
JOINはしない
• 水平分割
同一テーブルをキーにより分割
Range Partitioning / Hash Partitioning

51. DBのボトルネックはI/Oに
• 行きつく所はほとんどがディスクI/O
• CPU/DRAMの高速化、ストレージ大容量化
• 20年でCPUは数百万倍、ストレージは10倍
• 両者間のレイテンシが増大

52. 高速ストレージの導入
• 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

53. 近年のストレージは
進展が目覚ましい！

54. さらに上を行く製品も
• 2011/11 ioDrive Octalを発表
• PCIe 2スロット 容量10TB
• 1,300,000 IOPS
• read性能 6.7GB/s write性能 3.9GB/sec

55. 4) 今後への取り組み

56. 今取り組んでいること
• Windows Azureでの動作検証
• SQL Azure Federationのスケーラビリティ
• 海外展開するにはクラウド有利

57. 3. ソーシャルゲームの運用

58. 開発スタイル
• 2年間で17タイトルをリリース
• 開発期間は2ヶ月程度
• サービスはリリースしてからが始まり

59. 継続的改善
• ideas→build→code→measure→data→learnの
繰り返し
• Learn Fasterを心がける
• 実装することが目的ではない
• 最短命のアプリは1週間でクローズ

60. 運用スタイル
• データ分析を重視した改善プロセス
• 各種KPI数値 ex) DAU, ARPU, 継続率
• 動向把握を最速で（Monthly/Daily/Hourly）
• 継続的デプロイ

61. 高速PDCAを実現する開発
• ドキュメントは書かない
• 基本事項だけWikiに
• テーブル定義書もない
• 動くものが最新仕様

62. トラブルは尽きない...
• サービスが急成長し続けている限り、未知
の問題は常に発生する
• ミスは必ず起こるが繰り返さなければ良い
• 失敗を通じて成長していくカルチャー

63. まとめ
• ソーシャルゲームの概要を紹介
• システム構成と高トラフィックへの取り組
みを紹介
• ソーシャルゲームの運用スタイルを紹介

64. 最後にちょっとだけ宣伝

65. C#エンジニア募集中！
• 自社サービスの開発面白い！
• C#イケてるよ！ってのを広めたい！
• Microsoft MVPも2名在籍中！

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