في الصباح الباكر من يوم 19 مايو (بتوقيت شرق الولايات المتحدة) ، تحطمت quay.io. أثرت الكارثة على مستهلكي quay.io ومشاريع المصادر المفتوحة التي تستخدم quay.io كمنصة لبناء وتوزيع البرامج. ريد هات تقدر ثقة كليهما.
قفز فريق مهندسي SRE على الفور وحاولوا تثبيت خدمة Quay في أسرع وقت ممكن. ومع ذلك ، أثناء قيامهم بذلك ، لم يعد العملاء قادرين على دفع الصور الجديدة ، وفي بعض الأحيان فقط كانوا قادرين على سحب الصور الموجودة. لسبب غير معروف ، تم تأمين قاعدة بيانات quay.io بعد توسيع نطاق الخدمة إلى السعة الكاملة.
" ما الذي تغير؟ - هذا هو السؤال الأول الذي يطرح عادة في مثل هذه الحالات. لاحظنا أنه قبل حدوث المشكلة بوقت قصير ، بدأت مجموعة OpenShift المخصصة (التي يعمل عليها quay.io) بالتحديث إلى الإصدار 4.3.19. نظرًا لأن quay.io مدعوم من Red Hat OpenShift Dedicated (OSD) ، كانت التحديثات المنتظمة شائعة ولم تسبب مشكلات مطلقًا. علاوة على ذلك ، خلال الأشهر الستة الماضية ، قمنا بترقية مجموعات الرصيف عدة مرات دون أي انقطاع في الخدمة.
بينما كنا نحاول استعادة الخدمة ، بدأ مهندسون آخرون في إعداد مجموعة OSD جديدة مع الإصدار السابق من البرنامج من أجل نشر كل شيء عليها في حالة وجود أي شيء.
تحليل السبب الجذري
كان العَرَض الرئيسي للانهيار هو انهيار عشرات الآلاف من اتصالات قواعد البيانات التي جعلت مثيل MySQL غير قابل للاستخدام. هذا جعل من الصعب تشخيص المشكلة. لقد وضعنا حدًا أقصى لعدد الاتصالات من العملاء لمساعدة فريق SRE في تقييم المشكلة. لم نلاحظ أي حركة مرور غير عادية لقاعدة البيانات: في الواقع ، كانت معظم الطلبات للقراءات ، وكان القليل منها فقط للكتابة.
حاولنا أيضًا تحديد نمط في حركة مرور قاعدة البيانات يمكن أن يتسبب في هذا الانهيار. ومع ذلك ، لم يكن من الممكن العثور على أي أنماط في السجلات. أثناء انتظار المجموعة الجديدة مع OSD 4.3.18 لتكون جاهزة ، واصلنا محاولة إطلاق quay.io pods. في كل مرة تكون الكتلة فيها بكامل طاقتها ، يتم تجميد قاعدة البيانات. هذا يعني أنه كان من الضروري إعادة تشغيل مثيل RDS بالإضافة إلى جميع pods quay.io.
بحلول المساء ، قمنا بتثبيت الخدمة في وضع القراءة فقط وقمنا بتعطيل الحد الأقصى من الوظائف غير الأساسية (على سبيل المثال ، جمع البيانات المهملة في مساحة الاسم) لتقليل الحمل على قاعدة البيانات. توقفت عمليات التعليق ، لكن لم يتم العثور على السبب . كانت مجموعة OSD الجديدة جاهزة ، وقمنا بترحيل الخدمة وحركة المرور المتصلة والمراقبة المستمرة.
عمل Quay.io بثبات على مجموعة OSD الجديدة ، لذلك عدنا إلى سجلات قاعدة البيانات ، لكن لم نتمكن من العثور على ارتباط يشرح الأقفال. عمل مهندسو OpenShift معنا لمعرفة ما إذا كانت التغييرات في Red Hat OpenShift 4.3.19 قد تسببت في حدوث مشكلات في Quay. ومع ذلك ، لم يتم العثور على أي شيء ، ولا يمكن تكرار المشكلة في المختبر .
الفشل الثاني
في 28 مايو ، قبل وقت قصير من الظهر بتوقيت شرق الولايات المتحدة ، تعطل quay.io مرة أخرى بنفس الأعراض: تم حظر قاعدة البيانات. مرة أخرى ، ألقينا بكل قوتنا في التحقيق. بادئ ذي بدء ، كان من الضروري استعادة الخدمة. ومع ذلك ، فإن إعادة تشغيل RDS وإعادة تشغيل quay.io pods لم تؤد هذه المرة إلى أي شيء : فقد اجتاح سيل آخر من الاتصالات القاعدة. لكن لماذا؟
الرصيف مكتوب بلغة بايثون ويعمل كل جراب كحاوية واحدة متجانسة. تعمل العديد من المهام المتوازية بشكل متزامن في وقت تشغيل الحاوية. نحن نستخدم مكتبة
geventتحتgunicornلمعالجة طلبات الويب. عندما يتلقى Quay طلبًا (عبر واجهة برمجة التطبيقات الخاصة بنا ، أو عبر Docker API) ، يتم تعيين عامل gevent إليه. عادة ، يحتاج هذا العامل إلى التواصل مع قاعدة البيانات. بعد الفشل الأول ، وجدنا أن العمال الجاد كانوا يتصلون بقاعدة البيانات باستخدام الإعدادات الافتراضية.
نظرًا للعدد الكبير من وحدات Quay pods وآلاف الطلبات الواردة في الثانية ، فإن العدد الكبير من اتصالات قاعدة البيانات يمكن نظريًا تحميل مثيل MySQL بشكل زائد. بفضل المراقبة ، كان من المعروف أن Quay يعالج ما معدله 5 آلاف طلب في الثانية. كان عدد الاتصالات بقاعدة البيانات متماثلًا تقريبًا. 5 آلاف اتصال بهامش يتناسب مع إمكانات مثيل RDS (والذي لا يمكن قوله عن عشرات الآلاف).لسبب ما ، كانت هناك طفرات غير متوقعة في عدد الاتصالات ، ومع ذلك لم نلاحظ أي ارتباط مع الطلبات الواردة.
هذه المرة ، كنا مصممين على البحث عن مصدر المشكلة وإصلاحه ، وليس مجرد إعادة التشغيل. تم إجراء تغييرات على قاعدة بيانات Quay للحد من عدد اتصالات قاعدة البيانات لكل عامل gevent . أصبح هذا الرقم معلمة في التكوين: أصبح من الممكن تغييره "سريعًا" دون إنشاء صورة حاوية جديدة. لمعرفة عدد الاتصالات التي يجب معالجتها فعليًا ، أجرينا عدة اختبارات مع بيئة مرحلية تحدد قيمًا مختلفة لمعرفة كيف سيؤثر ذلك على سيناريوهات اختبار الحمل. نتيجة لذلك ، اتضح أنيبدأ Quay بإلقاء أخطاء 502 عندما يتجاوز عدد الاتصالات 10 كيلو.
لقد نشرنا هذا الإصدار الجديد على الفور في الإنتاج وبدأنا في مراقبة جدول اتصال قاعدة البيانات. في الماضي ، تم إغلاق القاعدة بعد حوالي 20 دقيقة. بعد 30 دقيقة خالية من المتاعب ، كان لدينا أمل ، وبعد ساعة ، الثقة. استعدنا حركة المرور إلى المنشور على الموقع وبدأنا تحليل ما بعد الوفاة.
بعد أن تمكنا من حل المشكلة التي أدت إلى الحجب ، لم نكتشف أسبابها الحقيقية . تم التأكيد على أنها لا تتعلق بأي تغييرات في OpenShift 4.3.19 ، كما حدث في الإصدار 4.3.18 ، والذي كان يعمل سابقًا مع Quay دون أي مشاكل.
من الواضح أنه كان هناك شيء آخر كامن في المجموعة.
دراسة تفصيلية
يستخدم Quay.io الإعدادات الافتراضية للاتصال بقاعدة البيانات لمدة ست سنوات دون أي مشاكل. ما الذي تغير؟ من الواضح أن حركة المرور إلى quay.io نمت بشكل مطرد طوال هذا الوقت. في حالتنا ، بدا كل شيء كما لو تم الوصول إلى قيمة حدية معينة ، والتي كانت بمثابة حافز لفيض من الاتصالات. واصلنا فحص سجلات قاعدة البيانات بعد الانهيار الثاني ، لكننا لم نجد أي أنماط أو علاقات واضحة.
في غضون ذلك ، كان فريق SRE يعمل على تحسين إمكانية ملاحظة استعلام Quay وصحة الخدمة بشكل عام. تم نشر مقاييس ولوحات معلومات جديدة توضح أجزاء Quay الأكثر طلبًا من العملاء.
عمل Quay.io بشكل جيد حتى 9 يونيو. في الصباح (عبر EDT) ، شهدنا مرة أخرى زيادة كبيرة في عدد اتصالات قاعدة البيانات. هذه المرة ، لم يكن هناك توقف ، حيث حدت المعلمة الجديدة من عددها ولم تسمح بتجاوز عرض النطاق الترددي لـ MySQL. ومع ذلك ، لمدة نصف ساعة تقريبًا ، لاحظ العديد من المستخدمين أن quay.io كان بطيئًا. قمنا بسرعة بجمع جميع البيانات الممكنة باستخدام أدوات المراقبة المضافة. ظهر نمط فجأة.
قبل قفزة الاتصالات مباشرة ، تم إرسال عدد كبير من الطلبات إلى App Registry API... App Registry هو ميزة غير معروفة لـ quay.io. يسمح لك بتخزين أشياء مثل مخططات Helm والحاويات الغنية بالبيانات الوصفية. لا يستخدم معظم مستخدمي quay.io هذه الميزة ، لكن Red Hat OpenShift يستخدمها بنشاط. يقوم OperatorHub داخل OpenShift بتخزين جميع المشغلين في App Registry. تشكل شركات النقل هذه الأساس لنظام OpenShift لأعباء العمل ونموذج التشغيل المرتكز على الشريك (في إطار عمليات اليوم الثاني).
تستخدم كل مجموعة OpenShift 4 مشغلين من OperatorHub المدمج لنشر كتالوج المشغلين المتاحين للتثبيت وتوفير التحديثات لأولئك المثبتين بالفعل. مع تزايد شعبية OpenShift 4 ، زاد أيضًا عدد المجموعات الموجودة عليه حول العالم. تقوم كل مجموعة من هذه المجموعات بتحميل محتوى المشغل لتشغيل OperatorHub المدمج ، باستخدام App Registry داخل quay.io كخلفية. عند البحث عن مصدر المشكلة ، فاتنا حقيقة أنه مع زيادة شعبية OpenShift تدريجيًا ، زاد الحمل على إحدى وظائف quay.io التي نادرًا ما تستخدم .
لقد أجرينا بعض التحليلات لحركة طلب سجل التطبيقات وفحصنا رمز التسجيل. على الفور ، تم الكشف عن عيوب ، بسبب الاستفسارات لقاعدة البيانات التي تم تشكيلها دون المستوى الأمثل. لم تسبب أي مشكلة في ظل الحمل الخفيف ، ولكن عندما ازدادت أصبحت مصدرًا للمشاكل. تبين أن سجل التطبيقات يحتوي على نقطتي نهاية إشكاليتين لم تستجيب بشكل جيد لزيادة التحميل: الأولى أعطت قائمة بجميع الحزم في المستودع ، والثانية أعادت جميع النقاط لحزمة.
القضاء على الأسباب
على مدار الأسبوع المقبل ، قمنا بتحسين كود سجل التطبيقات نفسه وبيئته. من الواضح أنه تم إعادة صياغة استعلامات SQL غير الفعالة ، وتم حذف المكالمات غير الضرورية للأمر
tar(تم تشغيله في كل مرة يتم فيها جلب النقطة) ، وتمت إضافة التخزين المؤقت حيثما أمكن ذلك. ثم أجرينا اختبارًا مكثفًا للأداء وقارننا أداء سجل التطبيقات قبل التغييرات وبعدها.
طلبات واجهة برمجة التطبيقات التي كانت تستغرق ما يصل إلى نصف دقيقة تم إكمالها الآن بالمللي ثانية . لقد طرحنا التغييرات على الإنتاج في الأسبوع التالي واستقر quay.io منذ ذلك الحين. خلال هذا الوقت ، كان هناك العديد من الارتفاعات في حركة المرور في نقطة نهاية App Registry ، لكن التحسينات التي تم إجراؤها حالت دون انقطاع قاعدة البيانات.
ماذا تعلمنا؟
من الواضح أن أي خدمة تحاول تجنب التوقف. في حالتنا ، نعتقد أن الحوادث الأخيرة ساعدت في تحسين quay.io. لأنفسنا ، تعلمنا العديد من الدروس الرئيسية التي نريد مشاركتها:
- البيانات حول من يستخدم خدمتك وكيف لا لزوم لها . نظرًا لأن Quay "نجح للتو" ، لم نضطر أبدًا إلى قضاء الوقت في تحسين حركة المرور وإدارة الحمل. كل هذا خلق إحساسًا زائفًا بالأمان بأن الخدمة يمكن أن تتسع إلى أجل غير مسمى.
- , — . Quay , . , — , .
- تقييم تأثير كل من وظائف الخدمة . نادرًا ما يستخدم العملاء سجل التطبيقات ، لذلك لم يكن يمثل أولوية بالنسبة لفريقنا. عندما يتم استخدام بعض ميزات المنتج نادرًا ، نادرًا ما "تظهر" الأخطاء ، ويتوقف المطورون عن مراقبة الشفرة. من السهل الوقوع فريسة للوهم بأن هذه هي الطريقة التي ينبغي أن تكون عليها - حتى تصبح هذه الميزة فجأة في قلب حادث ضخم.
ماذا بعد؟
لا يتوقف العمل لضمان استقرار الخدمة أبدًا ونعمل على تحسينه باستمرار. تستمر أحجام حركة المرور على quay.io في النمو ونحن ندرك أن علينا مسؤولية القيام بكل ما في وسعنا للارتقاء إلى مستوى ثقة عملائنا. لذلك ، نعمل حاليًا على المهام التالية:
- , RDS.
- RDS. . , ( ); .
- . , .
- firewall’ - (WAF), , quay.io.
- , Red Hat OpenShift App Registry (Operator Catalogs), , quay.io.
- قد يكون دعم مواصفات الأداة Open Container Initiative (OCI) بديلاً طويل الأمد لسجل التطبيقات. يتم تنفيذه حاليًا كوظيفة Quay أصلية وستكون متاحة للمستخدمين عند الانتهاء من المواصفات نفسها.
كل ما سبق هو جزء من استثمار Red Hat المستمر في quay.io بينما ننتقل من فريق صغير يشبه فريق بدء التشغيل إلى منصة ناضجة يقودها SRE. نحن نعلم أن العديد من عملائنا يعتمدون على quay.io في عملهم اليومي (بما في ذلك Red Hat!) ونحاول أن نكون منفتحين قدر الإمكان بشأن الاضطرابات الأخيرة والجهود المستمرة للتحسين.
PS من المترجم
اقرأ أيضًا على مدونتنا: