Artem Denisov ( , )
Badoo on maailma suurim tutvumissait. Praegu on meil üle maailma umbes 330 miljonit registreeritud kasutajat. Kuid meie tänase vestluse kontekstis on palju olulisem see, et salvestame umbes 3 petabaiti kasutajafotosid. Iga päev laadivad meie kasutajad üles umbes 3,5 miljonit uut fotot ja lugemiskoormus on umbes 80 tuhat päringut sekundis. Seda on meie taustaprogrammi jaoks üsna palju ja mõnikord on sellega raskusi.
Räägin selle süsteemi ülesehitusest, mis salvestab ja saadab fotosid tervikuna, ning annan sellele pilku arendaja vaatenurgast. Selle kujunemise kohta tuleb lühike tagasivaade, kus toon välja peamised verstapostid, kuid räägin lähemalt vaid lahendustest, mida praegu kasutame.
Nüüd alustame.
Nagu ma ütlesin, on see tagasivaade ja selleks, et seda kuskilt alustada, võtame kõige tavalisema näite.
Meil on ühine ülesanne, peame kasutajate fotosid vastu võtma, salvestama ja saatma. Sellel kujul on ülesanne üldine, saame kasutada kõike:
- kaasaegne pilvesalvestus,
- karbis lahendus, mida on ka praegu palju;
- Saame oma andmekeskuses seadistada mitu masinat ja panna neile suured kõvakettad ning salvestada sinna fotosid.
Badoo elab ajalooliselt – nii praegu kui ka siis (sel ajal, kui see oli alles lapsekingades) – omaenda serverites, meie enda DC-des. Seetõttu oli see variant meie jaoks optimaalne.
Võtsime lihtsalt mitu masinat, nimetasime neid "fotodeks" ja saime klastri, mis salvestab fotosid. Aga tundub, et midagi on puudu. Et see kõik toimiks, peame kuidagi kindlaks määrama, millises masinas milliseid fotosid talletame. Ja ka siin pole vaja Ameerikat avada.
Lisame oma salvestusruumi kasutajate teabega välja. Sellest saab killustamisvõti. Meie puhul nimetasime seda koha_id ja see koha ID osutab kohale, kus kasutaja fotosid hoitakse. Teeme kaarte.
Esimeses etapis saab seda teha isegi käsitsi - me ütleme, et sellise kohaga kasutaja foto maandub sellisesse serverisse. Tänu sellele kaardile teame alati, millal kasutaja foto üles laadib, kuhu see salvestada ja kust see anda.
See on täiesti triviaalne skeem, kuid sellel on üsna märkimisväärsed eelised. Esimene on see, et see on lihtne, nagu ma ütlesin, ja teine on see, et selle lähenemisviisiga saame hõlpsasti horisontaalselt skaleerida, lihtsalt tarnides uued autod ja lisades need kaardile. Sa ei pea midagi muud tegema.
Nii see meil mõnda aega oligi.
See oli umbes 2009. aastal. Nad tarnisid autosid, tarnisid ...
Ja mingil hetkel hakkasime märkama, et sellel skeemil on teatud puudused. Millised on puudused?
Esiteks on võimsus piiratud. Me ei saa ühte füüsilisse serverisse toppida nii palju kõvakettaid, kui tahaksime. Ja see on aja jooksul ja andmestiku kasvuga muutunud teatud probleemiks.
Ja teiseks. See on masinate ebatüüpiline konfiguratsioon, kuna selliseid masinaid on mõnes teises klastris raske taaskasutada, need on üsna spetsiifilised, s.t. nende jõudlus peaks olema nõrk, kuid samal ajal suure kõvakettaga.
See kõik oli 2009. aasta kohta, kuid põhimõtteliselt kehtivad need nõuded ka praegu. Meil on tagasivaade, nii et 2009. aastal oli sellega kõik täiesti halvasti.
Ja viimane punkt on hind.
Hind oli tol ajal väga krõbe ja tuli otsida alternatiive. Need. pidime kuidagi paremini ära kasutama nii andmekeskuste ruumi kui ka füüsilisi servereid, kus see kõik asub. Ja meie süsteemiinsenerid alustasid ulatuslikku uuringut, mille käigus nad vaatasid läbi hulga erinevaid võimalusi. Nad vaatasid ka rühmitatud failisüsteeme, nagu PolyCeph ja Luster. Esinesid jõudlusprobleemid ja üsna keeruline toimimine. Nad keeldusid. Püüdsime igale autole paigaldada kogu andmestiku NFS-i kaudu, et seda kuidagi suurendada. Lugemine läks ka kehvasti, proovisime erinevatelt müüjatelt erinevaid lahendusi.
Ja lõpuks otsustasime kasutada nn Storage Area Networki.
Need on suured SHD-d, mis on spetsiaalselt loodud suurte andmemahtude salvestamiseks. Need on ketastega riiulid, mis on paigaldatud lõplikele optilisele väljundmasinale. See. meil on mingisugune masinate kogum, üsna väike ja need SHD-d, mis on meie saatmisloogikale läbipaistvad, st. et meie nginx või keegi teine nende fotode taotlusi teenindaks.
Sellel otsusel olid ilmsed eelised. See on SHD. See on mõeldud fotode salvestamiseks. See tuleb välja odavam kui lihtsalt masinate varustamine kõvaketastega.
Teine pluss.
See on see, et võimsus on muutunud palju suuremaks, st. mahutame palju rohkem salvestusruumi palju väiksema mahuga.
Kuid oli ka miinuseid, mis ilmnesid üsna kiiresti. Selle süsteemi kasutajate arvu ja koormuse kasvades hakkasid tekkima jõudlusprobleemid. Ja probleem on siin üsna ilmne - iga SHD, mis on loodud paljude fotode salvestamiseks väikeses mahus, kannatab reeglina intensiivse lugemise all. See kehtib tegelikult iga pilvesalvestuse või muu kohta. Nüüd pole meil ideaalset salvestusruumi, mis oleks lõputult skaleeritav, sinna võiks toppida mida iganes ja see kannataks näitu väga hästi. Eriti juhuslikud lugemised.
Nagu meie fotode puhul, sest fotosid küsitakse ebajärjekindlalt ja see mõjutab oluliselt nende toimivust.
Isegi tänaste arvude järgi, kui me saame kuskil üle 500 RPS fotode eest masinas, millega on ühendatud salvestusruum, algavad juba probleemid. Ja see oli meile piisavalt halb, sest kasutajate arv kasvab, asjad lähevad ainult hullemaks. Seda tuleb kuidagi optimeerida.
Optimeerimiseks otsustasime sel ajal ilmselgelt vaadata koormusprofiili - mis üldiselt toimub, mida on vaja optimeerida.
Ja siin mängib kõik meie kätesse.
Ütlesin juba esimesel slaidil: meil on 80 tuhat lugemistaotlust sekundis ja ainult 3,5 miljonit üleslaadimist päevas. See tähendab, et see on kolme suurusjärgu erinevus. On ilmne, et lugemist on vaja optimeerida ja on praktiliselt selge, kuidas.
On veel üks väike punkt. Teenuse spetsiifika on selline, et inimene registreerub, laadib üles foto, seejärel hakkab aktiivselt teisi inimesi vaatama, neile meeldib ja teda näidatakse aktiivselt teistele. Siis leiab ta kaaslase või ei leia kaaslast, oleneb, kuidas see välja kukub, ja lõpetab mõneks ajaks teenuse kasutamise. Praegu, kui ta seda kasutab, on tema fotod väga kuumad – need on nõutud, neid vaatavad paljud. Niipea, kui ta selle lõpetab, loobub ta üsna kiiresti teiste inimestega kokkupuutest nii palju kui varem ja tema fotosid ei küsita peaaegu kunagi.
Need. Meil on väga väike kuum andmekogum. Kuid samal ajal on talle palju palveid. Ja siin on täiesti ilmne lahendus vahemälu lisamine.
Vahemälu koos LRU-ga lahendab kõik meie probleemid. Mida me teeme?
Lisame oma suure salvestusruumiga klastri ette veel ühe suhteliselt väikese, mida nimetatakse fotovahemäludeks. See on sisuliselt lihtsalt vahemällu salvestav puhverserver.
Kuidas see seestpoolt toimib? Siin on meie kasutaja, siin on salvestusruum. Kõik on sama, mis enne. Mida me sinna vahele lisame?
See on lihtsalt füüsilise lokaalse kettaga masin, mis on kiire. Seda näiteks SSD-ga. Ja sellele kettale on salvestatud mingi kohalik vahemälu.
Kuidas see välja näeb? Kasutaja saadab soovi foto saamiseks. NGINX otsib seda esmalt kohalikust vahemälust. Kui ei, siis lihtsalt proxy_pass meie salvestusruumi, laadige foto sealt alla ja andke see kasutajale.
Kuid see on väga banaalne ja on ebaselge, mis sees toimub. See töötab midagi sellist.
Vahemälu on loogiliselt jagatud kolmeks kihiks. Kui ma ütlen "kolm kihti", ei tähenda see, et oleks mingisugune keeruline süsteem. Ei, need on tinglikult vaid kolm failisüsteemi kataloogi:
- See on puhver, kuhu lähevad puhverserverist alla laaditud fotod.
- See on kuum vahemälu, mis salvestab hetkel aktiivselt taotletud fotod.
- Ja külm vahemälu, kus fotod tõrjutakse järk-järgult kuumast vahemälust välja, kui neile tuleb vähem taotlusi.
Et see toimiks, peame seda vahemälu kuidagi haldama, selles olevaid fotosid ümber korraldama jne. See on ka väga primitiivne protsess.
Nginx kirjutab iga päringu jaoks lihtsalt faili RAMDisk access.log, kus see näitab foto tee, mida ta praegu on teenindanud (muidugi suhteline tee) ja millist partitsiooni seda teenindati. Need. see võib öelda "foto 1" ja seejärel kas puhver, kuum vahemälu, külm vahemälu või puhverserver.
Olenevalt sellest peame kuidagi otsustama, mida fotoga peale hakata.
Igas masinas töötab väike deemon, mis loeb pidevalt seda logi ja salvestab oma mällu statistikat teatud fotode kasutamise kohta.
Ta lihtsalt kogub seal, hoiab loendureid ja teeb perioodiliselt järgmist. Ta liigutab aktiivselt taotletud fotod, mille jaoks on palju taotlusi, kuuma vahemällu, kus iganes need ka poleks.
Fotod, mida taotletakse harva ja on muutunud harvemaks, lükatakse järk-järgult kuumast vahemälust välja külma.
Ja kui vahemälus ruum otsa saab, hakkame lihtsalt vahemälust kõike valimatult kustutama. Ja muide, see toimib hästi.
Selleks, et foto puhvrisse puhverdamisel kohe salvestatud saaks, kasutame käskkirja proxy_store ja puhvriks on samuti RAMDisk, st. kasutaja jaoks töötab see väga kiiresti. See puudutab vahemällu salvestava serveri enda sisemisi.
Ülejäänud küsimus on, kuidas taotlusi nende serverite vahel jagada.
Oletame, et seal on kahekümnest salvestusmasinast koosnev klaster ja kolm vahemällu salvestavat serverit (see juhtus nii).
Peame kuidagi kindlaks määrama, millised taotlused milliste fotode jaoks on ja kuhu need saadetakse.
Kõige tavalisem variant on Round Robin. Või teeb seda kogemata?
Sellel on ilmselgelt mitmeid puudusi, sest sellises olukorras kasutaksime vahemälu väga ebaefektiivselt. Päringud maanduvad mõnele juhuslikule masinale: siin oli see vahemällu salvestatud, kuid järgmisel pole seda enam. Ja kui see kõik töötab, on see väga halb. Isegi väikese arvu masinatega klastris.
Peame kuidagi üheselt kindlaks määrama, milline server millise päringu maandada.
On banaalne viis. Võtame räsi URL-ist või räsi meie jaotusvõtmest, mis on URL-is, ja jagame selle serverite arvuga. Kas töötab? Will.
Need. Meil on 2% päring, näiteks mõne “example_url” puhul satub see alati serverisse indeksiga “XNUMX” ja vahemälu utiliseeritakse pidevalt nii hästi kui võimalik.
Kuid sellise skeemi puhul on probleem uuesti killustamisega. Resharding – pean silmas serverite arvu muutmist.
Oletame, et meie vahemäluklaster ei saa enam hakkama ja otsustame lisada teise masina.
Lisame.
Nüüd jagub kõik mitte kolmega, vaid neljaga. Seega on peaaegu kõik võtmed, mis meil varem olid, ja peaaegu kõik URL-id nüüd teistes serverites. Kogu vahemälu tühistati lihtsalt hetkeks. Kõik taotlused langesid meie salvestusklastrile, see muutus halvaks, teenuse tõrkeks ja rahulolematuteks kasutajatele. Ma ei taha seda teha.
Meile ka see variant ei sobi.
See. mida me peaksime tegema? Peame kuidagi tõhusalt kasutama vahemälu, suunama sama päringu ikka ja jälle samasse serverisse, kuid olema vastupidav uuesti jaotamisele. Ja selline lahendus on olemas, see pole nii keeruline. Seda nimetatakse järjekindlaks räsimiseks.
Kuidas see välja näeb?
Võtame killustamisvõtmest mõne funktsiooni ja levitame kõik selle väärtused ringile. Need. punktis 0 lähenevad selle miinimum- ja maksimumväärtused. Järgmisena asetame kõik oma serverid samale ringile ligikaudu järgmiselt:
Iga server on määratletud ühe punktiga ja sellele päripäeva suunduvat sektorit teenindab see host. Kui meile päringud tulevad, näeme kohe, et näiteks päring A - sellel on seal räsi - ja seda teenindab server 2. Päring B - server 3. Ja nii edasi.
Mis juhtub sellises olukorras ümberjaotamise ajal?
Me ei muuda kogu vahemälu kehtetuks, nagu varem, ega nihuta kõiki klahve, vaid nihutame iga sektorit väikese vahemaa tagant, nii et meie kuues server, mida tahame lisada, mahuks vabasse ruumi ja suhteliselt. lisame selle sinna.
Loomulikult liiguvad sellises olukorras ka võtmed välja. Kuid nad liiguvad välja palju nõrgemalt kui varem. Ja me näeme, et meie kaks esimest võtit jäid nende serveritesse ja vahemällu salvestamise server muutus ainult viimase võtme jaoks. See töötab üsna tõhusalt ja kui lisate uusi hoste järk-järgult, pole siin suurt probleemi. Lisad ja lisad vähehaaval, ootad, kuni vahemälu jälle täis saab ja kõik toimib hästi.
Ainus küsimus jääb keeldumiste kohta. Oletame, et mingi auto on korrast ära.
Ja me ei tahaks praegu seda kaarti uuesti genereerida, osa vahemälust kehtetuks muuta ja nii edasi, kui näiteks masin taaskäivitati ja me peame kuidagi teenindustaotlusi rahuldama. Me lihtsalt hoiame igal saidil ühte varufoto vahemälu, mis asendab kõiki praegu maas olevaid masinaid. Ja kui äkki muutub mõni meie serveritest kättesaamatuks, läheb liiklus sinna. Loomulikult ei ole meil seal vahemälu, st. on külm, aga vähemalt kasutajate taotlusi töödeldakse. Kui see on lühike intervall, siis kogeme seda täiesti rahulikult. Talletusruumi on lihtsalt rohkem. Kui see intervall on pikk, siis saame juba otsustada - eemaldada see server kaardilt või mitte või asendada see mõne teisega.
See puudutab vahemälusüsteemi. Vaatame tulemusi.
Näib, et siin pole midagi keerulist. Kuid see vahemälu haldamise meetod andis meile umbes 98% trikkide määra. Need. sellest 80 tuhandest päringust sekundis jõuab ainult 1600 salvestusruumi ja see on täiesti normaalne koormus, nad taluvad seda rahulikult, meil on alati reserv.
Asetasime need serverid kolme oma DC-sse ja saime kolm kohalolekupunkti – Prahas, Miamis ja Hongkongis.
See. nad asuvad enam-vähem igal meie sihtturul kohapeal.
Ja mõnusaks boonuseks saime selle vahemällu salvestava puhverserveri, mille peal CPU tegelikult jõude on, sest sisu teenindamiseks pole seda nii vaja. Ja seal, kasutades NGINX+ Lua, rakendasime palju utilitaarset loogikat.
Näiteks saame katsetada webp või progressive jpeg-iga (need on tõhusad kaasaegsed vormingud), vaadata, kuidas see liiklust mõjutab, teha mingeid otsuseid, lubada seda teatud riikide jaoks jne; muutke dünaamilist suurust või kärpige fotosid lennult.
See on hea kasutusjuht, kui teil on näiteks mobiilirakendus, mis kuvab fotosid ja mobiilirakendus ei taha raisata kliendi protsessorit suure foto nõudmisele ja seejärel selle suuruse muutmisele, et see sisse suruda. vaade. Saame UPorti tingimuslikus URL-is lihtsalt dünaamiliselt määrata mõned parameetrid ja foto vahemälu muudab foto enda suurust. Reeglina valib see suuruse, mis meil füüsiliselt kettal on, võimalikult lähedase soovitud suurusele ja müüb selle konkreetsetes koordinaatides alla.
Muide, oleme teinud avalikult kättesaadavaks videosalvestused viimase viie aasta suure koormusega süsteemide arendajate konverentsist . Vaadake, õppige, jagage ja tellige .
Samuti saame sinna lisada palju tooteloogikat. Näiteks saame URL-i parameetrite abil lisada erinevaid vesimärke, saame hägustada, hägustada või pikseleerida fotosid. See on siis, kui me tahame näidata inimese fotot, kuid me ei taha näidata tema nägu, see toimib hästi, see kõik on siin rakendatud.
Mida me saime? Saime kolm kohalolekupunkti, hea trikisageduse ja samal ajal ei ole meil nendel masinatel tühikäigul töötavat protsessorit. Nüüd on ta muutunud loomulikult olulisemaks kui varem. Peame andma endale tugevamad autod, kuid see on seda väärt.
See puudutab fotode tagastamist. Siin on kõik üsna selge ja ilmne. Ma arvan, et ma ei avastanud Ameerikat, peaaegu iga CDN töötab sel viisil.
Ja suure tõenäosusega võib kogenud kuulajal tekkida küsimus: miks mitte muuta kõike lihtsalt CDN-iks? See oleks umbes sama; kõik kaasaegsed CDN-id saavad seda teha. Ja põhjuseid on mitmeid.
Esimene on fotod.
See on meie infrastruktuuri üks võtmepunkte ja me vajame selle üle võimalikult suurt kontrolli. Kui see on mingisugune lahendus kolmandast osapoolest müüjalt ja teil pole selle üle võimu, on teil üsna raske sellega elada, kui teil on suur andmekogum ja kui teil on väga suur voog kasutajate taotlustest.
Lubage mul tuua teile näide. Nüüd saame oma taristuga näiteks mingite probleemide või maa-aluste koputuste korral masina juurde minna ja seal suhteliselt möllama hakata. Saame lisada ainult meile vajalike mõõdikute kogumi, saame kuidagi katsetada, vaadata, kuidas see graafikuid mõjutab jne. Nüüd kogutakse selle vahemäluklastri kohta palju statistikat. Ja me vaatame seda perioodiliselt ja uurime pikka aega mõningaid kõrvalekaldeid. Kui see oleks CDN-i poolel, oleks seda palju raskem kontrollida. Või näiteks kui juhtub mingi õnnetus, siis me teame, mis juhtus, teame, kuidas sellega elada ja kuidas sellest üle saada. See on esimene järeldus.
Ka teine järeldus on pigem ajalooline, sest süsteem on pikalt arenenud ning erinevatel etappidel oli palju erinevaid ärinõudeid ning need ei sobi alati CDN kontseptsiooniga.
Ja point, mis eelmisest järeldub, on
Seda seetõttu, et fotode vahemäludes on meil palju spetsiifilist loogikat, mida ei saa alati soovi korral lisada. On ebatõenäoline, et mõni CDN lisab teile teie soovil kohandatud asju. Näiteks URL-ide krüptimine, kui te ei soovi, et klient saaks midagi muuta. Kas soovite serveri URL-i muuta ja krüpteerida ning seejärel saata siia mõned dünaamilised parameetrid?
Millisele järeldusele see viitab? Meie puhul pole CDN kuigi hea alternatiiv.
Ja teie puhul, kui teil on konkreetsed ärinõuded, võite täiesti rahulikult rakendada seda, mida ma teile näitasin. Ja see töötab suurepäraselt sarnase koormusprofiiliga.
Kuid kui teil on mingi üldine lahendus ja ülesanne pole väga konkreetne, võite täiesti ohutult võtta CDN-i. Või kui teie jaoks on aeg ja ressursid olulisemad kui kontroll.
Ja tänapäevastel CDN-idel on peaaegu kõik, millest ma teile nüüd rääkisin. Välja arvatud pluss või miinus mõned funktsioonid.
See puudutab fotode kinkimist.
Liigume nüüd oma retrospektiivis veidi edasi ja räägime ladustamisest.
2013 oli möödas.
Lisati vahemällu salvestavad serverid, jõudlusprobleemid kadusid. Kõik on korras. Andmekogum kasvab. 2013. aasta seisuga oli meil salvestusruumiga ühendatud umbes 80 serverit ja igas DC-s umbes 40 vahemällu salvestavat serverit. See on 560 terabaiti andmemahtu igal DC-l, st. kokku umbes petabait.
Andmestiku kasvuga hakkasid tegevuskulud märkimisväärselt tõusma. Mida see tähendas?
Sellel joonisel - SAN-iga, sellega ühendatud masinad ja vahemälud - on palju tõrkepunkte. Kui olime vahemällu salvestamise serverite rikkega juba varem tegelenud, siis oli kõik enam-vähem etteaimatav ja arusaadav, kuid salvestuse poolel oli kõik palju hullem.
Esiteks, Storage Area Network (SAN) ise, mis võib ebaõnnestuda.
Teiseks on see optika kaudu ühendatud lõppmasinatega. Probleeme võib esineda optiliste kaartide ja süüteküünaldega.
Muidugi pole neid nii palju kui SAN-i enda puhul, kuid sellegipoolest on need ka tõrkepunktid.
Järgmine on masin ise, mis on ühendatud salvestusruumiga. See võib ka ebaõnnestuda.
Kokku on meil kolm ebaõnnestumise punkti.
Lisaks tõrkekohtadele toimub ka hoiuruumi enda raske hooldus.
See on keerukas mitmekomponendiline süsteem ja süsteemiinseneridel võib sellega töötada raske.
Ja viimane, kõige olulisem punkt. Kui mõni neist kolmest punktist ebaõnnestub, on meil nullist erinev võimalus kasutajaandmete kaotamiseks, kuna failisüsteem võib kokku kukkuda.
Oletame, et meie failisüsteem on katki. Esiteks võtab selle taastamine kaua aega – suure andmehulga korral võib kuluda nädal. Ja teiseks, lõpuks saame suure tõenäosusega hunniku arusaamatuid faile, mis tuleb kuidagi kasutajafotodeks kombineerida. Ja me riskime andmete kaotamisega. Risk on üsna suur. Ja mida sagedamini selliseid olukordi juhtub ja mida rohkem probleeme kogu selles ahelas tekib, seda suurem on see risk.
Sellega tuli midagi ette võtta. Ja otsustasime, et peame lihtsalt andmed varundama. See on tegelikult ilmselge ja hea lahendus. Mida me oleme teinud?
Selline nägi meie server välja, kui see oli varem salvestusruumiga ühendatud. See on üks põhiosa, see on lihtsalt plokkseade, mis tegelikult kujutab endast optika kaudu kaugsalvestuse alust.
Lisasime just teise jaotise.
Asetasime selle kõrvale teise salvestusruumi (õnneks pole see rahaliselt nii kallis) ja nimetasime seda varupartitsiooniks. See on samuti ühendatud optika kaudu ja asub samas masinas. Kuid me peame nendevahelised andmed kuidagi sünkroonima.
Siin teeme lihtsalt läheduses asünkroonse järjekorra.
Ta ei ole väga hõivatud. Teame, et meil pole piisavalt rekordeid. Järjekord on MySQL-is lihtsalt tabel, kuhu on kirjutatud sellised read nagu "peate selle foto varundama". Mis tahes muudatuse või üleslaadimise korral kopeerime põhisektsioonist varukoopiasse, kasutades asünkroonset või lihtsalt mingit taustatöötajat.
Ja seega on meil alati kaks ühtset osa. Isegi kui selle süsteemi üks osa ebaõnnestub, saame alati põhisektsiooni muuta varukoopia abil ja kõik töötab edasi.
Kuid tänu sellele suureneb lugemiskoormus kõvasti, sest... lisaks klientidele, kes loevad põhiosast, sest nad vaatavad esmalt seal olevat fotot (seal on see värskem) ja siis otsivad seda varukoopiast, kui nad seda ei leidnud (aga NGINX teeb seda lihtsalt), meie süsteem on ka pluss-varukoopia, mida nüüd loetakse põhisektsioonist. Asi pole selles, et see oleks kitsaskoht, aga ma ei tahtnud koormust sisuliselt niisama tõsta.
Ja lisasime kolmanda ketta, mis on väike SSD, ja nimetasime seda puhvriks.
Kuidas see nüüd töötab.
Kasutaja laadib foto üles puhvrisse, seejärel visatakse järjekorda sündmus, mis näitab, et see tuleb kaheks osaks kopeerida. See kopeeritakse ja foto elab mõnda aega (näiteks päeva) puhvris ja alles siis kustutatakse sealt. See parandab oluliselt kasutajakogemust, sest kasutaja laadib foto üles, reeglina hakkavad kohe taotlused järgnema või uuendas ta ise lehte ja värskendas seda. Kuid kõik sõltub rakendusest, mis üles laadib.
Või näiteks teised inimesed, kellele ta end näitama hakkas, saadavad selle foto peale kohe päringuid. Seda pole veel vahemälus; esimene päring toimub väga kiiresti. Sisuliselt sama, mis fotode vahemälust. Aeglane ladustamine ei ole sellega üldse seotud. Ja kui päev hiljem see tühjendatakse, on see juba meie vahemälukihil vahemällu salvestatud või suure tõenäosusega pole seda enam kellelgi vaja. Need. Siinne kasutajakogemus on tänu sellistele lihtsatele manipulatsioonidele väga hästi kasvanud.
Noh, ja mis kõige tähtsam: me lõpetasime andmete kaotamise.
Ütleme nii, et me peatusime potentsiaalselt kaotada andmeid, sest me ei kaotanud neid tegelikult. Kuid oht oli olemas. Näeme, et see lahendus on loomulikult hea, kuid see on veidi nagu probleemi sümptomite silumine, selle asemel, et see täielikult lahendada. Ja mõned probleemid jäävad siia.
Esiteks on see tõrkepunkt füüsilise hosti enda näol, millel kogu see masinavärk töötab; see pole kuhugi kadunud.
Teiseks on endiselt probleemid SAN-idega, nende raske hooldus jms. Asi polnud selles, et see oli kriitiline tegur, aga ma tahtsin proovida kuidagi ilma selleta elada.
Ja me tegime kolmanda versiooni (tegelikult teise) - broneeringu versiooni. Kuidas see välja nägi?
See see oli -
Meie peamised probleemid on selles, et tegemist on füüsilise hostiga.
Esiteks eemaldame SAN-id, kuna tahame katsetada, tahame proovida ainult kohalikke kõvakettaid.
See on juba 2014-2015 ja sel ajal muutus olukord ketaste ja nende mahutavusega ühes hostis palju paremaks. Otsustasime, et miks mitte proovida.
Ja siis võtame lihtsalt oma varupartitsiooni ja teisaldame selle füüsiliselt eraldi masinasse.
Seega saame selle diagrammi. Meil on kaks autot, mis salvestavad samu andmekogumeid. Nad varundavad üksteist täielikult ja sünkroonivad andmeid võrgu kaudu sama MySQL-i asünkroonse järjekorra kaudu.
Miks see hästi töötab, on see, et meil on vähe kirjeid. Need. kui kirjutamine oleks võrreldav lugemisega, oleks meil ehk mingisugune võrgukoormus ja probleemid. Kirjutamist on vähe, lugemist palju – see meetod töötab hästi, st. Kopeerime fotosid nende kahe serveri vahel harva.
Kuidas see töötab, kui vaatate veidi üksikasjalikumalt.
Laadi üles. Tasakaalustaja valib lihtsalt paariga juhuslikud hostid ja laadib sellesse üles. Samal ajal teeb ta loomulikult tervisekontrolli ja jälgib, et auto välja ei kukuks. Need. ta laadib fotod üles ainult reaalajas serverisse ja seejärel kopeeritakse see kõik asünkroonse järjekorra kaudu tema naabrile. Üleslaadimisega on kõik väga lihtne.
Ülesanne on veidi keerulisem.
Lua aitas meid siin, sest sellise loogika loomine vanilje NGINX-is võib olla keeruline. Teeme esmalt päringu esimesse serverisse, vaatame, kas foto on seal, sest potentsiaalselt võiks see olla näiteks naabrile üles laetud, aga siia pole veel jõudnud. Kui foto on olemas, on see hea. Anname selle kohe kliendile ja võimaluse korral salvestame vahemällu.
Kui seda pole, siis teeme lihtsalt oma naabrile palve ja saame selle sealt garanteeritult kätte.
See. jällegi võime öelda: jõudlusega võib esineda probleeme, kuna toimuvad pidevad edasi-tagasi reisid - foto laaditi üles, seda pole siin, teeme ühe päringu asemel kaks, see peaks aeglaselt töötama.
Meie olukorras ei tööta see aeglaselt.
Kogume selle süsteemi kohta hulga mõõdikuid ja sellise mehhanismi tingimuslik nutikas määr on umbes 95%. Need. Selle varunduse mahajäämus on väike ja tänu sellele on meil peaaegu garanteeritud, et pärast foto üleslaadimist teeme selle esimest korda ja ei pea kaks korda kuhugi minema.
Mis meil siis veel väga lahedat on?
Varem oli meil peamine varupartitsioon ja me lugesime neid järjestikku. Need. Otsisime alati esmalt peamist ja seejärel varukoopiat. See oli üks liigutus.
Nüüd kasutame lugemist kahest masinast korraga. Jagame taotlusi Round Robini abil. Väikesel protsendil juhtudest esitame kaks taotlust. Kuid üldiselt on meil nüüd kaks korda rohkem lugemisvara kui varem. Ja koormus vähenes kõvasti nii saatemasinatel kui ka otse laomasinatel, mis meil ka tol ajal olid.
Mis puutub veataluvusse. Tegelikult me selle nimel põhiliselt võitlesimegi. Veataluvusega tuli siin kõik suurepäraselt välja.
Üks auto läheb katki.
Pole probleemi! Süsteemiinsener ei pruugi isegi öösel ärgata, ta ootab hommikuni, midagi hullu ei juhtu.
Kui isegi selle masina rikke korral on järjekord rivist väljas, pole ka probleeme, logi kogutakse lihtsalt esmalt elavale masinale ja seejärel lisatakse see järjekorda ja seejärel autosse, mis mõne aja pärast tööle minema.
Sama lugu hooldusega. Lülitame ühe masina lihtsalt välja, tõmbame selle käsitsi kõigist basseinidest välja, see lõpetab liikluse vastuvõtmise, teeme mingisuguse hoolduse, redigeerime midagi, siis tagastame selle hooldusesse ja see varukoopia jõuab üsna kiiresti järele. Need. päevas jõuab ühe auto seisakuaeg järele paari minutiga. Seda on tõesti väga vähe. Veataluvusega ütlen veel kord, et siin on kõik lahe.
Milliseid järeldusi saab sellest koondamisskeemist teha?
Meil on veataluvus.
Lihtne kasutada. Kuna masinatel on lokaalsed kõvakettad, on see sellega töötavatele inseneridele töö seisukohast palju mugavam.
Saime kahekordse lugemistoetuse.
See on väga hea boonus lisaks veataluvusele.
Kuid on ka probleeme. Nüüd on meil mõned sellega seotud funktsioonid palju keerulisemad, sest süsteem on lõpuks muutunud 100% ühtlaseks.
Peame näiteks mõnes taustatöös pidevalt mõtlema: "Mis serveris me praegu töötame?", "Kas siin on tõesti praegune foto?" jne. See kõik on muidugi kokku pakitud ja äriloogikat kirjutava programmeerija jaoks on see läbipaistev. Kuid sellegipoolest on see suur keeruline kiht tekkinud. Kuid oleme valmis sellega leppima, vastutasuks selle maiuspalade eest, mille saime.
Ja siin tekib taas mingi konflikt.
Ütlesin alguses, et kõike kohalikele kõvaketastele salvestamine on halb. Ja nüüd ütlen, et meile meeldis.
Jah, tõepoolest, aja jooksul on olukord palju muutunud ja nüüd on sellel lähenemisviisil palju eeliseid. Esiteks saame palju lihtsama toimingu.
Teiseks on see produktiivsem, sest meil pole neid automaatkontrollereid ega ühendusi kettariiulitega.
Masinaid on seal tohutult ja need on vaid mõned kettad, mis siin masinal reidiks kokku pannakse.
Kuid on ka miinuseid.
See on ligikaudu 1,5 korda kallim kui SAN-ide kasutamine isegi tänapäevaste hindade juures. Seetõttu otsustasime, et ei muuda julgelt kogu oma suurt kobarat kohalike kõvaketastega autodeks ja otsustasime hübriidlahenduse jätta.
Pooled meie masinatest töötavad kõvaketastega (no mitte pooled – ilmselt 30 protsenti). Ja ülejäänud on vanad autod, millel oli varem esimene broneerimisskeem. Paigaldasime need lihtsalt uuesti, kuna me ei vajanud uusi andmeid ega midagi muud, teisaldasime lihtsalt kinnitused ühelt füüsiliselt hostilt kahele.
Ja nüüd on meil suur lugemisvara ja me laiendasime seda. Kui varem paigaldasime ühele masinale ühe hoidla, siis nüüd ühele paarile näiteks neli. Ja see töötab hästi.
Teeme lühikokkuvõtte sellest, mida saavutasime, mille nimel võitlesime ja kas see õnnestus.
Tulemused
Meil on kasutajaid – lausa 33 miljonit.
Meil on kolm kohalolekupunkti – Praha, Miami, Hongkong.
Need sisaldavad vahemälukihti, mis koosneb kiirete kohalike ketastega (SSD) autodest, millel jooksevad lihtsad masinad NGINXist, selle access.log ja Pythoni deemonid, mis seda kõike töötlevad ja vahemälu haldavad.
Soovi korral oled oma projektis sees, kui fotod pole sinu jaoks nii kriitilised kui meie jaoks või kui kompromissi kontroll versus arenduskiirus ja ressursikulud on sinu jaoks hoopis teises suunas, siis võid need julgelt välja vahetada CDN-iga saavad tänapäevased CDN-id hästi hakkama.
Järgmisena tuleb salvestuskiht, millel on masinapaaride klastrid, mis varundavad üksteist, faile kopeeritakse asünkroonselt ühest teise, kui need muutuvad.
Lisaks töötavad mõned neist masinatest kohalike kõvaketastega.
Mõned neist masinatest on ühendatud SAN-idega.
Ja ühest küljest on seda mugavam kasutada ja veidi produktiivsem, teisalt on see mugav paigutustiheduse ja gigabaidihinna poolest.
See on nii lühike ülevaade arhitektuurist, mida me saime ja kuidas see kõik arenes.
Veel mõned näpunäited kaptenilt, väga lihtsad.
Esiteks, kui otsustate ootamatult, et peate kiiresti kõike oma fototaristut parandama, siis kõigepealt mõõtke, sest võib-olla pole vaja midagi parandada.
Lubage mul tuua teile näide. Meil on masinate klaster, mis saadab chattides manuste fotosid ja seal töötab skeem 2009. aastast ja keegi selle all ei kannata. Kõik on hästi, kõigile meeldib kõik.
Mõõtmiseks riputage kõigepealt üles hunnik mõõdikuid, vaadake neid ja seejärel otsustage, millega te pole rahul ja mida tuleks parandada. Selle mõõtmiseks on meil lahe tööriist Pinba.
See võimaldab teil koguda NGINX-ilt väga üksikasjalikku statistikat iga päringu ja vastuse koodide ning aegade jaotuse kohta – mida iganes soovite. Sellel on seosed kõikvõimalike erinevate analüüsisüsteemidega ja siis saab seda kõike ilusti vaadata.
Kõigepealt mõõtsime ära, siis parandasime.
Edasi. Me optimeerime lugemist vahemälu abil, kirjutamist killustamisega, kuid see on ilmne punkt.
Edasi. Kui alles hakkate oma süsteemi üles ehitama, on palju parem teha fotosid muutumatute failidena. Sest sa kaotad kohe terve klassi probleeme vahemälu kehtetuks tunnistamisega, sellega, kuidas loogika peaks leidma foto õige versiooni jne.
Oletame, et laadisite üles sada, seejärel pöörasite seda ja muutsite selle nii, et see oleks füüsiliselt erinev fail. Need. pole vaja mõelda: nüüd säästan natuke ruumi, kirjutan selle samasse faili, muudan versiooni. See ei tööta alati hästi ja põhjustab hiljem palju peavalu.
Järgmine punkt. Umbes käigupealt suuruse muutmise kohta.
Varem, kui kasutajad fotosid üles laadisid, lõikasime kohe terve hunniku suurusi igaks juhuks, erinevate klientide jaoks ja need olid kõik kettal. Nüüd oleme sellest loobunud.
Jätsime ainult kolm peamist suurust: väike, keskmine ja suur. Me lihtsalt vähendame kõike muud alates suurusest, mis on meilt Uportis küsitud suurusest tagapool, me lihtsalt teeme alaskaala ja anname selle kasutajale.
Vahemälukihi protsessor osutub siin palju odavamaks kui siis, kui me neid suurusi igal salvestusruumil pidevalt taastaksime. Oletame, et tahame lisada uue, see võtab kuu aega – käivitage kõikjal skript, mis teeks seda kõike korralikult, ilma klastrit hävitamata. Need. Kui teil on praegu võimalus valida, on parem teha võimalikult vähe füüsilisi suurusi, kuid nii, et vähemalt mingi jaotus oleks näiteks kolm. Ja kõike muud saab valmismoodulite abil lihtsalt käigupealt muuta. See kõik on nüüd väga lihtne ja kättesaadav.
Ja järkjärguline asünkroonne varundamine on hea.
Nagu meie praktika on näidanud, töötab see skeem suurepäraselt muudetud failide hilinenud kopeerimisega.
Viimane punkt on samuti ilmne. Kui teie infrastruktuuril praegu selliseid probleeme ei ole, kuid on midagi, mis võib puruneda, läheb see kindlasti katki, kui seda natuke rohkem saab. Seetõttu on parem sellele eelnevalt mõelda ja mitte kogeda sellega probleeme. See on kõik, mida ma öelda tahtsin.
Sidemed
»
»
See aruanne on suure koormusega süsteemide arendajate konverentsil peetud ühe parima kõne ärakiri . HighLoad++ 2017 konverentsini on jäänud vähem kui kuu.
Meil on see juba valmis , ajakava koostatakse praegu aktiivselt.
Sel aastal jätkame arhitektuuride ja skaleerimise teema uurimist:
- / Igor Vassiljev
- / Dmitri Jegorov
- / Anatoli Plaskovski
- / Roman Šehovtsov, Aleksei Gromatšikov
- / Philip Delgado
Kasutame mõnda neist materjalidest ka suure koormusega süsteemide arendamise veebipõhisel koolitusel on spetsiaalselt valitud kirjade, artiklite, materjalide, videote kett. Meie õpikus on juba üle 30 ainulaadse materjali. Ühendage!
Allikas: www.habr.com
