Artem Denisov ( , )
Badoo è il sito di incontri più grande del mondo. Attualmente abbiamo circa 330 milioni di utenti registrati in tutto il mondo. Ma ciò che è molto più importante nel contesto della nostra conversazione di oggi è che memorizziamo circa 3 petabyte di foto degli utenti. Ogni giorno i nostri utenti caricano circa 3,5 milioni di nuove foto e il carico di lettura è di circa 80mila richieste al secondo. Questo è parecchio per il nostro backend e talvolta ci sono difficoltà con questo.
Parlerò del design di questo sistema, che memorizza e invia foto in generale, e lo guarderò dal punto di vista di uno sviluppatore. Ci sarà una breve retrospettiva su come si è sviluppato, in cui delineerò le tappe principali, ma parlerò solo più in dettaglio delle soluzioni che stiamo attualmente utilizzando.
Ora cominciamo.
Come ho detto, questa sarà una retrospettiva e, per iniziare da qualche parte, prendiamo l'esempio più comune.
Abbiamo un compito comune, dobbiamo accettare, archiviare e inviare le foto degli utenti. In questa forma, il compito è generale, possiamo usare qualsiasi cosa:
- archiviazione cloud moderna,
- una soluzione in scatola, di cui ce ne sono molte anche adesso;
- Possiamo installare diverse macchine nel nostro data center e inserirvi dischi rigidi di grandi dimensioni e archiviarvi le foto.
Badoo storicamente - sia adesso che allora (all'epoca in cui era appena agli inizi) - vive sui propri server, all'interno dei nostri DC. Pertanto, questa opzione è stata ottimale per noi.
Abbiamo semplicemente preso diverse macchine, le abbiamo chiamate "foto" e abbiamo ottenuto un cluster che memorizza le foto. Ma sembra che manchi qualcosa. Affinché tutto ciò funzioni, dobbiamo in qualche modo determinare su quale macchina memorizzeremo quali foto. E anche qui non c’è bisogno di aprire l’America.
Aggiungiamo alcuni campi al nostro archivio con informazioni sugli utenti. Questa sarà la chiave di sharding. Nel nostro caso, l'abbiamo chiamato place_id e questo ID luogo punta al luogo in cui sono archiviate le foto degli utenti. Realizziamo mappe.
Nella prima fase, questo può essere fatto anche manualmente: diciamo che la foto di questo utente con un posto simile verrà inviata a un server del genere. Grazie a questa mappa sappiamo sempre quando un utente carica una foto, dove salvarla e sappiamo da dove regalarla.
Questo è uno schema assolutamente banale, ma presenta vantaggi piuttosto significativi. Il primo è che è semplice, come ho detto, e il secondo è che con questo approccio possiamo facilmente scalare orizzontalmente semplicemente consegnando nuove auto e aggiungendole alla mappa. Non è necessario fare nient'altro.
Per noi è stato così per qualche tempo.
Questo era intorno al 2009. Hanno consegnato auto, hanno consegnato...
E ad un certo punto abbiamo iniziato a notare che questo schema presenta alcuni svantaggi. Quali sono gli svantaggi?
Innanzitutto la capacità è limitata. Non possiamo stipare tanti dischi rigidi su un server fisico quanto vorremmo. E questo è diventato un certo problema nel tempo e con la crescita del dataset.
E secondo. Questa è una configurazione atipica di macchine, poiché tali macchine sono difficili da riutilizzare in altri cluster; sono piuttosto specifiche, ad es. dovrebbero essere deboli in termini di prestazioni, ma allo stesso tempo con un disco rigido di grandi dimensioni.
Tutto questo riguardava il 2009, ma, in linea di principio, questi requisiti sono ancora attuali. Abbiamo una retrospettiva, quindi nel 2009 tutto andava completamente male.
E l'ultimo punto è il prezzo.
Il prezzo a quel tempo era molto alto e dovevamo cercare delle alternative. Quelli. avevamo bisogno di utilizzare in qualche modo meglio sia lo spazio nei data center che i server fisici su cui si trova tutto questo. E i nostri ingegneri di sistema hanno avviato un ampio studio in cui hanno esaminato una serie di opzioni diverse. Hanno anche esaminato i file system in cluster come PolyCeph e Lustre. Si sono verificati problemi di prestazioni e operazioni piuttosto difficili. Hanno rifiutato. Abbiamo provato a montare l'intero set di dati tramite NFS su ciascuna vettura per ingrandirlo in qualche modo. Anche la lettura è andata male, abbiamo provato diverse soluzioni di diversi fornitori.
Alla fine abbiamo deciso di utilizzare la cosiddetta Storage Area Network.
Si tratta di SHD di grandi dimensioni progettati specificamente per archiviare grandi quantità di dati. Sono scaffali con dischi montati sulle macchine finali di uscita ottica. Quello. abbiamo una sorta di pool di macchine, piuttosto piccolo, e questi SHD, che sono trasparenti per la nostra logica di invio, ad es. affinché il nostro nginx o chiunque altro possa soddisfare le richieste per queste foto.
Questa decisione presentava evidenti vantaggi. Questo è SHD. Ha lo scopo di archiviare foto. Ciò risulta più economico rispetto al semplice equipaggiamento delle macchine con dischi rigidi.
Secondo vantaggio.
Questo è che la capacità è diventata molto più grande, ad es. possiamo ospitare molto più spazio di archiviazione in un volume molto più piccolo.
Ma ci sono stati anche degli svantaggi che sono emersi abbastanza rapidamente. Con l'aumento del numero di utenti e del carico su questo sistema, iniziarono a sorgere problemi di prestazioni. E il problema qui è abbastanza ovvio: qualsiasi SHD progettato per archiviare molte foto in un piccolo volume, di norma, soffre di una lettura intensiva. Questo è in realtà vero per qualsiasi spazio di archiviazione cloud o qualsiasi altra cosa. Ora non abbiamo uno spazio di archiviazione ideale che sia infinitamente scalabile, potresti inserirci qualsiasi cosa e tollererebbe molto bene le letture. Letture soprattutto casuali.
Come nel caso delle nostre foto, perché le foto vengono richieste in modo incoerente e questo influirà notevolmente sulla loro resa.
Anche secondo le cifre odierne, se otteniamo più di 500 RPS per le foto su una macchina a cui è collegato lo spazio di archiviazione, iniziano già i problemi. E per noi è stato già abbastanza brutto, perché il numero di utenti sta crescendo e le cose non potranno che peggiorare. Questo deve essere ottimizzato in qualche modo.
Per ottimizzare, in quel momento abbiamo deciso, ovviamente, di guardare il profilo di carico: cosa sta succedendo in generale, cosa deve essere ottimizzato.
E qui tutto gioca nelle nostre mani.
L'ho già detto nella prima slide: abbiamo 80mila richieste di lettura al secondo con solo 3,5 milioni di caricamenti al giorno. Cioè, questa è una differenza di tre ordini di grandezza. È ovvio che la lettura va ottimizzata ed è praticamente chiaro come.
C'è un altro piccolo punto. Le specifiche del servizio sono tali che una persona si registra, carica una foto, quindi inizia a guardare attivamente altre persone, come loro, e viene mostrata attivamente ad altre persone. Poi trova o non trova un compagno, dipende da come va a finire, e smette di usare il servizio per un po’. In questo momento, quando lo usa, le sue foto sono molto calde: sono richieste, molte persone le vedono. Non appena smette di farlo, abbastanza rapidamente perde la stessa esposizione ad altre persone che aveva prima, e le sue foto non vengono quasi mai richieste.
Quelli. Abbiamo un set di dati molto piccolo. Ma allo stesso tempo le richieste per lui sono tantissime. E una soluzione del tutto ovvia qui è aggiungere una cache.
Una cache con LRU risolverà tutti i nostri problemi. Che cosa stiamo facendo?
Ne aggiungiamo un altro relativamente piccolo davanti al nostro grande cluster con spazio di archiviazione, chiamato photocache. Questo è essenzialmente solo un proxy di memorizzazione nella cache.
Come funziona dall'interno? Ecco il nostro utente, ecco lo spazio di archiviazione. Tutto è come prima. Cosa aggiungiamo in mezzo?
È semplicemente una macchina con un disco locale fisico, che è veloce. Questo è, ad esempio, con un SSD. E su questo disco è archiviata una sorta di cache locale.
Che cosa sembra? L'utente invia una richiesta per una foto. NGINX lo cerca prima nella cache locale. In caso contrario, semplicemente proxy_pass nel nostro archivio, scarica la foto da lì e consegnala all'utente.
Ma questo è molto banale e non è chiaro cosa stia succedendo all'interno. Funziona più o meno così.
La cache è logicamente divisa in tre livelli. Quando dico “tre strati”, ciò non significa che esista una sorta di sistema complesso. No, queste sono condizionatamente solo tre directory nel file system:
- Questo è un buffer in cui vanno le foto appena scaricate da un proxy.
- Questa è una hot cache che memorizza le foto attualmente richieste attivamente.
- E una cache fredda, in cui le foto vengono gradualmente espulse dalla cache calda quando arrivano meno richieste.
Affinché funzioni, dobbiamo in qualche modo gestire questa cache, dobbiamo riorganizzare le foto al suo interno, ecc. Anche questo è un processo molto primitivo.
Nginx scrive semplicemente nel RAMDisk access.log per ogni richiesta, in cui indica il percorso della foto che ha attualmente servito (percorso relativo, ovviamente) e quale partizione è stata servita. Quelli. potrebbe dire "foto 1" e poi un buffer, una hot cache, una cold cache o un proxy.
A seconda di ciò, dobbiamo in qualche modo decidere cosa fare con la foto.
Abbiamo un piccolo demone in esecuzione su ogni macchina che legge costantemente questo registro e memorizza nella sua memoria le statistiche sull'uso di determinate fotografie.
Raccoglie semplicemente lì, tiene i contatori e periodicamente fa quanto segue. Sposta le foto richieste attivamente, per le quali ci sono molte richieste, nella hot cache, ovunque si trovino.
Le foto richieste raramente e che sono diventate richieste meno frequentemente vengono gradualmente spostate dalla cache attiva a quella fredda.
E quando esauriamo lo spazio nella cache, iniziamo semplicemente a eliminare indiscriminatamente tutto dalla cache fredda. E comunque, funziona bene.
Affinché la foto venga salvata immediatamente quando la inseriamo nel buffer, utilizziamo la direttiva proxy_store e anche il buffer è un RAMDisk, cioè per l'utente funziona molto rapidamente. Ciò riguarda le parti interne del server di memorizzazione nella cache stesso.
La domanda rimanente è come distribuire le richieste su questi server.
Supponiamo che ci sia un cluster di venti macchine di storage e tre server di caching (è successo così).
Dobbiamo in qualche modo determinare quali richieste riguardano quali foto e dove inserirle.
L'opzione più comune è Round Robin. Oppure lo fai per sbaglio?
Ciò ovviamente presenta una serie di svantaggi perché in una situazione del genere utilizzeremmo la cache in modo molto inefficiente. Le richieste arriveranno su alcune macchine casuali: qui era memorizzato nella cache, ma su quella successiva non c'è più. E se tutto questo funziona, sarà molto brutto. Anche con un numero limitato di macchine nel cluster.
Dobbiamo in qualche modo determinare in modo inequivocabile quale server indirizzare a quale richiesta.
C'è un modo banale. Prendiamo l'hash dall'URL o l'hash dalla nostra chiave di sharding, che si trova nell'URL, e lo dividiamo per il numero di server. Funzionerà? Volere.
Quelli. abbiamo una richiesta del 2%, ad esempio per qualche “example_url” atterrerà sempre sul server con indice “XNUMX”, e la cache verrà costantemente smaltita nel miglior modo possibile.
Ma c'è un problema con il resharding in un simile schema. Resharding: intendo cambiare il numero di server.
Supponiamo che il nostro cluster di caching non possa più farcela e decidiamo di aggiungere un'altra macchina.
Aggiungiamo.
Ora tutto è divisibile non per tre, ma per quattro. Pertanto, quasi tutte le chiavi che avevamo, quasi tutti gli URL ora risiedono su altri server. L'intera cache è stata invalidata semplicemente per un momento. Tutte le richieste sono cadute sul nostro cluster di archiviazione, si è ammalato, si sono verificati guasti del servizio e utenti insoddisfatti. Non voglio farlo.
Anche questa opzione non è adatta a noi.
Quello. cosa dovremmo fare? Dobbiamo in qualche modo fare un uso efficiente della cache, inviare la stessa richiesta sullo stesso server più e più volte, ma essere resistenti al resharding. E esiste una soluzione del genere, non è così complicata. Si chiama hashing coerente.
Che aspetto ha?
Prendiamo qualche funzione dalla chiave di sharding e distribuiamo tutti i suoi valori sul cerchio. Quelli. al punto 0 i suoi valori minimo e massimo convergono. Successivamente, posizioniamo tutti i nostri server sullo stesso cerchio approssimativamente in questo modo:
Ogni server è definito da un punto e il settore che va in senso orario verso di esso, di conseguenza, è servito da questo host. Quando le richieste ci arrivano, vediamo immediatamente che, ad esempio, la richiesta A - ha un hash lì - ed è servita dal server 2. Richiesta B - dal server 3. E così via.
Cosa succede in questa situazione durante il resharding?
Non invalidiamo l'intera cache, come prima, e non spostiamo tutte le chiavi, ma spostiamo ogni settore di un breve tratto in modo che, relativamente parlando, il nostro sesto server, che vogliamo aggiungere, si adatti allo spazio libero e lo aggiungiamo lì.
Naturalmente, in una situazione del genere anche le chiavi si spostano. Ma escono molto più deboli di prima. E vediamo che le nostre prime due chiavi sono rimaste sui loro server e il server di memorizzazione nella cache è cambiato solo per l'ultima chiave. Funziona in modo abbastanza efficiente e se aggiungi nuovi host in modo incrementale, non ci sono grossi problemi qui. Aggiungi e aggiungi un po' alla volta, attendi che la cache sia di nuovo piena e tutto funziona bene.
Resta il dubbio sui rifiuti. Supponiamo che qualche tipo di macchina sia fuori servizio.
E non vorremmo davvero rigenerare questa mappa in questo momento, invalidare parte della cache e così via, se, ad esempio, la macchina fosse riavviata e avessimo bisogno in qualche modo di soddisfare le richieste. Conserviamo semplicemente una cache di foto di backup in ogni sito, che funge da sostituto per qualsiasi macchina attualmente inattiva. E se all'improvviso uno dei nostri server non è più disponibile, il traffico va lì. Naturalmente non abbiamo cache lì, cioè fa freddo, ma almeno le richieste degli utenti vengono elaborate. Se questo è un intervallo breve, lo sperimentiamo con totale calma. C'è solo più carico sullo spazio di archiviazione. Se questo intervallo è lungo, possiamo già prendere una decisione: rimuovere o meno questo server dalla mappa, o magari sostituirlo con un altro.
Riguarda il sistema di memorizzazione nella cache. Diamo un'occhiata ai risultati.
Sembrerebbe che non ci sia nulla di complicato qui. Ma questo metodo di gestione della cache ci ha dato una percentuale di trucchi di circa il 98%. Quelli. di queste 80mila richieste al secondo, solo 1600 raggiungono lo spazio di archiviazione, e questo è un carico del tutto normale, lo sopportano con calma, abbiamo sempre una riserva.
Abbiamo posizionato questi server in tre dei nostri DC e abbiamo ricevuto tre punti di presenza: Praga, Miami e Hong Kong.
Quello. sono più o meno localizzati in ciascuno dei nostri mercati target.
E come bonus, abbiamo questo proxy di caching, sul quale la CPU è effettivamente inattiva, perché non è così necessaria per servire i contenuti. E lì, utilizzando NGINX+ Lua, abbiamo implementato molta logica utilitaristica.
Ad esempio, possiamo sperimentare webp o jpeg progressivo (sono formati moderni efficaci), vedere come influisce sul traffico, prendere alcune decisioni, abilitarlo per determinati paesi, ecc.; effettua il ridimensionamento dinamico o ritaglia le foto al volo.
Questo è un buon caso d'uso quando, ad esempio, hai un'applicazione mobile che visualizza foto e l'applicazione mobile non vuole sprecare la CPU del client richiedendo una foto di grandi dimensioni e quindi ridimensionandola a una certa dimensione per inserirla la vista. Possiamo semplicemente specificare dinamicamente alcuni parametri nell'URL condizionale di UPort e la cache delle foto ridimensionerà la foto stessa. Di norma, selezionerà la dimensione che abbiamo fisicamente sul disco, il più vicino possibile a quella richiesta, e la venderà a coordinate specifiche.
A proposito, abbiamo reso disponibili al pubblico le registrazioni video degli ultimi cinque anni della conferenza degli sviluppatori di sistemi ad alto carico . Guarda, impara, condividi e iscriviti .
Possiamo anche aggiungere molta logica di prodotto lì. Ad esempio, possiamo aggiungere diverse filigrane utilizzando i parametri URL, possiamo sfocare, sfocare o pixelare le foto. Questo è quando vogliamo mostrare la foto di una persona, ma non vogliamo mostrare il suo volto, funziona bene, è tutto implementato qui.
Cosa abbiamo ottenuto? Abbiamo tre punti di presenza, un buon tasso di trick e allo stesso tempo non abbiamo CPU inattiva su queste macchine. Ora è diventato, ovviamente, più importante di prima. Dobbiamo dotarci di macchine più forti, ma ne vale la pena.
Ciò riguarda la restituzione delle fotografie. Qui tutto è abbastanza chiaro ed evidente. Penso di non aver scoperto l’America, quasi tutti i CDN funzionano in questo modo.
E, molto probabilmente, un ascoltatore sofisticato potrebbe avere una domanda: perché non cambiare semplicemente tutto in CDN? Sarebbe più o meno lo stesso; tutti i moderni CDN possono farlo. E ci sono una serie di ragioni.
Il primo sono le fotografie.
Questo è uno dei punti chiave della nostra infrastruttura e abbiamo bisogno del massimo controllo possibile su di esso. Se si tratta di una sorta di soluzione di un fornitore di terze parti e non hai alcun potere su di essa, sarà abbastanza difficile per te conviverci quando disponi di un set di dati di grandi dimensioni e quando hai un flusso molto ampio delle richieste degli utenti.
Lasciate che vi faccia un esempio. Adesso con la nostra infrastruttura possiamo, ad esempio, in caso di problemi o colpi sotterranei, andare alla macchina e fare casino lì, relativamente parlando. Possiamo aggiungere la raccolta di alcune metriche di cui abbiamo solo bisogno, possiamo sperimentare in qualche modo, vedere come ciò influisce sui grafici e così via. Ora vengono raccolte molte statistiche su questo cluster di memorizzazione nella cache. E periodicamente lo guardiamo e passiamo molto tempo ad esplorare alcune anomalie. Se fosse dalla parte della CDN, sarebbe molto più difficile da controllare. Oppure, ad esempio, se si verifica un qualche tipo di incidente, sappiamo cosa è successo, sappiamo come conviverci e come superarlo. Questa è la prima conclusione.
Anche la seconda conclusione è piuttosto storica, perché il sistema è stato sviluppato per molto tempo e c'erano molti requisiti aziendali diversi in fasi diverse, che non sempre rientrano nel concetto CDN.
E il punto che segue dal precedente è
Questo perché sulle cache delle foto abbiamo molta logica specifica, che non sempre può essere aggiunta su richiesta. È improbabile che qualsiasi CDN aggiunga alcune cose personalizzate su tua richiesta. Ad esempio, crittografare gli URL se non vuoi che il client possa modificare qualcosa. Vuoi modificare l'URL sul server e crittografarlo, quindi inviare qui alcuni parametri dinamici.
Quale conclusione suggerisce questo? Nel nostro caso, la CDN non è un’ottima alternativa.
E nel tuo caso, se hai requisiti aziendali specifici, puoi implementare abbastanza facilmente ciò che ti ho mostrato tu stesso. E funzionerà perfettamente con un profilo di carico simile.
Ma se hai una soluzione generale e il compito non è molto specifico, puoi prendere un CDN in tutta sicurezza. O se per te il tempo e le risorse sono più importanti del controllo.
E i CDN moderni hanno quasi tutto ciò di cui ti ho parlato ora. Ad eccezione di più o meno alcune funzionalità.
Si tratta di regalare foto.
Andiamo ora un po' avanti nella nostra retrospettiva e parliamo di storage.
Il 2013 stava passando.
Sono stati aggiunti i server di memorizzazione nella cache e i problemi di prestazioni sono stati risolti. Va tutto bene. Il set di dati è in crescita. Nel 2013, avevamo circa 80 server collegati allo storage e circa 40 server con memorizzazione nella cache in ciascun controller di dominio. Si tratta di 560 terabyte di dati su ciascun controller di dominio, ovvero circa un petabyte in totale.
E con la crescita del set di dati, i costi operativi hanno cominciato ad aumentare in modo significativo. Cosa significava?
In questo diagramma disegnato - con una SAN, con macchine e cache ad essa collegate - ci sono molti punti di guasto. Se avessimo già affrontato in precedenza il guasto dei server di caching, tutto sarebbe stato più o meno prevedibile e comprensibile, ma dal lato dello storage tutto era molto peggio.
In primo luogo, la stessa Storage Area Network (SAN), che può fallire.
In secondo luogo è collegato tramite ottica alle macchine finali. Potrebbero esserci problemi con le schede ottiche e le candele.
Naturalmente, non ce ne sono così tanti come con la SAN stessa, ma, tuttavia, questi sono anche punti di fallimento.
Poi c'è la macchina stessa, che è collegata allo spazio di archiviazione. Può anche fallire.
In totale, abbiamo tre punti di fallimento.
Inoltre, oltre ai punti di guasto, vi è una pesante manutenzione dello storage stesso.
Si tratta di un sistema complesso multicomponente e gli ingegneri di sistema possono avere difficoltà a lavorarci.
E l'ultimo punto più importante. Se si verifica un errore in uno qualsiasi di questi tre punti, abbiamo una possibilità diversa da zero di perdere i dati dell'utente perché il file system potrebbe bloccarsi.
Diciamo che il nostro file system è danneggiato. Innanzitutto, il suo ripristino richiede molto tempo: con una grande quantità di dati può richiedere una settimana. E in secondo luogo, alla fine, molto probabilmente ci ritroveremo con un mucchio di file incomprensibili che dovranno in qualche modo essere combinati nelle foto degli utenti. E rischiamo di perdere dati. Il rischio è piuttosto alto. E quanto più spesso si verificano tali situazioni e quanti più problemi sorgono nell'intera catena, tanto maggiore è il rischio.
Bisognava fare qualcosa a riguardo. E abbiamo deciso che dovevamo solo eseguire il backup dei dati. Questa è in realtà una soluzione ovvia e buona. Cosa abbiamo fatto?
Questo è l'aspetto del nostro server quando era connesso allo spazio di archiviazione in precedenza. Questa è una sezione principale, è solo un dispositivo a blocchi che in realtà rappresenta un supporto per l'archiviazione remota tramite ottica.
Abbiamo appena aggiunto una seconda sezione.
Accanto ad esso abbiamo posizionato un secondo spazio di archiviazione (per fortuna non è così costoso in termini di denaro) e lo abbiamo chiamato partizione di backup. Inoltre è collegato tramite ottica e si trova sulla stessa macchina. Ma dobbiamo in qualche modo sincronizzare i dati tra loro.
Qui facciamo semplicemente una coda asincrona nelle vicinanze.
Non è molto impegnata. Sappiamo di non avere abbastanza documenti. Una coda è semplicemente una tabella in MySQL in cui sono scritte righe come "devi eseguire il backup di questa foto". Con qualsiasi modifica o caricamento, copiamo dalla partizione principale al backup utilizzando un asincrono o semplicemente una sorta di operatore in background.
E così abbiamo sempre due sezioni coerenti. Anche se una parte di questo sistema fallisce, possiamo sempre cambiare la partizione principale con un backup e tutto continuerà a funzionare.
Ma a causa di ciò, il carico di lettura aumenta notevolmente, perché... oltre ai clienti che leggono dalla sezione principale, perché prima guardano la foto lì (là è più recente), e poi la cercano nel backup, se non l'hanno trovata (ma NGINX fa proprio questo), il nostro sistema è anche un backup in più ora legge dalla partizione principale. Non è che questo fosse un collo di bottiglia, ma non volevo aumentare il carico, insomma, proprio così.
E abbiamo aggiunto un terzo disco, che è un piccolo SSD, e lo abbiamo chiamato buffer.
Come funziona adesso.
L'utente carica una foto nel buffer, quindi un evento viene inserito in coda indicando che deve essere copiato in due sezioni. Viene copiata e la foto rimane nel buffer per un po' di tempo (diciamo, un giorno), e solo dopo viene eliminata da lì. Ciò migliora notevolmente l'esperienza dell'utente, perché l'utente carica una foto, di norma, le richieste iniziano immediatamente a seguire, oppure lui stesso ha aggiornato la pagina e l'ha aggiornata. Ma tutto dipende dall'applicazione che effettua il caricamento.
Oppure, ad esempio, altre persone a cui ha iniziato a mostrarsi inviano immediatamente richieste dopo questa foto. Non è ancora nella cache; la prima richiesta avviene molto rapidamente. Essenzialmente lo stesso di una cache di foto. Lo storage lento non è affatto coinvolto in questo. E quando il giorno dopo viene eliminato, è già memorizzato nella cache nel nostro livello di cache o, molto probabilmente, nessuno ne ha più bisogno. Quelli. L'esperienza dell'utente qui è cresciuta molto bene grazie a manipolazioni così semplici.
Bene, e soprattutto: abbiamo smesso di perdere dati.
Diciamo che ci siamo fermati potenzialmente perdere dati, perché non li abbiamo realmente persi. Ma c'era pericolo. Vediamo che questa soluzione è, ovviamente, buona, ma è un po’ come attenuare i sintomi del problema, invece di risolverlo completamente. E qui restano alcuni problemi.
In primo luogo, questo è un punto di fallimento sotto forma di host fisico stesso su cui gira tutto questo macchinario; non è scomparso.
In secondo luogo, ci sono ancora problemi con le SAN, la loro pesante manutenzione, ecc. Non che fosse un fattore critico, ma volevo provare a farne a meno in qualche modo.
E abbiamo realizzato la terza versione (in effetti, la seconda in effetti): la versione con prenotazione. Che aspetto aveva?
Questo è quello che era -
I nostri problemi principali riguardano il fatto che si tratta di un host fisico.
In primo luogo, stiamo rimuovendo le SAN perché vogliamo sperimentare, vogliamo provare solo i dischi rigidi locali.
Siamo già nel 2014-2015 e in quel momento la situazione con i dischi e la loro capacità in un host è migliorata molto. Abbiamo deciso perché non provarlo.
E poi prendiamo semplicemente la nostra partizione di backup e la trasferiamo fisicamente su una macchina separata.
Quindi, otteniamo questo diagramma. Abbiamo due auto che memorizzano gli stessi set di dati. Si supportano completamente a vicenda e sincronizzano i dati sulla rete tramite una coda asincrona nello stesso MySQL.
Il motivo per cui funziona bene è perché abbiamo pochi record. Quelli. se la scrittura fosse paragonabile alla lettura, forse avremmo qualche tipo di sovraccarico e di problemi di rete. Si scrive poco, si legge molto: questo metodo funziona bene, ad es. Raramente copiamo le foto tra questi due server.
Come funziona, se guardi un po' più in dettaglio.
Caricamento. Il bilanciatore seleziona semplicemente host casuali con una coppia e li carica. Allo stesso tempo, naturalmente, fa i controlli sanitari e si assicura che l’auto non cada. Quelli. carica le foto solo su un server live e poi, attraverso una coda asincrona, viene tutto copiato sul suo vicino. Con upload tutto è estremamente semplice.
Il compito è un po’ più difficile.
Lua ci ha aiutato qui, perché può essere difficile creare una tale logica su Vanilla NGINX. Per prima cosa facciamo una richiesta al primo server, vediamo se la foto è lì, perché potenzialmente potrebbe essere caricata, ad esempio, su un vicino, ma non è ancora arrivata qui. Se la foto c'è, va bene. Lo diamo immediatamente al cliente e, possibilmente, lo memorizziamo nella cache.
Se non c'è, facciamo semplicemente una richiesta al nostro vicino e da lì abbiamo la garanzia di riceverlo.
Quello. ancora una volta possiamo dire: potrebbero esserci problemi con le prestazioni, perché ci sono continui viaggi di andata e ritorno - la foto è stata caricata, non è qui, stiamo facendo due richieste invece di una, dovrebbe funzionare lentamente.
Nella nostra situazione, questo non funziona lentamente.
Raccogliamo una serie di parametri su questo sistema e il tasso intelligente condizionale di tale meccanismo è di circa il 95%. Quelli. Il ritardo di questo backup è minimo e per questo siamo quasi sicuri che, dopo che la foto è stata caricata, la prenderemo la prima volta e non dovremo andare da nessuna parte due volte.
Quindi cos'altro abbiamo di veramente bello?
In precedenza, avevamo la partizione di backup principale e leggevamo da esse in sequenza. Quelli. Abbiamo sempre cercato prima quello principale e poi quello di backup. È stata una mossa.
Ora utilizziamo la lettura da due macchine contemporaneamente. Distribuiamo le richieste utilizzando Round Robin. In una piccola percentuale di casi facciamo due richieste. Ma nel complesso, ora abbiamo il doppio del patrimonio di lettura rispetto a prima. E il carico è stato notevolmente ridotto sia sulle macchine di spedizione che direttamente sulle macchine di stoccaggio, che avevamo anche allora.
Per quanto riguarda la tolleranza agli errori. In realtà è proprio per questo che ci siamo battuti principalmente. Con la tolleranza agli errori, qui tutto è andato alla grande.
Una macchina va in panne.
Nessun problema! Un sistemista potrebbe anche non svegliarsi di notte, aspetterà fino al mattino, non succederà nulla di male.
Se anche se questa macchina si guasta, la coda è fuori servizio, e non ci sono problemi, il registro verrà semplicemente accumulato prima sulla macchina vivente, quindi verrà aggiunto alla coda, e poi sull'auto che verrà entrare in funzione dopo qualche tempo.
Stessa cosa con la manutenzione. Spegniamo semplicemente una delle macchine, la estraiamo manualmente da tutti i pool, smette di ricevere traffico, facciamo qualche tipo di manutenzione, modifichiamo qualcosa, quindi la rimettiamo in servizio e questo backup si aggiorna abbastanza rapidamente. Quelli. al giorno, il tempo di inattività di un'auto viene recuperato in un paio di minuti. Questo è davvero molto poco. Con la tolleranza agli errori, lo ripeto, qui va tutto bene.
Quali conclusioni si possono trarre da questo piano di licenziamento?
Abbiamo la tolleranza agli errori.
Facile da usare. Poiché le macchine dispongono di dischi rigidi locali, questo è molto più conveniente dal punto di vista operativo per gli ingegneri che ci lavorano.
Abbiamo ricevuto un'indennità di lettura doppia.
Questo è un ottimo bonus oltre alla tolleranza agli errori.
Ma ci sono anche problemi. Ora abbiamo uno sviluppo molto più complesso di alcune funzionalità legate a questo, perché il sistema è diventato finalmente coerente al 100%.
Dobbiamo, ad esempio, in qualche lavoro in background, pensare costantemente: "Su quale server stiamo lavorando adesso?", "C'è davvero una foto attuale qui?" eccetera. Tutto questo, ovviamente, è tutto compreso e per il programmatore che scrive la logica aziendale è trasparente. Tuttavia, è apparso questo grande strato complesso. Ma siamo pronti a sopportarlo in cambio dei benefici che ne abbiamo ricevuto.
E anche qui sorge qualche conflitto.
All'inizio ho detto che archiviare tutto sui dischi rigidi locali è dannoso. E ora dico che ci è piaciuto.
Sì, infatti, nel tempo la situazione è cambiata molto, e ora questo approccio presenta molti vantaggi. Innanzitutto, otteniamo un funzionamento molto più semplice.
In secondo luogo, è più produttivo, perché non abbiamo questi controller automatici o connessioni agli scaffali dei dischi.
C'è un'enorme quantità di macchinari lì, e questi sono solo alcuni dischi che vengono assemblati qui sulla macchina in un raid.
Ma ci sono anche degli svantaggi.
Questo è circa 1,5 volte più costoso rispetto all'utilizzo delle SAN anche ai prezzi odierni. Pertanto, abbiamo deciso di non convertire coraggiosamente l'intero nostro grande cluster in auto con dischi rigidi locali e abbiamo deciso di lasciare una soluzione ibrida.
La metà delle nostre macchine funziona con dischi rigidi (beh, non la metà, probabilmente il 30%). E il resto sono vecchie auto che avevano il primo schema di prenotazione. Li abbiamo semplicemente rimontati, visto che non avevamo bisogno di nuovi dati o altro, abbiamo semplicemente spostato i montaggi da un host fisico a due.
E ora abbiamo una grande scorta di letture e l'abbiamo ampliata. Se prima montavamo uno storage su una macchina, ora ne montiamo quattro, ad esempio, su una coppia. E funziona bene.
Facciamo un breve riassunto di ciò che abbiamo realizzato, per cosa abbiamo combattuto e se ci siamo riusciti.
Risultati di
Abbiamo utenti: ben 33 milioni.
Abbiamo tre punti di presenza: Praga, Miami, Hong Kong.
Contengono un livello di caching, che consiste in auto con dischi locali veloci (SSD), su cui girano semplici macchinari di NGINX, il suo access.log e demoni Python, che elaborano tutto questo e gestiscono la cache.
Se lo desideri, sei nel tuo progetto, se le foto non sono così importanti per te come lo sono per noi, o se il controllo del compromesso rispetto alla velocità di sviluppo e ai costi delle risorse è nella direzione opposta per te, allora puoi tranquillamente sostituirle con un CDN, i CDN moderni funzionano bene.
Poi arriva il livello di archiviazione, sul quale abbiamo cluster di coppie di macchine che si supportano a vicenda, i file vengono copiati in modo asincrono dall'uno all'altro ogni volta che cambiano.
Inoltre, alcune di queste macchine funzionano con dischi rigidi locali.
Alcune di queste macchine sono connesse a SAN.
E, da un lato, è più comodo da usare e un po' più produttivo, dall'altro è conveniente in termini di densità di posizionamento e prezzo per gigabyte.
Questa è una breve panoramica dell'architettura di ciò che abbiamo ottenuto e di come tutto si è sviluppato.
Ancora qualche consiglio dal capitano, molto semplice.
Innanzitutto, se all'improvviso decidi che hai urgentemente bisogno di migliorare tutto nella tua infrastruttura fotografica, misura prima, perché forse non c'è nulla da migliorare.
Lasciate che vi faccia un esempio. Abbiamo un gruppo di macchine che inviano foto dagli allegati nelle chat e il sistema funziona lì dal 2009 e nessuno ne soffre. Stanno tutti bene, piace tutto a tutti.
Per misurare, prima appendi una serie di parametri, guardali e poi decidi di cosa non sei soddisfatto e cosa deve essere migliorato. Per misurarlo, abbiamo uno strumento interessante chiamato Pinba.
Ti consente di raccogliere statistiche molto dettagliate da NGINX per ogni richiesta, codici di risposta e distribuzione dei tempi, qualunque cosa tu voglia. Ha collegamenti con tutti i tipi di diversi sistemi di analisi e quindi puoi guardarlo tutto magnificamente.
Prima l'abbiamo misurato, poi l'abbiamo migliorato.
Ulteriore. Ottimizziamo la lettura con la cache, la scrittura con lo sharding, ma questo è un punto ovvio.
Ulteriore. Se stai appena iniziando a costruire il tuo sistema, allora è molto meglio creare foto come file immutabili. Perché perdi immediatamente tutta una serie di problemi con l'invalidazione della cache, con il modo in cui la logica dovrebbe trovare la versione corretta della foto e così via.
Diciamo che ne hai caricati un centinaio, poi li hai ruotati, fai in modo che fosse un file fisicamente diverso. Quelli. non c'è bisogno di pensarci: ora risparmierò un po' di spazio, lo scrivo nello stesso file, cambio la versione. Questo non funziona sempre bene e causa molti mal di testa in seguito.
Punto successivo. Informazioni sul ridimensionamento al volo.
In precedenza, quando gli utenti caricavano una foto, tagliavamo immediatamente un sacco di dimensioni per tutte le occasioni, per clienti diversi, ed erano tutte sul disco. Ora lo abbiamo abbandonato.
Abbiamo lasciato solo tre taglie principali: piccola, media e grande. Riduciamo semplicemente tutto il resto dalla dimensione che sta dietro a quella che ci è stata chiesta a Uport, facciamo semplicemente il downscale e lo diamo all'utente.
La CPU del livello di caching qui risulta essere molto più economica che se rigenerassimo costantemente queste dimensioni su ogni storage. Diciamo che vogliamo aggiungerne uno nuovo, ci vorrà un mese: esegui ovunque uno script che faccia tutto questo in modo ordinato, senza distruggere il cluster. Quelli. Se hai l'opportunità di scegliere ora, è meglio creare il minor numero possibile di dimensioni fisiche, ma in modo che almeno una certa distribuzione sia, diciamo, tre. E tutto il resto può essere semplicemente ridimensionato al volo utilizzando moduli già pronti. Ora è tutto molto semplice e accessibile.
E il backup asincrono incrementale è buono.
Come ha dimostrato la nostra pratica, questo schema funziona perfettamente con la copia ritardata dei file modificati.
Anche l’ultimo punto è ovvio. Se la tua infrastruttura non presenta tali problemi ora, ma c'è qualcosa che può rompersi, si romperà sicuramente quando diventerà un po 'più grande. Pertanto, è meglio pensarci in anticipo e non avere problemi con esso. Questo è tutto quello che volevo dire.
Contatti
»
»
Questo rapporto è la trascrizione di uno dei migliori discorsi alla conferenza degli sviluppatori di sistemi ad alto carico . Manca meno di un mese alla conferenza HighLoad++ 2017.
Lo abbiamo già pronto , il programma è ora in fase di formazione attiva.
Quest'anno continuiamo ad esplorare il tema delle architetture e della scalabilità:
- / Igor Vasiliev
- / Dmitrij Egorov
- / Anatolij Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Filippo Delgado
Utilizziamo alcuni di questi materiali anche nel nostro corso di formazione online sullo sviluppo di sistemi ad alto carico è una catena di lettere, articoli, materiali, video appositamente selezionati. Il nostro libro di testo contiene già più di 30 materiali unici. Collegare!
Fonte: habr.com