DynamoDBだけでソシャゲを作ってみた
- 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つほど全部関わる
- 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 – バトルイベントのランキング集計等に使用 – 定期的に統計情報抽出タスクを実行 – メンテ時にフルバックアップタスクを実行
- 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は死ね る – メンテ時間が長くなると公式コミュが荒ぶる
- 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. なんか質問ある？