Download as PDF, PPTX
More Related Content
20120407 ASP.NET＋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.
- 5. ソーシャルゲームについて • SNSがプラットフォームとしてAPIを提供 • サードパーティがPF上にアプリを提供可能 •FBのオープン化から急速に拡大（日本では 2009年から）
- 6. 従来のゲームとの違い • 友達とプレイすることを前提としたアプリ • 1回のプレイ時間が5分程度でも成り立つ •終わりのないゲームデザイン • 運営中は継続的な改善の繰り返し • コミュニケーションサービス
- 7.
- 9.
- 10. システム的な特徴 • 実は従来のWebアプリと変わらない • プラットフォームの提供するAPIを使う (OpenSocialAPI / OAuth) • トラフィック量が半端ない
- 11. OpenSocialとは？ • 複数Webサイト間で使用可能なソーシャル アプリケーションのための共通API •2007年にGoogleが開発 • 国内ではMobage/GREE/mixiなどが実装 • WAP向けは日本独自の拡張
- 12.
- 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.
- 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.
- 25. システム構成の背景 • C#が好きだったから • でもMicrosoftが好きなわけではない •最初は３人しかいなかった • 高トラフィックの情報が圧倒的に少ない • 結果Windows+Linuxのハイブリッド構成に
- 26.
- 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.
- 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.
- 38. 様々なキャッシュ • 変更のないマスタデータはオンメモリの DataTableに保持 •HttpContext.Itemsの利用 • ASP.NET Cacheの利用 • @OutputCacheディレクティブ
- 39. リクエスト毎 / プロセス毎/ アプリ全体 あらゆる粒度でキャッシュを活用
- 40.
- 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.5KSAS DIsk × 6本（RAID 10）: 5,500 IOPS • ioDrive Duo × 1枚 : 120,000 IOPS • ioDrive Duo × 2枚（Striping）: 200,000 IOPS
- 53.
- 54. さらに上を行く製品も • 2011/11 ioDriveOctalを発表 • PCIe 2スロット 容量10TB • 1,300,000 IOPS • read性能 6.7GB/s write性能 3.9GB/sec
- 55.
- 56. 今取り組んでいること • Windows Azureでの動作検証 •SQL Azure Federationのスケーラビリティ • 海外展開するにはクラウド有利
- 57.
- 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.