انقطاع التيار الكهربائي في 29 أبريل: ماذا حدث، ولماذا حدث، وكيف نستجيب

فهم بنية خدمات منصة Braze

تحتفظ Braze بمجموعات منفصلة من الخوادم لكل مجموعة من مجموعاتنا الثمانية في الولايات المتحدة. تتم استضافة مجموعات Braze US 01 إلى 07 على Amazon Web Services (AWS)، بينما تتم استضافة مجموعة Braze US 08 على Microsoft Azure. في كل من هذه البيئات، يستخدم Braze مناطق توفر متعددة ولديه تكرارات لكل جزء من نظامنا. في حالة فشل منطقة الإتاحة، نقوم بشكل روتيني وشفاف بتعطيل مناطق الإتاحة المعطلة من التوجيه والمعالجة. يتيح لنا ذلك الحفاظ على إمكانية تقديم الخدمة بشكل موثوق أثناء انقطاع مزود الخدمة السحابية.

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

نظرًا لكثافة عبء عمل المعالجة في الوقت الفعلي لمنصة Braze، قمنا منذ عام 2013 بتكملة استخدامنا لـ AWS وAzure من خلال الشراكة مع Rackspace لاستضافة أجهزة تم تكوينها خصيصًا لتشغيل قواعد بيانات MongoDB. تم تكوين بيئات AWS وAzure الخاصة بنا باستخدام موصلات السحابة الخاصة AWS Direct Connect وAzure ExpressRoute، التي تربط البيئة السحابية بشبكتنا الداخلية التي تتم صيانتها في مراكز بيانات Rackspace عبر كابل ألياف ضوئية مخصص. يوفر هذا الاتصال المشفر، والذي يتم تشغيله بواسطة روابط الشبكة التي تدعم واجهات متعددة تدفع أكثر من 100 جيجابت من حركة مرور الشبكة في الثانية، وصولاً عالي الأداء بين السحابة الخاصة بنا وبيئات Rackspace.

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

سبب انقطاع الخدمة في 29 أبريل وكيف استجبنا

فشل التبديل الجزئي الأولي

في 29 أبريل الساعة 09:15 بالتوقيت العالمي، حدث فشل جزئي في محول شبكة Cisco Nexus الأساسي المتصل بخزائن خادم Rackspace لدينا. فشل المفتاح المعطل بطريقة لم تؤدي إلى تنشيط مفتاح الشبكة الثانوي تلقائيًا عبر تجاوز الفشل، وبدلاً من ذلك احتفظ بالمفتاح المعطل كمفتاح أساسي.

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

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

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

علاج Rackspace

نتيجة لهذا النشاط، تلقى مهندسو مركز بيانات Rackspace تنبيهات في حوالي الساعة 09:20 بالتوقيت العالمي المنسق فيما يتعلق بمشكلات الاتصال بالشبكة غير المتوقعة وبدأوا في معالجة المشكلة. بين الساعة 09:39 والساعة 10:03 بالتوقيت العالمي المنسق، قام مهندسو مركز بيانات Rackspace بتعليق محول الشبكة، وإعادة تدوير الطاقة للمحول الأساسي، وإجبار بطاقات واجهة الشبكة (NIC) في خزانة الخادم على تجاوز الفشل إلى المحول الثانوي. بعد تجاوز فشل NIC، تمت استعادة الاتصال بالخوادم الفعلية في بيئة Braze.

كيف تعمل قواعد بيانات Braze MongoDB

تسمح قواعد بيانات MongoDB التي يستخدمها Braze بتخزين البيانات عبر خوادم قواعد بيانات متعددة تُعرف باسم "الأجزاء". توفر MongoDB خدمة توجيه تسمى "mongoS"، والتي تعالج الاستعلامات من خدمات منصة Braze، وتحدد موقع البيانات ذات الصلة في مجموعة مقسمة، ثم توجه الاستعلام إلى قاعدة بيانات MongoDB المناسبة. لدى Braze المئات من قواعد بيانات MongoDB المتميزة، والتي تضم أكثر من 15000 عملية "mongoD"، وهي البرامج التي تقوم بتشغيل قاعدة البيانات وتخزين البيانات لجزء MongoDB معين.

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

تأثير حلقة الشبكة على عمليات MongoDB وكيفية استجابتنا لها

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

في هذه المرحلة، ومن أجل المساعدة في جهود الإصلاح التي يبذلها فريق مسؤول قاعدة بيانات Rackspace (DBA)، بدأت فرق Braze DevOps في تصحيح الأخطاء واختبار طرق استعادة هذا الاتصال بسرعة. توصل تحقيقنا إلى أن الخيار الوحيد المتاح هو إعادة تشغيل كل عملية من عمليات mongoD التي يبلغ عددها حوالي 16000 وما يزيد عن 6000 عملية mongoS في حاوياتها الافتراضية. نظرًا للحجم الهائل لهذا المشروع وحقيقة أن الأتمتة لم تكن موجودة لإعادة تشغيل العديد من الحاويات بسرعة، كتب مهندسو Rackspace تعليمات برمجية جديدة أثناء الحادث لإنشاء قدرة أتمتة سريعة.

لسوء الحظ، مع تكثيف عملية إعادة التشغيل، ظهرت مشكلة أخرى في نظام نظام أسماء النطاقات (DNS). عندما تصبح عمليات mongoS وmongoD متاحة عبر الإنترنت، فإنها تطلب معلومات من محللي DNS في عملية تُعرف باسم بحث DNS. مع عمليات البحث المستمرة لنظام أسماء النطاقات (DNS) المدفوعة بسرعة عمليات إعادة التشغيل، تعرضت خوادم DNS لحمل ثقيل، مما أدى إلى انتهاء مهلة الاتصال على طبقات mongoS أثناء إعادة اتصالها بعمليات mongoD. لاستيعاب هذا الحمل المتزايد، قام فريق Rackspace لدينا بزيادة سعة وحدة المعالجة المركزية لنظام أسماء النطاقات (DNS)، ولكنه اضطر بعد ذلك إلى إعادة تشغيل طبقة mongoS مرة ثانية من أجل إنشاء اتصالات سليمة من كل mongoS إلى عمليات mongoD المرتبطة بها.

حوالي الساعة 17:05 بالتوقيت العالمي، سمحت عملية إعادة التشغيل لبعض المجموعات بالبدء في العودة إلى الإنترنت. ومع تعافي أداء قاعدة البيانات واستقرار المجموعات، واصلت Braze زيادة قدرة معالجة البيانات وإرسال الرسائل؛ ومع ذلك، فقد تعقدت هذه الجهود بسبب التراكم الهائل الناتج عن عدم التوفر مسبقًا.

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

ومع ذلك، من خلال القيام بذلك، وصل Braze إلى حد AWS لعدد وحدات المعالجة المركزية الافتراضية التي تمكنا من توفيرها، مما يمنعنا من إضافة أي سعة خادم إضافية. قام فريق Braze بتصعيد هذا الظرف بسرعة مع فريق AWS لدينا وحصل على زيادة، مما سمح لمهندسينا برفع سعة معالجة الخادم لدينا إلى مستوى قياسي، والذي كان أعلى بنسبة تزيد عن 50% من السعة القصوى السابقة لدينا، والتي تم الوصول إليها على Black الجمعة 2023.

بحلول الساعة 20:30 بالتوقيت العالمي، كانت جميع مجموعاتنا في الولايات المتحدة باستثناء US 01 وUS 03 وUS 08 قد انتهت من معالجة الأعمال المتراكمة، وكانت تلك المجموعات المتبقية تعالج بمعدلات الذروة أو أعلى من اليوم السابق للحادث. وفي غضون ساعات قليلة، تمت إعادة جميع المجموعات إلى المعالجة في الوقت الفعلي وأعلنا أن الحادث قد تم حله.

كيف يقوم Braze بتوصيل التحديثات أثناء الحوادث

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

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

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

كيف تابع Braze الحادث وخطط الوقاية المستقبلية

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

منذ وقوع الحادث، قامت Braze وRackspace باستبدال المفتاح المعيب واستبداله، وأكمل فريق هندسة Rackspace مراجعة كاملة للبنية التحتية للشبكات التي تعتمد عليها خدمات Braze. في حين أنه من الصعب للغاية التنبؤ بأعطال الأجهزة، خاصة مع المعدات المشمولة بالضمان، إلا أن المراقبة موجودة لاكتشاف العيوب ولضمان الاستجابة السريعة. يتعاون كلا الفريقين الآن لإجراء تغييرات من شأنها منع تكرار حلقات الشبكة في المستقبل، حتى في حالة حدوث خلل في المعدات. سيستغرق تنفيذ بعض تغييرات الشبكة وقتًا، حيث نخطط لإجراء تغييرات ذات معنى على هيكل شبكتنا لتحسين الحماية ضد الحلقات بشكل أكبر. لقد فتحنا أيضًا تذاكر دعم مع كل من Cisco وMongoDB لفهم سيناريوهات الفشل التي واجهناها بشكل أفضل، ولتحسين قدرة عمليات mongoD وmongoS على الإصلاح الذاتي في أعقاب فشل الشبكة.

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

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

- جون