負載平衡器分配不均與健康檢查誤判 LB imbalance, bad health checks

原因 ID dc-lb-imbalance · 主要負責 基礎設施團隊（網路基礎設施） · 協同遊戲開發團隊（伺服器開發）

連線全集中到一台伺服器，或持續把人送往已經掛掉的伺服器。

為什麼 分配規則不合適，或健康檢查（health check）看不到實際狀態 → 於是只有一台伺服器過載，或連線被送往掛掉的伺服器 → 畫面上 只有部分頻道、部分人出現慢動作，或連不上／無限讀取

症狀: 慢動作, 連不上／無限讀取
因素: 停滯, 遺失
誰會遇到: 特定地點／頻道
何時: 剛登入／維護剛結束, 人潮湧入時
負責單位: 主要負責 基礎設施團隊（網路基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 實作健康檢查，依實際遊戲狀態（tick 是否推進、DB 連線）回應負載平衡器的檢查請求，並一併回報伺服器負載值。
基礎設施團隊要做的事: 把健康檢查改成確認實際遊戲回應的方式，依伺服器負載分配，監控各伺服器連線數的差距。
圖表上: 只有部分偏高 · 各伺服器的連線數與 CPU 使用率
查看位置: 把負載平衡器後方每台伺服器的連線數（ss -s）與 CPU 使用率疊在同一張圖上，並將負載平衡器的目標健康狀態（AWS 為 CloudWatch 的 HealthyHostCount、UnHealthyHostCount）與遊戲伺服器的實際狀態比較
符合的跡象: 只有一兩台伺服器的連線數與 CPU 明顯高於其他伺服器，或 tick 已停住的伺服器仍以健康狀態「正常」留著，持續接收新連線
不符合的跡象: 各伺服器連線數平均、只有一個頻道變慢時，是該頻道內部的負載問題（「單執行緒區域過載（熱點）」）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
實際案例: AWS 2025: AWS us-east-1 DynamoDB DNS 事故與漫長的復原

出處

Load Balancing in the Datacenter Google
單純的 round robin 會讓各工作之間的 CPU 使用量相差最多 2 倍，後端把負載附在回應與健康檢查中回傳的加權分配，表示不再接收請求的 lame duck 狀態
Health checks for Network Load Balancer target groups AWS
健康檢查預設間隔 30 秒、失敗 2 次即移出，UDP 服務是用 TCP、HTTP 健康檢查確認，建議配置成能反映實際服務狀態
CloudWatch metrics for your Network Load Balancer AWS
HealthyHostCount、UnHealthyHostCount：判定為健康、不健康的目標數