أسوأ يوم في سلاك

توضح هذه المقالة التفاصيل الفنية للمشكلات التي تسببت في تعطل Slack في 12 مايو 2020. لمعرفة المزيد عن عملية الرد على هذا الحادث ، انظر التسلسل الزمني لريان كاتكوف ، "كلتا يديك على جهاز التحكم عن بعد" .



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



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



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



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



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



خلف موازن تحميل Layer 4 هو مجموعة من مثيلات HAProxy لتوزيع الطلبات على مستوى تطبيق الويب. نحن نستخدم القنصل لاكتشاف الخدمة ونموذج القنصل لتقديم قوائم بخلفية تطبيقات الويب السليمة التي يجب على HAProxy توجيه الطلبات إليها.





تين. 1. عرض عالي المستوى لهندسة موازنة التحميل Slack



ومع ذلك ، فإننا لا نعرض قائمة مضيفي تطبيقات الويب مباشرة من ملف تكوين HAProxy ، لأن تحديث القائمة في هذه الحالة يتطلب إعادة تشغيل HAProxy. تتضمن عملية إعادة تشغيل HAProxy إنشاء عملية جديدة تمامًا ، مع الحفاظ على العملية القديمة حتى تنتهي من معالجة الطلبات الحالية. يمكن أن تؤدي عمليات إعادة التشغيل المتكررة جدًا إلى الكثير من عمليات HAProxy قيد التشغيل وضعف الأداء. يتعارض هذا القيد مع هدف تغيير مستوى تطبيق الويب تلقائيًا ، وهو إدخال مثيلات جديدة في الإنتاج في أسرع وقت ممكن. لذلك ، نحن نستخدم HAProxy Runtime APIلإدارة حالة خادم HAProxy دون إعادة التشغيل في كل مرة يدخل فيها خادم طبقة الويب أو يخرج. تجدر الإشارة إلى أن HAProxy يمكنه الاندماج مع واجهة Consul DNS ، ولكن هذا يضيف تأخرًا بسبب TTL لـ DNS ، ويحد من القدرة على استخدام علامات Consul ، وإدارة استجابات DNS الكبيرة غالبًا ما تؤدي إلى مواقف وأخطاء حادة مؤلمة.





تين. 2. كيف تتم إدارة مجموعة من تطبيقات الويب الخلفية على خادم Slack HAProxy واحد



في حالة HAProxy الخاصة بنا ، نحدد قوالب لخوادم HAProxy. في الواقع ، هذه "فتحات" يمكن أن تحتلها تطبيقات الويب الخلفية. عندما يتم طرح مثيل لتطبيق ويب جديد أو عندما يبدأ التطبيق القديم في الفشل ، يتم تحديث كتالوج خدمة القنصل. يطبع قالب القنصل إصدارًا جديدًا من قائمة المضيف ، ويقرأ برنامج إدارة حالة haproxy-server-state منفصل الذي تم تطويره في Slack قائمة المضيف هذه ويستخدم HAProxy Runtime API لتحديث حالة HAProxy.



نقوم بتشغيل تجمعات HAProxy Instance المتزامنة ومجمعات تطبيقات الويب المتزامنة ، كل منها في منطقة توفر AWS منفصلة. تم تكوين HAProxy مع N "فتحات" لخلفية تطبيقات الويب في كل AZ ، مما يعطي إجماليًا للخلفية N * M التي يمكن توجيهها إلى جميع AZ. قبل بضعة أشهر ، كان هذا الرقم أكثر من كافٍ - لم نطلق أي شيء قريبًا حتى من العديد من مثيلات تطبيق الويب لدينا. ومع ذلك ، بعد حادثة قاعدة البيانات الصباحية ، أطلقنا أكثر قليلاً من مثيلات تطبيق الويب N * M. إذا كنت تعتقد أن فتحات HAProxy هي لعبة كراسي عملاقة ، فإن بعض حالات تطبيق الويب هذه تُترك بدون مساحة. لم تكن هذه مشكلة - لدينا سعة خدمة أكثر من كافية.



تين. 3. "فتحات" في عملية HAProxy مع بعض مثيلات تطبيقات الويب الزائدة التي لا تتلقى حركة المرور



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



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



تين. 4. تغيرت حالة HAProxy بمرور الوقت وبدأت الفتحات تشير بشكل أساسي إلى المضيفين البعيدين ،



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



لم نعيد صياغة مكدس HAProxy هذا كثيرًا ، لأننا ننقل تدريجيًا جميع موازنة التحميل إلى Envoy (لقد نقلنا مؤخرًا حركة مرور الويب). عمل HAProxy بشكل جيد وموثوق به لسنوات عديدة ، ولكن لديه بعض المشكلات التشغيلية كما هو الحال في هذا الحادث. سنستبدل خط الأنابيب المعقد لإدارة حالة خادم HAProxy بتكاملنا الخاص مع Envoy مع مستوى التحكم xDS لاكتشاف نقطة النهاية. أحدث الإصدارات من HAProxy (منذ الإصدار 2.0) تحل أيضًا العديد من هذه المشاكل التشغيلية. ومع ذلك ، كنا نثق في Envoy بشبكة الخدمة الداخلية لبعض الوقت الآن ، لذلك نسعى جاهدين لتحويل موازنة التحميل إليها أيضًا. يبدو اختبارنا الأولي لـ Envoy + xDS على نطاق واسع واعدًا ، ومن المفترض أن يؤدي هذا الترحيل إلى تحسين الأداء والتوافر في المستقبل.البنية الجديدة لموازنة الحمل واكتشاف الخدمة محصنة ضد المشكلة التي تسببت في هذا الفشل.



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