Artem Denisov ( , )
Badoo on maailman suurin treffisivusto. Meillä on tällä hetkellä noin 330 miljoonaa rekisteröityä käyttäjää maailmanlaajuisesti. Mutta paljon tärkeämpää tämänpäiväisen keskustelumme yhteydessä on se, että tallennamme noin 3 petatavua käyttäjäkuvia. Joka päivä käyttäjämme lataavat noin 3,5 miljoonaa uutta kuvaa, ja lukumäärä on noin 80 tuhatta pyyntöä sekunnissa. Tämä on melko paljon taustajärjestelmällemme, ja joskus tässä on vaikeuksia.
Puhun tämän kuvia tallentavan ja lähettävän järjestelmän suunnittelusta yleensä, ja katson sitä kehittäjän näkökulmasta. Sen kehittymisestä tulee lyhyt retrospektiivi, jossa hahmotan tärkeimmät virstanpylväät, mutta kerron vain tarkemmin tällä hetkellä käyttämistämme ratkaisuista.
Aloitetaan nyt.
Kuten sanoin, tämä on retrospektiivi, ja aloittaaksemme sen jostain, otetaan yleisin esimerkki.
Meillä on yhteinen tehtävä, meidän on hyväksyttävä, tallennettava ja lähetettävä käyttäjien kuvia. Tässä muodossa tehtävä on yleinen, voimme käyttää mitä tahansa:
- moderni pilvitallennus,
- laatikkoratkaisu, jota on myös nyt paljon;
- Voimme asentaa useita koneita palvelinkeskukseemme ja laittaa niihin suuria kiintolevyjä ja tallentaa valokuvia.
Badoo elää historiallisesti - sekä nyt että silloin (silloin, kun se oli vasta lapsenkengissään) - omilla palvelimillaan, omissa DC:issämme. Siksi tämä vaihtoehto oli meille optimaalinen.
Otimme vain useita koneita, kutsuimme niitä "valokuviksi", ja saimme klusterin, joka tallentaa valokuvia. Mutta jotain näyttää puuttuvan. Jotta tämä kaikki toimisi, meidän on jotenkin määritettävä, mihin koneeseen tallennamme valokuvat. Eikä tässäkään ole tarvetta avata Amerikkaa.
Lisäämme varastoihimme kentän, jossa on tietoja käyttäjistä. Tämä tulee olemaan sirpalointiavain. Meidän tapauksessamme kutsuimme sitä paikka_id:ksi, ja tämä paikkatunnus osoittaa paikkaan, johon käyttäjän valokuvat on tallennettu. Teemme karttoja.
Ensimmäisessä vaiheessa tämä voidaan tehdä jopa manuaalisesti - sanomme, että valokuva tästä käyttäjästä, jolla on tällainen paikka, laskeutuu tällaiselle palvelimelle. Tämän kartan ansiosta tiedämme aina, kun käyttäjä lataa kuvan, minne se tallennetaan ja tiedämme, mistä se annetaan.
Tämä on täysin triviaali järjestelmä, mutta sillä on melko merkittäviä etuja. Ensimmäinen on, että se on yksinkertainen, kuten sanoin, ja toinen on, että tällä lähestymistavalla voimme helposti skaalata vaakatasossa yksinkertaisesti toimittamalla uusia autoja ja lisäämällä ne kartalle. Sinun ei tarvitse tehdä mitään muuta.
Näin meillä oli jonkin aikaa.
Tämä oli noin vuonna 2009. He toimittivat autoja, toimittivat...
Ja jossain vaiheessa aloimme huomata, että tällä järjestelmällä on tiettyjä haittoja. Mitkä ovat haitat?
Ensinnäkin kapasiteetti on rajallinen. Emme voi ahtaa niin monta kiintolevyä yhdelle fyysiselle palvelimelle kuin haluaisimme. Ja tästä on tullut tietty ongelma ajan myötä ja tietojoukon kasvun myötä.
Ja toiseksi. Tämä on epätyypillinen koneiden kokoonpano, koska tällaisia koneita on vaikea käyttää uudelleen joissakin muissa klustereissa, ne ovat melko spesifisiä, ts. niiden pitäisi olla heikkoja suorituskyvyltään, mutta samalla suurella kiintolevyllä.
Tämä kaikki oli vuodelta 2009, mutta periaatteessa nämä vaatimukset ovat ajankohtaisia edelleen. Meillä on retrospektiivi, joten vuonna 2009 kaikki oli täysin huonosti tämän kanssa.
Ja viimeinen kohta on hinta.
Hinta oli tuolloin erittäin kova, ja meidän piti etsiä vaihtoehtoja. Nuo. piti jotenkin paremmin hyödyntää sekä palvelinkeskusten tilaa että fyysisiä palvelimia, joilla tämä kaikki sijaitsee. Ja järjestelmäsuunnittelijamme aloittivat laajan tutkimuksen, jossa he tarkastelivat joukon erilaisia vaihtoehtoja. He tarkastelivat myös klusteroituja tiedostojärjestelmiä, kuten PolyCeph ja Luster. Oli suorituskykyongelmia ja melko vaikeaa toimintaa. He kieltäytyivät. Yritimme asentaa koko tietojoukon NFS:n kautta jokaiseen autoon skaalataksemme sitä jotenkin. Myös lukeminen sujui huonosti, kokeilimme erilaisia ratkaisuja eri toimittajilta.
Ja lopulta päädyimme käyttämään niin sanottua Storage Area Networkia.
Nämä ovat suuria SHD-levyjä, jotka on suunniteltu erityisesti suurten tietomäärien tallentamiseen. Ne ovat hyllyjä, joissa on levyjä, jotka on asennettu lopullisiin optisiin lähtölaitteisiin. Että. meillä on jonkinlainen joukko koneita, melko pieniä, ja nämä SHD:t, jotka ovat läpinäkyviä lähetyslogiikallemme, ts. nginxillemme tai kenelle tahansa muulle palvelemaan näitä kuvia koskevia pyyntöjä.
Tällä päätöksellä oli ilmeisiä etuja. Tämä on SHD. Se on tarkoitettu kuvien tallentamiseen. Tämä on halvempaa kuin pelkkä koneiden varustaminen kiintolevyillä.
Toinen plussa.
Tämä johtuu siitä, että kapasiteetti on kasvanut paljon, ts. voimme majoittaa paljon enemmän tallennustilaa paljon pienemmällä tilavuudella.
Mutta oli myös haittoja, jotka ilmenivät melko nopeasti. Kun käyttäjien määrä ja tämän järjestelmän kuormitus kasvoivat, suorituskykyongelmia alkoi ilmetä. Ja ongelma on melko ilmeinen - mikä tahansa SHD, joka on suunniteltu tallentamaan monia valokuvia pienessä tilavuudessa, kärsii yleensä intensiivisestä lukemisesta. Tämä pätee itse asiassa mihin tahansa pilvitallennustilaan tai mihin tahansa muuhunkin. Nyt meillä ei ole ihanteellista tallennustilaa, joka olisi äärettömästi skaalautuva, siihen voisi laittaa mitä tahansa ja se kestäisi lukemia erittäin hyvin. Varsinkin satunnaisia lukemia.
Kuten kuviemmekin tapauksessa, koska kuvia pyydetään epäjohdonmukaisesti, mikä vaikuttaa suuresti niiden suorituskykyyn.
Jopa tämän päivän lukujen mukaan, jos saamme jossain yli 500 RPS kuvista koneella, johon on kytketty tallennustila, ongelmat alkavat jo. Ja se oli tarpeeksi huono meille, koska käyttäjien määrä kasvaa, asiat vain pahenevat. Tämä pitää jotenkin optimoida.
Optimoimiseksi päätimme tuolloin tietysti tarkastella kuormitusprofiilia - mitä yleensä tapahtuu, mitä on optimoitava.
Ja tässä kaikki on meidän käsissämme.
Sanoin jo ensimmäisessä diassa: meillä on 80 tuhatta lukupyyntöä sekunnissa ja vain 3,5 miljoonaa latausta päivässä. Eli tämä on kolmen suuruusluokan ero. On selvää, että lukeminen on optimoitava ja on käytännössä selvää, miten.
On vielä yksi pieni pointti. Palvelun erityispiirteet ovat sellaisia, että henkilö rekisteröityy, lataa kuvan, alkaa sitten aktiivisesti katsoa muita ihmisiä, pitää heistä ja näytetään aktiivisesti muille ihmisille. Sitten hän löytää kumppanin tai ei löydä kumppania, riippuu siitä, miten se käy, ja lopettaa palvelun käytön hetkeksi. Tällä hetkellä, kun hän käyttää sitä, hänen valokuvansa ovat erittäin kuumia - niillä on kysyntää, monet ihmiset katselevat niitä. Heti kun hän lopettaa tämän, hän putoaa melko nopeasti altistumisesta muille ihmisille, eikä hänen kuviaan juuri koskaan pyydetä.
Nuo. Meillä on hyvin pieni kuuma tietojoukko. Mutta samaan aikaan hänelle on paljon pyyntöjä. Ja täysin ilmeinen ratkaisu tähän on lisätä välimuisti.
Välimuisti LRU:n kanssa ratkaisee kaikki ongelmamme. Mitä olemme tekemässä?
Lisäämme toisen suhteellisen pienen suuren tallennusklusterin eteen, jota kutsutaan valokuvakätköiksi. Tämä on pohjimmiltaan vain välimuistipalvelin.
Miten se toimii sisältäpäin? Tässä on käyttäjämme, tässä on tallennustilaa. Kaikki on kuten ennenkin. Mitä lisäämme väliin?
Se on vain kone, jossa on fyysinen paikallinen levy, joka on nopea. Tämä on esimerkiksi SSD-levyn kanssa. Ja tälle levylle on tallennettu jonkinlainen paikallinen välimuisti.
Miltä se näyttää? Käyttäjä lähettää valokuvapyynnön. NGINX etsii sen ensin paikallisesta välimuistista. Jos ei, niin yksinkertaisesti proxy_pass tallennustilaamme, lataa valokuva sieltä ja anna se käyttäjälle.
Mutta tämä on hyvin banaali, ja on epäselvää, mitä sisällä tapahtuu. Se toimii jotenkin näin.
Välimuisti on loogisesti jaettu kolmeen kerrokseen. Kun sanon "kolme kerrosta", se ei tarkoita, että on olemassa jonkinlainen monimutkainen järjestelmä. Ei, nämä ovat ehdollisesti vain kolme tiedostojärjestelmän hakemistoa:
- Tämä on puskuri, johon välityspalvelimelta juuri ladatut valokuvat menevät.
- Tämä on kuuma välimuisti, joka tallentaa tällä hetkellä aktiivisesti pyydetyt valokuvat.
- Ja kylmäkätkö, jossa valokuvat työnnetään vähitellen pois kuumasta kätköstä, kun niihin tulee vähemmän pyyntöjä.
Jotta tämä toimisi, meidän on jotenkin hallittava tätä välimuistia, meidän on järjestettävä siinä olevat valokuvat jne. Tämä on myös hyvin primitiivinen prosessi.
Nginx yksinkertaisesti kirjoittaa RAMDisk access.logiin jokaiselle pyynnölle, jossa se osoittaa polun valokuvaan, jota se on tällä hetkellä palvellut (suhteellinen polku tietysti) ja mikä osio sitä palveli. Nuo. se voi sanoa "valokuva 1" ja sitten joko puskuri, kuuma välimuisti, kylmä välimuisti tai välityspalvelin.
Tästä riippuen meidän on jotenkin päätettävä, mitä valokuvalle tehdään.
Meillä on jokaisessa koneessa käynnissä pieni demoni, joka lukee jatkuvasti tätä lokia ja tallentaa muistiinsa tilastot tiettyjen valokuvien käytöstä.
Hän vain kerää siellä, pitää laskurit ja tekee ajoittain seuraavia asioita. Hän siirtää aktiivisesti pyydetyt valokuvat, joista on paljon pyyntöjä, kuumaan kätköön, missä ne ovatkin.
Harvemmin pyydetyt ja harvemmin pyydetyt valokuvat työnnetään vähitellen kuumasta kätköstä kylmään.
Ja kun välimuistin tila loppuu, alamme yksinkertaisesti poistaa kaiken kylmästä välimuistista umpimähkään. Ja tämä muuten toimii hyvin.
Jotta valokuva tallentuisi välittömästi välityspalvelimelle välitettäessä, käytämme proxy_store-direktiiviä ja puskuri on myös RAMDisk, ts. käyttäjälle se toimii erittäin nopeasti. Tämä koskee itse välimuistipalvelimen sisäisiä osia.
Jäljellä oleva kysymys on, kuinka pyynnöt jaetaan näiden palvelimien kesken.
Oletetaan, että siellä on kahdenkymmenen tallennuskoneen klusteri ja kolme välimuistipalvelinta (näin se tapahtui).
Meidän on jotenkin määritettävä, mitkä valokuvat koskevat pyynnöt ja mihin ne lähetetään.
Yleisin vaihtoehto on Round Robin. Vai tehdäänkö se vahingossa?
Tällä on ilmeisesti useita haittoja, koska käyttäisimme välimuistia erittäin tehottomasti tällaisessa tilanteessa. Pyynnöt laskeutuvat joillekin satunnaisille koneille: täällä se oli välimuistissa, mutta seuraavassa sitä ei enää ole. Ja jos tämä kaikki toimii, se on erittäin huono. Jopa pienellä määrällä koneita klusterissa.
Meidän on jotenkin yksiselitteisesti määritettävä, mikä palvelin lähettää minkäkin pyynnön.
On olemassa banaali tapa. Otamme tiivisteen URL-osoitteesta tai hajautusavaimen, joka on URL-osoitteessa, ja jaamme sen palvelimien lukumäärällä. Toimii? Tahtoa.
Nuo. Meillä on 2-prosenttinen pyyntö, esimerkiksi jollekin "example_url" -osoitteelle se laskeutuu aina palvelimelle indeksillä "XNUMX", ja välimuistia hävitetään jatkuvasti mahdollisimman hyvin.
Mutta tällaisessa järjestelmässä on ongelma uudelleensharjoituksessa. Uudelleenjako – tarkoitan palvelimien määrän muuttamista.
Oletetaan, että välimuistiklusterimme ei enää kestä ja päätämme lisätä toisen koneen.
Lisätään.
Nyt kaikki ei ole jaollinen kolmella, vaan neljällä. Näin ollen lähes kaikki avaimet, jotka meillä oli aiemmin, lähes kaikki URL-osoitteet ovat nyt muilla palvelimilla. Koko välimuisti mitätöitiin yksinkertaisesti hetkeksi. Kaikki pyynnöt putosivat tallennusklusteriimme, siitä tuli huonovointisuus, palveluhäiriö ja tyytymättömät käyttäjät. En halua tehdä sitä.
Tämä vaihtoehto ei myöskään sovi meille.
Että. mitä meidän pitäisi tehdä? Meidän on jollain tapaa hyödynnettävä tehokkaasti välimuistia, saatava sama pyyntö samalle palvelimelle yhä uudelleen ja uudelleen, mutta vastustettava uudelleen sirpaloitumista. Ja on olemassa sellainen ratkaisu, se ei ole niin monimutkaista. Sitä kutsutaan johdonmukaiseksi hajautusjärjestelmäksi.
Mitä se näyttää?
Otamme jonkin funktion sirpalointiavaimesta ja levitämme kaikki sen arvot ympyrään. Nuo. pisteessä 0 sen minimi- ja maksimiarvot lähentyvät. Seuraavaksi sijoitamme kaikki palvelimemme samaan ympyrään suunnilleen näin:
Jokainen palvelin on määritelty yhdellä pisteellä, ja vastaavasti myötäpäivään menevää sektoria palvelee tämä isäntä. Kun meille tulee pyyntöjä, näemme heti, että esimerkiksi pyyntö A - siinä on hash - ja sitä palvelee palvelin 2. Pyyntö B - palvelin 3. Ja niin edelleen.
Mitä tässä tilanteessa tapahtuu uudelleenhajottamisen aikana?
Emme mitätöi koko välimuistia, kuten ennen, emmekä siirrä kaikkia avaimia, vaan siirrämme jokaista sektoria lyhyen matkan, jotta suhteellisesti sanottuna kuudes palvelimemme, jonka haluamme lisätä, mahtuu vapaaseen tilaan ja lisäämme sen sinne.
Tietysti tällaisessa tilanteessa myös avaimet liikkuvat pois. Mutta he siirtyvät ulos paljon heikommin kuin ennen. Ja näemme, että kaksi ensimmäistä avaimemme jäivät palvelimilleen, ja välimuistipalvelin vaihtui vain viimeiselle avaimelle. Tämä toimii melko tehokkaasti, ja jos lisäät uusia isäntiä vähitellen, tässä ei ole suuria ongelmia. Lisäät ja lisäät vähän kerrallaan, odotat kunnes välimuisti on taas täynnä, ja kaikki toimii hyvin.
Ainoa kysymys on kieltäytymisestä. Oletetaan, että jokin auto on epäkunnossa.
Emmekä todellakaan haluaisi luoda tätä karttaa uudelleen tällä hetkellä, mitätöidä osaa välimuistista ja niin edelleen, jos esimerkiksi kone käynnistetään uudelleen ja meidän on jotenkin tehtävä palvelupyyntöjä. Säilytämme jokaisessa sivustossa vain yhden varmuuskopion valokuvavälimuistin, joka korvaa kaikki tällä hetkellä alasajoissa olevat koneet. Ja jos yhtäkkiä jokin palvelimistamme ei ole käytettävissä, liikenne menee sinne. Luonnollisesti meillä ei ole siellä mitään välimuistia, ts. on kylmä, mutta ainakin käyttäjien pyyntöjä käsitellään. Jos tämä on lyhyt väli, koemme sen täysin rauhallisesti. Säilytystilaa on vain enemmän. Jos tämä aikaväli on pitkä, voimme jo tehdä päätöksen - poistaako tämä palvelin kartalta vai ei, tai kenties korvata se toisella.
Tämä koskee välimuistijärjestelmää. Katsotaanpa tuloksia.
Vaikuttaa siltä, että tässä ei ole mitään monimutkaista. Mutta tämä välimuistin hallintamenetelmä antoi meille noin 98 prosentin temppuprosentin. Nuo. näistä 80 tuhannesta pyynnöstä sekunnissa vain 1600 saavuttaa varaston, ja tämä on täysin normaali kuormitus, he kestävät sen rauhallisesti, meillä on aina varaus.
Sijoitimme nämä palvelimet kolmeen DC:ään ja saimme kolme läsnäolopistettä - Praha, Miami ja Hong Kong.
Että. ne sijaitsevat enemmän tai vähemmän paikallisesti jokaisella kohdemarkkinallamme.
Ja mukavana bonuksena saimme tämän välimuistipalvelimen, jolla prosessori on itse asiassa tyhjäkäynnillä, koska sitä ei niin paljon tarvita sisällön tarjoamiseen. Ja siellä NGINX+ Luaa käyttämällä toteutimme paljon utilitaristista logiikkaa.
Voimme esimerkiksi kokeilla webp:tä tai progressiivista jpegia (nämä ovat tehokkaita moderneja muotoja), nähdä kuinka se vaikuttaa liikenteeseen, tehdä päätöksiä, ottaa se käyttöön tietyissä maissa jne.; muuta dynaamista kokoa tai rajaa valokuvia lennossa.
Tämä on hyvä käyttötapa, kun sinulla on esimerkiksi mobiilisovellus, joka näyttää kuvia, eikä mobiilisovellus halua tuhlata asiakkaan prosessoria pyytämään isoa valokuvaa ja muuttamaan sen sitten tiettyyn kokoon työntääkseen sen sisään. näkymä. Voimme yksinkertaisesti määrittää dynaamisesti joitain parametreja UPortin ehdolliseen URL-osoitteeseen, ja valokuvavälimuisti muuttaa itse valokuvan kokoa. Yleensä se valitsee koon, joka meillä on fyysisesti levyllä, mahdollisimman lähellä pyydettyä, ja myy sen tietyissä koordinaateissa.
Muuten, olemme tehneet julkisesti saataville videotallenteita korkean kuormituksen järjestelmien kehittäjien konferenssista viimeisen viiden vuoden aikana. . Katso, opi, jaa ja tilaa .
Voimme myös lisätä siihen paljon tuotelogiikkaa. Voimme esimerkiksi lisätä erilaisia vesileimoja käyttämällä URL-parametreja, voimme sumentaa, sumentaa tai pikselöidä valokuvia. Tämä on silloin, kun haluamme näyttää valokuvan henkilöstä, mutta emme halua näyttää hänen kasvojaan, tämä toimii hyvin, kaikki on toteutettu täällä.
Mitä saimme? Meillä on kolme läsnäolopistettä, hyvä temppunopeus, ja samalla meillä ei ole käyttämättömänä suoritinta näissä koneissa. Hänestä on nyt tietysti tullut tärkeämpi kuin ennen. Meidän on annettava itsellemme vahvempia autoja, mutta se on sen arvoista.
Tämä koskee valokuvien palauttamista. Kaikki täällä on melko selvää ja selvää. Luulen, että en löytänyt Amerikkaa, melkein mikä tahansa CDN toimii tällä tavalla.
Ja mitä todennäköisimmin hienostuneella kuuntelijalla saattaa olla kysymys: miksi ei vain muuttaisi kaikkea CDN:ksi? Se olisi suunnilleen sama; kaikki nykyaikaiset CDN: t voivat tehdä tämän. Ja siihen on useita syitä.
Ensimmäinen on valokuvat.
Tämä on yksi infrastruktuurimme avainkohdista, ja tarvitsemme sen mahdollisimman paljon hallintaa. Jos tämä on jonkinlainen ratkaisu kolmannen osapuolen toimittajalta, eikä sinulla ole siihen valtaa, sinun on melko vaikea elää sen kanssa, kun sinulla on suuri tietojoukko ja kun sinulla on erittäin suuri tietovirta käyttäjien pyynnöistä.
Annan sinulle esimerkin. Nyt infrastruktuurimme avulla voimme esimerkiksi joidenkin ongelmien tai maanalaisten kolhujen sattuessa mennä koneelle ja sotkea siellä suhteellisesti sanottuna. Voimme lisätä vain tarvitsemiemme mittareiden kokoelman, voimme kokeilla jollakin tavalla, nähdä kuinka tämä vaikuttaa kaavioihin ja niin edelleen. Nyt tästä välimuistiklusterista kerätään paljon tilastoja. Ja katsomme sitä ajoittain ja vietämme pitkän aikaa joidenkin poikkeavuuksien tutkimiseen. Jos se olisi CDN-puolella, sitä olisi paljon vaikeampi hallita. Tai esimerkiksi jos sattuu jonkinlainen onnettomuus, tiedämme mitä tapahtui, tiedämme kuinka elää sen kanssa ja miten siitä selvitään. Tämä on ensimmäinen johtopäätös.
Toinen päätelmä on myös melko historiallinen, koska järjestelmää on kehitetty pitkään ja eri vaiheissa oli monia erilaisia liiketoimintavaatimuksia, jotka eivät aina sovi CDN-konseptiin.
Ja pointti, joka seuraa edellisestä on
Tämä johtuu siitä, että valokuvakätköissä on paljon erityistä logiikkaa, jota ei aina voida lisätä pyynnöstä. On epätodennäköistä, että mikään CDN lisää sinulle mukautettuja asioita pyynnöstäsi. Esimerkiksi URL-osoitteiden salaaminen, jos et halua, että asiakas voi muuttaa jotain. Haluatko muuttaa palvelimen URL-osoitetta ja salata sen ja lähettää sitten joitain dynaamisia parametreja tänne.
Mihin johtopäätökseen tämä viittaa? Meidän tapauksessamme CDN ei ole kovin hyvä vaihtoehto.
Ja sinun tapauksessasi, jos sinulla on erityisiä liiketoimintavaatimuksia, voit melko helposti toteuttaa sen, mitä näytin sinulle itse. Ja tämä toimii täydellisesti samanlaisen kuormitusprofiilin kanssa.
Mutta jos sinulla on jonkinlainen yleinen ratkaisu, ja tehtävä ei ole kovin tarkka, voit ehdottomasti ottaa CDN:n. Tai jos aika ja resurssit ovat sinulle tärkeämpiä kuin hallinta.
Ja nykyaikaisissa CDN-verkoissa on melkein kaikki, mistä kerroin sinulle nyt. Lukuun ottamatta plus tai miinus joitakin ominaisuuksia.
Tässä on kyse kuvien luovuttamisesta.
Mennään nyt hieman eteenpäin retrospektiivissämme ja puhutaan varastoinnista.
2013 meni ohi.
Välimuistipalvelimet lisättiin, suorituskykyongelmat poistuivat. Kaikki on hyvin. Tietokanta kasvaa. Vuodesta 2013 lähtien meillä oli noin 80 palvelinta yhdistettynä tallennustilaan ja noin 40 välimuistia kussakin DC:ssä. Tämä on 560 teratavua dataa jokaisella DC:llä, ts. yhteensä noin petatavu.
Ja tietojoukon kasvun myötä käyttökustannukset alkoivat nousta merkittävästi. Mitä tämä tarkoitti?
Tässä piirretyssä kaaviossa - SAN-verkolla, johon on kytketty koneet ja välimuistit - on paljon vikakohtia. Jos olimme jo käsitelleet välimuistipalvelimien epäonnistumista aiemmin, kaikki oli enemmän tai vähemmän ennustettavaa ja ymmärrettävää, mutta tallennuspuolella kaikki oli paljon huonompaa.
Ensinnäkin itse Storage Area Network (SAN), joka voi epäonnistua.
Toiseksi se on kytketty optiikan kautta päätykoneisiin. Optisissa korteissa ja sytytystulpissa voi olla ongelmia.
Niitä ei tietenkään ole niin paljon kuin itse SAN:ssa, mutta kuitenkin nämä ovat myös epäonnistumiskohtia.
Seuraavana on itse kone, joka on kytketty varastoon. Se voi myös epäonnistua.
Yhteensä meillä on kolme epäonnistumispistettä.
Edelleen, vikakohtien lisäksi, itse varastointia huolletaan raskaasti.
Tämä on monimutkainen monikomponenttinen järjestelmä, ja järjestelmäsuunnittelijoilla voi olla vaikeuksia työskennellä sen kanssa.
Ja viimeinen, tärkein kohta. Jos vika ilmenee jossakin näistä kolmesta kohdasta, meillä on nollasta poikkeava mahdollisuus menettää käyttäjätietoja, koska tiedostojärjestelmä saattaa kaatua.
Oletetaan, että tiedostojärjestelmämme on rikki. Ensinnäkin sen toipuminen kestää kauan - suurella tietomäärällä voi kestää viikon. Ja toiseksi, lopulta päädymme todennäköisesti joukkoon käsittämättömiä tiedostoja, jotka on jotenkin yhdistettävä käyttäjien valokuviin. Ja vaarana on tietojen menettäminen. Riski on melko korkea. Ja mitä useammin tällaisia tilanteita tapahtuu, ja mitä enemmän ongelmia syntyy koko ketjussa, sitä suurempi tämä riski on.
Asialle oli tehtävä jotain. Ja päätimme, että meidän täytyy vain varmuuskopioida tiedot. Tämä on itse asiassa ilmeinen ja hyvä ratkaisu. Mitä me olemme tehneet?
Tältä palvelimemme näytti, kun se oli aiemmin yhdistetty tallennustilaan. Tämä on yksi pääosa, se on vain lohkolaite, joka itse asiassa edustaa telinettä etätallennusta varten optiikan kautta.
Lisäsimme juuri toisen osion.
Sijoitimme sen viereen toisen tallennustilan (onneksi se ei ole niin kallis rahassa mitattuna) ja kutsuimme sitä varaosioiksi. Se on myös kytketty optiikan kautta ja sijaitsee samassa koneessa. Mutta meidän on jotenkin synkronoitava tiedot niiden välillä.
Täällä teemme yksinkertaisesti asynkronisen jonon lähelle.
Hän ei ole kovin kiireinen. Tiedämme, ettei meillä ole tarpeeksi levyjä. Jono on vain taulukko MySQL:ssä, johon on kirjoitettu rivit, kuten "sinun täytyy varmuuskopioida tämä valokuva". Jokaisen muutoksen tai latauksen yhteydessä kopioimme pääosiosta varmuuskopioon käyttämällä asynkronista tai vain jonkinlaista taustatyöntekijää.
Ja siksi meillä on aina kaksi johdonmukaista osiota. Vaikka jokin tämän järjestelmän osa epäonnistuisi, voimme aina vaihtaa pääosion varmuuskopiolla, ja kaikki toimii edelleen.
Mutta tämän vuoksi lukukuorma kasvaa huomattavasti, koska... pääosiosta lukevien asiakkaiden lisäksi, koska he katsovat ensin siellä olevaa valokuvaa (se on tuoreempi siellä) ja etsivät sen sitten varmuuskopiosta, jos he eivät ole löytäneet sitä (mutta NGINX vain tekee tämän), järjestelmämme on myös plus-varmuuskopio, joka nyt lukee pääosiosta. Kyse ei ole siitä, että tämä olisi ollut pullonkaula, mutta en halunnut lisätä kuormitusta, periaatteessa vain niin.
Ja lisäsimme kolmannen levyn, joka on pieni SSD, ja kutsuimme sitä puskuriksi.
Miten se nyt toimii.
Käyttäjä lataa valokuvan puskuriin, minkä jälkeen jonoon heitetään tapahtuma, joka ilmoittaa, että se on kopioitava kahteen osaan. Se kopioidaan ja valokuva elää puskurissa jonkin aikaa (esim. päivän), ja vasta sitten se poistetaan sieltä. Tämä parantaa huomattavasti käyttökokemusta, koska käyttäjä lataa valokuvan, yleensä pyynnöt alkavat seurata välittömästi, tai hän itse päivitti sivun ja päivitti sen. Mutta kaikki riippuu sovelluksesta, joka tekee latauksen.
Tai esimerkiksi muut ihmiset, joille hän alkoi näyttää itseään, lähettävät välittömästi pyyntöjä tämän kuvan jälkeen. Se ei ole vielä välimuistissa; ensimmäinen pyyntö tapahtuu hyvin nopeasti. Pohjimmiltaan sama kuin valokuvavälimuistista. Hidas varastointi ei liity tähän ollenkaan. Ja kun päivää myöhemmin se tyhjennetään, se on jo joko välimuistissa välimuistitasollamme tai todennäköisimmin kukaan ei tarvitse sitä enää. Nuo. Käyttökokemus täällä on kasvanut erittäin hyvin tällaisten yksinkertaisten manipulaatioiden ansiosta.
No, ja mikä tärkeintä: lopetimme tietojen menettämisen.
Sanotaanpa, että pysähdyimme mahdollisesti menettää tietoja, koska emme todellakaan menettäneet niitä. Mutta vaara oli olemassa. Näemme, että tämä ratkaisu on tietysti hyvä, mutta se on vähän kuin ongelman oireiden tasoittamista sen sijaan, että se ratkaisisi sen kokonaan. Ja joitain ongelmia on edelleen täällä.
Ensinnäkin tämä on epäonnistumispiste itse fyysisen isännän muodossa, jolla kaikki tämä koneisto toimii; se ei ole kadonnut.
Toiseksi SAN-verkkojen kanssa on edelleen ongelmia, niiden raskas huolto jne. on jäljellä. Se ei ollut kriittinen tekijä, mutta halusin yrittää jotenkin elää ilman sitä.
Ja teimme kolmannen version (itse asiassa toisen) - varausversion. Miltä se näytti?
Tätä se oli -
Suurin ongelmamme liittyy siihen, että tämä on fyysinen isäntä.
Ensinnäkin poistamme SAN:t, koska haluamme kokeilla, haluamme kokeilla vain paikallisia kiintolevyjä.
Tämä on jo 2014-2015, ja tuolloin tilanne levyjen ja niiden kapasiteetin kanssa yhdessä isännässä parani huomattavasti. Päätimme, miksi emme kokeilisi sitä.
Ja sitten otamme vain varmuuskopioosiomme ja siirrämme sen fyysisesti erilliseen koneeseen.
Siten saamme tämän kaavion. Meillä on kaksi autoa, jotka tallentavat samat tietojoukot. Ne varmuuskopioivat toisensa kokonaan ja synkronoivat tiedot verkon kautta asynkronisen jonon kautta samassa MySQL:ssä.
Miksi tämä toimii hyvin, johtuu siitä, että meillä on vähän tietueita. Nuo. jos kirjoittaminen olisi verrattavissa lukemiseen, meillä olisi ehkä jonkinlaista verkkokuluja ja ongelmia. Kirjoittamista on vähän, lukemista paljon - tämä menetelmä toimii hyvin, ts. Kopioimme harvoin valokuvia näiden kahden palvelimen välillä.
Miten tämä toimii, jos katsot hieman tarkemmin.
Lataa. Tasapainotin yksinkertaisesti valitsee satunnaiset isännät parin kanssa ja lataa siihen. Samalla hän tekee luonnollisesti terveystarkastuksia ja varmistaa, ettei auto putoa. Nuo. hän lataa kuvia vain live-palvelimelle, ja sitten asynkronisen jonon kautta kaikki kopioidaan hänen naapurilleen. Latauksella kaikki on erittäin yksinkertaista.
Tehtävä on hieman vaikeampi.
Lua auttoi meitä tässä, koska voi olla vaikeaa tehdä tällaista logiikkaa vanilla NGINX: llä. Teemme ensin pyynnön ensimmäiselle palvelimelle, katsotaanko kuva siellä, koska mahdollisesti se voidaan ladata vaikkapa naapurille, mutta ei ole vielä saapunut tänne. Jos kuva on siellä, se on hyvä. Annamme sen välittömästi asiakkaalle ja mahdollisesti tallennamme sen välimuistiin.
Jos sitä ei ole, teemme pyynnön naapurillemme ja saamme sen taatusti sieltä.
Että. jälleen voimme sanoa: suorituskyvyssä voi olla ongelmia, koska meno-paluumatkoja on jatkuvasti - kuva ladattiin, se ei ole täällä, teemme kaksi pyyntöä yhden sijaan, tämän pitäisi toimia hitaasti.
Meidän tilanteessamme tämä ei toimi hitaasti.
Keräämme joukon mittareita tästä järjestelmästä, ja tällaisen mekanismin ehdollinen älykäs osuus on noin 95%. Nuo. Tämän varmuuskopion viive on pieni, ja tästä johtuen olemme melkein varmoja, että valokuvan latauksen jälkeen otamme sen ensimmäisen kerran, eikä meidän tarvitse mennä kahdesti minnekään.
Joten mitä muuta meillä on todella siistiä?
Aiemmin meillä oli päävarmuuskopioosio, ja luimme niistä peräkkäin. Nuo. Etsimme aina ensin päähakua ja sitten varmuuskopiota. Se oli yksi liike.
Nyt hyödynnämme lukemista kahdelta koneelta kerralla. Jaamme pyynnöt Round Robinilla. Pienessä osassa tapauksia teemme kaksi pyyntöä. Mutta kaiken kaikkiaan meillä on nyt kaksi kertaa enemmän lukuvarastoa kuin ennen. Ja kuormitus väheni huomattavasti sekä lähetyskoneissa että suoraan varastokoneissa, joita meilläkin tuolloin oli.
Mitä tulee vikasietoisuuteen. Itse asiassa tämän puolesta taistelimme pääasiassa. Vikasietokyvyllä kaikki sujui täällä hienosti.
Yksi auto hajoaa.
Ei ongelmaa! Järjestelmäinsinööri ei ehkä edes herää yöllä, hän odottaa aamuun asti, mitään pahaa ei tapahdu.
Jos vaikka tämä kone epäonnistuu, jono on epäkunnossa, ei myöskään ongelmia, loki yksinkertaisesti kertyy ensin elävälle koneelle ja sitten se lisätään jonoon ja sitten autoon, joka ottaa käyttöön jonkin ajan kuluttua.
Huollon kanssa sama juttu. Sammutamme vain yhden koneen, vedämme sen manuaalisesti ulos kaikista altaista, se lakkaa vastaanottamasta liikennettä, teemme jonkinlaista huoltoa, muokkaamme jotain, sitten palaamme sen huoltoon, ja tämä varmuuskopio saa kiinni melko nopeasti. Nuo. päivässä yhden auton seisokki kestää muutamassa minuutissa. Tämä on todella vähän. Toistan vikasietoisuudella, että täällä on kaikki siistiä.
Mitä johtopäätöksiä tästä irtisanomissuunnitelmasta voidaan tehdä?
Meillä on vikasietokyky.
Helppokäyttöinen. Koska koneissa on paikalliset kiintolevyt, tämä on toiminnan kannalta paljon kätevämpää sen kanssa työskenteleville insinööreille.
Saimme kaksinkertaisen lukukorvauksen.
Tämä on erittäin hyvä bonus vikasietoisuuden lisäksi.
Mutta on myös ongelmia. Nyt meillä on paljon monimutkaisempi kehitys joitakin tähän liittyviä ominaisuuksia, koska järjestelmä on tullut lopulta 100% yhtenäiseksi.
Meidän täytyy esimerkiksi jossain taustatyössä jatkuvasti miettiä: "Millä palvelimella me nyt pyörimme?", "Onko täällä todellakin nykyinen valokuva?" jne. Tämä on tietysti kaikki tiivistettynä, ja liiketoimintalogiikkaa kirjoittavalle ohjelmoijalle se on läpinäkyvää. Mutta siitä huolimatta tämä suuri monimutkainen kerros on ilmestynyt. Mutta olemme valmiita sietämään tätä vastineeksi siitä saamistamme herkuista.
Ja tässä taas syntyy ristiriita.
Sanoin alussa, että kaiken tallentaminen paikallisille kiintolevyille on huono. Ja nyt sanon, että pidimme siitä.
Kyllä, todellakin, ajan myötä tilanne on muuttunut paljon, ja nyt tällä lähestymistavalla on monia etuja. Ensinnäkin saamme paljon yksinkertaisemman toiminnan.
Toiseksi se on tuottavampaa, koska meillä ei ole näitä automaattisia ohjaimia tai yhteyksiä levyhyllyihin.
Siellä on valtava määrä koneita, ja nämä ovat vain muutamia levyjä, jotka on koottu tänne koneeseen raidiksi.
Mutta on myös haittoja.
Tämä on noin 1,5 kertaa kalliimpaa kuin SAN-verkkojen käyttö jopa nykyhinnoilla. Siksi päätimme olla rohkeasti muuttamatta koko suurta klusteriamme paikallisilla kiintolevyillä varustetuiksi autoiksi ja päätimme jättää hybridiratkaisun.
Puolet koneistamme toimii kiintolevyillä (no, ei puolet - luultavasti 30 prosenttia). Ja loput ovat vanhoja autoja, joilla oli ensimmäinen varausjärjestelmä. Asensimme ne yksinkertaisesti uudelleen, koska emme tarvinneet uusia tietoja tai mitään muuta, siirsimme vain kiinnikkeet yhdestä fyysisestä isännästä kahteen.
Ja meillä on nyt suuri määrä luettavaa, ja laajensimme sitä. Jos aiemmin yhdelle koneelle asennettiin yksi säilytystila, niin nyt yhdelle parille esimerkiksi neljä. Ja se toimii hyvin.
Otetaan lyhyt yhteenveto siitä, mitä saimme aikaan, minkä puolesta taistelimme ja onnistuimmeko.
Tulokset
Meillä on käyttäjiä – jopa 33 miljoonaa.
Meillä on kolme läsnäolopistettä - Praha, Miami, Hong Kong.
Ne sisältävät välimuistikerroksen, joka koostuu autoista, joissa on nopeat paikalliset levyt (SSD), joilla pyörivät yksinkertaiset NGINX-koneet, sen access.log- ja Python-daemonit, jotka käsittelevät kaiken tämän ja hallitsevat välimuistia.
Halutessasi olet mukana projektissasi, jos valokuvat eivät ole sinulle yhtä kriittisiä kuin meille, tai jos kompromissien hallinta suhteessa kehitysnopeuteen ja resurssikustannuksiin on sinulle päinvastaisessa suunnassa, voit turvallisesti korvata sen CDN:llä modernit CDN:t pärjäävät hyvin.
Seuraavaksi tulee tallennuskerros, jossa meillä on klustereita konepareista, jotka varmuuskopioivat toisiaan, tiedostot kopioidaan asynkronisesti yhdestä toiseen aina, kun ne muuttuvat.
Lisäksi jotkut näistä koneista toimivat paikallisten kiintolevyjen kanssa.
Jotkut näistä koneista on kytketty SAN-verkkoihin.
Ja toisaalta se on kätevämpi käyttää ja hieman tuottavampi, toisaalta se on kätevä sijoitustiheyden ja gigatavun hinnan suhteen.
Tämä on niin lyhyt katsaus arkkitehtuuriin, mitä saimme ja miten se kaikki kehittyi.
Muutama vinkki lisää kapteenilta, hyvin yksinkertaisia.
Ensinnäkin, jos päätät yhtäkkiä, että sinun on kiireesti parannettava kaikkea valokuvainfrastruktuurissasi, mittaa ensin, koska ehkä mitään ei tarvitse parantaa.
Annan sinulle esimerkin. Meillä on koneklusteri, joka lähettää kuvia liitteistä chatissa, ja järjestelmä on toiminut siellä vuodesta 2009, eikä kukaan kärsi siitä. Kaikki voivat hyvin, kaikki pitävät kaikesta.
Mittaamista varten ripusta ensin joukko mittareita, katso niitä ja päätä sitten, mihin olet tyytymätön ja mitä on parannettava. Tämän mittaamiseksi meillä on hieno työkalu nimeltä Pinba.
Sen avulla voit kerätä erittäin yksityiskohtaisia tilastoja NGINX:ltä jokaisesta pyyntö- ja vastauskoodista sekä aikojen jakautumisesta - mitä haluat. Siinä on sidoksia kaikenlaisiin erilaisiin analytiikkajärjestelmiin, ja sitten voit katsoa sitä kaikkea kauniisti.
Ensin mittasimme sen, sitten paransimme sitä.
Edelleen. Optimoimme lukemisen välimuistin avulla, kirjoittamisen sirpaloinnin avulla, mutta tämä on ilmeinen asia.
Edelleen. Jos olet vasta aloittamassa järjestelmän rakentamista, on paljon parempi tehdä valokuvia muuttumattomina tiedostoina. Koska menetät välittömästi kokonaisen luokan ongelmia välimuistin mitätöinnissä, siinä, kuinka logiikan pitäisi löytää oikea versio valokuvasta ja niin edelleen.
Oletetaan, että latasit sata kappaletta, käänsit sen sitten niin, että se oli fyysisesti erilainen tiedosto. Nuo. ei tarvitse ajatella: nyt säästän vähän tilaa, kirjoitan sen samaan tiedostoon, vaihdan versiota. Tämä ei aina toimi hyvin ja aiheuttaa myöhemmin paljon päänsärkyä.
Seuraava kohta. Tietoja koon muuttamisesta lennossa.
Aiemmin, kun käyttäjät ladasivat valokuvan, leikkasimme heti koko joukon kokoja kaikkiin tilanteisiin, eri asiakkaille, ja ne olivat kaikki levyllä. Nyt olemme luopuneet tästä.
Jätimme vain kolme pääkokoa: pieni, keskikokoinen ja suuri. Me yksinkertaisesti pienennämme kaikkea muuta siitä koosta, joka on meille Uportissa pyydetyn koon takana, teemme skaalauksen ja annamme sen käyttäjälle.
Välimuistikerroksen prosessori tässä osoittautuu paljon halvemmaksi kuin jos luomme jatkuvasti nämä koot jokaiseen tallennustilaan. Oletetaan, että haluamme lisätä uuden, tämä kestää kuukauden – aja kaikkialla skripti, joka tekisi kaiken tämän siististi tuhoamatta klusteria. Nuo. Jos sinulla on nyt mahdollisuus valita, on parempi tehdä mahdollisimman vähän fyysisiä kokoja, mutta niin, että ainakin osa jakelusta on esimerkiksi kolme. Ja kaiken muun kokoa voidaan yksinkertaisesti muuttaa lennossa valmiiden moduulien avulla. Kaikki on nyt erittäin helppoa ja saatavilla.
Ja inkrementaalinen asynkroninen varmuuskopiointi on hyvä.
Kuten käytäntömme on osoittanut, tämä malli toimii erinomaisesti muuttuneiden tiedostojen viivästetyssä kopioinnissa.
Viimeinen kohta on myös ilmeinen. Jos infrastruktuurissasi ei ole tällaisia ongelmia nyt, mutta jokin voi rikkoutua, se rikkoutuu varmasti, kun sitä tulee hieman enemmän. Siksi on parempi ajatella tätä etukäteen eikä kokea ongelmia sen kanssa. Siinä kaikki, mitä halusin sanoa.
yhteystiedot
»
»
Tämä raportti on transkriptio yhdestä parhaista puheista korkean kuormituksen järjestelmien kehittäjien konferenssissa . HighLoad++ 2017 -konferenssiin on enää vajaa kuukausi.
Meillä on se jo valmiina , aikataulua laaditaan nyt aktiivisesti.
Tänä vuonna jatkamme arkkitehtuurien ja skaalauksen tutkimista:
- / Igor Vasiljev
- / Dmitri Jegorov
- / Anatoli Plaskovski
- / Roman Shekhovtsov, Aleksei Gromatšikov
- / Philip Delgado
Käytämme joitain näistä materiaaleista myös verkkokoulutuksessamme korkean kuormituksen järjestelmien kehittämisestä on ketju erityisesti valittuja kirjeitä, artikkeleita, materiaaleja ja videoita. Oppikirjassamme on jo yli 30 ainutlaatuista materiaalia. Kytkeä!
Lähde: will.com