Эскертүү. котормо.: Август айынын башында Red Hat өзүнүн кызматынын колдонуучулары мурунку айларда жолуккан жеткиликтүүлүк көйгөйлөрүн чечүү тууралуу ачык айтты. (бул компания CoreOS сатып алуу менен бирге алган контейнер сүрөттөрүнүн реестрине негизделген). Сиздин бул кызматка болгон кызыгууңузга карабастан, компаниянын SRE инженерлери кырсыктын себептерин диагностикалоо жана жоюу үчүн басып өткөн жолду үйрөтөт.
19-майда, эртең менен эрте (Чыгыш күндүзгү убакыт, EDT), quay.io кызматы кыйрады. Кырсык quay.io керектөөчүлөрүнө да, программалык камсыздоону куруу жана жайылтуу үчүн платформа катары quay.io колдонгон Open Source долбоорлоруна да таасирин тийгизди. 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's API аркылуу), ага gevent жумушчусу дайындалат. Эреже катары, бул жумушчу маалымат базасына кайрылышы керек. Биринчи катачылыктан кийин, биз gevent жумушчулары демейки жөндөөлөрдү колдонуу менен маалымат базасына туташып жатканын аныктадык.
Quay поддондорунун олуттуу санын жана секундасына миңдеген кирүүчү суроо-талаптарды эске алганда, көп сандагы маалыматтар базасына туташуу теориялык жактан MySQL инстанциясын басып кетиши мүмкүн. Мониторингдин аркасында Quay секундасына орто эсеп менен 5 миң суроону иштетээри белгилүү болду. Маалыматтар базасына байланыштардын саны болжол менен бирдей эле. 5 миң туташуулар биздин RDS инстанциябыздын мүмкүнчүлүктөрүнө туура келген (аны он миңдеген деп айтууга болбойт). Негедир байланыштардын саны күтүүсүз өскөн, бирок биз келип түшкөн өтүнүчтөр менен эч кандай байланышты байкаган жокпуз.
Бул жолу биз кайра жүктөө менен чектелбей, көйгөйдүн булагын таап, жок кылууга чечкиндүү болдук. Quay код базасына ар бир жумушчу үчүн маалымат базасына кошулуу санын чектөө үчүн өзгөртүүлөр киргизилген gevent. Бул сан конфигурацияда параметр болуп калды: жаңы контейнер сүрөтүн түзбөстөн, аны тез эле өзгөртүүгө мүмкүн болду. Канча туташууларды реалдуу иштетүүгө болорун билүү үчүн, биз жүктөөнү сыноо сценарийлерине кандай таасир этээрин көрүү үчүн ар кандай маанилерди коюп, стационардык чөйрөдө бир нече сыноолорду өткөрдүк. Натыйжада, бул аныкталды Quay туташуулардын саны 502 миңден ашканда 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 аны активдүү колдонот. OperatorHub OpenShiftтин бир бөлүгү катары бардык операторлорду Колдонмо реестринде сактайт. Бул операторлор OpenShift иш жүктөө экосистемасынын жана өнөктөшкө багытталган операциялык моделинин негизин түзөт (2-күн операциялары).
Ар бир OpenShift 4 кластери орнотуу үчүн жеткиликтүү операторлордун каталогун жарыялоо жана орнотулгандарга жаңыртууларды берүү үчүн орнотулган OperatorHub операторлорун колдонот. OpenShift 4 популярдуулугунун өсүшү менен дүйнө жүзү боюнча андагы кластерлердин саны да көбөйдү. Бул кластерлердин ар бири камтылган OperatorHub иштетүү үчүн оператордун мазмунун жүктөп алып, Quay.io ичиндеги Колдонмо реестрин арка катары колдонушат. Көйгөйдүн булагын издеп жатканыбызда, 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
Биздин блогдон дагы окуңуз:
- «";
- «";
- ««.
Source: www.habr.com