DynamoDBだけでソシャゲを作ってみた

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

自己紹介等• 伊藤祐策 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.

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

システム構成紹介System configuration

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

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

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

開発エピソードEpisode of developments

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

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

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

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

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

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

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

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

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

代替実装The alternative implementations

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

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

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

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

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

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

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

答えは2つThere are 2 answers.

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

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

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

なんか質問ある？

http://blog.serverworks.co.jp	794
http://shmachid.com	218
http://ec2-175-41-226-77.ap-northeast-1.compute.amazonaws.com	8
http://tweetedtimes.com	1
https://twimg0-a.akamaihd.net	1
https://si0.twimg.com	1
https://twitter.com	1

DynamoDBだけでソシャゲを作ってみた

by 祐策祐策 on Jun 05, 2012

Accessibility

Upload Details

Usage Rights

7 Embeds 1,024

Statistics