{"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 sull'indisponibilit\u00e0 di Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota di traduzione.<\/b>: all'inizio di agosto Red Hat ha pubblicamente parlato della risoluzione dei problemi di disponibilit\u00e0 che erano emersi nei mesi precedenti per gli utenti del suo servizio Quay.io<\/a><\/noindex> (alla base vi \u00e8 un registro per le immagini dei container, ereditato dall'azienda con l'acquisto di CoreOS). Indipendentemente dal vostro interesse per questo servizio, il percorso intrapreso dagli ingegneri SRE dell'azienda per diagnosticare e risolvere le cause dell'incidente \u00e8 istruttivo.<\/i><\/p>\n

\"Post
\n
\nIl 19 maggio, presto al mattino (ora estiva dell'America del Nord, EDT), il servizio quay.io \u00e8 andato gi\u00f9. L'incidente ha colpito sia i consumatori di quay.io che i progetti Open Source che utilizzano quay.io come piattaforma per la costruzione e la distribuzione del software. Red Hat tiene molto alla fiducia di entrambi.<\/p>\n

Il team di ingegneri SRE ha subito iniziato a lavorare per stabilizzare il servizio Quay il prima possibile. Tuttavia, mentre stavano facendo ci\u00f2, i clienti hanno perso la possibilit\u00e0 di caricare nuove immagini e solo occasionalmente sono riusciti a scaricare quelle esistenti. Per qualche motivo sconosciuto, il database di quay.io si bloccava dopo la scalabilit\u00e0 del servizio a piena capacit\u00e0.<\/a><\/noindex><\/p>\n

\u00abCosa \u00e8 cambiato?<\/b>\u00bb \u2014 \u00e8 la prima domanda che si tende a porre in questi casi. Abbiamo notato che poco prima del problema, il cluster OpenShift Dedicated (su cui opera quay.io) ha iniziato ad aggiornarsi alla versione 4.3.19. Poich\u00e9 quay.io funziona su Red Hat OpenShift Dedicated (OSD), gli aggiornamenti regolari erano operazioni consuete e non avevano mai portato a problemi. Inoltre, negli ultimi sei mesi avevamo 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, per poter intervenire rapidamente in caso di necessit\u00e0.<\/p>\n

Analisi delle cause<\/h2>\n

\nIl principale sintomo del guasto era un'ondata di decine di migliaia di connessioni al database, che ha reso l'istanza MySQL praticamente non operativa. Di conseguenza, era difficile diagnosticare il problema. Abbiamo imposto un limite massimo sul numero di connessioni dai client, per aiutare il team SRE a valutare la questione. Non abbiamo notato alcun traffico insolito verso il database: in realt\u00e0, la maggior parte delle richieste erano di lettura, mentre solo poche erano di scrittura.<\/p>\n

Abbiamo anche cercato di identificare un modello nel traffico del database che potesse causare questa ondata. 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 piena capacit\u00e0, il database si bloccava. Questo significava che era necessario riavviare l'istanza RDS oltre a tutti i pod di quay.io.<\/p>\n

Entro sera, abbiamo stabilizzato il servizio in modalit\u00e0 di sola lettura e disattivato il massimo delle funzionalit\u00e0 non essenziali (ad esempio, la raccolta dei rifiuti nello spazio dei nomi), per ridurre il carico sul database. I blocchi si erano fermati, ma la causa non era stata ancora 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 sul nuovo cluster OSD, quindi siamo tornati ai log del database, ma non siamo riusciti a rilevare alcuna correlazione che spiegasse i blocchi. Gli ingegneri di OpenShift lavoravano 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, e non siamo riusciti a riprodurre il problema in laboratorio<\/b>.<\/p>\n

Il secondo guasto<\/h2>\n

\nil 28 maggio, poco prima di mezzogiorno EDT, quay.io \u00e8 crollato di nuovo con gli stessi sintomi: il funzionamento del database era bloccato. Ancora una volta abbiamo messo in campo tutte le nostre forze per l'inchiesta. Prima di tutto, era necessario ristabilire il servizio. Tuttavia, questa volta il riavvio di RDS e il riavvio dei pod di quay.io non hanno portato a nulla<\/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 singolo contenitore monolitico. In un ambiente di esecuzione del contenitore, vengono eseguite molte attivit\u00e0 parallele contemporaneamente. Utilizziamo la libreria gevent<\/code> a gunicorn<\/code> per gestire le richieste web. Quando Quay riceve una richiesta (tramite la nostra API o tramite l'API di Docker), viene assegnato un worker gevent. Di solito, questo worker deve connettersi al database. Dopo il primo fallimento, abbiamo scoperto che i worker gevent si collegavano al database utilizzando le impostazioni predefinite.<\/p>\n

Considerando il numero significativo di pod Quay e le migliaia di richieste in arrivo al secondo, il numero elevato di connessioni al database teoricamente poteva sovraccaricare l'istanza MySQL. Grazie al monitoraggio, sappiamo che Quay gestisce in media 5.000 richieste al secondo. Circa lo stesso numero erano le connessioni al database. 5.000 connessioni si adattavano facilmente alle capacit\u00e0 della nostra istanza RDS (cosa che non si pu\u00f2 dire per decine di migliaia). Per qualche motivo si verificavano picchi inaspettati nel numero di connessioni<\/b>, tuttavia non notavamo alcuna correlazione con le richieste in arrivo.<\/p>\n

Questa volta abbiamo deciso fermamente di trovare e risolvere la fonte del problema, anzich\u00e9 limitarci a riavviare. Nella base di codice di Quay sono state apportate modifiche per limitare il numero di connessioni al database per ciascun worker<\/b> gevent. Questo numero \u00e8 diventato un parametro nella configurazione: \u00e8 stato possibile modificarlo \"al volo\", senza ricompilare una nuova immagine del container. Per sapere quanti collegamenti potevano realmente essere gestiti, sono stati condotti diversi test con l'ambiente di staging, in cui venivano impostati valori diversi per osservare come ci\u00f2 influenzasse gli scenari di stress test. Alla fine, \u00e8 emerso che Quay inizia a restituire errori 502 quando il numero di connessioni supera i 10.000.<\/b><\/p>\n

Abbiamo immediatamente 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, avevamo speranza e dopo un'ora \u2014 certezza. Abbiamo ripristinato il traffico di scrittura sul sito e abbiamo iniziato l'analisi post-mortem.<\/p>\n

Siamo riusciti a eludere il problema che portava al blocco, ma non abbiamo identificato le sue vere cause<\/b>. \u00c8 stato confermato che non era correlato a cambiamenti in OpenShift 4.3.19, poich\u00e9 lo stesso era accaduto anche nella versione 4.3.18, che prima funzionava con Quay senza alcun problema.<\/p>\n

Nel cluster c'era chiaramente altro da scoprire.<\/p>\n

Un'analisi dettagliata<\/h2>\n

\nQuay.io ha utilizzato le impostazioni predefinite per la connessione al database per sei anni senza alcun problema. Cosa \u00e8 cambiato? \u00c8 chiaro che nel frattempo il traffico su quay.io \u00e8 costantemente aumentato. Nel nostro caso, sembrava che fosse stata raggiunta una certa soglia che ha attivato un'ondata di connessioni. Abbiamo continuato a esaminare i log del database dopo il secondo guasto, ma non abbiamo trovato alcun schema o connessione evidente.<\/p>\n

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

Quay.io ha funzionato normalmente fino al 9 giugno. Al mattino (in EDT) siamo stati ancora testimoni di un significativo aumento del numero di connessioni al database. Questa volta non ci sono stati downtime<\/b>, poich\u00e9 un nuovo parametro limitava il loro numero e impediva di superare la capacit\u00e0 di MySQL. Tuttavia, per circa mezz'ora molti utenti hanno riscontrato prestazioni lente su quay.io. Abbiamo rapidamente raccolto tutti i dati disponibili, sfruttando gli strumenti di monitoraggio aggiunti. Improvvisamente si \u00e8 manifestato uno schema.<\/p>\n

Prima del picco delle connessioni, un gran numero di richieste \u00e8 pervenuto all'App Registry API<\/b>. L'App Registry \u00e8 una funzione poco conosciuta di quay.io. Consente di memorizzare elementi come i chart Helm e i contenitori con metadati ricchi. La maggior parte degli utenti di quay.io non utilizza questa funzione, ma \u00e8 ampiamente utilizzata 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 workload di 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 dall'OperatorHub integrato per pubblicare un catalogo di operatori disponibili per l'installazione e 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 l'OperatorHub integrato, utilizzando l'App Registry all'interno di quay.io come backend. Nella ricerca della fonte del problema, abbiamo trascurato il fatto che, con la crescente popolarit\u00e0 di OpenShift, aumentava anche il carico su una delle funzioni raramente utilizzate di quay.io.<\/b>.<\/p>\n

Abbiamo condotto un'analisi del traffico delle richieste dell'App Registry e abbiamo esaminato il codice del registro. Sono subito emerse delle carenze che portavano a una formulazione non ottimale delle richieste al database. Con un carico ridotto, non causavano problemi, ma con l'aumento diventavano fonte di difficolt\u00e0. L'App Registry aveva due endpoint problematici che non rispondevano bene all'aumento del carico: il primo forniva un elenco di tutti i pacchetti nel repository, il secondo restituiva tutti i blob per un pacchetto.<\/p>\n

Rimozione delle cause<\/h2>\n

\nPer tutta la settimana successiva ci siamo dedicati all'ottimizzazione del codice stesso dell'App Registry e del suo ambiente. Sono state rielaborate richieste SQL visibilmente inefficienti, eliminate chiamate non necessarie al comando tar<\/code> (veniva avviata ad ogni estrazione dei blob), \u00e8 stata aggiunta la cache ovunque possibile. \u00c8 stato quindi eseguito un ampio test delle prestazioni e confrontata la velocit\u00e0 di App Registry prima e dopo le modifiche.<\/p>\n

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

Cosa abbiamo imparato?<\/h2>\n

\n\u00c8 chiaro che ogni servizio cerca di evitare i downtime. Nel nostro caso, crediamo che i recenti malfunzionamenti abbiano contribuito a rendere quay.io migliore. Abbiamo appreso alcune lezioni fondamentali di cui 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 spendere tempo per ottimizzare il traffico e gestire il carico. Tutto ci\u00f2 ha creato una falsa sensazione di sicurezza che il servizio potesse scalare all'infinito.<\/li>\n
  2. Quando un servizio si interrompe, il ripristino del suo funzionamento \u00e8 la massima priorit\u00e0.<\/b>. Poich\u00e9 Quay continuava a soffrire di un database bloccato durante il primo guasto, le nostre procedure standard non hanno avuto l'effetto previsto e non siamo riusciti a ripristinare il servizio con il loro aiuto. Questo ha portato a una situazione in cui \u00e8 stato necessario perdere tempo ad analizzare e raccogliere dati nella speranza di trovare la causa principale, piuttosto che concentrare tutti gli sforzi sul ripristino della funzionalit\u00e0.<\/li>\n
  3. Valuta l'impatto di ciascuna delle funzioni del servizio<\/b>. I clienti raramente utilizzavano App Registry, quindi non era una priorit\u00e0 per il nostro team. Quando alcune funzioni del prodotto vengono utilizzate poco, i loro bug ''emergono'' raramente e gli sviluppatori smettono di seguire il codice. \u00c8 facile cadere nell'illusione che sia normale \u2014 finch\u00e9 improvvisamente quella funzione non si ritrova al centro di un incidente su larga scala.<\/li>\n<\/ol>\n

    <\/p>\n

    Cosa succede dopo?<\/h2>\n

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

      \n
    1. Distribuzione di repliche di database solo per la lettura, per aiutare il servizio a gestire il traffico adeguato in caso di problemi con l'istanza principale di RDS.<\/li>\n
    2. Aggiornamento dell'istanza di RDS. L'attuale versione di per s\u00e9 non \u00e8 problematica. Piuttosto, vogliamo semplicemente eliminare una falsa pista (seguita durante il guasto); mantenere il software aggiornato aiuter\u00e0 a rimuovere un ulteriore fattore in caso di futuri downtime.<\/li>\n
    3. Caching aggiuntivo in tutto il cluster. Continuiamo a cercare aree in cui il caching possa contribuire a ridurre il carico sul database.<\/li>\n
    4. Aggiunta di un firewall per applicazioni web (WAF), per vedere chi si connette a quay.io e perch\u00e9.<\/li>\n
    5. A partire dalla prossima versione, i cluster Red Hat OpenShift abbandoneranno App Registry a favore dei cataloghi degli operatori (Operator Catalogs), basati su immagini dei container disponibili su quay.io.<\/li>\n
    6. Una sostituzione a lungo termine di App Registry potrebbe essere il supporto per le specifiche degli artefatti dell'Open Container Initiative (OCI). Attualmente \u00e8 implementato come funzionalit\u00e0 nativa di Quay e sar\u00e0 disponibile per gli utenti quando la specifica sar\u00e0 definitivamente concordata.<\/li>\n<\/ol>\n

      \nTutto quanto sopra fa parte degli investimenti continui 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 si affidano a quay.io nel loro lavoro quotidiano (compresa Red Hat!) e ci impegniamo a essere il pi\u00f9 trasparenti possibile riguardo ai recenti interventi e agli sforzi continui per migliorarci.<\/p>\n

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

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