كيف نجعل البنية التحتية لـ Roblox أكثر كفاءة ومرونة

مع نمو Roblox على مدار أكثر من 16 عامًا، نما أيضًا حجم وتعقيد البنية التحتية التقنية التي تدعم ملايين التجارب التفاعلية ثلاثية الأبعاد الغامرة. وقد تضاعف عدد الأجهزة التي ندعمها أكثر من ثلاث مرات خلال العامين الماضيين، من حوالي 36,000 جهاز في 30 يونيو 2021 إلى ما يقرب من 145,000 جهاز اليوم. يتطلب دعم هذه التجارب المتاحة دائمًا للأشخاص في جميع أنحاء العالم أكثر من 1,000 خدمة داخلية. لمساعدتنا في التحكم في التكاليف وزمن انتقال الشبكة، نقوم بنشر وإدارة هذه الأجهزة كجزء من بنية تحتية سحابية خاصة هجينة ومصممة خصيصًا تعمل بشكل أساسي في الموقع.  

تدعم بنيتنا التحتية حاليًا أكثر من 70 مليون مستخدم نشط يوميًا حول العالم، بما في ذلك المبدعون الذين يعتمدون على اقتصاد Roblox في أعمالهم. يتوقع كل هؤلاء الملايين من الأشخاص مستوى عالٍ جدًا من الموثوقية. نظرًا للطبيعة الغامرة لتجاربنا، فإن التسامح مع التأخير أو زمن الوصول منخفض للغاية، ناهيك عن الانقطاعات. Roblox هي منصة للتواصل والترابط، حيث يجتمع الناس في تجارب ثلاثية الأبعاد غامرة. عندما يتواصل الناس من خلال شخصياتهم الرقمية في مساحة غامرة، فإن حتى التأخيرات أو الأعطال الطفيفة تكون أكثر وضوحًا مما هي عليه في سلسلة رسائل نصية أو مكالمة جماعية.

في أكتوبر 2021، تعرضنا لانقطاع على مستوى النظام بأكمله. بدأ الأمر صغيرًا، بمشكلة في مكون واحد في أحد مراكز البيانات. لكنه انتشر بسرعة أثناء تحقيقنا، وأدى في النهاية إلى انقطاع دام 73 ساعة. في ذلك الوقت، شاركنا تفاصيل حول ما حدث وبعض الدروس المبكرة التي تعلمناها من هذه المشكلة. منذ ذلك الحين، ونحن ندرس تلك الدروس ونعمل على زيادة مرونة بنيتنا التحتية لمواجهة أنواع الأعطال التي تحدث في جميع الأنظمة واسعة النطاق بسبب عوامل مثل الارتفاعات الشديدة في حركة المرور، أو الطقس، أو أعطال الأجهزة، أو أخطاء البرامج، أو مجرد أخطاء بشرية. عندما تحدث هذه الأعطال، كيف نضمن ألا تنتشر مشكلة في مكون واحد، أو مجموعة من المكونات، إلى النظام بأكمله؟ كان هذا السؤال محور اهتمامنا خلال العامين الماضيين، وبينما لا يزال العمل جارياً، فإن ما أنجزناه حتى الآن قد بدأ يؤتي ثماره بالفعل. على سبيل المثال، في النصف الأول من عام 2023، وفرنا 125 مليون ساعة تفاعل شهرياً مقارنة بالنصف الأول من عام 2022. واليوم، نشارككم العمل الذي أنجزناه بالفعل، بالإضافة إلى رؤيتنا طويلة المدى لبناء نظام بنية تحتية أكثر مرونة.

بناء نظام احتياطي

في أنظمة البنية التحتية واسعة النطاق، تحدث أعطال صغيرة عدة مرات في اليوم. إذا واجهت إحدى الآلات مشكلة واضطررت إلى إيقافها عن العمل، فهذا أمر يمكن التحكم فيه لأن معظم الشركات تحتفظ بعدة نسخ من خدماتها الخلفية. لذلك، عندما تفشل نسخة واحدة، تتولى النسخ الأخرى عبء العمل. لمعالجة هذه الأعطال المتكررة، يتم تعيين الطلبات عمومًا على إعادة المحاولة تلقائيًا في حالة حدوث خطأ.

يصبح هذا الأمر صعبًا عندما يعيد النظام أو الشخص المحاولة بشكل مفرط، مما قد يؤدي إلى انتشار هذه الأعطال الصغيرة عبر البنية التحتية إلى الخدمات والأنظمة الأخرى. إذا استمرت الشبكة أو المستخدم في إعادة المحاولة بشكل متواصل، فسوف يؤدي ذلك في النهاية إلى تحميل كل نسخة من تلك الخدمة، وربما الأنظمة الأخرى، بشكل زائد عن الحد على مستوى العالم. كان انقطاع الخدمة الذي تعرضنا له في عام 2021 نتيجة لشيء شائع إلى حد ما في الأنظمة واسعة النطاق: يبدأ الفشل صغيرًا ثم ينتشر عبر النظام، ويتضخم بسرعة كبيرة بحيث يصعب حله قبل أن يتعطل كل شيء. 

في وقت انقطاع الخدمة، كان لدينا مركز بيانات واحد نشط (مع مكونات بداخله تعمل كنسخة احتياطية). كنا بحاجة إلى القدرة على التحويل اليدوي إلى مركز بيانات جديد عندما تتسبب مشكلة ما في تعطل المركز الحالي. كانت أولويتنا الأولى هي ضمان وجود نسخة احتياطية من Roblox، لذلك أنشأنا تلك النسخة الاحتياطية في مركز بيانات جديد، يقع في منطقة جغرافية مختلفة. وقد أضاف ذلك حماية إضافية في أسوأ السيناريوهات: انقطاع الخدمة الذي ينتشر إلى عدد كافٍ من المكونات داخل مركز البيانات بحيث يصبح غير قابل للتشغيل تمامًا. لدينا الآن مركز بيانات واحد يتولى أعباء العمل (نشط) وآخر في وضع الاستعداد، يعمل كنسخة احتياطية (سلبي). هدفنا على المدى الطويل هو الانتقال من هذا التكوين النشط-السلبي إلى تكوين نشط-نشط، حيث يتولى كلا مركزي البيانات أعباء العمل، مع وجود موزع أحمال يوزع الطلبات بينهما بناءً على زمن الوصول والسعة والحالة. بمجرد تنفيذ ذلك، نتوقع الحصول على موثوقية أعلى لجميع أجزاء Roblox والقدرة على التحويل التلقائي بشكل شبه فوري بدلاً من عدة ساعات.

الانتقال إلى بنية تحتية خلوية

كانت أولويتنا التالية هي إنشاء جدران واقية قوية داخل كل مركز بيانات لتقليل احتمالية تعطل مركز البيانات بأكمله. الخلايا (تسميها بعض الشركات مجموعات) هي في الأساس مجموعة من الأجهزة وهي الطريقة التي نستخدمها لإنشاء هذه الجدران. نقوم بنسخ الخدمات داخل الخلايا وعبرها لتوفير مزيد من التكرار. في النهاية، نريد أن تعمل جميع الخدمات في Roblox داخل الخلايا حتى تستفيد من كل من الجدران الواقية القوية والتكرار. إذا لم تعد الخلية تعمل، فيمكن تعطيلها بأمان. يتيح النسخ عبر الخلايا استمرار تشغيل الخدمة أثناء إصلاح الخلية. في بعض الحالات، قد يعني إصلاح الخلية إعادة تهيئة الخلية بالكامل. في جميع أنحاء الصناعة، يعد مسح جهاز فردي أو مجموعة صغيرة من الأجهزة وإعادة تهيئتها أمرًا شائعًا إلى حد ما، ولكن القيام بذلك لخلية بأكملها، والتي تحتوي على حوالي 1400 جهاز، ليس كذلك. 

ولكي ينجح ذلك، يجب أن تكون هذه الخلايا متجانسة إلى حد كبير، حتى نتمكن من نقل أحمال العمل بسرعة وكفاءة من خلية إلى أخرى. وقد وضعنا متطلبات معينة يجب أن تفي بها الخدمات قبل تشغيلها في الخلية. على سبيل المثال، يجب أن تكون الخدمات معبأة في حاويات، مما يجعلها أكثر قابلية للنقل ويمنع أي شخص من إجراء تغييرات في التكوين على مستوى نظام التشغيل. لقد اعتمدنا فلسفة "البنية التحتية كرمز" للخلايا: في مستودع الكود المصدري الخاص بنا، نقوم بتضمين تعريف كل ما يوجد في الخلية حتى نتمكن من إعادة بنائها بسرعة من الصفر باستخدام أدوات آلية. 

لا تفي جميع الخدمات حاليًا بهذه المتطلبات، لذا عملنا على مساعدة مالكي الخدمات على تلبية هذه المتطلبات حيثما أمكن، وقمنا بإنشاء أدوات جديدة لتسهيل ترحيل الخدمات إلى الخلايا عندما تكون جاهزة. على سبيل المثال، تقوم أداة النشر الجديدة لدينا تلقائيًا بـ "توزيع" نشر الخدمة عبر الخلايا، بحيث لا يضطر مالكو الخدمات إلى التفكير في استراتيجية النسخ المتماثل. هذا المستوى من الدقة يجعل عملية الترحيل أكثر صعوبة وتستغرق وقتًا أطول، ولكن المكافأة على المدى الطويل ستكون نظامًا حيث: 

• يكون من الأسهل بكثير احتواء أي عطل ومنع انتشاره إلى الخلايا الأخرى؛ 
• يمكن لمهندسي البنية التحتية لدينا أن يكونوا أكثر كفاءة وأن يتحركوا بسرعة أكبر؛ و 
• لا يحتاج المهندسون الذين يبنون الخدمات على مستوى المنتج والتي يتم نشرها في النهاية في الخلايا إلى معرفة أو القلق بشأن الخلايا التي تعمل فيها خدماتهم.

حل التحديات الأكبر

على غرار الطريقة التي تُستخدم بها أبواب الحريق لاحتواء النيران، تعمل الخلايا كجدران مقاومة للانفجارات داخل بنيتنا التحتية للمساعدة في احتواء أي مشكلة تسبب عطلًا داخل خلية واحدة. في النهاية، سيتم نشر جميع الخدمات التي تشكل Roblox بشكل متكرر داخل الخلايا وعبرها. بمجرد اكتمال هذا العمل، قد تستمر المشكلات في الانتشار على نطاق واسع بما يكفي لتعطيل خلية بأكملها، ولكن سيكون من الصعب للغاية أن تنتشر المشكلة خارج تلك الخلية. وإذا نجحنا في جعل الخلايا قابلة للتبديل، فسيكون الاسترداد أسرع بكثير لأننا سنتمكن من التحويل إلى خلية مختلفة ومنع المشكلة من التأثير على المستخدمين النهائيين. 

يكمن التحدي في فصل هذه الخلايا بما يكفي لتقليل فرصة انتشار الأخطاء، مع الحفاظ على الأداء والوظائف. في نظام البنية التحتية المعقد، تحتاج الخدمات إلى التواصل مع بعضها البعض لمشاركة الاستعلامات والمعلومات وأحمال العمل وما إلى ذلك. وعندما ننسخ هذه الخدمات إلى خلايا، يجب أن نكون حذرين بشأن كيفية إدارة التواصل المتبادل. في العالم المثالي، نعيد توجيه حركة المرور من خلية غير سليمة إلى خلايا سليمة أخرى. ولكن كيف ندير "استعلام الموت" — الذي يتسبب في إصابة خلية بالخلل؟ إذا قمنا بإعادة توجيه هذا الاستعلام إلى خلية أخرى، فقد يتسبب ذلك في إصابة تلك الخلية بالخلل بالطريقة نفسها التي نحاول تجنبها. نحتاج إلى إيجاد آليات لتحويل حركة المرور "الجيدة" من الخلايا المعيبة مع اكتشاف وقمع حركة المرور التي تتسبب في إصابة الخلايا بالخلل. 

على المدى القصير، قمنا بنشر نسخ من خدمات الحوسبة في كل خلية حوسبة بحيث يمكن تلبية معظم الطلبات الموجهة إلى مركز البيانات بواسطة خلية واحدة. كما نقوم بتوزيع الحمل على الخلايا. وبالنظر إلى المستقبل، بدأنا في بناء عملية اكتشاف خدمات من الجيل التالي ستستفيد منها شبكة الخدمات، والتي نأمل في إكمالها في عام 2024. سيسمح لنا ذلك بتنفيذ سياسات متطورة تسمح بالاتصال عبر الخلايا فقط عندما لا يؤثر ذلك سلبًا على خلايا التحويل التلقائي. كما سيتم طرح طريقة في عام 2024 لتوجيه الطلبات التابعة إلى إصدار خدمة في نفس الخلية، مما سيقلل حركة المرور عبر الخلايا وبالتالي يقلل من مخاطر انتشار الأعطال عبر الخلايا.

في أوقات الذروة، يتم تقديم أكثر من 70 في المائة من حركة مرور خدماتنا الخلفية من خارج الخلايا، وقد تعلمنا الكثير عن كيفية إنشاء الخلايا، لكننا نتوقع المزيد من الأبحاث والاختبارات مع استمرارنا في ترحيل خدماتنا حتى عام 2024 وما بعده. ومع تقدمنا، ستصبح هذه الجدران الواقية أقوى بشكل متزايد.

ترحيل بنية تحتية تعمل بشكل مستمر

Roblox هي منصة عالمية تدعم المستخدمين في جميع أنحاء العالم، لذا لا يمكننا نقل الخدمات خلال أوقات الذروة أو "أوقات التوقف"، مما يزيد من تعقيد عملية ترحيل جميع أجهزتنا إلى خلايا وتشغيل خدماتنا في تلك الخلايا. لدينا ملايين التجارب التي تعمل بشكل مستمر والتي تحتاج إلى استمرار الدعم، حتى أثناء نقل الأجهزة التي تعمل عليها والخدمات التي تدعمها. عندما بدأنا هذه العملية، لم يكن لدينا عشرات الآلاف من الأجهزة التي لا تُستخدم ومتاحة لنقل أحمال العمل هذه إليها. 

ومع ذلك، كان لدينا عدد صغير من الأجهزة الإضافية التي تم شراؤها تحسبًا للنمو المستقبلي. في البداية، أنشأنا خلايا جديدة باستخدام تلك الأجهزة، ثم قمنا بترحيل أحمال العمل إليها. نحن نقدر الكفاءة والموثوقية، لذا بدلاً من الخروج وشراء المزيد من الأجهزة بمجرد نفاد الأجهزة "الاحتياطية"، قمنا ببناء المزيد من الخلايا عن طريق مسح وإعادة تهيئة الأجهزة التي قمنا بالترحيل منها. ثم قمنا بترحيل أحمال العمل إلى تلك الأجهزة التي أعيد تهيئتها، وبدأنا العملية من جديد. هذه العملية معقدة — فمع استبدال الأجهزة وتحريرها لدمجها في الخلايا، لا يتم تحريرها بطريقة مثالية ومنظمة. فهي مجزأة ماديًا عبر قاعات البيانات، مما يجبرنا على تهيئتها بشكل مجزأ، الأمر الذي يتطلب عملية إلغاء التجزئة على مستوى الأجهزة للحفاظ على توافق مواقع الأجهزة مع مجالات الأعطال المادية واسعة النطاق. 

يركز جزء من فريق هندسة البنية التحتية لدينا على ترحيل أحمال العمل الحالية من بيئتنا القديمة، أو "ما قبل الخلايا"، إلى الخلايا. سيستمر هذا العمل حتى ننتهي من ترحيل آلاف الخدمات المختلفة للبنية التحتية وآلاف الخدمات الخلفية إلى الخلايا المبنية حديثًا. نتوقع أن يستغرق هذا الأمر العام المقبل بأكمله وربما يمتد إلى عام 2025، بسبب بعض العوامل المعقدة. أولاً، يتطلب هذا العمل إنشاء أدوات قوية. على سبيل المثال، نحتاج إلى أدوات لإعادة التوازن تلقائيًا لعدد كبير من الخدمات عند نشر خلية جديدة — دون التأثير على مستخدمينا. كما لاحظنا خدمات تم إنشاؤها بناءً على افتراضات حول بنيتنا التحتية. نحتاج إلى مراجعة هذه الخدمات حتى لا تعتمد على أمور قد تتغير في المستقبل مع انتقالنا إلى الخلايا. كما قمنا بتنفيذ طريقة للبحث عن أنماط التصميم المعروفة التي لن تعمل بشكل جيد مع بنية الخلايا، بالإضافة إلى عملية اختبار منهجية لكل خدمة يتم ترحيلها. تساعدنا هذه العمليات على تجنب أي مشكلات تواجه المستخدمين بسبب عدم توافق الخدمة مع الخلايا.

اليوم، يتم إدارة ما يقرب من 30,000 جهاز بواسطة الخلايا. هذا ليس سوى جزء بسيط من مجموع أجهزتنا، ولكن الانتقال كان سلسًا للغاية حتى الآن دون أي تأثير سلبي على اللاعبين. هدفنا النهائي هو أن تحقق أنظمتنا وقت تشغيل بنسبة 99.99 في المائة للمستخدمين كل شهر، مما يعني أننا لن نتسبب في انقطاع لا يزيد عن 0.01 في المائة من ساعات التفاعل. على مستوى الصناعة، لا يمكن القضاء على فترات التعطل تمامًا، ولكن هدفنا هو تقليل أي فترات تعطل في Roblox إلى درجة تجعلها غير ملحوظة تقريبًا.

التأهب للمستقبل مع توسعنا

على الرغم من نجاح جهودنا المبكرة، إلا أن عملنا على الخلايا لم ينته بعد. مع استمرار توسع Roblox، سنواصل العمل على تحسين كفاءة ومرونة أنظمتنا من خلال هذه التقنية وغيرها. مع تقدمنا، ستصبح المنصة أكثر مرونة في مواجهة المشكلات، وستصبح أي مشكلات تحدث أقل وضوحًا وتأثيرًا على المستخدمين على منصتنا.

باختصار، حتى الآن، قمنا بما يلي: 

• بناء مركز بيانات ثانٍ وتحقيق حالة نشطة/سلبية بنجاح. 
• أنشأنا خلايا في مراكز البيانات النشطة والسلبية لدينا ونجحنا في ترحيل أكثر من 70 في المائة من حركة مرور خدماتنا الخلفية إلى هذه الخلايا.
• وضعنا المتطلبات وأفضل الممارسات التي سنحتاج إلى اتباعها للحفاظ على توحيد جميع الخلايا بينما نواصل ترحيل بقية بنيتنا التحتية. 
• بدأنا عملية مستمرة لبناء "جدران واقية" أقوى بين الخلايا. 

مع زيادة قابلية التبادل بين هذه الخلايا، سيقل التداخل بينها. وهذا يفتح لنا بعض الفرص المثيرة للاهتمام من حيث زيادة الأتمتة في مجالات المراقبة واستكشاف الأخطاء وإصلاحها، وحتى تحويل أحمال العمل تلقائيًا. 

في سبتمبر، بدأنا أيضًا في إجراء تجارب نشطة/نشطة عبر مراكز البيانات لدينا. هذه آلية أخرى نختبرها لتحسين الموثوقية وتقليل أوقات التحويل التلقائي. ساعدت هذه التجارب في تحديد عدد من أنماط تصميم النظام، التي تدور بشكل كبير حول الوصول إلى البيانات، والتي نحتاج إلى إعادة صياغتها بينما نسعى نحو أن نصبح نشطين-نشطين بالكامل. بشكل عام، كانت التجربة ناجحة بما يكفي لتركها تعمل لحركة المرور من عدد محدود من مستخدمينا.