{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem over de uitval van Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: 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<\/a><\/noindex> (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.<\/i><\/p>\n

\"Post
\n
\nIn 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.<\/p>\n

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.<\/a><\/noindex><\/p>\n

\u00abWat is er veranderd?<\/b>\u00bb \u2014 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.<\/p>\n

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.<\/p>\n

Analyse van de oorzaken<\/h2>\n

\nHet 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.<\/p>\n

We also attempted to identify a pattern in the database traffic that could have caused this avalanche. However, no patterns could be found in the logs. While awaiting the readiness of the new cluster with OSD 4.3.18, we continued attempts to launch the quay.io pods. Each time the cluster reached full power, the database would hang. This meant it was necessary to restart the RDS instance in addition to all the quay.io pods.<\/p>\n

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<\/b>. Het nieuwe OSD-cluster was gereed, en we hebben de service overgezet, het verkeer aangesloten en monitoring voortgezet.<\/p>\n

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.<\/b>.<\/p>\n

De tweede storing<\/h2>\n

\n28 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, This time, restarting the RDS and the quay.io pods did not lead to any results.<\/b>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<\/p>\n

gevent gunicorn<\/code> 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.<\/code> To handle web requests. When a request comes to Quay (through our own API or via Docker's API), it is assigned a gevent worker. Usually, this worker should connect to the database. After the first failure, we found that gevent workers were connecting to the database using default settings.<\/p>\n

Given the significant number of Quay pods and thousands of incoming requests per second, a large number of connections to the database could theoretically overload the MySQL instance. Monitoring showed that Quay, on average, processes 5,000 requests per second. The number of connections to the database was approximately the same. 5,000 connections comfortably fit the capabilities of our RDS instance (which cannot be said for tens of thousands). Om de een of andere reden waren er onverwachte pieken in het aantal verbindingen.<\/b>, maar we zagen geen enkele correlatie met de binnenkomende verzoeken.<\/p>\n

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 Changes were made to limit the number of database connections for each worker.<\/b> 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.<\/b><\/p>\n

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.<\/p>\n

Door het probleem dat leidde tot de blokkade te omzeilen, ontdekten we de werkelijke oorzaken ervan niet.<\/b>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.<\/p>\n

In de cluster moest er duidelijk nog iets anders verborgen zijn.<\/p>\n

Diepgaand onderzoek<\/h2>\n

\nQuay.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.<\/p>\n

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<\/b>, die laten zien welke delen van Quay het meest worden gevraag door klanten.<\/p>\n

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<\/b>, 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.<\/p>\n

Vlak voor de sprong in het aantal verbindingen ontvingen we een groot aantal verzoeken op de App Registry API<\/b>. 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.<\/p>\n

Each OpenShift 4 cluster uses operators from the built-in OperatorHub to publish a catalog of operators available for installation and provide updates for those already installed. With the growing popularity of OpenShift 4, the number of clusters running it has also increased globally. Each of these clusters loads the contents of operators to run the built-in OperatorHub, using the App Registry inside quay.io as the 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.<\/b>.<\/p>\n

We conducted an analysis of the App Registry request traffic and looked into the registry code. Immediately, shortcomings appeared that caused the database requests to be formed suboptimally. Under low load, they posed no issues, but as the load increased, they became a source of problems. The App Registry had two problematic endpoints that poorly responded to increased load: the first returned a list of all packages in the repository, the second returned all blobs for a package.<\/p>\n

Oorzaakverwijdering<\/h2>\n

\nDe 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<\/code> (het werd gestart bij elke blob-extractie), er is caching toegevoegd waar mogelijk. Vervolgens is er een uitgebreide prestatietest uitgevoerd en is de snelheid van de App Registry voor en na de wijzigingen vergeleken.<\/p>\n

API-verzoeken die voorheen tot een halve minuut duurden, werden nu uitgevoerd in milliseconden.<\/b>. Volgende week hebben we de wijzigingen in productie uitgerold, en sindsdien werkt quay.io stabiel. Tijdens deze periode zijn er verschillende scherpe verkeerspieken waargenomen op de App Registry-endpoint, maar de aangebrachte verbeteringen hebben onderbrekingen van de database voorkomen.<\/p>\n

Wat hebben we geleerd?<\/h2>\n

\nHet 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:<\/p>\n

    \n
  1. Gegevens over wie en hoe uw dienst wordt gebruikt zijn nooit overbodig.<\/b>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\u00eberd dat de dienst eindeloos kon schalen.<\/li>\n
  2. Wanneer de dienst uitvalt, is het herstellen van de werking de hoogste prioriteit.<\/b>. 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 \u2014 in plaats van al onze inspanningen te richten op het herstellen van de functionaliteit.<\/li>\n
  3. Evalueer de impact van elke functie van de service.<\/b>. 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 \u2014 totdat deze functie plotseling in het middelpunt van een grote storing komt te staan.<\/li>\n<\/ol>\n

    <\/p>\n

    Wat nu?<\/h2>\n

    \nHet 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:<\/p>\n

      \n
    1. 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.<\/li>\n
    2. 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.<\/li>\n
    3. Extra caching door het hele cluster. We blijven gebieden zoeken waar caching de belasting op de database kan verminderen.<\/li>\n
    4. Toevoegen van een webapplicatie-firewall (WAF) om te zien wie en waarom verbinding maakt met quay.io.<\/li>\n
    5. 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.<\/li>\n
    6. Een langdurige vervanger van App Registry kan de ondersteuning van de specificaties van Open Container Initiative (OCI) artifacts zijn. Dit wordt momenteel ge\u00efmplementeerd als native functionaliteit van Quay en zal beschikbaar zijn voor gebruikers zodra de specificatie definitief is goedgekeurd.<\/li>\n<\/ol>\n

      \nAl het bovenstaande maakt deel uit van de voortdurende investeringen van Red Hat in quay.io terwijl we van een klein, \u2018startup-achtig\u2019 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.<\/p>\n

      P.S. van de vertaler<\/h2>\n

      \nLees ook op onze blog:<\/p>\n