คู่มือเกมแลค › L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
การผ่านเกตเวย์/พร็อกซี Gateway / proxy hop
ID สาเหตุ in-gateway · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าวางเซิร์ฟเวอร์คั่นกลางระหว่างไคลเอนต์กับเซิร์ฟเวอร์เกม ทุกครั้งที่ผ่านจะมีเวลาประมวลผลเพิ่มขึ้น และเซิร์ฟเวอร์ตัวนั้นจะกลายเป็น single point of failure (จุดเดียวที่ล่มแล้วกระทบทั้งระบบ)
ทำไม โครงสร้างแบบ ไคลเอนต์ ↔ เกตเวย์ ↔ เซิร์ฟเวอร์เกม → ผลคือ มีเวลาประมวลผลและเวลารอที่เซิร์ฟเวอร์คั่นกลางเพิ่มเข้ามา ถ้าโหลดเกินจะกระทบทุกคน → บนหน้าจอ ปิงสูงขึ้นทั้งหมด ถ้าเกตเวย์ล่ม ผู้เล่นทุกคนที่ผ่านเกตเวย์นั้นหลุด
อาการ อินพุตดีเลย์ , หลุด ปัจจัย ความหน่วง, การหยุดชะงัก
ใครเจอ ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร ตอนคนแห่มารวมกัน, ตลอดเวลา
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม เซิร์ฟเวอร์: ออกแบบให้เพิ่มเกตเวย์เป็นหลายเครื่องได้, ออกแบบให้เมื่อเกตเวย์ล่มแล้วต่อเข้าเกตเวย์อื่นใหม่ ตัวละครยังอยู่ต่อจากเดิม (เชื่อมต่อเซสชันใหม่) ไคลเอนต์: เชื่อมต่อใหม่อัตโนมัติเมื่อเกตเวย์หลุด
งานฝั่งทีมอินฟรา ขยายเกตเวย์แนวนอน (เพิ่มจำนวนเครื่อง), มอนิเตอร์ CPU, จำนวนการเชื่อมต่อ และดีเลย์การประมวลผลของเกตเวย์แต่ละตัว
ตัวเลขที่ควรรู้ เพราะอยู่ในดาต้าเซ็นเตอร์เดียวกัน ปกติการผ่านแต่ละครั้งใช้เวลาไม่ถึง 1 ms แต่ถ้าเกตเวย์โหลดเกินจะเพิ่มเป็นหลายสิบถึงหลายร้อย ms
บนกราฟ จุดที่ต้องดู CPU และจำนวนการเชื่อมต่อของเกตเวย์ กับ Recv-Q ของซ็อกเก็ตบนเกตเวย์ (ss, netstat), ส่วนต่างของดีเลย์ก่อนและหลังผ่านเกตเวย์ ถ้าเป็นการเรียก HTTP/gRPC ที่ผ่าน service mesh ให้เทียบเมตริกมาตรฐานของ Istio istio_request_duration_milliseconds แยกฝั่งผู้ส่ง (reporter=source) กับฝั่งผู้รับ (reporter=destination) สัญญาณว่าใช่ เวลาประมวลผลของเซิร์ฟเวอร์เกมเท่าเดิม แต่ดีเลย์ช่วงเกตเวย์เพิ่มขึ้นอย่างเดียว และช่วงนั้น CPU ของเกตเวย์อิ่มตัวหรือ Recv-Q สะสม สัญญาณว่าไม่ใช่ เส้นทางที่ไม่ผ่านเกตเวย์ (ต่อตรง, เกตเวย์อื่น) ก็ช้าเท่ากัน: น่าจะเป็นที่เครือข่ายหรือเซิร์ฟเวอร์เกม วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม ถ้าใช้ service mesh (เช่น Istio) sidecar proxy (Envoy) ที่ติดอยู่ข้างเซิร์ฟเวอร์ทุกตัวจะเพิ่มเข้ามาอีกหนึ่งขั้น คำขอระหว่างเซอร์วิสต้องผ่าน sidecar ฝั่งผู้ส่งแล้วจึงผ่าน sidecar ฝั่งผู้รับ และยิ่งเพิ่มฟีเจอร์ให้พร็อกซี เช่น การเก็บ log และเมตริก เวลาประมวลผลและเวลารอก็ยิ่งเพิ่มขึ้น
กรณีจริง Riot Games 2020: โฮสต์ edge ของเซิร์ฟเวอร์ League of Legends ยุโรปและบราซิลโหลดเกิน
แหล่งอ้างอิง The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS New World ให้ไคลเอนต์เชื่อมต่อเข้าเซิร์ฟเวอร์ทางเข้า (REP) ที่มี public IP ตัวใดตัวหนึ่งจาก 4 ตัว แล้วจึงสื่อสารกับเซิร์ฟเวอร์ simulation (hub) ที่อยู่ด้านหลัง Designs, Lessons and Advice from Building Large Distributed Systems Google keynote ในงาน LADIS 2009 (Jeff Dean) เวลาไปกลับภายในดาต้าเซ็นเตอร์เดียวกันประมาณ 0.5 ms Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google ถ้าคิวยาวขึ้นเพราะโหลดเกิน เวลารอจะเพิ่มเป็นหลายเท่าของเวลาประมวลผล (ประมวลผล 100 ms และคิวยาว 10 เท่าของจำนวนเธรด จะเป็น 1.1 วินาที) Performance and Scalability Istio ในโหมด sidecar คำขอผ่าน sidecar proxy ฝั่งผู้ส่งแล้วจึงผ่านฝั่งผู้รับ, ยิ่งเพิ่มฟีเจอร์ เส้นทางประมวลผลในพร็อกซียิ่งยาว และการเก็บ telemetry ทำให้คำขอถัดไปต้องรอนานขึ้น What is Envoy Envoy Envoy เป็นโปรเซสแยกที่รันข้างแอปพลิเคชันเซิร์ฟเวอร์ทุกตัว และแอปรับส่งข้อมูลผ่าน Envoy บน localhost Istio Standard Metrics Istio istio_request_duration_milliseconds (การกระจายของเวลาประมวลผลคำขอ HTTP/gRPC), ใช้ label reporter แยกพร็อกซีฝั่งผู้ส่ง (source) กับฝั่งผู้รับ (destination) netstat(8) — Linux manual page net-tools Recv-Q: จำนวนไบต์ในซ็อกเก็ตที่เชื่อมต่อแล้วที่โปรแกรมของผู้ใช้ยังไม่ได้ดึงไป สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง