Share
Embed
Slide 1
Slide 1 text
スマホゲームサーバの
しくみをしってみよう
Takuma Kajikawa
2018/10/29 サポーターズ CoLab
Slide 2
Slide 2 text
梶川琢⾺
Takuma Kajikawa
- 2016卒
- モバイルゲーム開発会社
- サーバーエンジニア 3年⽬
Slide 3
Slide 3 text
過去の発表
- MySQLの基礎
- DBテーブル設計入門
- オンラインゲームのしくみをしってみよう
Slide 4
Slide 4 text
もくじ
- スマホゲームの特徴
- システム構成例と通信の流れ
- ゲームの開発・運用で気をつけるべきこと
Slide 5
Slide 5 text
スマホゲームの特徴
Slide 6
Slide 6 text
スマホゲームのゲームサイクル
- キャラ育成 → バトル/クエスト → キャラ育成 →..
- シングル + マルチプレイモード
- マルチプレイではよりリアルタイム性が求められる
Slide 7
Slide 7 text
課金モデル
- 無料 + アプリ内課金
- ガチャ、スタミナ回復、時短など
- 高可用性が求められる
- ガチャが引きたい時に引けない…
- せっかく時短したのにサーバー障害…
Slide 8
Slide 8 text
スマホゲームサーバの特徴
- 大量のアクセス
- データ更新頻度が高い
- ピーク時と平常時に求められる性能の差が大きい
- メンテナンスをなるべくしない
- 頻繁にコンテンツや機能の追加
Slide 9
Slide 9 text
データの特徴
- ユーザデータ
- ユーザのレベルや所持アイテム、所持金など
- マスタデータ
- ゲームのステージやキャラなどの運営が管理するデータ
- ログデータ
- KPI分析や障害調査
Slide 10
Slide 10 text
システム構成・処理の流れ
Slide 11
Slide 11 text
ゲームモードで変わるシステム構成
- アウトゲーム
- キャラ育成、ガチャ、バトル開始、終了など
- HTTP(S)通信
- Webアプリの構成に近い
Slide 12
Slide 12 text
ゲームモードで変わるシステム構成
- インゲーム(マルチプレイ)
- バトル中の味方や敵の位置、攻撃、チャットなど
- WebSocketやP2Pなどの双方向通信
Slide 13
Slide 13 text
API
サーバー
DB
サーバー
KVS
サーバー
Log
サーバー
LB
アウトゲームのサーバー構成
CDN Asset
サーバー
Slide 14
Slide 14 text
APIサーバ
- リクエスト先はロードバランサによって決まる
- 一般的なWebアプリのAPIと同じ構成
- Apache/Nginx
- PHP/Java/Go など
Slide 15
Slide 15 text
APIサーバ
- スケールアウト・スケールインを柔軟に
- ピーク時と平常時に求められる性能の差が大きい
- 機能ごとに分割したサーバーを用意することもある
- 課金、認証、マッチングなど
- 特定の機能に特化することで、開発に専念
Slide 16
Slide 16 text
データストア
- DB (MySQLやPostgreSQLなど)
- 永続化データ
- KVS (RedisやMemcachedなど)
- キャッシュ、アクセス頻度が高く消えても問題ない
- ログ(BigQueryなど)
- 分析用のデータ
Slide 17
Slide 17 text
アセットサーバー
- 静的ファイルの配信用のサーバー
- 画像や音楽、3Dモデルなど
- CDNでキャッシュさせる
- 新バージョンだったらクライアントがリクエストする
Slide 18
Slide 18 text
アウトゲームの処理の流れ
- 画面遷移時やデータ更新時にサーバーにリクエスト
- サーバーがDBやKVSのデータを取得、更新
- 一度のリクエストでデータの追加や更新、取得
- リクエストメソッドの使い分けはほぼGETかPOST
- × RESTful API
Slide 19
Slide 19 text
アセット取得の流れ
- アセットの種別ごとにバージョンを管理するDBを用意
- 新しいアセットをデプロイしたらDBのバージョンを上げる
- クライアントがアセットのバージョンを確認するリクエスト
をする
- サーバーはDBのバージョンを返す
- クライアントで保持しているバージョンと違うアセットがあっ
たらそのアセットをダウンロード
Slide 20
Slide 20 text
インゲーム (C/S方式)
Battle
サーバー
DB
サーバー
KVS
サーバー
Log
サーバー
Slide 21
Slide 21 text
Battleサーバー
- 接続先はバトル開始前にAPIサーバーで割り振られる
- リアルタイム性が求められる
- WebSocketやリアルタイムゲームエンジン
- C++/Node.js/Go など
- サーバー集中型とクライアント分散型
- ゲームによって特色がある
Slide 22
Slide 22 text
サーバー集中型
- サーバー側でゲームロジックや進行を行う
- バトル中サーバー側で必要なデータを保持しておく
- 端末間でズレるとまずい処理
- 対戦ゲームでのキャラの位置や当たり判定
- 協力バトルのボスの位置やHP
- サーバーの判定処理を待つ必要がある
Slide 23
Slide 23 text
クライアント分散型
- それぞれの端末でゲームの進行を行う
- ゲーム進行上、端末間のズレが気にならない場合
- 協力バトルの雑魚敵の位置はズレても気にならない
- 不正対策はしづらい
- 擬似的なP2P、パケットのブロードキャストに専念する
Slide 24
Slide 24 text
インゲームの処理
パーティを組んで戦うアクションバトルの例
1. パーティ作成 or 参加
2. ルーム(バトル空間)を作成、バトル開始
3. ルーム内でバトル
4. バトル終了、ルーム削除、パーティ解散
Slide 25
Slide 25 text
ルーム入場からバトル開始まで
1. CL → API: パーティ参加リクエスト
2. API → DB: パーティがあるか確認、なければ作成
3. API → CL: Battleサーバーの接続先を返す
4. CL → Battle: ルーム作成リクエスト
5. CL → API: Battle開始
Slide 26
Slide 26 text
バトル中
1. CL → Battle: コマンドを送信
2. Battle → CL: バトル情報を返す
3. Battle → CL: イベント発生を通知
Slide 27
Slide 27 text
バトル終了
1. CL → Battle: バトル終了リクエスト
2. Battle → CL: ルームを削除し、切断
3. CL → API: リザルトのリクエスト
4. CL → API: パーティを解散
Slide 28
Slide 28 text
その他、運営に必要なシステム
- レポジトリサーバー、デプロイサーバー
- ソースコードやアセットの管理、デプロイに使う
- 運営やカスタマーサポート用の管理ツール
- データの確認、お知らせやバナーの反映、補填など
- KPI基盤
- ログデータの分析や可視化、社内共通
Slide 29
Slide 29 text
運用・開発で
気をつけるべきこと
Slide 30
Slide 30 text
DBの負荷を考慮しよう
- DBが負荷のボトルネックになりがち
- オンラインでスキーマの変更がし辛い
- インデックスやDBのパーティショニング
- 集計データはバッチ処理して、キャッシュさせる
- なるべく少ないクエリ数でデータを取得
Slide 31
Slide 31 text
DBの負荷分散
- 水平分割
- ユーザのIDごとにDBサーバを振り分ける
- 期間限定のDBを日付でパーティショニング
- Master/Slave構成
- マネージドサービスを使うのもあり
Slide 32
Slide 32 text
オンラインメンテ
- DBのデータ設計を変えたときや定期メンテをオンライン
でやりたい
- Master DBがネック
- Master/Slave切り替え
- Percona Tool Kit Online Schema
Change（MySQL）
- マネージドサービスを使うのもあり
Slide 33
Slide 33 text
リリース後のアラート監視
- サーバーが止まる前に対処する
- 各種サーバーのエラー、CPU使用率、リクエスト数
- DBサーバーのクエリ数
- レスポンスタイム
- Disk write、使用量
- お客様の問い合わせ、Twitterでエゴサ
Slide 34
Slide 34 text
ゲーム運用で便利なツールを作る
- データ管理のしくみを作ろう
- ExcelやスプレッドシートからSQLへの変換
- デバッグ機能や管理ツールを作ろう
- 開発スピードが格段に上がる
- 管理ツールの権限管理は重要
Slide 35
Slide 35 text
まとめ
Slide 36
Slide 36 text
まとめ
- ゲームのシステム構成は基本的にはWebアプリと一緒
- アクセス数や更新頻度が高くなる傾向
- リアルタイム性の求められるシステム構成はゲームによっ
て異なる
- 高い可用性を保つためにオンラインメンテ、アラート監
視などの工夫が必要
Slide 37
Slide 37 text
ご清聴ありがとうございました！