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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yasutomo Uemori
PRO
January 17, 2024
Technology
490
1
Share
いまどきのゲームサーバアーキテクチャ
社内でLTしたときの資料です
Yasutomo Uemori
PRO
January 17, 2024
More Decks by Yasutomo Uemori
See All by Yasutomo Uemori
よくわかる新収益認識基準
wakaba260
PRO
0
1.1k
オンラインゲームのRails複数db戦略
wakaba260
PRO
0
84
Active job meets kubernetes
wakaba260
PRO
0
39
Ruby/Rails Benchmarking and Profiling with TDD
wakaba260
PRO
0
68
GCP・GKEで作るスケーラブルなゲーム開発環境
wakaba260
PRO
0
79
サービスクラス、その前に
wakaba260
PRO
0
38
Rails on Dockerとの戦い
wakaba260
PRO
0
39
Rubocopとの付き合い方
wakaba260
PRO
0
46
Rails api way in aiming
wakaba260
PRO
0
45
Other Decks in Technology
See All in Technology
AWS DevOps Agentはチームメイトになれるのか?/ Can AWS DevOps Agent become a teammate
kinunori
6
760
Percolatorを廃止し、マルチ検索サービスへ刷新した話 / Search Engineering Tech Talk 2026 Spring
visional_engineering_and_design
0
140
需要創出(Chatwork)×供給(BPaaS) フライホイールとMoat 実行能力の最適配置とAI戦略
kubell_hr
0
790
[最強DB講義]推薦システム | 評価編
recsyslab
PRO
0
100
今年注目する!データ分析プラットフォームでのAIの活用
nayuts
0
150
社内エンジニア勉強会の醍醐味と苦しみ/tamadev
nishiuma
0
230
独断と偏見で試してみる、 シングル or マルチエージェント どっちがいいの?
shichijoyuhi
1
120
AgentCore×VPCでの設計パターンn選と勘所
har1101
3
300
20260428_Product Management Summit_Loglass_JoeHirose
loglassjoe
2
3.6k
LLM時代の検索アーキテクチャと技術的意思決定
shibuiwilliam
3
1.5k
AI와 협업하는 조직으로의 여정
arawn
0
510
目的ファーストのハーネス設計 ~ハーネスの変更容易性を高めるための優先順位~
gotalab555
8
2.3k
Featured
See All Featured
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
110
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
770
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
380
Thoughts on Productivity
jonyablonski
76
5.1k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
220
How STYLIGHT went responsive
nonsquared
100
6.1k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
190
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.5k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
490
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
170
Transcript
いまどきの ゲームサーバ アーキテクチャ サーバエンジニア 植森 康友
今回のお話 ステートレスとステートフルの話に触れつつ いろんなサーバ構成の例を見て いまどきのゲームサーバの 全体アーキテクチャについて振り返る
お話の発端
お話の発端
とあるMMORPGのサーバ構成
Q. ステートフルゲームサーバのアーキテクチャが 重視しているポイントを2つ挙げてください
1. 負荷分散
2. サーバ費用
ステートフルゲームサーバのアーキテクチャが 重要視しているポイント 1. 負荷分散 2. サーバ費用 ➔ ステートレスなアーキテクチャが頭にあると 気づきにくいが実はスケーラビリティが重要視されている ※チート対策とかレイテンシとかももちろんある
MOの場合(空間コピー)
MMOの場合(空間分割+空間コピー)
さらにワールド分割でDBのボトルネックを回避
詳しくはオンラインゲームを支える技術を
ステートフルサーバアーキテクチャの 負荷分散手法 • 空間分割 • 空間コピー • ワールド分割 ➔ スケーラビリティとの戦いによる技術
➔ 「売れた時に規模を拡大したい」は昔から変わらない課題
古のゲーム開発からの時代の変化 • マシンコストの低下(メモリ、CPU、ディスク) • Web技術の発展 • アーキテクチャの進化(VM、クラウド、コンテナ) • ビジネス要求の変化
Web技術の採用 「剣と魔法のログレス いにしえの女神 〜スマホ時代の MMORPG を支える技術」より https://www.slideshare.net/satoshiyamafuji/cedec2014-logres-cedil
ビジネス要求の変化 グラブルのようなWebベースのゲームでもリアルタイム処理が必要な時代に 「グランブルーファンタジーを支えるインフラの技術」より https://speakerdeck.com/cygames/kuranhuruhuantasiwozhi-eruinhurafalseji-shu
ステートフルとステートレスの差が減りつつある
いまどきのステートレス vs ステートフル 簡単なwebアプリケーションなら、事前にデータフォーマットを定義し、リクエストを受けるたびに、DBからユーザの情報を読み取り、処理後DBに書き込みする ことが一般的です。ネットゲームにおいて、強いコンテキストを持ち、ユーザ間の連携も多いです。もし同じモードを採用すると、 DBの処理とロジックの処理の 間、ボトルネックになりやすい、このボトルネックネックは通常キャッシュをレイヤーを追加するだけで解決できないことが多いです 。 Skynetでゲームホストする場合は、同期的にデータをDBに保存することはおすすめしません、代わりにインメモリのDBに保存したほうが良い。 サービス、アプ
リロジックやゲームデータは全部メモリで常駐します。もしDBはあなたのフレームワークの一部でしたら、殆どの場合バックアップとして使うべき。データの状態 が変わったもしくは定期的にDBに保存します 。アプリは直接メモリからデータを呼びます。 • インフラ技術やミドルウェア、クラウドの発展によりDBのボトルネックは回避されやすくなった • インメモリ=アプリロジックの処理をどこでやるか?が決定的な差異 ➔ インメモリの処理をクライアントに依存しているのが今のステートレスサーバの正体 ➔ ビジネス要件がクライアントのインメモリ処理で事足りている(特にチート対策)
None
None
ステートフルサーバはMicro Serviceが必要 厳密にはMicroServiceではなく分散システム
剣と魔法のログレスのサーバ構成例 「剣と魔法のログレス いにしえの女神 〜スマホ時代の MMORPG を支える技術」より https://www.slideshare.net/satoshiyamafuji/cedec2014-logres-cedil
Proxyの採用による固定IPの排除 「Protect Multiplayer Game Servers From DDoS Attacks Using Amazon
GameLift」より https://aws.amazon.com/jp/blogs/gametech/protect-multiplayer-game-servers-from-ddos-attacks-using-amazon-gamelift-2/
Proxyの採用による固定IPの排除 とあるMMORPGの構成
Proxyの採用による固定IPの排除 「グランブルーファンタジーを支えるインフラの技術」より https://speakerdeck.com/cygames/kuranhuruhuantasiwozhi-eruinhurafalseji-shu
ステートフルサーバでもコンテナ技術を採用 「Kubernetesでステートフルなゲームサーバを動かした思い出」より https://link.medium.com/phnOduRALfb 「agones超入門」より https://medium.com/google-cloud-jp/agones-beginner-jp-5a6553e7e9a4
ステートレスではクラウドやサーバレスの採用 「ミリシタを支える GAE/Go」より https://www.slideshare.net/GoogleCloudPlatformJP/gaego-80349110 「AWSケーススタディ:Habby」より https://aws.amazon.com/cn/solutions/case-studies/habby/
どのアーキテクチャがいいのか
ゲームの要件によって 適切な構成は変化するので絶対の回答はない
まとめ • 時代の流れでステートレスとステートフルの差は減った • インメモリの処理をどこに寄せるかでアーキテクチャは大きく 変わる (チート対策、開発コスト、etc...) • 既存のアーキテクチャに学ぶ点は多いのでキャッチアップ大事 要件と相談してより良いアーキテクチャを検討していきましょう
ご静聴ありがとうございました