คู่มือเกมแลค › L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
autoscaling เพิ่มเครื่องไม่ทัน Autoscaling lag
ID สาเหตุ in-autoscale · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
เมื่อคนแห่เข้ามา ระบบจะเพิ่มเซิร์ฟเวอร์อัตโนมัติ แต่ต้องใช้เวลาเตรียมหลายนาที และระหว่างนั้นเซิร์ฟเวอร์เดิมรับโหลดเกิน
ทำไม อีเวนต์เริ่มแล้วผู้เล่นแห่เชื่อมต่อเข้ามา → ผลคือ กว่าเซิร์ฟเวอร์ใหม่จะเปิดและพร้อมใช้ต้องใช้เวลาหลายนาที → บนหน้าจอ ไม่กี่นาทีแรกหลังอีเวนต์เริ่ม เกิดสโลว์โมชั่นและเข้าเกมไม่ได้
- อาการ
- สโลว์โมชั่น, เข้าเกมไม่ได้/โหลดไม่จบ
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, หลังล็อกอิน/หลังปิดปรับปรุง
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- กระจายผู้เล่นตามแชนแนล (คนที่อยู่ในแชนแนลที่แน่นอยู่แล้วย้ายไปเซิร์ฟเวอร์ใหม่ไม่ได้), ลดเวลาเริ่มทำงานและเวลาโหลดข้อมูลของเซิร์ฟเวอร์ใหม่
- งานฝั่งทีมอินฟรา
- ขยายไว้ก่อนอีเวนต์, เตรียมเซิร์ฟเวอร์สำรองที่ warm-up แล้ว, เวลาลดเครื่องให้รอคนที่เหลือออกไปก่อนแล้วค่อยปิด
- ตัวเลขที่ควรรู้
- ใช้เวลา 1 นาทีถึงไม่กี่นาทีกว่าจะตรวจพบโหลด (เพราะดูค่าเฉลี่ยของเมตริกหลายนาที) และอีกหลายนาทีเพื่อเปิดเซิร์ฟเวอร์ใหม่ อ่านข้อมูลเกม และเติมแคช
- บนกราฟ
- พุ่งทันทีหลังเปิดเซิร์ฟ/ปิดปรับปรุง · จำนวนอินสแตนซ์, อัตราการใช้ CPU, จำนวนผู้เล่นที่รอเข้าเกม
- จุดที่ต้องดู
- วางประวัติกิจกรรมของ autoscaling (เวลาที่ตัดสินใจขยาย, เวลาที่อินสแตนซ์ใหม่เริ่มให้บริการ) บนกราฟอัตราการใช้ CPU และจำนวนการเชื่อมต่อ บน AWS ใช้เมตริกของ Auto Scaling group (ต้องเปิดก่อนจึงจะเห็น) GroupDesiredCapacity (จำนวนเป้าหมาย), GroupPendingInstances (กำลังเตรียม), GroupInServiceInstances (กำลังให้บริการ)
- สัญญาณว่าใช่
- หลังการเชื่อมต่อพุ่ง มีหลายนาทีที่เพิ่มขึ้นเฉพาะจำนวนเป้าหมายและอินสแตนซ์ที่กำลังเตรียม ขณะที่ CPU ของเซิร์ฟเวอร์เดิมชนเพดาน แล้วอาการคลายลงตั้งแต่ตอนที่จำนวนอินสแตนซ์ที่ให้บริการเพิ่มขึ้น
- สัญญาณว่าไม่ใช่
- อินสแตนซ์ใหม่เข้ามาแล้วยังช้า: น่าจะเป็นสาเหตุที่ไม่เกี่ยวกับจำนวนเซิร์ฟเวอร์ (ทรัพยากรที่ใช้ร่วมกันอย่าง DB, ความล้มเหลวแบบลูกโซ่)
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
- รายละเอียดเพิ่มเติม
- autoscaling มักใช้กับส่วนที่แค่ให้เซิร์ฟเวอร์ใหม่รับคนใหม่ก็พอ เช่น ล็อกอิน, เกตเวย์ และดันเจี้ยน ตอนลดเครื่องก็เกิดปัญหาได้ ถ้าลดเซิร์ฟเวอร์ตอนเช้ามืดที่คนบางตาแล้วปิดเลยโดยไม่รอคนที่เหลือออก คนเหล่านั้นจะหลุด
- กรณีจริง
- AWS 2021: เครือข่ายภายในของ AWS us-east-1 แออัด
AWS 2025: DNS ของ DynamoDB ใน AWS us-east-1 ขัดข้อง และการกู้คืนที่ยืดเยื้อ
แหล่งอ้างอิง
- Target tracking scaling policies for Amazon EC2 Auto Scaling AWS
เมตริกพื้นฐานของ EC2 มีช่วงห่าง 5 นาที (เปิด detailed monitoring จะเป็น 1 นาที) ถ้าต้องการตอบสนองเร็ว แนะนำเมตริกที่มีช่วงห่างไม่เกิน 1 นาที - Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS
group metrics ต้องเปิดก่อนจึงเผยแพร่ทุก 1 นาที, GroupDesiredCapacity (จำนวนที่ต้องการรักษาไว้), GroupPendingInstances (จำนวนอินสแตนซ์ที่ยังไม่เริ่มให้บริการ), GroupInServiceInstances (จำนวนอินสแตนซ์ที่กำลังให้บริการ) - Scheduled scaling for Amazon EC2 Auto Scaling AWS
เพิ่มและลด capacity ล่วงหน้าตามเวลาที่กำหนด ให้ตรงกับการเปลี่ยนแปลงของโหลดที่คาดการณ์ได้ - Decrease latency for applications with long boot times using warm pools AWS
แอปที่บูตนานใช้ pool ของอินสแตนซ์ที่ initialize ไว้ล่วงหน้า (warm pool) เพื่อลดเวลาที่ใช้ขยาย
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง