Забележка. превод: в началото на август Red Hat публично говори за решаването на проблеми с достъпността, с които потребителите на услугата са се сблъсквали през предходните месеци (базира се на регистър за изображения на контейнери, който компанията получи заедно с покупката на 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 да бъде готов, ние продължихме да се опитваме да стартираме quay.io pods. Всеки път, когато клъстерът достигне пълен капацитет, базата данни замръзва. Това означаваше, че е необходимо да рестартирате RDS инстанцията в допълнение към всички quay.io pods.
До вечерта стабилизирахме услугата в режим само за четене и деактивирахме възможно най-много несъществени функции (например събиране на отпадъци от пространството на имената), за да намалим натоварването на базата данни. Замръзването спря но причината така и не беше открита. Новият OSD клъстер беше готов и ние мигрирахме услугата, свързахме трафика и продължихме наблюдението.
Quay.io работи стабилно на новия OSD клъстер, така че се върнахме към регистрационните файлове на базата данни, но не можахме да намерим корелация, която да обясни блокировките. Инженерите на OpenShift работиха с нас, за да разберат дали промените в Red Hat OpenShift 4.3.19 могат да причинят проблеми с Quay. Нищо обаче не беше намерено и Не беше възможно да се възпроизведе проблемът в лабораторни условия.
Втори провал
На 28 май, малко преди обяд EDT, quay.io отново се срина със същия симптом: базата данни беше блокирана. И отново хвърлихме всичките си усилия в разследването. На първо място беше необходимо да се възстанови услугата. въпреки това този път рестартирането на RDS и рестартирането на quay.io pods не направи нищо: поредната лавина от връзки заля базата. Но защо?
Quay е написан на Python и всеки pod работи като единичен монолитен контейнер. Средата за изпълнение на контейнера изпълнява много паралелни задачи едновременно. Използваме библиотеката gevent под gunicorn за обработка на уеб заявки. Когато заявка постъпи в Quay (чрез нашия собствен API или чрез API на Docker), ѝ се присвоява gevent worker. Обикновено този работник трябва да се свърже с базата данни. След първия неуспех открихме, че работниците на gevent се свързват с базата данни, използвайки настройките по подразбиране.
Като се има предвид значителният брой модули Quay и хилядите входящи заявки в секунда, голям брой връзки към базата данни биха могли теоретично да претоварят екземпляра на MySQL. Благодарение на мониторинга беше известно, че Quay обработва средно 5 хиляди заявки в секунда. Броят на връзките към базата данни беше приблизително същият. 5 хиляди връзки бяха напълно в рамките на възможностите на нашата RDS инстанция (което не може да се каже за десетки хиляди). По някаква причина имаше неочаквани пикове в броя на връзките, но не забелязахме никаква връзка с входящите заявки.
Този път бяхме решени да намерим и премахнем източника на проблема, а не да се ограничим до рестартиране. Към кодовата база на Quay бяха направени промени за ограничаване на броя на връзките към базата данни за всеки работник гевент. Този номер стана параметър в конфигурацията: стана възможно да го промените в движение, без да създавате ново изображение на контейнер. За да разберем колко връзки могат да бъдат обработени реалистично, ние проведохме няколко теста в среда за етапи, задавайки различни стойности, за да видим как това ще се отрази на сценариите за тестване на натоварването. В резултат на това беше установено, че 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. Бързо събрахме всички възможни данни с помощта на добавените инструменти за наблюдение. Изведнъж се появи модел.
Точно преди нарастването на връзките бяха направени голям брой заявки към API на App Registry. App Registry е малко известна функция на quay.io. Позволява ви да съхранявате неща като Helm диаграми и контейнери с богати метаданни. Повечето потребители на quay.io не работят с тази функция, но Red Hat OpenShift активно я използва. OperatorHub като част от OpenShift съхранява всички оператори в регистъра на приложенията. Тези оператори формират основата за екосистемата за натоварване на OpenShift и ориентирания към партньорите оперативен модел (операции от Ден 2).
Всеки клъстер OpenShift 4 използва оператори от вградения OperatorHub, за да публикува каталог от оператори, налични за инсталиране, и да предоставя актуализации на вече инсталираните. С нарастващата популярност на OpenShift 4, броят на клъстерите в него по света също се увеличи. Всеки от тези клъстери изтегля съдържание на оператора, за да стартира вградения OperatorHub, като използва регистъра на приложенията в quay.io като бекенд. В нашето търсене на източника на проблема пропуснахме факта, че с постепенното нарастване на популярността на OpenShift, натоварването на една от рядко използваните функции на quay.io също се увеличи..
Направихме известен анализ на трафика на заявки за App Registry и разгледахме кода на регистъра. Веднага бяха разкрити недостатъци, поради които заявките към базата данни не бяха формирани оптимално. Когато товарът беше нисък, те не създаваха проблеми, но когато товарът се увеличи, те се превърнаха в източник на проблеми. Оказа се, че App Registry има две проблемни крайни точки, които не реагират добре на нарастващото натоварване: първата предостави списък на всички пакети в хранилището, втората върна всички петна за пакета.
Премахване на причините
През следващата седмица прекарахме в оптимизиране на кода на самия регистър на приложенията и неговата среда. Очевидно неефективните SQL заявки бяха преработени и ненужните извиквания на команди бяха елиминирани tar (изпълняваше се всеки път, когато се извличаха петна), беше добавено кеширане, където е възможно. След това проведохме задълбочено тестване на производителността и сравнихме скоростта на регистъра на приложенията преди и след промените.
API заявките, които преди отнемаха до половин минута, сега се изпълняват за милисекунди. Следващата седмица внедрихме промените в производството и оттогава quay.io работи стабилно. През това време имаше няколко резки пика в трафика на крайната точка на App Registry, но направените подобрения предотвратиха прекъсвания на базата данни.
Какво научихме?
Ясно е, че всяка услуга се опитва да избегне прекъсване. В нашия случай вярваме, че скорошните прекъсвания са помогнали да направим quay.io по-добър. Научихме няколко ключови урока, които бихме искали да споделим:
- Данните за това кой и как използва вашата услуга никога не са излишни. Тъй като Quay „току-що работеше“, никога не се наложи да прекарваме време в оптимизиране на трафика и управление на натоварването. Всичко това създаде фалшиво усещане за сигурност, което услугата можеше да мащабира за неопределено време.
- Когато услугата спре, връщането му в работно състояние е основен приоритет.. Тъй като Quay продължи да страда от заключена база данни по време на първото прекъсване, нашите стандартни процедури нямаха очаквания ефект и не успяхме да възстановим услугата, използвайки ги. Това доведе до ситуация, в която трябваше да се отдели време за анализиране и събиране на данни с надеждата да се открие основната причина - вместо да се съсредоточат всички усилия върху възстановяването на функционалността.
- Оценете въздействието на всяка услуга. Клиентите рядко използваха App Registry, така че това не беше приоритет за нашия екип. Когато някои функции на продукта почти не се използват, техните грешки рядко се появяват и разработчиците спират да наблюдават кода. Лесно е да станете жертва на погрешното схващане, че това е начинът, по който трябва да бъде – докато внезапно тази функция не се окаже в центъра на голям инцидент.
Каква е следващата?
Работата за осигуряване на стабилност на услугата никога не спира и ние непрекъснато я подобряваме. Тъй като обемът на трафика на quay.io продължава да нараства, ние осъзнаваме, че носим отговорност да направим всичко възможно, за да оправдаем доверието на нашите клиенти. Затова в момента работим по следните задачи:
- Разположете реплики на база данни само за четене, за да помогнете на услугата да се справи с подходящия трафик в случай на проблеми с първичния екземпляр на RDS.
- Актуализиране на RDS екземпляр. Самата текуща версия не е проблем. По-скоро искаме просто да премахнем фалшивата следа (която следвахме по време на провала); Поддържането на софтуера актуален ще елиминира друг фактор в случай на бъдещи прекъсвания.
- Допълнително кеширане в целия клъстер. Продължаваме да търсим области, в които кеширането може да намали натоварването на базата данни.
- Добавяне на защитна стена за уеб приложение (WAF), за да видите кой се свързва с quay.io и защо.
- Започвайки със следващото издание, клъстерите на Red Hat OpenShift ще изоставят регистъра на приложенията в полза на операторските каталози, базирани на изображения на контейнери, налични на quay.io.
- Дългосрочна замяна на App Registry може да бъде поддръжка за спецификациите на артефактите на Open Container Initiative (OCI). Понастоящем е внедрена като собствена функционалност на Quay и ще бъде достъпна за потребителите, когато самата спецификация бъде финализирана.
Всичко по-горе е част от текущата инвестиция на Red Hat в quay.io, докато преминаваме от малък екип в стил „стартъп“ към зряла платформа, управлявана от SRE. Знаем, че много от нашите клиенти разчитат на quay.io в ежедневната си работа (включително Red Hat!) и се опитваме да бъдем възможно най-прозрачни относно скорошните прекъсвания и текущите усилия за подобряване.
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «".
Източник: www.habr.com