2012-06-05 JAWS-UG 発表資料

1. DynamoDBだけで
ソシャゲをつくってみた
2012-06-05 JAWS-UG
株式会社マイネット・ジャパン
伊藤 祐策

2. 自己紹介等
• 伊藤 祐策 Ito Yusaku
– 1982年生まれ(満30歳)
– Birth on 1982 (30 years old)
– 釧路高専情報工学科卒
– Kushiro National College of Technology / Information Eng
– 電気通信大学システム工学科卒
– The University of Electro-Communications / Systems Eng
– 2006年10月 マイネット・ジャパン入社
– Joined to Mynet Japan Inc Oct 2006.

3. 会社紹介
• 株式会社マイネット・ジャパン
– 「どこでもドアの実現」が企業理念な会社
• マイネット・ジャパンの関わり
– 創業後すぐにジョインして5年半
– 自社サービスをかれこれ6つほど全部関わる

4. システム構成紹介
System configuration

5. システム構成
img.falkyrie.jp (sp|mb).falkyrie.jp
Elastic Load
Cloud Front DynamoDB
Balancer
S3
PHP
Image Files
Application Servers
Memcache Servers

6. 各種サーバーの詳細
• アプリケーションサーバー
– PHP 5.3.10
– インスタンスごとのスマフォ/ガラケーの区別
無し
• Memcacheサーバー
– Memcached/LibKetamaでConsistentHashing
– VPC上に構築した都合上、ElastiCacheが使用不
可

7. その他のサーバー達
• バッチサーバー
– PHP 5.3.10
– 主な仕事はキューの処理
– EMRの制御も行なっている
• EMR
– バトルイベントのランキング集計等に使用
– 定期的に統計情報抽出タスクを実行
– メンテ時にフルバックアップタスクを実行

8. 開発エピソード
Episode of developments

9. 厳しい現実
• ソシャゲ開発自体そもそも初めてだった。
– せいぜいFacebookアプリを作った程度
– ユーザー10万人を超えるサービスも未経験
• クラウド運用の実績なんかなかった。
– 今まではiDCにラック借りて自前運用の日々
– 使いたいとは思っていたけど移行とか大変
– トライアルで色々使ってみたけどどれも微妙

10. 当初の予定
• ストレージはMySQLで実装するつもり
だった。
– 商用サービスにNoSQLを採用した実績ナシ
– 社内にNoSQL経験者は誰もいなかった
• AWSなんかそもそも使う予定がなかった。
– なんか難しそうだった
– でもトラブル対応の度にiDC行くのももう嫌
だった
– クラウドならなんでもよかった。
– 旅行へ行きたい。というか実家帰りたい。

11. ワイルドな選択
• 3月13日、MySQLからDynamoDBへの乗り換
えを決断し、実装を開始。
– リリース71日前の話。
– 決め手は「運用が楽ですよ！」の一言
– テーブル設計は直感を頼りに作り直し。
• ソースコードを半分くらい捨てた
– 捨てたのは自分が作った分だけ
– 他メンバーが作った部分はほぼ全てそのまま
利用した

12. ワイルドな時系列
Start Transit Release
71 days
Jan Feb Mar Apr May Jun
DynamoDB DynamoDB
US East Region Tokyo Region
Released Released

13. 本当にDynamoDBだけで作れるのか？
Is it possible to implement them only DynamoDB?

14. DynamoDBにできないこと
• トランザクション
– START TRANSACTION ... COMMIT / ROLLBACK
• テーブルJOIN
– SELECT * FROM table1 LEFT OUTER JOIN table2 ...
• 一貫性のあるフルバックアップ
– mysqldump
• 自由な条件での検索
– SELECT * FROM table WHERE x=1 AND y=2

15. 本当にDynamoDBだけでできるの？
• トランザクションなんて甘え
– 無くてもなんとかなる！
• テーブルJOINも甘え
– JOINなんて使ってたらスケールしませんよね
• フルバックアップも甘え
– そのバックアップからリストアするつもりあ
るの？
• 自由な条件での検索は...
– ここをどう解決するかは腕の見せ所

16. 本当にDynamoDBだけでできるの？
• そもそもソシャゲは殆どの処理において
ユーザーIDが決定しているので、KVSとの
相性は非常に良い。
– 1回のリクエストで参照するのは、自分のデー
タだけか、自分と誰か1人のデータのみ。
– キーをユーザーIDにすればKVSと相性抜群
– KVS型ならスケールもしやすい

17. 本当にDynamoDBだけでできるの？
• ソシャゲは頻繁に仕様変更や拡張をする
のでNoSQLとの相性も非常に良い。
– アップデートは基本「毎週」
– さもないとユーザーが飽きて過疎る
– データ量が増えてきた時にALTER TABLEは死ね
る
– メンテ時間が長くなると公式コミュが荒ぶる

18. 代替実装
The alternative implementations

19. DynamoDBにもできること
• 条件付きアップデート
– UPDATE x=1 if x=0
– 楽観ロックでは必須の機能
– 条件式部分は等式(A is B)のみ指定可
• インクリメント/デクリメント
– UPDATE x+=10
– 更新前、更新後の値もそれぞれ取得可能

20. トランザクションの代替実装
• Re-Runnable設計にする
– 2回実行されても大丈夫なように作る
• 条件付きアップデートを駆使する
• 更新済みなら処理がスキップされるように作る
– 途中で失敗したら最初からやりなおす
• Re-Runnableでさえあれば何度実行しても大丈夫
• SQSを使って完遂保証をすると完璧！

21. トランザクションの代替実装
• 基本5フェーズを意識しよう
– 入力エラーチェック
– 書込み開始処理
– 書込み処理
– 書込み終了処理
– 出力処理
※後戻りはしない。フェーズを混在させない。

22. 条件検索の代替実装
• レンジキー(Range Key)というものがある
– ハッシュキー＋レンジキーで主キーになる
– 開始点＋検索方向(asc/desc)で検索ができる
– 先頭/末尾からという検索も可能
– 検索件数制限指定は必須
• レンジキーに指定した属性であれば検索
は可能
– 但しページングは無理（全体件数が分からな
い）

23. 条件検索の代替実装
• Amazon EMR連携でインデックスを作る
– 全部のデータを読み取るので若干非効率
– 古くなったデータの掃除が面倒
• SQSでリアルタイム更新インデックスを作
る
– 実装は面倒だけど現実的な手段
• Amazon Cloud Searchという選択肢
– 東京リージョンでは未登場（早く！）

24. バックアップの代替実装
• Amazon EMR連携でS3へエクスポート
– HELPの通りやれば簡単に出来る
– 但し一貫性を保つにはメンテが必須
• ソシャゲの場合リストアという選択肢は
無い
– データのリストアはできないと諦めた上で、
新たに戦略を立て直す
– 戦略上意味のないことはやらない

25. Q.苦労した末に何を得られるのか？
Qestion : What can we get?

26. 答えは2つ
There are 2 answers.

27. A1.無制限にスケールするストレージ
Answer#1 : The indefinitely scalable storage.

28. A2.安心して旅行へ行ける権利
Answer#2 : The long vacation with peace of mind.

29. その他紹介しきれなかったこと
• 具体的なRe-Runnable設計の実装方法
• リリース後に発生した数々のトラブル
– そしてそれらの対処方法等
• 監視すべきサーバー性能指標
– DynamoDB特有の問題があったりなかったり
• 利用料金チューニング
– Read/Writeそれぞれに対するチューニング手
法

30. なんか質問ある？