Artem Denisov ( , )
Badoo hè u più grande situ di incontri in u mondu. Avemu attualmente circa 330 milioni d'utilizatori registrati in u mondu. Ma ciò chì hè assai più impurtante in u cuntestu di a nostra conversazione oghje hè chì almacenamu circa 3 petabytes di foto d'utilizatori. Ogni ghjornu, i nostri utilizatori caricanu circa 3,5 milioni di foto novi, è a carica di lettura hè di circa 80 mila richieste per seconda. Questu hè assai per u nostru backend, è qualchì volta ci sò difficultà cù questu.
Parlaraghju di u disignu di stu sistema, chì guarda è manda foto in generale, è l'aghju guardatu da u puntu di vista di u sviluppatore. Ci sarà una breve retrospettiva nantu à cumu si sviluppò, induve descriveraghju e tappe principali, ma parleraraghju solu in più in dettaglio di e suluzioni chì avemu aduprà attualmente.
Avà cuminciamu.
Cumu l'aghju dettu, questu serà una retrospettiva, è per inizià in un locu, pigliemu l'esempiu più cumuni.
Avemu un compitu cumunu, avemu bisognu di accettà, almacenà è mandà e foto di l'utilizatori. In questa forma, u compitu hè generale, pudemu usà qualcosa:
- mudernu almacenamentu in nuvola,
- una suluzione boxed, di quale ci sò ancu assai avà;
- Pudemu stallà parechje macchine in u nostru centru di dati è mette un grande discu duru nantu à elli è almacenà e foto quì.
Badoo storicamente - sia avà sia allora (à l'epica quandu era ghjustu) - vive nantu à i so servitori, in i nostri DC. Dunque, sta opzione era ottima per noi.
Avemu pigliatu solu parechje macchine, chjamate "foto", è avemu un cluster chì guarda e foto. Ma pare chì qualcosa manca. Per fà tuttu questu per travaglià, avemu bisognu di determinate in qualchì manera nantu à quale macchina guardemu quale foto. È ancu quì, ùn ci hè bisognu di apre l'America.
Aghjunghjemu qualchì campu à u nostru almacenamentu cù infurmazioni nantu à l'utilizatori. Questu serà a chjave di sharding. In u nostru casu, avemu chjamatu place_id, è questu locu id indica u locu induve e foto di l'utilizatori sò guardati. Facemu carte.
À a prima tappa, questu pò ancu esse fattu manualmente - dicemu chì una foto di questu utilizatore cù un locu cusì sbarcarà in un tali servitore. Grazie à sta mappa, sapemu sempre quandu un utilizatore carica una foto, induve salvà, è sapemu da induve dà.
Questu hè un schema assolutamente triviale, ma hà vantaghji assai significativu. U primu hè chì hè simplice, cum'è l'aghju dettu, è u sicondu hè chì cù questu approcciu pudemu facilmente scala orizzontalmente, simpliciamente furnisce novi vitture è aghjunghjendu à a mappa. Ùn avete bisognu di fà nunda di più.
Hè cusì chì era per noi per qualchì tempu.
Era circa 2009. Hanu consegnatu vitture, consegnatu ...
È à un certu puntu avemu principiatu à nutà chì stu schema hà certi svantaghji. Chì sò i disadvantages?
Prima di tuttu, ci hè una capacità limitata. Ùn pudemu micca chjappà quanti discu duru in un servitore fisicu cum'è vuleriamu. È questu hè diventatu un certu prublema cù u tempu è cù a crescita di u dataset.
È secondu. Questa hè una cunfigurazione atipica di macchine, postu chì tali macchine sò difficiuli di reutilizazione in certi altri clusters; sò abbastanza specifichi, i.e. duveranu esse debuli in u rendiment, ma à u stessu tempu cù un grande discu duru.
Questu era tuttu per u 2009, ma, in principiu, sti esigenze sò sempre pertinenti oghje. Avemu una retrospettiva, cusì in u 2009 tuttu era completamente male cun questu.
È l'ultimu puntu hè u prezzu.
U prezzu era assai caru à quellu tempu, è avemu bisognu di circà alcune alternative. Quelli. avemu avutu bisognu di utilizà megliu u spaziu in i centri di dati è i servitori fisici nantu à quale tuttu questu hè situatu. È i nostri ingegneri di u sistema cuminciaru un grande studiu in quale anu rivisatu una mansa di diverse opzioni. Hanu ancu guardatu à i sistemi di fugliale clustered cum'è PolyCeph è Luster. Ci sò stati prublemi di rendiment è operazione abbastanza difficiule. Anu ricusatu. Avemu pruvatu à muntà tuttu u set di dati via NFS nantu à ogni vittura in modu di scala in qualchì manera. A lettura hè ancu andata male, avemu pruvatu diverse suluzioni da diversi venditori.
È à a fine, avemu stallatu annantu à l'usu di a chjamata Storage Area Network.
Quessi sò grandi SHD chì sò specificamente pensati per almacenà grandi quantità di dati. Sò scaffali cù dischi chì sò muntati nantu à e macchine finali di output otticu. Chì. avemu un tipu di pool di machini, abbastanza chjuchi, è questi SHD, chì sò trasparenti à a nostra logica di mandatu, i.e. per u nostru nginx o qualcunu altru per serve richieste per queste foto.
Sta decisione avia vantaghji evidenti. Questu hè SHD. Hè destinatu à guardà e foto. Questu hè più prezzu chè solu equipà e macchine cù discu duru.
Second plus.
Questu hè chì a capacità hè diventata assai più grande, i.e. pudemu accoglie assai più almacenamentu in un voluminu assai più chjucu.
Ma ci sò ancu disadvantages chì emergenu abbastanza rapidamente. Cum'è u numeru di utilizatori è carica nantu à stu sistema criscinu, i prublemi di rendiment cuminciaru à nasce. È u prublema quì hè abbastanza evidenti - ogni SHD pensatu per almacenà parechje foto in un picculu voluminu, in regula, soffre di lettura intensiva. Questu hè veramente veru per qualsiasi almacenamentu in nuvola o qualsiasi altra cosa. Avà ùn avemu micca un almacenamentu ideale chì seria scalabile à l'infinitu, pudete mette qualcosa in questu, è tollerà e letture assai bè. In particulare letture casuali.
Cum'è u casu cù e nostre foto, perchè e foto sò richieste in modu inconsistente, è questu affettarà assai u so rendiment.
Ancu sicondu i figuri di l'oghje, se ghjunghjemu in un locu più di 500 RPS per e foto nantu à una macchina à a quale l'almacenamiento hè cunnessu, i prublemi cumincianu digià. È era abbastanza male per noi, perchè u numeru di l'utilizatori hè in crescita, e cose sò solu peghju. Questu deve esse ottimisatu in qualchì modu.
Per ottimisà, avemu decisu à quellu tempu, ovviamente, per fighjà u prufilu di carica - ciò chì, in generale, succede, ciò chì deve esse ottimizatu.
È quì tuttu ghjoca in e nostre mani.
Aghju digià dettu in a prima slide: avemu 80 mila richieste di lettura per seconda cù solu 3,5 milioni di caricamenti per ghjornu. Questu hè, questu hè una diferenza di trè ordini di grandezza. Hè ovvi chì a lettura deve esse ottimizzata è hè praticamente chjaru cumu.
Ci hè un puntu più chjucu. I specifichi di u serviziu sò tali chì una persona si registra, carica una foto, poi principia à fighjà attivamente à l'altri populi, cum'è elli, è hè attivamente mostratu à l'altri populi. Allora si trova un cumpagnu o ùn trova micca un cumpagnu, dipende cumu si diventa, è cessà di utilizà u serviziu per un tempu. À questu mumentu, quandu l'utiliza, i so ritratti sò assai caldi - sò in dumanda, assai persone li vede. Appena ch'ellu smette di fà questu, abbastanza rapidamente abbanduneghja a quantità di esposizione à l'altri persone cum'è prima, è e so foto ùn sò quasi mai richieste.
Quelli. Avemu un set di dati assai chjucu. Ma à u listessu tempu ci sò parechje dumande per ellu. È una suluzione cumplettamente ovvia quì hè di aghjunghje una cache.
Una cache cù LRU risolverà tutti i nostri prublemi. Chì facemu ?
Aghjunghjemu un altru relativamente chjucu davanti à u nostru grande cluster cù almacenamiento, chì hè chjamatu photocaches. Questu hè essenzialmente solu un proxy di caching.
Cumu funziona da l'internu? Eccu u nostru utilizatore, quì hè u almacenamentu. Tuttu hè u listessu cum'è prima. Chì aghjunghjemu trà?
Hè solu una macchina cù un discu fisicu locale, chì hè veloce. Questu hè cù un SSD, per esempiu. È un tipu di cache locale hè almacenatu nantu à stu discu.
Chì pare ? L'utilizatore manda una dumanda per una foto. NGINX cerca prima in a cache locale. Se no, allora simpricimenti proxy_pass à u nostru almacenamentu, scaricate a foto da quì è dà à l'utilizatore.
Ma questu hè assai banale è ùn hè micca chjaru ciò chì succede in l'internu. Funziona qualcosa cum'è questu.
A cache hè logicamente divisa in trè strati. Quandu dicu "trè strati", questu ùn significa micca chì ci hè un sistema cumplessu. No, questi sò cundizionalmente solu trè cartulari in u sistema di fugliale:
- Questu hè un buffer induve e foto appena scaricate da un proxy vanu.
- Questa hè una cache calda chì guarda e foto attualmente richieste attivamente.
- È una cache fredda, induve e foto sò gradualmente spinte fora di a cache calda quandu menu richieste li venenu.
Per fà questu, avemu bisognu di gestisce in qualchì modu sta cache, avemu bisognu di riarrangerà e foto in questu, etc. Questu hè ancu un prucessu assai primitivu.
Nginx simpricimenti scrive à u RAMDisk access.log per ogni dumanda, in quale indica u percorsu à a foto chì hà attualmente servutu (via relative, sicuru), è quale partizione hè stata servuta. Quelli. pò dì "foto 1" è dopu o un buffer, o una cache calda, o una cache fredda, o un proxy.
Sicondu questu, avemu bisognu di qualcosa di decide ciò chì fà cù a foto.
Avemu un picculu demoniu chì curreghja nantu à ogni macchina chì leghje constantemente stu logu è guarda statistiche nantu à l'usu di certe ritratti in a so memoria.
Ellu simpricimenti recullà quì, mantene i cuntatori è periodicamente fa e seguenti. Si move attivamente e foto richieste, per quale ci sò parechje dumande, à u cache caldu, induve sò.
I ritratti chì sò dumandati raramente è sò diventati dumandati menu frequente sò gradualmente spinti da u cache caldu in u friddu.
È quandu avemu scappatu di u spaziu in u cache, simpricimenti cuminciamu à sguassà tuttu da a cache fredda indiscriminatamente. E per via, questu funziona bè.
Per chì a foto sia salvata immediatamente quandu u proxy à u buffer, usemu a direttiva proxy_store è u buffer hè ancu un RAMDisk, i.e. per l'utilizatori travaglia assai rapidamente. Questu riguarda l'internu di u servitore di caching stessu.
A quistione restante hè cumu si distribuisce e dumande in questi servitori.
Diciamu chì ci hè un cluster di vinti macchine di almacenamento è trè servitori di cache (questu hè accadutu).
Avemu bisognu di qualchì manera di determinà quali dumande sò per quale foto è induve sbarcà.
L'opzione più cumuna hè Round Robin. O fà per accidente?
Questu ovviamente hà una quantità di svantaghji perchè avemu aduprà a cache in modu assai inefficiente in una tale situazione. E dumande sbarcaranu nantu à certi macchine aleatorii: quì hè stata cache, ma nantu à u prossimu ùn ci hè più. È se tuttu questu funziona, serà assai male. Ancu cù un picculu numeru di machini in u cluster.
Avemu bisognu di determinà in modu senza ambiguità quale servitore sbarcà quale dumanda.
Ci hè un modu banale. Pigliemu l'hash da l'URL o l'hash da a nostra chjave di sharding, chì hè in l'URL, è dividite per u numeru di servitori. Funcionà ? Will.
Quelli. Avemu una dumanda di 2%, per esempiu, per qualchi "example_url" sbarcarà sempre nantu à u servitore cù l'indice "XNUMX", è a cache serà sempre disposta u megliu pussibule.
Ma ci hè un prublema cù resharding in un tali schema. Resharding - Vogliu dì cambià u numeru di servitori.
Assumimu chì u nostru cluster di caching ùn pò più affruntà è decidemu di aghjunghje una altra macchina.
Aghjunghjemu.
Avà tuttu hè divisibile micca da trè, ma da quattru. Cusì, quasi tutti i chjavi chì avemu avutu, quasi tutti l'URL ora campanu in altri servitori. Tuttu u cache hè statu invalidatu solu per un mumentu. Tutte e dumande sò cascate nantu à u nostru cluster di almacenamento, hè diventatu malatu, fallimentu di serviziu è utilizatori insatisfatti. Ùn vogliu micca fà quessa.
Questa opzione ùn ci cunvene ancu.
Chì. chì duvemu fà ? Avemu da fà un usu efficace di u cache, sbarcà a stessa dumanda nantu à u stessu servitore una volta è una volta, ma esse resistenti à u resharding. È ci hè una suluzione cusì, ùn hè micca cusì complicata. Hè chjamatu hashing consistente.
Cumu pare?
Pigliemu qualchì funzione da a chjave di sharding è sparghje tutti i so valori nantu à u circhiu. Quelli. à u puntu 0, i so valori minimi è massimi cunvergenu. In seguitu, pusemu tutti i nostri servitori nantu à u stessu cercolu in circa stu modu:
Ogni servitore hè definitu da un puntu, è u settore chì và in u sensu orariu, per quessa, hè servutu da questu host. Quandu e dumande venenu à noi, vedemu subitu chì, per esempiu, a dumanda A - hà un hash quì - è hè servutu da u servitore 2. A dumanda B - da u servitore 3. È cusì.
Cosa succede in sta situazione durante u reharding?
Ùn invalidemu micca u cache sanu, cum'è prima, è ùn cambiate micca tutte e chjave, ma cambiamu ogni settore à una corta distanza in modu chì, relativamente parlante, u nostru sestu servitore, chì vulemu aghjunghje, si mette in u spaziu liberu, è l'aghjunghjemu quì.
Di sicuru, in una tale situazione, i chjavi si movenu ancu fora. Ma si alluntananu assai più debuli chè prima. È vedemu chì i nostri primi dui chjavi sò stati in i so servitori, è u servitore di caching hà cambiatu solu per l'ultima chjave. Questu travaglia in modu abbastanza efficace, è se aghjunghje novi ospiti in modu incrementale, allora ùn ci hè micca un grande prublema quì. Aghjunghjite è aghjunghje un pocu à tempu, aspettate finu à chì a cache hè piena di novu, è tuttu funziona bè.
L'unica quistione resta cù i rifiuti. Assumimu chì un tipu di vittura hè fora di ordine.
È ùn vulemu micca veramente rigenerate sta mappa in questu momentu, invalidate una parte di u cache, è cusì, se, per esempiu, a macchina hè stata rebootata, è avemu bisognu di qualchì manera di dumande di serviziu. Semu simpricimenti mantene una cache di foto di salvezza in ogni situ, chì agisce cum'è un rimpiazzamentu per ogni macchina chì hè attualmente in calata. È se di colpu unu di i nostri servitori diventa indisponibile, u trafficu ci và. Naturalmente, ùn avemu micca cache quì, i.e. hè friddu, ma almenu e dumande di l'utilizatori sò trattate. S'ellu hè un cortu intervallu, allora l'avemu sperienze completamente tranquillamente. Ci hè solu più carica nantu à u almacenamentu. Se questu intervallu hè longu, allora pudemu digià piglià una decisione - per sguassà stu servitore da a mappa o micca, o forse rimpiazzà cù un altru.
Questu hè u sistema di caching. Fighjemu i risultati.
Sembra chì ùn ci hè nunda di complicatu quì. Ma stu metudu di gestisce a cache ci hà datu una freccia di u 98%. Quelli. Fora di sti 80 mila richieste per seconda, solu 1600 ghjunghjenu l'almacenamiento, è questu hè una carica cumplettamente normale, l'enduranu tranquillamente, avemu sempre una riserva.
Avemu postu questi servitori in trè di i nostri DC, è ricevutu trè punti di prisenza - Praga, Miami è Hong Kong.
Chì. sò più o menu localmente situati à ognunu di i nostri mercati di destinazione.
È cum'è un bonu bonu, avemu avutu stu proxy di caching, nantu à quale u CPU hè veramente inattivu, perchè ùn hè micca cusì necessariu per serve u cuntenutu. E quì, usendu NGINX + Lua, avemu implementatu assai logica utilitaria.
Per esempiu, pudemu sperimentà cù webp o jpeg progressiva (questi sò furmati muderni efficaci), vede cumu affetta u trafficu, piglià qualchi decisione, attivà per certi paesi, etc.; fate un ridimensionamentu dinamicu o tagliate e foto nantu à a mosca.
Questu hè un bonu casu d'utilizazione quandu, per esempiu, avete una applicazione mobile chì mostra e foto, è l'applicazione mobile ùn vole micca perdicà u CPU di u cliente per dumandà una grande foto è poi ridimensionà à una certa dimensione per spinghjala in a vista. Pudemu simpricimenti specificà dinamicamente certi paràmetri in l'URL cundizionale UPort, è a cache di foto resizerà a foto stessa. Comu regula, selezziunà a dimensione chì avemu fisicu nantu à u discu, u più vicinu pussibule à u dumandata, è u vende in coordenate specifiche.
A propositu, avemu fattu publicamente registrazioni video dispunibuli di l'ultimi cinque anni di a cunferenza di sviluppatori di sistemi d'alta carica. . Fighjate, amparà, sparte è abbonate .
Pudemu ancu aghjunghje assai logica di produttu quì. Per esempiu, pudemu aghjunghje diverse filigrane cù i paràmetri di l'URL, pudemu sfondate, sfocate o pixelate e foto. Questu hè quandu vulemu mustrà una foto di una persona, ma ùn vulemu mustrà a so faccia, questu funziona bè, tuttu hè implementatu quì.
Chì avemu avutu ? Avemu trè punti di prisenza, una bona tarifa di truccu, è à u stessu tempu ùn avemu micca CPU inattivu in queste macchine. Avà hè diventatu, sicuru, più impurtante chè prima. Avemu bisognu di dà vitture più forti, ma vale a pena.
Questu riguarda u ritornu di e fotografie. Tuttu quì hè abbastanza chjaru è evidenti. Pensu chì ùn aghju micca scupertu l'America, quasi ogni CDN funziona in questu modu.
E, assai prubabile, un ascultore sofisticatu puderia avè una quistione: perchè micca solu cambià tuttu à CDN? Saria da u listessu; tutti i CDN muderni ponu fà questu. È ci sò parechje ragioni.
U primu hè e fotografie.
Questu hè unu di i punti chjave di a nostra infrastruttura, è avemu bisognu di u più cuntrollu pussibule. S'ellu hè un tipu di suluzione da un venditore di terzu, è ùn avete micca un putere nantu à questu, serà abbastanza difficiule per voi di vive cun ellu quandu avete un grande dataset, è quandu avete un flussu assai grande. di e dumande di l'utilizatori.
Lasciami dà un esempiu. Avà, cù a nostra infrastruttura, pudemu, per esempiu, in casu di qualchì problema o colpi sottumessi, andate à a macchina è miss around there, relatively speaking. Pudemu aghjunghje a cullizzioni di qualchi metrica chì avemu solu bisognu, pudemu sperimentà di qualchì manera, vede cumu questu affetta i grafici, è cusì. Avà assai statistiche sò cullucate nantu à stu cluster di caching. È ci guardemu periodicamente è passemu assai tempu à esplorà alcune anomalie. S'ellu era in u latu CDN, saria assai più difficiuli di cuntrullà. O, per esempiu, s'ellu ci hè un accidentu, sapemu ciò chì hè accadutu, sapemu cumu campà cun ellu è cumu superà. Questa hè a prima cunclusione.
A seconda cunclusione hè ancu piuttostu storicu, perchè u sistema hè statu sviluppatu per un bellu pezzu, è ci era parechje esigenze di l'affari diffirenti in e diverse tappe, è ùn sò micca sempre adatti à u cuncettu CDN.
È u puntu chì seguita da u precedente hè
Questu hè chì nantu à i cache di foto avemu assai logica specifica, chì ùn pò micca sempre esse aghjuntu à dumanda. Hè improbabile chì qualsiasi CDN vi aghjunghje alcune cose persunalizate à a vostra dumanda. Per esempiu, criptu URL si ùn vulete micca chì u cliente pò cambià qualcosa. Vulete cambià l'URL in u servitore è criptate, è dopu mandate qualchi paràmetri dinamichi quì.
Chì cunclusione suggerisce questu? In u nostru casu, CDN ùn hè micca una alternativa assai bona.
È in u vostru casu, s'è vo avete ogni esigenza specifichi di l'affari, allora pudete facilmente implementà ciò chì vi aghju dimustratu. È questu travaglià perfettamente cù un prufilu di carica simili.
Ma s'è vo avete qualchi tipu di suluzione generale, è u compitu ùn hè micca assai specifichi, vi pò assulutamente sicuru piglià un CDN. O se u tempu è e risorse sò più impurtanti per voi chè u cuntrollu.
È i CDN muderni anu quasi tuttu ciò chì vi aghju dettu avà. Cù l'eccezzioni di più o minus alcune caratteristiche.
Il s'agit de donner des photos.
Avanzamu avà un pocu in a nostra retrospettiva è parlemu di almacenamiento.
2013 passava.
I servitori di cache sò stati aghjuntu, i prublemi di rendiment sò andati. Tuttu hè bè. Dataset hè in crescita. Da 2013, avemu avutu circa 80 servitori cunnessi à u almacenamiento, è circa 40 caching in ogni DC. Questu hè 560 terabytes di dati nantu à ogni DC, i.e. circa un petabyte in totale.
È cù a crescita di u dataset, i costi operativi cuminciaru à cresce significativamente. Chì significava questu?
In questu schema chì hè disegnatu - cù una SAN, cù machini è cache cunnessi à questu - ci sò assai punti di fallimentu. Sè avemu digià trattatu cù u fallimentu di i servitori di cache prima, tuttu era più o menu prevedibile è comprensibile, ma in u latu di almacenamiento tuttu era assai peggiu.
Prima, u Storage Area Network (SAN) stessu, chì pò fallu.
Siconda, hè cunnessu via otticu à e macchine finali. Ci ponu esse prublemi cù carte ottiche è spark plugs.
Di sicuru, ùn ci sò micca tanti di elli cum'è cù u SAN stessu, ma, però, sò ancu punti di fallimentu.
Dopu hè a macchina stessu, chì hè cunnessu à u almacenamiento. Pò ancu fallu.
In totale, avemu trè punti di fallimentu.
In più, in più di i punti di fallimentu, ci hè un mantenimentu pesante di l'almacenamiento stessu.
Questu hè un sistema cumplessu di cumpunenti multipli, è l'ingegneri di i sistemi ponu esse difficili di travaglià cun ellu.
È l'ultimu puntu, u più impurtante. Se un fallimentu si trova in qualcunu di sti trè punti, avemu una chance non-zero di perde i dati di l'utilizatori perchè u sistema di fugliale pò fallu.
Dicemu chì u nostru sistema di fugliale hè rottu. Prima, a so ricuperazione piglia assai tempu - pò piglià una settimana cù una grande quantità di dati. E in segundu, à a fine, avemu a più prubabile finisce cù una mansa di fugliali incomprensibili chì anu da esse cumminati in qualchì manera in e foto di l'utilizatori. È risichemu di perde dati. U risicu hè abbastanza altu. E più spessu si succèdenu tali situazioni, è più prublemi sò in questa catena intera, più altu hè u risicu.
Qualcosa avia da esse fattu nantu à questu. È avemu decisu chì avemu solu bisognu di salvezza di i dati. Questa hè veramente una suluzione ovvia è bona. Chì avemu fattu ?
Questu hè ciò chì u nostru servitore pareva quandu era cunnessu à l'almacenamiento prima. Questa hè una sezione principale, hè solu un dispositivu di bloccu chì in realtà rapprisenta una muntagna per l'almacenamiento remota via l'ottica.
Avemu appena aghjustatu una seconda sezione.
Pudemu un secondu almacenamentu vicinu à ellu (per furtuna, ùn hè micca cusì caru in termini di soldi), è l'hà chjamatu una partizione di salvezza. Hè ancu cunnessu via l'ottica è si trova nantu à a stessa macchina. Ma avemu bisognu di qualchì modu sincronizà e dati trà elli.
Quì simpricimenti facemu una fila asincrona vicinu.
Ùn hè micca assai occupata. Sapemu chì ùn avemu micca abbastanza dischi. Una fila hè solu una tavula in MySQL in quale linee cum'è "avete bisognu di fà una copia di salvezza di sta foto" sò scritte. Cù ogni cambiamentu o upload, copiemu da a partizione principale à a copia di salvezza utilizendu un asincronu o solu un tipu di travagliu di fondo.
È cusì avemu sempre duie sezioni cunsistenti. Ancu s'è una parte di stu sistema falla, pudemu sempre cambià a partizione principale cù una copia di salvezza, è tuttu hà da cuntinuà à travaglià.
Ma per quessa, a carica di lettura aumenta assai, perchè ... in più di i clienti chì leghjenu da a sezione principale, perchè prima guardanu a foto quì (hè più recente quì), è poi cercanu nantu à a copia di salvezza, s'ellu ùn l'anu micca trovu (ma NGINX solu fà questu), u nostru sistema hè dinù una copia di salvezza plus avà leghje da a particione principale. Ùn hè micca chì questu era un collu di buttiglia, ma ùn vulia micca aumentà a carica, essenzialmente, cusì cusì.
E avemu aghjustatu un terzu discu, chì hè un picculu SSD, è chjamatu un buffer.
Cumu travaglia avà.
L'utilizatore carica una foto in u buffer, dopu un avvenimentu hè ghjittatu in a fila chì indica chì deve esse copiatu in duie sezioni. Hè copiatu, è a photo vive nantu à u buffer per qualchì tempu (per dì, un ghjornu), è solu dopu hè purgatu da quì. Questu migliurà assai l'esperienza di l'utilizatori, perchè l'utilizatore carica una foto, in regula, e dumande cumincianu immediatamente à seguità, o ellu stessu aghjurnà a pagina è rinfriscata. Ma tuttu dipende di l'applicazione chì face a carica.
O, per esempiu, altre persone à quale ellu hà cuminciatu à mustrà subitu mandate dumande dopu à sta foto. Ùn hè micca ancu in u cache; a prima dumanda si trova assai rapidamente. Essenzialmente u listessu cum'è da una cache di foto. L'almacenamiento lento ùn hè micca implicatu in questu. È quandu un ghjornu dopu hè purgatu, hè digià in cache nantu à a nostra capa di caching, o, più prubabilmente, nimu hà più bisognu. Quelli. L'esperienza di l'utilizatori quì hè crisciutu assai bè per via di tali manipulazioni simplici.
Ebbè, è più impurtante: avemu firmatu perda dati.
Diciamu solu chì avemu firmatu potenzialmente perde dati, perchè ùn avemu micca veramente persu. Ma ci era periculu. Avemu vistu chì sta suluzione hè, sicuru, bona, ma hè un pocu cum'è alliscià i sintomi di u prublema, invece di risolve cumplettamente. È certi prublemi restanu quì.
Prima, questu hè un puntu di fallimentu in a forma di l'ospite fisicu stessu nantu à quale tutta sta machina funziona; ùn hè micca andatu.
Siconda, ci sò sempre prublemi cù SAN, u so mantenimentu pesante, etc. Ùn era micca chì era un fattore criticu, ma vulia pruvà à campà senza ellu.
E avemu fattu a terza versione (in fattu, a seconda in fattu) - a versione di riservazione. Chì pareva ?
Questu hè ciò chì era -
I nostri prublemi principali sò cù u fattu chì questu hè un host fisicu.
Prima, sguassemu SAN perchè vulemu sperimentà, vulemu pruvà solu i discu duru lucali.
Questu hè digià 2014-2015, è à quellu tempu a situazione cù i dischi è a so capacità in un òspite hè diventatu assai megliu. Avemu decisu perchè ùn pruvà micca.
E dopu avemu simpricimenti piglià a nostra particione di salvezza è trasfiriri fisicamenti lu in una macchina separata.
Cusì, avemu stu diagramma. Avemu dui vitture chì guardanu i stessi datasets. Si salvanu l'un l'altru cumplettamente è sincronizzanu e dati nantu à a reta attraversu una fila asincrona in u stessu MySQL.
Perchè questu funziona bè hè perchè avemu pochi records. Quelli. s'è a scrittura era paragunabili à a lettura, forse avemu avutu qualchì tipu di rete è prublemi. Ci hè pocu scrittu, assai lettura - stu metudu funziona bè, i.e. Copiemu raramente e foto trà sti dui servitori.
Cumu funziona stu travagliu, se cercate un pocu più in detail.
Caricà. L'equilibratore sceglie solu l'ospiti aleatorii cù una coppia è carica in questu. À u listessu tempu, naturalmente faci cuntrolli di salute è assicura chì a vittura ùn cascà micca. Quelli. carica foto solu à un servitore live, è dopu attraversu una fila asincrona hè tuttu copiatu à u so vicinu. Cù upload tuttu hè estremamente simplice.
U compitu hè un pocu più difficiule.
Lua ci hà aiutatu quì, perchè pò esse difficiule di fà una tale logica in vanilla NGINX. Facemu prima una dumanda à u primu servitore, vede s'ellu ci hè a foto, perchè potenzialmente puderia esse caricata, per esempiu, à un vicinu, ma ùn hè ancu ghjuntu quì. Se a foto hè quì, hè bè. Demu immediatamente à u cliente è, possibbilmente, cache.
S'ellu ùn hè micca quì, avemu solu fà una dumanda à u nostru vicinu è sò guarantiti di riceve da quì.
Chì. di novu pudemu dì: ci ponu esse prublemi cù u rendiment, perchè ci sò custanti andata - a foto hè stata caricata, ùn hè micca quì, facemu duie dumande invece di una, questu duverebbe travaglià lentamente.
In a nostra situazione, questu ùn viaghja micca lentamente.
Cullemu una mansa di metriche nantu à stu sistema, è a tarifa intelligente cundizionale di un tali mecanismu hè di circa 95%. Quelli. U ritardu di sta copia di salvezza hè chjuca, è per via di questu avemu quasi garantitu, dopu chì a foto hè stata caricata, avemu da piglià a prima volta è ùn duvemu micca andà in ogni locu duie volte.
Allora chì altru avemu chì hè veramente cool?
Prima, avemu avutu a partizione principale di salvezza, è avemu lettu da elli in sequenza. Quelli. Avemu sempre cercatu nantu à u principale prima, è dopu nantu à a copia di salvezza. Era una mossa.
Avà utilizemu a lettura da duie macchine à una volta. Distribuemu e dumande usendu Round Robin. In una piccula percentuale di casi facemu duie dumande. Ma in generale, avemu avà duie volte più scorte di lettura chè avemu avutu prima. È a carica hè stata ridutta assai nantu à e macchine di mandate è direttamente nantu à e macchine di almacenamento, chì avemu avutu ancu in quellu tempu.
In quantu à a tolleranza di colpa. In realtà, hè per quessa chì avemu luttatu principalmente. Cù a tolleranza à i difetti, tuttu hè statu bellu quì.
Una vittura si rompe.
Nisunu prublema! Un ingegnere di sistema ùn pò mancu svegliate di notte, aspittàrà finu à a matina, nunda di male ùn succederà.
Sè ancu s'è sta macchina falla, a fila hè fora di l'ordine, ùn ci hè micca prublemi ancu, u logu serà simpricimenti accumulatu prima nantu à a macchina vivente, è poi serà aghjuntu à a fila, è dopu à a vittura chì vi mette in opera dopu à qualchì tempu.
Stessa cosa cù u mantenimentu. Simpricamente spegnemu una di e macchine, tirà manualmente fora di tutte e piscine, smette di riceve u trafficu, facemu qualchì tipu di mantenimentu, editemu qualcosa, dopu turnemu à u serviziu, è sta copia di salvezza piglia abbastanza rapidamente. Quelli. per ghjornu, u tempu d'inattività di una vittura si mette in un paru di minuti. Questu hè veramente assai pocu. Cù a tolleranza di difetti, dicu novu, tuttu hè bellu quì.
Chì cunclusioni ponu esse tratte da stu schema di redundancy ?
Avemu a tolleranza à i difetti.
Facile à aduprà. Siccomu i machini anu discu duru lucali, questu hè assai più convenientu da un puntu di vista operativu per l'ingegneri chì travaglianu cun ellu.
Avemu ricevutu una doppia indennità di lettura.
Questu hè un bonu bonu in più di a tolleranza di difetti.
Ma ci sò ancu prublemi. Avà avemu un sviluppu assai più cumplessu di qualchi funziunalità ligata à questu, perchè u sistema hè diventatu 100% eventualmente coherente.
Duvemu, dì, in qualchì travagliu di fondo, pensanu constantemente: "Chì servitore avemu in esecuzione ora?", "Ci hè veramente una foto attuale quì?" ecc. Questu, sicuru, hè tuttu impannillatu, è per u programatore chì scrive a logica cummerciale, hè trasparente. Ma, però, stu grande stratu cumplessu hè apparsu. Ma simu pronti à mette cun questu in cambiu di i boni chì avemu ricevutu da ellu.
È quì dinò un cunflittu nasce.
Aghju dettu à u principiu chì l'almacenamiento di tuttu in i discu duru lucali hè male. È avà dicu chì ci hè piaciutu.
Iè, veramente, cù u tempu a situazione hà cambiatu assai, è avà stu approcciu hà assai vantaghji. Prima, avemu un funziunamentu assai più simplice.
Siconda, hè più produtivu, perchè ùn avemu micca questi cuntrolli automatichi o cunnessione à i scaffali di discu.
Ci hè una quantità enorme di machini quì, è questi sò solu uni pochi di discu chì sò assemblati quì nantu à a macchina in un raid.
Ma ci sò ancu disadvantages.
Questu hè circa 1,5 volte più caru chè l'usu di SAN ancu à i prezzi di l'oghje. Dunque, avemu decisu di ùn cunvertisce audacemente u nostru grande cluster in vitture cù discu duru lucali è decisu di lascià una soluzione hibrida.
A mità di i nostri machini travaglianu cù discu duru (bene, micca a mità - probabilmente 30 per centu). È u restu sò vechji vitture chì anu avutu u schema di prima riservazione. Avemu simpricimenti rimontatu, postu chì ùn avemu micca bisognu di novi dati o di qualcosa altru, simpricimenti movemu i monti da un ospite fisicu à dui.
È avemu avà un grande stock di lettura, è l'avemu allargatu. Se prima avemu muntatu un almacenamentu in una macchina, ora muntemu quattru, per esempiu, nantu à un paru. È funziona bè.
Facemu un brevi riassuntu di ciò chì avemu fattu, ciò chì avemu luttatu, è se avemu successu.
Risultati
Avemu utilizatori - quant'è 33 milioni.
Avemu trè punti di prisenza - Praga, Miami, Hong Kong.
Contenenu una capa di caching, chì hè custituita di vitture cù dischi lucali veloci (SSD), nantu à quale una machina simplice da NGINX, u so access.log è i demoni di Python currianu, chì processanu tuttu questu è gestionenu a cache.
Se vulete, site in u vostru prughjettu, se e foto ùn sò micca cusì critiche per voi cum'è per noi, o se u cuntrollu di u scambiu versus a velocità di sviluppu è i costi di risorse hè in l'altra direzione per voi, allora pudete rimpiazzà in modu sicuru. cù un CDN, i CDN muderni facenu bè.
Dopu vene a capa di almacenamento, nantu à quale avemu clusters di coppie di macchine chì si salvanu l'una di l'altra, i schedari sò copiati in modu asincronu da unu à l'altru ogni volta chì cambianu.
Inoltre, alcune di queste macchine travaglianu cù discu duru lucali.
Alcune di sti machini sò cunnessi à SAN.
È, da una banda, hè più còmuda d'utilizà è un pocu più pruduttivu, da l'altra banda, hè cunvenutu in quantu à a densità di piazzamentu è u prezzu per gigabyte.
Questa hè una breve panoramica di l'architettura di ciò chì avemu avutu è cumu si sviluppau tuttu.
Uni pochi di più cunsiglii da u capitanu, assai simplici.
Prima, se decide di colpu chì avete bisognu urgente di migliurà tuttu in a vostra infrastruttura di foto, misurate prima, perchè forsi nunda ùn deve esse migliuratu.
Lasciami dà un esempiu. Avemu un gruppu di machini chì manda foto da annessi in chats, è u schema hè travagliatu quì da u 2009, è nimu ùn soffre. Tutti sò bè, tutti li piace tuttu.
Per misurà, prima appiccà una mansa di metriche, fighjate, è poi decide ciò chì site infelice è ciò chì deve esse migliuratu. Per misurà questu, avemu un strumentu cool chjamatu Pinba.
Permette di cullà statistiche assai dettagliate da NGINX per ogni dumanda è codici di risposta, è distribuzione di i tempi - ciò chì vulete. Havi ligami à ogni tipu di sistemi analitici diffirenti, è poi pudete vede tuttu bè.
Prima l'avemu misuratu, dopu l'avemu migliuratu.
In più. Ottimisimu a lettura cù cache, scrittura cù sharding, ma questu hè un puntu evidenti.
In più. Sè vo site ghjustu avà principiatu à custruisce u vostru sistema, allura hè assai megliu à fà foto cum'è schedari immutable. Perchè subitu perde una classe sana di prublemi cù l'invalidazione di cache, cù cumu a logica deve truvà a versione curretta di a foto, è cusì.
Dicemu chì avete caricatu un centu, poi giratu, fate cusì chì era un schedariu fisicamente diversu. Quelli. ùn ci hè bisognu di pensà: avà risparmià un pocu spaziu, scrivite in u stessu schedariu, cambia a versione. Questu ùn viaghja micca sempre bè è causa assai mal di testa dopu.
U prossimu puntu. Circa ridimensionà nantu à a mosca.
Prima, quandu l'utilizatori caricavanu una foto, avemu tagliatu immediatamente un saccu di dimensioni per tutte l'occasioni, per diversi clienti, è eranu tutti nantu à u discu. Avà avemu abbandunatu questu.
Avemu lasciatu solu trè dimensioni principali: chjuca, mediana è grande. Simplicemu riduzzione di tuttu u restu da a dimensione chì hè daretu à quellu chì ci hè statu dumandatu à noi in Uport, simpricimenti facemu u downscale è dà à l'utilizatore.
U CPU di a capa di caching quì risulta esse assai più prezzu chè s'è avemu rigeneratu constantemente queste dimensioni nantu à ogni almacenamentu. Diciamu chì vulemu aghjunghje un novu, questu duverà un mesi - eseguisce un script in ogni locu chì faria tuttu questu pulitu, senza distrughje u cluster. Quelli. Sè vo avete l'uppurtunità di sceglie avà, hè megliu per fà quant'è pocu dimensioni fisiche pussibule, ma cusì chì almenu una distribuzione hè, per dì, trè. È tuttu u restu pò esse ridimensionatu solu nantu à a mosca usendu moduli pronti. Hè tuttu assai faciule è accessibile avà.
È a copia di salvezza asincrona incrementale hè bona.
Comu a nostra pratica hà dimustratu, stu schema funziona bè cù a copia ritardata di i schedarii cambiati.
L'ultimu puntu hè ancu evidenti. Se a vostra infrastruttura ùn hà micca tali prublemi avà, ma ci hè qualcosa chì pò rompe, certamenti si romperà quandu diventa un pocu più. Per quessa, hè megliu pensà à questu in anticipu è ùn sperienze prublemi cun ellu. Hè tuttu ciò chì vulia dì.
contatti
»
»
Stu rapportu hè una trascrizione di unu di i migliori discorsi in a cunferenza di sviluppatori di sistemi d'alta carica . Ci hè menu di un mesi finu à a cunferenza HighLoad++ 2017.
L'avemu digià pronta , u calendariu hè avà attivamente furmatu.
Quist'annu cuntinuemu à spiegà u tema di l'architettura è a scala:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Filippu Delgado
Avemu ancu aduprà alcuni di sti materiali in u nostru cursu di furmazione in linea nantu à u sviluppu di sistemi di alta carica hè una catena di lettere, articuli, materiali, video selezziunati apposta. U nostru libru di testu cuntene digià più di 30 materiali unichi. Cunnette!
Source: www.habr.com