Artem Denisov ( , )
Badoo munduko topaketa gunerik handiena da. Gaur egun 330 milioi erabiltzaile inguru ditugu erregistratuta mundu osoan. Baina gaur egun gure elkarrizketaren testuinguruan askoz ere garrantzitsuagoa dena da 3 petabyte inguru erabiltzaileen argazkiak gordetzen ditugula. Egunero gure erabiltzaileek 3,5 milioi argazki berri inguru kargatzen dituzte, eta irakurketa-karga ingurukoa da 80 mila eskaera segundoko. Hau asko da gure backendarentzat, eta batzuetan zailtasunak daude honekin.
Argazkiak oro har gordetzen eta bidaltzen dituen sistema honen diseinuaz hitz egingo dut eta garatzaile baten ikuspuntutik aztertuko dut. Nola garatu zenaren atzera begirako labur bat egingo da, non mugarri nagusiak azalduko ditudan, baina gaur egun erabiltzen ari garen irtenbideei buruz zehatzago hitz egingo dut.
Orain has gaitezen.
Esan bezala, hau atzera begirakoa izango da, eta nonbait hasteko, har dezagun adibiderik ohikoena.
Zeregin komun bat dugu, erabiltzaileen argazkiak onartu, gorde eta bidali behar ditugu. Forma honetan, zeregina orokorra da, edozer erabil dezakegu:
- hodeiko biltegiratze modernoa,
- kaxa-konponbide bat, orain ere asko daude;
- Gure datu-zentroan hainbat makina konfigura ditzakegu eta disko gogor handiak jarri eta bertan argazkiak gorde ditzakegu.
Badoo historikoki - orain zein orduan (hastapenean zegoen garaian) - bere zerbitzarietan bizi da, gure DC-en barruan. Horregatik, aukera hau egokiena zen guretzat.
Hainbat makina hartu besterik ez genuen egin, "argazkiak" deitu ziguten eta argazkiak gordetzen dituen kluster bat lortu genuen. Baina badirudi zerbait falta dela. Horrek guztiak funtziona dezan, nolabait zehaztu behar dugu zein makinatan zein argazki gordeko ditugun. Eta hemen ere ez dago Amerika ireki beharrik.
Erabiltzaileei buruzko informazioarekin eremu batzuk gehitzen ditugu gure biltegian. Hau izango da zatiketa-gakoa. Gure kasuan, place_id izena eman genion, eta lekuaren ID honek erabiltzaileen argazkiak gordetzen dituen lekua adierazten du. Mapak egiten ditugu.
Lehen fasean, eskuz ere egin daiteke - horrelako leku bat duen erabiltzaile honen argazki bat zerbitzari batean lehorreratuko dela esaten dugu. Mapa honi esker, beti dakigu erabiltzaile batek argazki bat noiz igotzen duen, non gorde behar den eta badakigu nondik eman.
Hau eskema guztiz hutsala da, baina abantaila nahiko esanguratsuak ditu. Lehenengoa sinplea dela, esan bezala, eta bigarrena, ikuspegi honekin erraz eskalatu dezakegula horizontalki auto berriak entregatu eta mapan gehituz. Ez duzu beste ezer egin behar.
Halaxe izan zen guretzat denbora batez.
Hau 2009 inguruan izan zen. Autoak entregatu zituzten, entregatu...
Eta momentu batean eskema honek zenbait desabantaila dituela nabaritzen hasi ginen. Zeintzuk dira desabantailak?
Lehenik eta behin, edukiera mugatua dago. Ezin ditugu nahi adina disko gogor sartu zerbitzari fisiko batean. Eta hori arazo jakin bat bihurtu da denborarekin eta datu-multzoaren hazkundearekin.
Eta bigarrena. Hau makinen konfigurazio atipikoa da, horrelako makinak zailak baitira beste zenbait klusteretan berrerabiltzea; nahiko zehatzak dira, hau da. errendimendu ahula izan behar dute, baina aldi berean disko gogor handi batekin.
Hau guztia 2009rako zen, baina, printzipioz, eskakizun horiek indarrean diraute gaur egun. Atzera begirakoa dugu, beraz, 2009an dena guztiz gaizki zegoen honekin.
Eta azken puntua prezioa da.
Prezioa oso altua zen garai hartan, eta alternatiba batzuk bilatu behar genituen. Horiek. nolabait hobeto aprobetxatu behar genuen bai datu-zentroetako espazioa bai hori guztia dagoen zerbitzari fisikoak. Eta gure sistemako ingeniariek azterketa handi bat hasi zuten eta bertan aukera ezberdin mordoa berrikusi zituzten. PolyCeph eta Luster bezalako fitxategi-sistema multzokatuak ere aztertu zituzten. Errendimendu arazoak eta funtzionamendu nahiko zaila zeuden. Ezezkoa eman zioten. Datu multzo osoa NFS bidez muntatzen saiatu gara auto bakoitzean, nolabait eskalatzeko. Irakurketa ere gaizki joan zen, saltzaile ezberdinen irtenbide desberdinak probatu genituen.
Eta azkenean, Storage Area Network delakoa erabiltzearekin finkatu ginen.
Datu kopuru handiak gordetzeko bereziki diseinatutako SHD handiak dira. Azken irteera optikoko makinetan muntatzen diren diskoak dituzten apalak dira. Hori. makina multzo bat dugu, nahiko txikia, eta SHD hauek, gure bidalketa logikarekiko gardenak, alegia. gure nginx edo beste edonork argazki hauen eskaerak egiteko.
Erabaki honek abantaila nabariak zituen. Hau SHD da. Argazkiak gordetzea du helburu. Honek makinak disko gogorrekin hornitzea baino merkeagoa da.
Bigarren plusa.
Hau da, ahalmena askoz handiagoa izan dela, hau da. askoz biltegiratze gehiago eduki dezakegu bolumen askoz txikiagoan.
Baina nahiko azkar agertu ziren desabantailak ere bazeuden. Sistema honen erabiltzaile kopurua eta karga hazi ahala, errendimendu arazoak sortzen hasi ziren. Eta hemen arazoa nahiko begi-bistakoa da: argazki asko bolumen txikian gordetzeko diseinatutako edozein SHDk, normalean, irakurketa intentsiboa jasaten du. Hau egia da hodeiko biltegiratze edo beste edozertarako. Orain ez dugu infinitu eskalagarria izango den biltegiratze aproposa, edozer gauza sartu dezakezu eta irakurketak oso ondo jasango lituzke. Batez ere kasualitatezko irakurketak.
Gure argazkiekin gertatzen den bezala, argazkiak koherentziarik gabe eskatzen direlako, eta horrek asko eragingo duelako haien errendimenduan.
Gaur egungo zifren arabera ere, nonbait 500 RPS baino gehiago lortzen baditugu biltegiratzea konektatuta dagoen makina batean argazkiak egiteko, arazoak hasten dira dagoeneko. Eta guretzat nahikoa txarra izan zen, erabiltzaile kopurua hazten ari delako, gauzak okerrera egingo dutelako. Hau nolabait optimizatu behar da.
Optimitzeko, orduan erabaki genuen, jakina, karga-profila aztertzea: zer gertatzen den, oro har, zer optimizatu behar den.
Eta hemen dena gure eskuetan jokatzen da.
Lehen diapositiban esan nuen jada: 80 mila irakurketa-eskaera ditugu segundoko egunean 3,5 milioi igoera baino ez direlarik. Hau da, hau hiru magnitude ordenako aldea da. Begi bistakoa da irakurketa optimizatu egin behar dela eta ia argi dago nola.
Puntu txiki bat gehiago dago. Zerbitzuaren berezitasunak pertsona bat erregistratu, argazki bat kargatzen du, gero beste pertsona batzuei aktiboki begiratzen hasten da, haiek bezala, eta aktiboki erakusten zaie beste pertsonei. Gero bikotekidea aurkitzen du edo ez du bikoterik aurkitzen, nola ateratzen den araberakoa da, eta zerbitzua erabiltzeari uzten dio denbora batez. Momentu honetan, erabiltzen duenean, bere argazkiak oso beroak dira - eskariak dira, jende askok ikusten ditu. Hori egiteari utzi bezain laster, nahiko azkar uzten du lehen bezain beste pertsona batzuekiko esposiziotik, eta bere argazkiak ez dira ia inoiz eskatzen.
Horiek. Datu multzo bero oso txikia dugu. Baina, aldi berean, eskaera asko daude harentzat. Eta irtenbide guztiz agerikoa hemen cache bat gehitzea da.
LRU duen cache batek gure arazo guztiak konponduko ditu. Zertan ari gara?
Biltegiratze duen gure multzo handiaren aurrean beste bat nahiko txiki bat gehitzen dugu, hau da, photocaches deritzona. Hau funtsean caching proxy bat besterik ez da.
Nola funtzionatzen du barrutik? Hona hemen gure erabiltzailea, hemen biltegia. Dena lehengo berdina da. Zer gehitzen dugu artean?
Disko lokal fisikoa duen makina bat besterik ez da, azkarra dena. Hau SSD batekin da, adibidez. Eta disko honetan tokiko cache motaren bat gordetzen da.
Nolakoa da? Erabiltzaileak argazki baten eskaera bidaltzen du. NGINX-ek tokiko cachean bilatzen du lehenik. Hala ez bada, proxy_pass gure biltegiratzera, deskargatu argazkia hortik eta eman erabiltzaileari.
Baina hau oso hutsala da eta ez dago argi zer gertatzen den barruan. Honelako zerbait funtzionatzen du.
Cachea logikoki hiru geruzatan banatuta dago. βHiru geruzaβ esaten dudanean, horrek ez du esan nahi nolabaiteko sistema konplexurik dagoenik. Ez, hauek baldintzapean fitxategi sistemako hiru direktorio besterik ez dira:
- Proxy batetik deskargatu berri diren argazkiak buffer bat da.
- Une honetan aktiboki eskatutako argazkiak gordetzen dituen cache beroa da.
- Eta cache hotza, non argazkiak pixkanaka-pixkanaka ateratzen diren cache berotik eskaera gutxiago iristen zaizkienean.
Honek funtziona dezan, nolabait kudeatu behar dugu cache hau, bertan dauden argazkiak berrantolatu behar ditugu, etab. Hau ere prozesu oso primitiboa da.
Nginx-ek RAMDisk access.log-era idazten du eskaera bakoitzeko, eta bertan zerbitzatzen duen argazkirako bidea adierazten du (bide erlatiboa, noski) eta zein partizio zerbitzatu den. Horiek. "Argazkia 1" esan dezake eta gero buffer bat, edo cache beroa, edo cache hotza edo proxy bat.
Horren arabera, nolabait argazkiarekin zer egin erabaki behar dugu.
Makina bakoitzean deabru txiki bat dugu martxan, erregistro hau etengabe irakurtzen duena eta argazki batzuen erabilerari buruzko estatistikak gordetzen dituena bere memorian.
Besterik gabe, bertan bildu, kontagailuak gordetzen ditu eta aldian-aldian honako hau egiten du. Eskatutako argazkiak aktiboki mugitzen ditu, eta horretarako eskaera asko daude, cache berora eramaten ditu, edonon dauden.
Gutxitan eskatzen diren eta gutxiagotan eskatu diren argazkiak cache berotik hotzera ateratzen dira pixkanaka.
Eta cachean lekurik gabe geratzen garenean, cache hotzeko dena ezabatzen hasten gara bereizi gabe. Eta, bide batez, honek ondo funtzionatzen du.
Bufferra proxy-ra bidalitakoan argazkia berehala gordetzeko, proxy_store zuzentaraua erabiltzen dugu eta bufferra ere RAMDisk bat da, hau da. erabiltzailearentzat oso azkar funtzionatzen du. Hau caching zerbitzariaren barnekoei dagokie.
Gainerako galdera zerbitzari hauetan eskaerak nola banatu da.
Demagun hogei biltegiratze-makina eta hiru caching zerbitzariz osatutako multzo bat dagoela (hala gertatu zen).
Nolabait zehaztu behar dugu zein eskaerak zein argazkitarako eta non lurreratu.
Aukerarik ohikoena Round Robin da. Edo ustekabean egin?
Honek, jakina, desabantaila batzuk ditu, egoera horretan cachea oso modu eraginkorrean erabiliko genukeelako. Eskaerak ausazko makina batzuetan lehorreratuko dira: hemen cachean zegoen, baina hurrengoan ez dago jada. Eta honek guztiak funtzionatzen badu, oso txarra izango da. Nahiz eta klusterrean makina kopuru txikia izan.
Nolabait anbiguoki zehaztu behar dugu zein zerbitzari zein eskaera lurreratu.
Modu hutsal bat dago. Hash-a URLtik edo hash-a gure sharding gakotik, URLan dagoena, hartzen dugu eta zerbitzari kopuruarekin zatitzen dugu. Lan egingo al da? Will.
Horiek. %2eko eskaera dugu, adibidez, "example_url" batzuentzat beti zerbitzarian lur hartuko du "XNUMX" indizearekin, eta cachea etengabe botako da ahalik eta ondoen.
Baina horrelako eskema batean birmoldaketarekin arazo bat dago. Birpartidatzea - ββzerbitzari kopurua aldatzea esan nahi dut.
Demagun gure caching clusterrak ezin duela aurre egin eta beste makina bat gehitzea erabakiko dugu.
Gehitu dezagun.
Orain dena zatigarria da hiruz ez, lauz baizik. Horrela, lehen genituen ia gako guztiak, ia URL guztiak gaur egun beste zerbitzarietan bizi dira. Cache osoa une batez baliogabetu zen. Eskaera guztiak gure biltegiratze-klusterean erori ziren, ondoezik geratu zen, zerbitzu-huts egin zen eta erabiltzaileak ez ziren pozik. Ez dut hori egin nahi.
Aukera hau ere ez zaigu egokitzen.
Hori. zer egin behar dugu? Nolabait, cachea modu eraginkorrean erabili behar dugu, eskaera bera zerbitzari berean behin eta berriro lurratu, baina birmoldaketari erresistenteak izan. Eta badago halako irtenbide bat, ez da hain konplikatua. Hashing koherentea deitzen zaio.
Zer itxura du honek?
Zatiketa gakotik funtzio batzuk hartzen ditugu eta bere balio guztiak zirkuluan zabaltzen ditugu. Horiek. 0 puntuan, bere balio minimoak eta maximoak bat egiten dute. Ondoren, gure zerbitzari guztiak zirkulu berean kokatuko ditugu gutxi gorabehera modu honetan:
Zerbitzari bakoitza puntu batek zehazten du, eta erlojuaren orratzen norantz doan sektorea, horren arabera, ostalari honek zerbitzatzen du. Eskaerak iristen zaizkigunean, berehala ikusten dugu, adibidez, A eskaera -hash bat dauka hor- eta 2. zerbitzariak zerbitzatzen duela. B eskaera - 3. zerbitzariak. Eta abar.
Zer gertatzen da egoera honetan birziklatze garaian?
Ez dugu cache osoa baliogabetzen, lehen bezala, eta ez ditugu gako guztiak mugitzen, baina sektore bakoitza distantzia laburrean mugitzen dugu, erlatiboki esanda, gehitu nahi dugun gure seigarren zerbitzaria espazio librean sar dadin, eta hor gehitzen dugu.
Jakina, halako egoera batean giltzak ere kanpora mugitzen dira. Baina lehen baino askoz ahulago ateratzen dira. Eta ikusten dugu gure lehen bi gakoak zerbitzarietan geratu zirela, eta caching zerbitzaria azken gakorako bakarrik aldatu zela. Honek nahiko modu eraginkorrean funtzionatzen du, eta ostalari berriak gehitzen badituzu pixkanaka, hemen ez dago arazo handirik. Pixka bat gehitu eta gehitzen duzu, itxaron cachea berriro bete arte eta dena ondo funtzionatzen du.
Galdera bakarra ukoekin geratzen da. Demagun auto motaren bat ez dagoela ordenatuta.
Eta ez genuke benetan mapa hau birsortu nahi momentu honetan, cachearen zati bat baliogabetu, eta abar, baldin, adibidez, makina berrabiarazi bada, eta nolabait zerbitzu eskaerak egin behar baditugu. Gune bakoitzean babeskopiko argazki-cache bat gordetzen dugu, une honetan hutsik dagoen edozein makinen ordezko gisa funtzionatzen duena. Eta bat-batean gure zerbitzariren bat erabilgarri geratzen ez bada, trafikoa hara doa. Berez, ez dugu hor cacherik, hau da. hotza egiten du, baina gutxienez erabiltzaileen eskaerak prozesatzen ari dira. Tarte laburra bada, erabat lasai bizi dugu. Biltegiratzean karga gehiago dago. Tarte hau luzea bada, orduan dagoeneko erabaki bat har dezakegu: zerbitzari hau mapatik kendu edo ez, edo agian beste batekin ordezkatu.
Hau cache-sistemari buruzkoa da. Ikus ditzagun emaitzak.
Badirudi hemen ez dagoela ezer konplikaturik. Baina cachea kudeatzeko metodo honek %98 inguruko trikimailu-tasa eman zigun. Horiek. segundoko 80 mila eskaera horietatik 1600 bakarrik iristen dira biltegiratzera, eta hau guztiz karga normala da, lasai jasaten dute, beti dugu erreserba.
Zerbitzari hauek gure hiru DCetan jarri genituen, eta hiru presentzia puntu jaso genituen: Praga, Miami eta Hong Kong.
Hori. gutxi gorabehera lokalean kokatzen dira gure xede-merkatu bakoitzean.
Eta bonus polit gisa, caching proxy hau lortu dugu, zeinaren gainean CPUa benetan inaktibo dagoen, edukia zerbitzatzeko hain beharrezkoa ez delako. Eta han, NGINX+ Lua erabiliz, logika utilitarista asko ezarri genuen.
Adibidez, webp edo jpeg progresiboarekin esperimentatu (formatu moderno eraginkorrak dira), trafikoari nola eragiten dion ikusi, erabaki batzuk hartu, zenbait herrialdetarako gaitu, etab.; egin tamaina aldatzeko dinamikoa edo moztu argazkiak hegan.
Hau erabilera egokia da, adibidez, argazkiak bistaratzen dituen mugikorrentzako aplikazio bat baduzu, eta mugikorreko aplikazioak ez du bezeroaren CPUa alferrik galdu nahi argazki handi bat eskatu eta gero tamaina jakin batera tamainaz aldatzeko. ikuspegia. Besterik gabe, dinamikoki zehaztu ditzakegu parametro batzuk UPort baldintzapeko URLan, eta argazkiaren cacheak argazkiaren tamaina aldatuko du. Oro har, diskoan fisikoki dugun tamaina hautatuko du, eskatutakotik ahalik eta hurbilen, eta koordenatu zehatzetan behera egingo du.
Bide batez, karga handiko sistemen garatzaileen konferentziaren azken bost urteetako bideo-grabaketak publikoki eskuragarri jarri ditugu. . Ikusi, ikasi, partekatu eta harpidetu .
Produktu-logika asko gehi ditzakegu bertan. Adibidez, URL parametroak erabiliz ur-marka desberdinak gehitu ditzakegu, argazkiak lausotu, lausotu edo pixelatu ditzakegu. Hau da pertsona baten argazkia erakutsi nahi dugunean, baina ez dugu bere aurpegia erakutsi nahi, honek ondo funtzionatzen du, dena hemen ezarrita dago.
Zer lortu dugu? Hiru presentzia puntu lortu ditugu, trikimailu-tasa ona, eta, aldi berean, ez dugu CPU inaktiborik makina hauetan. Orain, noski, lehen baino garrantzitsuagoa bihurtu da. Geure buruari auto indartsuagoak eman behar dizkiogu, baina merezi du.
Hau argazkiak itzultzeari dagokio. Hemen dena nahiko argia eta agerikoa da. Uste dut ez nuela Amerika deskubritu, ia edozein CDN funtzionatzen du horrela.
Eta, ziurrenik, entzule sofistikatu batek galdera bat izan dezake: zergatik ez aldatu dena CDNra? Berdin izango litzateke; CDN moderno guztiek egin dezakete hori. Eta hainbat arrazoi daude.
Lehenengoa argazkiak dira.
Hori da gure azpiegituren gakoetako bat, eta ahalik eta kontrol handiena behar dugu. Hirugarrenen hornitzaile baten irtenbidea bada, eta ez baduzu horren gaineko botererik, nahiko zaila izango zaizu horrekin bizitzea datu multzo handi bat duzunean eta fluxu oso handia duzunean. erabiltzaileen eskaerak.
Adibide bat jartzen dizut. Orain, gure azpiegiturarekin, adibidez, arazoren bat edo lurpeko kolpeen kasuan, makinara joan eta han inguruan nahastu, nahiko hitz eginez. Bakarrik behar ditugun metrika batzuen bilduma gehitu dezakegu, nolabait esperimentatu, honek grafikoetan nola eragiten duen ikusi eta abar. Orain estatistika asko biltzen ari dira caching kluster honetan. Eta aldian-aldian begiratzen dugu eta denbora luzea ematen dugu anomalia batzuk aztertzen. CDN aldean balego, askoz zailagoa izango litzateke kontrolatzea. Edo, adibidez, istripuren bat gertatzen bada, badakigu zer gertatu den, badakigu nola bizi eta nola gainditu. Hau da lehen ondorioa.
Bigarren ondorioa ere historiko samarra da, sistema denbora luzez garatzen ari delako, eta etapa ezberdinetan negozio-eskakizun asko zeuden, eta ez dira beti CDN kontzeptuan sartzen.
Eta aurrekotik datorren puntua da
Hau da, argazki-cacheetan logika espezifiko asko dugulako, eta hori ezin da beti eskatuta gehitu. Nekez da CDNren batek gauza pertsonalizatu batzuk gehitzea zure eskariz. Adibidez, URLak enkriptatzea nahi ez baduzu bezeroak zerbait aldatu ahal izatea. Zerbitzariko URLa aldatu eta enkriptatu nahi al duzu, eta, ondoren, parametro dinamiko batzuk bidali hemen.
Zein ondorio iradokitzen du honek? Gure kasuan, CDN ez da oso alternatiba ona.
Eta zure kasuan, negozio-eskakizun zehatzak badituzu, erakutsi dizudana erabat lasai ezar dezakezu. Eta honek ezin hobeto funtzionatuko du antzeko karga-profilarekin.
Baina irtenbide orokorren bat baduzu, eta zeregina oso zehatza ez bada, CDN bat guztiz seguru har dezakezu. Edo denbora eta baliabideak kontrola baino garrantzitsuago badira zuretzat.
Eta CDN modernoek orain kontatu dizudan ia guztia daukate. Funtzio batzuk plus edo minus izan ezik.
Hau argazkiak oparitzea da.
Goazen orain apur bat aurrera gure atzera begirakoan eta biltegiratzeari buruz hitz egin dezagun.
2013 pasatzen ari zen.
Caching zerbitzariak gehitu ziren, errendimendu arazoak desagertu ziren. Dena ondo dago. Datu multzoa hazten ari da. 2013tik aurrera, 80 zerbitzari inguru geneukan biltegiratzera konektatuta, eta 40 bat cachean DC bakoitzean. Hau DC bakoitzean 560 terabyte-ko datua da, hau da. petabyte inguru guztira.
Eta datu-multzoaren hazkundearekin, funtzionamendu-kostuak nabarmen igotzen hasi ziren. Zer esan nahi zuen honek?
Marrazten den diagrama honetan - SAN batekin, makinak eta cacheak harekin konektatuta - hutsegite puntu asko daude. Aurretik caching zerbitzarien hutsegiteari aurre egin bagenion, dena gutxi gorabehera aurreikusgarria eta ulergarria zen, baina biltegiratze aldetik dena askoz okerragoa zen.
Lehenik eta behin, biltegiratze eremuko sarea (SAN) bera, huts egin dezakeena.
Bigarrenik, optikaren bidez konektatzen da amaierako makinekin. Arazoak egon daitezke txartel optikoekin eta bujiekin.
Noski, ez daude SAN bera bezainbeste, baina, hala ere, porrot puntuak ere badira.
Ondoren, makina bera dago, biltegira konektatuta dagoena. Huts egin dezake ere.
Guztira, hiru porrot puntu ditugu.
Gainera, hutsegite puntuez gain, biltegiratze beraren mantentze-lan handia dago.
Osagai anitzeko sistema konplexua da eta sistemen ingeniariek zailtasunak izan ditzakete horrekin lan egitea.
Eta azken puntua, garrantzitsuena. Hiru puntu hauetako batean hutsegiteren bat gertatzen bada, erabiltzailearen datuak galtzeko aukera ez-zeroa dugu, fitxategi-sistema huts egin dezakeelako.
Demagun gure fitxategi-sistema hautsita dagoela. Lehenik eta behin, berreskuratzeak denbora asko behar du - aste bat iraun dezake datu kopuru handiarekin. Eta bigarrenik, azkenean, ziurrenik, erabiltzaileen argazkietan nolabait konbinatu beharko diren fitxategi ulertezin mordo batekin amaituko dugu. Eta datuak galtzeko arriskua dugu. Arriskua nahiko handia da. Eta zenbat eta maizago gertatu horrelako egoerak, eta zenbat eta arazo gehiago sortu kate osoan, orduan eta arrisku handiagoa.
Honen inguruan zerbait egin behar zen. Eta datuen babeskopia egin behar dugula erabaki genuen. Egia esan, irtenbide argia eta ona da. Zer egin dugu?
Hau da gure zerbitzariak biltegiratzera konektatuta zegoenean. Hau atal nagusi bat da, optikaren bidez urruneko biltegiratzeko muntaia adierazten duen bloke-gailu bat besterik ez da.
Bigarren atal bat gehitu berri dugu.
Bigarren biltegiratze bat jarri genuen ondoan (zorionez, ez da hain garestia diru aldetik), eta babeskopia partizioa deitu genion. Optikaren bidez ere konektatuta dago eta makina berean dago. Baina haien artean datuak nolabait sinkronizatu behar ditugu.
Hemen ilara asinkrono bat besterik ez dugu egiten inguruan.
Ez dago oso lanpetuta. Badakigu ez dugula nahikoa disko. Ilara bat MySQL-ko taula bat besterik ez da, non "argazki honen babeskopia egin behar duzu" bezalako lerroak idazten diren. Edozein aldaketa edo kargarekin, partizio nagusitik babeskopiara kopiatzen dugu asinkrono edo atzeko planoko langile bat erabiliz.
Eta horrela beti ditugu bi atal koherenteak. Sistema honen zati batek huts egiten badu ere, beti alda dezakegu partizio nagusia babeskopia batekin, eta denak funtzionatzen jarraituko du.
Baina horregatik, irakurketa-karga asko handitzen da, zeren... atal nagusitik irakurtzen duten bezeroez gain, lehenengo argazkia han begiratzen dutelako (bertan berriagoa da), eta gero babeskopian bilatzen dute, aurkitu ez badute (baina NGINXek hau besterik ez du egiten), gure sistema ere babeskopia gehigarria da orain partizio nagusitik irakurtzen dena. Ez da hori botila-lepoa zela, baina ez nuen karga handitu nahi, funtsean, horrela.
Eta hirugarren disko bat gehitu genuen, SSD txiki bat dena, eta buffer deitu genion.
Nola funtzionatzen duen orain.
Erabiltzaileak argazki bat kargatzen du bufferera, gero gertaera bat ilarara botatzen du bi ataletan kopiatu behar dela adieraziz. Kopiatu egiten da, eta argazkia bufferean bizi da denbora batez (esan, egun bat), eta orduan bakarrik garbitzen da hortik. Horrek asko hobetzen du erabiltzailearen esperientzia, erabiltzaileak argazki bat igotzen duelako, normalean, eskaerak berehala hasten direlako jarraitzen, edo berak orria eguneratu eta freskatu egiten duelako. Baina dena igoera egiten duen aplikazioaren araberakoa da.
Edo, adibidez, bere burua erakusten hasi zen beste pertsona batzuek berehala bidaltzen dituzte eskaerak argazki honen ondoren. Oraindik ez dago cachean; lehen eskaera oso azkar gertatzen da. Funtsean, argazki-cache bateko berdina. Biltegiratze geldoak ez du batere parte hartzen horretan. Eta egun bat beranduago purgatzen denean, dagoeneko cachean dago gure cache geruzan edo, ziurrenik, inork ez du gehiago behar. Horiek. Hemen erabiltzailearen esperientzia oso ondo hazi da manipulazio errazak direla eta.
Tira, eta garrantzitsuena: datuak galtzeari utzi genion.
Esan dezagun gelditu garela potentzialki datuak galtzea, benetan ez genuelako galdu. Baina arriskua zegoen. Konponbide hau, noski, ona dela ikusten dugu, baina arazoaren sintomak leuntzea bezalakoa da, guztiz konpondu beharrean. Eta arazo batzuk hemen geratzen dira.
Lehenik eta behin, makineria hori guztia exekutatzen den ostalari fisikoaren beraren porrot puntu bat da; ez da desagertu.
Bigarrenik, oraindik arazoak daude SANekin, haien mantentze-lan handiak, etab. Ez zen faktore kritikoa zela, baina hori gabe bizitzen saiatu nahi nuen nolabait.
Eta hirugarren bertsioa egin genuen (berez, bigarrena hain zuzen) - erreserba bertsioa. Nolakoa zen?
Hauxe izan zen -
Gure arazo nagusiak ostalari fisikoa izateak dira.
Lehenik eta behin, SANak kentzen ari gara esperimentatu nahi dugulako, tokiko disko gogorrak probatu nahi ditugulako.
Dagoeneko 2014-2015 da, eta garai hartan diskoen egoera eta ostalari bakarreko edukiera askoz hobetu zen. Zergatik ez probatu erabaki genuen.
Eta gero, besterik gabe, gure babeskopia partizioa hartu eta fisikoki beste makina batera transferituko dugu.
Horrela, diagrama hau lortuko dugu. Datu multzo berdinak gordetzen dituzten bi auto ditugu. Elkarren babeskopiak egiten dituzte guztiz eta datuak sarean sinkronizatzen dituzte MySQL berean ilara asinkrono baten bidez.
Honek ondo funtzionatzen duen zergatik disko gutxi ditugulako da. Horiek. idaztea irakurketaren parekoa izango balitz, agian sareko gainkostu eta arazoak izango genituzke. Idazketa gutxi dago, irakurketa asko - metodo honek ondo funtzionatzen du, hau da. Gutxitan kopiatzen ditugu argazkiak bi zerbitzari hauen artean.
Nola funtzionatzen du, xehetasun pixka bat gehiago begiratuz gero.
Kargatu. Balantzaileak bikote batekin ausazko ostalariak hautatzen ditu eta bertara kargatzen ditu. Aldi berean, berez egiten ditu osasun-kontrolak eta autoa ez dadin erortzen ziurtatzen du. Horiek. argazkiak zuzeneko zerbitzari batera bakarrik igotzen ditu, eta, ondoren, ilara asinkrono baten bidez bere bizilagunari kopiatzen zaio guztia. Kargatzean dena oso erraza da.
Zeregin apur bat zailagoa da.
Luak lagundu digu hemen, zaila izan baitaiteke vanilla NGINX-en halako logika egitea. Lehenik eta behin eskaera bat egiten diogu lehen zerbitzariari, ea argazkia hor dagoen, izan ere, potentzialki igo daitekeelako, adibidez, bizilagun bati, baina oraindik ez da hona iritsi. Argazkia hor badago, ona da. Berehala bezeroari ematen diogu eta, agian, cachean gordetzen dugu.
Bertan ez badago, gure auzokideari eskaera bat egiten diogu eta bertatik jasoko dugula bermatuta dago.
Hori. berriro esan dezakegu: errendimenduarekin arazoak egon daitezke, etengabeko joan-etorriak daudelako - argazkia igo zen, ez dago hemen, bi eskaera egiten ari gara baten ordez, honek poliki-poliki funtzionatu beharko luke.
Gure egoeran, honek ez du poliki-poliki funtzionatzen.
Sistema honetan neurketa mordoa biltzen dugu, eta mekanismo horren baldintza adimendunaren tasa % 95 ingurukoa da. Horiek. Babeskopia honen atzerapena txikia da, eta horregatik ia ziurtatuta daukagu, argazkia igo ondoren, lehenengo aldiz hartuko dugu eta ez dugu bi aldiz inora joan beharko.
Beraz, zer gehiago dugu benetan polita den?
Aurretik, babeskopia-partizio nagusia genuen, eta haietatik irakurtzen genuen sekuentzialki. Horiek. Beti nagusian bilatzen dugu lehenik, eta gero babeskopian. Mugimendu bat izan zen.
Orain bi makina batetik irakurtzen dugu aldi berean. Eskaerak Round Robin erabiliz banatzen ditugu. Kasuen ehuneko txiki batean bi eskaera egiten ditugu. Baina, oro har, orain lehen baino bi aldiz gehiago daukagu ββirakurketa stocka. Eta karga asko murrizten zen bai bidaltzeko makinetan eta baita zuzenean biltegiratzeko makinetan ere, garai hartan genuena.
Akatsen tolerantziari dagokionez. Egia esan, horregatik borrokatu genuen batez ere. Akatsen tolerantziarekin, dena bikain atera zen hemen.
Kotxe bat matxuratzen da.
Arazorik ez! Baliteke sistemaren ingeniari bat gauez esnatu ere ez izatea, goizera arte itxarongo du, ez da ezer txarrik gertatuko.
Makina honek huts egiten badu ere, ilara ez badago, arazorik ere ez badago, erregistroa lehenik bizidun makinan metatuko da, eta gero ilaran gehituko da, eta gero egingo duen autoan. denbora pixka bat igaro ondoren martxan jarri.
Mantenuarekin gauza bera. Besterik gabe, makinetako bat itzali dugu, eskuz ateratzen dugu igerileku guztietatik, trafikoa jasotzeari uzten dio, nolabaiteko mantentze-lanak egiten ditugu, zerbait editatzen dugu, gero zerbitzura itzultzen dugu eta segurtasun kopia hau nahiko azkar lortzen da. Horiek. egunean, auto baten geldialdiak minutu pare batean harrapatzen du. Hau benetan oso gutxi da. Akatsen tolerantziarekin, berriro diot, hemen dena polita dago.
Zer ondorio atera daitezke erredundantzia eskema honetatik?
Akatsen tolerantzia lortu dugu.
Erabiltzeko erraza. Makinek tokiko disko gogorrak dituztenez, hori askoz erosoagoa da ikuspuntu operatibotik harekin lan egiten duten ingeniarientzat.
Irakurketa bikoitza jaso genuen.
Hau oso bonus ona da akatsen tolerantziaz gain.
Baina arazoak ere badaude. Orain honekin lotutako ezaugarri batzuen garapen askoz konplexuagoa dugu, sistema %100ean koherente bihurtu delako azkenean.
Esan, atzeko lan batean, etengabe pentsatu behar dugu: "Zein zerbitzaritan ari gara exekutatzen?", "Benetan ba al dago oraingo argazkirik hemen?" etab. Hau, noski, dena bilduta dago, eta negozio-logika idazten duen programatzailearentzat gardena da. Baina, hala ere, geruza konplexu handi hori agertu da. Baina hori jasateko prest gaude bertatik jasotako onen truke.
Eta hemen berriro gatazka batzuk sortzen dira.
Hasieran esan nuen dena tokiko disko gogorretan gordetzea txarra dela. Eta orain diot gustatu zitzaigula.
Bai, egia esan, denborarekin egoera asko aldatu da, eta orain ikuspegi honek abantaila asko ditu. Lehenik eta behin, funtzionamendu askoz errazagoa lortzen dugu.
Bigarrenik, produktiboagoa da, ez ditugulako kontrolagailu automatiko hauek edo disko-apaletarako konexiorik.
Makineria kopuru handia dago bertan, eta hemen makinan raid batean muntatzen diren disko batzuk besterik ez dira.
Baina desabantailak ere badaude.
Hori gutxi gorabehera, SANak erabiltzea baino 1,5 aldiz garestiagoa da gaur egungo prezioetan ere. Hori dela eta, gure kluster handi osoa disko gogorrak dituzten autoetan ausardiaz ez bihurtzea erabaki genuen eta irtenbide hibrido bat uztea erabaki genuen.
Gure makinen erdiak disko gogorrekin funtzionatzen du (beno, ez erdia - ziurrenik ehuneko 30). Eta gainerakoak lehen erreserba eskema zuten auto zaharrak dira. Besterik gabe, berriro muntatu ditugu, datu berririk edo beste ezer behar ez genuenez, muntaiak ostalari fisiko batetik bitara eraman ditugu.
Eta orain irakurketa-bilketa handia dugu, eta zabaldu egin dugu. Lehen biltegiratze bat makina batean muntatzen bagenuen, orain lau muntatzen ditugu, adibidez, pare batean. Eta ondo funtzionatzen du.
Egin dezagun laburpen laburra zer lortu dugun, zeren alde borrokatu dugun eta lortu dugun ala ez.
Emaitzak
Erabiltzaileak ditugu: 33 milioi.
Hiru presentzia puntu ditugu: Praga, Miami, Hong Kong.
Caching geruza bat daukate, disko lokal azkarrak (SSD) dituzten autoek osatzen dutena, zeinetan NGINX-eko makineria sinplea, bere access.log eta Python deabruak exekutatzen diren, hau guztia prozesatu eta cachea kudeatzen dutenak.
Nahi baduzu, zure proiektuan zaude, argazkiak guretzat bezain garrantzitsuak ez badira zuretzako, edo garapen-abiaduraren eta baliabideen kostuen arteko truke-kontrola zuretzako beste norabide batean badago, segurtasunez ordezkatu dezakezu. CDN batekin, CDN modernoak ondo egiten dute.
Ondoren, biltegiratze geruza dator, eta bertan elkarren babeskopiak egiten dituzten makina bikote multzoak ditugu, fitxategiak modu asinkronoan kopiatzen dira batetik bestera aldatzen diren bakoitzean.
Gainera, makina horietako batzuk disko gogor lokalekin lan egiten dute.
Makina horietako batzuk SANetara konektatuta daude.
Eta, batetik, erabiltzeko erosoagoa eta apur bat emankorragoa da, bestetik, erosoa da kokapen-dentsitateari eta gigabyte bakoitzeko prezioari dagokionez.
Lortu dugunaren eta nola garatu den arkitekturaren ikuspegi laburra da hau.
Kapitainaren aholku batzuk gehiago, oso sinpleak.
Lehenik eta behin, bat-batean zure argazki-azpiegituran dena hobetu behar duzula premiazkoan erabakitzen baduzu, neurtu lehenik, agian ez baita ezer hobetu behar.
Adibide bat jartzen dizut. Txatetan eranskinetatik argazkiak bidaltzen dituen makina multzo bat dugu, eta eskema 2009az geroztik dago lanean, eta inork ez du sufritzen. Denak ondo daude, denei gustatzen zaie dena.
Neurtzeko, lehenik eta behin zintzilikatu metrika mordo bat, begiratu eta gero erabaki zerrekin ez zauden gustura eta zer hobetu behar den. Hori neurtzeko, Pinba izeneko tresna polita dugu.
Eskaera eta erantzun kode bakoitzerako NGINX-en estatistika oso zehatzak biltzeko aukera ematen du, eta denboraren banaketa - nahi duzuna. Era guztietako analisi-sistema ezberdinetarako loturak ditu, eta, ondoren, ederki begiratu dezakezu.
Lehenik neurtu genuen, gero hobetu genuen.
Aurrerago. Irakurketa cachearekin optimizatzen dugu, zatiketarekin idaztea, baina hori agerikoa da.
Aurrerago. Oraintxe zure sistema eraikitzen hasten bazara, askoz hobe da argazkiak fitxategi aldaezin gisa egitea. Cache baliogabetzearekin arazo klase osoa galtzen duzulako berehala, logikak argazkiaren bertsio zuzena nola aurkitu behar duen eta abarrekin.
Demagun ehun kargatu dituzula, gero biratu duzula, egin ezazu fisikoki beste fitxategi bat izan dadin. Horiek. Ez da pentsatu behar: orain leku apur bat aurreztuko dut, fitxategi berean idatzi, bertsioa aldatu. Honek beti ez du ondo funtzionatzen eta buruhauste asko eragiten ditu geroago.
Hurrengo puntua. Tamaina aldatzeari buruz.
Aurretik, erabiltzaileek argazki bat kargatzen zutenean, berehala moztu genuen neurri mordo bat une guztietarako, bezero ezberdinetarako, eta guztiak diskoan zeuden. Orain hori alde batera utzi dugu.
Hiru tamaina nagusi baino ez ditugu utzi: txikia, ertaina eta handia. Beste guztia Uport-en eskatu zigutenaren atzean dagoen tamainatik behera egiten dugu, besterik gabe, beherakada egin eta erabiltzaileari ematen diogu.
Hemen caching geruzaren CPUa askoz merkeagoa da biltegiratze bakoitzean tamaina hauek etengabe birsortuko bagenitu baino. Demagun berri bat gehitu nahi dugula, honek hilabete beharko du - exekutatu script bat nonahi, hori guztia txukun egingo lukeena, cluster-a suntsitu gabe. Horiek. Orain aukeratzeko aukera baduzu, hobe da ahalik eta tamaina fisiko gutxien egitea, baina banaketaren bat behintzat hirukoa izan dadin, demagun. Eta gainerako guztia hegan egin daiteke tamainaz aldatzeko prest dauden moduluak erabiliz. Orain oso erraza eta eskuragarria da guztia.
Eta babeskopia asinkrono inkrementala ona da.
Gure praktikak erakutsi duenez, eskema honek oso ondo funtzionatzen du aldatutako fitxategien kopia atzeratuarekin.
Azken puntua ere agerikoa da. Zure azpiegiturak ez baditu horrelako arazorik orain, baina apurtu daitekeen zerbait bada, zalantzarik gabe hautsi egingo da pixka bat gehiago bihurtzen denean. Hori dela eta, hobe da hau aldez aurretik pentsatzea eta arazorik ez izatea. Hori da esan nahi nuen guztia.
kontaktuak
Β»
Β»
Txosten hau karga handiko sistemen garatzaileen biltzarreko hitzaldi onenetako baten transkripzioa da . Hilabete baino gutxiago falta da HighLoad++ 2017 konferentziarako.
Dagoeneko prest daukagu , egitaraua aktiboki osatzen ari da orain.
Aurten arkitekturaren eta eskalatzearen gaia aztertzen jarraitzen dugu:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Karga handiko sistemak garatzeko lineako prestakuntza-ikastaroan ere erabiltzen ditugu material horietako batzuk bereziki hautatutako gutun, artikulu, material, bideoen kate bat da. Gure testuliburuak dagoeneko 30 material paregabe baino gehiago ditu. Konektatu!
Iturria: www.habr.com