🥇 Post mortem på grund av att Quay.io inte är tillgänglig

Notera. transl.: Red Hat talade i början av augusti offentligt om att lösa tillgänglighetsproblem som användare av dess tjänst hade stött på under tidigare månader Quay.io (det är baserat på ett register för containerbilder, som företaget fick tillsammans med köpet av CoreOS). Oavsett ditt intresse för denna tjänst som sådan, är vägen som företagets SRE-ingenjörer tog för att diagnostisera och eliminera orsakerna till olyckan lärorik.

Den 19 maj, tidigt på morgonen (Eastern Daylight Time, EDT), kraschade tjänsten quay.io. Olyckan påverkade både quay.io-konsumenter och Open Source-projekt som använde quay.io som plattform för att bygga och distribuera mjukvara. Red Hat värdesätter bådas förtroende.

Ett team av SRE-ingenjörer engagerade sig omedelbart och försökte stabilisera kajen så snart som möjligt. Men medan de höll på med detta förlorade klienterna förmågan att pusha nya bilder, och bara ibland kunde de dra befintliga. Av någon okänd anledning blockerades databasen quay.io efter att ha skalat tjänsten till full kapacitet.

«Vad har förändrats?" - det här är den första frågan som brukar ställas i sådana fall. Vi märkte att kort före problemet började OpenShift Dedicated-klustret (som kör quay.io) att uppdateras till version 4.3.19. Eftersom quay.io körs på Red Hat OpenShift Dedicated (OSD) var regelbundna uppdateringar rutinmässiga och orsakade aldrig problem. Dessutom har vi under de senaste sex månaderna uppgraderat Quay-kluster flera gånger utan något avbrott i tjänsten.

Medan vi försökte återställa tjänsten började andra ingenjörer förbereda ett nytt OSD-kluster med den tidigare versionen av programvaran, så att om något hände kunde de distribuera allt på det.

Grundorsaksanalys

Huvudsymtomet på misslyckandet var en lavin av tiotusentals databasanslutningar, vilket gjorde MySQL-instansen i praktiken obrukbar. Detta gjorde det svårt att diagnostisera problemet. Vi har satt en gräns för det maximala antalet anslutningar från klienter för att hjälpa SRE-teamet att utvärdera problemet. Vi märkte ingen ovanlig trafik till databasen: i själva verket lästes de flesta förfrågningar och endast ett fåtal skrevs.

Vi försökte också identifiera ett mönster i databastrafiken som kunde orsaka denna lavin. Vi kunde dock inte hitta några mönster i loggarna. I väntan på att det nya klustret med OSD 4.3.18 skulle vara klart fortsatte vi att försöka lansera quay.io pods. Varje gång klustret nådde full kapacitet, fryser databasen. Detta innebar att det var nödvändigt att starta om RDS-instansen förutom alla quay.io-poddar.

På kvällen stabiliserade vi tjänsten i skrivskyddat läge och inaktiverade så många icke-nödvändiga funktioner som möjligt (till exempel skräpinsamling av namnutrymme) för att minska belastningen på databasen. Frysningarna har upphört men orsaken hittades aldrig. Det nya OSD-klustret var klart och vi migrerade tjänsten, ansluten trafik och fortsatt övervakning.

Quay.io arbetade stabilt på det nya OSD-klustret, så vi gick tillbaka till databasloggarna, men kunde inte hitta en korrelation som skulle förklara blockeringarna. OpenShifts ingenjörer arbetade med oss för att förstå om ändringar i Red Hat OpenShift 4.3.19 kunde orsaka problem med Quay. Men ingenting hittades, och Det var inte möjligt att reproducera problemet i laboratorieförhållanden.

Andra misslyckandet

Den 28 maj, strax före middagstid EDT, kraschade quay.io igen med samma symptom: databasen blockerades. Och återigen lade vi alla våra ansträngningar på utredningen. Först och främst var det nödvändigt att återställa tjänsten. dock den här gången gjorde omstart av RDS och omstart av quay.io pods ingenting: ytterligare en lavin av anslutningar har överväldigat basen. Men varför?

Quay är skrivet i Python och varje pod fungerar som en enda monolitisk behållare. Containerruntime kör många parallella uppgifter samtidigt. Vi använder biblioteket gevent enligt gunicorn att behandla webbförfrågningar. När en förfrågan kommer till Quay (via vårt eget API, eller via Dockers API), tilldelas den en givent worker. Vanligtvis bör den här arbetaren kontakta databasen. Efter det första misslyckandet upptäckte vi att gavt arbetare ansluter till databasen med standardinställningar.

Med tanke på det betydande antalet Quay-pods och tusentals inkommande förfrågningar per sekund, kan ett stort antal databasanslutningar teoretiskt sett överväldiga MySQL-instansen. Tack vare övervakning var det känt att Quay i genomsnitt behandlar 5 tusen förfrågningar per sekund. Antalet anslutningar till databasen var ungefär detsamma. 5 tusen anslutningar var väl inom kapaciteten för vår RDS-instans (vilket inte kan sägas om tiotusentals). Av någon anledning var det oväntade toppar i antalet anslutningar, dock märkte vi inget samband med inkommande förfrågningar.

Den här gången var vi fast beslutna att hitta och eliminera källan till problemet, och inte begränsa oss till en omstart. Till Quay-kodbasen ändringar gjordes för att begränsa antalet anslutningar till databasen för varje arbetare gevent. Detta nummer blev en parameter i konfigurationen: det blev möjligt att ändra det i farten utan att bygga en ny containerbild. För att ta reda på hur många anslutningar som skulle kunna hanteras realistiskt, körde vi flera tester i en iscensättningsmiljö och satte olika värden för att se hur detta skulle påverka scenarier för belastningstestning. Som ett resultat upptäcktes det Quay börjar kasta 502 fel när antalet anslutningar överstiger 10 tusen.

Vi distribuerade omedelbart den här nya versionen till produktion och började övervaka databasanslutningsschemat. Tidigare var basen låst efter cirka 20 minuter. Efter 30 problemfria minuter hade vi hopp, och en timme senare hade vi självförtroende. Vi återställde trafiken till webbplatsen och började analysera efter slakt.

Efter att ha lyckats kringgå problemet som leder till blockering, vi har inte tagit reda på dess verkliga orsaker. Det bekräftades att det inte är relaterat till några ändringar i OpenShift 4.3.19, eftersom samma sak hände på version 4.3.18, som tidigare fungerade med Quay utan problem.

Det var helt klart något annat som låg på lur i klungan.

Detaljerad studie

Quay.io använde standardinställningarna för att ansluta till databasen i sex år utan problem. Vad förändrades? Det är tydligt att trafiken på quay.io hela tiden har ökat stadigt. I vårt fall såg det ut som om något tröskelvärde hade uppnåtts, vilket fungerade som en utlösande faktor för en lavin av förbindelser. Vi fortsatte att studera databasloggarna efter det andra felet, men hittade inga mönster eller uppenbara samband.

Under tiden har SRE-teamet arbetat med förbättringar av Quays begäran om observerbarhet och övergripande servicehälsa. Nya mätvärden och instrumentpaneler har implementerats, som visar vilka delar av kajen som är mest efterfrågade från kunderna.

Quay.io fungerade bra fram till den 9 juni. I morse (EDT) såg vi återigen en betydande ökning av antalet databasanslutningar. Den här gången blev det ingen stilleståndstid, eftersom den nya parametern begränsade deras antal och inte tillät dem att överskrida MySQL-genomströmningen. Men under ungefär en halvtimme noterade många användare långsam prestanda för quay.io. Vi samlade snabbt in all tänkbar data med hjälp av de extra övervakningsverktygen. Plötsligt dök ett mönster upp.

Strax innan ökningen av anslutningar gjordes ett stort antal förfrågningar till App Registry API. App Registry är en föga känd funktion på quay.io. Det låter dig lagra saker som Helm-diagram och behållare med rik metadata. De flesta quay.io-användare arbetar inte med den här funktionen, men Red Hat OpenShift använder den aktivt. OperatorHub som en del av OpenShift lagrar alla operatörer i appregistret. Dessa operatörer utgör grunden för OpenShifts arbetsbelastningsekosystem och partnercentrerad verksamhetsmodell (dag 2-operationer).

Varje OpenShift 4-kluster använder operatörer från den inbyggda OperatorHub för att publicera en katalog över operatörer som är tillgängliga för installation och tillhandahålla uppdateringar till de som redan är installerade. Med den växande populariteten för OpenShift 4 har antalet kluster på den runt om i världen också ökat. Vart och ett av dessa kluster laddar ner operatörsinnehåll för att köra den inbyggda OperatorHub, med appregistret inuti quay.io som backend. I vårt sökande efter källan till problemet missade vi det faktum att när OpenShift gradvis växte i popularitet, ökade också belastningen på en av de sällan använda funktionerna på quay.io..

Vi gjorde lite analys av appregistreringsförfrågningar och tog en titt på registerkoden. Omedelbart avslöjades brister, på grund av vilka frågor till databasen inte utformades optimalt. När belastningen var låg orsakade de inga problem, men när belastningen ökade blev de en källa till problem. App Registry visade sig ha två problematiska slutpunkter som inte svarade bra på ökande belastning: den första gav en lista över alla paket i förvaret, den andra returnerade alla blobs för paketet.

Eliminera orsaker

Under nästa vecka ägnade vi åt att optimera koden för själva appregistret och dess miljö. Klart ineffektiva SQL-frågor omarbetades och onödiga kommandoanrop eliminerades tar (den kördes varje gång blobbar hämtades), caching lades till där det var möjligt. Vi genomförde sedan omfattande prestandatester och jämförde appregistrets hastighet före och efter ändringarna.

API-förfrågningar som tidigare tog upp till en halv minut slutförs nu på millisekunder. Nästa vecka implementerade vi förändringarna i produktionen och sedan dess har quay.io fungerat stabilt. Under denna tid var det flera kraftiga toppar i trafiken på appregistrets slutpunkt, men de förbättringar som gjordes förhindrade databasavbrott.

Vad har vi lärt oss?

Det är tydligt att alla tjänster försöker undvika driftstopp. I vårt fall tror vi att de senaste avbrotten har bidragit till att göra quay.io bättre. Vi har lärt oss några viktiga lärdomar som vi skulle vilja dela med oss av:

Data om vem som använder din tjänst och hur är aldrig överflödig. Eftersom Quay "bara fungerade" behövde vi aldrig lägga tid på att optimera trafiken och hantera belastningen. Allt detta skapade en falsk trygghet att tjänsten kunde skala på obestämd tid.
När tjänsten går ner, att få den igång igen är en högsta prioritet.. Eftersom Quay fortsatte att lida av en låst databas under det första avbrottet, fick våra standardprocedurer inte avsedd effekt och vi kunde inte återställa tjänsten med hjälp av dem. Detta ledde till en situation där tid fick läggas på att analysera och samla in data i hopp om att hitta grundorsaken – istället för att fokusera alla ansträngningar på att återställa funktionalitet.
Utvärdera effekten av varje tjänstefunktion. Kunder använde sällan App Registry, så det var inte en prioritet för vårt team. När vissa produktfunktioner knappt används uppstår deras buggar sällan och utvecklare slutar övervaka koden. Det är lätt att falla offer för missuppfattningen att det är så det borde vara – tills den funktionen plötsligt befinner sig i centrum för en stor incident.

Vad händer nu?

Arbetet med att säkerställa tjänstens stabilitet upphör aldrig och vi förbättrar den hela tiden. När trafikvolymerna fortsätter att växa på quay.io inser vi att vi har ett ansvar att göra allt vi kan för att leva upp till våra kunders förtroende. Därför arbetar vi just nu med följande uppgifter:

Distribuera skrivskyddade databasrepliker för att hjälpa tjänsten att hantera lämplig trafik i händelse av problem med den primära RDS-instansen.
Uppdaterar en RDS-instans. Den nuvarande versionen i sig är inte problemet. Snarare vill vi helt enkelt ta bort det falska spåret (som vi följde under misslyckandet); Att hålla programvaran uppdaterad kommer att eliminera ytterligare en faktor i händelse av framtida avbrott.
Ytterligare cachning över hela klustret. Vi fortsätter att leta efter områden där cachning kan minska belastningen på databasen.
Lägga till en webbapplikationsbrandvägg (WAF) för att se vem som ansluter till quay.io och varför.
Från och med nästa release kommer Red Hat OpenShift-kluster att överge App Registry till förmån för operatörskataloger baserade på containerbilder tillgängliga på quay.io.
En långsiktig ersättning för App Registry kan vara stöd för artefaktspecifikationer för Open Container Initiative (OCI). Den är för närvarande implementerad som inbyggd Quay-funktionalitet och kommer att vara tillgänglig för användare när själva specifikationen är klar.

Allt ovanstående är en del av Red Hats pågående satsning på quay.io när vi går från ett litet "startup-style" team till en mogen SRE-driven plattform. Vi vet att många av våra kunder förlitar sig på quay.io i sitt dagliga arbete (inklusive Red Hat!) och vi försöker vara så transparenta som möjligt om de senaste avbrotten och pågående ansträngningar för att förbättra.

PS från översättaren

Läs även på vår blogg:

Källa: will.com

Post Mortem på Quay.io otillgänglighet