한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

遊戲 Lag 白皮書 › L13 伺服器架構與維運

經由閘道/proxy Gateway / proxy hop

原因 ID in-gateway · 主要負責 遊戲開發團隊(伺服器開發) · 協同 基礎設施團隊(伺服器基礎設施), 遊戲開發團隊(用戶端開發)

在含圖解與實驗的完整版中開啟卡片 →

在用戶端與遊戲伺服器之間放一台中介伺服器時,每經過一次就多一段處理時間,而且這台伺服器會成為單點故障。

為什麼 用戶端 ↔ 閘道 ↔ 遊戲伺服器的架構 → 於是 多了中介伺服器的處理與等待時間,過載時影響所有人 → 畫面上 整體 ping 上升;閘道故障時,經過它的玩家全部斷線

症狀
輸入延遲, 斷線
因素
延遲, 停滯
誰會遇到
整個伺服器
何時
人潮湧入時, 一直都有
負責單位
主要負責 遊戲開發團隊(伺服器開發) · 協同 基礎設施團隊(伺服器基礎設施), 遊戲開發團隊(用戶端開發)
遊戲開發團隊要做的事
伺服器:做成閘道可以擴充到多台的架構,並讓閘道掛掉時改連另一台閘道後角色能直接接續(session 重新連線)。用戶端:與閘道的連線中斷時自動重新連線。
基礎設施團隊要做的事
閘道水平擴展(增加台數),監控每台閘道的 CPU、連線數與處理延遲。
數值參考
因為在同一個資料中心內,平常每經過一次不到 1ms。閘道過載時會增加到數十~數百 ms。
圖表上
隨人數/負載上升 · 閘道處理延遲、閘道的 CPU 與連線數
查看位置
閘道的 CPU、連線數與閘道 socket 的 Recv-Q(ss、netstat),以及經過閘道前後的延遲差。若是經過 service mesh 的 HTTP、gRPC 呼叫,將 Istio 標準指標 istio_request_duration_milliseconds 分成發送端(reporter=source)與接收端(reporter=destination)比較
符合的跡象
遊戲伺服器的處理時間不變,只有閘道區段的延遲增加,且同一時間閘道 CPU 飽和或 Recv-Q 堆積
不符合的跡象
不經過閘道的路徑(直接連線、其他閘道)也一樣慢時,是線路或遊戲伺服器端的問題
確認方式
用基礎設施工具確認(不需要遊戲程式碼)
深入了解
使用 service mesh(Istio 等)時,每台伺服器旁邊附掛的 sidecar proxy(Envoy)也會多出一層。服務之間的請求會依序經過發送端的 sidecar 與接收端的 sidecar,proxy 上加的功能(例如收集 log、指標)越多,處理時間與等待時間就越長。
實際案例
Riot Games 2020: League of Legends 歐洲、巴西伺服器的邊緣主機過載

出處

  1. The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
    New World 的用戶端連到 4 台具有公用位址的入口伺服器(REP)之一,再與後方的模擬伺服器(hub)通訊
  2. Designs, Lessons and Advice from Building Large Distributed Systems Google
    LADIS 2009 主題演講(Jeff Dean)。同一資料中心內往返約 0.5ms
  3. Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
    過載使佇列變長時,等待時間會變成處理時間的好幾倍(處理 100ms、佇列為執行緒數的 10 倍時為 1.1 秒)
  4. Performance and Scalability Istio
    sidecar 模式下請求依序經過發送端與接收端的 sidecar proxy;功能加得越多,proxy 內的處理路徑越長,收集遙測資料(telemetry)也會拉長下一個請求的等待時間
  5. What is Envoy Envoy
    Envoy 是在每台應用程式伺服器旁邊獨立執行的處理程序,應用程式透過 localhost 上的 Envoy 收發資料
  6. Istio Standard Metrics Istio
    istio_request_duration_milliseconds(HTTP、gRPC 請求處理時間分布),以 reporter 標籤區分發送端(source)與接收端(destination)的 proxy
  7. netstat(8) — Linux manual page net-tools
    Recv-Q:已連線的 socket 中,使用者程式尚未取走的位元組數

相關原因

同一層:L13 伺服器架構與維運

同一症狀(輸入延遲)在其他層的原因

查看含圖解與實驗的完整版卡片