Artem Denisov ( , )
Badoo er stærsta stefnumótasíða heims. Núna erum við með um 330 milljónir skráða notendur um allan heim. En það sem er miklu mikilvægara í samhengi við samtal okkar í dag er að við geymum um 3 petabæta af notendamyndum. Á hverjum degi hlaða notendum okkar inn um 3,5 milljón nýjum myndum og lestrarálagið er um það bil 80 þúsund beiðnir á sekúndu. Þetta er töluvert mikið fyrir bakendann okkar og stundum eru erfiðleikar með þetta.
Ég mun tala um hönnun þessa kerfis, sem geymir og sendir myndir almennt, og ég mun skoða það frá sjónarhóli þróunaraðila. Það verður stutt yfirlit yfir hvernig það þróaðist, þar sem ég mun gera grein fyrir helstu tímamótum, en ég mun aðeins tala nánar um þær lausnir sem við erum að nota núna.
Nú skulum við byrja.
Eins og ég sagði verður þetta aftursýni og til að byrja á því einhvers staðar skulum við taka algengasta dæmið.
Við höfum sameiginlegt verkefni, við þurfum að taka við, geyma og senda notendamyndir. Í þessu formi er verkefnið almennt, við getum notað hvað sem er:
- nútíma skýgeymsla,
- kassalausn, sem það er líka mikið af núna;
- Við getum sett upp nokkrar vélar í gagnaverinu okkar og sett stóra harða diska á þær og geymt myndir þar.
Badoo sögulega séð - bæði nú og þá (á þeim tíma þegar það var bara í frumbernsku) - býr á sínum eigin netþjónum, inni í okkar eigin DCs. Þess vegna var þessi valkostur ákjósanlegur fyrir okkur.
Við tókum bara nokkrar vélar, kölluðum þær „myndir“ og við fengum þyrping sem geymir myndir. En það virðist sem eitthvað vanti. Til þess að allt þetta virki þurfum við einhvern veginn að ákveða á hvaða vél við munum geyma hvaða myndir. Og hér líka, það er engin þörf á að opna Ameríku.
Við bætum einhverjum reit við geymsluna okkar með upplýsingum um notendur. Þetta verður klippingarlykillinn. Í okkar tilviki kölluðum við það place_id og þetta staðauðkenni bendir á staðinn þar sem notendamyndir eru geymdar. Við gerum kort.
Á fyrsta stigi er þetta jafnvel hægt að gera handvirkt - við segjum að mynd af þessum notanda með slíkum stað muni lenda á slíkum netþjóni. Þökk sé þessu korti vitum við alltaf hvenær notandi hleður inn mynd, hvar á að vista hana og við vitum hvaðan á að gefa hana.
Þetta er algerlega léttvægt kerfi, en það hefur töluverða kosti. Í fyrsta lagi er það einfalt, eins og ég sagði, og annað er að með þessari nálgun getum við auðveldlega skalað lárétt með því einfaldlega að afhenda nýja bíla og bæta þeim á kortið. Þú þarft ekki að gera neitt annað.
Þannig var þetta hjá okkur um tíma.
Þetta var í kringum 2009. Þeir afhentu bíla, afhentu...
Og á einhverjum tímapunkti fórum við að taka eftir því að þetta kerfi hefur ákveðna ókosti. Hverjir eru ókostirnir?
Fyrst af öllu, það er takmörkuð afkastageta. Við getum ekki troðið eins mörgum harða diskum á einn netþjón og við viljum. Og þetta hefur orðið ákveðið vandamál með tímanum og með vexti gagnasafnsins.
Og í öðru lagi. Þetta er óhefðbundin uppsetning véla þar sem erfitt er að endurnýta slíkar vélar í sumum öðrum klösum; þær eru nokkuð sértækar, þ.e. þeir ættu að vera veikburða í frammistöðu, en á sama tíma með stórum harða diski.
Þetta var allt árið 2009, en í grundvallaratriðum eiga þessar kröfur enn við í dag. Við erum með yfirlitsmynd þannig að árið 2009 var allt algjörlega vont með þetta.
Og síðasti punkturinn er verðið.
Verðið var mjög hátt á þeim tíma og við þurftum að leita að einhverjum valkostum. Þeir. við þurftum einhvern veginn að nýta betur bæði plássið í gagnaverunum og líkamlegu netþjónana sem allt þetta er á. Og kerfisfræðingar okkar hófu stóra rannsókn þar sem þeir fóru yfir fullt af mismunandi valkostum. Þeir skoðuðu einnig þyrpuð skráarkerfi eins og PolyCeph og Luster. Það voru frammistöðuvandamál og nokkuð erfiður rekstur. Þeir neituðu. Við reyndum að tengja allt gagnasafnið í gegnum NFS á hvern bíl til að stækka það einhvern veginn. Lestur gekk líka illa, við reyndum mismunandi lausnir frá mismunandi söluaðilum.
Og á endanum settumst við að því að nota svokallað Storage Area Network.
Þetta eru stórir SHDs sem eru sérstaklega hönnuð til að geyma mikið magn af gögnum. Þetta eru hillur með diskum sem eru festir á endanlega sjónúttaksvélarnar. Það. við erum með einhvers konar laug af vélum, frekar litlar, og þessar SHDs, sem eru gagnsæar fyrir sendingarrökfræði okkar, þ.e. fyrir nginx okkar eða einhvern annan til að þjóna beiðnum um þessar myndir.
Þessi ákvörðun hafði augljósa kosti. Þetta er SHD. Það er ætlað að geyma myndir. Þetta virkar ódýrara en einfaldlega að útbúa vélar með hörðum diskum.
Annar plús.
Þetta er að afkastagetan er orðin miklu meiri, þ.e. við getum tekið við miklu meiri geymslu í miklu minna magni.
En það voru líka ókostir sem komu fljótt í ljós. Eftir því sem fjöldi notenda og álag á þetta kerfi jókst fóru að koma upp frammistöðuvandamál. Og vandamálið hér er alveg augljóst - hvaða SHD sem er hannað til að geyma margar myndir í litlu magni, þjáist að jafnaði af miklum lestri. Þetta á í raun við um hvaða skýjageymslu sem er eða eitthvað annað. Nú höfum við ekki tilvalið geymslu sem væri óendanlega skalanlegt, þú gætir troðið hverju sem er í hana og hún myndi þola lestur mjög vel. Sérstaklega frjálslegur lestur.
Eins og raunin er með myndirnar okkar, vegna þess að beðið er um myndir í ósamræmi, og það mun hafa mikil áhrif á frammistöðu þeirra.
Jafnvel samkvæmt tölum dagsins í dag, ef við fáum einhvers staðar meira en 500 RPS fyrir myndir á vél sem geymsla er tengd við, byrja vandamál þegar. Og það var nógu slæmt fyrir okkur, því notendum fjölgar, hlutirnir munu bara versna. Þetta þarf að hagræða einhvern veginn.
Til að hagræða ákváðum við á þeim tíma, augljóslega, að skoða álagssniðið - hvað er almennt að gerast, hvað þarf að hagræða.
Og hér spilar allt í okkar hendur.
Ég sagði þegar í fyrstu glærunni: við erum með 80 þúsund lestrarbeiðnir á sekúndu með aðeins 3,5 milljón upphleðslum á dag. Það er, þetta er þriggja stærðarmunur. Það er augljóst að það þarf að hagræða lestri og það er nánast ljóst hvernig.
Það er enn einn lítill punktur. Sérstakur þjónustunnar er þannig að einstaklingur skráir sig, hleður upp mynd, byrjar síðan að skoða annað fólk á virkan hátt, líkar við það og er virkur sýndur öðru fólki. Svo finnur hann maka eða finnur ekki maka, það fer eftir því hvernig það kemur út, og hættir að nota þjónustuna um tíma. Á þessari stundu, þegar hann notar það, eru myndirnar hans mjög heitar - þær eru eftirsóttar, margir skoða þær. Um leið og hann hættir að gera þetta hættir hann ansi fljótt úr eins mikilli útsetningu fyrir öðru fólki og hann hafði áður og nánast aldrei er beðið um myndirnar hans.
Þeir. Við erum með mjög lítið heitt gagnasafn. En á sama tíma er mikið af beiðnum eftir honum. Og algjörlega augljós lausn hér er að bæta við skyndiminni.
Skyndiminni með LRU mun leysa öll vandamál okkar. Hvað erum við að gera?
Við bætum við öðru tiltölulega litlu fyrir framan stóra þyrpinguna okkar með geymslu, sem kallast photocaches. Þetta er í rauninni bara skyndiminni umboð.
Hvernig virkar það innan frá? Hér er notandinn okkar, hér er geymsla. Allt er eins og áður. Hverju bætum við á milli?
Þetta er bara vél með líkamlegan staðbundinn disk, sem er fljótur. Þetta er til dæmis með SSD. Og einhvers konar staðbundið skyndiminni er geymt á þessum disk.
Hvernig lítur það út? Notandinn sendir beiðni um mynd. NGINX leitar fyrst að því í skyndiminni á staðnum. Ef ekki, þá einfaldlega proxy_pass í geymsluna okkar, hlaðið niður myndinni þaðan og gefið notandanum hana.
En þessi er mjög banal og óljóst hvað er að gerast inni. Það virkar eitthvað á þessa leið.
Skyndiminni er rökrétt skipt í þrjú lög. Þegar ég segi „þrjú lög“ þýðir þetta ekki að það sé einhvers konar flókið kerfi. Nei, þetta eru skilyrt aðeins þrjár möppur í skráarkerfinu:
- Þetta er biðminni þar sem myndir sem nýlega var hlaðið niður af proxy fara.
- Þetta er heitt skyndiminni sem geymir myndir sem beðið er um núna.
- Og kalt skyndiminni, þar sem myndum er smám saman ýtt út úr heitu skyndiminni þegar færri beiðnir berast til þeirra.
Til að þetta virki þurfum við einhvern veginn að stjórna þessu skyndiminni, við þurfum að endurraða myndunum í því o.s.frv. Þetta er líka mjög frumstætt ferli.
Nginx skrifar einfaldlega á RAMDisk access.log fyrir hverja beiðni, þar sem það gefur til kynna slóðina að myndinni sem hún hefur nú þjónað (afstætt slóð, auðvitað), og hvaða skipting það var þjónað. Þeir. það gæti sagt „mynd 1“ og síðan annað hvort biðminni, eða heitt skyndiminni, eða kalt skyndiminni, eða umboð.
Það fer eftir þessu, við þurfum einhvern veginn að ákveða hvað á að gera við myndina.
Við erum með lítinn púka í gangi á hverri vél sem les stöðugt þennan log og geymir tölfræði um notkun ákveðinna ljósmynda í minni hennar.
Hann safnar einfaldlega þar, heldur búðunum og gerir reglulega eftirfarandi. Hann færir myndir sem beðið er um með virkum hætti, sem það eru margar beiðnir um, í heita skyndiminni, hvar sem þær eru.
Myndum sem sjaldan er beðið um og hefur verið beðið um sjaldnar er smám saman ýtt út úr heitu skyndiminni í það kalda.
Og þegar við erum uppiskroppa með pláss í skyndiminni, byrjum við einfaldlega að eyða öllu úr köldu skyndiminni óspart. Og við the vegur, þetta virkar vel.
Til þess að myndin sé vistuð strax þegar hún er send umboð í biðminni notum við proxy_store tilskipunina og biðminni er líka RAMDisk, þ.e. fyrir notandann virkar það mjög hratt. Þetta varðar innra hluta skyndiminnisþjónsins sjálfs.
Spurningin sem eftir er er hvernig á að dreifa beiðnum yfir þessa netþjóna.
Segjum að það sé þyrping af tuttugu geymsluvélum og þremur skyndiminniþjónum (svona gerðist það).
Við þurfum einhvern veginn að ákveða hvaða beiðnir eru um hvaða myndir og hvar á að landa þeim.
Algengasta valkosturinn er Round Robin. Eða gera það óvart?
Þetta hefur augljóslega ýmsa ókosti vegna þess að við myndum nota skyndiminni mjög óhagkvæmt í slíkum aðstæðum. Beiðnir munu lenda á nokkrum vélum af handahófi: hér var það í skyndiminni, en á þeirri næstu er það ekki lengur til staðar. Og ef allt þetta virkar verður það mjög slæmt. Jafnvel með lítinn fjölda véla í klasanum.
Við þurfum einhvern veginn ótvírætt að ákveða hvaða netþjóni á að lenda hvaða beiðni.
Það er banal leið. Við tökum kjötkássa úr vefslóðinni eða kjötkássa úr sundurlykli okkar, sem er í vefslóðinni, og deilum því með fjölda netþjóna. Mun virka? Will.
Þeir. Við erum með 2% beiðni, til dæmis fyrir einhverja „example_url“ mun hún alltaf lenda á þjóninum með vísitölunni „XNUMX“ og skyndiminni verður stöðugt fargað eins og best verður á kosið.
En það er vandamál með endurskipulagningu í slíku kerfi. Endurhleðsla - ég meina að breyta fjölda netþjóna.
Gerum ráð fyrir að skyndiminni þyrpingin okkar ráði ekki lengur við og við ákveðum að bæta við annarri vél.
Við skulum bæta við.
Nú er allt deilanlegt ekki með þremur, heldur með fjórum. Þannig að næstum allir lyklar sem við höfðum áður, næstum allar vefslóðir eru nú á öðrum netþjónum. Allt skyndiminni var ógilt einfaldlega í augnablik. Allar beiðnir féllu á geymsluklasann okkar, hann varð illa farinn, þjónustubrestur og óánægðir notendur. Ég vil ekki gera það.
Þessi valkostur hentar okkur ekki heldur.
Það. hvað ættum við að gera? Við verðum einhvern veginn að nýta skyndiminni á skilvirkan hátt, lenda sömu beiðninni á sama netþjóninum aftur og aftur, en vera ónæm fyrir endurhleðslu. Og það er til slík lausn, hún er ekki svo flókin. Það er kallað stöðugt hashing.
Hvað lítur þetta út?
Við tökum einhverja aðgerð frá klippingarlyklinum og dreifum öllum gildum hans á hringinn. Þeir. í punkti 0, renna lágmarks- og hámarksgildi þess saman. Næst setjum við alla netþjóna okkar á sama hring á um það bil þennan hátt:
Hver netþjónn er skilgreindur af einum punkti og geirinn sem fer réttsælis að honum, í samræmi við það, er þjónað af þessum gestgjafa. Þegar beiðnir berast til okkar sjáum við strax að til dæmis beiðni A - það hefur hass þar - og það er þjónað af þjóni 2. Beiðni B - af þjóni 3. Og svo framvegis.
Hvað gerist í þessum aðstæðum við endurhleðslu?
Við ógildum ekki allt skyndiminni, eins og áður, og breytum ekki öllum lyklum, heldur færum við hvern geira stutta vegalengd þannig að tiltölulega séð, sjötti þjónninn okkar, sem við viljum bæta við, passi inn í lausa plássið, og við bætum því við þar.
Auðvitað, í slíkum aðstæðum, færast lyklarnir líka út. En þeir fara mun veikari út en áður. Og við sjáum að fyrstu tveir lyklarnir okkar voru áfram á netþjónum þeirra og skyndiminnisþjónninn breyttist aðeins fyrir síðasta lykilinn. Þetta virkar nokkuð skilvirkt og ef þú bætir við nýjum gestgjöfum í áföngum, þá er ekkert stórt vandamál hér. Þú bætir við og bætir við smá í einu, bíður þar til skyndiminni er fullt aftur og allt virkar vel.
Eina spurningin er eftir með synjun. Gefum okkur að einhvers konar bíll sé bilaður.
Og við myndum í raun ekki vilja endurnýja þetta kort á þessari stundu, ógilda hluta af skyndiminni og svo framvegis, ef vélin væri til dæmis endurræst og við þurfum einhvern veginn að biðja um þjónustu. Við geymum einfaldlega eitt skyndiminni fyrir öryggisafrit á hverri síðu, sem kemur í staðinn fyrir hvaða vél sem er niðri núna. Og ef skyndilega verður einn af netþjónum okkar ófáanlegur fer umferðin þangað. Við höfum náttúrulega ekkert skyndiminni þarna, þ.e. það er kalt, en að minnsta kosti er verið að vinna úr notendabeiðnum. Ef þetta er stutt millibil þá upplifum við það alveg rólega. Það er bara meira álag á geymslu. Ef þetta bil er langt, þá getum við þegar tekið ákvörðun - að fjarlægja þennan netþjón af kortinu eða ekki, eða kannski skipta honum út fyrir annan.
Þetta snýst um skyndiminniskerfið. Við skulum skoða niðurstöðurnar.
Svo virðist sem hér sé ekkert flókið. En þessi aðferð við að stjórna skyndiminni gaf okkur bragðhlutfall upp á um 98%. Þeir. af þessum 80 þúsund beiðnum á sekúndu ná bara 1600 í geymslu og þetta er alveg eðlilegt álag, þeir þola þetta í rólegheitum, við eigum alltaf varasjóð.
Við settum þessa netþjóna í þrjá af DCs okkar og fengum þrjá staði - Prag, Miami og Hong Kong.
Það. þau eru meira og minna staðbundin fyrir hvern markmarkað okkar.
Og sem ágætur bónus fengum við þennan skyndiminni umboð, sem örgjörvinn er í raun aðgerðalaus á, vegna þess að það er ekki svo nauðsynlegt til að þjóna efni. Og þar, með því að nota NGINX+ Lua, innleiddum við mikið af nytjahyggju.
Til dæmis getum við gert tilraunir með webp eða framsækið jpeg (þetta eru áhrifarík nútímasnið), sjá hvernig það hefur áhrif á umferð, tekið nokkrar ákvarðanir, virkjað það fyrir ákveðin lönd o.s.frv.; búa til kraftmikla stærðarbreytingu eða klippa myndir á flugu.
Þetta er gott notagildi þegar þú ert til dæmis með farsímaforrit sem sýnir myndir og farsímaforritið vill ekki sóa örgjörva viðskiptavinarins í að biðja um stóra mynd og breyta stærð hennar í ákveðna stærð til að ýta henni inn í útsýnið. Við getum einfaldlega tilgreint nokkrar færibreytur í UPort skilyrtu vefslóðinni, og myndaskyndiminni mun breyta stærð myndarinnar sjálfrar. Að jafnaði mun það velja stærðina sem við höfum líkamlega á disknum, eins nálægt þeirri sem óskað er eftir og hægt er, og selja hana niður í sérstökum hnitum.
Við the vegur, við höfum gert opinberlega aðgengilegar myndbandsupptökur af síðustu fimm árum ráðstefnu þróunaraðila á háhleðslukerfum . Horfa, læra, deila og gerast áskrifandi að .
Við getum líka bætt við miklu vörulogic þar. Til dæmis getum við bætt við mismunandi vatnsmerkjum með því að nota URL færibreytur, við getum gert myndir óskýrar, óskýrar eða pixlaðar. Þetta er þegar við viljum sýna mynd af einstaklingi, en við viljum ekki sýna andlit hans, þetta virkar vel, þetta er allt útfært hér.
Hvað fengum við? Við fengum þrjú viðverustig, gott bragðhlutfall og á sama tíma erum við ekki með aðgerðalausa örgjörva á þessum vélum. Hann er nú auðvitað orðinn mikilvægari en áður. Við þurfum að gefa okkur sterkari bíla en það er þess virði.
Þetta varðar skil á ljósmyndum. Hér er allt nokkuð skýrt og augljóst. Ég held að ég hafi ekki uppgötvað Ameríku, næstum hvaða CDN sem er virkar á þennan hátt.
Og líklega gæti háþróaður hlustandi haft spurningu: af hverju ekki bara að breyta öllu í CDN? Það væri um það bil það sama; öll nútíma CDN geta gert þetta. Og það eru ýmsar ástæður.
Í fyrsta lagi eru ljósmyndir.
Þetta er eitt af lykilatriðum innviða okkar og við þurfum eins mikla stjórn á því og mögulegt er. Ef þetta er einhvers konar lausn frá þriðja aðila söluaðila og þú hefur ekkert vald yfir því, þá verður frekar erfitt fyrir þig að lifa með því þegar þú ert með stórt gagnasafn og þegar þú ert með mjög mikið flæði af beiðnum notenda.
Leyfðu mér að gefa þér dæmi. Núna, með okkar innviði, getum við til dæmis, ef einhver vandamál koma upp eða neðanjarðar högg, farið að vélinni og ruglað þar, tiltölulega séð. Við getum bætt við safni nokkurra mælikvarða sem við þurfum aðeins, við getum gert tilraunir á einhvern hátt, séð hvernig þetta hefur áhrif á línuritin, og svo framvegis. Nú er mikið af tölfræði safnað um þennan skyndiminniklasa. Og við skoðum það reglulega og eyðum löngum tíma í að kanna nokkur frávik. Ef það væri á CDN hliðinni væri miklu erfiðara að stjórna því. Eða, til dæmis, ef einhvers konar slys verða, vitum við hvað gerðist, við vitum hvernig við eigum að lifa með því og hvernig á að sigrast á því. Þetta er fyrsta niðurstaðan.
Önnur niðurstaðan er líka frekar söguleg, því kerfið hefur verið að þróast í langan tíma og það voru margar mismunandi viðskiptakröfur á mismunandi stigum og þær passa ekki alltaf inn í CDN hugmyndina.
Og punkturinn sem leiðir af því fyrra er
Þetta er vegna þess að í myndaskyndiminni höfum við mikið af sértækri rökfræði, sem ekki er alltaf hægt að bæta við ef óskað er eftir því. Það er ólíklegt að CDN muni bæta einhverjum sérsniðnum hlutum við þig að beiðni þinni. Til dæmis að dulkóða vefslóðir ef þú vilt ekki að viðskiptavinurinn geti breytt einhverju. Viltu breyta slóðinni á þjóninum og dulkóða hana og senda síðan nokkrar dýnamískar breytur hingað.
Hvaða niðurstöðu gefur þetta til kynna? Í okkar tilviki er CDN ekki mjög góður valkostur.
Og í þínu tilviki, ef þú hefur einhverjar sérstakar viðskiptakröfur, þá geturðu auðveldlega útfært það sem ég sýndi þér sjálfur. Og þetta mun virka fullkomlega með svipuðu álagssniði.
En ef þú ert með einhvers konar almenna lausn, og verkefnið er ekki mjög sérstakt, geturðu alveg örugglega tekið CDN. Eða ef tími og fjármagn er mikilvægara fyrir þig en stjórn.
Og nútíma CDN hafa næstum allt sem ég sagði þér um núna. Að undanskildum plús eða mínus sumum eiginleikum.
Þetta snýst um að gefa myndir.
Við skulum nú fara aðeins fram á við í yfirlitinu okkar og tala um geymslu.
Árið 2013 var að líða.
Skyndiminniþjónum var bætt við, afköst vandamál fóru í burtu. Allt er í lagi. Gagnasett er að stækka. Frá og með 2013 vorum við með um 80 netþjóna tengda við geymslu og um 40 skyndiminni í hverjum DC. Þetta eru 560 terabæta af gögnum á hverjum DC, þ.e. um petabæti samtals.
Og með vexti gagnasafnsins fór rekstrarkostnaður að hækka verulega. Hvað þýddi þetta?
Í þessari skýringarmynd sem er teiknuð - með SAN, með vélum og skyndiminni tengdum við það - eru margir punktar sem bila. Ef við hefðum þegar tekist á við bilun í skyndiminni netþjónum áður, var allt meira og minna fyrirsjáanlegt og skiljanlegt, en á geymsluhliðinni var allt miklu verra.
Í fyrsta lagi geymslusvæðisnetið (SAN) sjálft, sem getur bilað.
Í öðru lagi er það tengt með ljósfræði við endavélarnar. Það geta verið vandamál með sjónkort og kerti.
Auðvitað eru þeir ekki eins margir og með SAN sjálft, en engu að síður eru þetta líka stig sem hafa misheppnast.
Næst er vélin sjálf sem er tengd við geymsluna. Það getur líka mistekist.
Alls erum við með þrjú stig mistök.
Ennfremur, auk bilunarpunkta, er mikið viðhald á geymslunni sjálfri.
Þetta er flókið fjölþátta kerfi og kerfisfræðingar geta átt erfitt með að vinna með það.
Og síðasti, mikilvægasti punkturinn. Ef einhver þessara þriggja punkta mistakast höfum við engar líkur á að notendagögn tapist vegna þess að skráarkerfið gæti hrunið.
Segjum að skráarkerfið okkar sé bilað. Í fyrsta lagi tekur bati þess langan tíma - það getur tekið viku með miklu magni af gögnum. Og í öðru lagi, á endanum munum við líklega enda með fullt af óskiljanlegum skrám sem þarf að sameina á einhvern hátt í notendamyndir. Og við eigum á hættu að missa gögn. Áhættan er frekar mikil. Og því oftar sem slíkar aðstæður gerast, og því fleiri vandamál sem koma upp í allri þessari keðju, því meiri er áhættan.
Það varð að gera eitthvað í þessu. Og við ákváðum að við þurfum bara að taka öryggisafrit af gögnunum. Þetta er í raun augljós lausn og góð. Hvað höfum við gert?
Svona leit þjónninn okkar út þegar hann var tengdur við geymslu áður. Þetta er einn aðalhluti, þetta er bara blokkartæki sem táknar í raun festingu fyrir fjargeymslu í gegnum ljósfræði.
Við bættum bara við öðrum hluta.
Við settum aðra geymslu við hliðina á henni (sem betur fer er hún ekki svo dýr miðað við peninga) og kölluðum hana varahluti. Það er einnig tengt í gegnum ljósfræði og er staðsett á sömu vél. En við þurfum einhvern veginn að samstilla gögnin á milli þeirra.
Hér gerum við einfaldlega ósamstillta biðröð í nágrenninu.
Hún er ekki mjög upptekin. Við vitum að við eigum ekki nóg af skrám. Biðröð er bara tafla í MySQL þar sem línur eins og „þú þarft að taka öryggisafrit af þessari mynd“ eru skrifaðar. Með hvaða breytingu eða upphleðslu sem er, afritum við frá aðal skiptingunni í öryggisafrit með því að nota ósamstilltan eða bara einhvers konar bakgrunnsstarfsmann.
Og þannig höfum við alltaf tvo samræmda hluta. Jafnvel þótt einn hluti þessa kerfis bili, getum við alltaf breytt aðalsneiðinni með öryggisafriti og allt mun halda áfram að virka.
En vegna þessa eykst lestrarálagið mjög, því... til viðbótar við viðskiptavini sem lesa úr aðalhlutanum, vegna þess að þeir skoða fyrst myndina þar (hún er nýlegri þar), og leita síðan að henni á öryggisafritinu, ef þeir hafa ekki fundið hana (en NGINX gerir þetta bara), Kerfið okkar er líka plús öryggisafrit sem les nú af aðal skiptingunni. Það er ekki það að þetta hafi verið flöskuháls, en ég vildi ekki auka álagið, í rauninni, bara svona.
Og við bættum við þriðja disknum, sem er lítill SSD, og kölluðum hann biðminni.
Hvernig það virkar núna.
Notandinn hleður upp mynd á biðminni, síðan er atburði hent inn í biðröðina sem gefur til kynna að það þurfi að afrita hana í tvo hluta. Það er afritað og myndin lifir á biðminni í nokkurn tíma (t.d. einn dag) og fyrst þá er hún hreinsuð þaðan. Þetta bætir notendaupplifunina til muna, því notandinn setur inn mynd, að jafnaði byrja beiðnir strax að fylgja, eða hann sjálfur uppfærði síðuna og endurnýjaði hana. En það veltur allt á forritinu sem gerir upphleðsluna.
Eða, til dæmis, annað fólk sem hann byrjaði að sýna sig sendir strax beiðnir eftir þessa mynd. Það er ekki enn í skyndiminni; fyrsta beiðnin kemur mjög fljótt. Í meginatriðum það sama og úr myndaskyndiminni. Hæg geymsla kemur alls ekki við sögu í þessu. Og þegar sólarhring síðar er hreinsað, er það þegar annað hvort í skyndiminni í skyndiminnislaginu okkar, eða, líklegast, enginn þarf þess lengur. Þeir. Notendaupplifunin hér hefur vaxið mjög vel vegna svo einfaldra aðgerða.
Jæja, og síðast en ekki síst: við hættum að tapa gögnum.
Segjum bara að við hættum hugsanlega tapa gögnum, vegna þess að við týndum þeim í raun ekki. En það var hætta. Við sjáum að þessi lausn er auðvitað góð, en hún er svolítið eins og að jafna út einkenni vandans í stað þess að leysa hann algjörlega. Og nokkur vandamál eru enn hér.
Í fyrsta lagi er þetta bilunarpunktur í formi líkamlega hýsilsins sjálfs sem öll þessi vél keyrir á; hún hefur ekki horfið.
Í öðru lagi eru enn vandamál með SAN, mikið viðhald þeirra osfrv. Það var ekki það að þetta væri mikilvægur þáttur, en ég vildi reyna að lifa á einhvern hátt án þess.
Og við gerðum þriðju útgáfuna (reyndar þá seinni) - pöntunarútgáfuna. Hvernig leit það út?
Þetta er það sem það var -
Helstu vandamál okkar eru með því að þetta er líkamlegur gestgjafi.
Í fyrsta lagi erum við að fjarlægja SAN vegna þess að við viljum gera tilraunir, við viljum prófa bara staðbundna harða diska.
Þetta er nú þegar 2014-2015 og á þeim tíma varð ástandið með diska og getu þeirra í einum hýsil miklu betra. Við ákváðum hvers vegna ekki að prófa það.
Og svo tökum við einfaldlega öryggisafritssneiðina okkar og flytjum hana líkamlega yfir á sérstaka vél.
Þannig fáum við þessa skýringarmynd. Við erum með tvo bíla sem geyma sömu gagnapakkana. Þeir taka algjörlega afrit af hvort öðru og samstilla gögn yfir netið í gegnum ósamstillta biðröð í sama MySQL.
Af hverju þetta virkar vel er vegna þess að við eigum fáar plötur. Þeir. ef ritun væri sambærileg við lestur, gætum við lent í einhvers konar netkerfi og vandamálum. Það er lítið skrifað, mikið lesið - þessi aðferð virkar vel, þ.e. Við afritum sjaldan myndir á milli þessara tveggja netþjóna.
Hvernig virkar þetta, ef þú skoðar aðeins nánar.
Hlaða upp. Jafnvægismaðurinn velur einfaldlega handahófskennda gestgjafa með pari og hleður upp á það. Á sama tíma gerir hann náttúrulega heilsufarsskoðun og passar upp á að bíllinn detti ekki út. Þeir. hann hleður aðeins inn myndum á netþjóninn í beinni og síðan í gegnum ósamstillta biðröð er þetta allt afritað til nágranna hans. Með upphleðslu er allt mjög einfalt.
Verkefnið er aðeins erfiðara.
Lua hjálpaði okkur hér, því það getur verið erfitt að búa til slíka rökfræði á vanillu NGINX. Við gerum fyrst beiðni til fyrsta netþjónsins, sjáum hvort myndin sé þar, því hugsanlega gæti hún verið hlaðin upp, til dæmis til nágranna, en er ekki enn komin hingað. Ef myndin er þarna, þá er það gott. Við gefum það strax til viðskiptavinarins og, hugsanlega, skyndiminni það.
Ef það er ekki til staðar gerum við einfaldlega beiðni til nágranna okkar og erum tryggð að fá hana þaðan.
Það. aftur getum við sagt: það geta verið vandamál með frammistöðu, vegna þess að það eru stöðugar ferðir fram og til baka - myndin var hlaðið upp, hún er ekki hér, við erum að leggja fram tvær beiðnir í stað einnar, þetta ætti að virka hægt.
Í okkar aðstæðum gengur þetta ekki hægt.
Við söfnum fullt af mælingum um þetta kerfi og skilyrt snjallhlutfall slíks kerfis er um 95%. Þeir. Töfin á þessu öryggisafriti er lítil og vegna þessa erum við nánast tryggð, eftir að myndinni hefur verið hlaðið upp, munum við taka hana í fyrsta skipti og þurfum ekki að fara neitt tvisvar.
Svo hvað annað höfum við sem er mjög flott?
Áður höfðum við aðalafritunarsneiðina og við lásum úr þeim í röð. Þeir. Við leituðum alltaf fyrst á aðalefninu og síðan í öryggisafritinu. Það var ein hreyfing.
Nú notum við lestur úr tveimur vélum í einu. Við dreifum beiðnum með því að nota Round Robin. Í litlu hlutfalli tilvika gerum við tvær beiðnir. En þegar á heildina er litið erum við núna með tvöfalt meira lesefni en áður. Og mikið minnkaði álagið bæði á sendivélarnar og beint á geymsluvélarnar sem við vorum líka með á þessum tíma.
Hvað varðar bilanaþol. Reyndar er þetta það sem við börðumst aðallega fyrir. Með bilunarþoli reyndist allt frábært hér.
Einn bíll bilar.
Ekkert mál! Kerfisfræðingur vaknar kannski ekki einu sinni á nóttunni, hann bíður til morguns, ekkert slæmt mun gerast.
Ef jafnvel þótt þessi vél bili, þá er röðin í ólagi, þá eru engin vandamál heldur, loggurinn safnast einfaldlega fyrst á lifandi vélina og síðan bætist hann við röðina og síðan á bílinn sem mun fara í rekstur eftir nokkurn tíma.
Sama með viðhald. Við slökkvum einfaldlega á einni vélinni, drögum hana handvirkt úr öllum laugum, hún hættir að taka á móti umferð, við gerum einhvers konar viðhald, við breytum einhverju, skilum henni svo aftur í notkun og þetta öryggisafrit nær sér nokkuð fljótt. Þeir. á dag nær niður í miðbæ eins bíls innan nokkurra mínútna. Þetta er í raun mjög lítið. Með gallaþoli segi ég aftur, hér er allt flott.
Hvaða ályktanir er hægt að draga af þessu uppsagnarkerfi?
Við fengum gallaþol.
Auðvelt í notkun. Þar sem vélarnar eru með staðbundna harða diska er þetta mun þægilegra frá rekstrarsjónarmiði fyrir verkfræðinga sem vinna með það.
Við fengum tvöfaldan lestrarstyrk.
Þetta er mjög góður bónus auk bilanaþols.
En það eru líka vandamál. Núna erum við með miklu flóknari þróun á sumum eiginleikum sem tengjast þessu, því kerfið hefur á endanum orðið 100% stöðugt.
Við verðum, segjum, í einhverju bakgrunnsstarfi, stöðugt að hugsa: "Á hvaða netþjóni erum við að keyra núna?", "Er virkilega núverandi mynd hér?" o.s.frv. Þetta er auðvitað allt í höfn og fyrir forritarann sem skrifar viðskiptarökfræði er þetta gagnsætt. En engu að síður hefur þetta stóra flókna lag birst. En við erum tilbúin að sætta okkur við þetta í skiptum fyrir góðgæti sem við fengum frá því.
Og hér koma aftur einhver átök.
Ég sagði í upphafi að það væri slæmt að geyma allt á staðbundnum hörðum diskum. Og nú segi ég að okkur líkaði það.
Já, reyndar, með tímanum hefur ástandið breyst mikið og nú hefur þessi aðferð marga kosti. Í fyrsta lagi fáum við miklu einfaldari aðgerð.
Í öðru lagi er það afkastameiri vegna þess að við höfum ekki þessar sjálfvirku stýringar eða tengingar við diskahillur.
Það er mikið magn af vélum þarna og þetta eru bara nokkrir diskar sem eru settir saman hérna á vélinni í raid.
En það eru líka gallar.
Þetta er um það bil 1,5 sinnum dýrara en að nota SAN jafnvel á verði í dag. Þess vegna ákváðum við að breyta ekki öllu stóra klasanum okkar í bíla með staðbundnum harða diskum og ákváðum að skilja eftir tvinnlausn.
Helmingur véla okkar vinnur með harða diska (jæja, ekki helmingur - líklega 30 prósent). Og restin eru gamlir bílar sem áður voru með fyrsta pöntunarkerfið. Við settum þau einfaldlega upp aftur, þar sem við þurftum ekki ný gögn eða neitt annað, færðum við einfaldlega festingarnar úr einum líkamlegum hýsil í tvo.
Og nú eigum við mikinn lestur og við stækkuðum hann. Ef við höfum áður sett eina geymslu á eina vél, þá festum við nú fjórar, til dæmis á eitt par. Og það virkar fínt.
Við skulum taka stutta samantekt á því sem við náðum, hverju við börðumst fyrir og hvort okkur hafi tekist það.
Niðurstöður
Við höfum notendur - allt að 33 milljónir.
Við erum með þrjá staði - Prag, Miami, Hong Kong.
Þau innihalda skyndiminnislag, sem samanstendur af bílum með hraðvirkum staðbundnum diskum (SSD), sem keyra einfaldar vélar frá NGINX, access.log og Python púkarnir þess, sem vinna úr þessu öllu og halda utan um skyndiminni.
Ef þú vilt, þú ert í verkefninu þínu, ef myndir eru ekki eins mikilvægar fyrir þig og þær eru fyrir okkur, eða ef skiptastjórn á móti þróunarhraða og tilföngskostnaði er í hina áttina fyrir þig, þá geturðu örugglega skipt þeim út með CDN, nútíma CDN eru þau að standa sig vel.
Næst kemur geymslulagið, þar sem við erum með þyrpingar af pörum af vélum sem taka öryggisafrit hver af annarri, skrár eru ósamstilltar afritaðar úr einni í aðra þegar þær breytast.
Þar að auki vinna sumar þessara véla með staðbundnum harða diskum.
Sumar þessara véla eru tengdar við SAN.
Og annars vegar er það þægilegra í notkun og aðeins meira afkastamikið, hins vegar er það þægilegt hvað varðar staðsetningarþéttleika og verð á gígabæta.
Þetta er svo stutt yfirlit yfir arkitektúrinn á því sem við fengum og hvernig þetta þróaðist allt saman.
Nokkur fleiri ráð frá skipstjóranum, mjög einföld.
Í fyrsta lagi, ef þú ákveður allt í einu að þú þurfir brýn að bæta allt í myndainnviðum þínum skaltu mæla fyrst, því kannski þarf ekkert að bæta.
Leyfðu mér að gefa þér dæmi. Við erum með þyrping af vélum sem sendir myndir úr viðhengjum í spjalli og kerfið hefur starfað þar síðan 2009 og enginn þjáist af því. Allir hafa það gott, öllum líkar við allt.
Til að mæla skaltu fyrst hengja upp fullt af mæligildum, skoða þær og ákveða síðan hvað þú ert óánægður með og hvað þarf að bæta. Til þess að mæla þetta erum við með flott tól sem heitir Pinba.
Það gerir þér kleift að safna mjög nákvæmum tölfræði frá NGINX fyrir hverja beiðni og svarkóða og dreifingu tíma - hvað sem þú vilt. Hann hefur bindingar við alls kyns mismunandi greiningarkerfi og svo er hægt að skoða þetta allt fallega.
Fyrst mældum við það, svo bættum við það.
Frekari. Við fínstillum lestur með skyndiminni, ritun með klippingu, en þetta er augljóst atriði.
Frekari. Ef þú ert bara að byrja að byggja upp kerfið þitt, þá er miklu betra að búa til myndir sem óbreytanlegar skrár. Vegna þess að þú missir strax heilan flokk af vandamálum með ógildingu skyndiminni, hvernig rökfræðin ætti að finna réttu útgáfuna af myndinni og svo framvegis.
Segjum að þú hafir hlaðið upp hundrað, síðan snúið því, gert það þannig að það væri líkamlega öðruvísi skrá. Þeir. engin þörf á að hugsa: nú mun ég spara smá pláss, skrifa það í sömu skrá, breyta útgáfunni. Þetta virkar alltaf ekki vel og veldur miklum höfuðverk síðar.
Næsti punktur. Um að breyta stærð á flugu.
Áður fyrr, þegar notendur hlóð upp mynd, klipptum við strax heilan helling af stærðum fyrir öll tækifæri, fyrir mismunandi viðskiptavini, og þær voru allar á disknum. Nú höfum við sleppt þessu.
Við skildum aðeins eftir þrjár aðalstærðir: Small, Medium og Large. Við lækkum einfaldlega allt annað frá þeirri stærð sem er á bak við þá sem var beðin um til okkar hjá Uport, við gerum einfaldlega niðurskalann og gefum notandanum.
Örgjörvi skyndiminnilagsins hér reynist mun ódýrari en ef við endurnýjum stöðugt þessar stærðir á hverri geymslu. Segjum að við viljum bæta við nýjum, þetta mun taka mánuð - keyrðu handrit alls staðar sem myndi gera þetta allt snyrtilega, án þess að eyðileggja þyrpinguna. Þeir. Ef þú hefur tækifæri til að velja núna, er betra að gera eins fáar stærðir og mögulegt er, en þannig að að minnsta kosti einhver dreifing sé, segjum, þrjár. Og allt annað er einfaldlega hægt að breyta stærðinni á flugu með því að nota tilbúnar einingar. Þetta er allt mjög auðvelt og aðgengilegt núna.
Og stigvaxandi ósamstilltur öryggisafrit er gott.
Eins og framkvæmd okkar hefur sýnt, virkar þetta kerfi frábærlega með seinkun á afritun breyttra skráa.
Síðasta atriðið er líka augljóst. Ef innviðir þínir eru ekki í slíkum vandræðum núna, en það er eitthvað sem getur brotnað, mun það örugglega brotna þegar það verður aðeins meira. Þess vegna er betra að hugsa um þetta fyrirfram og ekki lenda í vandræðum með það. Það var allt sem ég vildi segja.
tengiliðir
»
»
Þessi skýrsla er afrit af einni bestu ræðu á ráðstefnu þróunaraðila á háhleðslukerfum . Það er innan við mánuður eftir af ráðstefnunni HighLoad++ 2017.
Við höfum það þegar tilbúið , dagskráin er nú í virkri mótun.
Á þessu ári höldum við áfram að kanna efnið arkitektúr og mælikvarða:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Við notum líka sumt af þessu efni á netþjálfunarnámskeiðinu okkar um þróun á háhleðslukerfum er keðja sérvalinna bréfa, greina, efnis, myndbanda. Kennslubókin okkar inniheldur nú þegar meira en 30 einstök efni. Tengstu!
Heimild: www.habr.com