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

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

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

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

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

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

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

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

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

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

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

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

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

การแก้ปัญหาที่ท้าทายมากขึ้น

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

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

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

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

การย้ายโครงสร้างพื้นฐานที่ต้องสามารถเข้าถึงได้ตลอดเวลา

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

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

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

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

มั่นใจในอนาคตขณะที่เรากำลังเติบโตมากขึ้น

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

สรุปแล้วถึงวันนี้ เรามี:

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

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

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

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