🥇Post Mortem op Quay.io net verfügbar

Note. iwwersat.: Ufank August huet de Red Hat ëffentlech geschwat iwwer d'Léisung vun Accessibilitéitsproblemer, déi d'Benotzer vu sengem Service an de leschte Méint begéint haten Quay.io (et baséiert op engem Registry fir Container Biller, déi d'Firma zesumme mam Kaf vun CoreOS kritt huet). Onofhängeg vun Ärem Interessi un dësem Service als solch, de Wee, deen d'SRE Ingenieuren vun der Firma gemaach hunn fir d'Ursaachen vum Accident ze diagnostizéieren an ze eliminéieren ass léierräich.

Den 19. Mee moies fréi (Eastern Daylight Time, EDT) ass de Quay.io Service erofgefall. Den Accident huet souwuel quay.io Konsumenten wéi och Open Source Projete beaflosst mat quay.io als Plattform fir Software ze bauen an ze verdeelen. Red Hat schätzt d'Vertraue vun deenen zwee.

Eng Equipe vun SRE-Ingenieuren huet sech direkt bedeelegt a probéiert de Quay-Service sou séier wéi méiglech ze stabiliséieren. Wéi och ëmmer, wärend se dëst gemaach hunn, hunn d'Clienten d'Fäegkeet verluer nei Biller ze drécken, an nëmmen heiansdo konnten se existéierend zéien. Aus e puer onbekannte Grënn gouf d'Quay.io Datebank blockéiert nodeems de Service op voll Kapazitéit skaléiert gouf.

«Wat huet geännert?" - dat ass déi éischt Fro déi normalerweis an esou Fäll gestallt gëtt. Mir hu gemierkt datt kuerz virum Thema den OpenShift Dedicated Cluster (dee leeft quay.io) ugefaang ze aktualiséieren op d'Versioun 4.3.19. Zënter quay.io leeft op Red Hat OpenShift Dedicated (OSD), reegelméisseg Updates ware Routine an hunn ni Probleemer verursaacht. Ausserdeem, iwwer déi sechs Méint virdrun, hu mir Quay Cluster e puer Mol aktualiséiert ouni Ënnerbriechung am Service.

Wärend mir probéiert hunn de Service ze restauréieren, hunn aner Ingenieuren ugefaang en neien OSD-Cluster mat der viregter Versioun vun der Software virzebereeden, sou datt wann eppes geschitt ass, kënne se alles drop ofsetzen.

Root Ursaach Analyse

D'Haaptsymptom vum Echec war eng Lawin vun Zéngdausende vun Datenbankverbindungen, déi d'MySQL Instanz effektiv inoperabel gemaach hunn. Dëst huet et schwéier gemaach de Problem ze diagnostizéieren. Mir hunn eng Limit op déi maximal Unzuel u Verbindunge vu Cliente gesat fir dem SRE Team ze hëllefen d'Thema ze evaluéieren. Mir hunn keen ongewéinlechen Traffic an d'Datebank gemierkt: Tatsächlech goufen déi meescht Ufroe gelies, an nëmmen e puer goufen geschriwwen.

Mir hunn och probéiert e Muster am Datebankverkéier z'identifizéieren, deen dës Lawine verursaache kéint. Mir konnten awer keng Muster an de Logbicher fannen. Wärend mir waarden op den neie Stärekoup mat OSD 4.3.18 fir prett ze sinn, hu mir weider probéiert quay.io Pods ze lancéieren. All Kéier wann de Cluster voll Kapazitéit erreecht huet, géif d'Datebank afréieren. Dëst bedeit datt et néideg war d'RDS Instanz nieft all quay.io Pods nei ze starten.

Bis den Owend hu mir de Service am Read-only Modus stabiliséiert an esou vill net wesentlech Funktiounen wéi méiglech behënnert (zum Beispill Nummraum Drecksammlung) fir d'Laascht op der Datebank ze reduzéieren. Gefruer sinn opgehalen mä de Grond war ni fonnt. Den neie OSD Cluster war prett, a mir migréiert de Service, verbonne Verkéier a weider Iwwerwaachung.

Quay.io huet stabil um neien OSD-Cluster geschafft, also si mir zréck an d'Datebankprotokoller, awer konnten keng Korrelatioun fannen, déi d'Blockéierungen erkläre géif. OpenShift Ingenieuren hu mat eis geschafft fir ze verstoen ob Ännerungen am Red Hat OpenShift 4.3.19 Probleemer mam Quay verursaache kënnen. Allerdéngs gouf näischt fonnt, an Et war net méiglech de Problem an Laboratoire Konditiounen ze reproduzéieren.

Zweet Echec

Den 28. Mee, kuerz viru Mëtteg EDT, ass quay.io erëm mat deemselwechte Symptom erofgefall: d'Datebank gouf gespaart. An erëm hu mir all eis Efforten an d'Enquête geheit. Éischt vun all, war et néideg de Service ze restauréieren. Allerdéngs dës Kéier RDS nei starten an quay.io Pods nei starten huet näischt gemaach: eng aner Lawine vu Verbindungen huet d'Basis iwwerwältegt. Mee firwat?

Quay ass am Python geschriwwen an all Pod funktionnéiert als eenzegen monolithesche Container. De Container Runtime leeft vill parallel Aufgaben gläichzäiteg. Mir benotzen d'Bibliothéik gevent ënner dem gunicorn Web Ufroen ze verschaffen. Wann eng Ufro an de Quay kënnt (iwwer eisen eegene API, oder iwwer Docker's API), gëtt et e gevent Aarbechter zougewisen. Typesch soll dësen Aarbechter d'Datebank kontaktéieren. Nom éischten Echec, entdeckt mir dass gevent Aarbechter mat der Datebank benotzt Standard Astellunge Verbindung.

Mat der bedeitender Unzuel vu Quay Pods an Dausende vun erakommen Ufroe pro Sekonn, eng grouss Unzuel vun Datebankverbindunge kéinten theoretesch d'MySQL Instanz iwwerwannen. Dank Iwwerwaachung war et bekannt datt Quay am Duerchschnëtt 5 Tausend Ufroe pro Sekonn veraarbecht. D'Zuel vun de Verbindunge mat der Datebank war ongeféier d'selwecht. 5 dausend Verbindunge ware gutt an de Fäegkeeten vun eiser RDS Instanz (wat kann net iwwer Zéngdausende gesot ginn). Aus e puer Grënn goufen et onerwaart Spikes an der Unzuel vun de VerbindungenMir hunn awer keng Korrelatioun mat erakommen Ufroe gemierkt.

Dës Kéier ware mir décidéiert d'Quell vum Problem ze fannen an ze eliminéieren, an eis net op e Restart ze limitéieren. Zu der Quay Codebase Ännerungen goufen gemaach fir d'Zuel vun de Verbindunge mat der Datebank fir all Aarbechter ze limitéieren gevent. Dës Nummer gouf e Parameter an der Konfiguratioun: et gouf méiglech et op der Flucht z'änneren ouni en neit Containerbild ze bauen. Fir erauszefannen wéi vill Verbindunge realistesch gehandhabt kënne ginn, hu mir e puer Tester an engem Inszenéierungsëmfeld gemaach, verschidde Wäerter gesat fir ze kucken wéi dëst d'Laaschttestszenarie beaflosst. Als Resultat gouf entdeckt datt Quay fänkt 502 Feeler ze geheien wann d'Zuel vun de Verbindungen méi wéi 10 dausend.

Mir hunn dës nei Versioun direkt op d'Produktioun ofgesat an hunn ugefaang den Datebankverbindungsplang ze iwwerwaachen. Fréier war d'Basis no ronn 20 Minutten gespaart. No 30 problemfräie Minutten hate mir Hoffnung, an eng Stonn méi spéit hu mir Vertrauen. Mir hunn de Traffic op de Site restauréiert an hunn eng postmortem Analyse ugefaang.

Nodeems Dir et fäerdeg bruecht huet de Problem ëmzegoen, wat zu Blockéierung féiert, mir hunn hir richteg Grënn net erausfonnt. Et gouf bestätegt datt et net mat Ännerungen am OpenShift 4.3.19 verbonnen ass, well datselwecht geschitt ass op der Versioun 4.3.18, déi virdru mat Quay ouni Probleemer geschafft huet.

Et war kloer eppes anescht am Stärekoup gelauert.

Detailléiert Etude

Quay.io huet d'Standardastellunge benotzt fir sechs Joer ouni Probleemer mat der Datebank ze verbannen. Wat huet geännert? Et ass kloer datt all dës Zäit Traffic op quay.io stänneg gewuess ass. An eisem Fall huet et ausgesinn, wéi wann ee Schwellwäert erreecht wier, deen als Ausléiser fir eng Lawine vu Verbindungen gedéngt huet. Mir hunn d'Datebankprotokoller no der zweeter Echec studéiert, awer hu keng Mustere oder offensichtlech Bezéiungen fonnt.

An der Zwëschenzäit huet d'SRE Team un Verbesserungen vun der Quay Ufroobservabilitéit an der allgemenger Servicegesondheet geschafft. Nei Metriken an Dashboards goufen ofgesat, weist wéi eng Deeler vum Quai am meeschte gefrot gi vu Clienten.

Quay.io huet bis den 9. Juni gutt geschafft. Haut de Moien (EDT) hu mir erëm eng däitlech Erhéijung vun der Zuel vun den Datebankverbindunge gesinn. Dës Kéier gouf et keng Ausdauer, well den neie Parameter hir Zuel limitéiert huet an et net erlaabt huet de MySQL-Duerchgang ze iwwerschreiden. Wéi och ëmmer, fir ongeféier eng hallef Stonn hu vill Benotzer eng lues Leeschtung vu quay.io bemierkt. Mir hu séier all méiglech Donnéeë gesammelt mat den zousätzlechen Iwwerwaachungsinstrumenter. Op eemol ass e Muster entstanen.

Just virum Iwwerschwemmung vu Verbindungen goufen eng grouss Zuel vun Ufroe un d'App Registry API gemaach. App Registry ass eng wéineg bekannt Feature vu quay.io. Et erlaabt Iech Saachen wéi Helm Charts a Container mat räiche Metadaten ze späicheren. Déi meescht quay.io Benotzer schaffen net mat dëser Feature, awer Red Hat OpenShift benotzt se aktiv. OperatorHub als Deel vun OpenShift späichert all Betreiber an der App Registry. Dës Betreiber bilden d'Basis fir den OpenShift Workload Ökosystem a Partner-centric Betribsmodell (Dag 2 Operatiounen).

All OpenShift 4 Stärekoup benotzt Betreiber aus dem agebaute OperatorHub fir e Katalog vun Operatoren ze verëffentlechen déi fir d'Installatioun verfügbar sinn an d'Aktualiséierunge fir déi scho installéiert. Mat der wuessender Popularitéit vum OpenShift 4 ass d'Zuel vu Cluster op der ganzer Welt och eropgaang. Jiddereng vun dëse Stärekéip luet den Bedreiwerinhalt erof fir den agebaute OperatorHub auszeféieren, andeems d'App Registry bannent quay.io als Backend benotzt. An eiser Sich no der Quell vum Problem hu mir d'Tatsaach verpasst datt wéi OpenShift graduell an der Popularitéit gewuess ass, d'Laascht op eng vun de selten benotzte Quay.io Funktiounen och eropgaang..

Mir hunn e puer Analyse vum App Registry Ufro Traffic gemaach an de Registry Code gekuckt. Direkt goufen Mängel opgedeckt, wéinst deenen Ufroen un d'Datebank net optimal geformt goufen. Wann d'Laascht niddereg war, hunn se keng Probleemer verursaacht, awer wann d'Belaaschtung eropgeet, goufen se eng Quell vu Probleemer. App Registry huet sech erausgestallt fir zwee problematesch Endpunkter ze hunn, déi net gutt op d'Erhéijung vun der Belaaschtung reagéiert hunn: déi éischt huet eng Lëscht vun alle Packagen am Repository geliwwert, déi zweet huet all Blobs fir de Package zréckginn.

Eliminatioun vun Ursaachen

An der nächster Woch hu mir de Code vum App Registry selwer a seng Ëmwelt optiméiert. Kloer net effikass SQL Ufroen goufen ëmgebaut an onnéideg Kommando Uruff goufen eliminéiert tar (Et gouf all Kéier gelaf wann d'Blobs erëmfonnt goufen), Caching gouf bäigefüügt wou et méiglech ass. Mir hunn dunn extensiv Performance Tester gemaach an d'Geschwindegkeet vum App Registry virun an no den Ännerungen verglach.

API Ufroen, déi virdru bis zu enger hallef Minutt gedauert hunn, ginn elo a Millisekonnen ofgeschloss. Déi nächst Woch hu mir d'Ännerunge fir d'Produktioun agesat, an zënterhier huet quay.io stabil geschafft. Wärend dëser Zäit goufen et e puer schaarf Spikes am Traffic um App Registry Endpunkt, awer d'Verbesserunge verhënnert d'Datebankausfall.

Wat hu mir geléiert?

Et ass kloer datt all Service probéiert Ausdauer ze vermeiden. An eisem Fall gleewen mir datt déi rezent Ausbréch gehollef hunn quay.io besser ze maachen. Mir hunn e puer wichteg Lektioune geléiert, déi mir gären deelen:

Daten iwwer wien Äre Service benotzt a wéi ass ni iwwerflësseg. Well Quay "just geschafft huet", hu mir ni Zäit misse verbréngen fir de Traffic ze optimiséieren an d'Laascht ze managen. All dëst huet e falscht Sécherheetsgefill erstallt datt de Service onbestëmmt ka skaléieren.
Wann de Service erof geet, et erëm op a lafen ze kréien ass eng Haaptprioritéit.. Well Quay weider ënner enger gespaarter Datebank während dem éischten Ausfall leiden, hunn eis Standardprozeduren net de virgesinnenen Effekt gemaach a mir konnten de Service net mat hinnen restauréieren. Dëst huet zu enger Situatioun gefouert wou Zäit huet missen analyséieren an Daten sammelen an der Hoffnung d'Ursaach ze fannen - amplaz all Efforten op d'Funktionalitéit ze restauréieren.
Evaluéiert den Impakt vun all Service Feature. Clienten hunn selten App Registry benotzt, also war et keng Prioritéit fir eis Team. Wann e puer Produktfeatures kaum benotzt ginn, schéngen hir Bugs selten, an d'Entwéckler stoppen de Code ze iwwerwaachen. Et ass einfach de Mëssverständnis ze falen datt dat esou ass wéi et soll sinn - bis op eemol déi Funktioun sech am Mëttelpunkt vun engem groussen Tëschefall fënnt.

Wat d'nächst?

D'Aarbecht fir d'Stabilitéit vum Service ze garantéieren hält ni op a mir verbesseren et permanent. Wéi de Verkéiersvolumen weider op quay.io wuessen, erkennen mir datt mir eng Verantwortung hunn alles ze maachen fir dem Vertrauen vun eise Clienten ze liewen. Dofir schaffe mir momentan un folgenden Aufgaben:

Deploy just read-only Datebank Repliken fir de Service ze hëllefen de passenden Traffic am Fall vu Probleemer mat der primärer RDS Instanz ze handhaben.
Aktualiséierung vun enger RDS Instanz. Déi aktuell Versioun selwer ass net de Problem. Villméi wëlle mir einfach de falschen Trail ewechhuelen (dee mir während dem Echec gefollegt hunn); D'Software up to date halen wäert en anere Faktor am Fall vun zukünfteg Ausbroch eliminéieren.
Zousätzlech Cache iwwer de ganze Cluster. Mir sichen weider no Beräicher wou Caching d'Laascht op der Datebank reduzéiere kann.
Eng Webapplikatioun Firewall (WAF) bäizefügen fir ze kucken wien op quay.io verbënnt a firwat.
Vun der nächster Verëffentlechung un, Red Hat OpenShift Cluster verloossen d'App Registry zugonschte vun den Operateur Kataloge baséiert op Container Biller verfügbar op quay.io.
E laangfristeg Ersatz fir App Registry kéint Ënnerstëtzung fir Open Container Initiative (OCI) Artefakt Spezifikatioune sinn. Et ass de Moment als gebierteg Quay Funktionalitéit implementéiert a wäert fir Benotzer verfügbar sinn wann d'Spezifikatioun selwer finaliséiert ass.

All déi uewendriwwer sinn Deel vun der lafender Investitioun vu Red Hat an quay.io wéi mir vun engem klenge "Startup-Stil" Team op eng reife SRE-driven Plattform plënneren. Mir wëssen, datt vill vun eise Clienten op quay.io an hirer alldeeglecher Aarbecht vertrauen (och Red Hat!) A mir probéieren esou transparent wéi méiglech ze sinn iwwer déi rezent Stéierungen a weider Efforte fir ze verbesseren.