🥇 Post Mortem as gevolg van Quay.io onbeskikbaarheid

Let wel. vertaal.: vroeg in Augustus het Red Hat in die openbaar gepraat oor die oplossing van toeganklikheidsprobleme wat gebruikers van sy diens in vorige maande teëgekom het Quay.io (dit is gebaseer op 'n register vir houerbeelde, wat die maatskappy saam met die aankoop van CoreOS ontvang het). Ongeag jou belangstelling in hierdie diens as sodanig, is die pad wat die maatskappy se SRE-ingenieurs geneem het om die oorsake van die ongeluk te diagnoseer en uit te skakel leersaam.

Op 19 Mei, vroeg in die oggend (Eastern Daylight Time, EDT), het die quay.io-diens neergestort. Die ongeluk het beide quay.io-verbruikers en oopbronprojekte geraak wat quay.io gebruik het as 'n platform vir die bou en verspreiding van sagteware. Red Hat waardeer die vertroue van albei.

’n Span SRE-ingenieurs het dadelik betrokke geraak en probeer om die Quay-diens so gou moontlik te stabiliseer. Terwyl hulle dit gedoen het, het kliënte egter die vermoë verloor om nuwe beelde te stoot, en kon slegs af en toe bestaande beelde trek. Om een of ander onbekende rede is die quay.io-databasis geblokkeer nadat die diens tot volle kapasiteit afgeskaal is.

«Wat het verander?" - dit is die eerste vraag wat gewoonlik in sulke gevalle gevra word. Ons het opgemerk dat die OpenShift Dedicated-kluster (wat quay.io bestuur) kort voor die uitgawe begin bywerk het na weergawe 4.3.19. Aangesien quay.io op Red Hat OpenShift Dedicated (OSD) loop, was gereelde opdaterings roetine en het nooit probleme veroorsaak nie. Verder, oor die vorige ses maande het ons Quay-klusters verskeie kere opgegradeer sonder enige onderbreking in diens.

Terwyl ons probeer het om die diens te herstel, het ander ingenieurs begin met die voorbereiding van 'n nuwe OSD-groepering met die vorige weergawe van die sagteware, sodat as iets gebeur, hulle alles daarop kon ontplooi.

Oorsprongsanaliese

Die hoof simptoom van die mislukking was 'n stortvloed van tienduisende databasisverbindings, wat die MySQL-instansie effektief onbruikbaar gemaak het. Dit het dit moeilik gemaak om die probleem te diagnoseer. Ons het 'n beperking op die maksimum aantal verbindings van kliënte gestel om die SRE-span te help om die kwessie te evalueer. Ons het geen ongewone verkeer na die databasis opgemerk nie: in werklikheid is die meeste versoeke gelees, en slegs 'n paar is geskryf.

Ons het ook probeer om 'n patroon in die databasisverkeer te identifiseer wat hierdie stortvloed kan veroorsaak. Ons kon egter geen patrone in die logs vind nie. Terwyl ons gewag het dat die nuwe groep met OSD 4.3.18 gereed is, het ons voortgegaan om quay.io-peule te begin. Elke keer as die groepering volle kapasiteit bereik het, sou die databasis vries. Dit het beteken dat dit nodig was om die RDS-instansie te herbegin bykomend tot alle quay.io-peule.

Teen die aand het ons die diens in slegs-leesmodus gestabiliseer en soveel moontlik nie-noodsaaklike funksies (byvoorbeeld naamruimte-vullisversameling) gedeaktiveer om die las op die databasis te verminder. Vries het opgehou maar die rede is nooit gevind nie. Die nuwe OSD-groepering was gereed, en ons het die diens gemigreer, verkeer gekoppel en voortgesette monitering.

Quay.io het stabiel gewerk aan die nuwe OSD-groepering, so ons het teruggegaan na die databasislogboeke, maar kon nie 'n korrelasie vind wat die blokkasies sou verduidelik nie. OpenShift-ingenieurs het saam met ons gewerk om te verstaan of veranderinge in Red Hat OpenShift 4.3.19 probleme met Quay kan veroorsaak. Niks is egter gevind nie, en Dit was nie moontlik om die probleem in laboratoriumtoestande te reproduseer nie.

Tweede mislukking

Op 28 Mei, kort voor middag EDT, het quay.io weer neergestort met dieselfde simptoom: die databasis is geblokkeer. En weer het ons al ons pogings in die ondersoek gegooi. Eerstens was dit nodig om die diens te herstel. Egter hierdie keer het die herlaai van RDS en die herbegin van quay.io-peule niks gedoen nie: nog 'n stortvloed van verbindings het die basis oorweldig. Maar hoekom?

Quay is in Python geskryf en elke peul werk as 'n enkele monolitiese houer. Die houerlooptyd loop baie parallelle take gelyktydig uit. Ons gebruik die biblioteek gevent onder gunicorn om webversoeke te verwerk. Wanneer 'n versoek in Quay kom (via ons eie API, of via Docker se API), word dit 'n toegewese werker toegeken. Tipies moet hierdie werker die databasis kontak. Na die eerste mislukking, het ons ontdek dat gegewe werkers met die standaardinstellings aan die databasis koppel.

Gegewe die aansienlike aantal Quay-peule en duisende inkomende versoeke per sekonde, kan 'n groot aantal databasisverbindings teoreties die MySQL-instansie oorweldig. Danksy monitering was dit bekend dat Quay gemiddeld 5 duisend versoeke per sekonde verwerk. Die aantal verbindings met die databasis was ongeveer dieselfde. 5 duisend verbindings was goed binne die vermoëns van ons RDS-instansie (wat nie oor tienduisende gesê kan word nie). Om een of ander rede was daar onverwagte stygings in die aantal verbindings, ons het egter geen korrelasie met inkomende versoeke opgemerk nie.

Hierdie keer was ons vasbeslote om die bron van die probleem te vind en uit te skakel, en nie onsself te beperk tot 'n herlaai nie. Na die Quay-kodebasis veranderinge is aangebring om die aantal verbindings met die databasis vir elke werker te beperk gegee. Hierdie nommer het 'n parameter in die konfigurasie geword: dit het moontlik geword om dit dadelik te verander sonder om 'n nuwe houerbeeld te bou. Om uit te vind hoeveel verbindings realisties hanteer kan word, het ons verskeie toetse in 'n opstelomgewing uitgevoer en verskillende waardes gestel om te sien hoe dit lastoetsscenario's sou beïnvloed. As gevolg hiervan is ontdek dat Quay begin 502 foute gooi wanneer die aantal verbindings 10 duisend oorskry.

Ons het hierdie nuwe weergawe onmiddellik na produksie ontplooi en die databasisverbindingskedule begin monitor. In die verlede was die basis ná sowat 20 minute toegesluit. Na 30 minute sonder probleme het ons hoop gehad, en 'n uur later het ons vertroue gehad. Ons het verkeer na die webwerf herstel en nadoodse ontleding begin.

Nadat u daarin geslaag het om die probleem te omseil wat tot blokkering lei, ons het nie die werklike redes daarvan uitgevind nie. Dit is bevestig dat dit nie verband hou met enige veranderinge in OpenShift 4.3.19 nie, aangesien dieselfde ding gebeur het op weergawe 4.3.18, wat voorheen sonder enige probleme met Quay gewerk het.

Daar was duidelik iets anders wat in die tros geskuil het.

Gedetailleerde studie

Quay.io het die verstekinstellings gebruik om vir ses jaar sonder enige probleme aan die databasis te koppel. Wat het verander? Dit is duidelik dat die verkeer op quay.io al hierdie tyd bestendig gegroei het. In ons geval het dit gelyk of een of ander drempelwaarde bereik is, wat as sneller vir 'n stortvloed van verbindings gedien het. Ons het voortgegaan om die databasislogboeke te bestudeer na die tweede mislukking, maar het geen patrone of ooglopende verwantskappe gevind nie.

Intussen het die SRE-span gewerk aan verbeterings aan Quay se versoekwaarneembaarheid en algehele diensgesondheid. Nuwe maatstawwe en kontroleskerms is ontplooi, wat wys watter dele van die Kaai die meeste in aanvraag van klante is.

Quay.io het goed gewerk tot 9 Junie. Vanoggend (EDT) het ons weer 'n aansienlike toename in die aantal databasisverbindings gesien. Hierdie keer was daar geen stilstand nie, aangesien die nuwe parameter hul aantal beperk het en hulle nie toegelaat het om MySQL-deurset te oorskry nie. Vir ongeveer 'n halfuur het baie gebruikers egter die stadige werkverrigting van quay.io opgemerk. Ons het vinnig alle moontlike data ingesamel met behulp van die bygevoegde moniteringsinstrumente. Skielik het 'n patroon na vore gekom.

Net voor die toename in verbindings, is 'n groot aantal versoeke aan die App Registry API gerig. App Registry is 'n min bekende kenmerk van quay.io. Dit laat jou toe om dinge soos Helm-kaarte en houers met ryk metadata te stoor. Die meeste gebruikers van quay.io werk nie met hierdie kenmerk nie, maar Red Hat OpenShift gebruik dit aktief. OperatorHub as deel van OpenShift stoor alle operateurs in die toepassingsregister. Hierdie operateurs vorm die basis vir die OpenShift-werklading-ekosisteem en vennootgesentreerde bedryfsmodel (Dag 2-bedrywighede).

Elke OpenShift 4-kluster gebruik operateurs van die ingeboude OperatorHub om 'n katalogus van operateurs wat beskikbaar is vir installasie te publiseer en opdaterings te verskaf aan diegene wat reeds geïnstalleer is. Met die groeiende gewildheid van OpenShift 4, het die aantal groepe daarop regoor die wêreld ook toegeneem. Elkeen van hierdie groepe laai operateur-inhoud af om die ingeboude OperatorHub te laat loop, met behulp van die App Registry binne quay.io as die agterkant. In ons soeke na die bron van die probleem het ons die feit gemis dat namate OpenShift geleidelik in gewildheid toegeneem het, die las op een van die selde gebruikte quay.io-funksies ook toegeneem het..

Ons het 'n bietjie ontleding van App Registry-versoekverkeer gedoen en na die registerkode gekyk. Onmiddellik is tekortkominge aan die lig gekom, waardeur navrae na die databasis nie optimaal gevorm is nie. Wanneer die las laag was, het hulle geen moeilikheid veroorsaak nie, maar toe die las toegeneem het, het hulle 'n bron van probleme geword. App Registry het geblyk twee problematiese eindpunte te hê wat nie goed gereageer het op toenemende vrag nie: die eerste het 'n lys van alle pakkette in die bewaarplek verskaf, die tweede het alle kolle vir die pakket teruggestuur.

Uitskakeling van oorsake

Ons het die volgende week spandeer om die kode van die toepassingregister self en sy omgewing te optimaliseer. Duidelik oneffektiewe SQL-navrae is herwerk en onnodige opdragoproepe is uitgeskakel tar (dit is uitgevoer elke keer as knoppies herwin is), caching is bygevoeg waar moontlik. Ons het toe uitgebreide prestasietoetsing uitgevoer en die spoed van die toepassingregister voor en na die veranderinge vergelyk.

API-versoeke wat voorheen tot 'n halwe minuut geneem het, word nou in millisekondes voltooi. Die volgende week het ons die veranderinge aan produksie ontplooi, en sedertdien werk quay.io stabiel. Gedurende hierdie tyd was daar verskeie skerp stygings in verkeer op die App Registry eindpunt, maar die verbeterings wat gemaak is, het databasisonderbrekings verhoed.

Wat het ons geleer?

Dit is duidelik dat enige diens stilstand probeer vermy. In ons geval glo ons dat die onlangse onderbrekings gehelp het om quay.io beter te maak. Ons het 'n paar sleutellesse geleer wat ons graag wil deel:

Data oor wie jou diens gebruik en hoe is nooit oorbodig nie. Omdat Quay “net gewerk het”, hoef ons nooit tyd te spandeer om verkeer te optimaliseer en vrag te bestuur nie. Dit alles het 'n valse gevoel van sekuriteit geskep wat die diens onbepaald kon skaal.
Wanneer die diens afneem, om dit weer aan die gang te kry is 'n topprioriteit.. Omdat Quay aangehou het om aan 'n geslote databasis te ly tydens die eerste onderbreking, het ons standaardprosedures nie die beoogde effek gehad nie en kon ons nie die diens herstel deur hulle te gebruik nie. Dit het gelei tot 'n situasie waar tyd bestee moes word om data te ontleed en in te samel in die hoop om die oorsaak te vind - in plaas daarvan om alle pogings op die herstel van funksionaliteit te fokus.
Evalueer die impak van elke dienskenmerk. Kliënte het selde App Registry gebruik, so dit was nie 'n prioriteit vir ons span nie. Wanneer sommige produkkenmerke skaars gebruik word, verskyn hul foute selde, en ontwikkelaars hou op om die kode te monitor. Dit is maklik om ten prooi te val aan die wanopvatting dat dit die manier is waarop dit moet wees—totdat daardie funksie hom skielik in die middel van 'n groot voorval bevind.

Wat is volgende?

Die werk om die stabiliteit van die diens te verseker hou nooit op nie en ons verbeter dit voortdurend. Aangesien verkeersvolumes steeds op quay.io groei, erken ons dat ons 'n verantwoordelikheid het om alles te doen wat ons kan om aan ons kliënte se vertroue te voldoen. Daarom is ons tans besig met die volgende take:

Ontplooi leesalleen databasis replikas om die diens te help om toepaslike verkeer te hanteer in die geval van probleme met die primêre RDS-instansie.
Dateer tans 'n RDS-instansie op. Die huidige weergawe self is nie die probleem nie. Ons wil eerder bloot die vals spoor (wat ons tydens die mislukking gevolg het) verwyder; Om die sagteware op datum te hou, sal 'n ander faktor uitskakel in die geval van toekomstige onderbrekings.
Bykomende kas oor die hele groepering. Ons gaan voort om te soek na gebiede waar caching die las op die databasis kan verminder.
Voeg 'n webtoepassing-firewall (WAF) by om te sien wie aan quay.io koppel en hoekom.
Vanaf die volgende vrystelling sal Red Hat OpenShift-klusters App Registry laat vaar ten gunste van Operator Catalogs gebaseer op houerbeelde beskikbaar op quay.io.
'n Langtermynvervanger vir App Registry kan ondersteuning vir Open Container Initiative (OCI) artefakspesifikasies wees. Dit word tans as inheemse Quay-funksionaliteit geïmplementeer en sal vir gebruikers beskikbaar wees wanneer die spesifikasie self gefinaliseer is.

Al die bogenoemde is deel van Red Hat se deurlopende belegging in quay.io terwyl ons van 'n klein "beginstyl"-span na 'n volwasse SRE-gedrewe platform beweeg. Ons weet dat baie van ons kliënte staatmaak op quay.io in hul daaglikse werk (insluitend Red Hat!) en ons probeer so deursigtig as moontlik wees oor onlangse onderbrekings en voortdurende pogings om te verbeter.

Post Mortem op Quay.io onbeskikbaarheid