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
4
15k
スマホゲームサーバーのしくみをしってみよう
【サポーターズCoLab勉強会】「スマホゲームサーバーのしくみをしってみよう」の登壇資料です。
Takuma Kajikawa
October 29, 2018
Tweet
Share
More Decks by Takuma Kajikawa
See All by Takuma Kajikawa
phpkansai2025 domain event
kajitack
0
1
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
1k
エラーって何種類あるの?
kajitack
5
390
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
660
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1.5k
例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する
kajitack
17
5.5k
デザインシステムを始めるために取り組んだこと - TechTrain x ゆめみ ここを意識してほしい!リファクタリング勉強会
kajitack
3
680
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
13
2.9k
Figmaで進化するデザイナーとエンジニアの連携 FoF Tokyo 2024
kajitack
0
110
Other Decks in Programming
See All in Programming
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
620
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
8.7k
可変変数との向き合い方 $$変数名が踊り出す$$ / php conference Variable variables
gunji
0
180
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
0
120
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
1.1k
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
350
Rails Frontend Evolution: It Was a Setup All Along
skryukov
0
280
NEWT Backend Evolution
xpromx
1
140
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
1
200
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
1k
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
620
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
108
19k
For a Future-Friendly Web
brad_frost
179
9.8k
How STYLIGHT went responsive
nonsquared
100
5.6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Documentation Writing (for coders)
carmenintech
72
4.9k
Become a Pro
speakerdeck
PRO
29
5.4k
Fireside Chat
paigeccino
37
3.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Bash Introduction
62gerente
613
210k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
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アプリと一緒 - アクセス数や更新頻度が高くなる傾向 - リアルタイム性の求められるシステム構成はゲームによっ て異なる - 高い可用性を保つためにオンラインメンテ、アラート監
視などの工夫が必要
ご清聴ありがとうございました!