คู่มือเกมแลค › L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
การ deploy และรีสตาร์ต Deploy / rolling restart
ID สาเหตุ in-deploy · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้ารีสตาร์ตเซิร์ฟเวอร์เพื่ออัปเดตโดยไม่ย้ายการเชื่อมต่อ ผู้เล่นที่อยู่บนเซิร์ฟเวอร์นั้นจะหลุด และการบันทึกข้อมูลก่อนปิดกับการเชื่อมต่อใหม่จะทะลักเข้ามาพร้อมกัน
ทำไม deploy hotfix โดยรีสตาร์ตเซิร์ฟเวอร์ทีละเครื่องตามลำดับ → ผลคือ ปิดเซิร์ฟเวอร์โดยไม่ย้ายการเชื่อมต่อไปเซิร์ฟเวอร์อื่น การบันทึกของผู้เล่นทุกคนบนเซิร์ฟเวอร์นั้นจึงไปกองที่ DB → บนหน้าจอ หลุดโดยไม่มีประกาศ, คนแห่เชื่อมต่อใหม่
- อาการ
- หลุด, เข้าเกมไม่ได้/โหลดไม่จบ, อินพุตดีเลย์
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์, บางจุด/บางแชนแนล
- เกิดเมื่อไร
- สุ่มเป็นครั้งคราว, หลังล็อกอิน/หลังปิดปรับปรุง
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- ทำฟีเจอร์ drain (กันเฉพาะการเชื่อมต่อใหม่ แล้วรอจนคนเดิมออกไป), ย้ายตัวละครไปเซิร์ฟเวอร์อื่น, ทยอยบันทึกก่อนปิด, หลังรีสตาร์ตให้โหลดแคชและ JIT warm-up ให้เสร็จก่อนแจ้งว่าพร้อม, hot reload ให้อ่านไว้ล่วงหน้าในเธรดแยกแล้วสลับทีเดียวระหว่างทิก
- งานฝั่งทีมอินฟรา
- ให้เครื่องมือ deploy รอ drain ทีละเครื่องก่อนรีสตาร์ต, ให้เซิร์ฟเวอร์ที่รีสตาร์ตแล้วรับทราฟฟิกหลังยืนยันว่าพร้อม (warm-up เสร็จ), ประกาศเวลา deploy
- ตัวเลขที่ควรรู้
- ถ้าเซิร์ฟเวอร์หนึ่งเครื่องมี 5,000 คน ในไม่กี่วินาทีก่อนปิดจะมีการบันทึก 5,000 รายการพุ่งเข้า DB พร้อมกัน
- บนกราฟ
- การเชื่อมต่อหลุดพร้อมกัน · จำนวนการเชื่อมต่อแยกตามเซิร์ฟเวอร์, จำนวนการเขียน DB
- จุดที่ต้องดู
- วางประวัติงานของเครื่องมือ deploy (เวลารีสตาร์ตของแต่ละเซิร์ฟเวอร์) เป็นเส้นแนวตั้ง (annotation) บนกราฟจำนวนการเชื่อมต่อ, จำนวนการหลุด, การเขียน DB และคำขอล็อกอิน
- สัญญาณว่าใช่
- จำนวนการเชื่อมต่อของแต่ละเซิร์ฟเวอร์ดิ่งลงทีละเครื่องตามเวลารีสตาร์ต การเขียน DB พุ่งก่อนหน้านั้น และคำขอล็อกอินพุ่งหลังจากนั้น
- สัญญาณว่าไม่ใช่
- เวลาที่หลุดไม่ตรงกับประวัติ deploy หรือรีสตาร์ต: น่าจะเป็นเซิร์ฟเวอร์แครชหรืออุปกรณ์เครือข่าย
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
- รายละเอียดเพิ่มเติม
- ช่วงไม่กี่นาทีหลังเปิดใหม่ก็ยังช้า เพราะแคชว่างจึงมีการอ่าน DB ทะลักเข้ามา และเซิร์ฟเวอร์ Java หรือ C# ยังไม่เสร็จขั้นตอน optimize โค้ดระหว่างรัน (JIT warm-up) งานเดิมจึงใช้เวลามากขึ้น การโหลดสคริปต์หรือตารางข้อมูลใหม่โดยไม่ปิดเซิร์ฟเวอร์ (hot reload) ก็ทำให้ทิกหยุดระหว่างอ่าน จึงเกิดการหยุดสั้น ๆ
แหล่งอ้างอิง
- Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
เซิร์ฟเวอร์ที่ได้รับ SIGTERM เข้าสถานะ lame duck ส่งคำขอใหม่ไปเซิร์ฟเวอร์อื่นและทำเฉพาะคำขอที่กำลังทำอยู่ให้เสร็จ, ช่วงไม่กี่นาทีหลังรีสตาร์ตยังไม่ผ่าน JIT optimization จึงใช้ทรัพยากรมากกว่า ให้ warm-up ก่อนแล้วค่อยรับทราฟฟิก - Liveness, Readiness, and Startup Probes Kubernetes
ใช้ readiness check ไม่ส่งทราฟฟิกมาจนกว่าการสร้างการเชื่อมต่อ, การโหลดไฟล์ และการ warm-up แคชจะเสร็จ - Edit target group attributes for your Network Load Balancer AWS
เมื่อ deregister target จะไม่ส่งการเชื่อมต่อใหม่ไปให้ และ drain การเชื่อมต่อเดิม (ค่าเริ่มต้น 300 วินาที)
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (หลุด)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง