Post Mortem على عدم توفر Quay.io

ملحوظة. ترجمة.: في أوائل أغسطس، تحدثت Red Hat علنًا عن حل مشكلات إمكانية الوصول التي واجهها مستخدمو خدمتها في الأشهر السابقة Quay.io (يعتمد على سجل صور الحاويات، الذي تلقته الشركة مع شراء CoreOS). وبغض النظر عن اهتمامك بهذه الخدمة في حد ذاتها، فإن المسار الذي سلكه مهندسو SRE في الشركة لتشخيص أسباب الحادث والقضاء عليه هو أمر مفيد.

في 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 بالإضافة إلى جميع حجرات quay.io.

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

عمل Quay.io بثبات على مجموعة OSD الجديدة، لذلك عدنا إلى سجلات قاعدة البيانات، ولكن لم نتمكن من العثور على ارتباط يفسر العوائق. لقد عمل مهندسو OpenShift معنا لفهم ما إذا كانت التغييرات في Red Hat OpenShift 4.3.19 قد تسبب مشكلات في Quay. ومع ذلك، لم يتم العثور على شيء، و ولم يكن من الممكن إعادة إنتاج المشكلة في ظروف المختبر.

الفشل الثاني

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

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

نظرًا للعدد الكبير من كبسولات Quay وآلاف الطلبات الواردة في الثانية، يمكن لعدد كبير من اتصالات قاعدة البيانات أن يطغى نظريًا على مثيل 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.io بشكل جيد حتى 9 يونيو. شهدنا هذا الصباح (بتوقيت شرق الولايات المتحدة) مرة أخرى زيادة كبيرة في عدد اتصالات قاعدة البيانات. هذه المرة لم يكن هناك توقف، نظرًا لأن المعلمة الجديدة حددت عددهم ولم تسمح لهم بتجاوز إنتاجية MySQL. ومع ذلك، لمدة نصف ساعة تقريبًا، لاحظ العديد من المستخدمين بطء أداء quay.io. لقد قمنا بجمع جميع البيانات الممكنة بسرعة باستخدام أدوات المراقبة المضافة. فجأة ظهر نمط.

قبل زيادة الاتصالات مباشرة، تم تقديم عدد كبير من الطلبات إلى App Registry API. يعد سجل التطبيقات إحدى الميزات غير المعروفة في quay.io. يسمح لك بتخزين أشياء مثل مخططات Helm والحاويات التي تحتوي على بيانات وصفية غنية. لا يعمل معظم مستخدمي quay.io مع هذه الميزة، لكن Red Hat OpenShift يستخدمها بشكل نشط. يقوم OperatorHub كجزء من OpenShift بتخزين جميع المشغلين في سجل التطبيقات. يشكل هؤلاء المشغلون الأساس للنظام البيئي لأعباء العمل OpenShift ونموذج التشغيل المتمركز حول الشريك (عمليات اليوم الثاني).

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

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

القضاء على الأسباب

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

طلبات واجهة برمجة التطبيقات (API) التي كانت تستغرق في السابق ما يصل إلى نصف دقيقة، يتم إكمالها الآن بالمللي ثانية. في الأسبوع التالي، قمنا بنشر التغييرات على الإنتاج، ومنذ ذلك الحين يعمل quay.io بثبات. خلال هذا الوقت، حدثت عدة زيادات حادة في حركة المرور على نقطة نهاية سجل التطبيقات، ولكن التحسينات التي تم إجراؤها حالت دون انقطاع قاعدة البيانات.

ماذا تعلمنا؟

من الواضح أن أي خدمة تحاول تجنب التوقف. في حالتنا، نعتقد أن الانقطاعات الأخيرة ساعدت في تحسين quay.io. لقد تعلمنا بعض الدروس الأساسية التي نود مشاركتها:

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

ما هي الخطوة التالية؟

العمل لضمان استقرار الخدمة لا يتوقف أبدًا ونحن نعمل على تحسينها باستمرار. مع استمرار نمو حجم حركة المرور على quay.io، فإننا ندرك أن لدينا مسؤولية لبذل كل ما في وسعنا للارتقاء إلى مستوى ثقة عملائنا. ولذلك فإننا نعمل حالياً على المهام التالية:

1. قم بنشر النسخ المتماثلة لقاعدة البيانات للقراءة فقط لمساعدة الخدمة في التعامل مع حركة المرور المناسبة في حالة حدوث مشكلات في مثيل RDS الأساسي.
2. تحديث مثيل RDS. الإصدار الحالي نفسه ليس هو المشكلة. بل نريد ببساطة إزالة الأثر الزائف (الذي اتبعناه أثناء الفشل)؛ سيؤدي الحفاظ على تحديث البرنامج إلى القضاء على عامل آخر في حالة انقطاع الخدمة في المستقبل.
3. تخزين مؤقت إضافي عبر المجموعة بأكملها. نواصل البحث عن المناطق التي يمكن أن يؤدي فيها التخزين المؤقت إلى تقليل الحمل على قاعدة البيانات.
4. إضافة جدار حماية لتطبيق الويب (WAF) لمعرفة من يتصل بـ quay.io ولماذا.
5. بدءًا من الإصدار التالي، ستتخلى مجموعات Red Hat OpenShift عن سجل التطبيقات لصالح كتالوجات المشغلين استنادًا إلى صور الحاوية المتوفرة على quay.io.
6. يمكن أن يكون البديل طويل المدى لسجل التطبيقات هو دعم المواصفات الفنية لمبادرة الحاوية المفتوحة (OCI). يتم تنفيذه حاليًا كوظيفة Quay أصلية وسيكون متاحًا للمستخدمين عند الانتهاء من المواصفات نفسها.

كل ما سبق هو جزء من استثمار Red Hat المستمر في quay.io حيث ننتقل من فريق صغير "على طراز الشركات الناشئة" إلى منصة ناضجة تعتمد على SRE. نحن نعلم أن العديد من عملائنا يعتمدون على quay.io في عملهم اليومي (بما في ذلك Red Hat!) ونحاول أن نكون شفافين قدر الإمكان بشأن الانقطاعات الأخيرة والجهود المستمرة للتحسين.

PS من المترجم

اقرأ أيضًا على مدونتنا:

• «Red Hat رمز التسجيل مفتوح المصدر لصور حاوية CoreOS - Quay"؛
• «قصص عملية من حياتنا اليومية SRE. الجزء 2"؛
• «كيف تسببت أولويات البودات في Kubernetes في توقف العمل في Grafana Labs".

المصدر: www.habr.com