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

Nota del traduttore.<\/b>: all'inizio di agosto, Red Hat ha pubblicamente affrontato le problematiche di disponibilit\u00e0 emerse nei mesi precedenti per gli utenti del suo servizio Quay.io<\/a><\/noindex> (alla base vi \u00e8 un registro per le immagini dei container, acquisito dall\u2019azienda con l'acquisto di CoreOS). Indipendentemente dall'interesse per questo servizio in particolare, \u00e8 interessante il percorso che gli ingegneri SRE dell'azienda hanno seguito per diagnosticare e risolvere le cause dell'incidente.<\/i><\/p>\n

\"Post
\n
\nIl 19 maggio, nella prima mattinata (secondo l'ora estiva del fuso orario orientale nordamericano, EDT), il servizio quay.io \u00e8 andato in crash. L'incidente ha interessato sia i consumatori di quay.io che i progetti Open Source che utilizzano quay.io come piattaforma per la costruzione e distribuzione del software. Red Hat tiene in alta considerazione la fiducia di entrambi.<\/p>\n

Il team di ingegneri SRE \u00e8 entrato subito in azione cercando di stabilizzare il servizio Quay il pi\u00f9 rapidamente possibile. Tuttavia, mentre erano impegnati in questo lavoro, i clienti hanno perso la possibilit\u00e0 di pushare nuove immagini, riuscendo a pullare solo occasionalmente quelle esistenti. Per motivi sconosciuti, il database di quay.io si bloccava dopo che il servizio era stato scalato a piena capacit\u00e0.<\/a><\/noindex><\/p>\n

\u00abCosa \u00e8 cambiato?<\/b>\u00bb \u2014 \u00e8 la prima domanda che ci si pone in questi casi. Abbiamo notato che poco prima del problema, il cluster OpenShift Dedicated (su cui opera quay.io) \u00e8 iniziato ad essere aggiornato alla versione 4.3.19. Poich\u00e9 quay.io funziona su Red Hat OpenShift Dedicated (OSD), gli aggiornamenti regolari erano un'operazione routinaria e non avevano mai portato a problemi. Inoltre, nei sei mesi precedenti, abbiamo aggiornato pi\u00f9 volte i cluster Quay senza alcuna interruzione del servizio.<\/p>\n

Mentre cercavamo di ripristinare il servizio, altri ingegneri hanno iniziato a preparare un nuovo cluster OSD con la versione precedente del software, in modo da poterlo attivare in caso di necessit\u00e0.<\/p>\n

Analisi delle cause principali<\/h2>\n

\nIl principale sintomo del guasto era un'onda di decine di migliaia di connessioni al database, che ha reso l'istanza MySQL praticamente inutilizzabile. Questo ha reso difficile diagnosticare il problema. Abbiamo impostato un limite sul numero massimo di connessioni da parte dei clienti per aiutare il team SRE a valutare la situazione. Non abbiamo notato alcun traffico anomalo verso il database: in realt\u00e0, la maggior parte delle richieste erano per la lettura, e solo poche per la scrittura.<\/p>\n

Abbiamo anche cercato di identificare un modello nel traffico del database che potesse aver causato questa valanga. Tuttavia, non siamo riusciti a trovare alcuna regolarit\u00e0 nei log. In attesa della disponibilit\u00e0 del nuovo cluster con OSD 4.3.18, abbiamo continuato a tentare di avviare i pod di quay.io. Ogni volta che il cluster raggiungeva la massima capacit\u00e0, il database si bloccava. Ci\u00f2 significava che era necessario riavviare l'istanza RDS oltre a tutti i pod di quay.io.<\/p>\n

Entro la sera, abbiamo stabilizzato il servizio in modalit\u00e0 di sola lettura e disattivato il massimo numero di funzionalit\u00e0 non essenziali (ad esempio, la raccolta dei rifiuti nello spazio dei nomi) per ridurre il carico sul database. I blocchi si sono fermati, ma la causa non \u00e8 stata trovata<\/b>. Il nuovo cluster OSD era pronto, e abbiamo trasferito il servizio, collegato il traffico e continuato il monitoraggio.<\/p>\n

Quay.io funzionava stabilmente nel nuovo cluster OSD, quindi siamo tornati ai log del database, ma non siamo riusciti a trovare alcuna correlazione che spiegasse i blocchi. Gli ingegneri di OpenShift hanno lavorato insieme a noi, cercando di capire se le modifiche in Red Hat OpenShift 4.3.19 potessero aver causato problemi con Quay. Tuttavia, non \u00e8 emerso nulla. Non siamo riusciti a replicare il problema in laboratorio.<\/b>.<\/p>\n

Secondo guasto<\/h2>\n

\nIl 28 maggio, poco prima di mezzogiorno EDT, quay.io \u00e8 di nuovo andato in crash con gli stessi sintomi: il funzionamento del database veniva bloccato. E di nuovo, abbiamo messo in campo tutte le forze per indagare. Prima di tutto, era necessario ripristinare il servizio. Tuttavia questa volta il riavvio di RDS e il riavvio dei pod di quay.io non hanno dato risultati.<\/b>: un'altra valanga di connessioni ha travolto il database. Ma perch\u00e9?<\/p>\n

Quay \u00e8 scritto in Python, e ogni pod funziona come un unico container monolitico. Nell'ambiente di esecuzione del container vengono eseguite simultaneamente molte attivit\u00e0 parallele. Utilizziamo la libreria gevent<\/code> sotto gunicorn<\/code> per gestire le richieste web. Quando Quay riceve una richiesta (tramite la nostra API o tramite l'API di Docker), gli viene assegnato un worker gevent. Di solito, questo worker deve connettersi al database. Dopo il primo guasto, abbiamo scoperto che i worker gevent si connettevano al database utilizzando le impostazioni predefinite.<\/p>\n

Considerando il numero significativo di pod di Quay e le migliaia di richieste al secondo, un alto numero di connessioni al database potrebbe teoricamente sovraccaricare l'istanza MySQL. Dal monitoraggio, sapevamo che Quay gestisce in media 5.000 richieste al secondo. Il numero di connessioni al database era approssimativamente lo stesso. 5.000 connessioni rientravano nelle capacit\u00e0 della nostra istanza RDS (cosa che non si pu\u00f2 dire per decine di migliaia). Per qualche motivo si verificavano picchi imprevisti nel numero di connessioni<\/b>, tuttavia non notavamo alcuna correlazione con le richieste in arrivo.<\/p>\n

Questa volta eravamo decisi a trovare e risolvere la causa del problema, e non a limitarci a un riavvio. Sono state apportate modifiche al codice sorgente di Quay per limitare il numero di connessioni al DB per ogni worker.<\/b> gevent. Questo numero \u00e8 diventato un parametro nella configurazione: ora \u00e8 possibile modificarlo \u00abal volo\u00bb, senza dover ricompilare una nuova immagine del container. Per determinare quanti collegamenti possono essere gestiti realmente, sono stati eseguiti diversi test nell'ambiente di staging, in cui sono stati impostati valori diversi per vedere come ci\u00f2 influisse sugli scenari di test di carico. Alla fine \u00e8 emerso che Quay inizia a restituire errori 502 quando il numero di collegamenti supera i 10.000.<\/b><\/p>\n

Abbiamo subito distribuito questa nuova versione in produzione e abbiamo iniziato a monitorare il grafico delle connessioni al database. In passato, il database si bloccava dopo circa 20 minuti. Dopo 30 minuti senza problemi, abbiamo iniziato a sperare, e dopo un'ora abbiamo acquisito sicurezza. Abbiamo ripristinato il traffico in scrittura sul sito e abbiamo iniziato l'analisi postmortem.<\/p>\n

Essendo riusciti a aggirare il problema che causava il blocco, non abbiamo scoperto le sue vere cause<\/b>. \u00c8 stato confermato che non era correlata a modifiche nella versione OpenShift 4.3.19, poich\u00e9 lo stesso \u00e8 accaduto anche nella versione 4.3.18, che prima funzionava con Quay senza problemi.<\/p>\n

Nel cluster si nascondeva chiaramente qualcos'altro.<\/p>\n

Un'indagine dettagliata<\/h2>\n

\nQuay.io ha utilizzato per sei anni le impostazioni predefinite per la connessione al database senza alcun problema. Cosa \u00e8 cambiato? \u00c8 evidente che, per tutto questo tempo, il traffico su quay.io \u00e8 cresciuto incessantemente. Nel nostro caso, sembrava che si fosse raggiunto una sorta di soglia, che ha attivato un effetto valanga di connessioni. Abbiamo continuato a esaminare i log del database dopo il secondo crash, ma non abbiamo trovato alcuna coerenza o legami evidenti.<\/p>\n

Nel frattempo, il team SRE si stava occupando di miglioramenti nella visibilit\u00e0 delle richieste in Quay e nella salute generale del servizio. Sono state implementate nuove metriche e dashboard<\/b>, che mostrano quali parti di Quay sono pi\u00f9 richieste dai clienti.<\/p>\n

Quay.io ha funzionato normalmente fino al 9 giugno. La mattina (ora EDT) abbiamo assistito ancora a un significativo aumento del numero di connessioni al database. Questa volta non ci sono stati tempi di inattivit\u00e0.<\/b>, poich\u00e9 il nuovo parametro limitava il numero e non permetteva di superare la larghezza di banda di MySQL. Tuttavia, per circa mezz'ora molti utenti hanno segnalato un lento funzionamento di quay.io. Abbiamo rapidamente raccolto tutti i dati possibili utilizzando gli strumenti di monitoraggio aggiunti. \u00c8 emerso un modello inaspettato.<\/p>\n

Poco prima del balzo nel numero delle connessioni, un gran numero di richieste \u00e8 arrivato all'API App Registry<\/b>. L'App Registry \u00e8 una funzione poco conosciuta di quay.io. Consente di memorizzare cose come grafici Helm e contenitori con metadati ricchi. La maggior parte degli utenti di quay.io non utilizza questa funzione, ma \u00e8 ampiamente sfruttata da Red Hat OpenShift. OperatorHub all'interno di OpenShift memorizza tutti gli operatori nell'App Registry. Questi operatori costituiscono la base per l'ecosistema delle applicazioni OpenShift e il modello operativo (nell'ambito delle operazioni del 'secondo giorno', Day 2) orientato ai partner.<\/p>\n

Ogni cluster OpenShift 4 utilizza operatori dal built-in OperatorHub per pubblicare il catalogo degli operatori disponibili per l'installazione e per fornire aggiornamenti per quelli gi\u00e0 installati. Con la crescente popolarit\u00e0 di OpenShift 4, \u00e8 aumentato anche il numero di cluster in tutto il mondo. Ognuno di questi cluster carica il contenuto degli operatori per avviare il built-in OperatorHub utilizzando l'App Registry all'interno di quay.io come backend. Nella ricerca della fonte del problema, abbiamo trascurato il fatto che, con l'aumento graduale della popolarit\u00e0 di OpenShift, aumentava anche il carico su una delle funzionalit\u00e0 raramente utilizzate di quay.io.<\/b>.<\/p>\n

Abbiamo condotto un'analisi del traffico delle richieste all'App Registry e abbiamo esaminato il codice del registry. Sono emersi subito dei problemi che causavano la formazione non ottimale delle richieste al database. Con un carico basso non erano un problema, tuttavia, con l'aumento del carico, diventavano fonte di problemi. L'App Registry ha rivelato due endpoint problematici, che rispondevano male all'aumento del carico: il primo restituiva un elenco di tutti i pacchetti nel repository, il secondo restituiva tutti i blob per un pacchetto.<\/p>\n

Risoluzione delle cause<\/h2>\n

\nPer tutta la settimana scorsa ci siamo concentrati sull'ottimizzazione del codice dell'App Registry e del suo ambiente. Sono state riscritte chiaramente le query SQL inefficaci e sono stati eliminati i chiamate superflue al comando tar<\/code> (che veniva eseguito ad ogni estrazione dei blob), \u00e8 stata aggiunta la cache ovunque fosse possibile. Successivamente, \u00e8 stato condotto un ampio test delle prestazioni e la velocit\u00e0 di funzionamento dell'App Registry \u00e8 stata confrontata prima e dopo le modifiche.<\/p>\n

Le richieste API, che prima richiedevano fino a trenta secondi, ora vengono eseguite in millisecondi<\/b>. La settimana successiva abbiamo implementato le modifiche in produzione, e da allora quay.io funziona in modo stabile. Durante questo periodo ci sono stati alcuni picchi di traffico sul endpoint dell'App Registry, ma i miglioramenti apportati hanno evitato interruzioni nel funzionamento del database.<\/p>\n

Cosa abbiamo imparato?<\/h2>\n

\n\u00c8 chiaro che ogni servizio cerca di evitare tempi di inattivit\u00e0. Nel nostro caso, crediamo che i recenti problemi abbiano aiutato a rendere quay.io migliore. Per noi, abbiamo tratto alcune lezioni fondamentali che vogliamo condividere:<\/p>\n

    \n
  1. I dati su chi e come utilizza il tuo servizio non sono mai superflui.<\/b>. Poich\u00e9 Quay \"funzionava semplicemente\", non abbiamo mai sentito la necessit\u00e0 di dedicare tempo all'ottimizzazione del traffico e alla gestione del carico. Tutto ci\u00f2 ha creato un falso senso di sicurezza, facendo credere che il servizio potesse scalare all'infinito.<\/li>\n
  2. Quando il servizio va in down, il ripristino del suo funzionamento \u00e8 la massima priorit\u00e0<\/b>. Poich\u00e9 Quay ha continuato a soffrire di una base di dati bloccata durante il primo guasto, le nostre procedure standard non hanno avuto l'effetto desiderato e non siamo riusciti a ripristinare il servizio con esse. Questo ha portato a una situazione in cui \u00e8 stato necessario spendere tempo ad analizzare e raccogliere dati nella speranza di trovare la causa principale, invece di concentrare tutti gli sforzi sul ripristino della funzionalit\u00e0.<\/li>\n
  3. Valuta l'impatto di ciascuna delle funzionalit\u00e0 del servizio<\/b>. I clienti utilizzavano raramente App Registry, quindi non era una priorit\u00e0 per il nostro team. Quando alcune funzioni del prodotto vengono utilizzate poco, i loro bug \u00abemergono\u00bb raramente e gli sviluppatori smettono di monitorare il codice. \u00c8 facile cadere nell'illusione che sia normale \u2014 fino a quando all'improvviso quella funzione non finisce al centro di un grande incidente.<\/li>\n<\/ol>\n

    <\/p>\n

    E ora?<\/h2>\n

    \nIl lavoro per garantire la stabilit\u00e0 del servizio non si ferma mai e continuiamo a migliorarlo costantemente. I volumi di traffico su quay.io continuano a crescere e abbiamo la consapevolezza di dover fare tutto il possibile per meritare la fiducia dei clienti. Pertanto, attualmente stiamo lavorando sui seguenti obiettivi:<\/p>\n

      \n
    1. Distribuzione di repliche di database in sola lettura per aiutare il servizio a gestire il traffico corrispondente in caso di problemi con l'istanza principale di RDS.<\/li>\n
    2. Aggiornamento dell'istanza di RDS. L'attuale versione non presenta di per s\u00e9 problemi. Piuttosto, vogliamo semplicemente eliminare un falso indizio (su cui ci siamo orientati durante il guasto); mantenere il software aggiornato eliminer\u00e0 un altro fattore in caso di futuri blackout.<\/li>\n
    3. Caching aggiuntivo su tutto il cluster. Continuiamo a cercare aree in cui il caching pu\u00f2 ridurre il carico sul database.<\/li>\n
    4. Aggiunta di un firewall per applicazioni web (WAF), per vedere chi e perch\u00e9 si connette a quay.io.<\/li>\n
    5. A partire dal prossimo rilascio, i cluster Red Hat OpenShift abbandoneranno l'App Registry in favore dei cataloghi degli operatori (Operator Catalogs), basati su immagini di container disponibili su quay.io.<\/li>\n
    6. Una sostituzione a lungo termine dell'App Registry potrebbe essere il supporto delle specifiche degli artefatti Open Container Initiative (OCI). Attualmente \u00e8 implementato come funzionalit\u00e0 nativa di Quay e sar\u00e0 disponibile per gli utenti una volta finalizzate le specifiche.<\/li>\n<\/ol>\n

      \nTutto quanto sopra fa parte degli investimenti in corso di Red Hat in quay.io mentre passiamo da un piccolo team \"in stile startup\" a una piattaforma matura gestita da SRE. Sappiamo che molti dei nostri clienti fanno affidamento su quay.io nel loro lavoro quotidiano (incluso Red Hat!) e ci impegniamo a essere il pi\u00f9 trasparenti possibile riguardo ai recenti problemi e agli sforzi in corso per migliorare.<\/p>\n

      P.S. dal traduttore<\/h2>\n

      \nLeggete anche nel nostro blog:<\/p>\n