การตรวจสอบการสูญเสียแพ็กเก็ตเครือข่ายและความหน่วงบนคลาวด์ Roblox

ทีมวิศวกรรมเครือข่ายของ Roblox ดูแลเครือข่ายขนาดใหญ่ที่เติบโตอย่างรวดเร็ว โดยมีศูนย์ข้อมูลและจุดเชื่อมต่อ (POP) กระจายอยู่ทั่วโลก การมอบประสบการณ์ที่ยอดเยี่ยมให้กับผู้ใช้บนแพลตฟอร์ม Roblox ขึ้นอยู่กับความสามารถในการทำงานและเสถียรภาพของเครือข่ายนี้ การที่ผู้ดูแลเครือข่ายสามารถแก้ไขปัญหาและตรวจจับปัญหาในเครือข่าย รวมถึงการมองเห็นประสิทธิภาพของเครือข่ายได้ ถือเป็นสิ่งสำคัญอย่างยิ่ง การตรวจสอบเครือข่ายโดยทั่วไปจะดำเนินการโดยการเก็บรวบรวมสถิติของอุปกรณ์, ตัวชี้วัดข้อผิดพลาด, และบันทึกระบบ (syslogs) เป็นระยะ ๆ และจัดเก็บไว้ในฐานข้อมูลแบบลำดับเวลา (time series) หรือฐานข้อมูลบันทึก (log database) ข้อมูลจะถูกเก็บรวบรวมโดยใช้แบบจำลองการส่งข้อมูล (push) หรือการดึงข้อมูล (pull) โดยใช้โปรโตคอลมาตรฐานเช่น SNMP, Netconf, Rest APIs, หรือ Streaming Telemetry

การตรวจจับข้อผิดพลาดของเครือข่ายผ่านเทเลเมทริกซ์ของอุปกรณ์เพียงอย่างเดียวมีข้อบกพร่องหลายประการ เนื่องจากเป็นเทคนิคการตรวจสอบแบบพาสซีฟ ขึ้นอยู่กับความสามารถของโหนดเครือข่ายในการระบุและรายงานสถานการณ์ผิดปกติทันทีที่เกิดขึ้น อุปกรณ์อาจไม่รายงานข้อมูลกลับมาเสมอไป หรือในบางกรณีอาจไม่มีการเปิดเผยสถิติสุขภาพทั้งหมดให้กับวิธีการเก็บรวบรวมเทเลเมทริกซ์ตามปกติ นอกจากนี้ อุปกรณ์เครือข่ายอาจให้ข้อมูลที่ผิดพลาดหรือบล็อกทราฟฟิกโดยไม่แจ้งให้ทราบล่วงหน้า ข้อจำกัดหลักของการวัดระยะไกลของอุปกรณ์คือมันให้ข้อมูลที่น้อยมากเกี่ยวกับการเข้าถึงแบบปลายทางถึงปลายทาง, การสูญเสียแพ็กเก็ต, และสถิติความหน่วงของเครือข่าย

วิธีที่ยอดเยี่ยมในการตรวจสอบเครือข่ายอย่างสม่ำเสมอคือการส่งสัญญาณทดสอบที่สังเคราะห์ขึ้นเป็นประจำผ่านเมชตามที่แสดงในภาพด้านล่าง

ในขณะที่กำลังแก้ไขปัญหาการหยุดชะงักของการผลิต ผู้ปฏิบัติการเครือข่ายมักถูกถามคำถามเช่น "เครือข่ายกำลังทิ้งแพ็กเก็ตหรือไม่?" หรือ "มีข้อผิดพลาดของเครือข่ายที่กำลังส่งผลกระทบต่อการเชื่อมต่อบริการอยู่หรือไม่?" เพื่อที่จะตอบคำถามประเภทนี้โดยไม่มีข้อมูลการสูญเสียแพ็กเก็ตและความล่าช้าในอดีต พวกเขาจำเป็นต้องตรวจสอบชุดลิงก์และโหนดจำนวนมากภายในเครือข่าย

การออกแบบระบบตรวจสอบเครือข่ายแบบเมชที่เชื่อถือได้และขยายขนาดได้

เพื่อให้ระบบตรวจสอบเครือข่ายแบบกล่องดำมีประสิทธิภาพในการตรวจจับการสูญเสียแพ็กเก็ตหรือการเพิ่มขึ้นของความหน่วงเวลา จำเป็นต้องมีการตรวจสอบอย่างต่อเนื่องในส่วนต่าง ๆ ของเครือข่าย ศูนย์ข้อมูลใช้ลิงก์ทั้งหมดระหว่างโหนดสำหรับการจราจรของผู้ใช้ อุปกรณ์เครือข่ายในเครือข่ายการผลิตจะทำงานด้วย BGP และกระจายการจราจรผ่านเส้นทางที่มีค่าใช้จ่ายเท่ากันหลายเส้นทาง การเปลี่ยนแปลงในโครงสร้างเครือข่ายมักจะสะท้อนให้เห็นภายในไม่กี่วินาทีโดยการอัปเดตตารางเส้นทางภายใต้สถานการณ์ปกติ เพื่อให้ได้การวัดการสูญเสียแพ็กเก็ตเครือข่ายที่แม่นยำ การทดสอบควรทำการตรวจสอบผ่านเส้นทางให้มากที่สุดเท่าที่จะเป็นไปได้ ครอบคลุมทุกโหนดและลิงก์ในเครือข่าย ด้วยเครือข่ายขนาดใหญ่เช่นของเรา ที่ครอบคลุมหลายไซต์ทั่วโลก การตรวจสอบระหว่างทุกคู่ของโหนดหรือแร็คไม่สามารถทำได้ในเชิงขนาด ทางออกที่ยั่งยืนกว่าที่เราเลือก ซึ่งไม่ลดระดับการมองเห็น คือการตรวจสอบแบบเมช N² ภายในแต่ละไซต์พร้อมกับเมช N² อีกชุดหนึ่งข้ามทุกไซต์

เราใช้สิ่งใดในการตรวจสอบเครือข่าย?

หัววัดทดสอบควรจำลองการจราจรจริงที่ผ่านเครือข่ายการผลิต การจราจรส่วนใหญ่บนเครือข่ายของเราเป็น TCP, UDP หรือ HTTP และแต่ละประเภทนี้อาจถูกใช้สำหรับการทดสอบได้ หนึ่งในปัญหาของการทดสอบ TCP คือมันไม่เบามากพอที่จะขยายตัวตามจำนวนการเชื่อมต่อที่จำเป็นสำหรับการตรวจสอบเครือข่ายขนาดใหญ่ อีกปัญหาหนึ่งของ TCP คือการควบคุมการไหลและการส่งข้อมูลแบบหน้าต่างเลื่อนที่มีอยู่ในตัว ซึ่งส่งผลให้อัตราการส่งข้อมูลของโพรบมีความแปรปรวน ซึ่งไม่เหมาะสำหรับการวัดหรือตรวจจับการสูญเสียแพ็กเก็ตชั่วขณะ ICMP ซึ่งใช้โดยคำสั่ง ping และ traceroute มักจะถูกจำกัดอัตราบนเซิร์ฟเวอร์หรือโหนดเครือข่าย ซึ่งจะทำให้อัตราการส่งโพรบ ICMP รวมสูงสุดที่สามารถใช้ได้ถูกจำกัด คำขอ HTTP อยู่ในชั้นแอปพลิเคชันที่สูงขึ้นและขึ้นอยู่กับปัจจัยบางอย่างภายนอกเครือข่าย เช่น ประสิทธิภาพของเซิร์ฟเวอร์หรือแอปพลิเคชัน HTTP เพิ่มตัวแปรพิเศษให้กับผลลัพธ์ที่ยากต่อการแยกออก เป้าหมายของระบบนี้คือการตรวจสอบประสิทธิภาพของโครงสร้างพื้นฐานเครือข่ายที่อยู่เบื้องหลังซึ่งทำงานหลักที่ชั้น OSI 4 และต่ำกว่า เราเลือกใช้การตรวจสอบแบบ UDP ด้วยเหตุผลเหล่านี้ รวมถึงเป็นโปรโตคอลชั้นการขนส่งหลักบนเครือข่ายของเรา

เราจะตรวจสอบจากที่ไหน?

วิธีหนึ่งในการบรรลุอัตราการตรวจสอบแบบรวมที่สูงและครอบคลุมเส้นทางเครือข่ายจำนวนมากคือการใช้โหนดคอมพิวต์ให้มากที่สุดเท่าที่จะเป็นไปได้ในการส่งการตรวจสอบ ซึ่งมีข้อดีสองประการ: ช่วยกระจายภาระงานในระบบที่กำลังสร้างการตรวจสอบ และขยายจำนวนพอร์ตเครือข่ายที่รองรับการตรวจสอบ อย่างไรก็ตาม วิธีนี้ต้องการเอเจนต์ที่มีความเสถียรสูงและใช้ทรัพยากรของระบบโฮสต์ให้น้อยที่สุดเท่าที่จะเป็นไปได้ ในขณะเดียวกัน เอเจนต์ควรมีความสามารถในการวัดการสูญเสียแพ็กเก็ตและความหน่วงเวลาบนเส้นทางหลายเส้นทางได้อย่างแม่นยำ โดยไม่ได้รับผลกระทบจากการใช้งาน CPU, หน่วยความจำ หรือการเปลี่ยนแปลงของ I/O บนระบบโฮสต์ เอเจนต์ต้องรักษาสมดุลที่ละเอียดอ่อนนี้อย่างต่อเนื่องระหว่างการเป็นซอฟต์แวร์ที่มีน้ำหนักเบาและประสิทธิภาพสูง

เราจะวัดการสูญเสียเครือข่ายและความหน่วงได้อย่างไร?

อาจดูเหมือนเป็นการคำนวณที่เล็กน้อยสำหรับข้อมูลการตรวจสอบเพียงชุดเดียว อย่างไรก็ตาม มีความท้าทายบางประการที่เกิดขึ้นเมื่อขยายขนาดซึ่งอาจไม่ชัดเจนในทันที ในการขยายขนาดไปยังตาข่ายขนาดใหญ่เช่นนี้ ตัวแทนจำเป็นต้องคำนวณจำนวนแพ็กเก็ตที่ส่ง (Tx) และรับ (Rx) อย่างรวดเร็วและแม่นยำพร้อมเวลาประทับตราบนหลายสตรีมพร้อมกัน สิ่งสำคัญคือการวัดค่าการสูญเสียเครือข่ายต้องไม่รวมแพ็กเก็ตที่สูญหายที่โฮสต์ซึ่งรันเอเจนต์เมื่อ CPU ของมันยุ่งหรือบัฟเฟอร์เครือข่ายล้น ความหน่วงของเครือข่ายต้องคำนวณด้วยเวลาทั้งหมดที่โพรบอยู่บนสายหรือโหนดเครือข่ายกลาง โดยไม่รวมเวลาที่ใช้รอในบัฟเฟอร์ I/O และกระบวนการของเอเจนต์ที่รอการกำหนดเวลาจากระบบปฏิบัติการ

ระบบ Ping Mesh ของ Roblox

ความต้องการในการตรวจสอบการสูญเสียและค่าความหน่วงของเครือข่ายแบบกล่องดำมีมาตั้งแต่การเติบโตของโครงสร้างพื้นฐานคลาวด์สาธารณะและส่วนตัว การหาโซลูชันสำเร็จรูปที่สามารถขยายขนาดได้กับเครือข่ายขนาดใหญ่ของเราพิสูจน์แล้วว่าเป็นเรื่องยาก ผู้ให้บริการคลาวด์รายใหญ่และผู้ให้บริการเครื่องมือเครือข่ายหลายรายได้ออกแบบโซลูชันของตนเองเพื่อตรวจสอบการสูญเสียและค่าความหน่วงของเครือข่าย เราได้ทดลองใช้เครื่องมือที่เปิดเผยต่อสาธารณะบางตัว แต่พบปัญหาเกี่ยวกับความเสถียรและความสามารถในการขยายระบบ ขณะที่สามารถมองเห็นประสิทธิภาพของเครือข่ายได้เพียงจำกัดเท่านั้น สิ่งนี้ทำให้เราตัดสินใจสร้างระบบตรวจสอบแบบเมชของเราเอง ซึ่งช่วยให้สามารถตรวจจับข้อผิดพลาดที่เกิดขึ้นน้อยได้ดียิ่งขึ้นโดยมีค่าใช้จ่ายต่ำ หนึ่งในคุณสมบัติเด่นของระบบของเราคือ:

• เราเลือกใช้ Go ในการพัฒนาทุกส่วนประกอบของระบบของเรา ซึ่งช่วยให้สามารถบรรลุประสิทธิภาพในระดับสูงในขณะที่ใช้ทรัพยากรของระบบน้อยที่สุด
• ตัวแทนของเราเสถียรสูงและสามารถทำงานบนโฮสต์การผลิตที่หลากหลาย รวมถึงโฮสต์ที่ให้บริการสำคัญบนแพลตฟอร์ม Roblox เช่น การจัดการทราฟฟิก การแคช และเซิร์ฟเวอร์แอปพลิเคชัน
• เอเจนต์ได้รับการปรับให้เหมาะสมเพื่อดำเนินการ I/O ของแพ็กเก็ตเป็นชุดด้วยฟังก์ชัน Go wrapper ผ่านระบบเรียกใช้ sendmmsg() และ recvmmsg() ของ Linux ซึ่งช่วยให้สามารถส่งการตรวจสอบในอัตราสูงด้วยค่าใช้จ่ายต่ำ เอเจนต์ทุกตัวในการใช้งานของเราจะส่งการตรวจสอบไปยังโฮสต์อื่นสูงสุด 100 เครื่องพร้อมกัน ด้วยอัตรา 100 แพ็กเก็ตต่อวินาที (PPS) เอเจนต์จะส่งแพ็กเก็ตเป็นชุดทุกวินาทีไปยังแต่ละปลายทาง
• โพรบจะนำค่าฟิลด์ประเภทการให้บริการ (TOS) ที่แตกต่างกันในเฮดเดอร์ IP ไปยังปลายทางแต่ละแห่ง และจะถูกนับแยกกันสำหรับการสูญเสียแพ็กเก็ตและความล่าช้าในเครือข่าย แต่ละชุดของแพ็กเก็ตที่ส่งออกไปจะประกอบด้วยค่า TOS หลายค่าผสมกันไปยังปลายทางอื่น ๆ ทั้งหมด วิธีนี้ช่วยให้สามารถตรวจสอบประสิทธิภาพของเครือข่ายสำหรับแต่ละคลาสคุณภาพการให้บริการ (QoS) ได้อย่างมีประสิทธิภาพ
• ตัวแทนสามารถตรวจจับการหลุดของเครือข่ายได้ต่ำถึง 1 ใน 6000 แพ็กเก็ตต่อนาทีบนแต่ละเส้นทางของโพรบ แพ็กเก็ตที่สูญหายภายในแกนหลักหรือขอบของเครือข่ายที่มีระยะเวลาต่ำกว่า 1 วินาทีสามารถตรวจจับได้ เช่นที่เกิดขึ้นระหว่างการสลับสถานะ BGP
• กราฟการสูญเสียแพ็กเก็ตจากการตรวจสอบเลียนแบบกราฟอัตราการเกิดข้อผิดพลาดของอินเทอร์เฟซอุปกรณ์เครือข่ายเมื่อข้อผิดพลาดเป็นสาเหตุของการสูญเสียแพ็กเก็ต เราสามารถค้นพบข้อบกพร่องที่ทำให้เกิดการสูญหายของทราฟฟิกในเครือข่ายซึ่งยากต่อการตรวจพบ
• ตัวแทนใช้การอ่านเวลาประทับของนิวเคลียส NIC เพื่อให้ได้ความแม่นยำสูงในการวัดความหน่วงของเครือข่าย สามารถวัดความหน่วงของการเดินทางรอบในไซต์เดียวกันที่สม่ำเสมอได้ในช่วง 50–100 ไมโครวินาที โดยไม่รวมความหน่วงจากการจัดตารางเวลาของระบบปฏิบัติการโฮสต์และการคลาดเคลื่อนของนาฬิกาเครือข่าย
• การใช้ CPU และหน่วยความจำต่ำ ตัวเอเจนต์ใช้ทรัพยากรน้อยกว่า 25% ของคอร์เดียวในอัตราสูงสุดของการส่งและรับข้อมูล (5 kpps ต่อการรับส่งแต่ละประเภท) ตัวเอเจนต์ส่วนใหญ่ที่ใช้งานจริงใช้เพียงประมาณ 5% ของคอร์เท่านั้น ต้องการหน่วยความจำฮีปเพียง 10MB สำหรับจัดการบัฟเฟอร์และตัวนับแพ็กเก็ต Tx และ Rx ของตัวเอเจนต์ เมื่อเครือข่ายขยายตัว เราสามารถปรับขนาดได้ทั้งในแนวตั้งหรือแนวนอนโดยการปรับค่าขีดจำกัดหรือเพิ่มจำนวนตัวเอเจนต์
• ตัวแทนมักไม่ได้รับผลกระทบเมื่อระบบโฮสต์อยู่ภายใต้ความเครียด เราได้รับผลลัพธ์ที่แม่นยำแม้ในกรณีที่โหลด CPU ของโฮสต์เข้าใกล้ 99% หลายครั้ง
• ข้อมูลการวัดระยะไกลถูกเก็บรวบรวมจากแต่ละเอเจนต์เพื่อตรวจสอบสถานะการทำงานของเอเจนต์เหล่านั้น เอเจนต์สามารถระบุสถานการณ์ที่มีปัญหาได้ เช่น เมื่อระบบโฮสต์รีบูต เมื่อกระบวนการของเอเจนต์เริ่มต้นใหม่ หรือเมื่อแพ็กเก็ตสูญหายเนื่องจากบัฟเฟอร์ของซ็อกเก็ตเต็ม

ตัวแทนถูกนำไปใช้กับ Chef บนเซิร์ฟเวอร์คลัสเตอร์หลากหลายชุดเพื่อรักษาจำนวนโหนดที่สูงในการเข้าร่วมการตรวจสอบเครือข่าย ตัวแทนไบนารีถูกเรียกใช้และจัดการด้วย systemd บน Linux เพื่อให้สามารถเริ่มต้นใหม่โดยอัตโนมัติหลังจากการรีบูตโฮสต์หรือการอัปเกรดตัวแทน ตัวจัดการตารางเวลาแบบเมชจะตรวจจับและปรับสตรีมแบบไดนามิกตามความจำเป็นเมื่อตัวแทนใดตัวแทนหนึ่งล่มหรือมีตัวแทนใหม่เพิ่มขึ้น แอปพลิเคชันกำหนดตารางเวลาของเราจะทำการสำรวจข้อมูลอุปกรณ์และระบบค้นหาบริการเป็นระยะ เพื่อตรวจจับตัวแทนใหม่และสถานะสุขภาพของเซิร์ฟเวอร์ ก่อนที่จะจัดสรรเป้าหมายสำหรับการตรวจสอบภายในพอด (Intra-Pod), ภายในไซต์ (Intra-Site) และระหว่างไซต์ (Inter-Site) บัสข้อความถูกใช้เพื่อสื่อสารรายการโฮสต์เป้าหมายไปยังเอเจนต์แต่ละตัวที่กำลังส่งโปรบทดสอบ สตรีมแต่ละตัวที่มีต้นทางหรือปลายทางอยู่ที่แร็กเฉพาะจะถูกกระจายไปยังเอเจนต์ทั้งหมดที่มีอยู่ภายในแร็กนั้น นี่ช่วยให้เราสามารถทดสอบเส้นทางที่มีค่าใช้จ่ายเท่ากันจำนวนมากภายในโครงสร้างเครือข่ายของเราได้ ตามที่แสดงในรูปด้านล่าง

เราเริ่มต้นด้วยตัวแทน 150 คนในการใช้งานครั้งแรก และตอนนี้ได้ขยายตัวสำเร็จถึง 10 เท่าแล้ว ระบบเมชครอบคลุมโครงข่ายหลักที่เชื่อมต่อ 25 แห่งที่กระจายอยู่ทั่วโลก ที่หนึ่งในศูนย์ข้อมูลหลักของเรา เรามีระบบเมชภายในศูนย์ครอบคลุมพื้นที่กว่า 200 แร็ค โดยมีประมาณ 33,000 สตรีมที่รวมกันเป็นอัตราการตรวจสอบ 1.65 Mpps แต่ละแร็คได้รับการตรวจสอบจากแร็คอื่น ๆ ประมาณ 5–10 kpps แอปพลิเคชันผู้จัดตารางคำนวณและกระจายเป้าหมายกว่า 35,000 เป้าหมายไปยังเอเจนต์ทั้งหมดของเราในศูนย์ต่าง ๆ อย่างเท่าเทียมกัน

การรวบรวมข้อมูลและการแสดงผลข้อมูล

เราใช้แอปพลิเคชันผู้รวบรวมแยกต่างหากที่ทำการตรวจสอบอย่างต่อเนื่องกับตัวแทน Ping Mesh ทั้งหมดเพื่อตรวจสอบการสูญเสียแพ็กเก็ตและค่าความล่าช้า ข้อมูลนี้จะถูกกรองโดยอัตโนมัติเพื่อยกเว้นผลลัพธ์ที่ไม่ถูกต้องตามสถานะสุขภาพที่ถูกเก็บไว้ในหน่วยความจำชั่วคราวที่ผู้รวบรวม ตัวอย่างเช่น เราจะไม่รวมผลลัพธ์จากตัวแทนที่ทำงานบนเซิร์ฟเวอร์ที่ไม่ตอบสนองต่อการตรวจสอบสุขภาพหรือเซิร์ฟเวอร์ที่เพิ่งรีบูต ผู้รวบรวมของเราสามารถสำรวจและคัดกรองผลลัพธ์จากโหนดมากกว่า 1,500 โหนดพร้อมกันได้ และนำข้อมูลเข้าสู่ฐานข้อมูลแบบลำดับเวลาภายในเวลา 2 วินาที

ผลลัพธ์ทั้งแบบรวมและแบบต่อสตรีมถูกแสดงผลด้วยแดชบอร์ด Grafana ตารางฮีตแมปอาจใช้งานยากเมื่อมีชุดข้อมูลขนาดใหญ่ โดยเฉพาะอย่างยิ่งสำหรับศูนย์ข้อมูลขนาดใหญ่ของเรา เราใช้คำสั่ง Prometheus topk() เพื่อแสดงเส้นทางที่มีการสูญเสียแพ็กเก็ตสูงสุดในแต่ละรายการจากผลลัพธ์นับพัน ซึ่งโดยทั่วไปแล้วจะมีเพียงไม่กี่รายการเท่านั้น ผลลัพธ์ได้รับการตรวจสอบอย่างละเอียดกับสถิติสุขภาพของระบบตัวแทนและระบบโฮสต์ที่ถูกตรวจสอบอย่างสม่ำเสมอโดยผู้รวบรวมข้อมูล ซึ่งทำให้เราได้รับความมั่นใจในระดับสูงในแต่ละผลลัพธ์โดยไม่คำนึงถึงความแตกต่างของปริมาณแพ็กเก็ตที่สูญเสียไปมากเพียงใด เมื่อผลลัพธ์แต่ละรายการถูกนำมาดูรวมกัน จะช่วยให้เราสามารถค้นหาสาเหตุของปัญหาในระบบเครือข่ายได้ ตัวอย่างของปัญหาการสูญเสียแพ็กเก็ตที่ถูกตรวจพบโดยระบบตรวจสอบแบบเมชของเราได้แสดงไว้ด้านล่าง

สรุปและขั้นตอนต่อไป

ระบบ Ping Mesh ของเราเป็นเครื่องมือที่ทรงพลังสำหรับทีมวิศวกรรมเครือข่ายในการตรวจสอบการสูญเสียแพ็กเก็ตและความหน่วงของเครือข่ายตั้งแต่ต้นทางถึงปลายทาง ข้อมูลนี้สามารถใช้เพื่อตอบคำถามได้ทันทีว่า "เครือข่ายกำลังสูญเสียแพ็กเก็ตหรือไม่?" จากประสบการณ์ของเรา เหตุการณ์เครือข่ายที่มีผลกระทบต่อลูกค้าส่วนใหญ่จะถูกตรวจจับและแจ้งเตือนโดยระบบตรวจสอบข้อมูลจากระยะไกลของอุปกรณ์ ระบบนี้ช่วยเปิดเผยปัญหาที่อาจเกิดขึ้นได้แม้จะมีผลกระทบต่ำ เช่น การบัฟเฟอร์ของเครือข่ายหรือการเกิดจุดดำในทราฟฟิกที่แยกตัวออกจากกัน

ระบบของเราสามารถให้ข้อมูลเชิงลึกเกี่ยวกับความน่าเชื่อถือโดยรวมของเครือข่ายคลาวด์ของ Roblox ได้อีกด้วย ที่หนึ่งในศูนย์ข้อมูลหลักของเรา เรามีการตรวจสอบสุขภาพของเครือข่ายด้วยโพรบมากกว่า 100 ล้านครั้งต่อนาที และแทบจะไม่เคยพบจำนวนแพ็กเก็ตที่สูญหายเกิน 50 แพ็กเก็ตต่อนาที ซึ่งบ่งชี้ถึงความน่าเชื่อถือประมาณ 6 9 (99.9999%) จากเครือข่ายศูนย์ข้อมูลของเรา บ่อยครั้งที่ไม่มีการสังเกตเห็นการสูญเสียแพ็กเก็ตในกลุ่มแพ็กเก็ตจำนวน 100 ล้านแพ็กเก็ต เมื่อมีการสูญเสียแพ็กเก็ตในปริมาณมาก ระบบจะให้ข้อมูลเชิงลึกเกี่ยวกับตำแหน่งและระยะเวลาที่เกิดการสูญเสียแพ็กเก็ต เครื่องมือแก้ไขอัตโนมัติจะซ่อมแซมเครือข่ายโดยอัตโนมัติและป้องกันไม่ให้การจราจรของผู้ใช้ประสบกับการสูญเสียแพ็กเก็ตเพิ่มเติมโดยการเปลี่ยนเส้นทางผ่านเส้นทางอื่นในเครือข่าย ทีมเครือข่ายของ Roblox ได้สร้างเครือข่ายคลาวด์ที่มีความน่าเชื่อถือสูงมาก

ในอนาคต เราตั้งใจที่จะใช้เครื่องมือวิเคราะห์ข้อมูลเพื่อเชื่อมโยงข้อมูลจากระบบติดตามระยะไกลของอุปกรณ์, ไฟล์บันทึกระบบ (syslogs), และชุดข้อมูลอื่น ๆ จากนั้นเราวางแผนที่จะเปรียบเทียบข้อมูลนี้กับข้อมูลจากระบบ Ping Mesh เพื่อช่วยระบุตำแหน่งที่เกิดข้อผิดพลาดในระบบเครือข่าย เมื่อเครือข่ายคลาวด์ของ Roblox ยังคงขยายตัวและพัฒนาต่อไป เราวางแผนที่จะปรับปรุงกลไกการตรวจสอบของเราให้ครอบคลุมถึง IPv6 และแพ็กเก็ตขนาดใหญ่ (jumbo frames) พร้อมทั้งเพิ่มจำนวนตัวแทน (agents) ให้ครอบคลุมระหว่างไซต์ต่าง ๆ มากขึ้น