Nota. transl.: a principis d'agost, Red Hat va parlar públicament sobre la solució dels problemes d'accessibilitat que els usuaris del seu servei havien trobat els mesos anteriors (es basa en un registre d'imatges de contenidors, que l'empresa va rebre juntament amb la compra de CoreOS). Independentment del vostre interès en aquest servei com a tal, el camí que van seguir els enginyers de l'SRE de l'empresa per diagnosticar i eliminar les causes de l'accident és instructiu.
El 19 de maig, a primera hora del matí (Eastern Daylight Time, EDT), el servei quay.io es va estavellar. L'accident va afectar tant als consumidors de quay.io com a projectes de codi obert que utilitzaven quay.io com a plataforma per construir i distribuir programari. Red Hat valora la confiança d'ambdós.
Un equip d'enginyers de l'SRE es va implicar immediatament i va intentar estabilitzar el servei de Quay el més aviat possible. Tanmateix, mentre feien això, els clients van perdre la capacitat d'empènyer noves imatges i només de tant en tant van poder treure les existents. Per algun motiu desconegut, la base de dades de quay.io es va bloquejar després d'escalar el servei a plena capacitat.
«Què ha canviat?"- aquesta és la primera pregunta que se sol fer en aquests casos. Ens vam adonar que poc abans del problema, el clúster dedicat OpenShift (que executa quay.io) va començar a actualitzar-se a la versió 4.3.19. Com que quay.io s'executa amb Red Hat OpenShift Dedicated (OSD), les actualitzacions periòdiques eren rutinàries i mai van causar problemes. A més, durant els sis mesos anteriors, hem actualitzat els clústers de Quay diverses vegades sense cap interrupció del servei.
Mentre intentàvem restaurar el servei, altres enginyers van començar a preparar un nou clúster OSD amb la versió anterior del programari, de manera que si passava alguna cosa, poguessin desplegar-hi tot.
Anàlisi de causes arrels
El símptoma principal de la fallada va ser una allau de desenes de milers de connexions a la base de dades, que va fer que la instància MySQL fos efectivament inoperable. Això va dificultar el diagnòstic del problema. Hem establert un límit al nombre màxim de connexions dels clients per ajudar l'equip SRE a avaluar el problema. No vam notar cap trànsit inusual a la base de dades: de fet, la majoria de les sol·licituds es van llegir i només unes poques es van escriure.
També hem intentat identificar un patró en el trànsit de la base de dades que podria provocar aquesta allau. Tanmateix, no hem pogut trobar cap patró als registres. Mentre esperàvem que el nou clúster amb OSD 4.3.18 estigués a punt, vam continuar intentant llançar pods de quay.io. Cada vegada que el clúster arribava a la seva capacitat, la base de dades es congelava. Això significava que era necessari reiniciar la instància RDS a més de tots els pods de quay.io.
Al vespre, vam estabilitzar el servei en mode de només lectura i vam desactivar tantes funcions no essencials com sigui possible (per exemple, la recollida d'escombraries de l'espai de noms) per reduir la càrrega de la base de dades. Les gelades s'han aturat però mai es va trobar el motiu. El nou clúster OSD estava preparat i vam migrar el servei, vam connectar el trànsit i vam continuar la supervisió.
Quay.io va treballar de manera estable al nou clúster OSD, de manera que vam tornar als registres de la base de dades, però no vam trobar una correlació que expliqués els bloquejos. Els enginyers d'OpenShift van treballar amb nosaltres per entendre si els canvis a Red Hat OpenShift 4.3.19 podrien causar problemes amb Quay. No obstant això, no es va trobar res, i No va ser possible reproduir el problema en condicions de laboratori.
Segon fracàs
El 28 de maig, poc abans del migdia EDT, quay.io es va estavellar de nou amb el mateix símptoma: la base de dades estava bloquejada. I de nou vam dedicar tots els nostres esforços a la investigació. En primer lloc, calia restablir el servei. malgrat això aquesta vegada, reiniciar RDS i reiniciar els pods de quay.io no va fer res: una altra allau de connexions ha desbordat la base. Però perquè?
Quay està escrit en Python i cada pod funciona com un únic contenidor monolític. El temps d'execució del contenidor executa moltes tasques paral·leles simultàniament. Utilitzem la biblioteca gevent под gunicorn per processar sol·licituds web. Quan arriba una sol·licitud a Quay (mitjançant la nostra pròpia API o l'API de Docker), se li assigna un treballador de gevent. Normalment, aquest treballador hauria de contactar amb la base de dades. Després del primer error, vam descobrir que els treballadors de gevent es connectaven a la base de dades mitjançant la configuració predeterminada.
Tenint en compte el nombre important de pods de Quay i milers de sol·licituds entrants per segon, un gran nombre de connexions de bases de dades podrien, teòricament, desbordar la instància MySQL. Gràcies al seguiment, es va saber que Quay processa una mitjana de 5 mil peticions per segon. El nombre de connexions a la base de dades era aproximadament el mateix. 5 mil connexions estaven dins de les capacitats de la nostra instància RDS (que no es pot dir de desenes de milers). Per alguna raó hi va haver pics inesperats en el nombre de connexions, però, no hem observat cap correlació amb les sol·licituds entrants.
Aquesta vegada estàvem decidits a trobar i eliminar l'origen del problema, i no limitar-nos a un reinici. A la base de codis Quay es van fer canvis per limitar el nombre de connexions a la base de dades per a cada treballador gevent. Aquest número es va convertir en un paràmetre de la configuració: va ser possible canviar-lo sobre la marxa sense construir una nova imatge de contenidor. Per esbrinar quantes connexions es podrien gestionar de manera realista, vam realitzar diverses proves en un entorn de prova, establint diferents valors per veure com això afectaria els escenaris de proves de càrrega. Com a resultat, es va descobrir que Quay comença a llançar 502 errors quan el nombre de connexions supera les 10 mil.
Immediatament vam implementar aquesta nova versió a producció i vam començar a supervisar el calendari de connexió de la base de dades. En el passat, la base estava tancada després d'uns 20 minuts. Després de 30 minuts sense problemes teníem esperança, i una hora més tard teníem confiança. Vam restablir el trànsit al lloc i vam començar l'anàlisi postmortem.
Després d'haver aconseguit eludir el problema que portava al bloqueig, no hem descobert les seves raons reals. Es va confirmar que no està relacionat amb cap canvi a l'OpenShift 4.3.19, ja que a la versió 4.3.18 va passar el mateix, que abans funcionava amb Quay sense cap problema.
Clarament hi havia alguna cosa més a l'aguait al grup.
Estudi de detall
Quay.io va utilitzar la configuració predeterminada per connectar-se a la base de dades durant sis anys sense cap problema. Què va canviar? És evident que durant tot aquest temps el trànsit a quay.io ha anat creixent de manera constant. En el nostre cas, semblava com si s'hagués assolit algun valor llindar, que va servir de detonant d'una allau de connexions. Vam continuar estudiant els registres de la base de dades després del segon error, però no vam trobar cap patró ni relació evident.
Mentrestant, l'equip de l'SRE ha estat treballant per millorar l'observabilitat de la sol·licitud de Quay i la salut general del servei. S'han desplegat noves mètriques i quadres de comandament, mostrant quines parts del moll són més demandades pels clients.
Quay.io va funcionar bé fins al 9 de juny. Aquest matí (EDT) hem tornat a veure un augment significatiu del nombre de connexions a bases de dades. Aquesta vegada no hi va haver temps d'inactivitat, ja que el nou paràmetre limitava el seu nombre i no els permetia superar el rendiment de MySQL. Tanmateix, durant aproximadament mitja hora, molts usuaris van notar un rendiment lent de quay.io. Vam recollir ràpidament totes les dades possibles mitjançant les eines de seguiment afegides. De sobte va sorgir un patró.
Just abans de l'augment de les connexions, es van fer un gran nombre de sol·licituds a l'API del registre d'aplicacions. El registre d'aplicacions és una característica poc coneguda de quay.io. Us permet emmagatzemar coses com ara gràfics Helm i contenidors amb metadades riques. La majoria dels usuaris de quay.io no treballen amb aquesta funció, però Red Hat OpenShift l'utilitza activament. OperatorHub com a part d'OpenShift emmagatzema tots els operadors al registre d'aplicacions. Aquests operadors formen la base per a l'ecosistema de càrrega de treball OpenShift i el model operatiu centrat en els socis (operacions del dia 2).
Cada clúster d'OpenShift 4 utilitza operadors de l'OperatorHub integrat per publicar un catàleg d'operadors disponibles per a la instal·lació i proporcionar actualitzacions als que ja estan instal·lats. Amb la creixent popularitat d'OpenShift 4, també ha augmentat el nombre de clústers a tot el món. Cadascun d'aquests clústers descarrega contingut de l'operador per executar l'OperatorHub integrat, utilitzant el registre d'aplicacions dins de quay.io com a backend. En la nostra recerca de l'origen del problema, vam perdre el fet que a mesura que OpenShift va augmentar gradualment en popularitat, també va augmentar la càrrega d'una de les funcions de quay.io poc utilitzades..
Hem fet una anàlisi del trànsit de sol·licituds d'App Registry i hem fet una ullada al codi de registre. Immediatament, es van revelar deficiències, a causa de les quals les consultes a la base de dades no es van formar de manera òptima. Quan la càrrega era baixa, no causaven cap problema, però quan augmentava la càrrega es convertien en una font de problemes. El registre d'aplicacions va resultar tenir dos punts finals problemàtics que no responien bé a l'augment de la càrrega: el primer proporcionava una llista de tots els paquets del dipòsit, el segon retornava tots els blobs del paquet.
Eliminació de causes
Durant la setmana vinent vam dedicar l'optimització del codi del propi registre d'aplicacions i del seu entorn. Les consultes SQL clarament ineficaces es van tornar a treballar i es van eliminar les trucades d'ordres innecessàries tar (s'executava cada cop que es recuperaven taques), es va afegir la memòria cau sempre que era possible. Després vam realitzar proves de rendiment exhaustives i vam comparar la velocitat del registre d'aplicacions abans i després dels canvis.
Les sol·licituds d'API que abans trigaven fins a mig minut es completen ara en mil·lisegons. La setmana següent vam desplegar els canvis a la producció, i des de llavors quay.io ha estat treballant de manera estable. Durant aquest temps, hi va haver diversos pics forts en el trànsit al punt final del registre d'aplicacions, però les millores realitzades van evitar les interrupcions de la base de dades.
Què hem après?
És evident que qualsevol servei intenta evitar temps d'inactivitat. En el nostre cas, creiem que les interrupcions recents han ajudat a millorar quay.io. Hem après algunes lliçons clau que ens agradaria compartir:
- Les dades sobre qui utilitza el vostre servei i com no són mai superflues. Com que Quay "només funcionava", mai hem hagut de dedicar temps a optimitzar el trànsit i gestionar la càrrega. Tot això va crear una falsa sensació de seguretat que el servei podia escalar indefinidament.
- Quan el servei baixa, tornar-lo a posar en marxa és una prioritat.. Com que Quay va continuar patint una base de dades bloquejada durant la primera interrupció, els nostres procediments estàndard no van tenir l'efecte previst i no vam poder restaurar el servei utilitzant-los. Això va provocar una situació en què s'havia de dedicar temps a analitzar i recollir dades amb l'esperança de trobar la causa arrel, en lloc de centrar tots els esforços a restaurar la funcionalitat.
- Avalueu l'impacte de cada característica del servei. Els clients poques vegades utilitzaven App Registry, de manera que no era una prioritat per al nostre equip. Quan algunes característiques del producte amb prou feines s'utilitzen, els seus errors rarament apareixen i els desenvolupadors deixen de supervisar el codi. És fàcil caure en la concepció errònia que hauria de ser així, fins que de sobte aquesta funció es troba al centre d'un incident important.
Què serà el següent?
La feina per garantir l'estabilitat del servei no s'atura mai i l'estem millorant constantment. A mesura que els volums de trànsit segueixen creixent a quay.io, reconeixem que tenim la responsabilitat de fer tot el possible per estar a l'altura de la confiança dels nostres clients. Per tant, actualment estem treballant en les següents tasques:
- Desplegueu rèpliques de bases de dades només de lectura per ajudar el servei a gestionar el trànsit adequat en cas de problemes amb la instància RDS principal.
- Actualització d'una instància RDS. La versió actual en si no és el problema. Més aviat, simplement volem eliminar el rastre fals (que vam seguir durant la falla); Mantenir el programari actualitzat eliminarà un altre factor en cas de futures interrupcions.
- Emmagatzematge a la memòria cau addicional a tot el clúster. Continuem buscant àrees on la memòria cau pot reduir la càrrega de la base de dades.
- Afegir un tallafoc d'aplicacions web (WAF) per veure qui es connecta a quay.io i per què.
- A partir de la propera versió, els clústers de Red Hat OpenShift abandonaran el registre d'aplicacions a favor dels catàlegs d'operadors basats en imatges de contenidors disponibles a quay.io.
- Un reemplaçament a llarg termini del registre d'aplicacions podria ser el suport per a les especificacions d'artefactes Open Container Initiative (OCI). Actualment està implementat com a funcionalitat nativa de Quay i estarà disponible per als usuaris quan es finalitzi l'especificació.
Tot l'anterior formen part de la inversió contínua de Red Hat a quay.io mentre passem d'un petit equip "d'estil d'inici" a una plataforma madura impulsada per SRE. Sabem que molts dels nostres clients confien en quay.io en la seva feina diària (inclòs Red Hat!) i intentem ser el més transparents possible sobre les interrupcions recents i els esforços en curs per millorar.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «».
Font: www.habr.com