Post Mortem in Quay.io indisponibilità

Nota. transl.: à principiu di aostu, Red Hat hà parlatu publicamente di risolve i prublemi di accessibilità chì l'utilizatori di u so serviziu avianu scontru in i mesi precedenti. Quay.io (hè basatu annantu à un registru per l'imaghjini di u containeru, chì a cumpagnia hà ricevutu cù a compra di CoreOS). Indipendentemente da u vostru interessu in stu serviziu cum'è tali, a strada chì l'ingegneri SRE di a cumpagnia hà pigliatu per diagnosticà è eliminà e cause di l'accidentu hè istruttiva.

U 19 di maghju, prima matina (Eastern Daylight Time, EDT), u serviziu di quay.io s'hè lampatu. L'accidentu hà affettatu i cunsumatori di quay.io è i prughjetti Open Source chì utilizanu quay.io cum'è una piattaforma per a custruzione è a distribuzione di software. Red Hat apprezza a fiducia di i dui.

Una squadra di ingegneri SRE s'hè implicatu immediatamente è hà pruvatu à stabilizzà u serviziu di Quay u più prestu pussibule. In ogni casu, mentre facianu questu, i clienti anu persu a capacità di spinghje novi imaghjini, è solu in ocasioni sò stati capaci di tirà quelli esistenti. Per qualchì mutivu scunnisciutu, a basa di dati quay.io hè stata bluccata dopu à scalà u serviziu à a piena capacità.

«Chì hà cambiatu?"- questa hè a prima quistione chì hè generalmente fatta in tali casi. Avemu nutatu chì pocu prima di u prublema, u cluster OpenShift Dedicated (chì corre quay.io) hà cuminciatu à aghjurnà à a versione 4.3.19. Siccomu quay.io funziona in Red Hat OpenShift Dedicated (OSD), l'aghjurnamenti regulari eranu di rutina è ùn anu mai causatu prublemi. Inoltre, in i sei mesi precedenti, avemu aghjurnatu i cluster Quay parechje volte senza alcuna interruzzione in u serviziu.

Mentre stavamu pruvendu à restaurà u serviziu, altri ingegneri cuminciaru à preparà un novu cluster OSD cù a versione precedente di u software, perchè se qualcosa succede, puderanu implementà tuttu nantu à questu.

Root Cause Analysis

U sintumu principalu di u fallimentu era una valanga di decine di millaie di cunnessione di basa di dati, chì rendeva l'istanza MySQL effettivamente inoperabile. Questu hà fattu difficiule di diagnosticà u prublema. Avemu stabilitu un limitu à u numeru massimu di cunnessione da i clienti per aiutà a squadra SRE à valutà u prublema. Ùn avemu micca nutatu un trafficu inusual à a basa di dati: in fattu, a maiò parte di e dumande sò state leghjite, è solu uni pochi sò stati scritti.

Avemu ancu pruvatu à identificà un mudellu in u trafficu di basa di dati chì puderia causà sta avalanche. In ogni casu, ùn pudemu truvà micca mudelli in i logs. Mentre aspittendu chì u novu cluster cù OSD 4.3.18 sia prontu, avemu cuntinuatu à pruvà à lancià pods quay.io. Ogni volta chì u cluster hà righjuntu a piena capacità, a basa di dati si congelava. Questu significava chì era necessariu di riavvià l'istanza RDS in più di tutti i pod di quay.io.

À a sera, stabilimu u serviziu in modu di sola lettura è disattivate quant'è più funzioni micca essenziali pussibule (per esempiu, a cullizzioni di spazzatura di namespace) per riduce a carica nantu à a basa di dati. I freezes anu cessatu ma u mutivu ùn hè mai statu trovu. U novu cluster OSD era prontu, è avemu migratu u serviziu, u trafficu cunnessu è u monitoraghju cuntinuatu.

Quay.io hà travagliatu in modu stabile nantu à u novu cluster OSD, cusì avemu vultatu à i logs di a basa di dati, ma ùn pudia truvà una correlazione chì spiegà i blocchi. L'ingegneri OpenShift anu travagliatu cun noi per capiscenu se i cambiamenti in Red Hat OpenShift 4.3.19 puderanu causari prublemi cù Quay. Tuttavia, nunda hè statu trovu, è Ùn era micca pussibule di ripruduce u prublema in cundizioni di laboratoriu.

Second fallimentu

U 28 di maghju, pocu prima di meziornu EDT, quay.io s'hè lampatu novu cù u listessu sintumu: a basa di dati hè stata bluccata. È di novu avemu lanciatu tutti i nostri sforzi in l'inchiesta. Prima di tuttu, era necessariu di restaurà u serviziu. Tuttavia sta volta, u reboot RDS è u reiniciu di quay.io pods ùn hà fattu nunda: un'altra valanga di cunnessione hà sbulicatu a basa. Ma perchè ?

Quay hè scrittu in Python è ogni pod opera cum'è un solu cuntainer monoliticu. U runtime di u container esegue parechje attività parallele simultaneamente. Avemu aduprà a biblioteca gevent sottu a gunicorn per trattà e dumande web. Quandu una dumanda vene in Quay (via a nostra propria API, o via l'API di Docker), hè assignatu un travagliadore gevent. Di genere, stu travagliadore deve cuntattà a basa di dati. Dopu à u primu fallimentu, avemu scupertu chì i travagliadori di Gevent eranu cunnessi à a basa di dati utilizendu paràmetri predeterminati.

Data u numeru significativu di pods di Quay è millaie di richieste entrate per seconda, un gran numaru di cunnessione di basa di dati puderia teoricamente sopra l'istanza MySQL. Grazie à u monitoraghju, era cunnisciutu chì Quay processa una media di 5 mila richieste per seconda. U numaru di cunnessione à a basa di dati era circa u listessu. 5 mila cunnessione eranu bè in e capacità di a nostra istanza RDS (chì ùn si pò dì circa decine di millaie). Per una certa ragione, ci sò stati spikes inespettati in u numeru di cunnessione, però, ùn avemu micca nutatu alcuna correlazione cù e richieste entrate.

Sta volta eramu decisu di truvà è eliminà a fonte di u prublema, è micca limità à un reboot. À a basa di codice Quay I cambiamenti sò stati fatti per limità u numeru di cunnessione à a basa di dati per ogni travagliadore ghjenti. Stu numeru hè diventatu un paràmetru in a cunfigurazione: hè diventatu pussibule di cambià nantu à a mosca senza custruisce una nova maghjina di cuntainer. Per sapè quante cunnessioni puderanu esse trattate realisticamente, avemu realizatu parechje teste in un ambiente di staging, stabilendu diversi valori per vede cumu questu affettarebbe i scenarii di prova di carica. In u risultatu, hè statu scupertu chì Quay cumencia à scaccià 502 errori quandu u numeru di cunnessione supera 10 mila.

Avemu immediatamente implementatu sta nova versione in a pruduzzione è hà cuminciatu à seguità u calendariu di cunnessione di a basa di dati. In u passatu, a basa hè stata chjusa dopu à circa 20 minuti. Dopu à 30 minuti senza prublemi avemu avutu a speranza, è una ora dopu avemu avutu cunfidenza. Avemu restauratu u trafficu à u situ è ​​cuminciamu l'analisi postmortem.

Dopu avè riisciutu à aggira u prublema chì porta à u bluccatu, ùn avemu micca scupertu i so mutivi veri. Hè stata cunfirmata chì ùn hè micca ligata à qualsiasi cambiamenti in OpenShift 4.3.19, postu chì a stessa cosa hè accaduta in a versione 4.3.18, chì prima hà travagliatu cù Quay senza prublemi.

Ci era chjaramente qualcosa d'altru chì stava in u cluster.

Studiu detallatu

Quay.io hà utilizatu i paràmetri predeterminati per cunnette à a basa di dati per sei anni senza prublemi. Chì cambiò? Hè chjaru chì tuttu stu trafficu di u tempu nantu à quay.io hè cresciutu constantemente. In u nostru casu, pareva cum'è s'ellu era statu righjuntu un valore di limitu, chì hà servitu com'è trigger per una avalanche di cunnessione. Avemu cuntinuatu à studià i logs di basa di dati dopu a seconda fallimentu, ma ùn truvamu micca mudelli o relazioni evidenti.

Intantu, a squadra SRE hà travagliatu nantu à migliurà a dumanda di osservabilità di Quay è a salute generale di u serviziu. Novi metrichi è dashboards sò stati implementati, chì mostra chì parte di u Quay sò più richieste da i clienti.

Quay.io hà travagliatu bè finu à u 9 di ghjugnu. Sta matina (EDT) avemu vistu novu un aumentu significativu in u numeru di cunnessione di basa di dati. Sta volta ùn ci era micca un downtime, Siccomu u novu paràmetru limitò u so numeru è ùn li permettenu micca di sopra à u throughput MySQL. Tuttavia, per una meza ora, parechji utilizatori anu nutatu un rendimentu lento di quay.io. Avemu cullucatu rapidamente tutte e dati pussibuli usendu l'arnesi di surviglianza aghjuntu. Di colpu un mudellu emerse.

Appena prima di l'aumentu di e cunnessione, un gran numaru di richieste sò state fatte à l'API di u Registru App. App Registry hè una funzione pocu cunnisciuta di quay.io. Permette di almacenà e cose cum'è i charts Helm è i cuntenituri cù metadati ricchi. A maiò parte di l'utilizatori di quay.io ùn anu micca travagliatu cù sta funzione, ma Red Hat OpenShift l'utiliza attivamente. OperatorHub cum'è parte di OpenShift almacena tutti l'operatori in u Registru di l'App. Questi operatori formanu a basa per l'ecosistema di carichi di travagliu OpenShift è u mudellu operativu centratu in i partenarii (operazioni Day 2).

Ogni cluster OpenShift 4 usa l'operatori da l'OperatorHub integratu per pubblicà un catalogu d'operatori dispunibili per a stallazione è furnisce l'aghjurnamenti à quelli chì sò digià stallati. Cù a pupularità crescente di OpenShift 4, u numeru di clusters nantu à questu in u mondu hà ancu aumentatu. Ognunu di sti clusters scarica u cuntenutu di l'operatore per eseguisce l'OperatorHub integratu, utilizendu u App Registru in quay.io cum'è backend. In a nostra ricerca di a fonte di u prublema, avemu missu u fattu chì OpenShift hà gradualmente crisciutu in pupularità, a carica nantu à una di e funzioni di quay.io raramente usate hà ancu aumentatu..

Avemu fattu un pocu di analisi di u trafficu di dumanda di u Registru di l'App è hà pigliatu un ochju à u codice di u registru. Immediatamente, i difetti sò stati revelati, per via di quale e dumande à a basa di dati ùn sò micca formate in modu ottimali. Quandu a carica era bassa, ùn anu micca causatu prublemi, ma quandu a carica aumentava, diventenu una fonte di prublemi. U Registru di l'App hà fattu avè dui punti finali problematici chì ùn anu micca rispostu bè à a carica crescente: u primu hà furnitu una lista di tutti i pacchetti in u repository, u sicondu hà restituutu tutti i blobs per u pacchettu.

Eliminazione di e cause

A settimana dopu avemu passatu ottimisà u codice di u Registru App stessu è u so ambiente. E dumande SQL chjaramente inefficaci sò state rielaborate è e chjama di cumandamenti inutili sò state eliminate tar (hè stata eseguita ogni volta chì i blobs sò stati recuperati), a caching hè stata aghjunta induve pussibule. Dopu avemu realizatu teste di prestazione estensiva è paragunate a velocità di u Registru App prima è dopu i cambiamenti.

E dumande API chì prima duravanu finu à a mità di minutu sò avà finite in millisecondi. A settimana dopu avemu implementatu i cambiamenti à a produzzione, è da tandu quay.io hà travagliatu stabile. Duranti stu tempu, ci sò stati parechji picchi forti in u trafficu nantu à l'App Registry endpoint, ma i migliuramenti fatti impediscenu l'interruzioni di a basa di dati.

Chì avemu amparatu ?

Hè chjaru chì ogni serviziu prova di evità i tempi di inattività. In u nostru casu, avemu cridutu chì i recenti outages anu aiutatu à fà quay.io megliu. Avemu amparatu uni pochi di lezioni chjave chì vulemu sparte:

1. Dati nantu à quale usa u vostru serviziu è cumu ùn hè mai superfluu. Perchè Quay "solu hà travagliatu", ùn avemu mai avutu à passà u tempu per ottimisà u trafficu è a gestione di a carica. Tuttu chistu hà creatu un falsu sensu di sicurità chì u serviziu puderia scala indefinitu.
2. Quandu u serviziu scende, ripiglià u funziunamentu hè una priorità maiò.. Perchè Quay hà cuntinuatu à soffre di una basa di dati chjusa durante a prima interrupzione, i nostri prucedure standard ùn anu micca avutu l'effettu previstu è ùn pudemu micca ristabilisce u serviziu cù elli. Questu hà purtatu à una situazione induve u tempu deve esse passatu per analizà è raccoglie dati in a speranza di truvà a causa radicale - invece di fucalizza tutti i sforzi per restaurà a funziunalità.
3. Evaluate l'impattu di ogni funzione di serviziu. I clienti raramente usavanu App Registry, cusì ùn era micca una priorità per a nostra squadra. Quandu alcune caratteristiche di u produttu sò appena aduprate, i so bug raramente appariscenu, è i sviluppatori cessanu di monitorà u codice. Hè facilitu per fallu preda à l'idea sbagliata chì questu hè u modu chì deve esse, finu à chì di colpu sta funzione si trova in u centru di un incidente maiò.

Chi c'è vicinu?

U travagliu per assicurà a stabilità di u serviziu ùn si ferma mai è l'avemu migliuratu constantemente. Siccomu i volumi di trafficu cuntinueghjanu à cresce in quay.io, ricunnoscemu chì avemu a rispunsabilità di fà tuttu ciò chì pudemu per esse à a fiducia di i nostri clienti. Dunque, simu attualmente travagliendu nantu à e seguenti attività:

1. Implementa repliche di basa di dati di sola lettura per aiutà u serviziu à gestisce u trafficu adattatu in casu di prublemi cù l'istanza RDS primaria.
2. Aghjurnà una istanza RDS. A versione attuale ùn hè micca u prublema. Piuttostu, vulemu simpricimenti caccià a falsa pista (chì avemu seguitu durante u fallimentu); Mantene u software aghjurnatu eliminerà un altru fattore in l'eventuali futuri outages.
3. Cache supplementu in tuttu u cluster. Cuntinuemu à circà i spazii induve caching pò riduce a carica nantu à a basa di dati.
4. Adding a web application firewall (WAF) per vede quale hè cunnessu à quay.io è perchè.
5. Partendu da a prossima versione, i clusters Red Hat OpenShift abbandunaranu u Registru di l'App in favore di i Cataloghi di l'Operatori basati nantu à l'imaghjini di u containeru dispunibili nantu à quay.io.
6. Un rimpiazzamentu à longu andà per App Registry puderia esse supportu per e specificazioni di l'artifactu Open Container Initiative (OCI). Hè attualmente implementatu cum'è funziunalità nativa di Quay è serà dispunibule per l'utilizatori quandu a specificazione stessa hè finalizzata.

Tuttu ciò chì sopra face parte di l'investimentu cuntinuu di Red Hat in quay.io mentre passemu da una piccula squadra "stile di startup" à una piattaforma matura guidata da SRE. Sapemu chì parechji di i nostri clienti s'appoghjanu à quay.io in u so travagliu di ogni ghjornu (cumpresu Red Hat!) È pruvemu à esse u più trasparenti pussibule annantu à l'interruzioni recenti è i sforzi in corso per migliurà.

PS da u traduttore

Leghjite puru nant'à u nostru blog:

• «Red Hat codice di registru open source per l'imaghjini di u containeru CoreOS - Quay";
• «Storie pratiche da a nostra vita di ogni ghjornu SRE. Parte 2";
• «Cumu e priorità di pod in Kubernetes anu causatu tempi di inattività in Grafana Labs».

Source: www.habr.com