🥇Post Mortem na nedostupnost Quay.io

Pozn. přek.: na začátku srpna Red Hat veřejně informovala o řešení problémů s dostupností, které v předchozích měsících bránily uživatelům její služby Quay.io (základem je registr obrazů kontejnerů, který společnost získala s akvizicí CoreOS). Bez ohledu na vaši zájem o tuto službu, je poučné sledovat cestu, kterou SRE inženýři společnosti prošli při diagnostice a odstranění příčin selhání.

19. května, brzy ráno (podle letního severoamerického východního času, EDT), služba quay.io selhala. Selhání zasáhlo jak uživatele quay.io, tak open source projekty, které používají quay.io jako platformu pro sestavení a distribuci softwaru. Red Hat si váží důvěry obou skupin.

Tým SRE inženýrů se okamžitě zapojil do práce a snažil se co nejdříve stabilizovat provoz služby Quay. Během této doby však klienti ztratili možnost pushovat nové obrazy a pouze občas se jim podařilo pullovat existující. Z neznámého důvodu se databáze quay.io blokovala po škálování služby na plný výkon.

«Co se změnilo?» — to je první otázka, kterou je běžně kladeno v podobných případech. Všimli jsme si, že těsně před problémem začal cluster OpenShift Dedicated (na kterém běží quay.io) aktualizaci na verzi 4.3.19. Protože quay.io běží na Red Hat OpenShift Dedicated (OSD), pravidelné aktualizace byly každodenní operací a nikdy nezpůsobily žádné problémy. Navíc jsme v uplynulých šesti měsících několikrát aktualizovali clustery Quay bez jakýchkoli přerušení v poskytování služeb.

Zatímco jsme se snažili obnovit provoz služby, jiní inženýři začali připravovat nový OSD cluster s předchozí verzí softwaru, aby v případě potřeby mohli všechno rozdělit na něm.

Analýza prvních příčin

Hlavním symptomem výpadku byla lavina desítek tisíc připojení k DB, kvůli kterým byl instanci MySQL v podstatě neschopná. Díky tomu bylo těžké diagnostikovat problém. Stanovili jsme limit na maximální počet připojení od klientů, aby tým SRE mohl lépe posoudit situaci. Nebyly zaznamenány žádné neobvyklé provozy k databázi: ve skutečnosti většina dotazů byla na čtení a jen několik bylo na zápis.

Snažili jsme se také identifikovat vzor v provozu DB, který by tuto lavinu mohl způsobit. Nicméně se nám nepodařilo v logách najít žádné pravidelnosti. V očekávání připravenosti nového clusteru s OSD 4.3.18 jsme pokračovali v pokusech spustit pod'y quay.io. Pokaždé, když cluster dosáhl plné kapacity, databáze zamrzla. To znamenalo, že bylo nutné restartovat instanci RDS kromě všech pod'ů quay.io.

K večeru jsme stabilizovali službu v režimu read-only a deaktivovali maximální počet nepodstatných funkcí (například shromažďování odpadu v názvovém prostoru), abychom snížili zátěž na DB. Zmrazení se zastavilo, ale příčina nebyla stále nalezena. Nový cluster OSD byl připraven, a my jsme přešli na službu, připojili provoz a pokračovali v monitorování.

Quay.io stabilně fungoval na novém OSD clusteru, a tak jsme se vrátili k logům databáze, ale stále se nám nepodařilo odhalit korelaci vysvětlující zámky. Inženýři OpenShift s námi spolupracovali, aby se pokusili pochopit, zda změny v Red Hat OpenShift 4.3.19 mohly způsobit problémy s Quay. Nicméně se nic neobjevilo, a nepodařilo se reprodukovat problém v laboratorních podmínkách.

Druhý výpadek

28. května, krátce před polednem EDT, quay.io znovu spadl se stejnými symptomy: fungování databáze bylo blokováno. A znovu jsme nasadili všechny síly na vyšetřování. Nejdříve bylo třeba obnovit provoz služby. Nicméně tentokrát restart RDS a restart pod'ů quay.io nic nezměnily:další lavina připojení přehnala databázi. Ale proč?

Quay je napsán v Pythonu a každý pod funguje jako jednotný monolitní kontejner. V prostředí kontejneru běží současně mnoho paralelních úloh. Používáme knihovnu gevent pod gunicorn pro zpracování webových požadavků. Když do Quay přijde požadavek (přes náš vlastní API, nebo přes API Dockeru), je mu přiřazen gevent worker. Obvykle by tento worker měl navázat spojení s databází. Po prvním výpadku jsme zjistili, že gevent workery se připojují k databázi pomocí výchozích nastavení.

S ohledem na značný počet pod’ů Quay a tisíce příchozích požadavků za sekundu by mohlo velké množství připojení k databázi teoreticky přetížit instanci MySQL. Díky monitorování jsme zjistili, že Quay průměrně zpracovává 5 tisíc požadavků za sekundu. Přibližně stejný počet byl i připojení k databázi. 5 tisíc připojení jsme pohodlně zvládli naší instancí RDS (což se nedalo říci o desítkách tisíc). Z nějakého důvodu docházelo k neočekávaným výskytům počtu připojení, ale nevšimli jsme si žádné korelace s přicházejícími požadavky.

Tentokrát jsme se pevně rozhodli najít a odstranit zdroj problému, místo abychom se omezili na restartování. Do kódu Quay byly provedeny změny, které omezily počet připojení k DB pro každý worker gevent. Tento počet se stal parametrem v konfiguraci: bylo možné jej měnit „za chodu“, aniž bychom museli sestavit nový obraz kontejneru. Abychom zjistili, kolik připojení je skutečně možné zpracovat, provedli jsme několik testů ve staging prostředí, kde jsme nastavili různé hodnoty, abychom zjistili, jak to ovlivní scénáře zátěžového testování. Nakonec se ukázalo, že Quay začíná vyhazovat chyby 502, když počet připojení překročí 10 tisíc.

Okamžitě jsme nasadili tuto novou verzi do produkce a začali sledovat graf připojení k databázi. Dříve byla databáze blokována přibližně po 20 minutách. Po 30 bezproblémových minutách jsme měli naději, a po hodině jsme byli přesvědčeni. Obnovili jsme provoz zápisu na stránkách a zahájili postmortem analýzu.

Podařilo se nám obejít problém vedoucí k blokaci, ale nevyjasnili jsme jeho skutečné příčiny. Potvrdilo se, že nesouvisí s jakýmiikoli změnami v OpenShift 4.3.19, protože to samé se stalo i na verzi 4.3.18, která předtím fungovala s Quay bez jakýchkoli problémů.

V clusteru se očividně skrývalo něco dalšího.

Podrobná analýza

Quay.io již šest let využívá výchozí nastavení pro připojení k databázi bez jakýchkoli problémů. Co se změnilo? Je jasné, že v průběhu této doby neustále rostl provoz na quay.io. V našem případě to vypadalo, jako by bylo dosaženo určitého prahového bodu, který spustil lavinu připojení. Pokračovali jsme ve zkoumání databázových logů po druhém výpadku, ale nenašli jsme žádné vzory nebo zjevné souvislosti.

Mezitím se tým SRE zabýval zlepšením sledování požadavků v Quay a celkového zdraví služby. Byly nasazeny nové metriky a panely pro monitorování, které ukazují, které části Quay mají největší zájem ze strany zákazníků.

Quay.io správně fungoval až do 9. června. Ráno (podle EDT) jsme opět byli svědky významného nárůstu počtu připojení k databázi. Tentokrát k výpadku nedošlo, protože nová konfigurace omezovala jejich počet a bránila překročení kapacity MySQL. Nicméně přibližně po dobu půl hodiny mnoho uživatelů hlásilo pomalou odezvu quay.io. Rychle jsme shromáždili všechny dostupné údaje pomocí nově přidaných monitorovacích nástrojů. Náhle se objevily vzory.

Před samotným nárůstem počtu připojení přišlo velké množství požadavků na App Registry API. App Registry je málo známá funkce quay.io. Umožňuje uchovávat takové věci, jako jsou Helm grafy a kontejnerové bohaté (rich) metadata. Většina uživatelů quay.io s touto funkcí nepracuje, nicméně je aktivně používána Red Hat OpenShift. OperatorHub integrovaný v OpenShift uchovává všechny operátory v App Registry. Tito operátoři vytvářejí základ pro ekosystém pracovních zátěží OpenShift a provozní model (v rámci operací „druhého dne“, Day 2), orientovaný na partnery.

Každý OpenShift 4 cluster používá operátory z integrovaného OperatorHubu k publikaci katalogu operátorů dostupných k instalaci a poskytování aktualizací pro již nainstalované. Se vzrůstající popularitou OpenShift 4 se zvyšuje také počet clusterů na něm po celém světě. Každý z těchto clusterů načítá obsah operátorů, aby spustil integrovaný OperatorHub, používající App Registry uvnitř quay.io jako backend. V hledání zdroje problému jsme opomněli, že s postupným nárůstem popularity OpenShift narůstalo i zatížení jedné z málo využívaných funkcí quay.io..

Provedli jsme určitý rozbor provozu API registru aplikací a podívali se do kódu registru. Okamžitě se ukázaly nedostatky, které způsobovaly neoptimální vytváření dotazů na databázi. Při malém zatížení to nezpůsobovalo žádné potíže, avšak při jeho vzrůstající intenzitě se stávalo zdrojem problémů. U registru aplikací se ukázaly dva problematické endpointy, které špatně reagovaly na zvyšující se zátěž: první vracel seznam všech balíčků v repozitáři, druhý vrátil všechny blobové objekty pro konkrétní balíček.

Odstranění příčin

Celý následující týden jsme se věnovali optimalizaci kódu samotného registru aplikací a jeho okolí. Byly přepracovány jasně neefektivní SQL dotazy, odstraněny zbytečné požadavky na příkaz tar (ten se spouštěl při každém vytažení blobů), přidáno cacheování všude, kde to bylo možné. Poté bylo provedeno rozsáhlé testování výkonnosti a porovnání rychlosti fungování registru aplikací před a po změnách.

API dotazy, které dříve trvaly až půl minuty, nyní byly vykonávány za milisekundy.V následujícím týdnu jsme nasadili změny do produkce a od té doby quay.io funguje stabilně. Během této doby jsme zaznamenali několik náhlých výkyvů provozu na endpointu registru aplikací, ale provedená vylepšení zabránila výpadkům databáze.

Co jsme se naučili?

Je jasné, že každý servis se snaží vyhnout výpadkům. V našem případě věříme, že nedávné problémy přispěly k tomu, aby quay.io bylo lepším. Získali jsme několik základních lekcí, které bychom chtěli sdílet:

Informace o tom, kdo a jak používá váš servis, nejsou nikdy zbytečné.Jelikož Quay 'jednoduše fungoval', nikdy jsme neměli potřebu trávit čas optimalizací provozu a řízením zátěže. To vše vytvořilo falešný pocit bezpečí, že služba může škálovat do nekonečna.
Když služba selže, obnova její funkčnosti je hlavní prioritou.. Vzhledem k tomu, že Quay nadále trpěl blokovanou databází během prvního výpadku, naše standardní postupy neměly očekávaný efekt a nemohli jsme obnovit provoz služby s jejich pomocí. To vedlo k situaci, kdy jsme museli strávit čas analýzou a shromažďováním dat v naději, že najdeme příčinu — místo abychom veškeré úsilí zaměřili na obnovení funkčnosti.
Hodnoťte dopad každé funkce služby. Klienti zřídka používali App Registry, takže nebyl prioritou pro náš tým. Když se některé funkce produktu téměř nepoužívají, jejich chyby se 'vynořují' zřídka a vývojáři přestávají sledovat kód. Snadno se můžete stát obětí omylu, že to tak má být — až se tato funkce najednou ocitne v centru rozsáhlého incidentu.

Co dál?

Práce na zajištění stability služby nikdy nekončí a neustále ji zlepšujeme. Objem provozu na quay.io nadále roste a uvědomujeme si, že jsme povinni udělat vše pro to, abychom splnili důvěru zákazníků. Proto v současnosti pracujeme na následujících úkolech:

Nasazení replik databází pouze pro čtení, aby pomohly službě zpracovávat příslušný provoz v případě problémů s hlavním exemplářem RDS.
Aktualizace exempláře RDS. Aktuální verze sama o sobě není problém. Spíše si jen přejeme odstranit falešnou stopu (kterou jsme sledovali během výpadku); udržování softwaru v aktuálním stavu odstraní další faktor v případě budoucích výpadků.
Další mezipaměť v celém klastru. Pokračujeme v hledání oblastí, kde by mezipaměť mohla snížit zatížení databáze.
Přidání firewallu webových aplikací (WAF), abychom viděli, kdo a proč se připojuje k quay.io.
Od příštího vydání se klastry Red Hat OpenShift vzdají App Registry ve prospěch katalogů operátorů (Operator Catalogs), které jsou založeny na kontejnerech dostupných na quay.io.
Dlouhodobou náhradou App Registry by mohla být podpora specifikací artefaktů Open Container Initiative (OCI). V současné době je implementována jako nativní funkce Quay a bude dostupná uživatelům, jakmile bude specifikace definitivně schválena.

Vše výše uvedené je součástí pokračujících investic společnosti Red Hat do quay.io, jak přecházíme od malé týmu „ve stylu startupu“ k vyspělé platformě řízené SRE. Víme, že na quay.io se spoléhá mnoho našich zákazníků (včetně Red Hat!) a snažíme se být co nejotevřenější ohledně nedávných poruch a pokračujících snah stát se lepšími.