Your SlideShare is downloading. ×
アカツキはどのようにAWSを活用しているか #jawsug
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

6,736

Published on

第21回 AWS User Group - Japan 東京勉強会 - Startup CTO AWS Battle …

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,736
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
8
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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分は短い…

×