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...
APIの利用• OpenSocial API  People / Message / Activity / AppData etc...• Game API  Avatar / Payment / Ads / TextData etc...• ...
国内SNSプラットフォーム規模• 会員数(2011年9月時点)• Mobage : 3200万人• GREE : 2700万人• mixi : 2500万人
2. 大規模サービスを支える   システム構成
サービス規模• 2010年2月よりゲーム提供を開始• 提供タイトル:17本(2012年4月現在)• 会員数 : 1500万人• 月間PV : 146億
20,000          PV(単位:百万)          ユーザ数(単位:千人)15,00010,000 5,000    0    2010/02   2010/08   2011/02   2011/08   2012/02
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...
Q. なんでWindows使ってるの?
システム構成の背景• C#が好きだったから• でもMicrosoftが好きなわけではない• 最初は3人しかいなかった• 高トラフィックの情報が圧倒的に少ない• 結果Windows+Linuxのハイブリッド構成に
IIS + ASP.NETは速い!(Linuxサーバーエンジニア談)
インフラ構成           LoadBalancer     nginx(LB)         nginx(LB) ...      • シンプルな構成                                          ...
1ゲームタイトルの規模例• ロードバランサ:40台• APサーバー:100台 FP用:40台、SP用:40台、Flash合成:20台• memcached:4台、Redis:4台• DBサーバー:3∼5台
画像配信系     CDN(Akamai)                                  • とにかくキャッシュVarnish   Varnish   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)• カスタムOutputCache...
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/stac...
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• ioDr...
近年のストレージは進展が目覚ましい!
さらに上を行く製品も• 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名在籍中!
ご清聴ありがとうございました
20120407 ASP.NET+C#で開発する大規模ソーシャルゲーム
Upcoming SlideShare
Loading in …5
×

20120407 ASP.NET+C#で開発する大規模ソーシャルゲーム

8,967
-1

Published on

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

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
8,967
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
31
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

20120407 ASP.NET+C#で開発する大規模ソーシャルゲーム

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

    Clipping is a handy way to collect important slides you want to go back to later.

×