Artem Denisov ( , )
Badoo je največje spletno mesto za zmenke na svetu. Trenutno imamo približno 330 milijonov registriranih uporabnikov po vsem svetu. Kar pa je v kontekstu najinega današnjega pogovora veliko bolj pomembno, je, da hranimo približno 3 petabajte uporabniških fotografij. Vsak dan naši uporabniki naložijo približno 3,5 milijona novih fotografij, obremenitev pri branju pa je približno 80 tisoč zahtevkov na sekundo. To je precej za naše zaledje in včasih so s tem težave.
Govoril bom o zasnovi tega sistema, ki shranjuje in pošilja fotografije na splošno, in pogledal ga bom z vidika razvijalca. Sledila bo kratka retrospektiva razvoja, kjer bom orisal glavne mejnike, podrobneje pa bom spregovoril le o rešitvah, ki jih trenutno uporabljamo.
Zdaj pa začnimo.
Kot rečeno, to bo retrospektiva in da bi jo nekje začeli, vzemimo najpogostejši primer.
Imamo skupno nalogo, moramo sprejemati, shranjevati in pošiljati fotografije uporabnikov. V tej obliki je naloga splošna, uporabimo lahko karkoli:
- sodobno shranjevanje v oblaku,
- škatlasta rešitev, ki jih je zdaj tudi veliko;
- V našem podatkovnem centru lahko postavimo več strojev in nanje namestimo velike trde diske ter shranimo fotografije.
Badoo zgodovinsko gledano - tako zdaj kot nekoč (v času, ko je bil šele v povojih) - živi na svojih strežnikih, znotraj naših lastnih DC-jev. Zato je bila ta možnost za nas optimalna.
Pravkar smo vzeli več strojev, jih poimenovali "fotografije", in dobili smo gručo, ki shranjuje fotografije. A zdi se, kot da nekaj manjka. Da bi vse to delovalo, moramo nekako določiti, na kateri stroj bomo hranili katere fotografije. In tudi tu ni treba odpirati Amerike.
V našo shrambo dodamo nekaj polj s podatki o uporabnikih. To bo ključ za razčlenjevanje. V našem primeru smo ga poimenovali place_id in ta id mesta kaže na mesto, kjer so shranjene fotografije uporabnikov. Izdelujemo zemljevide.
Na prvi stopnji je to mogoče celo ročno - pravimo, da bo fotografija tega uporabnika s takšnim mestom pristala na takem strežniku. Zahvaljujoč temu zemljevidu vedno vemo, kdaj uporabnik naloži fotografijo, kje jo shraniti, in vemo, od kod jo dati.
To je popolnoma trivialna shema, vendar ima precej pomembne prednosti. Prvi je, da je preprost, kot sem rekel, drugi pa je, da lahko s tem pristopom enostavno vodoravno povečamo tako, da preprosto dostavimo nove avtomobile in jih dodamo na zemljevid. Ničesar drugega ti ni treba narediti.
Tako je bilo nekaj časa pri nas.
To je bilo okoli leta 2009. Dostavili so avtomobile, dostavili ...
In na neki točki smo začeli opažati, da ima ta shema določene pomanjkljivosti. Kakšne so slabosti?
Najprej je omejena zmogljivost. Na en fizični strežnik ne moremo stlačiti toliko trdih diskov, kot bi si želeli. In to je sčasoma in z rastjo nabora podatkov postalo določen problem.
In drugo. Gre za netipično konfiguracijo strojev, saj je takšne stroje težko ponovno uporabiti v kakšnih drugih gručih, so precej specifični, tj. morali bi biti šibki v zmogljivosti, a hkrati z velikim trdim diskom.
To je bilo vse za leto 2009, načeloma pa so te zahteve aktualne še danes. Imamo retrospektivo, torej leta 2009 je bilo s tem vse čisto slabo.
In zadnja točka je cena.
Cena je bila takrat zelo visoka in morali smo iskati nekaj alternativ. Tisti. morali smo nekako bolje izkoristiti tako prostor v podatkovnih centrih kot fizične strežnike, na katerih se vse to nahaja. In naši sistemski inženirji so začeli veliko študijo, v kateri so pregledali kup različnih možnosti. Ogledali so si tudi datotečne sisteme v gručah, kot sta PolyCeph in Luster. Prišlo je do težav pri delovanju in precej težavnem delovanju. Zavrnili so. Poskušali smo namestiti celoten nabor podatkov prek NFS na vsak avto, da bi ga nekako povečali. Tudi branje je šlo slabo, preizkušali smo različne rešitve različnih prodajalcev.
In na koncu smo se odločili za uporabo tako imenovanega Storage Area Network.
To so veliki SHD-ji, ki so posebej zasnovani za shranjevanje velikih količin podatkov. So police z diski, ki so nameščeni na končne optične izhodne stroje. to. imamo nekakšen nabor strojev, precej majhen, in ti SHD-ji, ki so pregledni za našo logiko pošiljanja, tj. za naš nginx ali kogarkoli drugega, ki bo služil zahtevam za te fotografije.
Ta odločitev je imela očitne prednosti. To je SHD. Namenjen je shranjevanju fotografij. To je ceneje kot preprosto opremljanje strojev s trdimi diski.
Drugi plus.
To je, da je zmogljivost postala veliko večja, tj. lahko sprejmemo veliko več prostora za shranjevanje v veliko manjši prostornini.
Bile pa so tudi slabosti, ki so se pokazale precej hitro. Ko sta število uporabnikov in obremenitev tega sistema rasla, so se začele pojavljati težave z delovanjem. In težava je tukaj precej očitna - vsak SHD, zasnovan za shranjevanje številnih fotografij v majhnem obsegu, praviloma trpi zaradi intenzivnega branja. To dejansko velja za katero koli shrambo v oblaku ali karkoli drugega. Zdaj nimamo idealnega pomnilnika, ki bi bil neskončno razširljiv, vanj bi lahko stlačili karkoli in bi zelo dobro prenašal branja. Še posebej priložnostna branja.
Tako kot pri naših fotografijah, saj se fotografije zahtevajo nedosledno, kar bo močno vplivalo na njihovo uspešnost.
Tudi po današnjih številkah, če dobimo nekje več kot 500 RPS za fotografije na stroju, na katerega je priključen pomnilnik, se težave že začnejo. In bilo nam je dovolj hudo, saj število uporabnikov raste, stvari bodo šle samo na slabše. To je treba nekako optimizirati.
Da bi optimizirali, smo se takrat seveda odločili, da pogledamo profil obremenitve - kaj se na splošno dogaja, kaj je treba optimizirati.
In tukaj vse igra v naše roke.
V prvem diapozitivu sem že povedal: imamo 80 tisoč zahtev za branje na sekundo s samo 3,5 milijoni nalaganja na dan. Se pravi, to je razlika treh velikosti. Očitno je, da je treba branje optimizirati in praktično je jasno, kako.
Obstaja še ena majhna točka. Posebnosti storitve so takšne, da se oseba registrira, naloži fotografijo, nato začne aktivno gledati druge ljudi, jih všečkati in se aktivno prikazuje drugim ljudem. Potem najde partnerja ali pa ne najde partnerja, odvisno kako se izide, in za nekaj časa preneha uporabljati storitev. V tem trenutku, ko ga uporablja, so njegove fotografije zelo vroče - povpraševanje je po njih, veliko ljudi si jih ogleda. Takoj, ko preneha s tem, zelo hitro preneha biti tako izpostavljen drugim ljudem, kot je bil prej, in skoraj nikoli ne zahtevajo njegovih fotografij.
Tisti. Imamo zelo majhen nabor vročih podatkov. Toda hkrati je veliko prošenj zanj. In povsem očitna rešitev tukaj je dodajanje predpomnilnika.
Predpomnilnik z LRU bo rešil vse naše težave. Kaj počnemo?
Pred našo veliko gručo s shrambo dodamo še enega razmeroma majhnega, ki mu rečemo photocaches. To je v bistvu le proxy za predpomnjenje.
Kako deluje od znotraj? Tukaj je naš uporabnik, tukaj je shramba. Vse je isto kot prej. Kaj dodamo vmes?
Je le stroj s fizičnim lokalnim diskom, ki je hiter. To je na primer s SSD. In na tem disku je shranjen nekakšen lokalni predpomnilnik.
Kako izgleda? Uporabnik pošlje zahtevo za fotografijo. NGINX ga najprej poišče v lokalnem predpomnilniku. Če ne, potem preprosto proxy_pass v našo shrambo, prenesite fotografijo od tam in jo dajte uporabniku.
A ta je zelo banalen in ni jasno, kaj se notri dogaja. Deluje nekako takole.
Predpomnilnik je logično razdeljen na tri plasti. Ko rečem »tri plasti«, to ne pomeni, da obstaja nekakšen zapleten sistem. Ne, to so pogojno le trije imeniki v datotečnem sistemu:
- To je medpomnilnik, kamor gredo fotografije, ki so bile pravkar prenesene iz proxyja.
- To je vroč predpomnilnik, ki shranjuje trenutno aktivno zahtevane fotografije.
- In hladen predpomnilnik, kjer se fotografije postopoma potisnejo iz vročega predpomnilnika, ko nanje pride manj zahtev.
Da bi to delovalo, moramo nekako upravljati s tem predpomnilnikom, preurediti moramo fotografije v njem itd. To je tudi zelo primitiven postopek.
Nginx preprosto zapiše v RAMDisk access.log za vsako zahtevo, v kateri navede pot do fotografije, ki jo je trenutno stregel (seveda relativna pot), in katero particijo je stregel. Tisti. lahko piše "fotografija 1" in nato medpomnilnik, vroč predpomnilnik, hladni predpomnilnik ali proxy.
Glede na to se moramo nekako odločiti, kaj narediti s fotografijo.
Na vsakem stroju imamo majhen demon, ki nenehno bere ta dnevnik in v svoj pomnilnik shranjuje statistične podatke o uporabi določenih fotografij.
Tam preprosto zbira, hrani števce in občasno naredi naslednje. Aktivno zahtevane fotografije, za katere je veliko zahtev, premakne v vroč predpomnilnik, kjer koli so.
Fotografije, ki so redko zahtevane in so postale manj pogosto zahtevane, se postopoma potiskajo iz vročega predpomnilnika v hladnega.
In ko nam zmanjka prostora v predpomnilniku, preprosto začnemo brez razlikovanja brisati vse iz hladnega predpomnilnika. In mimogrede, to dobro deluje.
Da se fotografija takoj shrani ob posredovanju v medpomnilnik, uporabimo direktivo proxy_store in tudi medpomnilnik je RAMDisk, tj. za uporabnika deluje zelo hitro. To zadeva notranjost samega strežnika za predpomnjenje.
Preostalo vprašanje je, kako porazdeliti zahteve po teh strežnikih.
Recimo, da obstaja gruča dvajsetih pomnilniških strojev in treh predpomnjenih strežnikov (tako se je zgodilo).
Nekako moramo določiti, katere zahteve so za katere fotografije in kje jih pristati.
Najpogostejša možnost je Round Robin. Ali pa to storite po naključju?
To ima očitno številne pomanjkljivosti, ker bi v takšni situaciji predpomnilnik uporabljali zelo neučinkovito. Zahteve bodo pristale na nekaterih naključnih strojih: tukaj so bile shranjene v predpomnilniku, na naslednjem pa jih ni več. In če bo vse to delovalo, bo zelo slabo. Tudi z majhnim številom strojev v gruči.
Moramo nekako nedvoumno določiti, kateri strežnik naj sprejme katero zahtevo.
Obstaja banalen način. Zgoščeno vrednost vzamemo iz URL-ja ali zgoščeno vrednost iz našega ključa za razčlenjevanje, ki je v URL-ju, in ga delimo s številom strežnikov. Bo delovalo? Volja.
Tisti. Imamo 2-odstotno zahtevo, na primer za nek "example_url" bo vedno pristal na strežniku z indeksom "XNUMX", predpomnilnik pa bo nenehno odstranjen, kolikor je le mogoče.
Toda v takšni shemi obstaja težava z reshardingom. Resharding – mislim na spreminjanje števila strežnikov.
Predpostavimo, da naša predpomnilniška gruča ne zmore več in se odločimo, da dodamo še en stroj.
Dodajmo.
Zdaj je vse deljivo ne s tri, ampak s štirimi. Tako skoraj vsi ključi, ki smo jih imeli, skoraj vsi URL-ji zdaj živijo na drugih strežnikih. Celoten predpomnilnik je bil samo za trenutek razveljavljen. Vse zahteve so padle na naš skladiščni grozd, slabo počutje, napake v storitvi in nezadovoljni uporabniki. Nočem tega narediti.
Tudi ta možnost nam ne ustreza.
to. kaj naj storimo? Nekako moramo učinkovito uporabljati predpomnilnik, isto zahtevo vedno znova pristati na istem strežniku, vendar biti odporni na ponovno razdeljevanje. In taka rešitev obstaja, ni tako zapletena. Imenuje se dosledno zgoščevanje.
Kako izgleda?
Vzamemo neko funkcijo iz ključa za razčlenjevanje in vse njene vrednosti razširimo na krog. Tisti. v točki 0 se njegove najmanjše in največje vrednosti konvergirajo. Nato vse naše strežnike postavimo v isti krog na približno ta način:
Vsak strežnik je definiran z eno točko in sektor, ki gre v smeri urinega kazalca do njega, ustrezno streže ta gostitelj. Ko pridejo zahteve do nas, takoj vidimo, da je na primer zahteva A - tam ima hash - in jo streže strežnik 2. Zahteva B - strežnik 3. In tako naprej.
Kaj se zgodi v tej situaciji med ponovnim delitvijo?
Ne razveljavimo celotnega predpomnilnika kot prej in ne premaknemo vseh ključev, ampak premaknemo vsak sektor na kratko, tako da se, relativno gledano, naš šesti strežnik, ki ga želimo dodati, prilega prostemu prostoru in ga dodamo tja.
Seveda se v taki situaciji izmaknejo tudi ključi. Vendar se odselijo veliko šibkejši kot prej. In vidimo, da sta naša prva dva ključa ostala na svojih strežnikih, strežnik za predpomnjenje pa se je spremenil samo za zadnji ključ. To deluje precej učinkovito in če postopoma dodajate nove gostitelje, tukaj ni večjih težav. Dodajate in dodajate po malem, počakate, da se predpomnilnik spet napolni, in vse deluje dobro.
Edino vprašanje ostaja pri zavrnitvah. Predpostavimo, da je kakšen avto v okvari.
In v tem trenutku res ne bi želeli ponovno generirati tega zemljevida, razveljaviti dela predpomnilnika in tako naprej, če bi na primer stroj znova zagnali in bi morali nekako servisirati zahteve. Preprosto hranimo en varnostni predpomnilnik fotografij na vsakem mestu, ki deluje kot zamenjava za kateri koli računalnik, ki trenutno ne deluje. In če nenadoma eden od naših strežnikov postane nedosegljiv, gre promet tja. Seveda tam nimamo predpomnilnika, tj. mrzlo je, a se vsaj obdelujejo zahteve uporabnikov. Če je to kratek interval, potem ga doživljamo povsem umirjeno. Večja je obremenitev prostora za shranjevanje. Če je ta interval dolg, potem se že lahko odločimo - odstraniti ta strežnik z zemljevida ali ne ali ga morda zamenjati z drugim.
Tu gre za sistem predpomnjenja. Poglejmo rezultate.
Zdi se, da tukaj ni nič zapletenega. Toda ta način upravljanja predpomnilnika nam je dal približno 98-odstotno stopnjo zvijač. Tisti. od teh 80 tisoč zahtev na sekundo jih le 1600 doseže shrambo, in to je povsem normalna obremenitev, mirno jo prenašajo, vedno imamo rezervo.
Te strežnike smo postavili v tri naše DC in prejeli tri točke prisotnosti – Praga, Miami in Hong Kong.
to. so bolj ali manj lokalno locirani na vsakem od naših ciljnih trgov.
In kot lep bonus smo dobili ta caching proxy, na katerem CPE dejansko miruje, ker ni tako potreben za serviranje vsebine. In tam smo z uporabo NGINX+ Lua implementirali veliko utilitarne logike.
Eksperimentiramo lahko na primer z webp ali progressive jpeg (to sta učinkoviti sodobni formati), vidimo, kako vpliva na promet, sprejmemo kakšne odločitve, omogočimo za določene države itd.; dinamično spreminjanje velikosti ali obrezovanje fotografij na letenju.
To je dober primer uporabe, ko imate na primer mobilno aplikacijo, ki prikazuje fotografije, in mobilna aplikacija ne želi zapravljati odjemalčevega CPE-ja za zahtevanje velike fotografije in nato spreminjanje velikosti na določeno velikost, da bi jo potisnili v pogled. Preprosto lahko dinamično določimo nekatere parametre v pogojnem URL-ju UPort in predpomnilnik fotografij bo sam spremenil velikost fotografije. Praviloma bo izbral velikost, ki jo fizično imamo na disku, čim bližje zahtevani, in jo znižal na določene koordinate.
Mimogrede, javno smo objavili video posnetke zadnjih petih let konference razvijalcev visokoobremenjenih sistemov . Glejte, učite se, delite in se naročite .
Tja lahko dodamo tudi veliko produktne logike. Dodamo lahko na primer različne vodne žige z uporabo parametrov URL-ja, fotografije lahko zabrišemo, zabrišemo ali piksliramo. To je, ko želimo pokazati fotografijo osebe, vendar ne želimo pokazati njenega obraza, to dobro deluje, vse je implementirano tukaj.
Kaj smo dobili? Dobili smo tri točke prisotnosti, dobro stopnjo trikov, hkrati pa na teh strojih nimamo nedejavnega procesorja. Zdaj je seveda postal pomembnejši kot prej. Moramo si dati močnejše avtomobile, a je vredno.
To zadeva vračilo fotografij. Tukaj je vse precej jasno in očitno. Mislim, da Amerike nisem odkril, skoraj vsak CDN deluje tako.
In najverjetneje bo prefinjeni poslušalec morda imel vprašanje: zakaj ne bi vsega preprosto spremenili v CDN? Bilo bi približno enako; to zmorejo vsi sodobni CDN-ji. In obstaja več razlogov.
Prvi so fotografije.
To je ena ključnih točk naše infrastrukture in nad njo potrebujemo čim večji nadzor. Če je to nekakšna rešitev drugega proizvajalca in nad njo nimate nobene moči, boste s tem precej težko živeli, ko imate velik nabor podatkov in ko imate zelo velik pretok zahtev uporabnikov.
Naj vam povem primer. Zdaj, z našo infrastrukturo, lahko, na primer, v primeru kakšnih težav ali podzemnih udarcev, gremo do stroja in tam, relativno rečeno, zamotimo. Dodamo lahko zbirko nekaterih meritev, ki jih samo potrebujemo, lahko nekako eksperimentiramo, vidimo, kako to vpliva na grafe itd. Zdaj se na tej gruči predpomnjenja zbira veliko statističnih podatkov. Občasno ga opazujemo in dolgo časa raziskujemo nekatere anomalije. Če bi bil na strani CDN, bi ga bilo veliko težje nadzorovati. Ali pa na primer, če se zgodi kakšna nesreča, vemo, kaj se je zgodilo, vemo, kako s tem živeti in kako to premagati. To je prvi sklep.
Tudi drugi zaključek je precej zgodovinski, saj se je sistem razvijal dolgo časa in na različnih stopnjah je bilo veliko različnih poslovnih zahtev, ki se ne ujemajo vedno s konceptom CDN.
In bistvo, ki izhaja iz prejšnjega, je
To je zato, ker imamo na predpomnilnikih fotografij veliko specifične logike, ki je ni mogoče vedno dodati na zahtevo. Malo verjetno je, da vam bo kateri koli CDN na vašo zahtevo dodal nekaj stvari po meri. Na primer šifriranje URL-jev, če ne želite, da odjemalec lahko nekaj spremeni. Ali želite spremeniti URL na strežniku in ga šifrirati ter nato sem poslati nekaj dinamičnih parametrov.
Kakšen zaključek nakazuje to? V našem primeru CDN ni zelo dobra alternativa.
In v vašem primeru, če imate kakšne specifične poslovne zahteve, potem lahko povsem enostavno izvedete to, kar sem vam pokazal, sami. In to bo odlično delovalo s podobnim profilom obremenitve.
Če pa imate neko splošno rešitev in naloga ni zelo specifična, lahko povsem varno vzamete CDN. Ali če so vam čas in viri pomembnejši od nadzora.
In sodobni CDN-ji imajo skoraj vse, o čemer sem vam zdaj povedal. Z izjemo plus ali minus nekaterih funkcij.
Tu gre za razdajanje fotografij.
Pojdimo zdaj malo naprej v našo retrospektivo in se pogovorimo o shranjevanju.
Leto 2013 je minilo.
Dodani so bili strežniki za predpomnjenje, težave z zmogljivostjo so izginile. Vse je vredu. Nabor podatkov raste. Od leta 2013 smo imeli približno 80 strežnikov, povezanih s shrambo, in približno 40 strežnikov za predpomnjenje v vsakem DC. To je 560 terabajtov podatkov na vsakem DC, tj. približno en petabajt skupaj.
In z rastjo nabora podatkov so stroški poslovanja začeli znatno naraščati. Kaj je to pomenilo?
V tem diagramu, ki je narisan - s SAN, z napravami in predpomnilniki, povezanimi z njim - je veliko točk napake. Če smo se že prej ukvarjali z odpovedjo predpomnjenja strežnikov, je bilo vse skupaj bolj ali manj predvidljivo in razumljivo, na pomnilniški strani pa je bilo vse veliko slabše.
Prvič, tu je samo Storage Area Network (SAN), ki lahko odpove.
Drugič, preko optike je povezan s končnimi stroji. Lahko pride do težav z optičnimi karticami in svečkami.
Seveda jih ni toliko kot pri samem SAN-u, a kljub temu so tudi to točke napake.
Sledi sam stroj, ki je povezan s skladiščem. Lahko tudi spodleti.
Skupaj imamo tri točke neuspeha.
Nadalje, poleg točk okvare, obstaja veliko vzdrževanje samega skladišča.
To je zapleten večkomponentni sistem in sistemski inženirji lahko težko delajo z njim.
In zadnja, najpomembnejša točka. Če pride do okvare na kateri koli od teh treh točk, imamo različno verjetnost, da izgubimo uporabniške podatke, ker se lahko datotečni sistem zruši.
Recimo, da je naš datotečni sistem pokvarjen. Prvič, njegovo obnavljanje traja dolgo - z veliko količino podatkov lahko traja teden dni. In drugič, na koncu bomo najverjetneje končali s kupom nerazumljivih datotek, ki jih bo treba nekako združiti v uporabniške fotografije. In tvegamo izgubo podatkov. Tveganje je precej veliko. In pogosteje ko se takšne situacije dogajajo in več težav se pojavlja v celotni tej verigi, večje je to tveganje.
Glede tega je bilo treba nekaj narediti. In odločili smo se, da moramo samo varnostno kopirati podatke. To je pravzaprav očitna rešitev in dobra. Kaj smo storili?
Takole je izgledal naš strežnik, ko je bil prej povezan s shrambo. To je en glavni del, je samo blok naprava, ki pravzaprav predstavlja nosilec za oddaljeno shranjevanje preko optike.
Pravkar smo dodali drugi del.
Zraven smo postavili drugo shrambo (na srečo denarno ni tako draga) in jo poimenovali rezervna particija. Prav tako je povezan preko optike in se nahaja na istem stroju. Moramo pa nekako sinhronizirati podatke med njimi.
Tukaj preprosto naredimo asinhrono čakalno vrsto v bližini.
Ni zelo zaposlena. Vemo, da nimamo dovolj evidenc. Čakalna vrsta je le tabela v MySQL, v kateri so zapisane vrstice, kot je "morate varnostno kopirati to fotografijo". Z vsako spremembo ali nalaganjem kopiramo iz glavne particije v varnostno kopijo z uporabo asinhronega ali samo neke vrste delavca v ozadju.
In tako imamo vedno dva dosledna dela. Tudi če en del tega sistema odpove, lahko vedno zamenjamo glavno particijo z varnostno kopijo in vse bo delovalo naprej.
A zaradi tega se bralna obremenitev močno poveča, saj... poleg strank, ki berejo iz glavnega dela, ker tam najprej pogledajo fotografijo (tam je novejša), nato pa jo poiščejo na varnostni kopiji, če je ne najdejo (NGINX pa samo to naredi), naš sistem je tudi plus backup zdaj bere iz glavne particije. Saj ne, da je bilo to ozko grlo, ampak obremenitve v bistvu nisem želel povečati kar tako.
In dodali smo tretji disk, ki je majhen SSD, in ga poimenovali medpomnilnik.
Kako zdaj deluje.
Uporabnik naloži fotografijo v medpomnilnik, nato pa se v čakalno vrsto vrže dogodek, ki nakazuje, da jo je treba kopirati v dva dela. Kopira se in fotografija nekaj časa (recimo en dan) živi v medpomnilniku in se šele nato izbriše od tam. To zelo izboljša uporabniško izkušnjo, saj uporabnik, ki naloži fotografijo, praviloma takoj začne slediti zahteve ali pa je sam posodobil stran in jo osvežil. Vendar je vse odvisno od aplikacije, ki izvaja nalaganje.
Ali na primer drugi ljudje, ki se jim je začel kazati, takoj pošljejo zahteve po tej fotografiji. Ni še v predpomnilniku, prva zahteva se zgodi zelo hitro. V bistvu enako kot iz predpomnilnika fotografij. Počasno shranjevanje pri tem sploh ni vključeno. In ko je dan kasneje očiščen, je že bodisi predpomnjen na našem sloju predpomnjenja ali pa ga najverjetneje nihče več ne potrebuje. Tisti. Uporabniška izkušnja je tukaj zelo zrasla zaradi tako preprostih manipulacij.
No, in kar je najpomembnejše: prenehali smo izgubljati podatke.
Recimo, da smo se ustavili potencialno izgubili podatke, ker jih v resnici nismo izgubili. Toda obstajala je nevarnost. Vidimo, da je ta rešitev seveda dobra, vendar je nekoliko podobna glajenju simptomov težave, namesto da bi jo popolnoma rešila. In tu ostaja nekaj težav.
Prvič, to je točka napake v obliki samega fizičnega gostitelja, na katerem teče vsa ta mašinerija; ni izginila.
Drugič, še vedno obstajajo težave s SAN-ji, njihovo težko vzdrževanje itd. Ni šlo za to, da je bil kritičen dejavnik, ampak želel sem poskusiti nekako živeti brez njega.
In naredili smo tretjo različico (pravzaprav drugo) - rezervacijsko. Kako je bilo videti?
To je bilo -
Naše glavne težave so v tem, da je to fizični gostitelj.
Prvič, odstranjujemo SAN-ove, ker želimo eksperimentirati, želimo poskusiti samo lokalne trde diske.
To je že 2014-2015 in takrat se je situacija z diski in njihovo kapaciteto v enem hostu bistveno izboljšala. Odločili smo se, zakaj ne bi poskusili.
Nato preprosto vzamemo rezervno particijo in jo fizično prenesemo na ločen stroj.
Tako dobimo ta diagram. Imamo dva avtomobila, ki hranita iste nize podatkov. Drug drugega v celoti varnostno kopirata in sinhronizirata podatke prek omrežja prek asinhrone čakalne vrste v istem MySQL.
To deluje dobro zato, ker imamo malo zapisov. Tisti. če bi bilo pisanje primerljivo z branjem, bi morda imeli kakšne omrežne stroške in težave. Piše se malo, bere se veliko – ta metoda dobro deluje, t.j. Redko kopiramo fotografije med tema dvema strežnikoma.
Kako to deluje, če pogledaš malo bolj podrobno.
Naloži. Uravnoteževalec preprosto izbere naključne gostitelje s parom in jih naloži. Obenem seveda opravlja zdravstvene preglede in poskrbi, da avto ne pade ven. Tisti. fotografije naloži samo na strežnik v živo, potem pa se preko asinhrone čakalne vrste vse to prekopira k sosedu. Z nalaganjem je vse izjemno preprosto.
Naloga je malo težja.
Tu nam je pomagal Lua, ker je lahko težko narediti takšno logiko na vanilla NGINX. Najprej naredimo zahtevo na prvi strežnik, pogledamo, ali je fotografija tam, ker bi jo potencialno lahko naložili na primer k sosedu, sem pa še ni prispela. Če je fotografija tam, je to dobro. Takoj jo damo stranki in po možnosti predpomnimo.
Če ga ni, enostavno pošljemo zahtevo sosedu in od tam ga bomo zagotovo prejeli.
to. spet lahko rečemo: lahko pride do težav z delovanjem, ker prihaja do stalnih povratnih potovanj - fotografija je bila naložena, ni je tukaj, postavljamo dve zahtevi namesto ene, to bi moralo delovati počasi.
V naših razmerah to ne gre počasi.
Na tem sistemu zbiramo kup metrik in pogojna pametna stopnja takega mehanizma je približno 95 %. Tisti. Zamik te varnostne kopije je majhen in zaradi tega smo skoraj zagotovljeni, da bomo fotografijo po nalaganju posneli prvič in nam ne bo treba nikamor dvakrat.
Torej, kaj še imamo, kar je res kul?
Prej smo imeli glavno rezervno particijo in smo brali z njih zaporedno. Tisti. Vedno smo najprej iskali na glavnem, potem pa na rezervnem. Bila je ena poteza.
Zdaj uporabljamo branje z dveh strojev hkrati. Zahteve distribuiramo z Round Robin. V majhnem odstotku primerov podamo dve zahtevi. Toda na splošno imamo zdaj dvakrat več bralskega fonda kot prej. In močno se je zmanjšala obremenitev tako na oddajnih strojih kot neposredno na skladiščnih strojih, ki smo jih takrat tudi imeli.
Kar se tiče tolerance napak. Pravzaprav smo se za to predvsem borili. S toleranco napak se je tukaj vse izkazalo odlično.
En avto se pokvari.
Brez problema! Sistemski inženir se ponoči morda sploh ne zbudi, počakal bo do jutra, nič hudega se ne bo zgodilo.
Če tudi če ta stroj odpove, je čakalna vrsta v okvari, tudi ni nobenih težav, preprosto se bo dnevnik najprej nabral na živi mašini, nato pa bo dodan v čakalno vrsto in nato naprej v avto, ki bo čez nekaj časa začne delovati.
Enako je z vzdrževanjem. Enostavno ugasnemo enega od strojev, ga ročno potegnemo iz vseh bazenov, neha prejemati prometa, naredimo nekakšno vzdrževanje, nekaj uredimo, potem ga vrnemo v servis in ta backup se kar hitro ujame. Tisti. na dan, izpad enega avtomobila nadoknadi v nekaj minutah. To je res zelo malo. S toleranco napak, ponavljam, tukaj je vse kul.
Kakšne sklepe je mogoče potegniti iz te sheme odpuščanja?
Imamo toleranco napak.
Enostaven za uporabo. Ker imajo stroji lokalne trde diske, je to veliko bolj priročno z operativnega vidika za inženirje, ki delajo z njim.
Dobili smo dvojni dodatek za branje.
To je zelo dober bonus poleg odpornosti na napake.
So pa tudi težave. Zdaj imamo veliko bolj zapleten razvoj nekaterih funkcij, povezanih s tem, ker je sistem sčasoma postal 100 % konsistenten.
Moramo, recimo, v nekem delu v ozadju nenehno razmišljati: "Na katerem strežniku zdaj delujemo?", "Je tukaj res trenutna fotografija?" itd. To je seveda vse zavito in za programerja, ki piše poslovno logiko, je pregledno. Toda kljub temu se je pojavila ta velika kompleksna plast. A to smo pripravljeni potrpeti v zameno za dobrote, ki smo jih od tega prejeli.
In tu se spet pojavi nek konflikt.
Na začetku sem rekel, da je shranjevanje vsega na lokalne trde diske slabo. In zdaj pravim, da nam je bilo všeč.
Da, res, sčasoma so se razmere zelo spremenile in zdaj ima ta pristop številne prednosti. Prvič, dobimo veliko preprostejše delovanje.
Drugič, bolj produktivno je, ker nimamo teh samodejnih krmilnikov ali povezav z diskovnimi policami.
Tam je ogromno strojev in to je le nekaj diskov, ki so tukaj na stroju sestavljeni v raid.
So pa tudi slabosti.
To je približno 1,5-krat dražje od uporabe SAN-jev tudi po današnjih cenah. Zato smo se odločili, da celotnega velikega grozda ne bomo pogumno predelali v avtomobile z lokalnimi trdimi diski in smo se odločili, da pustimo hibridno rešitev.
Polovica naših strojev deluje s trdimi diski (no, ne polovica – verjetno 30 odstotkov). Ostalo pa so stari avti, ki so prej imeli prvo rezervacijsko shemo. Enostavno smo jih namestili na novo, saj nismo potrebovali novih podatkov ali česa drugega, montaže smo preprosto prestavili z enega fizičnega gostitelja na dva.
In zdaj imamo veliko zalogo branja in smo jo razširili. Če smo prej na en stroj namestili eno shrambo, zdaj na en par namestimo na primer štiri. In dobro deluje.
Naj na kratko povzamemo, kaj nam je uspelo, za kaj smo se borili in ali nam je uspelo.
Rezultati
Imamo uporabnike – kar 33 milijonov.
Imamo tri točke prisotnosti - Praga, Miami, Hong Kong.
Vsebujejo predpomnilniško plast, ki jo sestavljajo avtomobili s hitrimi lokalnimi diski (SSD), na katerih tečejo enostavni stroji iz NGINX-a, njegov access.log in Python demoni, ki vse to procesirajo in upravljajo s predpomnilnikom.
Če želite, ste v svojem projektu, če fotografije za vas niso tako kritične kot za nas, ali če je nadzor kompromisa v primerjavi s hitrostjo razvoja in stroški virov v drugi smeri za vas, potem ga lahko varno zamenjate s CDN se sodobni CDN dobro obnesejo.
Sledi sloj za shranjevanje, na katerem imamo gruče parov strojev, ki medsebojno varnostno kopirajo, datoteke se asinhrono kopirajo iz enega v drugega, kadar koli se spremenijo.
Poleg tega nekateri od teh strojev delujejo z lokalnimi trdimi diski.
Nekateri od teh strojev so povezani s SAN-ji.
In po eni strani je bolj priročen za uporabo in nekoliko bolj produktiven, po drugi strani pa je priročen glede na gostoto namestitve in ceno na gigabajt.
To je tako kratek pregled arhitekture tega, kar smo dobili in kako se je vse razvilo.
Še nekaj nasvetov od kapitana, zelo preprostih.
Prvič, če se nenadoma odločite, da morate nujno izboljšati vse v svoji fotografski infrastrukturi, najprej izmerite, ker morda ni treba ničesar izboljšati.
Naj vam povem primer. Imamo gručo strojev, ki pošilja fotografije iz priponk v klepetih, in shema tam deluje od leta 2009 in nihče ne trpi zaradi tega. Vsi so v redu, vsi imajo radi vse.
Če želite meriti, najprej obesite kup meritev, si jih oglejte in se nato odločite, s čim niste zadovoljni in kaj je treba izboljšati. Da bi to izmerili, imamo kul orodje, imenovano Pinba.
Omogoča vam zbiranje zelo podrobnih statističnih podatkov iz NGINX za vsako kodo zahteve in odgovora ter porazdelitev časov – karkoli želite. Ima vezave na najrazličnejše analitične sisteme in potem lahko vse lepo pogledate.
Najprej smo ga izmerili, nato pa izboljšali.
Nadalje. Optimiziramo branje s predpomnilnikom, pisanje s sečenjem, vendar je to očitna točka.
Nadalje. Če šele začenjate graditi svoj sistem, potem je veliko bolje, da naredite fotografije kot nespremenljive datoteke. Ker takoj izgubite cel razred težav z razveljavitvijo predpomnilnika, s tem, kako naj logika najde pravo različico fotografije itd.
Recimo, da ste jih naložili sto, nato pa jih zavrteli, tako da je bila fizično drugačna datoteka. Tisti. ni treba razmišljati: zdaj bom prihranil malo prostora, zapisal v isto datoteko, spremenil različico. To vedno ne deluje dobro in pozneje povzroča veliko preglavic.
Naslednja točka. O spreminjanju velikosti na letenju.
Prej, ko so uporabniki naložili fotografijo, smo takoj izrezali cel kup velikosti za vse priložnosti, za različne naročnike in vse so bile na disku. Zdaj smo to opustili.
Pustili smo samo tri glavne velikosti: majhno, srednje in veliko. Vse ostalo preprosto zmanjšamo od velikosti, ki je za tisto, ki so nam jo zaprosili v Uportu, preprosto zmanjšamo in damo uporabniku.
Izkaže se, da je CPE sloja predpomnjenja veliko cenejši, kot če bi nenehno regenerirali te velikosti na vsakem pomnilniku. Recimo, da želimo dodati novega, to bo trajalo mesec dni - povsod zaženite skript, ki bi vse to naredil lepo, ne da bi uničil gručo. Tisti. Če imate zdaj možnost izbire, je bolje narediti čim manj fizičnih velikosti, vendar tako, da je vsaj neka distribucija recimo tri. In vse ostalo je mogoče preprosto sproti spreminjati s pomočjo že pripravljenih modulov. Zdaj je vse zelo enostavno in dostopno.
In inkrementalno asinhrono varnostno kopiranje je dobro.
Kot je pokazala naša praksa, ta shema odlično deluje pri zakasnjenem kopiranju spremenjenih datotek.
Zadnja točka je tudi očitna. Če vaša infrastruktura zdaj nima takšnih težav, vendar se lahko nekaj pokvari, se bo zagotovo zlomilo, ko bo tega malo več. Zato je bolje o tem razmišljati vnaprej in s tem ne imeti težav. To je vse, kar sem hotel povedati.
Stiki
»
»
To poročilo je prepis enega najboljših govorov na konferenci razvijalcev visokoobremenjenih sistemov . Do konference HighLoad++ 2017 je še manj kot mesec dni.
Imamo ga že pripravljenega , zdaj se urnik aktivno oblikuje.
Letos nadaljujemo z raziskovanjem teme arhitektur in skaliranja:
- / Igor Vasiljev
- / Dmitrij Egorov
- / Anatolij Plaskovski
- / Roman Šehovcov, Aleksej Gromatčikov
- / Filip Delgado
Nekatere od teh materialov uporabljamo tudi v našem spletnem tečaju usposabljanja o razvoju sistemov z visoko obremenitvijo je veriga posebej izbranih pisem, člankov, materialov, videov. Naš učbenik vsebuje že več kot 30 edinstvenih gradiv. Povežite se!
Vir: www.habr.com