300万人が遊ぶソーシャルアプリ「おみせやさん」の作り方

芸者東京エンターテインメント株式会社山内 雅浩

発表内容

1. おみせやさんの紹介2. 負荷対策3. 開発と運用

おみせやさんの紹介

芸者東京エンターテインメント株式会社

2006年10月起業現在は主にソーシャルアプリを開発主な自社製品

2007年「それは無理だよ！オオスガさん」2008年「電脳フィギュア ARis」「アニメ さくらんBOY DT」2009年「おみせやさん for mixi」2010年「おみせやさん for GREE」2010年「お金持ちさん for mixi」 NEW!

http://www.geishatokyo.com/

「おみせやさん」

約300万人(2010年11月2日現在)が遊ぶソーシャルアプリ。商品を作り、友達と売り買いを楽しむゲーム。mixi, GREEのモバイルアプリとして提供中。芸者東京エンターテインメントが開発・運用をすべて自社で行っている。

おみせやさん for GREE

2010年6月末から提供開発言語：ScalaWEBフレームワーク：Liftストレージ：Cassandra, MySQL, memcached,Webサーバ：nginxアプリサーバ：TomcatOS：Debian GNU/Linux国内DCホスティングで数十台運用

ユーザーのデータはCassandraに保存。MySQLは、リソースデータと課金に関するデータを保存している。

おみせやさん for GREE 構成

おみせやさん for mixi

2009年9月末から提供開発言語：JavaWEBフレームワーク：Wicketストレージ：MySQL, memcached, Tokyo TyrantWebサーバ：nginxアプリサーバ：TomcatOS：Debian GNU/Linux国内DCハウジングで数十台運用

おみせやさん for mixi 構成

負荷対策

負荷対策のポイント

負荷対策の3つのポイント1. DB分割2. KVSの利用3. サーバのパラメータチューニング

水平分割と垂直分割

水平分割: 同じ機能を持ったDBをIDなどを元に複数台に分割する

垂直分割: 異なる機能を持ったDBをその機能やアクセス頻度にしたがって分割する。例えば正規化も垂直分割の1つ。

水平分割 (DB sharding)

DBをIDの値などで分割することで負荷を分散する。弊社では、Platform側のUserIDを元に、プログラム上で仮想的に128分割しており、Rangeで物理サーバーに割り当てている。例えば物理4台の場合、VirtualShardID = ID % 128DB1 : 0 <= VirtualShardID < 32DB2 : 32 <= VirtualShardID < 64DB3 : 64 <= VirtualShardID < 96DB4 : 96 <= VirtualShardID < 128物理サーバーを増やしたいときは、割り当てるRangeの設定を変更する

水平分割 の特性

メリット：1つのDBにデータをまとめる場合と比べてアクセスが分散する分割しただけ1つのDBあたりのデータ量が減る

デメリット：再分割・結合するのが容易ではない他のユーザデータを参照するような処理では複数のDBにアクセスする必要がある

負荷対策

負荷対策の3つのポイント1. DB分割2. KVSの利用3. サーバのパラメータチューニング

KVSの利用

RDB(Relational Data Base)に比べて読込、更新処理が高速なKVS(Key Value Store)を使うことでより多くのリクエストを処理できるようになる。

弊社で使っているKVSmemcachedCassandraTokyo Tyrant

memcached

1つのKeyに1つのValueを持つだけのシンプルなKVSメリット：

読み込み・書き込みともに高速各種言語へのインターフェースが豊富に存在

デメリット：データの永続性がない複雑なデータ構造を持たせるのが面倒

CassandraKVSの1つで複数台で運用されることを想定して作られたシステムメリット：

単一障害点がない。クラスタリングしてくれるので、スケールアウトが容易。逆に縮退するのも楽。クライアント側でのshardingが不要なのでプログラマに優しい。列指向データベースなので、(単純なKVSよりは)データを構造化しやすい。スキーマレスなのでデータ構造を変更しやすい。

デメリット：データの一貫性が低い。Indexがないので、データ解析がやりにくい(0.6.x)

※Indexは0.7.xから使えるようになるらしい

Cassandraのデータ構造

Cassandraのデータの具体例

KeySpace ColumnFamily Key Column Value

"PlayShop" "User" 11009 "nickname" Enock"point" 666

"lastAccess" 2010-11-02

"level" 5

KeySpace ColumnFamily Key SuperColum

n Column Value"PlayShop" "Possession" 11009@Material 00002_00002 "id" 2

"usableCount" 5

"voltage" 5

00002_00003 "id" 3

"usableCount" 4

"voltage" 0

User - ユーザー情報

OwnMaterial - 持っている商品の素

Cassandraのデータの持ち方

UserのlevelやOwnMaterialのvoltageは、サービス開始後しばらく経過してから追加した。修正はプログラム部分しか行っていない。一部のKeyやSuperColumnで0詰めした数値を_(アンダーバー)で繋いでいるが、これはSliceRangeで特定の範囲だけを取得出来るようにするため。OwnMaterialの00002_00003の前半の2は、スイーツ用の素を表しているため、SliceRangeで00002_00000~00002_99999の範囲を取得することでスイーツ用の素の情報だけを取得できる。ただしこれは、Indexがないから苦肉の策。ちなみに後半の3はMySQLに登録されている素のデータのID。

Tokyo Tyrant

更新速度とデータ永続性を両立したKVSメリット：・データ永続性があるデメリット：・スケールアウトさせるのが難しい

負荷対策

負荷対策の3つのポイント1. DB分割2. KVSの利用3. サーバのパラメータチューニング

JVM の GC

アプリケーション開始後、Edenにオブジェクトが格納される。EdenがいっぱいになるとNew GCが実行され、ライブオブジェクトはFromToへ。非ライブオブジェクトは開放される。FromToでも長時間生き残っているオブジェクトはTenuredへ。Tenuredが増えてくると、ライフオブジェクトをMark、非ライフオブジェクトをSweepする。時々Compactionでデフラグされる。OldがいっぱいになるとFull GCが実行され、長時間停止する。Permanent はリフレクションが使う領域。

JVM の GC パラメータチューニング

JVM(Java Virtual Machine) の GC パラメータを負荷テストの結果を見て調整する。弊社では負荷テストには Apache Bench と JMeter  を主に使っている。

GC チューニングのための設定Tomcat の gc log を有効にしておき、GCViewer でGCの動きを読む(-Xloggc:/path/to/gc.log)JMeter の結果ログから秒間レスポンス数やエラー率、遅延レスポンス数を見て、処理落ちしていないかを確認する。必要に応じてプロファイラを使い、メモリリークがないかをチェックする。

JVM GC グラフの比較

悪い例 良い例

JVM GC パラメータ

おみせやさんアプリサーバでの設定例-XX:+UseTLAB-Xms1981M-Xmx1981M-XX:NewSize=198M-XX:PermSize=128M-XX:MaxPermSize=256M-XX:SurvivorRatio=1024-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=0-XX:+AggressiveOpts-XX:+HeapDumpOnOutOfMemoryError-XX:+DoEscapeAnalysis-XX:+UseCompressedOops-XX:+UseParNewGC-XX:ParallelGCThreads=4-XX:+UseConcMarkSweepGC-XX:+CMSParallelRemarkEnabled-XX:CMSInitiatingOccupancyFraction=60

開発と運用

SWF合成

アバターや店を表現するのにSWFを合成しているPCではクライアント側で出来るが、ケータイおよびFlashLite1.1の制限によりサーバ側で合成しなければならないことが多いswfmill-0.3.0(swf<->xml)すべてのSWF素材をXML形式で保管しているSWF合成は処理が重いのでキャッシュを有効に使っている（なるべく合成を行わない）クライアント側でSWFバイナリの変数を書き換えることでSWF合成を極力行わないようにする

サーバの管理と監視

サーバセットアップ：Puppetサーバ監視：Xymon(Hobbit)パフォーマンス監視：muninサービス自動復旧：daemontools, mon

開発管理

バグ＆タスク管理：Redmineバージョン管理：Subversion, Mercurial

おまけ

宣伝

新アプリをリリースしました！お金持ちさん for mixi (2010年10月29日)

上記以外のアプリも鋭意制作中

エンジニア募集中！

・ソーシャルアプリを一緒に開発・運営してくれるエンジニアを募集中・特にサーバエンジニアは大歓迎

興味がある方は

info＠geishatokyo.com

にメールしてください！！