เราทำให้โครงสร้างพื้นฐานของ Roblox มีประสิทธิภาพและยืดหยุ่นมากขึ้นได้อย่างไร - Roblox Blog

เผยแพร่ซ้ำโดยเพลโต

ผู้ติดตาม: 0

เนื่องจาก Roblox เติบโตขึ้นในช่วง 16 ปีที่ผ่านมา ขนาดและความซับซ้อนของโครงสร้างพื้นฐานทางเทคนิคที่รองรับประสบการณ์ร่วม 3 มิติที่ดื่มด่ำนับล้านก็เพิ่มขึ้นเช่นกัน จำนวนเครื่องจักรที่เรารองรับเพิ่มขึ้นกว่าสามเท่าในช่วงสองปีที่ผ่านมา จากประมาณ 36,000 เครื่อง ณ วันที่ 30 มิถุนายน 2021 เป็นเกือบ 145,000 เครื่องในปัจจุบัน การสนับสนุนประสบการณ์ที่เปิดตลอดเวลาเหล่านี้ให้กับผู้คนทั่วโลกต้องการบริการภายในมากกว่า 1,000 รายการ เพื่อช่วยให้เราควบคุมค่าใช้จ่ายและเวลาแฝงของเครือข่าย เราปรับใช้และจัดการเครื่องเหล่านี้โดยเป็นส่วนหนึ่งของโครงสร้างพื้นฐานคลาวด์ส่วนตัวแบบไฮบริดที่สร้างขึ้นเองซึ่งทำงานในสถานที่เป็นหลัก

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

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

การสร้างแบ็คสต็อป

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

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

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

การย้ายไปสู่โครงสร้างพื้นฐานเซลลูล่าร์

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

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

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

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

การแก้ปัญหาความท้าทายที่ใหญ่กว่า

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

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

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

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

การย้ายโครงสร้างพื้นฐานที่ทำงานตลอดเวลา

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

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

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

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

การพิสูจน์อนาคตในขณะที่เราขยายขนาด

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

โดยสรุปจนถึงขณะนี้เรามี:

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

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

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

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