Ескерту. аударма: тамыз айының басында 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 қосқыштарын іске қосу әрекетін жалғастырдық. Кластер толық сыйымдылыққа жеткен сайын дерекқор қатып қалады. Бұл барлық quay.io қосқыштарына қосымша RDS данасын қайта іске қосу қажет екенін білдірді.
Кешке қарай біз қызметті тек оқуға арналған режимде тұрақтандырдық және дерекқорға жүктемені азайту үшін мүмкіндігінше маңызды емес функцияларды (мысалы, аттар кеңістігінің қоқысын жинау) өшірдік. Мұздатулар тоқтады бірақ себебі ешқашан табылмады. Жаңа OSD кластері дайын болды, біз қызметті көшірдік, трафикті қостық және бақылауды жалғастырдық.
Quay.io жаңа OSD кластерінде тұрақты жұмыс істеді, сондықтан біз дерекқор журналдарына қайта оралдық, бірақ бұғаттауларды түсіндіретін корреляцияны таба алмадық. OpenShift инженерлері Red Hat OpenShift 4.3.19 жүйесіндегі өзгерістер Quay-да ақаулық тудыруы мүмкін екенін түсіну үшін бізбен бірге жұмыс істеді. Алайда, ештеңе табылмады және Зертханалық жағдайда мәселені қайта шығару мүмкін болмады.
Екінші сәтсіздік
28 мамырда, EDT түске дейін, quay.io қайтадан бірдей симптоммен бұзылды: дерекқор бұғатталды. Біз тағы да бар күш-жігерімізді тергеуге жұмсадық. Ең алдымен, қызметті қалпына келтіру қажет болды. Дегенмен бұл жолы RDS-ті қайта жүктеу және quay.io қосқыштарын қайта іске қосу ештеңеге әкелмеді: байланыстардың тағы бір көшкіні базаны басып қалды. Бірақ неге?
Quay Python тілінде жазылған және әрбір подвод бір монолитті контейнер ретінде жұмыс істейді. Контейнердің орындалу уақыты бір уақытта көптеген параллель тапсырмаларды орындайды. Біз кітапхананы пайдаланамыз gevent астында gunicorn веб сұрауларды өңдеу үшін. Сұрау Quay-ға түскенде (өз API арқылы немесе Docker API арқылы), оған gevent жұмысшысы тағайындалады. Әдетте бұл жұмысшы дерекқорға хабарласуы керек. Бірінші сәтсіздіктен кейін біз gevent жұмысшылары әдепкі параметрлерді пайдаланып дерекқорға қосылып жатқанын анықтадық.
Quay қосқыштарының айтарлықтай санын және секундына мыңдаған кіріс сұрауларын ескере отырып, дерекқор қосылымдарының үлкен саны MySQL данасын теориялық тұрғыдан басып кетуі мүмкін. Мониторингтің арқасында Quay секундына орта есеппен 5 мың сұранысты өңдейтіні белгілі болды. Дерекқорға қосылулар саны шамамен бірдей болды. 5 мың қосылым біздің RDS данасының мүмкіндіктеріне сай болды (оны ондаған мың деп айту мүмкін емес). Қандай да бір себептермен қосылымдар санында күтпеген өсулер болдыдегенмен, біз кіріс сұрауларымен ешқандай байланыс байқамадық.
Бұл жолы біз қайта жүктеумен шектелмей, мәселенің көзін тауып, жоюға бел будық. Quay код базасына әрбір жұмысшы үшін деректер базасына қосылу санын шектеу үшін өзгертулер енгізілді гевент. Бұл сан конфигурациядағы параметр болды: жаңа контейнер кескінін жасамай-ақ оны жылдам өзгерту мүмкін болды. Қанша қосылымды нақты өңдеуге болатынын білу үшін біз жүктеуді тексеру сценарийлеріне қалай әсер ететінін көру үшін әртүрлі мәндерді орнатып, кезеңдік ортада бірнеше сынақ жүргіздік. Нәтижесінде, бұл анықталды Қосылымдар саны 502 мыңнан асқан кезде Quay 10 қате жібере бастайды.
Біз бұл жаңа нұсқаны бірден өндіріске енгізіп, дерекқорға қосылу кестесін бақылай бастадық. Бұрын база шамамен 20 минуттан кейін жабылатын. 30 қиындықсыз минуттан кейін бізде үміт болды, ал бір сағаттан кейін бізде сенімді болды. Біз сайтқа трафикті қалпына келтіріп, өлімнен кейінгі талдауды бастадық.
Бұғаттауға әкелетін мәселені айналып өтіп, оның нақты себептерін анықтаған жоқпыз. Оның OpenShift 4.3.19-дағы ешбір өзгерістерге қатысы жоқ екені расталды, өйткені дәл осындай жағдай бұрын Quay-мен еш қиындықсыз жұмыс істеген 4.3.18 нұсқасында болған.
Кластерде тағы бір нәрсе жасырынып жатқаны анық.
Егжей-тегжейлі зерттеу
Quay.io алты жыл бойы еш қиындықсыз дерекқорға қосылу үшін әдепкі параметрлерді пайдаланды. Не өзгерді? Осы уақыт ішінде quay.io-да трафик тұрақты түрде өсіп келе жатқаны анық. Біздің жағдайда, бұл байланыстардың көшкіні үшін триггер ретінде қызмет еткен қандай да бір шекті мәнге жеткендей болды. Біз екінші сәтсіздіктен кейін дерекқор журналдарын зерттеуді жалғастырдық, бірақ ешқандай үлгілер немесе айқын байланыстар таппадық.
Әзірге SRE командасы Quay сұранысының бақылану мүмкіндігін және жалпы қызмет көрсету жағдайын жақсартумен жұмыс істеуде. Жаңа көрсеткіштер мен бақылау тақталары орналастырылды, Quay-дың қай бөліктері тұтынушылардан көбірек сұранысқа ие екенін көрсетеді.
Quay.io 9 маусымға дейін жақсы жұмыс істеді. Бүгін таңертең (EDT) біз тағы да дерекқорға қосылу санының айтарлықтай өскенін байқадық. Бұл жолы үзіліс болған жоқ, өйткені жаңа параметр олардың санын шектеді және MySQL өткізу қабілетінен асып кетуге мүмкіндік бермеді. Дегенмен, шамамен жарты сағат бойы көптеген пайдаланушылар quay.io-ның баяу өнімділігін атап өтті. Қосылған бақылау құралдарының көмегімен біз барлық ықтимал деректерді жылдам жинадық. Кенеттен үлгі пайда болды.
Қосылымдар көбейер алдында App Registry API интерфейсіне көптеген сұраулар жіберілді. Қолданбалар тізілімі - quay.io-ның аз белгілі мүмкіндігі. Ол Helm диаграммалары және бай метадеректері бар контейнерлер сияқты нәрселерді сақтауға мүмкіндік береді. Quay.io пайдаланушыларының көпшілігі бұл мүмкіндікпен жұмыс істемейді, бірақ Red Hat OpenShift оны белсенді пайдаланады. OpenShift бөлігі ретінде OperatorHub қолданбалар тізілімінде барлық операторларды сақтайды. Бұл операторлар OpenShift жұмыс жүктемесі экожүйесінің және серіктеске бағытталған операциялық үлгінің негізін құрайды (2-ші күн әрекеттері).
Әрбір OpenShift 4 кластері орнатуға қолжетімді операторлар каталогын жариялау және бұрыннан орнатылғандарға жаңартуларды беру үшін кірістірілген OperatorHub операторларын пайдаланады. OpenShift 4-тің танымалдылығының артуымен бүкіл әлем бойынша ондағы кластерлердің саны да артты. Осы кластерлердің әрқайсысы сервер мазмұны ретінде quay.io ішіндегі қолданбалар тізілімін пайдаланып, кірістірілген OperatorHub бағдарламасын іске қосу үшін оператор мазмұнын жүктейді. Мәселенің көзін іздеу барысында біз OpenShift бірте-бірте танымалдылыққа ие болған сайын, сирек қолданылатын quay.io функцияларының біріне жүктеме де артқанын ұмытып кеттік..
Біз қолданбалар тізілімінің сұрау трафигіне талдау жасадық және тізілім кодын қарастырдық. Деректер базасына сұраныстар оңтайлы қалыптаспаған кемшіліктер бірден анықталды. Жүк аз болған кезде олар ешқандай қиындық тудырмады, бірақ жүктеме артқан кезде олар мәселенің көзі болды. Қолданбалар тізілімінде жүктеменің артуына жақсы жауап бермейтін екі проблемалық соңғы нүкте бар болып шықты: біріншісі репозиторийдегі барлық бумалардың тізімін берді, екіншісі бума үшін барлық блоктарды қайтарды.
Себептерді жою
Келесі аптада біз қолданбалар тізілімінің кодын және оның ортасын оңтайландыруға жұмсадық. Әлбетте тиімсіз SQL сұраулары қайта өңделді және қажетсіз пәрмен шақырулары жойылды. tar (ол блобтар шығарылған сайын іске қосылды), кэштеу мүмкіндігінше қосылды. Содан кейін біз ауқымды өнімділік тестілерін жүргіздік және өзгерістерге дейінгі және одан кейінгі қолданбалар тізілімінің жылдамдығын салыстырдық.
Бұрын жарты минутқа созылған API сұраулары енді миллисекундтарда аяқталады. Келесі аптада біз өндіріске өзгерістер енгіздік, содан бері quay.io тұрақты жұмыс істейді. Осы уақыт ішінде Қолданбалар тізілімінің соңғы нүктесінде трафикте бірнеше күрт өсу болды, бірақ жақсартулар дерекқордың үзілуіне жол бермеді.
Біз не үйрендік?
Кез келген қызмет тоқтап қалмауға тырысатыны анық. Біздің жағдайда, соңғы үзілістер quay.io-ны жақсартуға көмектесті деп санаймыз. Біз бөліскіміз келетін бірнеше негізгі сабақ алдық:
- Қызметіңізді кім және қалай пайдаланатыны туралы деректер ешқашан артық болмайды. Quay «жұмыс істеді» болғандықтан, біз ешқашан трафикті оңтайландыруға және жүктемені басқаруға уақыт жұмсамадық. Мұның бәрі қызмет шексіз масштабтауға болатын жалған қауіпсіздік сезімін тудырды.
- Қызмет тоқтаған кезде, оны қалпына келтіру және іске қосу – басты басымдық.. Quay бірінші өшіру кезінде құлыпталған дерекқордан зардап шеге бергендіктен, стандартты процедураларымыз күткен нәтиже бермеді және біз оларды пайдаланып қызметті қалпына келтіре алмадық. Бұл барлық күш-жігерді функционалдылықты қалпына келтіруге бағыттаудың орнына, түпкі себебін табу үмітімен деректерді талдауға және жинауға уақыт бөлуге тура келетін жағдайға әкелді.
- Әрбір қызмет мүмкіндігінің әсерін бағалаңыз. Клиенттер қолданбалар тізілімін сирек пайдаланды, сондықтан бұл біздің команда үшін басымдық болмады. Кейбір өнім мүмкіндіктері әрең пайдаланылған кезде, олардың қателері сирек пайда болады және әзірлеушілер кодты бақылауды тоқтатады. Бұл солай болуы керек деген қате пікірдің құрбаны болу оңай - бұл функция кенеттен үлкен оқиғаның ортасында болғанға дейін.
Ары қарай не?
Қызметтің тұрақтылығын қамтамасыз ету жұмысы ешқашан тоқтамайды және біз оны үнемі жетілдіріп отырамыз. Quay.io сайтында трафик көлемі артып келе жатқандықтан, біз тұтынушыларымыздың сенімін ақтау үшін қолдан келгеннің бәрін жасауға жауапты екенімізді түсінеміз. Сондықтан біз қазір келесі тапсырмаларды орындаудамыз:
- Негізгі RDS данасына қатысты мәселелер туындаған жағдайда қызметке сәйкес трафикті өңдеуге көмектесу үшін тек оқуға арналған дерекқор репликаларын орналастырыңыз.
- RDS данасын жаңарту. Ағымдағы нұсқаның өзі мәселе емес. Керісінше, біз жалған ізді алып тастағымыз келеді (сәтсіздік кезінде біз оны ұстандық); Бағдарламалық құралды жаңартып отыру болашақта тоқтаулар болған жағдайда басқа факторды жояды.
- Бүкіл кластер бойынша қосымша кэштеу. Біз кэштеу дерекқордағы жүктемені азайтатын аймақтарды іздеуді жалғастырамыз.
- quay.io-ге кім және не үшін қосылып жатқанын көру үшін веб-бағдарлама брандмауэрін (WAF) қосу.
- Келесі шығарылымнан бастап Red Hat OpenShift кластерлері quay.io сайтында қолжетімді контейнер кескіндеріне негізделген Оператор каталогтарының пайдасына қолданбалар тізілімінен бас тартады.
- Қолданбалар тізілімін ұзақ мерзімді ауыстыру Open Container Initiative (OCI) артефакті сипаттамаларына қолдау көрсетуі мүмкін. Ол қазіргі уақытта Quay төл функциясы ретінде іске асырылуда және спецификацияның өзі аяқталған кезде пайдаланушыларға қолжетімді болады.
Жоғарыда айтылғандардың барлығы Red Hat компаниясының quay.io-ға тұрақты инвестициясының бөлігі болып табылады, өйткені біз шағын «стартап стиліндегі» командадан жетілген SRE басқарылатын платформаға көшеміз. Біз тұтынушыларымыздың көпшілігі күнделікті жұмысында quay.io-ға сенетінін білеміз (соның ішінде Red Hat!) және біз соңғы үзілістер мен жақсартуға бағытталған әрекеттер туралы барынша ашық болуға тырысамыз.
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com