2014/05/20 JAWS UG
田中 勇輔
田中 勇輔 @csouls, @yusuket
• 株式会社アカツキ
• CTOではない
• 責任者…?責任感は強い方です!
アカツキ
• ソーシャルゲーム出しています
• ブラウザゲームは、Ruby on Rails
• ネイティブゲームは、C++ と Ruby on Rails
インフラ
構成
VPC
ELB
EC2
RDS
ElastiCache
CloudFront
S3
構築
• CloudFormation + Chef + Capistrano
• CloudFormation template
• https://gist.github.com/yusuket/
40e2ec7811cf1cd3d703

( yusuket の public gist )
デプロイ
デプロイ
• 管理用(踏み台)サーバ[Public zone]からWeb
サーバ群[Private zone]に対してCapistranoを
実行
デプロイ
• デプロイ内容をどうやって決めているか?
• Gitのタグ
# 検証が終わった環境から、本番用の production/yyyymmddhhmmss タグを作る	
git tag production/yyyymmddhhmmss	
!
# git tag 結果は文字列の昇順にソートされているので、

# 最後に表示される production タグをもとにデプロイする	
git tag | grep "^production" | last
※Capistranoでの実装: http://hackerslab.aktsk.jp/technology/2014-04-29-faster-deploy/
デプロイ
• デプロイ先をどうやって決めているか?
• AWSのタグ
• Webサーバの数は変動するので、プログラ
ムで判断する為には、インスタンスの

「役割」を明確にする必要がある
※Capistranoでの実装: http://hackerslab.aktsk.jp/technology/2014-04-29-faster-deploy/
デプロイ
• データの更新も同時に実施
• Assets on Cloud パターン (静的コンテンツ)
• Rails だと、asset_sync Gem を使うと簡単
※ http://d.hatena.ne.jp/lettas0726/20130320/1363773153
デプロイ
• クライアントが予めダウンロードしておく

画像やサウンドデータの更新
• 仕組みは、S3のデータとレポジトリの差分を
毎回アップロード
• 毎回S3のデータをダウンロードするのは遅い
ので、S3上にFilepath + MD5のリストを作っ
ておいて、そのリストとレポジトリを比較
リスト取得
def s3_md5_list(bucket, platform)	
obj = bucket.objects.with_prefix("#{platform}/
md5_list/").sort_by{|o| o.last_modified}[-1]	
return [] if obj.nil?	
obj.read.each_line.map do |line|	
line.chomp.split("t")	
end	
end
• 直接S3上のファイルを操作できる AWS-SDK
が素晴らしい
RDSの話
RDS
• 2014/4 全国TV-CM開始!
• RDS Master DB Instance type は既に
db.cr1.8xlarge (最大サイズ)
• CPU使用率は30%弱
• ユーザ数は最大3~4倍を想定。普通に考えてCPUリ
ソースが枯渇する
立ち止まれない運用
迫り来るCM
どうしたか?
RDS
• 全データベース の
innodb_flush_log_at_trx_commit を 0 に、
sync_binlogを 0 に
どういうことか?
RDS
• Commit 時の REDO ログと binlog の fsync() を
止める
• srv_sync_log_buffer_in_background() によっ
て、1秒置きにログは fsync() されている
• 障害時に最大1秒間のデータが消失する可能性
がある!(Master DB では普通やらない)
RDS
 1. ユーザが来ないよう祈る
 2. アプリケーションと構成を変える
(DynamoDB導入、Shading 等)
→ 3. 最大1秒のデータ消失を許容する
RDS
• 結果、CPU使用率は 5% 程度に
• WriteIOPSも少し下がった
• TV-CM乗り切った
• パラメータは戻す予定。余程のことが無い限
り、参考にしない方が良いと思います
監視
CloudWatchのアラートをChatに流すのが良い
監視
• Pull型のメールと違い、すぐに気付ける
• 「この辺がやばそう」「自分はここを調べる」
という会話が同じコンテクストの中ですぐに
出来る
監視
• https://github.com/blackline/amazon-
cloudwatch-to-hipchat を使ってます
他にも苦労や工夫の話はたく
さんあるのですが、今日はこ
れくらいが限界です
ありがとうございました!

5分は短い…

アカツキはどのようにAWSを活用しているか #jawsug