در دسترس نبودن Post Mortem در Quay.io

توجه داشته باشید. ترجمه: در اوایل آگوست، Red Hat به طور عمومی در مورد حل مشکلات دسترسی که کاربران سرویس آن در ماه های گذشته با آن مواجه شده بودند صحبت کرد. Quay.io (بر اساس یک رجیستری برای تصاویر کانتینر است که این شرکت همراه با خرید CoreOS دریافت کرده است). صرف نظر از علاقه شما به این خدمات، مسیری که مهندسان SRE شرکت برای تشخیص و رفع علل حادثه طی کردند آموزنده است.

در 19 مه، در اوایل صبح (به وقت شرقی شرقی، EDT)، سرویس quay.io از کار افتاد. این حادثه هم بر مصرف کنندگان quay.io و هم پروژه های منبع باز که از quay.io به عنوان پلتفرمی برای ساخت و توزیع نرم افزار استفاده می کردند، تحت تاثیر قرار داد. Red Hat برای اعتماد هر دو ارزش قائل است.

تیمی از مهندسان SRE بلافاصله درگیر شدند و سعی کردند سرویس Quay را در اسرع وقت تثبیت کنند. با این حال، در حالی که آنها این کار را انجام می دادند، مشتریان توانایی ارسال تصاویر جدید را از دست دادند و فقط گاهی اوقات می توانستند تصاویر موجود را بکشند. به دلایلی نامعلوم، پایگاه داده quay.io پس از مقیاس‌بندی سرویس تا ظرفیت کامل مسدود شد.

«چه چیزی تغییر کرده است؟" - این اولین سوالی است که معمولا در چنین مواردی پرسیده می شود. ما متوجه شدیم که اندکی قبل از این مشکل، خوشه OpenShift Dedicated (که quay.io را اجرا می کند) شروع به به روز رسانی به نسخه 4.3.19 کرد. از آنجایی که quay.io روی Red Hat OpenShift Dedicated (OSD) اجرا می‌شود، به‌روزرسانی‌های منظم معمولی بود و هرگز مشکلی ایجاد نکرد. علاوه بر این، در طول شش ماه گذشته، ما چندین بار خوشه‌های Quay را بدون وقفه در خدمات ارتقا داده‌ایم.

در حالی که ما در تلاش برای بازیابی سرویس بودیم، مهندسان دیگر شروع به تهیه یک خوشه OSD جدید با نسخه قبلی نرم افزار کردند تا اگر اتفاقی افتاد، بتوانند همه چیز را روی آن مستقر کنند.

بررسی دلیل ریشه ای

علامت اصلی شکست، بهمنی از ده ها هزار اتصال پایگاه داده بود که نمونه MySQL را عملاً غیرقابل اجرا کرد. این امر تشخیص مشکل را دشوار می کرد. ما برای کمک به تیم SRE در ارزیابی مشکل، محدودیتی برای حداکثر تعداد اتصالات از مشتریان تعیین کرده ایم. ما متوجه ترافیک غیرعادی به پایگاه داده نشدیم: در واقع، بیشتر درخواست‌ها خوانده می‌شدند و فقط تعداد کمی از آنها رایت می‌شدند.

ما همچنین سعی کردیم الگویی را در ترافیک پایگاه داده شناسایی کنیم که می تواند باعث این بهمن شود. با این حال، ما نتوانستیم هیچ الگوی را در سیاههها پیدا کنیم. در حالی که منتظر آماده شدن خوشه جدید با OSD 4.3.18 هستیم، به تلاش خود برای راه‌اندازی pods quay.io ادامه دادیم. هر بار که خوشه به ظرفیت کامل می رسید، پایگاه داده منجمد می شد. این بدان معناست که لازم است نمونه RDS را علاوه بر تمام پادهای quay.io مجدداً راه اندازی کنیم.

تا عصر، ما سرویس را در حالت فقط خواندنی تثبیت کردیم و تا حد امکان بسیاری از عملکردهای غیر ضروری (به عنوان مثال، جمع آوری زباله فضای نام) را غیرفعال کردیم تا بار روی پایگاه داده کاهش یابد. یخ زدگی متوقف شده است اما دلیل آن هرگز پیدا نشد. خوشه OSD جدید آماده بود و ما سرویس را انتقال دادیم، ترافیک را متصل کردیم و نظارت را ادامه دادیم.

Quay.io روی خوشه OSD جدید به‌طور پایدار کار می‌کرد، بنابراین ما به گزارش‌های پایگاه داده بازگشتیم، اما نتوانستیم ارتباطی پیدا کنیم که انسدادها را توضیح دهد. مهندسان OpenShift با ما کار کردند تا بفهمند آیا تغییرات در Red Hat OpenShift 4.3.19 می تواند مشکلاتی را در Quay ایجاد کند یا خیر. با این حال، چیزی پیدا نشد، و امکان بازتولید مشکل در شرایط آزمایشگاهی وجود نداشت.

شکست دوم

در 28 می، کمی قبل از ظهر EDT، quay.io دوباره با همان علامت خراب شد: پایگاه داده مسدود شد. و ما دوباره تمام تلاش خود را در تحقیقات انجام دادیم. اول از همه، بازیابی سرویس ضروری بود. با این حال این بار راه اندازی مجدد RDS و راه اندازی مجدد پادهای quay.io هیچ کاری انجام نداد: بهمن دیگری از اتصالات پایگاه را فرا گرفته است. اما چرا؟

Quay در پایتون نوشته شده است و هر پاد به عنوان یک ظرف یکپارچه عمل می کند. زمان اجرا کانتینر بسیاری از وظایف موازی را به طور همزمان اجرا می کند. ما از کتابخانه استفاده می کنیم gevent تحت gunicorn برای پردازش درخواست های وب وقتی درخواستی به Quay می‌رسد (از طریق API خودمان یا از طریق Docker's API)، یک gevent worker به آن اختصاص داده می‌شود. معمولاً این کارگر باید با پایگاه داده تماس بگیرد. پس از اولین شکست، متوجه شدیم که کارگران gevent با استفاده از تنظیمات پیش‌فرض به پایگاه داده متصل می‌شوند.

با توجه به تعداد قابل توجهی از Quay pod و هزاران درخواست ورودی در ثانیه، تعداد زیادی از اتصالات پایگاه داده از نظر تئوری می تواند نمونه 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 ژوئن خوب کار کرد. امروز صبح (EDT) ما دوباره شاهد افزایش قابل توجهی در تعداد اتصالات پایگاه داده بودیم. این بار هیچ تعطیلی وجود نداشت، از آنجایی که پارامتر جدید تعداد آنها را محدود می کرد و به آنها اجازه نمی داد از توان خروجی MySQL تجاوز کنند. با این حال، برای حدود نیم ساعت، بسیاری از کاربران به عملکرد کند quay.io اشاره کردند. ما به سرعت تمام داده های ممکن را با استفاده از ابزارهای نظارتی اضافه شده جمع آوری کردیم. ناگهان یک الگو ظاهر شد.

درست قبل از افزایش اتصالات، تعداد زیادی درخواست به App Registry API ارسال شد. رجیستری برنامه یک ویژگی کمتر شناخته شده quay.io است. این به شما امکان می دهد چیزهایی مانند نمودارهای Helm و ظروف را با ابرداده غنی ذخیره کنید. اکثر کاربران quay.io با این ویژگی کار نمی کنند، اما Red Hat OpenShift به طور فعال از آن استفاده می کند. OperatorHub به عنوان بخشی از OpenShift همه اپراتورها را در رجیستری برنامه ذخیره می کند. این اپراتورها اساس اکوسیستم بار کاری OpenShift و مدل عملیاتی شریک محور (عملیات روز دوم) را تشکیل می دهند.

هر خوشه OpenShift 4 از عملگرهایی از OperatorHub داخلی برای انتشار کاتالوگ اپراتورهای موجود برای نصب و ارائه به‌روزرسانی‌هایی برای اپراتورهایی که قبلاً نصب شده‌اند، استفاده می‌کند. با افزایش محبوبیت OpenShift 4، تعداد خوشه های موجود در آن در سراسر جهان نیز افزایش یافته است. هر یک از این خوشه‌ها محتوای اپراتور را برای اجرای OperatorHub داخلی با استفاده از App Registry در quay.io به عنوان باطن دانلود می‌کنند. در جستجوی ما برای منبع مشکل، این واقعیت را از دست دادیم که با افزایش تدریجی محبوبیت OpenShift، بار روی یکی از توابع quay.io که به ندرت استفاده می شود نیز افزایش می یابد..

ما مقداری از ترافیک درخواست رجیستری برنامه را تحلیل کردیم و نگاهی به کد رجیستری انداختیم. فوراً کاستی هایی آشکار شد که به همین دلیل استعلام به پایگاه داده به طور مطلوب شکل نگرفت. با یک بار کوچک هیچ مشکلی ایجاد نکردند، اما با افزایش بار، منبع مشکل شدند. مشخص شد که App Registry دو نقطه پایانی مشکل‌ساز دارد که به خوبی به افزایش بار پاسخ نمی‌دهند: اولی فهرستی از تمام بسته‌های موجود در مخزن را ارائه می‌دهد، دومی همه حباب‌ها را برای بسته برمی‌گرداند.

از بین بردن علل

در طول هفته آینده، ما صرف بهینه سازی کد خود رجیستری برنامه و محیط آن کردیم. واضح است که پرس‌وجوهای SQL ناکارآمد دوباره کار شده و فراخوانی‌های غیر ضروری دستور حذف شدند. tar (هر بار که حباب‌ها بازیابی می‌شد اجرا می‌شد)، ذخیره‌سازی در هر کجا که امکان داشت اضافه می‌شد. سپس تست عملکرد گسترده ای انجام دادیم و سرعت رجیستری برنامه را قبل و بعد از تغییرات مقایسه کردیم.

درخواست‌های API که قبلاً نیم دقیقه طول می‌کشید، اکنون در میلی‌ثانیه تکمیل می‌شوند. هفته بعد ما تغییرات را در تولید اعمال کردیم و از آن زمان quay.io به طور پایدار کار می کند. در طول این مدت، چندین جهش شدید در ترافیک در نقطه پایانی App Registry وجود داشت، اما بهبودهای انجام شده از قطع شدن پایگاه داده جلوگیری کرد.

ما چه آموخته ایم؟

واضح است که هر سرویسی سعی می کند از خرابی جلوگیری کند. در مورد ما، ما معتقدیم که قطعی های اخیر به بهتر شدن quay.io کمک کرده است. ما چند درس کلیدی آموخته ایم که می خواهیم به اشتراک بگذاریم:

1. داده‌های مربوط به اینکه چه کسی و چگونه از خدمات شما استفاده می‌کند هرگز اضافی نیست. از آنجایی که Quay «فقط کار کرد»، هرگز مجبور نشدیم زمانی را صرف بهینه‌سازی ترافیک و مدیریت بار کنیم. همه اینها احساس امنیت کاذبی را ایجاد می کند که سرویس می تواند به طور نامحدود گسترش یابد.
2. وقتی سرویس از کار افتاد، راه اندازی مجدد و راه اندازی آن اولویت اصلی است.. از آنجایی که Quay همچنان از یک پایگاه داده قفل شده در اولین قطعی رنج می برد، رویه های استاندارد ما اثر مورد نظر را نداشت و نتوانستیم سرویس را با استفاده از آنها بازیابی کنیم. این منجر به وضعیتی شد که در آن زمان باید صرف تجزیه و تحلیل و جمع‌آوری داده‌ها به امید یافتن علت اصلی می‌شد - به جای تمرکز تمام تلاش‌ها بر بازیابی عملکرد.
3. تأثیر هر ویژگی خدمات را ارزیابی کنید. مشتریان به ندرت از App Registry استفاده می کردند، بنابراین برای تیم ما اولویت نداشت. هنگامی که برخی از ویژگی های محصول به سختی استفاده می شوند، اشکالات آنها به ندرت ظاهر می شود و توسعه دهندگان نظارت بر کد را متوقف می کنند. به راحتی می توان گرفتار این تصور غلط شد که باید اینگونه باشد - تا زمانی که ناگهان آن عملکرد خود را در مرکز یک حادثه بزرگ بیابد.

گام بعدی چیست؟

کار برای اطمینان از پایداری سرویس هرگز متوقف نمی شود و ما دائماً در حال بهبود آن هستیم. از آنجایی که حجم ترافیک در quay.io همچنان در حال افزایش است، ما می دانیم که مسئولیت داریم هر کاری که می توانیم انجام دهیم تا به اعتماد مشتریان خود عمل کنیم. بنابراین، ما در حال حاضر بر روی وظایف زیر کار می کنیم:

1. کپی های پایگاه داده فقط خواندنی را برای کمک به سرویس در مدیریت ترافیک مناسب در صورت بروز مشکل در نمونه اولیه RDS، مستقر کنید.
2. به روز رسانی یک نمونه RDS. خود نسخه فعلی مشکلی ندارد. در عوض، ما به سادگی می خواهیم دنباله کاذب را حذف کنیم (که در طول شکست دنبال کردیم). به روز نگه داشتن نرم افزار عامل دیگری را در صورت قطعی های بعدی حذف می کند.
3. حافظه پنهان اضافی در کل خوشه. ما همچنان به دنبال مناطقی هستیم که کش می تواند بار روی پایگاه داده را کاهش دهد.
4. افزودن فایروال برنامه وب (WAF) برای اینکه ببینید چه کسی و چرا به quay.io متصل می شود.
5. با شروع نسخه بعدی، خوشه‌های Red Hat OpenShift رجیستری برنامه را به نفع کاتالوگ‌های اپراتور بر اساس تصاویر کانتینر موجود در quay.io کنار می‌گذارند.
6. یک جایگزین طولانی مدت برای App Registry می تواند پشتیبانی از مشخصات مصنوعات Open Container Initiative (OCI) باشد. در حال حاضر به عنوان قابلیت بومی Quay پیاده سازی شده است و زمانی که مشخصات نهایی نهایی شد در دسترس کاربران قرار خواهد گرفت.

همه موارد فوق بخشی از سرمایه گذاری مداوم Red Hat در quay.io است زیرا ما از یک تیم کوچک "به سبک استارتاپی" به یک پلت فرم بالغ مبتنی بر SRE حرکت می کنیم. ما می دانیم که بسیاری از مشتریان ما در کارهای روزانه خود (از جمله Red Hat!) به quay.io متکی هستند و سعی می کنیم تا حد امکان در مورد قطعی های اخیر و تلاش های مداوم برای بهبود شفافیت صحبت کنیم.

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «کد رجیستری منبع باز Red Hat برای تصاویر کانتینر CoreOS - Quay"؛
• «داستان های عملی از زندگی روزمره SRE ما. قسمت 2"؛
• «چگونه اولویت‌های غلاف در Kubernetes باعث خرابی در آزمایشگاه Grafana شد'.

منبع: www.habr.com