• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
モバイルゲームにおけるAWSの泥臭い使い方
 

モバイルゲームにおけるAWSの泥臭い使い方

on

  • 20,376 views

 

Statistics

Views

Total Views
20,376
Views on SlideShare
19,926
Embed Views
450

Actions

Likes
68
Downloads
87
Comments
0

12 Embeds 450

http://blog.serverworks.co.jp 298
https://twitter.com 99
http://s.deeeki.com 26
http://tweetedtimes.com 9
http://openlink.to 5
http://nuevospowerpoints.blogspot.com.es 4
https://www.chatwork.com 3
http://nuevospowerpoints.blogspot.com 2
http://cloud.feedly.com 1
http://b.hatena.ne.jp 1
https://kcw.kddi.ne.jp 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    モバイルゲームにおけるAWSの泥臭い使い方 モバイルゲームにおけるAWSの泥臭い使い方 Presentation Transcript

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