🥇Post Mortem over de uitval van Quay.io

Opmerking vertaler.: begin augustus heeft Red Hat publiekelijk gesproken over het oplossen van de beschikbaarheidsproblemen die de afgelopen maanden zijn opgetreden voor gebruikers van hun service. Quay.io (waarbij de basis een register voor containerafbeeldingen is, dat de onderneming verwierf met de aankoop van CoreOS). Ongeacht uw interesse in deze service, het pad dat de SRE-engineers van het bedrijf hebben afgelegd om de oorzaken van de storing te diagnosticeren en op te lossen, is leerzaam.

In de vroege ochtend van 19 mei (volgens de zomer tijdzone van het noordoostelijke Noord-Amerika, EDT) is de service quay.io uitgevallen. De storing trof zowel consumenten van quay.io als Open Source-projecten die quay.io gebruikten als platform voor de bouw en verspreiding van software. Red Hat hecht veel waarde aan het vertrouwen van beide groepen.

Het team van SRE-engineers ging onmiddellijk aan de slag en probeerde de werking van de Quay-service zo snel mogelijk te stabiliseren. Terwijl zij hiermee bezig waren, verloren klanten echter de mogelijkheid om nieuwe afbeeldingen te pushen en lieten ze slechts af en toe bestaande afbeeldingen pullen. Om onbekende redenen werd de database van quay.io geblokkeerd na het opschalen van de service naar zijn volledige capaciteit.

«Wat is er veranderd?» — dat is de eerste vraag die in dergelijke gevallen gesteld wordt. We hebben opgemerkt dat kort voor het probleem de OpenShift Dedicated-cluster (waarop quay.io draait) begon met het updaten naar versie 4.3.19. Aangezien quay.io draait op Red Hat OpenShift Dedicated (OSD), waren reguliere updates een alledaagse taak en leidde dit nooit tot problemen. Sterker nog, in de afgelopen zes maanden hebben we de Quay-clusters meerdere keren bijgewerkt zonder enige downtime.

Terwijl we probeerden de werking van de service te herstellen, begonnen andere ingenieurs met het voorbereiden van een nieuwe OSD-cluster met de vorige versie van de software, zodat we in geval van problemen alles daarop konden uitrollen.

Analyse van de oorzaken

Het belangrijkste symptoom van de storing was een vloedgolf van tienduizenden verbindingen met de database, waardoor het MySQL-exemplaar feitelijk onbruikbaar werd. Hierdoor was het moeilijk om het probleem te diagnosticeren. We hebben een limiet ingesteld voor het maximale aantal verbindingen van klanten om het SRE-team te helpen bij het evalueren van het probleem. We hebben geen ongewoon verkeer naar de database waargenomen: in feite waren de meeste aanvragen leesverzoeken en slechts enkele schrijfverzoeken.

We hebben ook geprobeerd een patroon in het databaseverkeer te identificeren dat deze vloedgolf zou kunnen veroorzaken. Echter, er konden geen patronen in de logs worden gevonden. In afwachting van de gereedheid van het nieuwe cluster met OSD 4.3.18, bleven we proberen de pods van quay.io te starten. Elke keer als het cluster op volle capaciteit draaide, hing de database vast. Dit betekende dat het nodig was om de RDS-instantie opnieuw op te starten, naast alle pods van quay.io.

Tegen de avond stabiliseerden we de service in een alleen-lezen modus en schakelden we zoveel mogelijk onbelangrijke functies uit (zoals het opruimen van ongebruikte ruimte), om de belasting op de database te verlagen. De vastlopers stopten, maar de oorzaak werd nog steeds niet gevonden. Het nieuwe OSD-cluster was gereed, en we hebben de service overgezet, het verkeer aangesloten en monitoring voortgezet.

Quay.io functioneerde stabiel op het nieuwe OSD-cluster, dus keerden we terug naar de database-logs, maar we konden nog steeds geen correlatie ontdekken die de blokkeringen verklaarde. De ingenieurs van OpenShift werkten samen met ons om te begrijpen of wijzigingen in Red Hat OpenShift 4.3.19 problemen met Quay konden veroorzaken. Echter, er werd niets ontdekt, en het bleek niet mogelijk om het probleem in een laboratoriumomgeving te reproduceren..

De tweede storing

28 mei, kort voor het middaguur EDT, viel quay.io opnieuw met dezelfde symptomen: de werking van de database werd geblokkeerd. En opnieuw zetten we al onze middelen in voor het onderzoek. In eerste instantie moest de service weer operationeel worden. Echter, deze keer leidde het herstarten van RDS en het opnieuw opstarten van de pods van quay.io tot niets: een nieuwe vloedgolf van verbindingen overspoelde de database. Maar waarom?Quay is geschreven in Python, en elke pod werkt als een enkele monolithische container. In de uitvoeringsomgeving van de container worden veel gelijktijdige taken uitgevoerd. We gebruiken de bibliotheek

gevent gunicorn onder voor het verwerken van webverzoeken. Wanneer Quay een verzoek ontvangt (via onze eigen API, of via de Docker API), wordt er een gevent worker toegewezen. Normaal gesproken moet deze worker verbinding maken met de database. Na de eerste storing ontdekten we dat de gevent workers verbinding maakten met de database met de standaardinstellingen. voor het verwerken van webverzoeken. Wanneer er een verzoek binnenkomt bij Quay (via onze eigen API of via de API van Docker), wordt er een gevent worker toegewezen. Gewoonlijk moet deze worker verbinding maken met de database. Na de eerste storing ontdekten we dat de gevent workers verbinding maakten met de database met gebruik van de standaardinstellingen.

Gezien het aanzienlijke aantal pod's van Quay en de duizenden binnenkomende verzoeken per seconde, had een groot aantal databaseverbindingen theoretisch het MySQL-exemplaar kunnen overbelasten. Dankzij monitoring was bekend dat Quay gemiddeld 5.000 verzoeken per seconde verwerkt. Ongeveer hetzelfde aantal verbindingen tot de database werd waargenomen. 5.000 verbindingen pasten ruim binnen de mogelijkheden van onze RDS-instantie (wat niet gezegd kan worden van tienduizenden). Om de een of andere reden waren er onverwachte pieken in het aantal verbindingen., maar we zagen geen enkele correlatie met de binnenkomende verzoeken.

Deze keer hebben we ons vastbijgezet om de bron van het probleem te vinden en op te lossen, in plaats van alleen opnieuw op te starten. In de codebasis van Quay werden aanpassingen gedaan die het aantal databaseverbindingen per worker gevent. Dit aantal werd een parameter in de configuratie: het werd mogelijk om het 'on the fly' te wijzigen, zonder een nieuw containerbeeld te hoeven opbouwen. Om te ontdekken hoeveel verbindingen werkelijk verwerkt konden worden, werden er verschillende tests uitgevoerd in de staging-omgeving, waarbij verschillende waarden werden ingesteld om te zien hoe dit invloed had op de belastingstestscenario's. Uiteindelijk werd ontdekt dat Quay fouten 502 begint te geven wanneer het aantal verbindingen de 10.000 overschrijdt.

We hebben deze nieuwe versie meteen in productie gebracht en de verbindingen met de database in de gaten gehouden. Eerder werd de database ongeveer na 20 minuten geblokkeerd. Na 30 probleemloze minuten hadden we hoop, en na een uur - zekerheid. We herstelden het schrijfverkeer op de site en begonnen met de postmortem-analyse.

Door het probleem dat leidde tot de blokkade te omzeilen, ontdekten we de werkelijke oorzaken ervan niet.Het bleek dat het niet gerelateerd was aan veranderingen in OpenShift 4.3.19, aangezien hetzelfde gebeurde op versie 4.3.18, die eerder zonder problemen met Quay werkte.

In de cluster moest er duidelijk nog iets anders verborgen zijn.

Diepgaand onderzoek

Quay.io heeft zes jaar lang de standaardinstellingen gebruikt voor de verbinding met de database zonder enige problemen. Wat is er veranderd? Het is duidelijk dat het verkeer naar quay.io gedurende deze tijd gestaag is gegroeid. In ons geval leek het alsof een drempelwaarde werd bereikt die een lawine aan verbindingen triggerde. We bleven de logs van de database onderzoeken na de tweede storing, maar ontdekten geen patronen of duidelijke verbanden.

Ondertussen was het SRE-team bezig met verbeteringen op het gebied van de observatie van verzoeken in Quay en de algehele gezondheid van de service. Nieuwe metrics en dashboards zijn uitgerold, die laten zien welke delen van Quay het meest worden gevraag door klanten.

Quay.io functioneerde normaal tot 9 juni. In de ochtend (in EDT) werden we opnieuw getuige van een significante toename van het aantal verbindingen met de database. Deze keer vond er geen downtime plaats, omdat een nieuwe parameter het aantal verbindingen beperkte en verhinderde dat de capaciteit van MySQL werd overschreden. Echter, voor ongeveer een half uur ervoeren veel gebruikers traagheden op quay.io. We verzamelden snel alle beschikbare gegevens door gebruik te maken van de toegevoegde monitoringtools. Plotseling verscheen er een patroon.

Vlak voor de sprong in het aantal verbindingen ontvingen we een groot aantal verzoeken op de App Registry API. App Registry is een minder bekende functie van quay.io. Het maakt het mogelijk om dingen zoals Helm charts en containers met rijke metadata op te slaan. De meeste gebruikers van quay.io maken geen gebruik van deze functie, maar ze wordt actief gebruikt door Red Hat OpenShift. OperatorHub binnen OpenShift slaat alle operators op in App Registry. Deze operators vormen de basis voor het ecosysteem van OpenShift-werloaden en het operationele model (in het kader van 'tweede dag'-operaties) gericht op partners.

Elke OpenShift 4-cluster gebruikt operators uit de ingebouwde OperatorHub om de catalogus van beschikbare operators voor installatie te publiceren en updates voor al geïnstalleerde operators te bieden. Met de groeiende populariteit van OpenShift 4 is ook het aantal clusters wereldwijd toegenomen. Elk van deze clusters laadt de inhoud van operators om de ingebouwde OperatorHub te starten en gebruikt App Registry binnen quay.io als backend. Bij het zoeken naar de oorzaak van het probleem hebben we gemist dat met de geleidelijke toename van de populariteit van OpenShift ook de belasting op een van de zelden gebruikte functies van quay.io toenam..

We hebben een analyse uitgevoerd van het verkeer van verzoeken aan App Registry en zijn in de code van het register gedoken. Meteen kwamen er tekortkomingen aan het licht, waardoor de databaseverzoeken suboptimaal werden gevormd. Bij een lage belasting veroorzaakten ze geen problemen, maar wanneer de belasting toenam, werden ze een bron van problemen. App Registry had twee problematische eindpunten die slecht reageerden op de toename van de belasting: de eerste gaf een lijst van alle pakketten in de repository, de tweede gaf alle blob's voor een pakket terug.

Oorzaakverwijdering

De hele volgende week hebben we gewerkt aan het optimaliseren van de code van App Registry en zijn omgeving. Ineffectieve SQL-query's werden herzien, overbodige aanroepen van commando's werden verwijderd, tar (het werd bij elke blob-oproep uitgevoerd), en er werd caching toegevoegd waar mogelijk. Vervolgens werd er een uitgebreide prestatietest uitgevoerd en werd de snelheid van App Registry voor en na de wijzigingen vergeleken.

API-verzoeken die voorheen tot een halve minuut duurden, werden nu uitgevoerd in milliseconden.In de daaropvolgende week hebben we de wijzigingen in productie uitgerold en sindsdien werkt quay.io stabiel. Gedurende deze tijd waren er enkele scherpe pieken in het verkeer op het eindpunt van App Registry, maar de aangebrachte verbeteringen hebben storingen in de database voorkomen.

Wat hebben we geleerd?

Het is duidelijk dat elke dienst probeert downtime te vermijden. In ons geval geloven we dat de recente storingen hebben geholpen om quay.io beter te maken. We hebben verschillende belangrijke lessen geleerd die we willen delen:

Gegevens over wie en hoe uw dienst wordt gebruikt zijn nooit overbodig.Omdat Quay 'gewoon werkte', hebben we nooit de noodzaak gevoeld om tijd door te brengen aan het optimaliseren van verkeer en het beheren van belasting. Dit heeft een valse gevoel van veiligheid gecreëerd dat de dienst eindeloos kon schalen.
Wanneer de dienst uitvalt, is het herstellen van de werking de hoogste prioriteit.. Aangezien Quay bleef lijden onder een geblokkeerde database tijdens de eerste storing, hebben onze standaardprocedures niet het beoogde effect gehad en konden we de diensten niet herstellen met hun hulp. Dit leidde tot een situatie waarin tijd moest worden besteed aan analyse en gegevensverzameling in de hoop de hoofdoorzaak te vinden — in plaats van al onze inspanningen te richten op het herstellen van de functionaliteit.
Evalueer de impact van elke functie van de service.. Klanten gebruikten App Registry zelden, waardoor het geen prioriteit was voor ons team. Wanneer bepaalde productfuncties bijna niet worden gebruikt, komen bugs zelden aan het licht en verliezen ontwikkelaars de aandacht voor de code. Het is gemakkelijk om slachtoffer te worden van de misvatting dat het zo moet zijn — totdat deze functie plotseling in het middelpunt van een grote storing komt te staan.

Wat nu?

Het werk aan het waarborgen van de stabiliteit van de service stopt nooit en we verbeteren het voortdurend. Het verkeer op quay.io blijft groeien, en we beseffen dat we alles moeten doen om het vertrouwen van onze klanten te rechtvaardigen. Daarom werken we momenteel aan de volgende taken:

Implementatie van alleen-lezen database-replicas om de service te helpen het relevante verkeer te verwerken in geval van problemen met de primaire RDS-instance.
Bijwerken van de RDS-instance. De huidige versie is op zich geen probleem. We willen simpelweg een valse piste (die we tijdens de storing volgden) opruimen; het bijhouden van de software in actuele staat zal nog een factor wegnemen voor toekomstige onderbrekingen.
Extra caching door het hele cluster. We blijven gebieden zoeken waar caching de belasting op de database kan verminderen.
Toevoegen van een webapplicatie-firewall (WAF) om te zien wie en waarom verbinding maakt met quay.io.
Vanaf de volgende release zullen Red Hat OpenShift-clusters App Registry afschaffen ten gunste van operator catalogi, gebaseerd op container images die beschikbaar zijn op quay.io.
Een langdurige vervanger van App Registry kan de ondersteuning van de specificaties van Open Container Initiative (OCI) artifacts zijn. Dit wordt momenteel geïmplementeerd als native functionaliteit van Quay en zal beschikbaar zijn voor gebruikers zodra de specificatie definitief is goedgekeurd.

Al het bovenstaande maakt deel uit van de voortdurende investeringen van Red Hat in quay.io terwijl we van een klein, ‘startup-achtig’ team overgaan naar een volwassen platform dat wordt beheerd door SRE. We weten dat veel van onze klanten op quay.io vertrouwen in hun dagelijkse werkzaamheden (inclusief Red Hat!) en we doen ons best om zo open mogelijk te zijn over recente storing en de voortdurende inspanningen om beter te worden.

Post Mortem over de uitval van Quay.io