Artem Denisov ( , )
Badoo is die wêreld se grootste afspraakwebwerf. Ons het tans sowat 330 miljoen geregistreerde gebruikers wêreldwyd. Maar wat baie belangriker is in die konteks van ons gesprek vandag, is dat ons ongeveer 3 petagrepe gebruikersfoto's stoor. Ons gebruikers laai elke dag ongeveer 3,5 miljoen nuwe foto's op, en die leeslading is omtrent 80 duisend versoeke per sekonde. Dit is nogal baie vir ons backend, en soms is daar probleme hiermee.
Ek sal praat oor die ontwerp van hierdie stelsel, wat foto's in die algemeen stoor en stuur, en ek sal daarna kyk vanuit 'n ontwikkelaar se oogpunt. Daar sal 'n kort terugblik wees oor hoe dit ontwikkel het, waar ek die hoofmylpale sal uiteensit, maar ek sal net in meer besonderhede praat oor die oplossings wat ons tans gebruik.
Kom ons begin nou.
Soos ek gesê het, sal dit 'n terugblik wees, en om dit iewers te begin, kom ons neem die mees algemene voorbeeld.
Ons het 'n gemeenskaplike taak, ons moet gebruikersfoto's aanvaar, stoor en stuur. In hierdie vorm is die taak algemeen, ons kan enigiets gebruik:
- moderne wolkberging,
- 'n boksoplossing, waarvan daar nou ook baie is;
- Ons kan verskeie masjiene in ons datasentrum opstel en groot hardeskywe daarop sit en foto's daar stoor.
Badoo woon histories - nou en dan (in die tyd toe dit net in sy kinderskoene was) - op sy eie bedieners, binne ons eie DC's. Daarom was hierdie opsie vir ons optimaal.
Ons het net verskeie masjiene geneem, dit "foto's" genoem, en ons het 'n groepie gekry wat foto's stoor. Maar dit lyk of iets skort. Om dit alles te laat werk, moet ons op een of ander manier bepaal op watter masjien ons watter foto's sal stoor. En ook hier is dit nie nodig om Amerika oop te maak nie.
Ons voeg 'n veld by ons berging met inligting oor gebruikers. Dit sal die skeursleutel wees. In ons geval het ons dit place_id genoem, en hierdie plek-ID wys na die plek waar gebruikersfoto's gestoor word. Ons maak kaarte.
In die eerste stadium kan dit selfs met die hand gedoen word - ons sê dat 'n foto van hierdie gebruiker met so 'n plek op so 'n bediener sal land. Danksy hierdie kaart weet ons altyd wanneer 'n gebruiker 'n foto oplaai, waar om dit te stoor, en ons weet waar om dit vandaan te gee.
Dit is 'n absoluut onbenullige skema, maar dit het aansienlike voordele. Die eerste is dat dit eenvoudig is, soos ek gesê het, en die tweede is dat ons met hierdie benadering maklik horisontaal kan skaal deur bloot nuwe motors af te lewer en dit by die kaart te voeg. Jy hoef niks anders te doen nie.
So was dit vir 'n geruime tyd vir ons.
Dit was om en by 2009. Hulle het karre afgelewer, afgelewer...
En op 'n stadium het ons begin agterkom dat hierdie skema sekere nadele het. Wat is die nadele?
Eerstens is daar beperkte kapasiteit. Ons kan nie soveel hardeskywe op een fisiese bediener inprop as wat ons wil nie. En dit het mettertyd 'n sekere probleem geword en met die groei van die datastel.
En tweedens. Dit is 'n atipiese konfigurasie van masjiene, aangesien sulke masjiene moeilik is om te hergebruik in sommige ander groepe hulle is redelik spesifiek, d.w.s. hulle behoort swak te wees in prestasie, maar terselfdertyd met 'n groot hardeskyf.
Dit was alles vir 2009, maar in beginsel is hierdie vereistes vandag steeds relevant. Ons het 'n terugskouing, so in 2009 was alles heeltemal sleg hiermee.
En die laaste punt is die prys.
Die prys was op daardie stadium baie hoog, en ons moes alternatiewe soek. Dié. ons moes op een of ander manier beide die spasie in die datasentrums en die fisiese bedieners waarop dit alles geleë is, beter benut. En ons stelselingenieurs het 'n groot studie begin waarin hulle 'n klomp verskillende opsies hersien het. Hulle het ook gekyk na gegroepeerde lêerstelsels soos PolyCeph en Luster. Daar was prestasieprobleme en nogal moeilike werking. Hulle het geweier. Ons het probeer om die hele datastel via NFS op elke motor te monteer om dit op een of ander manier op te skaal. Lees het ook swak gegaan, ons het verskillende oplossings van verskillende verskaffers probeer.
En op die ou end het ons besluit om die sogenaamde Storage Area Network te gebruik.
Dit is groot SHD's wat spesifiek ontwerp is vir die stoor van groot hoeveelhede data. Dit is rakke met skywe wat op die finale optiese uitsetmasjiene gemonteer is. Daardie. ons het 'n soort poel masjiene, redelik klein, en hierdie SHD's, wat deursigtig is vir ons stuurlogika, d.w.s. vir ons nginx of enigiemand anders om versoeke vir hierdie foto's te dien.
Hierdie besluit het ooglopende voordele ingehou. Dit is SHD. Dit is daarop gemik om foto's te stoor. Dit werk goedkoper uit as om bloot masjiene met hardeskywe toe te rus.
Tweede plus.
Dit is dat die kapasiteit baie groter geword het, m.a.w. ons kan baie meer berging in 'n baie kleiner volume akkommodeer.
Maar daar was ook nadele wat redelik vinnig na vore gekom het. Namate die aantal gebruikers en las op hierdie stelsel toegeneem het, het werkverrigtingprobleme begin ontstaan. En die probleem hier is redelik voor die hand liggend - enige SHD wat ontwerp is om baie foto's in 'n klein volume te stoor, ly as 'n reël aan intensiewe lees. Dit is eintlik waar vir enige wolkberging of enigiets anders. Nou het ons nie 'n ideale berging wat oneindig skaalbaar sou wees nie, jy kan enigiets daarin stop, en dit sal lesings baie goed verdra. Veral toevallige lesings.
Soos die geval is met ons foto's, want foto's word teenstrydig aangevra, en dit sal hul prestasie grootliks beïnvloed.
Selfs volgens vandag se syfers, as ons iewers meer as 500 RPS kry vir foto's op 'n masjien waaraan berging gekoppel is, begin probleme reeds. En dit was vir ons erg genoeg, want die aantal gebruikers groei, dinge gaan net erger word. Dit moet op een of ander manier geoptimaliseer word.
Om te optimaliseer, het ons op daardie tydstip natuurlik besluit om na die lasprofiel te kyk - wat oor die algemeen gebeur, wat moet geoptimaliseer word.
En hier speel alles in ons hande.
Ek het reeds in die eerste skyfie gesê: ons het 80 duisend leesversoeke per sekonde met slegs 3,5 miljoen oplaaie per dag. Dit wil sê, dit is 'n verskil van drie ordes van grootte. Dit is duidelik dat lees geoptimaliseer moet word en dit is prakties duidelik hoe.
Daar is nog een klein puntjie. Die besonderhede van die diens is sodanig dat 'n persoon registreer, 'n foto oplaai, dan aktief na ander mense begin kyk, soos hulle, en aktief aan ander mense gewys word. Dan kry hy 'n maat of kry hy nie 'n maat nie, dit hang af hoe dit uitdraai, en hou vir 'n rukkie op om die diens te gebruik. Op hierdie oomblik, wanneer hy dit gebruik, is sy foto's baie warm - dit is in aanvraag, baie mense sien dit. Sodra hy ophou om dit te doen, val hy redelik vinnig uit soveel blootstelling aan ander mense as wat hy voorheen gehad het, en sy foto's word amper nooit versoek nie.
Dié. Ons het 'n baie klein warm datastel. Maar terselfdertyd is daar baie versoeke vir hom. En 'n heeltemal voor die hand liggende oplossing hier is om 'n kas by te voeg.
'n Kas met LRU sal al ons probleme oplos. Wat doen ons?
Ons voeg nog 'n relatief klein een voor ons groot groepie met berging, wat fotocaches genoem word. Dit is in wese net 'n kasinstaanbediener.
Hoe werk dit van binne af? Hier is ons gebruiker, hier is berging. Alles is dieselfde as voorheen. Wat voeg ons tussenin by?
Dit is net 'n masjien met 'n fisiese plaaslike skyf, wat vinnig is. Dit is byvoorbeeld met 'n SSD. En 'n soort plaaslike kas word op hierdie skyf gestoor.
Soos wat lyk dit? Die gebruiker stuur 'n versoek vir 'n foto. NGINX soek dit eerste in die plaaslike kas. Indien nie, gee dan eenvoudig proxy_pass na ons berging, laai die foto van daar af en gee dit aan die gebruiker.
Maar hierdie een is baie banaal en dit is onduidelik wat binne gebeur. Dit werk so iets.
Die kas word logies in drie lae verdeel. As ek sê "drie lae", beteken dit nie dat daar 'n soort komplekse stelsel is nie. Nee, dit is voorwaardelik net drie dopgehou in die lêerstelsel:
- Dit is 'n buffer waarheen foto's wat pas vanaf 'n instaanbediener afgelaai is, gaan.
- Dit is 'n warm kas wat tans aktief versoekte foto's stoor.
- En 'n koue kas, waar foto's geleidelik uit die warm kas gestoot word wanneer minder versoeke na hulle toe kom.
Vir dit om te werk, moet ons op een of ander manier hierdie kas bestuur, ons moet die foto's daarin herrangskik, ens. Dit is ook 'n baie primitiewe proses.
Nginx skryf eenvoudig na die RAMDisk access.log vir elke versoek, waarin dit die pad na die foto aandui wat dit tans bedien het (relatiewe pad, natuurlik), en watter partisie dit bedien is. Dié. dit kan sê "foto 1" en dan of 'n buffer, of 'n warm kas, of 'n koue kas, of 'n proxy.
Na gelang hiervan moet ons op een of ander manier besluit wat om met die foto te doen.
Ons het 'n klein demoon wat op elke masjien loop wat voortdurend hierdie log lees en statistieke oor die gebruik van sekere foto's in sy geheue stoor.
Hy haal sommer daar af, hou die tellers en doen periodiek die volgende. Hy skuif aktief versoekte foto's, waarvoor daar baie versoeke is, na die warm kas, waar hulle ook al is.
Foto's wat selde aangevra word en minder gereeld aangevra word, word geleidelik uit die warm kas in die koue een gestoot.
En wanneer ons nie meer spasie in die kas het nie, begin ons eenvoudig alles uit die koue kas uitvee. En terloops, dit werk goed.
Ten einde die foto onmiddellik gestoor te word wanneer dit na die buffer gevolmagtig word, gebruik ons die proxy_store-aanwysing en die buffer is ook 'n RAMDisk, m.a.w. vir die gebruiker werk dit baie vinnig. Dit gaan oor die interne van die kasbediener self.
Die oorblywende vraag is hoe om versoeke oor hierdie bedieners te versprei.
Kom ons sê daar is 'n groep van twintig bergingsmasjiene en drie kasbedieners (dit is hoe dit gebeur het).
Ons moet op een of ander manier bepaal watter versoeke vir watter foto's is en waar om dit te land.
Die mees algemene opsie is Round Robin. Of doen dit per ongeluk?
Dit het natuurlik 'n aantal nadele, want ons sal die kas baie ondoeltreffend in so 'n situasie gebruik. Versoeke sal op 'n paar ewekansige masjiene beland: hier is dit gekas, maar op die volgende een is dit nie meer daar nie. En as dit alles werk, sal dit baie sleg wees. Selfs met 'n klein aantal masjiene in die groep.
Ons moet op een of ander manier ondubbelsinnig bepaal watter bediener watter versoek moet land.
Daar is 'n banale manier. Ons neem die hash van die URL of die hash van ons sharding-sleutel, wat in die URL is, en deel dit deur die aantal bedieners. Sal werk? Sal.
Dié. Ons het 'n 2% versoek, byvoorbeeld, vir 'n paar "voorbeeld_url" sal dit altyd op die bediener land met indeks "XNUMX", en die kas sal voortdurend so goed as moontlik van die hand gesit word.
Maar daar is 'n probleem met herharding in so 'n skema. Herharding - ek bedoel die verandering van die aantal bedieners.
Kom ons neem aan dat ons kasgroep nie meer kan klaarkom nie en ons besluit om nog 'n masjien by te voeg.
Kom ons voeg by.
Nou is alles heeltemal nie in drie verdeel nie, maar in vier. Dus, byna al die sleutels wat ons voorheen gehad het, is byna al die URL's nou op ander bedieners. Die hele kas is net vir 'n oomblik ongeldig gemaak. Alle versoeke het op ons bergingkluster geval, dit het sleg geword, diens mislukking en ontevrede gebruikers. Ek wil dit nie doen nie.
Hierdie opsie pas ook nie by ons nie.
Daardie. wat moet ons doen? Ons moet op een of ander manier die kas doeltreffend gebruik, dieselfde versoek oor en oor op dieselfde bediener land, maar weerstand teen herharding moet wees. En daar is so 'n oplossing, dit is nie so ingewikkeld nie. Dit word konsekwente hashing genoem.
Hoe lyk dit?
Ons neem 'n paar funksie van die skeursleutel en versprei al sy waardes op die sirkel. Dié. by punt 0 konvergeer sy minimum en maksimum waardes. Vervolgens plaas ons al ons bedieners op dieselfde sirkel op ongeveer hierdie manier:
Elke bediener word deur een punt gedefinieer, en die sektor wat kloksgewys daarna gaan, word dienooreenkomstig deur hierdie gasheer bedien. Wanneer versoeke na ons toe kom, sien ons dadelik dat, byvoorbeeld, versoek A - dit het 'n hash daar - en dit word bedien deur bediener 2. Versoek B - deur bediener 3. Ensovoorts.
Wat gebeur in hierdie situasie tydens herverwydering?
Ons maak nie die hele kas ongeldig, soos voorheen, en skuif nie al die sleutels nie, maar ons skuif elke sektor 'n kort afstand sodat, relatief gesproke, ons sesde bediener, wat ons wil byvoeg, in die vrye spasie pas, en ons voeg dit daar by.
Natuurlik, in so 'n situasie skuif die sleutels ook uit. Maar hulle beweeg baie swakker uit as voorheen. En ons sien dat ons eerste twee sleutels op hul bedieners gebly het, en die kasbediener het net vir die laaste sleutel verander. Dit werk redelik doeltreffend, en as u nuwe leërskare inkrementeel byvoeg, is daar geen groot probleem hier nie. Jy voeg 'n bietjie op 'n slag by en voeg by, wag totdat die kas weer vol is, en alles werk goed.
Die enigste vraag bly by weiering. Kom ons neem aan dat 'n soort motor buite werking is.
En ons sal nie regtig hierdie kaart op hierdie oomblik wil herskep nie, 'n deel van die kas ongeldig maak, ensovoorts, as, byvoorbeeld, die masjien herlaai is, en ons op een of ander manier diensversoeke moet doen nie. Ons hou eenvoudig een rugsteunfoto-kas op elke webwerf, wat dien as 'n plaasvervanger vir enige masjien wat tans af is. En as een van ons bedieners skielik onbeskikbaar raak, gaan die verkeer daarheen. Natuurlik het ons geen kas daar nie, m.a.w. dit is koud, maar ten minste word gebruikersversoeke verwerk. As dit 'n kort tussenpose is, dan ervaar ons dit heeltemal rustig. Daar is net meer las op berging. As hierdie interval lank is, kan ons reeds 'n besluit neem - om hierdie bediener van die kaart te verwyder of nie, of dalk met 'n ander te vervang.
Dit gaan oor die kasstelsel. Kom ons kyk na die resultate.
Dit wil voorkom asof hier niks ingewikkeld is nie. Maar hierdie metode om die kas te bestuur het ons 'n truukkoers van ongeveer 98% gegee. Dié. uit hierdie 80 duisend versoeke per sekonde bereik slegs 1600 berging, en dit is 'n heeltemal normale vrag, hulle verduur dit rustig, ons het altyd 'n reserwe.
Ons het hierdie bedieners in drie van ons DC's geplaas en drie punte van teenwoordigheid ontvang - Praag, Miami en Hong Kong.
Daardie. hulle is min of meer plaaslik geleë in elk van ons teikenmarkte.
En as 'n lekker bonus het ons hierdie kasinstaanbediener gekry, waarop die SVE eintlik ledig is, want dit is nie so nodig om inhoud te bedien nie. En daar, met behulp van NGINX+ Lua, het ons baie utilitaristiese logika geïmplementeer.
Ons kan byvoorbeeld eksperimenteer met webp of progressiewe jpeg (dit is effektiewe moderne formate), kyk hoe dit verkeer beïnvloed, sommige besluite neem, dit vir sekere lande aktiveer, ens.; maak 'n dinamiese grootteverandering of sny foto's dadelik.
Dit is 'n goeie gebruiksgeval wanneer jy byvoorbeeld 'n mobiele toepassing het wat foto's vertoon, en die mobiele toepassing wil nie die kliënt se SVE mors om 'n groot foto aan te vra en dit dan na 'n sekere grootte te verander om dit in te druk nie die uitsig. Ons kan sommige parameters eenvoudig dinamies spesifiseer in die UPort voorwaardelike URL, en die foto kas sal die grootte van die foto self verander. As 'n reël sal dit die grootte kies wat ons fisies op die skyf het, so na as moontlik aan die versoekte een, en dit in spesifieke koördinate verkoop.
Terloops, ons het video-opnames van die afgelope vyf jaar van die konferensie van ontwikkelaars van hoëladingstelsels in die openbaar beskikbaar gemaak . Kyk, leer, deel en teken in op .
Ons kan ook baie produklogika daarby voeg. Byvoorbeeld, ons kan verskillende watermerke byvoeg met behulp van URL-parameters, ons kan foto's vervaag, vervaag of pikseleer. Dit is wanneer ons 'n foto van 'n persoon wil wys, maar ons wil nie sy gesig wys nie, dit werk goed, dit is alles hier geïmplementeer.
Wat het ons gekry? Ons het drie punte van teenwoordigheid, 'n goeie truuktempo, en terselfdertyd het ons nie ledige SVE op hierdie masjiene nie. Hy het nou natuurlik belangriker as voorheen geword. Ons moet vir onsself sterker karre gee, maar dit is die moeite werd.
Dit gaan oor die terugstuur van foto's. Alles hier is baie duidelik en duidelik. Ek dink ek het nie Amerika ontdek nie, amper enige CDN werk so.
En, heel waarskynlik, kan 'n gesofistikeerde luisteraar 'n vraag hê: hoekom nie net alles na CDN verander nie? Dit sal omtrent dieselfde wees; alle moderne CDN's kan dit doen. En daar is 'n aantal redes.
Die eerste is foto's.
Dit is een van die sleutelpunte van ons infrastruktuur, en ons het soveel as moontlik beheer daaroor nodig. As dit 'n soort oplossing van 'n derdeparty-verskaffer is, en jy het geen mag daaroor nie, sal dit vir jou nogal moeilik wees om daarmee saam te leef as jy 'n groot datastel het en wanneer jy 'n baie groot vloei het. van gebruikersversoeke.
Kom ek gee vir jou 'n voorbeeld. Nou, met ons infrastruktuur, kan ons byvoorbeeld, in geval van probleme of ondergrondse stote, na die masjien gaan en daar rond mors, relatief gesproke. Ons kan die versameling van sommige maatstawwe byvoeg wat ons net nodig het, ons kan op een of ander manier eksperimenteer, sien hoe dit die grafieke beïnvloed, ensovoorts. Nou word baie statistieke oor hierdie kasgroepering ingesamel. En ons kyk gereeld daarna en spandeer 'n lang tyd om 'n paar afwykings te ondersoek. As dit aan die CDN-kant was, sou dit baie moeiliker wees om te beheer. Of, byvoorbeeld, as een of ander ongeluk plaasvind, weet ons wat gebeur het, ons weet hoe om daarmee saam te leef en hoe om dit te oorkom. Dit is die eerste gevolgtrekking.
Die tweede gevolgtrekking is ook taamlik histories, want die stelsel ontwikkel al lank, en daar was baie verskillende besigheidsvereistes op verskillende stadiums, en dit pas nie altyd by die CDN-konsep nie.
En die punt wat uit die vorige een volg is
Dit is omdat ons op fotokas baie spesifieke logika het, wat nie altyd op versoek bygevoeg kan word nie. Dit is onwaarskynlik dat enige CDN 'n paar persoonlike dinge by jou sal voeg op jou versoek. Byvoorbeeld, enkripteer URL's as jy nie wil hê die kliënt moet iets kan verander nie. Wil jy die URL op die bediener verander en dit enkripteer, en dan 'n paar dinamiese parameters hierheen stuur.
Watter gevolgtrekking stel dit voor? In ons geval is CDN nie 'n baie goeie alternatief nie.
En in jou geval, as jy enige spesifieke besigheidsvereistes het, dan kan jy redelik maklik implementeer wat ek jou gewys het self. En dit sal perfek werk met 'n soortgelyke lasprofiel.
Maar as jy 'n soort algemene oplossing het, en die taak is nie baie spesifiek nie, kan jy absoluut veilig 'n CDN neem. Of as tyd en hulpbronne vir jou belangriker is as beheer.
En moderne CDN's het byna alles waarvan ek jou nou vertel het. Met die uitsondering van plus of minus sommige kenmerke.
Dit gaan oor die weggee van foto's.
Kom ons beweeg nou 'n bietjie vorentoe in ons terugblik en praat oor berging.
2013 was verby.
Kasbedieners is bygevoeg, werkverrigtingprobleme het verdwyn. Alles is reg. Datastel groei. Vanaf 2013 het ons ongeveer 80 bedieners gehad wat aan berging gekoppel is, en ongeveer 40 cache in elke DC. Dit is 560 teragrepe data op elke DC, d.w.s. ongeveer 'n petagreep in totaal.
En met die groei van die datastel het bedryfskoste aansienlik begin styg. Wat het dit beteken?
In hierdie diagram wat geteken is - met 'n SAN, met masjiene en kas wat daaraan gekoppel is - is daar baie punte van mislukking. As ons al voorheen die mislukking van kasbedieners hanteer het, was alles min of meer voorspelbaar en verstaanbaar, maar aan die stoorkant was alles baie erger.
Eerstens, die Storage Area Network (SAN) self, wat kan misluk.
Tweedens word dit via optika aan die eindmasjiene gekoppel. Daar kan probleme met optiese kaarte en vonkproppe wees.
Daar is natuurlik nie soveel van hulle soos met die SAN self nie, maar dit is nietemin ook punte van mislukking.
Volgende is die masjien self, wat aan die stoor gekoppel is. Dit kan ook misluk.
In totaal het ons drie punte van mislukking.
Verder, benewens punte van mislukking, is daar swaar instandhouding van die stoor self.
Dit is 'n komplekse multi-komponent stelsel, en stelselingenieurs kan moeilik daarmee werk.
En die laaste, belangrikste punt. As enige van hierdie drie punte misluk, het ons 'n nie-nul kans om gebruikersdata te verloor omdat die lêerstelsel kan ineenstort.
Kom ons sê ons lêerstelsel is stukkend. Eerstens neem die herstel daarvan 'n lang tyd - dit kan 'n week neem met 'n groot hoeveelheid data. En tweedens, op die ou end sal ons heel waarskynlik met 'n klomp onverstaanbare lêers eindig wat op een of ander manier in gebruikersfoto's gekombineer sal moet word. En ons loop die risiko om data te verloor. Die risiko is redelik hoog. En hoe meer dikwels sulke situasies gebeur, en hoe meer probleme in hierdie hele ketting ontstaan, hoe groter is hierdie risiko.
Iets moes hieraan gedoen word. En ons het besluit dat ons net die data moet rugsteun. Dit is eintlik 'n voor die hand liggende oplossing en 'n goeie een. Wat het ons gedoen?
Dit is hoe ons bediener gelyk het toe dit voorheen aan berging gekoppel was. Dit is een hoofafdeling, dit is net 'n bloktoestel wat eintlik 'n bevestiging verteenwoordig vir afstandberging via optika.
Ons het sopas 'n tweede afdeling bygevoeg.
Ons het 'n tweede stoorplek langsaan geplaas (gelukkig is dit nie so duur in terme van geld nie), en het dit 'n rugsteunpartisie genoem. Dit is ook via optika verbind en is op dieselfde masjien geleë. Maar ons moet op een of ander manier die data tussen hulle sinchroniseer.
Hier maak ons eenvoudig 'n asynchrone tou naby.
Sy is nie baie besig nie. Ons weet ons het nie genoeg rekords nie. 'n Tou is net 'n tabel in MySQL waarin reëls soos "jy moet hierdie foto rugsteun" geskryf is. Met enige verandering of oplaai, kopieer ons van die hoofpartisie na rugsteun deur 'n asynchrone of net 'n soort agtergrondwerker te gebruik.
En dus het ons altyd twee konsekwente afdelings. Selfs as een deel van hierdie stelsel misluk, kan ons altyd die hoofpartisie verander met 'n rugsteun, en alles sal aanhou werk.
Maar as gevolg hiervan neem die leeslading baie toe, want... bykomend tot kliënte wat uit die hoofafdeling lees, want hulle kyk eers na die foto daar (dit is meer onlangs daar), en soek dit dan op die rugsteun, as hulle dit nie gevind het nie (maar NGINX doen dit net), ons stelsel is ook 'n plus rugsteun lees nou van die hoof partisie. Dit is nie dat dit 'n bottelnek was nie, maar ek wou nie die las in wese net so verhoog nie.
En ons het 'n derde skyf bygevoeg, wat 'n klein SSD is, en dit 'n buffer genoem.
Hoe dit nou werk.
Die gebruiker laai 'n foto op na die buffer, dan word 'n gebeurtenis in die tou gegooi wat aandui dat dit in twee afdelings gekopieer moet word. Dit word gekopieer, en die foto bly vir 'n geruime tyd op die buffer (sê 'n dag), en word dan eers van daar gesuiwer. Dit verbeter die gebruikerservaring aansienlik, want die gebruiker laai 'n foto op, as 'n reël begin versoeke onmiddellik volg, of hy het self die bladsy opgedateer en verfris. Maar dit hang alles af van die toepassing wat die oplaai maak.
Of, byvoorbeeld, ander mense aan wie hy homself begin wys het, stuur onmiddellik versoeke ná hierdie foto. Dit is nog nie in die kas nie; die eerste versoek vind baie vinnig plaas. In wese dieselfde as vanaf 'n fotokas. Stadige berging is glad nie hierby betrokke nie. En wanneer dit oor 'n dag gesuiwer word, is dit reeds óf op ons kaslaag gekas, óf, heel waarskynlik, het niemand dit meer nodig nie. Dié. Die gebruikerservaring hier het baie goed gegroei as gevolg van sulke eenvoudige manipulasies.
Wel, en die belangrikste: ons het opgehou om data te verloor.
Kom ons sê net ons het opgehou potensieel data verloor, want ons het dit nie regtig verloor nie. Maar daar was gevaar. Ons sien dat hierdie oplossing natuurlik goed is, maar dit is 'n bietjie soos om die simptome van die probleem uit te stryk, in plaas daarvan om dit heeltemal op te los. En 'n paar probleme bly hier.
Eerstens is dit 'n punt van mislukking in die vorm van die fisiese gasheer self waarop al hierdie masjinerie nie weg is nie.
Tweedens is daar steeds probleme met SAN'e, hul swaar instandhouding, ens. Dit was nie dat dit 'n kritieke faktor was nie, maar ek wou probeer om op een of ander manier daarsonder te leef.
En ons het die derde weergawe gemaak (in werklikheid die tweede) - die besprekingsweergawe. Hoe het dit gelyk?
Dit is wat dit was -
Ons grootste probleme is met die feit dat dit 'n fisiese gasheer is.
Eerstens, ons verwyder SAN'e omdat ons wil eksperimenteer, ons wil net plaaslike hardeskywe probeer.
Dit is reeds 2014-2015, en op daardie stadium het die situasie met skywe en hul kapasiteit in een gasheer baie beter geword. Ons het besluit hoekom dit nie probeer nie.
En dan neem ons eenvoudig ons rugsteunpartisie en dra dit fisies oor na 'n aparte masjien.
Dus kry ons hierdie diagram. Ons het twee motors wat dieselfde datastelle stoor. Hulle rugsteun mekaar heeltemal en sinchroniseer data oor die netwerk deur 'n asynchrone tou in dieselfde MySQL.
Hoekom dit goed werk, is omdat ons min rekords het. Dié. as skryf vergelykbaar was met lees, sou ons dalk 'n soort netwerkoorhoofse en probleme hê. Daar is min skryfwerk, baie lees – hierdie metode werk goed, m.a.w. Ons kopieer selde foto's tussen hierdie twee bedieners.
Hoe werk dit, as jy bietjie meer in detail kyk.
Laai op. Die balanseerder kies eenvoudig ewekansige gashere met 'n paar en laai dit op. Terselfdertyd doen hy natuurlik gesondheidsondersoeke en maak seker die kar val nie uit nie. Dié. hy laai foto's net na 'n lewendige bediener op, en dan deur 'n asynchrone tou word dit alles na sy buurman gekopieer. Met oplaai is alles uiters eenvoudig.
Die taak is 'n bietjie moeiliker.
Lua het ons hier gehelp, want dit kan moeilik wees om sulke logika op vanilla NGINX te maak. Ons rig eers 'n versoek aan die eerste bediener, kyk of die foto daar is, want moontlik kan dit byvoorbeeld opgelaai word na 'n buurman, maar het nog nie hier aangekom nie. As die foto daar is, is dit goed. Ons gee dit dadelik aan die kliënt en kas dit moontlik.
As dit nie daar is nie, rig ons bloot 'n versoek aan ons buurman en is gewaarborg om dit van daar af te ontvang.
Daardie. weer kan ons sê: daar kan probleme met prestasie wees, want daar is konstante heen- en terugreise - die foto is opgelaai, dit is nie hier nie, ons rig twee versoeke in plaas van een, dit behoort stadig te werk.
In ons situasie werk dit nie stadig nie.
Ons versamel 'n klomp metrieke oor hierdie stelsel, en die voorwaardelike slim koers van so 'n meganisme is ongeveer 95%. Dié. Die vertraging van hierdie rugsteun is klein, en as gevolg hiervan is ons amper gewaarborg, nadat die foto opgelaai is, sal ons dit die eerste keer neem en sal nie twee keer iewers heen hoef te gaan nie.
So wat het ons nog wat regtig cool is?
Voorheen het ons die hoofrugsteunpartisie gehad, en ons het opeenvolgend daaruit gelees. Dié. Ons het altyd eers op die hoof een gesoek, en dan op die rugsteun. Dit was een skuif.
Nou gebruik ons lees vanaf twee masjiene gelyktydig. Ons versprei versoeke met behulp van Round Robin. In 'n klein persentasie gevalle rig ons twee versoeke. Maar oor die algemeen het ons nou twee keer soveel leesvoorraad as wat ons voorheen gehad het. En die vrag is baie verminder op beide die stuurmasjiene en direk op die stoormasjiene, wat ons ook destyds gehad het.
Wat foutverdraagsaamheid betref. Eintlik is dit waarvoor ons hoofsaaklik geveg het. Met foutverdraagsaamheid het alles hier goed uitgedraai.
Een motor breek.
Geen probleem! ’n Stelselingenieur sal dalk nie eers in die nag wakker word nie, hy sal tot die oggend wag, niks sleg sal gebeur nie.
As selfs as hierdie masjien misluk, die tou buite werking is, is daar ook geen probleme nie, die log sal eenvoudig eers op die lewende masjien opgehoop word, en dan sal dit by die tou gevoeg word, en dan na die motor wat sal gaan na 'n rukkie in werking.
Dieselfde ding met onderhoud. Ons skakel eenvoudig een van die masjiene af, trek dit met die hand uit al die swembaddens, dit hou op om verkeer te ontvang, ons doen 'n soort instandhouding, ons redigeer iets, dan stuur ons dit terug na diens, en hierdie rugsteun haal redelik vinnig in. Dié. per dag haal die staantyd van een motor binne 'n paar minute in. Dit is regtig baie min. Met foutverdraagsaamheid, sê ek weer, alles is cool hier.
Watter gevolgtrekkings kan uit hierdie afdankingskema gemaak word?
Ons het foutverdraagsaamheid.
Maklik om te gebruik. Aangesien die masjiene plaaslike hardeskywe het, is dit uit 'n operasionele oogpunt baie geriefliker vir die ingenieurs wat daarmee werk.
Ons het 'n dubbelleestoelaag ontvang.
Dit is 'n baie goeie bonus bykomend tot foutverdraagsaamheid.
Maar daar is ook probleme. Nou het ons 'n baie meer komplekse ontwikkeling van sommige kenmerke wat hiermee verband hou, want die stelsel het uiteindelik 100% konsekwent geword.
Ons moet, sê, in een of ander agtergrond werk, voortdurend dink: "Op watter bediener loop ons nou?", "Is daar regtig 'n huidige foto hier?" ens. Dit is natuurlik alles afgehandel, en vir die programmeerder wat besigheidslogika skryf, is dit deursigtig. Maar, nietemin, hierdie groot komplekse laag het verskyn. Maar ons is gereed om dit te verduur in ruil vir die lekkernye wat ons daaruit ontvang het.
En hier ontstaan weer 'n mate van konflik.
Ek het aan die begin gesê dat dit sleg is om alles op plaaslike hardeskywe te stoor. En nou sê ek dat ons daarvan gehou het.
Ja, inderdaad, met verloop van tyd het die situasie baie verander, en nou het hierdie benadering baie voordele. Eerstens kry ons baie eenvoudiger werking.
Tweedens is dit meer produktief, want ons het nie hierdie outomatiese beheerders of verbindings na skyfrakke nie.
Daar is 'n groot hoeveelheid masjinerie daar, en dit is net 'n paar skywe wat hier op die masjien saamgestel word in 'n klopjag.
Maar daar is ook nadele.
Dit is ongeveer 1,5 keer duurder as om SAN's te gebruik, selfs teen vandag se pryse. Daarom het ons besluit om nie ons hele groot groep met vrymoedigheid om te skakel in motors met plaaslike hardeskywe nie en besluit om 'n hibriede oplossing te verlaat.
Die helfte van ons masjiene werk met hardeskywe (wel, nie die helfte nie - seker 30 persent). En die res is ou motors wat vroeër die eerste besprekingskema gehad het. Ons het hulle eenvoudig weer gemonteer, aangesien ons nie nuwe data of enigiets anders nodig gehad het nie, het ons eenvoudig die monterings van een fisiese gasheer na twee geskuif.
En ons het nou 'n groot voorraad leeswerk, en ons het dit uitgebrei. As ons vroeër een stoor op een masjien gemonteer het, monteer ons nou vier, byvoorbeeld, op een paar. En dit werk goed.
Kom ons neem 'n kort opsomming van wat ons bereik het, waarvoor ons geveg het en of ons daarin geslaag het.
Resultate van
Ons het gebruikers – soveel as 33 miljoen.
Ons het drie punte van teenwoordigheid - Praag, Miami, Hong Kong.
Hulle bevat 'n kaslaag, wat bestaan uit motors met vinnige plaaslike skywe (SSD's), waarop eenvoudige masjinerie van NGINX, sy access.log en Python-demone loop, wat dit alles verwerk en die kas bestuur.
As jy wil, is jy in jou projek, as foto's nie so krities vir jou is soos dit vir ons is nie, of as afruilbeheer teenoor ontwikkelingspoed en hulpbronkoste in die ander rigting vir jou is, dan kan jy dit veilig vervang met 'n CDN, vaar moderne CDN's hulle goed.
Volgende kom die bergingslaag, waarop ons groepe van pare masjiene het wat mekaar rugsteun, lêers word asinchronies van die een na die ander gekopieer wanneer hulle ook al verander.
Boonop werk sommige van hierdie masjiene met plaaslike hardeskywe.
Sommige van hierdie masjiene is aan SAN'e gekoppel.
En aan die een kant is dit geriefliker om te gebruik en 'n bietjie meer produktief, aan die ander kant is dit gerieflik in terme van plasingsdigtheid en prys per gigagreep.
Dit is so 'n kort oorsig van die argitektuur van wat ons gekry het en hoe dit alles ontwikkel het.
Nog 'n paar wenke van die kaptein, baie eenvoudiges.
Eerstens, as jy skielik besluit dat jy alles in jou foto-infrastruktuur dringend moet verbeter, meet eers, want dalk hoef niks verbeter te word nie.
Kom ek gee vir jou 'n voorbeeld. Ons het 'n groep masjiene wat foto's van aanhangsels in kletse stuur, en die skema werk sedert 2009 daar, en niemand ly daaronder nie. Dit gaan goed met almal, almal hou van alles.
Om te meet, hang eers 'n klomp metrieke op, kyk daarna, en besluit dan waarmee jy ontevrede is en wat verbeter moet word. Om dit te meet, het ons 'n oulike instrument genaamd Pinba.
Dit laat jou toe om baie gedetailleerde statistieke van NGINX in te samel vir elke versoek en reaksiekodes, en verspreiding van tye - wat jy ook al wil hê. Dit het bindings aan allerhande verskillende analitiese stelsels, en dan kan jy pragtig daarna kyk.
Eers het ons dit gemeet, toe verbeter ons dit.
Verder. Ons optimaliseer lees met kas, skryf met versplintering, maar dit is 'n ooglopende punt.
Verder. As jy nou eers begin om jou stelsel te bou, dan is dit baie beter om foto's as onveranderlike lêers te maak. Want jy verloor dadelik 'n hele klas probleme met kas ongeldigmaking, met hoe die logika die korrekte weergawe van die foto moet vind, ensovoorts.
Kom ons sê jy het honderd opgelaai, dit dan geroteer, maak dit so dat dit 'n fisies ander lêer was. Dié. nie nodig om te dink nie: nou sal ek 'n bietjie spasie spaar, dit in dieselfde lêer skryf, die weergawe verander. Dit werk altyd nie goed nie en veroorsaak later baie hoofpyn.
Volgende punt. Oor die verandering van grootte op die vlieg.
Voorheen, toe gebruikers 'n foto opgelaai het, het ons dadelik 'n hele klomp groottes gesny vir alle geleenthede, vir verskillende kliënte, en hulle was almal op die skyf. Nou het ons dit laat vaar.
Ons het net drie hoofgroottes oorgelaat: klein, medium en groot. Ons skaal eenvoudig alles anders af van die grootte wat agter die een is wat aan ons by Uport gevra is, ons doen eenvoudig die afskaal en gee dit aan die gebruiker.
Die SVE van die kaslaag hier blyk baie goedkoper te wees as wanneer ons hierdie groottes voortdurend op elke berging herskep het. Kom ons sê ons wil 'n nuwe een byvoeg, dit sal 'n maand neem - voer oral 'n skrif uit wat dit alles netjies sal doen, sonder om die groep te vernietig. Dié. As jy nou die geleentheid het om te kies, is dit beter om so min as moontlik fisiese groottes te maak, maar sodat ten minste 'n mate van verspreiding, sê, drie is. En alles anders kan eenvoudig verander word met behulp van klaargemaakte modules. Dit is nou alles baie maklik en toeganklik.
En inkrementele asynchrone rugsteun is goed.
Soos ons praktyk getoon het, werk hierdie skema uitstekend met vertraagde kopiëring van veranderde lêers.
Die laaste punt is ook duidelik. As jou infrastruktuur nie nou sulke probleme het nie, maar daar is iets wat kan breek, sal dit beslis breek wanneer dit 'n bietjie meer word. Daarom is dit beter om vooraf hieroor te dink en nie probleme daarmee te ervaar nie. Dis al wat ek wou sê.
kontakte
»
»
Hierdie verslag is 'n transkripsie van een van die beste toesprake by die konferensie van ontwikkelaars van hoëladingstelsels . Daar is minder as 'n maand oor tot die HighLoad++ 2017-konferensie.
Ons het dit reeds gereed , word die skedule nou aktief gevorm.
Hierdie jaar gaan ons voort om die onderwerp van argitekture en skaal te verken:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Ons gebruik ook sommige van hierdie materiaal in ons aanlyn opleidingskursus oor die ontwikkeling van hoëladingstelsels is 'n ketting van spesiaal geselekteerde briewe, artikels, materiaal, video's. Ons handboek bevat reeds meer as 30 unieke materiaal. Koppel!
Bron: will.com