テスターですが何か?

ホビープログラマ略してHPです

MS×gloops合同セミナーに参加してきました

leave a comment »

品川マイクロソフトで行われたセミナー「全部見せます!ASP.NETで開発した大規模ソーシャルゲーム」に参加してきました。Windowsプラットフォームでソーシャルゲームを運営しているgloopsのエンジニアを迎えてのセミナーでした。

以下、自分の手元のメモです。

 

gloopsという会社の紹介(川方さん)

  • はじめはNENDOというゲームをリリースしたが、技術にこだわりすぎてあまりウケなかった。
  • モバイルをなめていたが、モバイル向けのゲームをリリースしたらウケた。
  • モバイルソーシャルゲームをリリースしたら大受けした。
  • 1年半で13ゲームをリリース、Mobageランキングでもいくつか上位にランクインしている。

開発チームについて

  • サービスごとに7~12名の体制、すべて内製
  • チームないにPM、ME、デザイナーなどの役割を設けている

現在

  • 126億Req/月

今後

  • やっぱり海外進出

なぜWindowsプラットフォームなのか

  • GUIが充実していて教育しやすい
  • 短期でサービスをリリース可能
  • 高負荷状態でも安定して稼動してくれる

 

gloopsを支える技術(池田さん)

提供するサービス

  • SNS(Mobage)がプラットフォームを提供しているので、そこにゲームを載せて提供している

システムについて

  • 普通のWebアプリ
  • プラットフォームのAPIを利用している
  • 超膨大なトラフィック

構成

  • クライアントからのリクエストはSNS事業者のサーバー経由で来る
  • ユーザーに関する情報は保持しておらず、API経由で取得する
  • OpenSocial, OAuthを使用している、他のプラットフォームへ移植しやすい

image

膨大なアクセス

  • 一気にアクセスが増大する可能性があり、スモールスタートはできない
  • 50万ユーザー登録/週、3.5億Req/日(4000Req/秒)
  • SNSプラットフォームへ5秒以内にレスポンスを返さないとユーザーへはタイムアウトが通知される
  • 1000回/3分のタイムアウトでSNS事業者から強制メンテナンス状態にされる
  • レスポンスタイムは超シビア(レスポンスが悪くなるとユーザーは使ってくれない)

ここから本題

システム構成

  • ASP.NET WebForm + C#
  • Windows Server + IIS
  • SQL Server
  • ngixでロードバランス
  • memcached, Redisをキャッシュサーバーとして使用

インフラ

  • サーバーは国内のDCに数百台
  • 1タイトルで最大50台のサーバーを使用
  • 以下のように普通の構成

image

大量のトラフィックをさばくには

アプリの最適化

  • 不必要なデータベースへのアクセスを行わない
  • SNSAPIへのアクセスを非同期に
  • 基本をしっかりやる。手を抜くと絶対にそこがボトルネックになる
  • 例:冗長DBアクセス、デバッグモードのログ・メールをそのまま本番移行
  • 開発時にはクエリパフォーマンスを常時モニタ、画面に出すようにして遅いクエリにすぐ気づけるようにしている

キャッシュの利用

  • マスタはオンメモリのDataTableに保持
  • 持てるものは全部メモリに持つ、ASP.NETが持つキャッシュ機能は最大限利用する

データベース

  • 1億件のテーブル
  • ボトルネックになるのはDBが多い
  • スケールアウトしにくい
  • データベースのパフォーマンスチューニングも基本が大事!!!
  • ディスクアクセスはメモリアクセスよりも何千倍も遅い
  • メモリにあるデータへアクセスする、ディスクI/Oを発生させない
  • ディスク書き込みはコミットのタイミングではない、チェックアウトのタイミングであることを意識する
  • インデックスは絶対使う
  • クエリの書き方にも注意(データを絞り込んでからJOINする)
  • Row_Number関数、Rank関数など内部的にソートが行われる処理は注意
  • データ件数が数千万になる辺りから性能問題が発生しやすい
  • オンライン中のテーブル定義変更
  • 全件count(sys.sysindex使えよ!)
  • データのスキャン方法(シーケンシャル/ランダム)を意識
  • ソートが遅くなることが多い
  • インデックスを使わないクエリは論外!
  • ログの自動拡張は注意、デフォルトでは10%拡張なので10GBのログだと1GBの領域を割り当てようとする…
  • テーブル変数、一時テーブルを使うことでtempDBがボトルネックにになることも

トラブルは尽きない orz

  • 1回はしょうがない、2回同じことが起きないようにすることが重要

DB負荷低減

  • KVSをキャッシュサーバーとして使用
  • DBの垂直分割、水平分割
  • 高速なストレージを使う(スケールアップ)

KVSとは

  • HashTableのようにkeyに対してvalueを持つもの
  • NoSQLとして注目
  • memcachedとRedisを使用している

memcached

  • データは永続化できない(サーバー、IISのワーカプロセスが終了すると…)
  • 複雑なデータの格納は向かない
  • 実績が多い(使ってないWebサービスはないのでは?)

Redis

  • 単純データだけでなく、List,Hashなどを格納可能
  • ディスクに非同期で書きこむことができ、永続化可能
  • レプリケーション可能
  • ニコ生で使われて注目を浴びている

KVSの使い所

  • 一時的なデータ
  • 更新頻度の多いデータ(経験値、スタミナ など)←都度DBに書きこむなんてありえない
  • 最終的にDBに書きこむデータ(ここはRedisを使う?)

DB分割

  • 垂直分割(テーブルをグループ化して分割、トランザクション制御に注意)
  • 推定分割(同一テーブルをキーで分割、アプリからは同じテーブルに見せる必要がある)

ディスクI/Oがボトルネックになりやすい

  • CPUやメモリの進化に対して、ディスクがアクセススピードは進化が遅い

高速なストレージの利用

  • PCIeのSSDを使用
  • SAS(RAID 10) → 5,500スコア、SSO → 120,000スコア、圧倒的な速さ

運用

  • 担当者のアイディアよりも、データ分析を重視
  • KPI数値(DAU、ARPU 平均課金額, 継続率 何日連続てユーザーが使うか)はいつでも誰でも見えるようにしている
  • 高速なPCDA

開発スタイル

  • ドキュメントは書かない
  • 基本的な考え方をwikiに書く
  • テーブル定義なんてあるわけない
  • 動くものが最新の使用

今後やりたいこと

  • データ分析基盤の構築(いわゆるBigData)
  • Azure上での動作、レスポンス検証

最後に

  • 基本が大事
  • 技術を正しく理解する

 

個人的な感想

ソーシャルゲームだからといって特別なことはしてないという印象でした。「ディスクにアクセスさせず、メモリにアクセスさせる」「よぶんなDBアクセスはしない」は、聞いててものすごく共感できる内容でした、元はてなの伊藤さんが書いた「[Web開発者のための]大規模サービス技術入門 ―データ構造,メモリ,OS,DB,サーバ/インフラ」の内容を思い出しました。「技術を正しく理解して、基本を大事にする」は、どの分野でも同じなのだと思います。業務アプリでもソーシャルゲームアプリでも、WebアプリでRDBを使用している点は同じですから、同じ事で悩んで同じベストプラクティスとなるんだと思います。

そういう意味ではSIerからソーシャルゲームアプリエンジニアへの転職も全然ありだと思います。今まで身につけたスキルは十分に生きると思います。あと、インフラの知識があると(ネットワーク、ロードバランシング、ハードウェア)重宝されるんじゃないでしょうか。利用者が限定されている業務アプリとは異なり、余裕のあるスペックを見積もっても、前提・想定以上のアクセスがくることは日常茶飯事でしょうから。

Written by david9142

2011年11月17日 @ 1:45 AM

カテゴリー: 未分類

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。