Huomautus. käännös: Red Hat puhui elokuun alussa julkisesti esteettömyysongelmien ratkaisemisesta, joita sen palvelun käyttäjät olivat kohdanneet aiempina kuukausina (se perustuu konttikuvien rekisteriin, jonka yritys sai CoreOS:n oston yhteydessä). Huolimatta kiinnostuksestasi tätä palvelua kohtaan, polku, jonka yrityksen SRE-insinöörit valitsivat onnettomuuden syiden diagnosoimiseksi ja poistamiseksi, on opettavainen.
Toukokuun 19. päivänä aikaisin aamulla (Eastern Daylight Time, EDT) quay.io-palvelu kaatui. Onnettomuus vaikutti sekä quay.io-kuluttajiin että avoimen lähdekoodin projekteihin, joissa quay.iota käytettiin ohjelmistojen rakentamisen ja jakelun alustana. Red Hat arvostaa molempien luottamusta.
Ryhmä SRE:n insinöörejä tuli välittömästi mukaan ja yritti vakauttaa Quay-palvelun mahdollisimman pian. Tätä tehdessään asiakkaat kuitenkin menettivät kyvyn työntää uusia kuvia, ja vain satunnaisesti he pystyivät vetäämään olemassa olevia kuvia. Jostain tuntemattomasta syystä quay.io-tietokanta estettiin, kun palvelu skaalattiin täyteen kapasiteettiin.
«Mikä on muuttunut?" - tämä on ensimmäinen kysymys, joka yleensä kysytään tällaisissa tapauksissa. Huomasimme, että juuri ennen ongelmaa OpenShift Dedicated -klusteri (joka suorittaa quay.io) alkoi päivittää versioon 4.3.19. Koska quay.io toimii Red Hat OpenShift Dedicated (OSD) -järjestelmällä, säännölliset päivitykset olivat rutiinia eivätkä koskaan aiheuttaneet ongelmia. Lisäksi olemme viimeisten kuuden kuukauden aikana päivittäneet Quay-klustereita useita kertoja ilman palvelun keskeytyksiä.
Kun yritimme palauttaa palvelua, muut suunnittelijat alkoivat valmistella uutta OSD-klusteria ohjelmiston edellisellä versiolla, jotta he voisivat ottaa kaiken käyttöön, jos jotain tapahtuisi.
Perussyyanalyysimenetelmiä
Pääasiallinen oire epäonnistumisesta oli kymmenien tuhansien tietokantayhteyksien lumivyöry, joka teki MySQL-instanssin käytännössä toimintakyvyttömäksi. Tämä vaikeutti ongelman diagnosointia. Olemme asettaneet rajan asiakkaiden yhteyksien enimmäismäärälle auttaaksemme SRE-tiimiä arvioimaan ongelman. Emme havainneet epätavallista liikennettä tietokantaan: itse asiassa suurin osa pyynnöistä luettiin ja vain muutama kirjoitettiin.
Yritimme myös tunnistaa tietokantaliikenteestä kuvion, joka voisi aiheuttaa tämän lumivyöryn. Emme kuitenkaan löytäneet lokeista mitään kuvioita. Odottaessamme uuden OSD 4.3.18 -klusterin valmistumista jatkoimme quay.io podien lanseeraamista. Joka kerta kun klusteri saavutti täyden kapasiteetin, tietokanta jumiutui. Tämä tarkoitti, että RDS-instanssi oli käynnistettävä uudelleen kaikkien quay.io-koteloiden lisäksi.
Illalla vakiinnuimme palvelun vain luku -tilaan ja poistimme käytöstä mahdollisimman monet ei-välttämättömät toiminnot (esimerkiksi nimitilan roskienkeruu) tietokannan kuormituksen vähentämiseksi. Jäätyminen on pysähtynyt mutta syytä ei löytynyt. Uusi OSD-klusteri oli valmis, ja siirsimme palvelun, liittimme liikenteen ja jatkoimme seurantaa.
Quay.io toimi vakaasti uudessa OSD-klusterissa, joten palasimme tietokannan lokeihin, mutta emme löytäneet korrelaatiota, joka selittäisi tukoksia. OpenShift-insinöörit työskentelivät kanssamme selvittääkseen, voivatko Red Hat OpenShift 4.3.19:n muutokset aiheuttaa ongelmia Quayn kanssa. Mitään ei kuitenkaan löytynyt, ja Ongelmaa ei ollut mahdollista toistaa laboratorio-olosuhteissa.
Toinen epäonnistuminen
28. toukokuuta, vähän ennen puoltapäivää EDT, quay.io kaatui uudelleen samalla oireella: tietokanta estettiin. Ja jälleen panostimme kaikki voimamme tutkimuksen eteen. Ensinnäkin palvelu oli palautettava. kuitenkin Tällä kertaa RDS:n uudelleenkäynnistäminen ja quay.io-podien uudelleenkäynnistäminen ei tehnyt mitään: toinen yhteyksien lumivyöry on vallannut tukikohdan. Mutta miksi?
Quay on kirjoitettu Pythonilla ja jokainen pod toimii yhtenä monoliittisena konttina. Säilön suoritusaika suorittaa useita rinnakkaisia tehtäviä samanaikaisesti. Käytämme kirjastoa gevent alle gunicorn web-pyyntöjen käsittelyyn. Kun pyyntö saapuu Quaylle (oman API:n tai Dockerin API:n kautta), sille määrätään gevent worker. Tyypillisesti tämän työntekijän tulee ottaa yhteyttä tietokantaan. Ensimmäisen epäonnistumisen jälkeen havaitsimme, että gevent-työntekijät olivat yhteydessä tietokantaan oletusasetuksia käyttäen.
Kun otetaan huomioon Quay-tyynyjen huomattava määrä ja tuhansia saapuvia pyyntöjä sekunnissa, suuri määrä tietokantayhteyksiä voisi teoriassa ylittää MySQL-instanssin. Seurannan ansiosta tiedettiin, että Quay käsittelee keskimäärin 5 tuhatta pyyntöä sekunnissa. Yhteyksien määrä tietokantaan oli suunnilleen sama. 5 tuhatta yhteyttä oli reilusti RDS-instanssimme rajoissa (mitä ei voi sanoa kymmenistä tuhansista). Jostain syystä yhteyksien määrässä oli odottamattomia piikkejäemme kuitenkaan havainneet mitään korrelaatiota saapuvien pyyntöjen kanssa.
Tällä kertaa päätimme löytää ja poistaa ongelman syyn, emmekä rajoita itseämme uudelleenkäynnistykseen. Quayn koodikantaan Muutoksia tehtiin rajoittamaan kunkin työntekijän tietokantaan tehtävien yhteyksien määrää gevent. Tästä numerosta tuli kokoonpanon parametri: se tuli mahdolliseksi muuttaa lennossa rakentamatta uutta konttikuvaa. Selvittääksemme, kuinka monta yhteyttä voitaisiin realistisesti käsitellä, suoritimme useita testejä vaiheittaisessa ympäristössä asettamalla erilaisia arvoja nähdäksemme, kuinka tämä vaikuttaisi kuormitustestausskenaarioihin. Tämän seurauksena havaittiin, että Quay alkaa heittää 502 virhettä, kun yhteyksien määrä ylittää 10 tuhatta.
Otimme tämän uuden version välittömästi käyttöön tuotantoon ja aloimme seurata tietokannan yhteysaikataulua. Aiemmin tukikohta lukittiin noin 20 minuutin kuluttua. 30 ongelmattoman minuutin jälkeen meillä oli toivoa, ja tuntia myöhemmin meillä oli luottamus. Palautimme liikenteen paikalle ja aloitimme post mortem -analyysin.
Onnistuttuaan ohittamaan estoon johtavan ongelman, emme ole saaneet selville sen todellisia syitä. Vahvistettiin, että se ei liity mihinkään muutoksiin OpenShift 4.3.19:ssä, koska sama tapahtui versiossa 4.3.18, joka aiemmin toimi Quayn kanssa ilman ongelmia.
Ryhmässä oli selvästi jotain muuta piilossa.
Yksityiskohtainen tutkimus
Quay.io käytti oletusasetuksia muodostaakseen yhteyden tietokantaan kuuden vuoden ajan ilman ongelmia. Mikä muuttui? On selvää, että koko tämän ajan quay.io:n liikenne on kasvanut tasaisesti. Meidän tapauksessamme näytti siltä, että jokin kynnysarvo oli saavutettu, mikä toimi laukaisuna yhteyksien lumivyörylle. Jatkoimme tietokannan lokien tutkimista toisen epäonnistumisen jälkeen, mutta emme löytäneet kaavoja tai ilmeisiä suhteita.
Tällä välin SRE-tiimi on työskennellyt Quayn pyyntöjen havaittavuuden ja yleisen palvelun kunnon parantamiseksi. Uusia mittareita ja kojetauluja on otettu käyttöön, joka näyttää, mitkä laiturin osat ovat asiakkaiden kysytyimpiä.
Quay.io toimi hyvin kesäkuun 9. päivään asti. Tänä aamuna (EDT) tietokantayhteyksien määrä kasvoi jälleen merkittävästi. Tällä kertaa ei ollut seisokkeja, koska uusi parametri rajoitti niiden määrää eikä sallinut niiden ylittää MySQL:n suorituskykyä. Kuitenkin noin puolen tunnin ajan monet käyttäjät havaitsivat quay.io:n hitaan toiminnan. Keräsimme nopeasti kaikki mahdolliset tiedot lisättyjen seurantatyökalujen avulla. Yhtäkkiä ilmestyi kuvio.
Juuri ennen yhteyksien lisääntymistä App Registry API:lle tehtiin suuri määrä pyyntöjä. App Registry on quay.io:n vähän tunnettu ominaisuus. Sen avulla voit tallentaa asioita, kuten Helm-kaavioita ja säiliöitä, joissa on runsaasti metatietoja. Useimmat quay.io-käyttäjät eivät käytä tätä ominaisuutta, mutta Red Hat OpenShift käyttää sitä aktiivisesti. OperatorHub osana OpenShiftiä tallentaa kaikki operaattorit sovellusrekisteriin. Nämä operaattorit muodostavat perustan OpenShift-työkuormitusekosysteemille ja kumppanikeskeiselle toimintamallille (2. päivän toiminnot).
Jokainen OpenShift 4 -klusteri käyttää sisäänrakennetun OperatorHubin operaattoreita julkaistakseen luettelon asennettavista operaattoreista ja päivittääkseen jo asennettuja. OpenShift 4:n kasvavan suosion myötä sen klusterien määrä ympäri maailmaa on myös lisääntynyt. Jokainen näistä klusteista lataa operaattorin sisältöä sisäänrakennetun OperatorHubin suorittamista varten käyttämällä quay.io:n sovellusrekisteriä taustaohjelmana. Ongelman lähdettä etsiessämme jäi huomaamatta, että OpenShiftin suosion asteittain kasvaessa myös yhden harvoin käytetyn quay.io-toiminnon kuormitus lisääntyi..
Analysoimme App Registry -pyyntöliikennettä ja tarkastelimme rekisterikoodia. Välittömästi paljastui puutteita, joiden vuoksi tietokantaan kohdistuvat kyselyt eivät muodostuneet optimaalisesti. Kun kuorma oli alhainen, ne eivät aiheuttaneet ongelmia, mutta kuorman kasvaessa niistä tuli ongelmia. Sovellusrekisterissä osoittautui olevan kaksi ongelmallista päätepistettä, jotka eivät reagoineet hyvin kasvavaan kuormitukseen: ensimmäinen tarjosi luettelon kaikista arkiston paketeista, toinen palautti paketin kaikki blobit.
Syiden poistaminen
Ensi viikolla optimoitiin itse sovellusrekisterin koodi ja sen ympäristö. Selvästi tehottomia SQL-kyselyitä muokattiin ja tarpeettomat komentokutsut poistettiin tar (se ajettiin aina, kun blobit haettiin), välimuisti lisättiin aina kun mahdollista. Tämän jälkeen teimme laajan suorituskyvyn testauksen ja vertasimme sovellusrekisterin nopeutta ennen ja jälkeen muutoksia.
Aiemmin jopa puoli minuuttia kestäneet API-pyynnöt valmistuvat nyt millisekunneissa. Seuraavalla viikolla otimme muutokset käyttöön tuotantoon, ja siitä lähtien quay.io on toiminut vakaasti. Tänä aikana App Registry -päätepisteen liikenteessä oli useita jyrkkiä piikkejä, mutta tehdyt parannukset estivät tietokannan katkokset.
Mitä olemme oppineet?
On selvää, että kaikki palvelut pyrkivät välttämään seisokkeja. Meidän tapauksessamme uskomme, että viimeaikaiset seisokit ovat auttaneet parantamaan quay.io:ta. Olemme oppineet muutaman keskeisen opetuksen, jotka haluaisimme jakaa:
- Tieto siitä, kuka ja miten käyttää palveluasi, ei ole koskaan tarpeetonta. Koska Quay "vain toimi", meidän ei koskaan tarvinnut käyttää aikaa liikenteen optimointiin ja kuorman hallintaan. Kaikki tämä loi väärän turvallisuuden tunteen, jota palvelu saattoi skaalata loputtomiin.
- Kun palvelu lakkaa, sen uudelleen käynnistäminen on ensisijainen tavoite.. Koska Quay kärsi edelleen lukitusta tietokannasta ensimmäisen käyttökatkon aikana, standardimenettelymme eivät tuottaneet toivottua vaikutusta, emmekä pystyneet palauttamaan palvelua niiden avulla. Tämä johti tilanteeseen, jossa jouduttiin käyttämään aikaa tietojen analysointiin ja keräämiseen toivoen perimmäisen syyn löytäminen - sen sijaan, että kaikki ponnistukset olisi keskitetty toimivuuden palauttamiseen.
- Arvioi kunkin palvelutoiminnon vaikutus. Asiakkaat käyttivät sovellusrekisteriä harvoin, joten se ei ollut tiimimme prioriteetti. Kun joitain tuotteen ominaisuuksia käytetään tuskin, niiden virheitä ilmaantuu harvoin, ja kehittäjät lopettavat koodin seurannan. On helppo joutua sen väärinkäsityksen uhriksi, että näin sen pitäisi olla – kunnes yhtäkkiä tämä toiminto löytää itsensä suuren tapahtuman keskipisteestä.
Mitä seuraavaksi?
Työ palvelun vakauden varmistamiseksi ei lopu koskaan ja kehitämme sitä jatkuvasti. Kun liikennemäärät kasvavat edelleen quay.io-alueella, ymmärrämme, että meillä on velvollisuus tehdä kaikkemme asiakkaidemme luottamuksen täyttämiseksi. Siksi työskentelemme tällä hetkellä seuraavien tehtävien parissa:
- Ota käyttöön vain luku -muotoisia tietokantareplikoita auttaaksesi palvelua käsittelemään asianmukaista liikennettä, jos ensisijaisen RDS-esiintymän kanssa ilmenee ongelmia.
- Päivitetään RDS-esiintymää. Nykyinen versio itsessään ei ole ongelma. Pikemminkin haluamme vain poistaa väärän jäljen (jota seurasimme epäonnistumisen aikana); Ohjelmiston ajan tasalla pitäminen eliminoi toisen tekijän tulevien käyttökatkojen varalta.
- Lisävälimuisti koko klusterin alueella. Etsimme edelleen alueita, joilla välimuisti voi vähentää tietokannan kuormitusta.
- Verkkosovelluksen palomuurin (WAF) lisääminen nähdäksesi, kuka muodostaa yhteyden quay.io-sivustoon ja miksi.
- Seuraavasta julkaisusta alkaen Red Hat OpenShift -klusterit luopuvat sovellusrekisteristä ja siirtävät operaattoriluetteloita quay.io-sivustolta saatavien konttikuvien perusteella.
- Sovellusrekisterin pitkäaikainen korvaaminen voisi olla Open Container Initiativen (OCI) artefaktimäärittelyjen tuki. Se on tällä hetkellä toteutettu alkuperäisenä Quay-toimintona, ja se on käyttäjien saatavilla, kun itse spesifikaatio on viimeistelty.
Kaikki edellä mainitut ovat osa Red Hatin meneillään olevaa investointia quay.io-sivustoon, kun siirrymme pienestä "startup-tyyppisestä" tiimistä kypsään SRE-pohjaiseen alustaan. Tiedämme, että monet asiakkaamme luottavat quay.io-palveluun päivittäisessä työssään (mukaan lukien Red Hat!) ja pyrimme kertomaan mahdollisimman avoimesti viimeaikaisista katkoksista ja meneillään olevista parannustoimista.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «'.
Lähde: will.com