モバイルゲームにおけるAWSの泥臭い使い方
- 2. 自己紹介 中田 淳平（なかだ じゅんぺい） 株式会社Razest CTO AWS歴：3年ほど 好きなＡＷＳサービス：RDS PHP / MySQL / Flash
- 3. Razest ● 2006年から携帯向け対戦カードゲームを運営 ○ とあるブームの始祖 ○ 2006年はAWSがサービスを開始した年 ● AWSは2011年4月から利用 ○ 東京リージョンができてから ○ 利用期間は2年半くらい ● インフラエンジニア：0人
- 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日分なので速い ● コスト予測が立てやすい ○ 時間毎の起動台数を予測・把握しやすい ● 予測不能なトラフィックには対応できない ○ 普段から余裕は持たせておく
- 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回くらい ○ 実際にはサーバは動いている ○ 日本～シドニー間の回線の問題？