iT邦幫忙

4

請教關於全球架構遊戲伺服器的建議

大家好,小弟不才想在此請教各位有經驗的前輩們提供建議或給予鞭策

目前專案的需求是希望可以在全球各處的使用者可以在同一個場景下互相看到彼此,依照我所查詢的一些資料和其他公司的做法,大致上都是根據各區域進行分服各自處理該區的資料,但主管認為這不符合需求因此駁回,同時也有提供一個名為Zwift的騎車訓練用軟體給我參考,該軟體似乎也是全球同步的作法。

目前我的作法是:

  1. 利用AWS EC2在各區域架設並在上面運行伺服器,彼此之間互相進行遊戲及玩家資料傳送
  2. 資料庫的部分在台灣架設master資料庫,其他各區域架設slave資料庫減少資料讀取延遲並降低master資料庫負載

目前我的疑惑是:

  1. 結構過於網狀化管理起來似乎很複雜
  2. 各區域即使會互相傳送資料同步還是會受到現實物理距離影響導致客戶端畫面同步不順暢

上述做法如果前輩們希望我可以多補充說明的地方可以向我提出,我會盡快補充上去,或是有哪裡很笨的地方也可以直接給予鞭策,感謝!

補充目前使用相關工具:

  1. Unity
  2. AWS(EC2, RDS, S3, CloudFront, DynamoDB)
  3. Photon
kuosheng iT邦新手 4 級 ‧ 2021-09-20 09:01:49 檢舉
既然都用了AWS EC2了,為什還用master/slave 的架構; 直接用AWS Dynomodb不就OK了;不想用NoSQL, 那你就遷移到GCP,用它的spanner, distributed RDBMS.你要的架構一定是可以處裡分散式交易的資料架構啦~~ 因為你的要求是全球阿~~ 告訴你的主管,不要認為全球的分散式架構的資料同步好做,光一個 zone內的資料同步就不見得能達到它的要求,不然你就什麼都由AP來控制囉~~看來他的想法是想這麼做
....就慢慢由AP端攪吧~~看起來你的年薪是超過300萬....不然怎麼會去扛這種責任??
kuosheng iT邦新手 4 級 ‧ 2021-09-20 11:23:10 檢舉
You can also try this by the AP point of view,but you also need a very strong database system to support AP servers' requests.
With global Cloud Load Balancing, your application presents a
single front-end to the world
● Users get a single, global anycast IPaddress.
● Traffic goes over the Google backbonefrom the closest point-of-presence to the user.
● Backends are selected based on load.
● Only healthy backends receive traffic.
● No pre-warming is required.
andy2kuo iT邦新手 5 級 ‧ 2021-09-20 14:47:46 檢舉
感謝您的回答!
DynamoDB確實是因為NoSQL而放棄的,因為有些功能是使用NoSQL比較不方便處理的。至於GCP的話我確實比較沒有去研究他們的相關服務,我會先從您提供的那幾項服務中先去看看,感謝!
我的年薪大約在砍一個位數就差不多了哈哈...我也不知道為什麼最後我會去負責到這項工作,至今依然百思不解...
8
raytracy
iT邦大神 1 級 ‧ 2021-09-20 11:15:46
最佳解答

沒考慮用 Photon Engine 嗎? (不用自己重新發明輪子)
https://www.photonengine.com/zh-TW/Realtime

自架伺服器授權可容納不限人數用戶 (通常是你的頻寬在受限):
https://medium.com/photon-taiwan/%E5%A6%82%E4%BD%95%E6%8C%91%E9%81%B8%E9%81%A9%E7%95%B6%E7%9A%84-photon-%E4%BC%BA%E6%9C%8D%E7%AB%AF%E7%94%A2%E5%93%81%E6%96%B9%E6%A1%88-68b40b68053a

看更多先前的回應...收起先前的回應...
andy2kuo iT邦新手 5 級 ‧ 2021-09-20 14:33:20 檢舉

感謝提供相關工具資訊,Photon Engine也有在我們使用工具中的名單內,很抱歉上面內文沒有提到,稍後我會再補充上去。
依照目前Photon使用狀況來看確實是相當方便好上手,擴充上也相當方便,只是目前對於整體架構規劃方面比較有疑惑,因為目前歐美區的使用者反應延遲狀況很嚴重...

raytracy iT邦大神 1 級 ‧ 2021-09-20 14:45:38 檢舉

這樣就是你們架構設計的問題了, 延遲有兩種: Network Latency 和 Application Latency, 網路延遲是先天物理限制, 比較沒有改良的空間; 但應用延遲通常可以挖出很多可改善的點....

改善任何應用延遲之前, 都要先建立好準確的量測工具, 長期觀察測量出每一段 Micro service 的延遲狀況, 看是誰卡住最多? 再來想辦法排除....

如果你們覺得是 Photon Engine 造成延遲的話, 可以跟它們官方討論架構...或者, 你們也可以請官方提供, 跟你們應用場景類似的成功案例, 讓你們參考他們架構看看....

你們也可以用獎金懸賞方式, 徵求架構師幫你們解決問題....當然, 獎金不能開太少, 目前架構師的年薪普遍在 NT$250萬起跳到 NT$500萬之間...

andy2kuo iT邦新手 5 級 ‧ 2021-09-20 14:58:49 檢舉

延遲狀況的話,我在檢驗運算所有使用者狀態時間消耗約為5~15ms左右,這部分要看當時的連線人數。但在歐美伺服器與亞洲伺服器之間的ping約莫落在150~250ms之間,因此我也認為應該是在架構上有配置有誤。
最近的想法是試試AWS Global Accelerator這項服務,但主管認為消耗經費上想再多控制點,因此我把這個放在比較後面...

raytracy iT邦大神 1 級 ‧ 2021-09-20 15:06:21 檢舉

跨洲延遲已經撞上物理限制, 你不可能突破, 唯一方法就是提前把資料先送到歐美的 Edge 端點, 讓他可以立即拿到..

Global Accelerator 不見得是最優解, 因為他並不瞭解你們的資料特性, 只會傻傻地把存取量需求最高的派送到端點去, 但存取量最高是否就等於資料即時性最高? 這兩個不見得對等....而且你還是無法控制他的派送時間...

目前看來, 光是依賴現成工具似乎是辦不到你們要的...

你們需要設計一個: 符合你們特性, 專用的全球資料分派演算法, 而且可能必須自己搭建底層的資料傳遞系統, 來實現這個演算法...

(題外話, Zwift 去年七月也在徵求架構師, 不知道他們找到沒...)

raytracy iT邦大神 1 級 ‧ 2021-09-20 15:57:54 檢舉

簡單的數學算一下:

假設一個用戶產生的動作, 從一端跨洲傳送到最遠端, 我們可以控制的延遲是 250ms 的話, 加上兩端各自運算邏輯處理的時間, 假設各 25ms 延遲的話, 一個用戶的動作發佈到全球端點需要:
250+(25x2)=300ms

也就是說, 你的遊戲動作精細度(時間差), 不能小於 300ms, 才有可能辦到這個全球同步的要求. (通常全球同步我們都預期要抓 500ms 延遲)

Zwift 能做到有幾種可能:

  1. 他要呈現的動作時間差, 不需要那麼短
  2. 他利用假動作欺騙端點用戶, 待收到正確資料再修正
  3. 他利用 AI 預測下一個可能的動作, 提早傳送或運算
  4. 他的運算處理量不高 (他有許多運算是 Edge 就完成的)

以 Zwift 的遊戲特徵來看, 以上都很容易做到; 但換成別的性質, 就很難說了; 所以你們其實可以尋求 Unity 或 Photon 官方的協助, 看能否給你們一些案例參考?

此外, 如果要優先考慮低延遲, 可能就要容許某種程度的資料損失, 允許 UDP, 後補, 壓縮, 或者只傳送差異資料, 這些都是你們底層要設計的演算邏輯, 也是其他現成工具無法馬上取代掉的; Photon 有些思考方向可以參考:
https://doc.photonengine.com/en-us/pun/current/gameplay/synchronization-and-state

andy2kuo iT邦新手 5 級 ‧ 2021-09-22 10:14:01 檢舉

感謝您提供的這幾項分析!
我後續根據您建議的方向以及其他相關收集的資料,似乎MMORPG會有一個獨立的地圖伺服器作為管理所有玩家位置以及地圖上的相關物件,再加上您建議設計符合我們特性的演算法去推送玩家資訊,我目前的想法是類似主從式的架構,各區域伺服器(從)連接地圖伺服器(主)取得相關玩家資訊針對該區域進行分發,並允許各區域伺服器(從)依照目前資料延遲狀態進行玩家資料模擬。
不過這部分應該也是需要段時間去進行演算法測試及優化,想請教下您對這部分有沒有哪些建議?

1
mathewkl
iT邦研究生 5 級 ‧ 2021-09-19 12:36:37

看起來是想類似MMO那種多人同時線上?
目前我玩過的遊戲在伺服器架構上最強大的依舊是2012上市的GW2

原本GW2架構跟其他遊戲一樣伺服器只能看到同伺服器的玩家
現今依舊普遍的單一伺服器獨立架構

但開發商很快地在2014捨棄了這個架構,GW2搖身一變可以在同個地圖上看到不同伺服器的玩家,快超出上限就會自動產生地圖分流繼續容納陸續進來的各伺服器玩家
開發商稱為MEGA Server
https://www.guildwars2.com/en/news/introducing-the-megaserver-system/

FF14單純可以讓玩家傳送去別的伺服器遊玩和打副本,滿了要排隊
(我沒玩FF14所以描述比較少)

基於物理限制,不管何種架構都有Sync和ping的問題
不過GW2的網狀架構更為複雜但除了戰場伺服器外都運行的很好
GW2也是建在AWS上,你可以看一下MEGA Server介紹看能不能給你一些靈感?

andy2kuo iT邦新手 5 級 ‧ 2021-09-19 15:32:50 檢舉

在此先感謝回覆以及提供相關資訊,在看過內文關於Megaserver System的介紹後,我發現他似乎還是以分區為前提來開發,但是在同區域內會以玩家興趣取向來分配相關伺服器位置。
不過這部分對於未來設計玩家位置分配演算法很有幫助,感謝幫忙!

mathewkl iT邦研究生 5 級 ‧ 2021-09-19 19:56:35 檢舉

兩個獨立大區EU/US,CN是代理論外,EU伺服器有標示語系,但我是US玩家,語系標示在Mega server機制後大概名存實亡,目前只有WvW會產生玩家為了追求更多戰場人口而移動帳號伺服器,不過下半年要開始測試以公會聯盟為基礎的戰場,測試完取代WvW正式上線後選擇伺服器就真的沒有任何意義了。

2

其實如果是AWS的話,AWS本身就有對應的相關伺服處理了。
一般來說,我會資料庫直接RDS開多分區來處理(成本會很高就是了)
但一個地理區(如亞太、西歐....)同步連結一個地區。
因為不太清楚你的地理區情況。我只能先用這樣做範例。

再來就是考量頻寬區及機器效能區。
在不了解你遊戲的情況下。我會偏重使用M級的機器(記憶體加強)
能搭配負載平衡就搭配。降低一些成本。

最後再利用ROUND53的能力及VPN的能力來處理就行了。

基本上這些一整個系列的搭配。都需要要求很高的等級處理。

andy2kuo iT邦新手 5 級 ‧ 2021-09-22 10:40:54 檢舉

感謝您提供的建議!
我們的地理狀態大致就和您範例中的一樣,Route53的部分我還沒有去看過相關服務,我會再去確認相關功能說明試試後續搭配方式。

去看一下round53詳細說明文件,它有地理區特性連結(需要設定)
我之前開CN2線路(很貴的線路),其主要目的給大陸地區使用。
但那時還不會做切換。任何一條國際線都是透過CN2的線路出去。
其成本非常的高。
(CN2是採取流量計費)

後期有高人告訴我可以透過round53來區分跳轉所需線路。
可以切換大陸來的線路才跑CN2。其餘依常規線路跑。
設定完後,整體線路成本就下降到原本的一半以下。
(因為其實大陸區的會員並不多)

且 round53 可以幫忙你分配到專屬地理區。無需再用PROXY的方式轉接過去。

其它你的需求,其實你可以去問一下專門跑AWS的架構師。
他會做好一整體的規劃。當初教我的高人其實就是架構師。

dragonH iT邦超人 5 級 ‧ 2021-09-22 21:58:15 檢舉

在不了解你遊戲的情況下。我會偏重使用M級的機器(記憶體加強)

指的是ec2嗎

是的話 m 應該是 general purpose

r開頭才是 memory optimized

我要發表回答

立即登入回答