Your SlideShare is downloading. ×
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
モバイルゲームにおけるAWSの泥臭い使い方
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の泥臭い使い方

18,737

Published on

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

No Downloads
Views
Total Views
18,737
On Slideshare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
94
Comments
0
Likes
70
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. モバイルゲームにおける AWSの泥臭い使い方 ~大規模トラフィックとの戦いに勝つためにしたこと~
  • 2. 自己紹介 中田 淳平(なかだ じゅんぺい) 株式会社Razest CTO AWS歴:3年ほど 好きなAWSサービス:RDS PHP / MySQL / Flash
  • 3. Razest ● 2006年から携帯向け対戦カードゲームを運営 ○ とあるブームの始祖 ○ 2006年はAWSがサービスを開始した年 ● AWSは2011年4月から利用 ○ 東京リージョンができてから ○ 利用期間は2年半くらい ● インフラエンジニア:0人
  • 4. 続きはWebで razest 検索
  • 5. 今日お話しすること ● ● ● ● webサーバ(静的コンテンツ) webサーバ(動的コンテンツ) データベース 監視 このあたりの使い方に関する話 すごくフツーの話です
  • 6. AWSの利用形態
  • 7. webサーバ(静的コンテンツ) ● 静的コンテンツ ○ 画像 ○ CSS、JavaScript → Amazon S3で配信
  • 8. 静的コンテンツをAmazon S3で ● パブリックに公開したS3上のファイルはhttpで 取得できる ○ EC2上でwebサーバで公開しているのと変わらない ● コスト安い ○ S3→インターネットの転送料金とファイル容量料金 ○ EC2上でApache/Nginxで配信するのに比べて、EC2イ ンスタンスのコスト分お得
  • 9. 静的コンテンツをAmazon S3で ● トラフィックがある程度かかっても、スケールして 捌いてくれる(らしい) ○ 転送量以上の追加料金とかは取られない ● ファイルの更新もアップロードするだけと手軽
  • 10. 静的コンテンツをAmazon S3で ● CloudFront(CDN)は使わないの? → 使っていない 更新の時のキャッシュ制御が面倒 国内向けだけなら、S3で困らない
  • 11. 動的なコンテンツの静的コンテンツ化 ● 画像合成 ○ ガラケーのゲームでは多様していた ○ 理論上の組み合わせが数万通り以下なら、全パターン の画像を作ってS3においてしまう ○ ファイル名を組み合わせを表現する命名規約にしてアク セス ○ 通常のwebサーバでは容量的に不可能なことでもS3な らやってくれる!
  • 12. webサーバ(動的コンテンツ) ● 動的コンテンツ ○ PHP(HTML) ○ JSON ○ 画像合成 → Amazon EC2 / ELB
  • 13. Amazon EC2 / ELB ● 数を並べて解決できる戦略に落とし込む ○ c1.medium ■ 1台当たりの性能上げても処理できるトラフィックはリ ニアに伸びない、C10k問題とか怖い ■ 数さえ揃えてしまえばApacheもNginxも関係ない ■ ロードアベレージ0.2未満くらい ○ コンテンツの作りはシンプルに ■ $_SESSIONとか使わない ■ サーバローカルに情報を保存しない
  • 14. 数でおせるwebサーバのスケール ● トラフィックに合わせてのwebサーバのスケール こんなやつ 「はじめてのAmazon Web Services」より http://www.slideshare.net/kentamagawa/amazon-web-services7711671
  • 15. 数でおせるwebサーバのスケール ● AutoScaling → 使っていない ● 1日でユーザーが倍にでも増えない限りゲーム のトラフィックは予測可能 ○ 夕方~夜にかけてピーク。深夜~早朝は低い等 ○ イベントの開始のタイミング
  • 16. なぜAutoScalingを使わないか ● AutoScalingは、CloudWatchに指定されたメト リックスのしきい値を見てサーバを増減させる仕 組み ○ CPU使用率がXX%を超えたらサーバを増やす ○ サーバが起動するまで数分かかる ○ 負荷の立ち上がりがピークの場合、対応できない ○ AutoScalingは保険的な位置付けの機能
  • 17. AutoScalingに頼らないスケール ● AutoManualScaling ○ AWS APIを使ってEC2インスタンスをstartするスクリプ トをcronで指定時刻に実行 ○ サーバ起動時にrsyncで最新コンテンツをダウンロード ○ rsync成功後に自分自身をELBに追加するAPIを実行 ○ cronにより指定時刻にEC2インスタンスをstopでする ※AWS OpsWorkのtime-baseでも同じようなことができるようになった
  • 18. ManualScaling ● EC2インスタンスをSTOPで置いておける ○ いざとなったらマネージメントコンソールからStartですぐ に起動できる ○ rsyncでの差分同期も1日分なので速い ● コスト予測が立てやすい ○ 時間毎の起動台数を予測・把握しやすい ● 予測不能なトラフィックには対応できない ○ 普段から余裕は持たせておく
  • 19. データベース ● RDS-MySQL ● memcached(EC2)
  • 20. RDS ● レプリケーション(ReadReplica)は使っていな い ● 垂直分割で書き込み分散 ● パラメータ調整よりインスタンスサイズアップ
  • 21. レプリケーションは使っていない ● MySQLレプリケーション機能は非同期 ● マスターへの書き込みが、スレーブに反映され ていることが保証されない(特に高負荷時!) ● スレーブからの参照は厳密には信用できない ● 結局、マスターから参照することに・・・
  • 22. マスターDBで頑張る ● レプリケーションを使って参照サーバを増やすこ とを辞めて、参照も全力でマスターDBへ ● 参照頻度が高い情報はmemcachedへ ○ マスタ情報テーブル ○ ランキング情報 ○ チームBBS
  • 23. マスターDBで頑張る ● RDSも普通のMySQLなので、いろいろなテク ニックはそのまま使える ○ ランダム→シーケンシャルアクセスへの帰着 ○ カバーリングインデックス ○ force index構文によるヒント ○ なるべく小さなデータ型、少ないインデックス ○ memcachedの利用 →書き込み以外は何とかなる
  • 24. 垂直分割で書き込み分散 ● テーブル単位でRDSインスタンスを分ける ○ ボトルネックになっている書き込みを分散させる ○ 垂直分割できるようにJOINは最初から使わない ○ 最初からある程度意識して設計しておけば、あとから垂 直分割を増やすことは難しくない ○ 水平分割はランキング集計とかで困るので使ってない
  • 25. パラメータ調整よりインスタンスサイズアップ ● RDSの初期パラメータは、けっこう優秀 ○ 頑張っていじっても10%くらいしか変わらない ● インスタンスサイズアップ ○ マウスクリックで出来るYO! ○ AWSサイコー ○ 優秀なDBA雇うよりも安い ■ m2.4xlarge マルチAZ 35万円/月 ● お金で解決できるのもクラウドの良いところ
  • 26. 監視 ● 監視 ○ zabbix (シドニーリージョン) ○ CloudWatch
  • 27. 監視 ● データの保存&アラートはzabbixに一本化 ● CloudWatchのメトリックスをAPIで取得して zabbixに取り込む ○ ELB ■ トラフィック ■ HTTP5XXカウント ○ RDS ■ CPU使用率
  • 28. 監視 ● CloudWatchで取れないデータはzabbixエー ジェント ○ EC2 ■ LoadAvarage ○ RDS ■ SHOW INNODB STATUS ● LSN 、checkpoint、wait中のトランザクション、rollback数
  • 29. 監視 ● CloudWatchは2週間しかデータ保存されない ● 長期保存はzabbixへ ● シドニーから監視してると、たまに全zabbixエー ジェントが誤検知でアラート上げまくる ○ 3か月に1回くらい ○ 実際にはサーバは動いている ○ 日本~シドニー間の回線の問題?

×