Roblox กลับสู่บริการ 10/28-10/31 2021

ตั้งแต่วันที่ 28 ตุลาคมและได้รับการแก้ไขอย่างสมบูรณ์ในวันที่ 31 ตุลาคม Roblox ประสบปัญหาการหยุดทำงาน 73 ชั่วโมง¹ ผู้เล่นห้าสิบล้านคนใช้ Roblox เป็นประจำทุกวัน และเพื่อสร้างประสบการณ์ที่ผู้เล่นคาดหวัง ระดับของเราเกี่ยวข้องกับบริการออนไลน์ภายในหลายร้อยรายการ เช่นเดียวกับบริการขนาดใหญ่ เรามีการหยุดชะงักของบริการเป็นครั้งคราว แต่ระยะเวลาที่เพิ่มขึ้นของการหยุดทำงานนี้ทำให้มีความโดดเด่นเป็นพิเศษ เราขออภัยอย่างจริงใจต่อชุมชนของเราสำหรับการหยุดทำงาน

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

Roblox Engineering และเจ้าหน้าที่ด้านเทคนิคจาก HashiCorp ได้ร่วมกันพยายามนำ Roblox กลับมาให้บริการ เราต้องการรับทราบทีม HashiCorp ที่นำทรัพยากรที่เหลือเชื่อมาและทำงานร่วมกับเราอย่างไม่รู้จักเหน็ดเหนื่อยจนกว่าปัญหาจะได้รับการแก้ไข

สรุปการหยุดทำงาน

การหยุดทำงานนั้นไม่ซ้ำกันทั้งในด้านระยะเวลาและความซับซ้อน ทีมต้องจัดการกับความท้าทายหลายประการตามลำดับเพื่อทำความเข้าใจสาเหตุที่แท้จริงและนำบริการกลับมา

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

คำนำ: สภาพแวดล้อมคลัสเตอร์ของเราและ HashiStack

โครงสร้างพื้นฐานหลักของ Roblox ทำงานในศูนย์ข้อมูล Roblox เราปรับใช้และจัดการฮาร์ดแวร์ของเราเอง ตลอดจนระบบประมวลผล ที่เก็บข้อมูล และระบบเครือข่ายของเราเองที่ด้านบนของฮาร์ดแวร์นั้น ขนาดของการปรับใช้ของเรามีความสำคัญ ด้วยเซิร์ฟเวอร์มากกว่า 18,000 เซิร์ฟเวอร์และคอนเทนเนอร์ 170,000 คอนเทนเนอร์

เพื่อใช้งานเซิร์ฟเวอร์หลายพันเครื่องในไซต์ต่างๆ เราใช้ประโยชน์จากชุดเทคโนโลยีที่รู้จักกันทั่วไปในชื่อ “ฮาชิสแต็ค". พเนจร, กงสุล และ หกคะเมน เป็นเทคโนโลยีที่เราใช้จัดการเซิร์ฟเวอร์และบริการทั่วโลก และที่ช่วยให้เราสามารถจัดการคอนเทนเนอร์ที่รองรับบริการ Roblox

พเนจร ใช้สำหรับจัดตารางงาน มันตัดสินใจว่าคอนเทนเนอร์ใดจะทำงานบนโหนดใดและพอร์ตใดที่สามารถเข้าถึงได้ นอกจากนี้ยังตรวจสอบความสมบูรณ์ของคอนเทนเนอร์ ข้อมูลทั้งหมดนี้ถูกส่งไปยัง Service Registry ซึ่งเป็นฐานข้อมูลของ IP:Port ที่รวมกัน บริการ Roblox ใช้ Service Registry เพื่อค้นหาบริการอื่นเพื่อให้สามารถสื่อสารกันได้ กระบวนการนี้เรียกว่า "การค้นพบบริการ" เราใช้ กงสุล เพื่อค้นหาบริการ ตรวจสุขภาพ การล็อกเซสชัน (สำหรับระบบ HA ที่สร้างขึ้นบน) และในฐานะที่เก็บ KV

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

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

ในช่วงหลายเดือนที่นำไปสู่เหตุการณ์ในเดือนตุลาคม Roblox ได้อัพเกรดจากกงสุล 1.9 เป็น กงสุล 1.10 เพื่อใช้ประโยชน์จาก คุณสมบัติการสตรีมใหม่. คุณลักษณะการสตรีมนี้ได้รับการออกแบบมาเพื่อลด CPU และแบนด์วิดท์เครือข่ายที่จำเป็นอย่างมากในการเผยแพร่การอัปเดตในคลัสเตอร์ขนาดใหญ่เช่นเดียวกับที่ Roblox

การตรวจจับเบื้องต้น (10/28 13:37)

ในช่วงบ่ายของวันที่ 28 ต.ค. Vประสิทธิภาพ ault ลดลงและเซิร์ฟเวอร์ Consul เดียวมี CPU loa สูงง. วิศวกร Roblox เริ่มตรวจสอบ ณ จุดนี้ผู้เล่นไม่ได้รับผลกระทบ

การพิจารณาคดีก่อนกำหนด (10/28 13:37 – 10/29 02:00)

การตรวจสอบเบื้องต้นชี้ให้เห็นว่ากลุ่มกงสุลที่ห้องนิรภัยและบริการอื่น ๆ พึ่งพานั้นไม่แข็งแรง โดยเฉพาะอย่างยิ่ง ตัวชี้วัดคลัสเตอร์กงสุลแสดงให้เห็นเวลาแฝงในการเขียนที่เพิ่มขึ้นสำหรับร้าน KV พื้นฐานที่กงสุลเก็บข้อมูล เวลาแฝงเปอร์เซ็นไทล์ที่ 50 ในการดำเนินการเหล่านี้โดยทั่วไปแล้วจะต่ำกว่า 300 มิลลิวินาที แต่ตอนนี้เหลือ 2 วินาที ปัญหาฮาร์ดแวร์ไม่ได้ผิดปกติในระดับของ Roblox และกงสุลสามารถอยู่รอดได้ ความล้มเหลวของฮาร์ดแวร์ อย่างไรก็ตาม หากฮาร์ดแวร์ทำงานช้าแทนที่จะทำงานล้มเหลว อาจส่งผลต่อประสิทธิภาพโดยรวมของกงสุล ในกรณีนี้ ทีมสงสัยว่าประสิทธิภาพของฮาร์ดแวร์ลดลงเป็นสาเหตุหลัก และเริ่มกระบวนการเปลี่ยนโหนดคลัสเตอร์ Consul ตัวใดตัวหนึ่ง นี่เป็นความพยายามครั้งแรกของเราในการวินิจฉัยเหตุการณ์ที่เกิดขึ้น. ในช่วงเวลานี้ พนักงานจาก HashiCorp ได้เข้าร่วมกับวิศวกรของ Roblox เพื่อช่วยในการวินิจฉัยและการแก้ไข การอ้างอิงถึง "ทีม" และ "ทีมวิศวกรรม" นับจากนี้ไปหมายถึงทั้งเจ้าหน้าที่ Roblox และ HashiCorp

แม้จะมีฮาร์ดแวร์ใหม่ ประสิทธิภาพของคลัสเตอร์กงสุลยังคงประสบปัญหา เมื่อเวลา 16:35 น. จำนวนผู้เล่นออนไลน์ลดลงเหลือ 50% ของจำนวนปกติ

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

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

เมื่อพิจารณาถึงความรุนแรงของเหตุการณ์ ทีมงานจึงตัดสินใจเปลี่ยนโหนดทั้งหมดในคลัสเตอร์กงสุลด้วยเครื่องใหม่ที่ทรงพลังกว่า เครื่องใหม่เหล่านี้มี 128 คอร์ (เพิ่มขึ้น 2 เท่า) และดิสก์ NVME SSD ที่ใหม่กว่าและเร็วกว่า ภายในเวลา 19:00 น. ทีมงานได้ย้ายคลัสเตอร์ส่วนใหญ่ไปยังเครื่องใหม่ แต่คลัสเตอร์ยังไม่สมบูรณ์ คลัสเตอร์กำลังรายงานว่าโหนดส่วนใหญ่ไม่สามารถติดตามการเขียนได้ และเวลาแฝงเปอร์เซ็นไทล์ที่ 50 ในการเขียน KV ยังคงอยู่ที่ประมาณ 2 วินาที แทนที่จะเป็น 300ms ทั่วไปหรือน้อยกว่า

กลับสู่ความพยายามให้บริการ #1 (10/29 02:00 – 04:00 น.)

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

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

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

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

กลับไปลองบริการ #2 (10/29 04:00 – 10/30 02:00)

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

ทีมวิศวกรตัดสินใจลดการใช้กงสุลแล้วแนะนำอีกครั้งอย่างรอบคอบและเป็นระบบ เพื่อให้แน่ใจว่าเรามีจุดเริ่มต้นที่สะอาด เราจึงบล็อกการรับส่งข้อมูลภายนอกที่เหลืออยู่ด้วย เราได้รวบรวมรายชื่อบริการทั้งหมดที่ใช้กงสุลและดำเนินการเปลี่ยนแปลงการกำหนดค่าเพื่อปิดใช้งานการใช้งานที่ไม่จำเป็นทั้งหมด กระบวนการนี้ใช้เวลาหลายชั่วโมงเนื่องจากมีการกำหนดเป้าหมายระบบและประเภทการเปลี่ยนแปลงการกำหนดค่าที่หลากหลาย บริการ Roblox ที่โดยทั่วไปมีหลายร้อยอินสแตนซ์ที่ทำงานอยู่ถูกลดขนาดเป็นตัวเลขหลักเดียว ความถี่ในการตรวจสุขภาพลดลงจาก 60 วินาทีเป็น 10 นาที เพื่อให้คลัสเตอร์มีห้องหายใจเพิ่มเติม เมื่อเวลา 16:00 น. ของวันที่ 29 ต.ค. มากกว่า 24 ชั่วโมงหลังจากการหยุดทำงาน ทีมงานได้เริ่มพยายามครั้งที่สองเพื่อนำ Roblox กลับมาออนไลน์อีกครั้ง อีกครั้งที่ช่วงเริ่มต้นของการพยายามรีสตาร์ทครั้งนี้ดูดี แต่เมื่อเวลา 02:00 น. ของวันที่ 30 ต.ค. กงสุลอยู่ในสถานะที่ไม่แข็งแรงอีกครั้ง คราวนี้มีภาระน้อยลงอย่างมากจากบริการ Roblox ที่ขึ้นอยู่กับมัน

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

วิจัยเรื่องความขัดแย้ง (10/30 02:00 – 10/30 12:00)

ในอีก 10 ชั่วโมงข้างหน้า ทีมวิศวกรได้เจาะลึกลงไปในบันทึกการแก้ปัญหาและตัวชี้วัดระดับระบบปฏิบัติการ ข้อมูลนี้แสดงให้เห็นว่าการเขียนกงสุล KV ถูกบล็อกเป็นเวลานาน กล่าวอีกนัยหนึ่ง "การโต้แย้ง" สาเหตุของความขัดแย้งไม่ชัดเจนในทันที แต่ทฤษฎีหนึ่งคือการเปลี่ยนจากเซิร์ฟเวอร์ CPU Core 64 เป็น 128 ในช่วงต้นของการหยุดทำงานอาจทำให้ปัญหาแย่ลง หลังจากดูข้อมูล htop และข้อมูลการดีบักประสิทธิภาพที่แสดงในภาพหน้าจอด้านล่าง ทีมงานสรุปว่าคุ้มค่าที่จะกลับไปใช้เซิร์ฟเวอร์ 64 Core ที่คล้ายกับที่ใช้ก่อนการหยุดทำงาน ทีมงานเริ่มเตรียมฮาร์ดแวร์: ติดตั้งกงสุลแล้ว ตรวจสอบการกำหนดค่าระบบปฏิบัติการสามครั้ง และเครื่องพร้อมสำหรับการบริการในลักษณะที่มีรายละเอียดมากที่สุด จากนั้นทีมได้เปลี่ยนคลัสเตอร์ Consul กลับไปเป็นเซิร์ฟเวอร์ CPU Core 64 ตัว แต่การเปลี่ยนแปลงนี้ไม่ได้ช่วยอะไร นี่เป็นความพยายามครั้งที่สี่ของเราในการวินิจฉัยสาเหตุที่แท้จริงของเหตุการณ์

พบสาเหตุหลัก (10/30 12:00 – 10/30 20:00)

หลายเดือนก่อน เราเปิดใช้งานคุณสมบัติการสตรีมใหม่ของกงสุลในกลุ่มย่อยของบริการของเรา ฟีเจอร์นี้ออกแบบมาเพื่อลดการใช้งาน CPU และแบนด์วิดท์เครือข่ายของคลัสเตอร์ Consul ทำงานตามที่คาดไว้ ดังนั้นในอีกไม่กี่เดือนข้างหน้า เราจึงเปิดใช้งานฟีเจอร์นี้ในบริการแบ็กเอนด์ของเรามากขึ้น ในวันที่ 27 ตุลาคม เวลา 14:00 น. หนึ่งวันก่อนเกิดไฟฟ้าดับ เราได้เปิดใช้งานคุณลักษณะนี้ในบริการแบ็กเอนด์ที่รับผิดชอบการกำหนดเส้นทางการรับส่งข้อมูล ในการเปิดตัวครั้งนี้ เพื่อเตรียมพร้อมสำหรับการรับส่งข้อมูลที่เพิ่มขึ้นซึ่งปกติแล้วเราจะเห็นในช่วงปลายปี เรายังได้เพิ่มจำนวนโหนดที่สนับสนุนการกำหนดเส้นทางการรับส่งข้อมูลอีก 50% ระบบทำงานได้ดีกับการสตรีมในระดับนี้เป็นเวลาหนึ่งวันก่อนเหตุการณ์เริ่มต้น ดังนั้นในตอนแรกจึงไม่ชัดเจนว่าทำไมประสิทธิภาพจึงเปลี่ยนไป อย่างไรก็ตาม จากการวิเคราะห์รายงานประสิทธิภาพและกราฟเปลวไฟจากเซิร์ฟเวอร์กงสุล เราเห็นหลักฐานว่าเส้นทางรหัสการสตรีมมีส่วนรับผิดชอบต่อการโต้แย้งที่ก่อให้เกิดการใช้งาน CPU สูง เราปิดการใช้งานคุณสมบัติการสตรีมสำหรับระบบกงสุลทั้งหมด รวมถึงโหนดการกำหนดเส้นทางการรับส่งข้อมูล การเปลี่ยนแปลงการกำหนดค่าเสร็จสิ้นเมื่อเวลา 15:51 น. โดยที่เปอร์เซ็นต์ไทล์ที่ 50 สำหรับการเขียน Consul KV ลดลงเหลือ 300 มิลลิวินาที ในที่สุดเราก็มีความก้าวหน้า

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

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

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

อย่างไรก็ตาม เนื่องจากการออกแบบของ BoltDB แม้ว่ารายการบันทึกที่เก่าที่สุดจะถูกลบ พื้นที่ BoltDB ที่ใช้บนดิสก์จะไม่ลดขนาดลง แต่หน้าทั้งหมด (4kb ในไฟล์) ที่ใช้ในการจัดเก็บข้อมูลที่ถูกลบจะถูกทำเครื่องหมายเป็น "ฟรี" และนำมาใช้ใหม่สำหรับการเขียนในภายหลัง BoltDB ติดตามหน้าฟรีเหล่านี้ในโครงสร้างที่เรียกว่า "รายการอิสระ" โดยปกติเวลาในการตอบสนองในการเขียนจะไม่ได้รับผลกระทบอย่างมีนัยสำคัญจากเวลาที่ใช้ในการอัปเดตรายการอิสระ แต่ภาระงานของ Roblox เปิดเผยปัญหาประสิทธิภาพทางพยาธิวิทยาใน BoltDB ที่ทำให้การบำรุงรักษาฟรีลิสต์มีราคาแพงมาก 

บริการกู้คืนแคช (10/30 20:00 – 10/31 05:00)

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

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

กระบวนการปรับใช้แคชใหม่พบปัญหาหลายประการ: 

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

ทีมงานทำงานตลอดทั้งคืนเพื่อระบุและแก้ไขปัญหาเหล่านี้ ตรวจสอบให้แน่ใจว่าระบบแคชได้รับการติดตั้งอย่างเหมาะสม และตรวจสอบความถูกต้อง เวลา 05:00 น. ของวันที่ 31 ตุลาคม 61 ชั่วโมงนับตั้งแต่เริ่มต้นการหยุดทำงาน เรามีกลุ่มกงสุลที่ทำงานได้ดีและระบบแคชที่ดี เราพร้อมที่จะนำ Roblox ที่เหลือขึ้นมา

การกลับมาของผู้เล่น (10/31 05:00 – 10/31 16:00 น.)

การกลับสู่ระยะให้บริการสุดท้ายเริ่มอย่างเป็นทางการเมื่อเวลา 05:00 น. ของวันที่ 31 เช่นเดียวกับระบบแคช ส่วนสำคัญของบริการที่ทำงานอยู่ได้ถูกปิดลงในระหว่างการหยุดทำงานครั้งแรกหรือขั้นตอนการแก้ไขปัญหา ทีมงานจำเป็นต้องเริ่มบริการเหล่านี้ใหม่ด้วยระดับความสามารถที่ถูกต้องและตรวจสอบว่าทำงานได้อย่างถูกต้อง สิ่งนี้ดำเนินไปอย่างราบรื่น และเมื่อเวลา 10 น. เราก็พร้อมที่จะเปิดรับผู้เล่น

ด้วยแคชเย็นและระบบที่เรายังไม่แน่ใจ เราไม่ต้องการให้มีการรับส่งข้อมูลจำนวนมากซึ่งอาจทำให้ระบบกลับสู่สถานะไม่เสถียร เพื่อหลีกเลี่ยงน้ำท่วม เราใช้การควบคุม DNS เพื่อจัดการจำนวนผู้เล่นที่สามารถเข้าถึง Roblox สิ่งนี้ทำให้เราสามารถปล่อยให้ผู้เล่นสุ่มเลือกได้เป็นเปอร์เซ็นต์ในขณะที่คนอื่น ๆ ยังคงถูกเปลี่ยนเส้นทางไปยังหน้าการบำรุงรักษาแบบคงที่ของเรา ทุกครั้งที่เราเพิ่มเปอร์เซ็นต์ เราจะตรวจสอบการโหลดฐานข้อมูล ประสิทธิภาพแคช และความเสถียรของระบบโดยรวม งานดำเนินต่อไปตลอดทั้งวัน โดยเพิ่มการเข้าถึงทีละ 10% โดยประมาณ เรามีความสุขที่ได้เห็นผู้เล่นที่ทุ่มเทที่สุดของเราบางคนคิดแผนการควบคุม DNS ของเรา และเริ่มแลกเปลี่ยนข้อมูลนี้บน Twitter เพื่อให้พวกเขาสามารถเข้าถึงได้ "ก่อนใคร" ในขณะที่เรานำบริการสำรองกลับมา เมื่อเวลา 16:45 น. วันอาทิตย์ 73 ชั่วโมงหลังจากการเริ่มต้นของการหยุดทำงาน ผู้เล่น 100% ได้รับการเข้าถึงและ Roblox ก็ใช้งานได้อย่างสมบูรณ์

การวิเคราะห์เพิ่มเติมและการเปลี่ยนแปลงที่เกิดจากไฟดับ

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

การวิเคราะห์เพิ่มเติมเกี่ยวกับปัญหาผู้นำที่ช้ายังเปิดเผยสาเหตุหลักของการเขียนข้อมูล Raft สองวินาทีและปัญหาความสอดคล้องของคลัสเตอร์ วิศวกรดูกราฟเปลวไฟดังตัวอย่างด้านล่างเพื่อทำความเข้าใจการทำงานภายในของ BoltDB ให้ดีขึ้น

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

ผลลัพธ์ของคำสั่งก่อนหน้าบอกเราหลายประการ:

• ที่จัดเก็บบันทึก 4.2GB นี้จัดเก็บข้อมูลจริงเพียง 489MB (รวมถึงดัชนีภายในทั้งหมด) 3.8GB คือพื้นที่ว่าง
• พื้นที่ อิสระคือ 7.8MB เนื่องจากมีรหัสเพจฟรีเกือบล้านรหัส

นั่นหมายความว่า สำหรับทุกบันทึกต่อท้าย (แต่ละ Raft เขียนหลังจากการแบทช์บางชุด) รายการอิสระ 7.8MB ใหม่ก็ถูกเขียนลงดิสก์เช่นกัน แม้ว่าข้อมูลดิบจริงที่ถูกผนวกคือ 16kB หรือน้อยกว่า 

แรงกดดันย้อนกลับต่อการดำเนินการเหล่านี้ยังสร้างบัฟเฟอร์ TCP แบบเต็มและมีส่วนทำให้เวลาเขียน 2-3 วินาทีสำหรับผู้นำที่ไม่แข็งแรง ภาพด้านล่างแสดงการวิจัยเกี่ยวกับ TCP Zero Windows ระหว่างเหตุการณ์

HashiCorp และ Roblox ได้พัฒนาและปรับใช้กระบวนการโดยใช้เครื่องมือ BoltDB ที่มีอยู่เพื่อ "กระชับ" ฐานข้อมูล ซึ่งแก้ไขปัญหาด้านประสิทธิภาพ

การปรับปรุงล่าสุดและขั้นตอนในอนาคต

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

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

การปรับปรุงการวัดและส่งข้อมูลทางไกล

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

เราได้ขยายระบบ telemetry เพื่อให้ทัศนวิสัยที่ดีขึ้นในประสิทธิภาพของกงสุลและ BoltDB ตอนนี้เราได้รับการแจ้งเตือนที่ตรงเป้าหมายหากมีสัญญาณว่าระบบกำลังเข้าใกล้สถานะที่เป็นสาเหตุของการหยุดทำงานนี้ เรายังได้ขยายระบบ telemetry ของเราเพื่อให้มองเห็นรูปแบบการรับส่งข้อมูลระหว่างบริการ Roblox และกงสุลมากขึ้น การมองเห็นเพิ่มเติมเกี่ยวกับพฤติกรรมและประสิทธิภาพของระบบของเราในหลายระดับได้ช่วยเราแล้วในระหว่างการอัปเกรดระบบและเซสชันการดีบัก

การขยายสู่ความพร้อมใช้งานหลายโซนและศูนย์ข้อมูล

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

กงสุลอัพเกรดและชาร์ด

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

บริการหลักบางอย่างของ Roblox กำลังใช้ร้าน KV ของ Consul โดยตรงเป็นที่ที่สะดวกในการจัดเก็บข้อมูล แม้ว่าเราจะมีระบบจัดเก็บข้อมูลอื่นๆ ที่เหมาะสมกว่าก็ตาม เรากำลังดำเนินการย้ายข้อมูลนี้ไปยังระบบจัดเก็บข้อมูลที่เหมาะสมกว่า เมื่อเสร็จสิ้นแล้ว การดำเนินการนี้จะลดภาระของกงสุลด้วย

เราค้นพบข้อมูล KV ที่ล้าสมัยจำนวนมาก การลบข้อมูลที่ล้าสมัยนี้ช่วยปรับปรุงประสิทธิภาพของกงสุล

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

การปรับปรุงขั้นตอนการบูตสแตรปและการจัดการการกำหนดค่า

การกลับไปสู่ความพยายามในการบริการช้าลงด้วยปัจจัยหลายประการ รวมถึงการปรับใช้และการอุ่นแคชที่จำเป็นสำหรับบริการ Roblox เรากำลังพัฒนาเครื่องมือและกระบวนการใหม่เพื่อทำให้กระบวนการนี้เป็นแบบอัตโนมัติมากขึ้นและเกิดข้อผิดพลาดน้อยลง โดยเฉพาะอย่างยิ่ง เราได้ออกแบบกลไกการปรับใช้แคชใหม่เพื่อให้แน่ใจว่าเราสามารถเรียกใช้ระบบแคชของเราได้อย่างรวดเร็วตั้งแต่เริ่มต้น การดำเนินการนี้กำลังดำเนินการอยู่

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

เราได้พัฒนาและปรับใช้กลไกเพื่อให้การเปลี่ยนแปลงการกำหนดค่าเครื่องเร็วขึ้น

การกลับมาของสตรีมมิ่ง

เดิมทีเราใช้การสตรีมเพื่อลดการใช้ CPU และแบนด์วิดท์เครือข่ายของคลัสเตอร์กงสุล เมื่อการใช้งานใหม่ได้รับการทดสอบในระดับเดียวกับปริมาณงานของเราแล้ว เราคาดว่าจะแนะนำการใช้งานใหม่ในระบบของเราอย่างรอบคอบ

หมายเหตุเกี่ยวกับคลาวด์สาธารณะ

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

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

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

ความเสถียรของระบบตั้งแต่เกิดไฟดับ

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

คิดปิด

เราอยากจะขอบคุณชุมชน Roblox ทั่วโลกสำหรับความเข้าใจและการสนับสนุนของพวกเขา ค่านิยมอีกอย่างของ Roblox ของเราคือ Take Responsibility และเรารับผิดชอบอย่างเต็มที่สำหรับสิ่งที่เกิดขึ้นที่นี่ เราขอขอบคุณทีมงานที่ HashiCorp จากใจจริงอีกครั้ง วิศวกรของพวกเขาเข้ามาช่วยเหลือเราในตอนเริ่มต้นของเหตุไฟฟ้าขัดข้องที่ไม่เคยเกิดขึ้นมาก่อนนี้ และไม่ได้ละทิ้งเรา แม้กระทั่งตอนนี้ วิศวกรของ Roblox และ HashiCorp ยังคงทำงานร่วมกันอย่างใกล้ชิดเป็นเวลาหลายสัปดาห์ จากการหยุดทำงานหลายสัปดาห์หลังเรา เพื่อให้แน่ใจว่าเรากำลังทำทุกอย่างที่ทำได้เพื่อป้องกันไม่ให้ไฟดับแบบเดียวกันนี้เกิดขึ้นอีก

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

เราได้เรียนรู้อย่างมากจากประสบการณ์นี้ และเรามุ่งมั่นที่จะทำให้ Roblox เป็นแพลตฟอร์มที่แข็งแกร่งและเชื่อถือได้มากขึ้นในอนาคต

ขอขอบคุณอีกครั้ง 

---

¹ โปรดทราบว่าวันที่และเวลาทั้งหมดในโพสต์บล็อกนี้เป็นเวลามาตรฐานแปซิฟิก (PST)

โพสต์ Roblox กลับสู่บริการ 10/28-10/31 2021 ปรากฏตัวครั้งแรกเมื่อ บล็อก Roblox.

Source: https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/