คู่มือเกมแลค › L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

โหลดบาลานเซอร์กระจายไม่เท่ากัน/health check ตัดสินผิด LB imbalance, bad health checks

ID สาเหตุ dc-lb-imbalance · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

การเชื่อมต่อไปกองที่เซิร์ฟเวอร์เครื่องเดียว หรือยังส่งคนไปเซิร์ฟเวอร์ที่ตายแล้วอยู่เรื่อย ๆ

ทำไม กฎการกระจายไม่เหมาะ หรือ health check มองไม่เห็นสถานะจริง → ผลคือ เซิร์ฟเวอร์เครื่องเดียวโหลดเกิน หรือพยายามเชื่อมต่อไปเซิร์ฟเวอร์ที่ตายแล้ว → บนหน้าจอ เฉพาะบางแชนแนลหรือบางคนที่เป็นสโลว์โมชั่น, เข้าเกมไม่ได้หรือโหลดไม่จบ

อาการ

สโลว์โมชั่น, เข้าเกมไม่ได้/โหลดไม่จบ

ปัจจัย

การหยุดชะงัก, แพ็กเก็ตหาย

ใครเจอ

บางจุด/บางแชนแนล

เกิดเมื่อไร

หลังล็อกอิน/หลังปิดปรับปรุง, ตอนคนแห่มารวมกัน

ผู้รับผิดชอบ

ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

งานฝั่งทีมพัฒนาเกม

ทำ health check ที่ตอบคำขอตรวจของโหลดบาลานเซอร์ตามสถานะเกมจริง (ทิกยังเดิน, การเชื่อมต่อ DB), ส่งค่าโหลดของเซิร์ฟเวอร์ไปด้วย

งานฝั่งทีมอินฟรา

เปลี่ยน health check เป็นแบบที่ตรวจการตอบสนองจริงของเกม, กระจายโหลดตามโหลดของเซิร์ฟเวอร์, มอนิเตอร์ความต่างของจำนวนการเชื่อมต่อในแต่ละเซิร์ฟเวอร์

บนกราฟ

สูงเฉพาะบางกลุ่ม · จำนวนการเชื่อมต่อ/อัตราการใช้ CPU แยกตามเซิร์ฟเวอร์

จุดที่ต้องดู

ซ้อนจำนวนการเชื่อมต่อ (ss -s) และอัตราการใช้ CPU ของแต่ละเซิร์ฟเวอร์หลังโหลดบาลานเซอร์ไว้ในกราฟเดียว แล้วเทียบสถานะ health ของ target ในโหลดบาลานเซอร์ (AWS ดู HealthyHostCount และ UnHealthyHostCount ใน CloudWatch) กับสถานะจริงของเซิร์ฟเวอร์เกม

สัญญาณว่าใช่

มีเซิร์ฟเวอร์หนึ่งหรือสองเครื่องที่จำนวนการเชื่อมต่อและ CPU สูงกว่าเครื่องอื่นมาก หรือเซิร์ฟเวอร์ที่ทิกหยุดไปแล้วยังมีสถานะ health เป็น “healthy” และยังรับการเชื่อมต่อใหม่อยู่เรื่อย ๆ

สัญญาณว่าไม่ใช่

ถ้าจำนวนการเชื่อมต่อแต่ละเซิร์ฟเวอร์เท่า ๆ กันแต่ช้าเฉพาะแชนแนลเดียว น่าจะเป็นโหลดภายในแชนแนลนั้น (“พื้นที่ที่รันบนเธรดเดียวโหลดเกิน (hotspot)”)

วิธีตรวจ

ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)

กรณีจริง

AWS 2025: DNS ของ DynamoDB ใน AWS us-east-1 ขัดข้อง และการกู้คืนที่ยืดเยื้อ

แหล่งอ้างอิง

1. Load Balancing in the Datacenter Google
   round robin แบบธรรมดาทำให้การใช้ CPU ระหว่างงานต่างกันได้ถึง 2 เท่า, การกระจายแบบถ่วงน้ำหนักที่ backend ส่งค่าโหลดมากับการตอบกลับและ health check, สถานะ lame duck ที่บอกว่าจะไม่รับคำขอเพิ่ม
2. Health checks for Network Load Balancer target groups AWS
   ค่าเริ่มต้นของ health check คือทุก 30 วินาที และถ้าล้มเหลว 2 ครั้งจะถูกถอดออก, บริการ UDP ตรวจด้วย health check แบบ TCP หรือ HTTP จึงแนะนำให้ตั้งค่าให้สะท้อนสถานะจริงของบริการ
3. CloudWatch metrics for your Network Load Balancer AWS
   HealthyHostCount และ UnHealthyHostCount: จำนวน target ที่ถูกตัดสินว่าปกติและผิดปกติ

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

• ตารางเซสชันของไฟร์วอลล์เต็ม
• การอ้อมผ่านระบบป้องกัน DDoS และ false positive
• idle timeout ของโหลดบาลานเซอร์
• connection tracking ของ security group บนคลาวด์หมดอายุ
• ขีดจำกัดการเชื่อมต่อ/พอร์ตของ NAT gateway บนคลาวด์
• microburst ที่สวิตช์
• ลิงก์ของดาต้าเซ็นเตอร์เต็ม
• การ failover ของอุปกรณ์เครือข่าย
• สายเสีย/พอร์ตมี error
• MTU ไม่ตรงกัน (เฉพาะแพ็กเก็ตใหญ่ที่หาย)

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)

• fixed timestep ไล่ตามไม่ทันจนบานปลาย L1 โปรเซสเกมฝั่งไคลเอนต์
• เธรดมากเกินไปและ context switch L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• CPU throttling ของคอนเทนเนอร์ (CFS quota) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• ความหน่วงพุ่งจากการจัดการพลังงานของเซิร์ฟเวอร์ (C-state/การปรับความถี่) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• งานตามกำหนดเวลา (scheduled job) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• ประสิทธิภาพเปลี่ยนไปหลังอัปเดต OS/เคอร์เนล/ไดรเวอร์/เฟิร์มแวร์ L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• การส่งแบบ blocking เพราะไคลเอนต์ช้า L8 ซ็อกเก็ตและโปรโตคอล
• โครงสร้างแบบ blocking I/O L8 ซ็อกเก็ตและโปรโตคอล

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง