ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか 〜その原因と対策〜 accepted

Abstract

概要

スマートフォン上のソーシャルゲームアプリは開発からリリースするまでに数年を要し、 プロジェクトチームの規模も数十人を超えるようになってきました。

リリース後も定期的なアップデートが重ねられ、多くの自動テストやQAを経てようやくユーザの手元にゲームが届けられます。

このようなサポートにもかかわらず、サーバ障害が起きることは珍しくありません

ここでは想定外のアクセスに見舞われたプロジェクトの実例をもとに、過負荷に至った原因と対策をお話します。

原因と対策

・予測流入数との乖離
 ・予想流入数とベータテストを経てサーバ群を構築
 ・負荷試験を経てMasterDB一台で捌けるであろうとの見込みを立てていた
 ・リリース3週間で想定の数倍以上の流入を観測
 ・DBをMaster-Slave構成に変更しクエリを逃がすなどの対策

・Photonを利用したマルチプレイゲームのルーム管理
 ・ルームの管理にRedisを利用していたが、リリース後数日で壁にぶち当たる
 ・マルチプレイはほとんど遊ばれていなかったが、報酬設計を見直したことで想定以上に使われるようになった
 ・深い考えもなくRedisのkeysを利用していた箇所を即座に修正
 ・PhotonAPIを活用してアクセス数を監視する仕組みを導入

・知らぬ間にアプリに仕込まれていた機能
 ・あるバージョンから重めのAPIが過剰に叩かれている事が判明
 ・既に大規模な広告施策が実施される事が確定している
 ・広告施策前にアプリを修正アップデートする時間はない、さてどうするか?

・ゲームイベント
 ・高難易度イベントの開始時間を境にアクセスが数倍になる
 ・予想外の事態に急遽サーバの台数を増やし、以降はピーク時の最大台数で運用を継続
 ・あまりもアクセスの落差が大きすぎるので最大台数での稼働はコスト的に問題がある
 ・オートスケールを導入しイベントスケジュールと負荷状況に合わせた台数調整を行う

・みんな大好きガチャ
 ・ガチャ施策の開始時間を堺にアクセス数が急増、全く収まる気配が見えない
 ・DBのチューニングで時間を稼ぎつつアプリケーションの修正を行う
 ・行ったアプリケーションの修正も時間稼ぎに過ぎない
 ・ テーブル構造とアプリケーションの設計を見直し根本解決を計る

Video
Slides
Session Information
Confirmed confirmed
Material Level Beginner
Starts On 9/7/18, 4:40 PM
Room Multi-Purpose Room 2
Session Duration Regular Session (60min)
Spoken Language Japanese
Interpretation Unavailable
Slide Language Japanese