1. 300万人が遊ぶソーシャルアプリ
「おみせやさん」の作り方
芸者東京エンターテインメント株式会社
山内 雅浩

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

3. おみせやさんの紹介

4. 芸者東京エンターテインメント株式会社
2006年10月起業
現在は主にソーシャルアプリを開発
主な自社製品
2007年「それは無理だよ！オオスガさん」
2008年「電脳フィギュア ARis」「アニメ さくらんBOY DT」
2009年「おみせやさん for mixi」
2010年「おみせやさん for GREE」
2010年「お金持ちさん for mixi」 NEW!
http://www.geishatokyo.com/

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

6. おみせやさん for GREE
2010年6月末から提供
開発言語：Scala
WEBフレームワーク：Lift
ストレージ：Cassandra, MySQL, memcached,
Webサーバ：nginx
アプリサーバ：Tomcat
OS：Debian GNU/Linux
国内DCホスティングで数十台運用
ユーザーのデータはCassandraに保存。
MySQLは、リソースデータと課金に関するデータを保存している。

7. おみせやさん for GREE 構成

8. おみせやさん for mixi
2009年9月末から提供
開発言語：Java
WEBフレームワーク：Wicket
ストレージ：MySQL, memcached, Tokyo Tyrant
Webサーバ：nginx
アプリサーバ：Tomcat
OS：Debian GNU/Linux
国内DCハウジングで数十台運用

9. おみせやさん for mixi 構成

10. 負荷対策

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

12. 水平分割と垂直分割
水平分割: 同じ機能を持ったDBをIDなどを元に複数台に分割する
垂直分割: 異なる機能を持ったDBをその機能やアクセス頻度にした
がって分割する。例えば正規化も垂直分割の1つ。

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

14. 水平分割 の特性
メリット：
1つのDBにデータをまとめる
場合と比べてアクセスが分
散する
分割しただけ1つのDBあた
りのデータ量が減る
デメリット：
再分割・結合するのが容易
ではない
他のユーザデータを参照す
るような処理では複数のDB
にアクセスする必要がある

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

16. KVSの利用
RDB(Relational Data Base)に比べて読込、更新処理が高速なKVS
(Key Value Store)を使うことでより多くのリクエストを処理できるように
なる。
弊社で使っているKVS
memcached
Cassandra
Tokyo Tyrant

17. memcached
1つのKeyに1つのValueを持つだけのシンプルなKVS
メリット：
読み込み・書き込みともに高速
各種言語へのインターフェースが豊富に存在
デメリット：
データの永続性がない
複雑なデータ構造を持たせるのが面倒

18. Cassandra
KVSの1つで複数台で運用されることを想定して作られたシステム
メリット：
単一障害点がない。
クラスタリングしてくれるので、スケールアウトが容易。逆に縮退す
るのも楽。
クライアント側でのshardingが不要なのでプログラマに優しい。
列指向データベースなので、(単純なKVSよりは)データを構造化
しやすい。
スキーマレスなのでデータ構造を変更しやすい。
デメリット：
データの一貫性が低い。
Indexがないので、データ解析がやりにくい(0.6.x)
※Indexは0.7.xから使えるようになるらしい

19. Cassandraのデータ構造

20. Cassandraのデータの具体例
KeySpace
ColumnFami
ly
Key Column Value
"PlayShop" "User" 11009 "nickname" Enock
"point" 666
"lastAccess" 2010-11-02
"level" 5
KeySpace
ColumnFami
ly
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 - 持っている商品の素

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

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

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

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

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

26. JVM GC グラフの比較
悪い例 良い例

27. 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

28. 開発と運用

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

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

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

32. おまけ

33. 宣伝
新アプリをリリースしました！
お金持ちさん for mixi (2010年10月29日)
上記以外のアプリも鋭意制作中

34. エンジニア募集中！
・ソーシャルアプリを一緒に開発・運営してくれるエンジニアを募集中
・特にサーバエンジニアは大歓迎
興味がある方は
info＠geishatokyo.com
にメールしてください！！