遊戲 Lag 白皮書 › L13 伺服器架構與維運
自動擴展延遲 Autoscaling lag
原因 ID in-autoscale · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
人潮湧入時會自動增加伺服器，但準備要花幾分鐘，這段期間既有的伺服器處於過載。
為什麼 活動開始，連線急增 → 於是 新伺服器從啟動到準備好需要數分鐘 → 畫面上 活動剛開始的幾分鐘內出現慢動作、連不上
症狀 慢動作 , 連不上／無限讀取 因素 停滯
誰會遇到 整個伺服器
何時 人潮湧入時, 剛登入／維護剛結束
負責單位 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事 分散頻道（已在擁擠頻道裡的人無法移到新伺服器），縮短新伺服器的啟動與資料載入時間。
基礎設施團隊要做的事 活動前預先擴展、準備已暖機的備用伺服器，縮減時等留下的人離開後再關閉。
數值參考 偵測到負載要 1～數分鐘（因為指標是取數分鐘的平均來看），啟動新伺服器、讀取遊戲資料、填滿快取又要數分鐘。
圖表上 查看位置 把自動擴展的活動紀錄（決定擴展的時間、新執行個體開始服務的時間）疊在 CPU 使用率、連線數圖表上看。AWS 看 Auto Scaling 群組指標（要先啟用才看得到）GroupDesiredCapacity（目標台數）、GroupPendingInstances（準備中）、GroupInServiceInstances（服務中） 符合的跡象 連線急增後幾分鐘內只有目標台數與準備中的執行個體增加，既有伺服器的 CPU 貼齊上限，直到服務中的執行個體增加的時間點才緩解 不符合的跡象 新執行個體加入後仍然很慢時，是伺服器台數以外的原因（DB 等共用資源、連鎖故障） 確認方式 用基礎設施工具確認（不需要遊戲程式碼）
深入了解 自動擴展主要用在登入、閘道、副本這類只要讓新伺服器接新玩家就好的地方。縮減時也會出問題。清晨人少時縮減伺服器，如果沒等留下的人離開就關機，這些人會斷線。
實際案例 AWS 2021: AWS us-east-1 內部網路壅塞 AWS 2025: AWS us-east-1 DynamoDB DNS 事故與漫長的復原
出處 Target tracking scaling policies for Amazon EC2 Auto Scaling AWS EC2 基本指標為 5 分鐘間隔（啟用詳細監控為 1 分鐘），要快速反應建議使用 1 分鐘以下間隔的指標 Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS 群組指標要啟用後才會以 1 分鐘為單位發布，GroupDesiredCapacity（要維持的台數）、GroupPendingInstances（尚未開始服務的執行個體數）、GroupInServiceInstances（服務中的執行個體數） Scheduled scaling for Amazon EC2 Auto Scaling AWS 配合可預測的負載變化，在排定的時間預先增減容量 Decrease latency for applications with long boot times using warm pools AWS 開機很久的應用程式，用預先初始化的執行個體池（warm pool）縮短擴展延遲 相關原因
同一層：L13 伺服器架構與維運
同一症狀（慢動作）在其他層的原因
查看含圖解與實驗的完整版卡片