Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スマホゲームサーバーのしくみをしってみよう
Search
Takuma Kajikawa
October 29, 2018
Programming
1
14k
スマホゲームサーバーのしくみをしってみよう
Takuma Kajikawa
October 29, 2018
Tweet
Share
More Decks by Takuma Kajikawa
See All by Takuma Kajikawa
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
0
43
Figmaで進化するデザイナーとエンジニアの連携 FoF Tokyo 2024
kajitack
0
13
コードの責務を例外で表現しよう PHPerKaigi2024
kajitack
2
250
オンラインゲームの仕組みをしってみよう
kajitack
4
3k
DBテーブル設計入門
kajitack
0
600
Other Decks in Programming
See All in Programming
Zoneless Testing
rainerhahnekamp
0
120
今からはじめるAndroidアプリ開発 2024 / DevFest 2024
star_zero
0
1k
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
1
440
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
1
370
Symfony Mapper Component
soyuka
2
730
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
930
Fibonacci Function Gallery - Part 1
philipschwarz
PRO
0
210
HTTP compression in PHP and Symfony apps
dunglas
2
1.7k
ソフトウェアの振る舞いに着目し 複雑な要件の開発に立ち向かう
rickyban
0
890
17年周年のWebアプリケーションにTanStack Queryを導入する / Implementing TanStack Query in a 17th Anniversary Web Application
saitolume
0
250
KMP와 kotlinx.rpc로 서버와 클라이언트 동기화
kwakeuijin
0
140
range over funcの使い道と非同期N+1リゾルバーの夢 / about a range over func
mackee
0
110
Featured
See All Featured
Visualization
eitanlees
146
15k
Adopting Sorbet at Scale
ufuk
73
9.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Agile that works and the tools we love
rasmusluckow
328
21k
A better future with KSS
kneath
238
17k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
RailsConf 2023
tenderlove
29
940
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Optimising Largest Contentful Paint
csswizardry
33
3k
Transcript
スマホゲームサーバの しくみをしってみよう Takuma Kajikawa 2018/10/29 サポーターズ CoLab
梶川琢⾺ Takuma Kajikawa - 2016卒 - モバイルゲーム開発会社 - サーバーエンジニア 3年⽬
過去の発表 - MySQLの基礎 - DBテーブル設計入門 - オンラインゲームのしくみをしってみよう
もくじ - スマホゲームの特徴 - システム構成例と通信の流れ - ゲームの開発・運用で気をつけるべきこと
スマホゲームの特徴
スマホゲームのゲームサイクル - キャラ育成 → バトル/クエスト → キャラ育成 →.. - シングル
+ マルチプレイモード - マルチプレイではよりリアルタイム性が求められる
課金モデル - 無料 + アプリ内課金 - ガチャ、スタミナ回復、時短など - 高可用性が求められる -
ガチャが引きたい時に引けない… - せっかく時短したのにサーバー障害…
スマホゲームサーバの特徴 - 大量のアクセス - データ更新頻度が高い - ピーク時と平常時に求められる性能の差が大きい - メンテナンスをなるべくしない -
頻繁にコンテンツや機能の追加
データの特徴 - ユーザデータ - ユーザのレベルや所持アイテム、所持金など - マスタデータ - ゲームのステージやキャラなどの運営が管理するデータ -
ログデータ - KPI分析や障害調査
システム構成・処理の流れ
ゲームモードで変わるシステム構成 - アウトゲーム - キャラ育成、ガチャ、バトル開始、終了など - HTTP(S)通信 - Webアプリの構成に近い
ゲームモードで変わるシステム構成 - インゲーム(マルチプレイ) - バトル中の味方や敵の位置、攻撃、チャットなど - WebSocketやP2Pなどの双方向通信
API サーバー DB サーバー KVS サーバー Log サーバー LB アウトゲームのサーバー構成
CDN Asset サーバー
APIサーバ - リクエスト先はロードバランサによって決まる - 一般的なWebアプリのAPIと同じ構成 - Apache/Nginx - PHP/Java/Go など
APIサーバ - スケールアウト・スケールインを柔軟に - ピーク時と平常時に求められる性能の差が大きい - 機能ごとに分割したサーバーを用意することもある - 課金、認証、マッチングなど -
特定の機能に特化することで、開発に専念
データストア - DB (MySQLやPostgreSQLなど) - 永続化データ - KVS (RedisやMemcachedなど) -
キャッシュ、アクセス頻度が高く消えても問題ない - ログ(BigQueryなど) - 分析用のデータ
アセットサーバー - 静的ファイルの配信用のサーバー - 画像や音楽、3Dモデルなど - CDNでキャッシュさせる - 新バージョンだったらクライアントがリクエストする
アウトゲームの処理の流れ - 画面遷移時やデータ更新時にサーバーにリクエスト - サーバーがDBやKVSのデータを取得、更新 - 一度のリクエストでデータの追加や更新、取得 - リクエストメソッドの使い分けはほぼGETかPOST -
× RESTful API
アセット取得の流れ - アセットの種別ごとにバージョンを管理するDBを用意 - 新しいアセットをデプロイしたらDBのバージョンを上げる - クライアントがアセットのバージョンを確認するリクエスト をする - サーバーはDBのバージョンを返す
- クライアントで保持しているバージョンと違うアセットがあっ たらそのアセットをダウンロード
インゲーム (C/S方式) Battle サーバー DB サーバー KVS サーバー Log サーバー
Battleサーバー - 接続先はバトル開始前にAPIサーバーで割り振られる - リアルタイム性が求められる - WebSocketやリアルタイムゲームエンジン - C++/Node.js/Go など
- サーバー集中型とクライアント分散型 - ゲームによって特色がある
サーバー集中型 - サーバー側でゲームロジックや進行を行う - バトル中サーバー側で必要なデータを保持しておく - 端末間でズレるとまずい処理 - 対戦ゲームでのキャラの位置や当たり判定 -
協力バトルのボスの位置やHP - サーバーの判定処理を待つ必要がある
クライアント分散型 - それぞれの端末でゲームの進行を行う - ゲーム進行上、端末間のズレが気にならない場合 - 協力バトルの雑魚敵の位置はズレても気にならない - 不正対策はしづらい -
擬似的なP2P、パケットのブロードキャストに専念する
インゲームの処理 パーティを組んで戦うアクションバトルの例 1. パーティ作成 or 参加 2. ルーム(バトル空間)を作成、バトル開始 3. ルーム内でバトル
4. バトル終了、ルーム削除、パーティ解散
ルーム入場からバトル開始まで 1. CL → API: パーティ参加リクエスト 2. API → DB:
パーティがあるか確認、なければ作成 3. API → CL: Battleサーバーの接続先を返す 4. CL → Battle: ルーム作成リクエスト 5. CL → API: Battle開始
バトル中 1. CL → Battle: コマンドを送信 2. Battle → CL:
バトル情報を返す 3. Battle → CL: イベント発生を通知
バトル終了 1. CL → Battle: バトル終了リクエスト 2. Battle → CL:
ルームを削除し、切断 3. CL → API: リザルトのリクエスト 4. CL → API: パーティを解散
その他、運営に必要なシステム - レポジトリサーバー、デプロイサーバー - ソースコードやアセットの管理、デプロイに使う - 運営やカスタマーサポート用の管理ツール - データの確認、お知らせやバナーの反映、補填など -
KPI基盤 - ログデータの分析や可視化、社内共通
運用・開発で 気をつけるべきこと
DBの負荷を考慮しよう - DBが負荷のボトルネックになりがち - オンラインでスキーマの変更がし辛い - インデックスやDBのパーティショニング - 集計データはバッチ処理して、キャッシュさせる -
なるべく少ないクエリ数でデータを取得
DBの負荷分散 - 水平分割 - ユーザのIDごとにDBサーバを振り分ける - 期間限定のDBを日付でパーティショニング - Master/Slave構成 -
マネージドサービスを使うのもあり
オンラインメンテ - DBのデータ設計を変えたときや定期メンテをオンライン でやりたい - Master DBがネック - Master/Slave切り替え -
Percona Tool Kit Online Schema Change(MySQL) - マネージドサービスを使うのもあり
リリース後のアラート監視 - サーバーが止まる前に対処する - 各種サーバーのエラー、CPU使用率、リクエスト数 - DBサーバーのクエリ数 - レスポンスタイム -
Disk write、使用量 - お客様の問い合わせ、Twitterでエゴサ
ゲーム運用で便利なツールを作る - データ管理のしくみを作ろう - ExcelやスプレッドシートからSQLへの変換 - デバッグ機能や管理ツールを作ろう - 開発スピードが格段に上がる -
管理ツールの権限管理は重要
まとめ
まとめ - ゲームのシステム構成は基本的にはWebアプリと一緒 - アクセス数や更新頻度が高くなる傾向 - リアルタイム性の求められるシステム構成はゲームによっ て異なる - 高い可用性を保つためにオンラインメンテ、アラート監
視などの工夫が必要
ご清聴ありがとうございました!