遊戲 Lag 白皮書 › L13 伺服器架構與維運
連鎖故障 Cascading failure
原因 ID in-cascade · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（網路基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
一個服務變慢時，呼叫它的伺服器會卡在等待回應，連不相關的功能也跟著停擺。
為什麼 DB、認證等某一個服務變慢 → 於是 呼叫端伺服器的執行緒與連線卡在等待回應，失敗請求的重試又加重負載 → 畫面上 看似無關的功能也全部變慢或停擺
- 症狀
- 定格, 輸入延遲, 連不上／無限讀取
- 因素
- 停滯
- 誰會遇到
- 整個伺服器
- 何時
- 人潮湧入時, 偶爾隨機發生
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（網路基礎設施）
- 遊戲開發團隊要做的事
- 所有呼叫都設逾時、斷路器、依功能隔離（bulkhead），重試要逐步拉長間隔並限制次數，健康檢查的回應與忙碌的工作分開處理。
- 基礎設施團隊要做的事
- 負載平衡器的健康檢查在失敗次數與間隔上保留餘裕，避免把只是暫時變慢的伺服器立刻移出；限制同時移出的伺服器數量。
- 圖表上
- 碰到上限後持平 · 各服務的回應時間與錯誤率、執行緒與連線使用數
- 查看位置
- 把各服務的回應時間、錯誤率、重試次數對齊時間軸放在同一個畫面，找出最先變慢的地方。若在負載平衡器後方，看目標回應時間（AWS ALB 為 TargetResponseTime）、目標的 5xx 數（HTTPCode_Target_5XX_Count）、判定異常而移出的目標數（UnHealthyHostCount）
- 符合的跡象
- 某個服務的延遲先上升，接著呼叫該服務一方的執行緒、連線使用數貼齊上限，錯誤擴散到其他服務，重試次數與移出的目標數一起增加
- 不符合的跡象
- 多個服務在同一瞬間一起變慢時，先查共用資源（DB、網路、主機）的故障
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 健康檢查（確認伺服器是否存活的檢查）也會讓連鎖擴大。忙碌的伺服器太晚回應檢查時，負載平衡器會把其實正常的伺服器移出，它的流量湧向剩下的伺服器，下一台伺服器也跟著變慢。
- 實際案例
- Riot Games 2020: League of Legends 歐洲、巴西伺服器的邊緣主機過載
Riot Games 2021: League of Legends EUW 5 小時事故：一個附屬 DB 讓整個伺服器停擺
Roblox 2021: Roblox 73 小時事故：服務探索（Consul）叢集的資源競爭
AWS 2021: AWS us-east-1 內部網路壅塞
AWS 2025: AWS us-east-1 DynamoDB DNS 事故與漫長的復原
出處
- Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
過載的伺服器健康檢查失敗被移出後，負載集中到剩下的伺服器，重試又放大負載；建議限制重試次數、使用隨機化的指數退避並設定截止時間（deadline） - Circuit Breaker Pattern Microsoft Azure
卡到逾時的請求占用執行緒與 DB 連線，讓不相關的功能也失敗；一定時間內失敗累積時直接拒絕呼叫 - Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library。5 層呼叫中每層各重試 3 次，DB 負載會變成 243 倍；只在一個地方重試，並用 token bucket 限制 - CloudWatch metrics for your Application Load Balancer AWS
TargetResponseTime（請求離開負載平衡器到目標開始回應所花的時間）、HTTPCode_Target_5XX_Count（目標產生的 5xx 數）、UnHealthyHostCount（異常目標數）
相關原因
同一層：L13 伺服器架構與維運
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片