Poznámka. preklad.: začiatkom augusta Red Hat verejne hovoril o riešení problémov s dostupnosťou, s ktorými sa používatelia jej služby stretli v predchádzajúcich mesiacoch (je založený na registri pre obrázky kontajnerov, ktorý spoločnosť získala spolu s nákupom CoreOS). Bez ohľadu na váš záujem o túto službu ako takú, cesta, ktorou sa inžinieri SRE spoločnosti vydali na diagnostiku a odstránenie príčin nehody, je poučná.
19. mája skoro ráno (východný letný čas, EDT) sa zrútila služba quay.io. Nehoda ovplyvnila spotrebiteľov quay.io aj projekty s otvoreným zdrojovým kódom využívajúcim quay.io ako platformu na vytváranie a distribúciu softvéru. Red Hat si cení dôveru oboch.
Tím inžinierov SRE sa okamžite zapojil a pokúsil sa čo najskôr stabilizovať službu Quay. Kým to však robili, klienti stratili schopnosť pretláčať nové obrázky a iba občas sa im podarilo stiahnuť existujúce. Z nejakého neznámeho dôvodu bola databáza quay.io zablokovaná po škálovaní služby na plnú kapacitu.
«Čo sa zmenilo?“ - to je prvá otázka, ktorá sa v takýchto prípadoch zvyčajne kladie. Všimli sme si, že krátko pred problémom sa klaster OpenShift Dedicated (na ktorom beží quay.io) začal aktualizovať na verziu 4.3.19. Keďže quay.io beží na Red Hat OpenShift Dedicated (OSD), pravidelné aktualizácie boli rutinné a nikdy nespôsobovali problémy. Okrem toho sme v priebehu predchádzajúcich šiestich mesiacov niekoľkokrát zmodernizovali klastre Quay bez akéhokoľvek prerušenia prevádzky.
Zatiaľ čo sme sa pokúšali obnoviť službu, iní inžinieri začali pripravovať nový OSD cluster s predchádzajúcou verziou softvéru, takže ak by sa niečo stalo, mohli naň všetko nasadiť.
Analýza koreňovej príčiny
Hlavným príznakom zlyhania bola lavína desiatok tisíc databázových pripojení, čo spôsobilo, že inštancia MySQL bola prakticky nefunkčná. To sťažilo diagnostiku problému. Stanovili sme limit na maximálny počet spojení od klientov, aby sme pomohli tímu SRE vyhodnotiť problém. Nezaznamenali sme žiadnu nezvyčajnú návštevnosť databázy: v skutočnosti väčšina požiadaviek bola čítaná a iba niekoľko bolo zapisovaných.
Pokúsili sme sa tiež identifikovať vzor v prevádzke databázy, ktorý by mohol spôsobiť túto lavínu. V protokoloch sa nám však nepodarilo nájsť žiadne vzory. Počas čakania, kým bude pripravený nový klaster s OSD 4.3.18, sme pokračovali v pokuse spustiť moduly quay.io. Zakaždým, keď klaster dosiahne plnú kapacitu, databáza zamrzne. To znamenalo, že okrem všetkých modulov quay.io bolo potrebné reštartovať aj inštanciu RDS.
Do večera sme stabilizovali službu v režime len na čítanie a deaktivovali čo najviac nepodstatných funkcií (napríklad garbage collection), aby sme znížili zaťaženie databázy. Zamrznutia prestali ale príčina sa nikdy nenašla. Nový klaster OSD bol pripravený a migrovali sme službu, pripojili prevádzku a pokračovali v monitorovaní.
Quay.io fungovalo stabilne na novom klastri OSD, takže sme sa vrátili k databázovým protokolom, ale nenašli sme koreláciu, ktorá by vysvetľovala blokády. Inžinieri OpenShift s nami spolupracovali, aby sme pochopili, či zmeny v Red Hat OpenShift 4.3.19 môžu spôsobiť problémy s Quay. Nič sa však nenašlo a Problém nebolo možné reprodukovať v laboratórnych podmienkach.
Druhé zlyhanie
28. mája, krátko pred poludním EDT, quay.io opäť havaroval s rovnakým príznakom: databáza bola zablokovaná. A opäť sme všetko úsilie vrhli do vyšetrovania. V prvom rade bolo potrebné obnoviť službu. Avšak tentoraz reštartovanie RDS a reštartovanie modulov quay.io neurobilo nič: základňu zavalila ďalšia lavína spojení. Ale prečo?
Quay je napísaný v Pythone a každý modul funguje ako jeden monolitický kontajner. Runtime kontajnera súčasne spúšťa mnoho paralelných úloh. Využívame knižnicu gevent pod gunicorn na spracovanie webových požiadaviek. Keď príde požiadavka do Quay (cez naše vlastné API alebo cez Docker's API), je jej priradený pracovník gevent. Tento pracovník by mal zvyčajne kontaktovať databázu. Po prvom zlyhaní sme zistili, že pracovníci gevent sa pripájajú k databáze pomocou predvolených nastavení.
Vzhľadom na značný počet modulov Quay a tisícky prichádzajúcich požiadaviek za sekundu by veľké množstvo databázových pripojení teoreticky mohlo zahltiť inštanciu MySQL. Vďaka monitoringu bolo známe, že Quay spracuje v priemere 5 tisíc požiadaviek za sekundu. Počet pripojení k databáze bol približne rovnaký. 5 tisíc spojení bolo v rámci možností našej inštancie RDS (čo sa nedá povedať o desiatkach tisíc). Z nejakého dôvodu došlo k neočakávaným skokom v počte spojenínezaznamenali sme však žiadnu koreláciu s prichádzajúcimi požiadavkami.
Tentoraz sme boli odhodlaní nájsť a odstrániť zdroj problému a neobmedzovať sa na reštart. Do kódovej základne Quay boli vykonané zmeny na obmedzenie počtu pripojení k databáze pre každého pracovníka gevent. Toto číslo sa stalo parametrom v konfigurácii: bolo možné ho zmeniť za chodu bez vytvárania nového obrazu kontajnera. Aby sme zistili, koľko pripojení by sa dalo reálne zvládnuť, spustili sme niekoľko testov v prípravnom prostredí, pričom sme nastavili rôzne hodnoty, aby sme zistili, ako to ovplyvní scenáre testovania záťaže. V dôsledku toho sa zistilo, že Quay začne vyhadzovať 502 chýb, keď počet spojení prekročí 10 tisíc.
Okamžite sme nasadili túto novú verziu do produkcie a začali sme monitorovať harmonogram pripojenia k databáze. V minulosti bola základňa uzamknutá asi po 20 minútach. Po 30 bezproblémových minútach sme mali nádej ao hodinu neskôr sme mali dôveru. Obnovili sme návštevnosť stránky a začali sme s posmrtnou analýzou.
Keď sa podarilo obísť problém vedúci k zablokovaniu, nezistili sme jeho skutočné dôvody. Potvrdilo sa, že to nesúvisí so žiadnymi zmenami v OpenShift 4.3.19, keďže to isté sa stalo aj na verzii 4.3.18, ktorá predtým fungovala s Quay bez problémov.
V zhluku očividne číhalo niečo iné.
Podrobná štúdia
Quay.io používal predvolené nastavenia na pripojenie k databáze šesť rokov bez akýchkoľvek problémov. čo sa zmenilo? Je jasné, že celý ten čas návštevnosť na quay.io neustále rastie. V našom prípade to vyzeralo, ako keby bola dosiahnutá nejaká prahová hodnota, ktorá poslúžila ako spúšťač lavíny spojení. Po druhom zlyhaní sme pokračovali v štúdiu databázových protokolov, ale nenašli sme žiadne vzory ani zjavné vzťahy.
Medzitým tím SRE pracuje na zlepšení pozorovateľnosti požiadaviek Quay a celkového stavu služieb. Boli nasadené nové metriky a informačné panely, ktorá ukazuje, ktoré časti Quay sú najviac žiadané zo strany zákazníkov.
Quay.io fungovalo dobre až do 9. júna. Dnes ráno (EDT) sme opäť zaznamenali výrazný nárast počtu databázových pripojení. Tentoraz nedošlo k žiadnemu výpadku, keďže nový parameter obmedzil ich počet a neumožnil im prekročiť priepustnosť MySQL. Avšak asi pol hodiny mnohí používatelia zaznamenali pomalý výkon quay.io. Pomocou pridaných monitorovacích nástrojov sme rýchlo zhromaždili všetky možné údaje. Zrazu sa objavil vzorec.
Tesne pred nárastom pripojení sa do API registra aplikácií odoslalo veľké množstvo požiadaviek. Register aplikácií je málo známa funkcia quay.io. Umožňuje vám ukladať veci ako Helmove grafy a kontajnery s bohatými metadátami. Väčšina používateľov quay.io s touto funkciou nepracuje, ale Red Hat OpenShift ju aktívne využíva. OperatorHub ako súčasť OpenShift ukladá všetkých operátorov do registra aplikácií. Títo operátori tvoria základ pre ekosystém pracovnej záťaže OpenShift a prevádzkový model zameraný na partnera (operácie 2. dňa).
Každý klaster OpenShift 4 využíva operátorov zo vstavaného OperatorHub na zverejnenie katalógu operátorov dostupných na inštaláciu a poskytovanie aktualizácií už nainštalovaným operátorom. S rastúcou popularitou OpenShift 4 sa zvýšil aj počet klastrov na ňom po celom svete. Každý z týchto klastrov sťahuje obsah operátora na spustenie vstavaného OperatorHub pomocou registra aplikácií v quay.io ako backendu. Pri pátraní po zdroji problému nám unikla skutočnosť, že s postupným rastom popularity OpenShift sa zvýšila aj záťaž jednej z málo používaných funkcií quay.io..
Vykonali sme analýzu návštevnosti žiadostí registra aplikácií a pozreli sme sa na kód registra. Okamžite sa ukázali nedostatky, kvôli ktorým sa dotazy do databázy netvorili optimálne. Pri nízkej záťaži nespôsobovali žiadne problémy, ale keď sa záťaž zvýšila, stali sa zdrojom problémov. Ukázalo sa, že App Registry má dva problematické koncové body, ktoré nereagovali dobre na zvyšujúce sa zaťaženie: prvý poskytoval zoznam všetkých balíkov v úložisku, druhý vrátil všetky bloby pre balík.
Odstránenie príčin
Počas nasledujúceho týždňa sme sa venovali optimalizácii kódu samotného registra aplikácií a jeho prostredia. Zjavne neúčinné SQL dotazy boli prepracované a zbytočné volania príkazov boli odstránené tar (bolo spustené vždy, keď boli bloby načítané), ukladanie do vyrovnávacej pamäte bolo pridané všade, kde to bolo možné. Potom sme vykonali rozsiahle testovanie výkonu a porovnali rýchlosť registra aplikácií pred a po zmenách.
Žiadosti rozhrania API, ktoré predtým trvali až pol minúty, sú teraz dokončené v milisekundách. Ďalší týždeň sme nasadili zmeny do produkcie a odvtedy quay.io funguje stabilne. Počas tejto doby došlo k niekoľkým prudkým nárastom návštevnosti na koncovom bode App Registry, ale vykonané vylepšenia zabránili výpadkom databázy.
čo sme sa naučili?
Je jasné, že každá služba sa snaží vyhnúť prestojom. V našom prípade veríme, že nedávne výpadky pomohli zlepšiť quay.io. Naučili sme sa niekoľko kľúčových ponaučení, o ktoré by sme sa chceli podeliť:
- Údaje o tom, kto a ako používa vašu službu, nie sú nikdy nadbytočné. Keďže Quay „len fungoval“, nikdy sme nemuseli tráviť čas optimalizáciou návštevnosti a riadením zaťaženia. To všetko vytváralo falošný pocit bezpečia, ktorý mohla služba škálovať donekonečna.
- Keď služba vypadne, jeho opätovné spustenie je najvyššou prioritou.. Keďže Quay počas prvého výpadku naďalej trpel zamknutou databázou, naše štandardné postupy nemali zamýšľaný efekt a pomocou nich sme nedokázali službu obnoviť. To viedlo k situácii, keď bolo potrebné venovať čas analýze a zhromažďovaniu údajov v nádeji, že sa nájde hlavná príčina – namiesto sústredenia všetkého úsilia na obnovenie funkčnosti.
- Vyhodnoťte vplyv každej funkcie služby. Klienti zriedka používali register aplikácií, takže to nebolo pre náš tím prioritou. Keď sa niektoré funkcie produktu takmer nepoužívajú, ich chyby sa objavia len zriedka a vývojári prestanú monitorovať kód. Je ľahké prepadnúť mylnej predstave, že to tak má byť – až sa zrazu táto funkcia ocitne v centre veľkého incidentu.
Čo bude ďalej?
Práca na zabezpečení stability služby sa nikdy nezastaví a neustále ju vylepšujeme. Keďže objemy návštevnosti na quay.io naďalej rastú, uvedomujeme si, že máme zodpovednosť urobiť všetko, čo je v našich silách, aby sme naplnili dôveru našich zákazníkov. Preto momentálne pracujeme na nasledujúcich úlohách:
- Nasaďte repliky databáz len na čítanie, aby ste pomohli službe zvládnuť vhodnú prevádzku v prípade problémov s primárnou inštanciou RDS.
- Aktualizácia inštancie RDS. Samotná aktuálna verzia nie je problém. Skôr chceme jednoducho odstrániť falošnú stopu (ktorú sme sledovali počas zlyhania); Udržiavaním softvéru v aktuálnom stave sa odstráni ďalší faktor v prípade budúcich výpadkov.
- Ďalšie ukladanie do vyrovnávacej pamäte v celom klastri. Pokračujeme v hľadaní oblastí, kde môže ukladanie do vyrovnávacej pamäte znížiť zaťaženie databázy.
- Pridanie brány firewall webovej aplikácie (WAF), aby ste videli, kto sa pripája na quay.io a prečo.
- Počnúc ďalším vydaním klastre Red Hat OpenShift opustia register aplikácií v prospech katalógov operátorov založených na obrázkoch kontajnerov dostupných na quay.io.
- Dlhodobou náhradou za App Registry by mohla byť podpora špecifikácií artefaktov Open Container Initiative (OCI). V súčasnosti je implementovaná ako natívna funkcia Quay a bude k dispozícii používateľom, keď bude dokončená samotná špecifikácia.
Všetky vyššie uvedené sú súčasťou pokračujúcich investícií spoločnosti Red Hat do quay.io, keď prechádzame z malého tímu „v štýle startupov“ na vyspelú platformu riadenú SRE. Vieme, že mnohí naši zákazníci sa pri svojej každodennej práci spoliehajú na quay.io (vrátane Red Hat!) a snažíme sa byť čo najtransparentnejší, pokiaľ ide o nedávne výpadky a prebiehajúce snahy o zlepšenie.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «".
Zdroj: hab.com