Ripplationという会社の安藤さんと立本さんによるゲーム運営にAWSのマネージドサービスを活用する話です。 最近のゲーム界隈にうといのですが、「騎士とドラゴン」が代表的タイトルですかね。

とことん運用を楽にする側に振り切っているのは清々とします。

Kinesis – ElasticBeansTalk – S3の組み合わせ方がかなり独特で、二段階に処理を分けるというのはとてもおもしろいと思いました

• いかにして最小人数でサーバー側の開発を行うか

• 以下にしてサーバーコストを下げるか

• スケール・耐障害の自動化

• 監視システムも簡単にしたい

なので、ElasticBeansTalk + DynamoDBのみで構成することにした

AWSを使ってみてわかったこと

• すぐ始められる
• アプリをサーバーにデプロイするまでに流れを作るのが簡単
• 1から整える必要がない
• 思った以上に実用に耐えられる
• ほとんど放置が可能: 最近サーバーをコンソールで調整したくらい

ElasticBeansTalkの注意点

• デプロイ時に一瞬アクセスできないことがある: 気にせずデプロイしている。エラー処理はアプリケーション側で行っている
• オートスケーリングの調整はきっちりしておく

DynamoDBの注意点

• 社内にいるDB技術者の文句やいちゃもんに負けない　問題が出たら後付けで
• バッチ処理をしっかり使う、リトライも行う
• スループットの限界値は急激に変化させられない: 急激な書き込みは読み込みはできない
• バックアップするかどうか　リストアする場合ってどんな状況だろうか

汎用化なんて考えたらダメ

• AWSを使い倒さないと真の良さは発揮されない
• そんなにどれでも動く仕組みって重要なんでしょうか。

ログデータの収集・集計

• 結局、最初はDynamoDBだけでなんとかした

KinesisとBigData

ビッグデータとはなにか

単体ではよくわからないデータこそがビッグデータ

達成課題：毎秒10万件のデータを収集する

Linux TCP 28000個ぐらいのポート TIMEWAIT 60sec 実測値への縫製係数: 0.6 1server 282 req/sec

チューニング後：

Linux TCP 64000 Port TIMEWAIT 10sec 1server 4000req/sec

26台あれば　 3870x26=100620req/sec

ただ、これをどうやって集める？ 一般的なサーバーでつくろうとするとdisaster recovery含めて大変

Kinesisならシャードを100個立てれば終了

Grasslandというツールを開発中: データを分析して

GrasslandでのKinesisの使いどころ

1 クライアントからはKinesisにデータを直接投げる 2 ElasticBeansTalkはS3にキャシュを保存 3 S3はcacheの解析リクエストをKinesisに返す 4 Kinesis –> EBT に解析リクエストを投げる 5 S3 –> EBT はキャッシュを返す 6 EBT –> S3 解析結果を渡す

セキュリティを担保できる工夫はいろいろできる

Kinesisは世界のデータを集めるように作られている