1. モバイルゲームにおける
AWSの泥臭い使い方
～大規模トラフィックとの戦いに勝つためにしたこと～

2. 自己紹介
中田 淳平（なかだ じゅんぺい）
株式会社Razest CTO
AWS歴：3年ほど
好きなＡＷＳサービス：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回くらい
○ 実際にはサーバは動いている
○ 日本～シドニー間の回線の問題？