第21回 AWS User Group - Japan 東京勉強会 - Startup CTO AWS Battle http://jawsug-tokyo.doorkeeper.jp/events/11269

1. 2014/05/20 JAWS UG
田中 勇輔

2. 田中 勇輔 @csouls, @yusuket
• 株式会社アカツキ
• CTOではない
• 責任者…？責任感は強い方です！

3. アカツキ
• ソーシャルゲーム出しています
• ブラウザゲームは、Ruby on Rails
• ネイティブゲームは、C++ と Ruby on Rails

4. インフラ
構成
VPC
ELB
EC2
RDS
ElastiCache
CloudFront
S3

5. 構築
• CloudFormation + Chef + Capistrano
• CloudFormation template
• https://gist.github.com/yusuket/
40e2ec7811cf1cd3d703
( yusuket の public gist )

6. デプロイ

7. デプロイ
• 管理用(踏み台)サーバ[Public zone]からWeb
サーバ群[Private zone]に対してCapistranoを
実行

8. デプロイ
• デプロイ内容をどうやって決めているか？
• 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/

9. デプロイ
• デプロイ先をどうやって決めているか？
• AWSのタグ
• Webサーバの数は変動するので、プログラ
ムで判断する為には、インスタンスの
「役割」を明確にする必要がある
※Capistranoでの実装: http://hackerslab.aktsk.jp/technology/2014-04-29-faster-deploy/

10. デプロイ
• データの更新も同時に実施
• Assets on Cloud パターン (静的コンテンツ)
• Rails だと、asset_sync Gem を使うと簡単
※ http://d.hatena.ne.jp/lettas0726/20130320/1363773153

11. デプロイ
• クライアントが予めダウンロードしておく
画像やサウンドデータの更新
• 仕組みは、S3のデータとレポジトリの差分を
毎回アップロード
• 毎回S3のデータをダウンロードするのは遅い
ので、S3上にFilepath + MD5のリストを作っ
ておいて、そのリストとレポジトリを比較

12. リスト取得
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
が素晴らしい

13. RDSの話

14. RDS
• 2014/4 全国TV-CM開始！
• RDS Master DB Instance type は既に
db.cr1.8xlarge (最大サイズ)
• CPU使用率は30%弱
• ユーザ数は最大3~4倍を想定。普通に考えてCPUリ
ソースが枯渇する

15. 立ち止まれない運用

16. 迫り来るCM

17. どうしたか？

18. RDS
• 全データベース の
innodb_flush_log_at_trx_commit を 0 に、
sync_binlogを 0 に

19. どういうことか？

20. RDS
• Commit 時の REDO ログと binlog の fsync() を
止める
• srv_sync_log_buffer_in_background() によっ
て、1秒置きにログは fsync() されている
• 障害時に最大1秒間のデータが消失する可能性
がある！(Master DB では普通やらない)

21. RDS
1. ユーザが来ないよう祈る
2. アプリケーションと構成を変える
(DynamoDB導入、Shading 等）
→ 3. 最大1秒のデータ消失を許容する

22. RDS
• 結果、CPU使用率は 5% 程度に
• WriteIOPSも少し下がった
• TV-CM乗り切った
• パラメータは戻す予定。余程のことが無い限
り、参考にしない方が良いと思います

23. 監視

24. CloudWatchのアラートをChatに流すのが良い

25. 監視
• Pull型のメールと違い、すぐに気付ける
• 「この辺がやばそう」「自分はここを調べる」
という会話が同じコンテクストの中ですぐに
出来る

26. 監視
• https://github.com/blackline/amazon-
cloudwatch-to-hipchat を使ってます

27. 他にも苦労や工夫の話はたく
さんあるのですが、今日はこ
れくらいが限界です

28. ありがとうございました！
5分は短い…