مع نمو Roblox على مدار أكثر من 16 عامًا الماضية، فقد تطور أيضًا حجم وتعقيد البنية التحتية التقنية التي تدعم الملايين من التجارب المشتركة ثلاثية الأبعاد الغامرة. لقد تضاعف عدد الأجهزة التي ندعمها أكثر من ثلاثة أضعاف خلال العامين الماضيين، من حوالي 3 جهاز اعتبارًا من 36,000 يونيو 30 إلى ما يقرب من 2021 جهاز اليوم. يتطلب دعم هذه التجارب الدائمة للأشخاص في جميع أنحاء العالم أكثر من 145,000 خدمة داخلية. لمساعدتنا في التحكم في التكاليف وزمن وصول الشبكة، نقوم بنشر هذه الأجهزة وإدارتها كجزء من بنية أساسية سحابية خاصة ومختلطة ومصممة خصيصًا والتي تعمل بشكل أساسي في أماكن العمل.
تدعم بنيتنا التحتية حاليًا أكثر من 70 مليون مستخدم نشط يوميًا حول العالم، بما في ذلك المبدعين الذين يعتمدون على Roblox اقتصاد لأعمالهم. كل هؤلاء الملايين من الناس يتوقعون مستوى عالٍ جدًا من الموثوقية. نظرًا للطبيعة الغامرة لتجاربنا، فإن التسامح مع التأخير أو الكمون منخفض للغاية، ناهيك عن انقطاع الخدمة. Roblox عبارة عن منصة للتواصل والتواصل، حيث يجتمع الأشخاص معًا في تجارب ثلاثية الأبعاد غامرة. عندما يتواصل الأشخاص كصور رمزية خاصة بهم في مساحة غامرة، فإن التأخير أو الأخطاء البسيطة تكون أكثر وضوحًا مما هي عليه في سلسلة رسائل نصية أو مكالمة جماعية.
في أكتوبر 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 بالمائة من حركة مرور الخدمة الخلفية لدينا إلى هذه الخلايا.
- قم بوضع المتطلبات وأفضل الممارسات التي سنحتاج إلى اتباعها للحفاظ على توحيد جميع الخلايا بينما نواصل ترحيل بقية بنيتنا التحتية.
- بدأت عملية مستمرة لبناء "جدران انفجارية" أقوى بين الخلايا.
عندما تصبح هذه الخلايا أكثر قابلية للتبديل، سيكون هناك تداخل أقل بين الخلايا. يفتح هذا بعض الفرص المثيرة للاهتمام بالنسبة لنا فيما يتعلق بزيادة التشغيل الآلي للمراقبة واستكشاف الأخطاء وإصلاحها وحتى تحويل أعباء العمل تلقائيًا.
وفي شهر سبتمبر، بدأنا أيضًا في إجراء تجارب نشطة/نشطة عبر مراكز البيانات لدينا. هذه آلية أخرى نقوم باختبارها لتحسين الموثوقية وتقليل أوقات تجاوز الفشل. ساعدت هذه التجارب في تحديد عدد من أنماط تصميم النظام، والتي تتعلق إلى حد كبير بالوصول إلى البيانات، والتي نحتاج إلى إعادة صياغتها بينما نمضي قدماً نحو أن نصبح نشطين بالكامل. بشكل عام، كانت التجربة ناجحة بما يكفي لتركها قيد التشغيل لحركة المرور الواردة من عدد محدود من مستخدمينا.
نحن متحمسون لمواصلة دفع هذا العمل إلى الأمام لتحقيق قدر أكبر من الكفاءة والمرونة للنظام الأساسي. إن هذا العمل على الخلايا والبنية التحتية النشطة النشطة، إلى جانب جهودنا الأخرى، سيمكننا من النمو لنصبح أداة موثوقة وعالية الأداء لملايين الأشخاص ومواصلة التوسع بينما نعمل على توصيل مليار شخص فعليًا وقت.
- محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
- PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
- أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
- أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
- أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
- المصدر https://blog.roblox.com/2023/12/making-robloxs-infrastructure-efficient-resilient/
