{"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\/ro\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem privind inaccesibilitatea Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota traduc\u0103torului.<\/b>: la \u00eenceputul lunii august, Red Hat a anun\u021bat public despre solu\u021biile pentru problemele de disponibilitate care au ap\u0103rut \u00een lunile anterioare pentru utilizatorii serviciului s\u0103u. Quay.io<\/a><\/noindex> (\u00een esen\u021b\u0103, acesta este un registru pentru imagini de containere, primit de companie odat\u0103 cu achizi\u021bionarea CoreOS). Indiferent de interesul dumneavoastr\u0103 fa\u021b\u0103 de acest serviciu, calea pe care inginerii SRE ai companiei au parcurs-o pentru a diagnostica \u0219i a rezolva cauzele \u00eentreruperii este instructiv\u0103.<\/i><\/p>\n

\"Post
\n
\nPe 19 mai, devreme \u00een diminea\u021b\u0103 (ora de var\u0103 a timpului de est al Americii de Nord, EDT), serviciul quay.io a c\u0103zut. Incidentul a afectat at\u00e2t utilizatorii quay.io, c\u00e2t \u0219i proiectele Open Source care folosesc quay.io ca platform\u0103 pentru construirea \u0219i distribuirea software-ului. Red Hat valorific\u0103 \u00eencrederea at\u00e2t a uneia, c\u00e2t \u0219i a celeilalte p\u0103r\u021bi.<\/p>\n

Echipa de ingineri SRE a intervenit imediat \u0219i a \u00eencercat s\u0103 stabilizeze serviciul Quay c\u00e2t mai repede posibil. Cu toate acestea, \u00een timp ce ace\u0219tia lucrau, clien\u021bii nu au putut s\u0103 \u00eemping\u0103 noi imagini \u0219i doar ocazional reu\u0219eau s\u0103 descarce cele existente. Dintr-o cauz\u0103 necunoscut\u0103, baza de date quay.io se bloca dup\u0103 scalarea serviciului la capacitate maxim\u0103.<\/a><\/noindex><\/p>\n

\u00abCe s-a schimbat?<\/b>\u00bb \u2014 aceasta este prima \u00eentrebare pe care se obi\u0219nuie\u0219te s\u0103 o pun\u0103 \u00een astfel de cazuri. Am observat c\u0103, cu pu\u021bin timp \u00eenainte de problem\u0103, clusterul OpenShift Dedicated (pe care ruleaz\u0103 quay.io) a \u00eenceput s\u0103 se actualizeze la versiunea 4.3.19. Deoarece quay.io func\u021bioneaz\u0103 pe Red Hat OpenShift Dedicated (OSD), actualiz\u0103rile regulate erau o opera\u021biune obi\u0219nuit\u0103 \u0219i niciodat\u0103 nu au cauzat probleme. Mai mult, \u00een ultimele \u0219ase luni, am actualizat de mai multe ori clusterele Quay f\u0103r\u0103 vreo \u00eentrerupere \u00een serviciu.<\/p>\n

\u00cen timp ce \u00eencercam s\u0103 restabilim func\u021bionarea serviciului, al\u021bi ingineri au \u00eenceput s\u0103 preg\u0103teasc\u0103 un nou cluster OSD cu o versiune anterioar\u0103 a software-ului, pentru a putea desf\u0103\u0219ura totul pe acesta, \u00een caz de necesitate.<\/p>\n

Analiza cauzelor principale<\/h2>\n

\nSimptomul principal al defect\u0103rii a fost o avalan\u0219\u0103 de zeci de mii de conexiuni la baza de date, din cauza c\u0103reia instan\u021ba MySQL a devenit practic ineficient\u0103. Din acest motiv, a fost greu s\u0103 diagnostice problema. Am impus o restric\u021bie asupra num\u0103rului maxim de conexiuni din partea clien\u021bilor pentru a ajuta echipa SRE s\u0103 evalueze problema. Nu am observat trafic neobi\u0219nuit c\u0103tre baza de date: de fapt, majoritatea cererilor erau pentru citire, iar doar c\u00e2teva pentru scriere.<\/p>\n

Am \u00eencercat, de asemenea, s\u0103 identific\u0103m un model \u00een traficul bazei de date care ar putea provoca aceast\u0103 avalan\u0219\u0103. Cu toate acestea, nu am g\u0103sit nicio regularitate \u00een jurnalele de log. A\u0219tept\u00e2nd finalizarea noului cluster cu OSD 4.3.18, am continuat s\u0103 \u00eencerc\u0103m s\u0103 lans\u0103m pod-urile quay.io. De fiecare dat\u0103 c\u00e2nd clusterul ajungea la capacitate maxim\u0103, baza de date se bloca. Aceasta \u00eensemna c\u0103 era necesar s\u0103 repornim instan\u021ba RDS, pe l\u00e2ng\u0103 toate pod-urile quay.io.<\/p>\n

P\u00e2n\u0103 seara, am stabilizat serviciul \u00een modul de citire \u0219i am dezactivat maximum func\u021biilor nesemnificative (de exemplu, colectarea de\u0219eurilor \u00een spa\u021biul de nume) pentru a reduce \u00eenc\u0103rc\u0103tura pe baza de date. Blocajele s-au oprit, dar cauza nu a fost g\u0103sit\u0103<\/b>. Noul cluster OSD a fost gata \u0219i am mutat serviciul, am conectat traficul \u0219i am continuat monitorizarea.<\/p>\n

Quay.io a func\u021bionat stabil pe noul cluster OSD, a\u0219a c\u0103 ne-am \u00eentors la jurnalele bazei de date, dar nu am reu\u0219it s\u0103 descoperim o corela\u021bie care s\u0103 explice blocajele. Inginerii OpenShift au colaborat cu noi, \u00eencerc\u00e2nd s\u0103 \u00een\u021beleag\u0103 dac\u0103 modific\u0103rile din Red Hat OpenShift 4.3.19 ar fi putut cauz\u0103 problemelor cu Quay. Totu\u0219i, nu s-a descoperit nimic \u0219i problema nu a putut fi reproduc\u0103 \u00een condi\u021bii de laborator<\/b>.<\/p>\n

Al doilea e\u0219ec<\/h2>\n

\nPe 28 mai, pu\u021bin \u00eenainte de pr\u00e2nz EDT, quay.io a c\u0103zut din nou cu acelea\u0219i simptome: func\u021bionarea bazei de date era blocat\u0103. \u0218i din nou, ne-am concentrat toate for\u021bele pe investigare. \u00cen primul r\u00e2nd, trebuia s\u0103 restabilim func\u021bionarea serviciului. Totu\u0219i, de data aceasta, repornirea RDS \u0219i repornirea pod-urilor quay.io nu au avut niciun efect<\/b>Quay este scris \u00een Python, iar fiecare pod func\u021bioneaz\u0103 ca un singur container monolitic. \u00cen mediul de execu\u021bie al containerului, sunt executate simultan multe sarcini paralele. Folosim biblioteca<\/p>\n

gevent pentru a gestiona cererile web. C\u00e2nd Quay prime\u0219te o cerere (prin API-ul nostru, sau prin API-ul Docker), i se aloc\u0103 un worker gevent. De obicei, acest worker trebuie s\u0103 se conecteze la baza de date. Dup\u0103 primul e\u0219ec, am descoperit c\u0103 worker-ii gevent se conectau la baza de date, folosind set\u0103rile implicite.<\/code> sub gunicorn<\/code> pentru a gestiona cererile web. C\u00e2nd Quay prime\u0219te o cerere (prin API-ul nostru sau prin API-ul Docker), i se aloc\u0103 un worker gevent. De obicei, acest worker trebuie s\u0103 se conecteze la baza de date. Dup\u0103 prima e\u0219ec, am descoperit c\u0103 worker-urile gevent se conectau la baza de date folosind set\u0103rile implicite.<\/p>\n

Av\u00e2nd \u00een vedere num\u0103rul semnificativ de pod-uri Quay \u0219i miile de cereri primite pe secund\u0103, un num\u0103r mare de conexiuni la baza de date ar fi putut suprasolicita instan\u021ba MySQL. Monitorizarea a ar\u0103tat c\u0103 Quay gestioneaz\u0103 \u00een medie 5.000 de cereri pe secund\u0103. Aproape acela\u0219i num\u0103r era \u0219i al conexiunilor la baza de date. 5.000 de conexiuni se \u00eencadrau confortabil \u00een capacit\u0103\u021bile instan\u021bei noastre RDS (spre deosebire de zecile de mii). Dintr-un motiv oarecare, au avut loc cre\u0219teri nea\u0219teptate ale num\u0103rului de conexiuni<\/b>, \u00eens\u0103 nu am observat vreo corela\u021bie cu cererile de intrare.<\/p>\n

De data aceasta, am decis ferm s\u0103 g\u0103sim \u0219i s\u0103 elimin\u0103m sursa problemei, \u0219i nu s\u0103 ne limit\u0103m la o repornire. \u00cen codul surs\u0103 Quay au fost f\u0103cute modific\u0103ri care limiteaz\u0103 num\u0103rul de conexiuni la baza de date pentru fiecare worker<\/b> gevent. Acest num\u0103r a devenit un parametru \u00een configura\u021bie: a devenit posibil s\u0103-l schimb\u0103m \u201e\u00een mi\u0219care\u201d, f\u0103r\u0103 a construi o nou\u0103 imagine a containerului. Pentru a afla ce num\u0103r de conexiuni poate fi gestionat efectiv, au fost efectuate mai multe teste cu un mediu de staging, \u00een care s-au setat diferite valori pentru a observa cum afecteaz\u0103 aceste scenarii de testare a \u00eenc\u0103rc\u0103rii. \u00cen cele din urm\u0103, s-a descoperit c\u0103 Quay \u00eencepe s\u0103 returneze erori 502 c\u00e2nd num\u0103rul de conexiuni dep\u0103\u0219e\u0219te 10.000.<\/b><\/p>\n

Imediat am desf\u0103\u0219urat aceast\u0103 nou\u0103 versiune \u00een produc\u021bie \u0219i am \u00eenceput s\u0103 monitoriz\u0103m graficul conexiunilor la baza de date. \u00cen trecut, baza s-a blocat dup\u0103 aproximativ 20 de minute. Dup\u0103 30 de minute f\u0103r\u0103 probleme, am \u00eenceput s\u0103 avem speran\u021b\u0103, iar dup\u0103 o or\u0103 \u2014 \u00eencredere. Am restabilit traficul de scriere pe site \u0219i am \u00eenceput analiza postmortem.<\/p>\n

Reu\u0219ind s\u0103 evit\u0103m problema care cauzase blocarea, nu am reu\u0219it s\u0103 \u00eei afl\u0103m cauzele reale<\/b>. S-a confirmat c\u0103 aceasta nu este legat\u0103 de nicio modificare \u00een OpenShift 4.3.19, deoarece acela\u0219i lucru s-a \u00eent\u00e2mplat \u0219i pe versiunea 4.3.18, care anterior func\u021biona cu Quay f\u0103r\u0103 nicio problem\u0103.<\/p>\n

\u00cen cluster se ascundea evident ceva mai mult.<\/p>\n

O analiz\u0103 detaliat\u0103<\/h2>\n

\nQuay.io a folosit set\u0103rile implicite pentru conectarea la baza de date timp de \u0219ase ani, f\u0103r\u0103 nicio problem\u0103. Ce s-a schimbat? Este evident c\u0103, pe parcursul acestei perioade, traficul pe quay.io a crescut constant. \u00cen cazul nostru, p\u0103rea c\u0103 s-a atins un anumit prag, care a ac\u021bionat ca un declan\u0219ator pentru o avalan\u0219\u0103 de conexiuni. Am continuat s\u0103 analiz\u0103m jurnalele bazei de date dup\u0103 a doua c\u0103dere, dar nu am g\u0103sit nicio corela\u021bie sau rela\u021bie evident\u0103.<\/p>\n

\u00centre timp, echipa SRE s-a ocupat de \u00eembun\u0103t\u0103\u021birea observabilit\u0103\u021bii cererilor \u00een Quay \u0219i a s\u0103n\u0103t\u0103\u021bii generale a serviciului. Au fost desf\u0103\u0219urate noi metrici \u0219i tablouri de bord<\/b>, ar\u0103t\u00e2nd care p\u0103r\u021bi ale Quay sunt cele mai solicitate de clien\u021bi.<\/p>\n

Quay.io a func\u021bionat bine p\u00e2n\u0103 pe 9 iunie. \u00cen diminea\u021ba (ora EDT), am fost din nou martorii unei cre\u0219teri semnificative a num\u0103rului de conexiuni la baza de date. De data aceasta nu a avut loc nicio \u00eentrerupere<\/b>, deoarece o nou\u0103 setare limita num\u0103rul acestora \u0219i nu permitea dep\u0103\u0219irea capacit\u0103\u021bii de procesare MySQL. Totu\u0219i, timp de aproximativ o jum\u0103tate de or\u0103, mul\u021bi utilizatori au raportat o func\u021bionare lent\u0103 a quay.io. Am adunat rapid toate datele posibile, folosind instrumentele de monitorizare ad\u0103ugate. O corela\u021bie a ap\u0103rut brusc.<\/p>\n

\u00cenainte de saltul num\u0103rului de conexiuni, un num\u0103r mare de cereri a fost \u00eendreptat c\u0103tre API-ul App Registry<\/b>. App Registry este o func\u021bie pu\u021bin cunoscut\u0103 a quay.io. Aceasta permite stocarea unor produse, precum graficele Helm \u0219i containerele cu metadate bogate. Cei mai mul\u021bi utilizatori ai quay.io nu utilizeaz\u0103 aceast\u0103 func\u021bie; cu toate acestea, este folosit\u0103 activ de Red Hat OpenShift. OperatorHub din cadrul OpenShift stocheaz\u0103 to\u021bi operatorii \u00een App Registry. Ace\u0219ti operatori formeaz\u0103 baza pentru ecosistemul de sarcini de lucru OpenShift \u0219i modelul opera\u021bional (\u00een cadrul opera\u021biunilor \"zilei a doua\", Day 2) orientat c\u0103tre parteneri.<\/p>\n

Fiecare cluster OpenShift 4 utilizeaz\u0103 operatori din OperatorHub integrat pentru a publica catalogul operatorilor disponibili pentru instalare \u0219i pentru a oferi actualiz\u0103ri pentru cei deja instala\u021bi. Odat\u0103 cu cre\u0219terea popularit\u0103\u021bii OpenShift 4, num\u0103rul de clustere pe acesta a crescut, de asemenea, \u00een \u00eentreaga lume. Fiecare dintre aceste clustere \u00eencarc\u0103 con\u021binutul operatorilor pentru a lansa OperatorHub-ul integrat, folosind App Registry \u00een interiorul quay.io ca backend. C\u0103ut\u00e2nd sursa problemei, am trecut cu vederea faptul c\u0103, odat\u0103 cu cre\u0219terea treptat\u0103 a popularit\u0103\u021bii OpenShift, a crescut \u0219i \u00eenc\u0103rcarea pe una dintre func\u021biile rar utilizate quay.io.<\/b>.<\/p>\n

Am efectuat o analiz\u0103 a traficului cererilor App Registry \u0219i am examinat codul registrului. Au ie\u0219it imediat la iveal\u0103 deficien\u021be care f\u0103ceau ca cererile c\u0103tre baza de date s\u0103 fie formulate suboptim. La o \u00eenc\u0103rcare mic\u0103, acestea nu cauzau probleme, dar pe m\u0103sur\u0103 ce \u00eenc\u0103rcarea cre\u0219tea, deveneau surse de probleme. App Registry avea dou\u0103 endpoint-uri problematice care r\u0103spundeau prost la cre\u0219terea \u00eenc\u0103rc\u0103rii: primul returna o list\u0103 cu toate pachetele din depozit, iar al doilea \u2014 toate blob-urile pentru un pachet.<\/p>\n

Eliminarea cauzelor<\/h2>\n

\n\u00cen toat\u0103 s\u0103pt\u0103m\u00e2na urm\u0103toare, ne-am concentrat pe optimizarea codului App Registry \u0219i a mediului s\u0103u. Am rescris interog\u0103rile SQL evident ineficiente, am eliminat apelurile de comand\u0103 inutile, tar<\/code> (aceasta se activa la fiecare extragere de blob-uri), s-a ad\u0103ugat caching peste tot unde a fost posibil. Apoi, a fost realizat un test extins de performan\u021b\u0103 \u0219i s-a comparat viteza de func\u021bionare a App Registry \u00eenainte \u0219i dup\u0103 modific\u0103ri.<\/p>\n

Cererea API, care alt\u0103dat\u0103 dura p\u00e2n\u0103 la o jum\u0103tate de minut, acum se realizeaz\u0103 \u00een milisecunde.<\/b>. S\u0103pt\u0103m\u00e2na viitoare am implementat modific\u0103rile \u00een production, iar de atunci quay.io func\u021bioneaz\u0103 stabil. \u00cen aceast\u0103 perioad\u0103, au fost observate c\u00e2teva cre\u0219teri bruste ale traficului pe endpoint-ul App Registry, dar \u00eembun\u0103t\u0103\u021birile realizate au prevenit \u00eentreruperile \u00een baza de date.<\/p>\n

Ce am \u00eenv\u0103\u021bat?<\/h2>\n

\nEste clar c\u0103 orice serviciu \u00eencearc\u0103 s\u0103 evite timpii de nefunc\u021bionare. \u00cen cazul nostru, credem c\u0103 \u00eentreruperile recente au ajutat quay.io s\u0103 devin\u0103 mai bun. Am \u00eenv\u0103\u021bat c\u00e2teva lec\u021bii esen\u021biale pe care dorim s\u0103 le \u00eemp\u0103rt\u0103\u0219im:<\/p>\n

    \n
  1. Informa\u021biile despre cine \u0219i cum folose\u0219te serviciul t\u0103u nu sunt niciodat\u0103 de prisos.<\/b>Deoarece Quay \u201ea func\u021bionat pur \u0219i simplu\u201d, nu am avut niciodat\u0103 nevoie s\u0103 ne pierdem timpul cu optimizarea traficului \u0219i gestionarea \u00eenc\u0103rc\u0103rii. Toate acestea au creat o senza\u021bie fals\u0103 de siguran\u021b\u0103, c\u0103 serviciul poate scala nelimitat.<\/li>\n
  2. C\u00e2nd serviciul cade, restaurarea acestuia devine prioritatea principal\u0103.<\/b>. Deoarece Quay a continuat s\u0103 sufere de o baz\u0103 de date blocat\u0103 \u00een timpul primei defec\u021biuni, procedurile noastre standard nu au avut efectul scontat \u0219i nu am reu\u0219it s\u0103 restaur\u0103m serviciul cu ajutorul lor. Acest lucru a dus la o situa\u021bie \u00een care a fost necesar s\u0103 pierdem timp analizeaz\u0103 \u0219i colect\u00e2nd date \u00een speran\u021ba de a g\u0103si cauza principal\u0103 \u2014 \u00een loc s\u0103 ne concentr\u0103m toate eforturile pe restabilirea func\u021bionalit\u0103\u021bii.<\/li>\n
  3. Evalua\u021bi impactul fiec\u0103rei func\u021bii a serviciului<\/b>. Clien\u021bii au folosit rar App Registry, a\u0219a c\u0103 nu a fost o prioritate pentru echipa noastr\u0103. C\u00e2nd anumite func\u021bii ale produsului sunt aproape neutilizate, bug-urile lor \u00abapar\u00bb rar \u0219i dezvoltatorii \u00eenceteaz\u0103 s\u0103 urm\u0103reasc\u0103 codul. Este u\u0219or s\u0103 devii victima unei iluzii c\u0103 a\u0219a trebuie s\u0103 fie \u2014 p\u00e2n\u0103 c\u00e2nd, dintr-o dat\u0103, aceast\u0103 func\u021bie ajunge \u00een centrul unui incident major.<\/li>\n<\/ol>\n

    <\/p>\n

    Ce urmeaz\u0103?<\/h2>\n

    \nMunca pentru asigurarea stabilit\u0103\u021bii serviciului nu se opre\u0219te niciodat\u0103 \u0219i ne \u00eembun\u0103t\u0103\u021bim constant serviciul. Volumul de trafic pe quay.io continu\u0103 s\u0103 creasc\u0103 \u0219i suntem con\u0219tien\u021bi c\u0103 trebuie s\u0103 facem tot posibilul pentru a justifica \u00eencrederea clien\u021bilor. De aceea, lucr\u0103m \u00een prezent la urm\u0103toarele sarcini:<\/p>\n

      \n
    1. Implementarea replicilor de baze de date doar pentru citire, pentru a ajuta serviciul s\u0103 gestioneze traficul corespunz\u0103tor \u00een cazul \u00een care apar probleme cu instan\u021ba principal\u0103 RDS.<\/li>\n
    2. Actualizarea instan\u021bei RDS. Versiunea actual\u0103 \u00een sine nu este o problem\u0103. Mai degrab\u0103, dorim pur \u0219i simplu s\u0103 elimin\u0103m urma fals\u0103 (pe care am urm\u0103rit-o \u00een timpul defec\u021biunii); men\u021binerea software-ului la zi va elimina un alt factor \u00een cazul unor deconect\u0103ri viitoare.<\/li>\n
    3. Cache suplimentar \u00een \u00eentregul cluster. Continu\u0103m s\u0103 c\u0103ut\u0103m domenii \u00een care cache-ul poate reduce sarcina pe baza de date.<\/li>\n
    4. Ad\u0103ugarea unui firewall pentru aplica\u021bii web (WAF) pentru a vedea cine \u0219i de ce se conecteaz\u0103 la quay.io.<\/li>\n
    5. \u00cencep\u00e2nd cu urm\u0103toarea versiune, grupele Red Hat OpenShift vor renun\u021ba la App Registry \u00een favoarea catalogilor operatorilor (Operator Catalogs), bazate pe imagini de containere disponibile pe quay.io.<\/li>\n
    6. O \u00eenlocuire pe termen lung pentru App Registry ar putea fi suportul pentru specifica\u021biile artefactelor Open Container Initiative (OCI). Aceasta este \u00een prezent implementat\u0103 ca func\u021bionalitate nativ\u0103 Quay \u0219i va fi disponibil\u0103 pentru utilizatori atunci c\u00e2nd specifica\u021bia \u00een sine va fi finalizat\u0103.<\/li>\n<\/ol>\n

      \nToate cele de mai sus fac parte din investi\u021biile continue ale Red Hat \u00een quay.io, pe m\u0103sur\u0103 ce trecem de la o echip\u0103 mic\u0103 \u201e\u00een stil de startup\u201d la o platform\u0103 matur\u0103, gestionat\u0103 de SRE. \u0218tim c\u0103 mul\u021bi dintre clien\u021bii no\u0219tri depind de quay.io \u00een activit\u0103\u021bile lor zilnice (inclusiv Red Hat!) \u0219i ne str\u0103duim s\u0103 fim c\u00e2t mai transparen\u021bi cu privire la \u00eentreruperile recente \u0219i la eforturile continue de a ne \u00eembun\u0103t\u0103\u021bi.<\/p>\n

      P.S. de la traduc\u0103tor<\/h2>\n

      \nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n