Белешка. трансл.: почетком августа Ред Хат је јавно говорио о решавању проблема приступачности са којима су се корисници његовог сервиса сусретали претходних месеци (заснован је на регистру за слике контејнера, који је компанија добила уз куповину ЦореОС-а). Без обзира на ваше интересовање за ову услугу као такву, пут којим су СРЕ инжењери компаније кренули да дијагностикују и елиминишу узроке несреће је поучан.
Дана 19. маја, рано ујутру (Еастерн Даилигхт Тиме, ЕДТ), сервис куаи.ио је пао. Несрећа је утицала и на куаи.ио потрошаче и на пројекте отвореног кода који користе куаи.ио као платформу за прављење и дистрибуцију софтвера. Ред Хат цени поверење и једног и другог.
Тим инжењера СРЕ се одмах укључио и покушао да што пре стабилизује Кеј сервис. Међутим, док су то радили, клијенти су изгубили могућност да гурају нове слике, а само повремено су могли да повуку постојеће. Из неког непознатог разлога, база података куаи.ио је блокирана након скалирања услуге до пуног капацитета.
«Шта се променило?“ – ово је прво питање које се обично поставља у оваквим случајевима. Приметили смо да је непосредно пре проблема, ОпенСхифт Дедицатед кластер (који покреће куаи.ио) почео да се ажурира на верзију 4.3.19. Пошто куаи.ио ради на Ред Хат ОпенСхифт Дедицатед (ОСД), редовна ажурирања су била рутинска и никада нису изазивала проблеме. Штавише, током претходних шест месеци, неколико пута смо надоградили кластере Кеј без икаквих прекида у раду.
Док смо покушавали да вратимо сервис, други инжењери су почели да припремају нови ОСД кластер са претходном верзијом софтвера, како би, ако се нешто деси, могли све да распореде на њему.
Анализа основног узрока
Главни симптом квара била је лавина десетина хиљада веза са базом података, што је инстанцу МиСКЛ учинило неоперативном. Ово је отежало дијагностиковање проблема. Поставили смо ограничење на максималан број конекција клијената како бисмо помогли СРЕ тиму да процени проблем. Нисмо приметили необичан саобраћај у бази података: у ствари, већина захтева је прочитана, а само неколико написано.
Такође смо покушали да идентификујемо образац у саобраћају базе података који би могао да изазове ову лавину. Међутим, нисмо могли да пронађемо никакве обрасце у евиденцији. Док смо чекали да нови кластер са ОСД 4.3.18 буде спреман, наставили смо да покушавамо да покренемо куаи.ио подове. Сваки пут када би кластер достигао пуни капацитет, база података би се замрзнула. То је значило да је потребно поново покренути РДС инстанцу поред свих куаи.ио подова.
До вечери смо стабилизовали услугу у режиму само за читање и онемогућили што је могуће више небитних функција (на пример, сакупљање смећа у простору имена) да бисмо смањили оптерећење базе података. Замрзавања су престала али разлог никада није пронађен. Нови ОСД кластер је био спреман, а ми смо мигрирали услугу, повезали саобраћај и наставили праћење.
Куаи.ио је радио стабилно на новом ОСД кластеру, тако да смо се вратили на евиденцију базе података, али нисмо могли да пронађемо корелацију која би објаснила блокаде. ОпенСхифт инжењери су радили са нама да би разумели да ли промене у Ред Хат ОпенСхифт 4.3.19 могу да изазову проблеме са Куаи-ом. Међутим, ништа није пронађено, и Није било могуће репродуковати проблем у лабораторијским условима.
Други неуспех
28. маја, нешто пре подне ЕДТ, куаи.ио се поново срушио са истим симптомом: база података је блокирана. И опет смо све напоре уложили у истрагу. Пре свега, било је потребно обновити услугу. Међутим овог пута поновно покретање РДС-а и поновно покретање куаи.ио подова нису ништа урадили: још једна лавина веза затрпала базу. Али зашто?
Куаи је написан у Питхон-у и сваки под ради као један монолитни контејнер. Време извођења контејнера истовремено покреће многе паралелне задатке. Користимо библиотеку gevent под gunicorn за обраду веб захтева. Када захтев дође у Куаи (преко нашег сопственог АПИ-ја или преко Доцкер-овог АПИ-ја), додељује му се гевент радник. Обично овај радник треба да контактира базу података. Након првог неуспеха, открили смо да се гевент радници повезују на базу података користећи подразумевана подешавања.
С обзиром на значајан број Куаи подова и хиљаде долазних захтева у секунди, велики број веза са базом података би теоретски могао да преплави МиСКЛ инстанцу. Захваљујући праћењу, било је познато да Кеј обрађује у просеку 5 хиљада захтева у секунди. Број веза са базом података био је приближно исти. 5 хиљада веза је било у границама могућности наше РДС инстанце (што се не може рећи за десетине хиљада). Из неког разлога дошло је до неочекиваних скокова у броју веза, међутим, нисмо приметили никакву корелацију са пристиглим захтевима.
Овог пута смо били одлучни да пронађемо и елиминишемо извор проблема, а не да се ограничимо на поновно покретање. У кодну базу Кеј извршене су измене како би се ограничио број конекција на базу података за сваког радника гевент. Овај број је постао параметар у конфигурацији: постало је могуће мењати га у ходу без прављења нове слике контејнера. Да бисмо сазнали колико веза може бити реално обрађено, извршили смо неколико тестова у окружењу за постављање, постављајући различите вредности да видимо како ће то утицати на сценарије тестирања оптерећења. Као резултат тога, откривено је да Куаи почиње да пушта 502 грешке када број веза пређе 10 хиљада.
Одмах смо применили ову нову верзију у производњу и почели да надгледамо распоред повезивања базе података. У прошлости је база била закључана након 20 минута. После 30 минута без проблема имали смо наду, а сат касније самопоуздање. Вратили смо саобраћај на сајт и почели постморталну анализу.
Успевши да заобиђе проблем који је довео до блокирања, нисмо сазнали његове праве разлоге. Потврђено је да то није у вези са било каквим изменама у ОпенСхифт 4.3.19, пошто се иста ствар десила и на верзији 4.3.18, која је раније радила са Куаи-ом без икаквих проблема.
Очигледно је нешто друго вребало у грозду.
Детаљна студија
Куаи.ио је користио подразумевана подешавања за повезивање са базом података шест година без икаквих проблема. Шта се променило? Јасно је да је све ово време саобраћај на куаи.ио стално растао. У нашем случају је изгледало као да је достигнута нека гранична вредност која је послужила као окидач за лавину веза. Наставили смо да проучавамо евиденцију базе података након другог отказа, али нисмо пронашли никакве обрасце или очигледне односе.
У међувремену, СРЕ тим је радио на побољшањима уочљивости захтева Куаиа и општег здравља услуге. Нове метрике и контролне табле су примењене, показујући који делови Кеја су најтраженији од купаца.
Куаи.ио је добро функционисао до 9. јуна. Јутрос (ЕДТ) поново смо видели значајно повећање броја веза са базом података. Овог пута није било застоја, пошто је нови параметар ограничио њихов број и није им дозволио да премаше МиСКЛ пропусност. Међутим, око пола сата, многи корисници су приметили споре перформансе куаи.ио. Брзо смо прикупили све могуће податке користећи додатне алате за праћење. Одједном се појавио образац.
Непосредно пре пораста броја веза, велики број захтева упућен је АПИ-ју регистра апликација. Регистар апликација је мало позната карактеристика куаи.ио. Омогућава вам да складиштите ствари као што су Хелм графикони и контејнери са богатим метаподацима. Већина корисника куаи.ио не ради са овом функцијом, али Ред Хат ОпенСхифт је активно користи. ОператорХуб као део ОпенСхифт складишти све оператере у регистру апликација. Ови оператери чине основу за ОпенСхифт екосистем радног оптерећења и оперативни модел усредсређен на партнера (операције другог дана).
Сваки ОпенСхифт 4 кластер користи операторе из уграђеног ОператорХуб-а да објави каталог оператора доступних за инсталацију и обезбеди ажурирања за оне који су већ инсталирани. Са растућом популарношћу ОпенСхифт 4, број кластера на њему широм света такође се повећао. Сваки од ових кластера преузима садржај оператера да би покренуо уграђени ОператорХуб, користећи Апп Регистри унутар куаи.ио као позадину. У нашој потрази за извором проблема, пропустили смо чињеницу да како је ОпенСхифт постепено растао у популарности, расте и оптерећење једне од ретко коришћених функција куаи.ио..
Урадили смо анализу саобраћаја захтева за Апп Регистри и погледали шифру регистра. Одмах су уочени недостаци, због којих упити према бази нису оптимално формирани. Када је оптерећење било мало, нису правили проблеме, али када се оптерећење повећало, постали су извор проблема. Испоставило се да регистар апликација има две проблематичне крајње тачке које нису добро реаговале на повећање оптерећења: прва је обезбедила листу свих пакета у спремишту, друга је вратила све блобове за пакет.
Отклањање узрока
Током следеће недеље смо провели оптимизацију кода самог регистра апликација и његовог окружења. Очигледно неефикасни СКЛ упити су прерађени и непотребни позиви команди су елиминисани tar (покренуто је сваки пут када су блобови преузети), кеширање је додато где год је то могуће. Затим смо спровели опсежно тестирање перформанси и упоредили брзину регистра апликација пре и после промена.
АПИ захтеви који су раније трајали до пола минута сада се завршавају у милисекундама. Следеће недеље смо применили промене у производњи и од тада куаи.ио ради стабилно. Током овог времена, било је неколико оштрих скокова у саобраћају на крајњој тачки регистра апликација, али побољшања су спречила прекиде у бази података.
Шта смо научили?
Јасно је да свака услуга покушава да избегне застоје. У нашем случају, верујемо да су недавни прекиди помогли да куаи.ио буде бољи. Научили смо неколико кључних лекција које бисмо желели да поделимо:
- Подаци о томе ко и како користи вашу услугу никада нису сувишни. Пошто је Куаи „само радио“, никада нисмо морали да трошимо време на оптимизацију саобраћаја и управљање оптерећењем. Све ово је створило лажни осећај сигурности да би услуга могла да се повећава на неодређено време.
- Када услуга падне, његово поновно покретање и рад је главни приоритет.. Пошто је Куаи наставио да пати од закључане базе података током првог прекида, наше стандардне процедуре нису имале жељени ефекат и нисмо били у могућности да вратимо услугу користећи их. То је довело до ситуације у којој је време требало потрошити на анализу и прикупљање података у нади да ће се пронаћи основни узрок – уместо да се сви напори усредсреде на враћање функционалности.
- Процените утицај сваке функције услуге. Клијенти су ретко користили Апп Регистри, тако да то није био приоритет за наш тим. Када се неке карактеристике производа једва користе, њихове грешке се ретко појављују, а програмери престају да прате код. Лако је постати жртвом погрешног схватања да је тако и требало да буде – све док се изненада та функција не нађе у центру великог инцидента.
Шта је следеће?
Рад на обезбеђивању стабилности услуге никада не престаје и стално га унапређујемо. Како обим саобраћаја наставља да расте на куаи.ио, схватамо да имамо одговорност да учинимо све што можемо да оправдамо поверење наших клијената. Стога тренутно радимо на следећим задацима:
- Поставите реплике базе података само за читање да бисте помогли услузи да управља одговарајућим саобраћајем у случају проблема са примарном РДС инстанцом.
- Ажурирање РДС инстанце. Тренутна верзија сама по себи није проблем. Уместо тога, једноставно желимо да уклонимо лажни траг (који смо пратили током неуспеха); Одржавање софтвера ажурним ће елиминисати још један фактор у случају будућих прекида рада.
- Додатно кеширање у целом кластеру. Настављамо да тражимо области у којима кеширање може смањити оптерећење базе података.
- Додавање заштитног зида веб апликације (ВАФ) да видите ко се повезује на куаи.ио и зашто.
- Почевши од следећег издања, Ред Хат ОпенСхифт кластери ће напустити Апп Регистри у корист Каталога оператера на основу слика контејнера доступних на куаи.ио.
- Дугорочна замена за Апп Регистри могла би бити подршка за спецификације артефаката Иницијативе отвореног контејнера (ОЦИ). Тренутно је имплементирана као изворна Куаи функционалност и биће доступна корисницима када се сама спецификација заврши.
Све горе наведено је део Ред Хат-овог текућег улагања у куаи.ио док се крећемо од малог тима у "стартуп стилу" на зрелу платформу вођену СРЕ. Знамо да се многи наши клијенти ослањају на куаи.ио у свом свакодневном раду (укључујући Ред Хат!) и трудимо се да будемо што транспарентнији у вези са недавним прекидима рада и текућим напорима да се побољшамо.
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «'.
Извор: ввв.хабр.цом