Artem Denisov ( , )
Badoo on maailma suurim tutvumisportaal. Meil on praegu registreeritud umbes 330 miljonit kasutajat kogu maailmas. Kuid, mis on meie tänase arutelu kontekstis palju olulisem, on see, et hoiame umbes 3 petabaiti kasutajafotosid. Igal päeval laadivad meie kasutajad üles umbes 3,5 miljonit uut fotot ja lugemise koormus on umbes 80 tuhat päringut sekundis. See on meie tagaplaanile piisavalt suur koormus ja sellega on aeg-ajalt probleeme.
Räägin süsteemi kujundusest, mis hoiab ja jagab fotosid üldiselt, ning tutvustan seda arendaja vaatenurgast. Kuidas see arenes, tuleb lühike ülevaade, kus ma määratlen peamised verstapostid, kuid räägin põhjalikumalt vaid nendest lahendustest, mida me praegu kasutame.
Nii et alustame.
Nagu ma juba ütlesin, on see retrospektiiv, ja et alustada, võtame kõige tavalisema näite.
Meil on üldine ülesanne, peame vastu võtma, hoidma ja jagama kasutajate fotosid. Sellisel kujul on ülesanne üldine, saame kasutada mida iganes:
- kaasaegset pilvepõhist salvestust,
- karbivälisel lahendusel, mida on nüüd samuti palju;
- võime üles seada mitu masinat oma andmekeskuses ja paigaldada neile suured kõvaketaste, et hoida fotosid seal.
Badoo ajaloos – nii praegu kui tollal (ajal, mil see alles algas) – elab meieenda serverites, meie enda andmekeskustes. Seetõttu oli see variant meile optimaalseim.
Me lihtsalt võtsime mitu masinat, nimetasime need "photos" ja saime klastrit, mis hoiab fotosid. Kuid tundub, et millestki on puudu. Selleks, et kõik see töötaks, tuleb kuidagi määratleda, millisel masinal hoitakse milliseid fotosid. Ja siin ei pea Ameerikat taasavastama.
Lisame oma salvestusse kasutaja teabe juurde mingi välja. See on sharding'i võti. Meie puhul nimetatakse seda place_id-ks ja see id näitab kohta, kus hoitakse kasutajate fotosid. Loome kaardid.
Esimesel etapil saab seda isegi käsitsi teha - me räägime, et selle kasutaja foto sellise kohaga maandub sellisel serveril. Tänu sellele kaardile teame alati, kui kasutaja üles laadib foto, kuhu see salvestada, ja teame, kust seda jagada.
See on täiesti triviaalne skeem, kuid sellel on üsna olulised plussid. Esiteks, see on lihtne, nagu ma juba ütlesin, ja teiseks, sellise lähenemisega saame hõlpsasti horisontaalselt skaleeruda, lihtsalt toomise uued masinad ja lisades nad kaardile. Rohkem teha ei ole vaja.
Nii töötasime mõnda aega.
See oli kuskil 2009. aastal. Saime masinaid, toimetasime…
Ja mingil hetkel hakkasime märkama, et sellel skeemil on teatud puudused. Millised puudused?
Esiteks on piiratud mahutavus. Ühele füüsilisele serverile ei saa me paigutada nii palju kõvaketaste kui sooviksime. Ja see on aja jooksul ja andmestiku kasvades muutunud tõeliseks probleemiks.
Teiseks. See on ebatüüpiline seadmete konfiguratsioon, kuna selliseid masinaid on raske kasutada mõnes teises klastris, nad on üsna spetsiifilised, st nad peavad olema madala jõudlusega, kuid samas suurte kõvaketastega.
See kõik leidis aset 2009. aastal, kuid tegelikult on need nõudmised endiselt aktuaalsed. Meie retrospektiivis oli 2009. aastal kõik selle osas halb.
Ja viimane punkt – hind.
Hind oli siis üsna kõrge ja pidime otsima mingeid alternatiive. St pidiime kuidagi paremini ka kasutama nii ruumi andmekeskustes kui ka füüsilisi servereid, millel see kõik paikneb. Meie süsteemi insenerid alustasid suurt uurimistööd, kus nad vaatasid mitmeid erinevaid variante. Nad uurisid klasterpõhiseid failisüsteeme, nagu PolyCeph ja Lustre. Seal olid jõudluse probleemid ja selle haldamine oli üsna keeruline. Lõpetasid. Proovisime mountida kogu andmestiku NFS-i kaudu iga masina juurde, et sel moel kuidagi skaleerida. Lugemine ei sujunud ka hästi, proovisime eri lahendusi erinevatelt tarnijatelt.
Ja lõpuks otsustasime, et hakkame kasutama nii nimetatud Storage Area Network.
Need on suured SHD-d, mis on mõeldud suurte andmemahtude säilitamiseks. Need on ketaste riiulid, mis on ühendatud lõpptootmismasinatele optiliselt. Seega, meil on väike masinate grupp, ja need SHD-d, mis on meie lõpptootmisloogika, st meie nginx-i või kellegi muu jaoks läbipaistvad, teenindavad päringuid nende piltide taga.
Selle lahenduse eelised olid ilmsed. See on SHD. See on suunatud piltide säilitamisele. See on odavam kui lihtsalt seadistada masinad kõvaketastega.
Teine eelis.
See on see, et mahutavus on suurenenud, st me saame palju rohkem salvestusruumi väiksemas mahus mahutada.
Aga kiiresti ilmus ka miinuseid. Kasutajate arvu ja süsteemi koormuse suurenemisega hakkasid tekkima jõudlusprobleemid. Probleem on mõistetav — iga SHD, mis on mõeldud paljude piltide hoidmiseks väikeses mahus, kannatab tavaliselt intensiivse lugemise all. See on tõsi ka igasuguste pilvesalvestuste puhul. Praegu ei ole meil ideaalset salvestust, mis oleks piiramatult skaleeritav ja kuhu võiks kõike talletada, et see taluks väga hästi lugemist. Eriti juhuslikku lugemist.
Nagu meie fotode puhul, kuna fotosid küsitakse ebaühtlaselt, mõjutab see nende jõudlust oluliselt.
Ieven kui täna, kui meil langetab kusagil rohkem kui 500 RPS fotodele masin, millega salvestus on ühendatud, algavad juba probleemid. See oli meile murettekitav, kuna kasutajate arv kasvab ja olukord peaks vaid halvenema. Peame sellega kuidagi optimeerima.
Optimeerimiseks otsustasime siis vaadata koormusprofiili — mis täpselt toimub, mida on vaja optimeerida.
Ja kõik mängib meile kasuks.
Olen esimeses slaidis juba maininud: meil on 80 000 lugemispäringut sekundis ning ainult 3,5 miljonit üleslaadimist päevas. Seega on vahe kolm korda. Ilmselgelt on vaja optimeerida lugemist ja praktiliselt on selge, kuidas seda teha.
On veel üks väike nüanss. Teenuse iseloom on selline, et inimene registreerib end, üles laadib foto, seejärel hakkab aktiivselt teiste inimesi vaatama, nende postitusi nagu, ja teda näidatakse aktiivselt teistele. Siis ta leiab omale paarilise või mitte, see sõltub sellest, kuidas läheb, ja teatud ajaks lõpetab teenuse kasutamise. Just sel hetkel, kui ta teenust kasutab, on tema pildid väga palavikuline — neid nõutakse ja neid vaatab väga palju inimesi. Kui ta sellest tegevusest loobub, langeb ta kiiresti neist intensiivsetest näidustest, nagu varem, ja tema pilte praktiliselt ei küsita.
Seega, meil on väga väike kuum andmestik. Kuid sellel on siiski väga palju päringuid. Ja täiesti loogiline lahendus on koodi lisamine.
Caching LRU lahendab kõik meie probleemid. Mida me teeme?
Me lisame meie suure salvestusklastri ette veel ühe suhteliselt väikese, mida nimetatakse fotokettaks (photoscache). See on sisuliselt lihtsalt vahemälu proks.
Kuidas see seestpoolt töötab? See on kasutaja, see on salvestus. Kõik nagu varem. Mida me nende vahele lisame?
See on lihtsalt masin koos kiire füüsilise kohaliku kettaga. See on SSD, näiteks. Ja sellel kettal hoitakse mingit kohalikku vahemälu.
Kuidas see välja näeb? Kasutaja saadab päringu foto saamiseks. NGINX otsib seda esmalt kohalikust vahemälust. Kui ei, siis teeb lihtsalt proxy_pass meie salvestusele, laadib foto sealt alla ja annab selle kasutajale.
Aga see on väga lihtne ja arusaamatu, mis seestpoolt toimub. See töötab umbes nii.
Vahemälu on loogiliselt jagatud kolmeks tasemeks. Kui ma ütlen "kolm taset", ei tähenda see, et seal on mingi keeruline süsteem. Ei, seal on tinglikult lihtsalt kolm katalooge failisüsteemis:
- See on puhversalvestus, kuhu satuvad just proksist alla laaditud fotod.
- See on kuum vahemälu, kus hoitakse aktiivselt hinnatud fotosid.
- Ja külm vahemälu, kuhu järk-järgult tõukatakse fotosid kuumast vahemälust, kui neile jõuab vähem päringuid.
Kuna see töötab, peame kuidagi seda vahemälu haldama, peame fotosid seal ringi liigutama jne. See on samuti väga primitiivne protsess.
Nginx kirjutab iga päringu kohta RAMDiskile access.log, kus ta märgib tee fotoni, mida ta hetkel teenindab (ilma kahteta, suhteline tee) ja samuti selle, millise osaga see teenindati. Näiteks võib seal olla kirjas "foto 1" ning edasi on või siis vahemälu, kuum vahemälu, külm vahemälu või proxy.
Sõltuvalt sellest peame kuidagi otsustama, mida fotoga teha.
Igal masinal töötab väike daemon, mis pidevalt loeb seda logi ja hoiab oma mälus statistikat kasutatud fotode kohta.
See lihtsalt kogub andmeid, juhib loendureid ja perioodiliselt teeb järgmist: aktiivselt küsitavaid fotosid, millele tuleb palju päringuid, tõukab ta kuuma vahemällu, kus nad ka ei asu.
Fotod, mida küsitakse harva ja mis on muutunud veel harvemaks, tõukab ta tasapisi külma vahemälust välja.
Ja kui meie vahemälus ei ole enam ruumi, hakkame lihtsalt külmast vahemälust kõike segamatult kustutama. Ja see töötab muide väga hästi.
Kuna foto salvestatakse kohe vahemällu proxy'imise ajal, kasutame direktiivi proxy_store ja vahemälu — see on samuti RAMDisk, nii et kasutaja jaoks töötab see väga kiiresti. See, mis puudutab tõeliselt vahemälu serveri sisemust.
Küsimus on jäänud, kuidas hajutada päringuid nende serverite vahel.
Oletame, et meil on kaheksateist storage-masinat ja kolm vahemälu serverit (nii juhtub).
Peame kuidagi määrama, millised päringud on milliste fotode jaoks ja kuhu need suunata.
Kõige lihtsam variant — see on Round Robin. Või teha seda juhuslikult?
Ilmselgelt on sel olnud mitmeid puudusi, kuna sellises olukorras ei kasutataks vahemälu efektiivselt. Päringud maanduvad juhuslikel masinatel: siin on see vahemälus, aga naaber masinas ei ole seda. Ja see kõik töötab kui töötab, siis väga halvasti. Isegi väikese masinate arvu puhul klastris.
Peame leidma mõne viisi, kuidas ühemõtteliselt määrata, millisele serverile suunata üks või teine päring.
On üks lihtne viis. Me võtame URL'ist hash'i või meie jagamisvõtme hash'i, mis on URL'is, ja jagame selle tervikuna serverite arvuga. Kas see töötab? Jah.
St me ei tingimata identifitseerime päringu, näiteks mõne "example_url", alati maandub serveris, mille indeks on "2", ja vahemälu kasutatakse pidevalt paremini.
Kuid sellises skeemis tekib probleem uuesti jagamisega. Uuesti jagamine — ma mõtlen serverite arvu muutmist.
Oletame, et meie vahemälu klaster ei suutnud enam hakkama saada ja otsustasime lisada ühe masina.
Lisa.
Meil on nüüd kogu see jaotamine mitte enam kolmekümnele, vaid neljale. Nii et praktiliselt kõik meie võtmed, mis me varem olime, praktiliselt kõik URL'id elavad nüüd teistes serverites. Kogu vahemälu kehtetuks, lihtsalt hetkega. Kõik päringud jooksid meie klastrisse-storage, see hakkas halvasti töötama ja rahulolematud kasutajad. Seda ei soovi me teha.
See variant ei sobi meile samuti.
Nii et mida me peame tegema? Peame leidma viisi, kuidas tõhusalt kasutada vahemälu, pidevalt suunama ühe päringu sama serveri suunas, kuid samas olema uuesti jagamisele vastupidavad. Ja selline lahendus on olemas, see pole just keeruline. Seda kutsutakse pidevaks hashimiseks.
Kuidas see välja näeb?
Me võtame mingisuguse funktsiooni jagamisvõtmest ja jagame kõik selle väärtused ringil. St punktis 0 on meil nende minimaalsed ja maksimaalsed väärtused. Jätkame ringil kõigi meie serverite paigutamisega umbes selliselt:
Iga server määratakse ühe punktiga, ja see sektor, mis kulgeb kellaosuti suunas kuni temani, teenindatakse vastavalt sellele hostile. Kui meile tulevad päringud, näeme kohe, et näiteks päring A — selle hash on selline — ja selle teenindab server 2. Päring B — serveri 3. Ja nii edasi.
Mis toimub sel juhul uuesti jagamisel?
Me ei kehtesta kogu vahemälu, nagu varem, ja ei nihuta kõiki võtmeid, vaid nihutame iga sektori väikese vahemaa võrra, et vabasse ruumi, tinglikult öeldes, mahuks meie kuues server, mille tahame lisada, ja lisame selle sinna.
Muidugi, sellises olukorras võtmed nihkuvad samuti. Kuid nad nihkuvad palju vähem kui varem. Ja me näeme, et meie esimesed kaks võtmed on jäänud oma serverites, ja ainult viimane võtme jaoks on server vahemällu muutunud. See töötab üsna tõhusalt, ja kui te lisate uusi hoste järk-järgult, siis pole siin suurt probleemi. Lisage järk-järgult, oodake, kuni vahemälu uuesti täitub ja kõik töötab hästi.
Ainult üks küsimus jääb alles, kui tegemist on riketega. Oletame, et meil on mingisugune masin rikki läinud.
Ja me ei tahaks selles olukorras kaarti ümber genereerida, tühistada osa vahemälust jne, kui näiteks masin on taaskäivitatud ja meil on mingil moel vaja teenindada päringuid. Me hoiame lihtsalt igas asukohas üht varukoopiat, mis toimib asendajana igasugusele masinale, mis on hetkel rikki läinud. Ja kui mõni meie server mingil hetkel muutub kättesaamatuks, liigub liiklus sinna. Meil ei ole seal loomulikult mingit vahemälu, see on külm, aga vähemalt töötavad kasutajate päringud. Kui see on lühike intervall, siis me saame selle täiesti rahulikult üle elada. Lihtsalt suureneb koormus salvestusele. Kui intervall on pikk, saame juba otsustada — kas eemaldada see server kaardilt või mitte, või äkki asendada see millegi muuga.
See oli vahemälusüsteemi kohta. Vaadakem tulemusi.
Tundub, et siin pole midagi keerulist. Kuid selline lähenemine vahemälu haldamisele andis meile umbes 98% hitrate'i. See tähendab, et neist 80 000 päringust sekundis jõuab ainult 1600 salvestustele, ja see on täiesti normaalne koormus, nad taluvad seda rahulikult, meil on alati varu.
Me paigutasime need serverid kolmes meie andmekeskuses ja saime kolm kohaloleku punkti — Praha, Miami ja Hongkong.
Nii on nad enam-vähem paiknenud igaühe meie sihtturgude lähedal.
Ja meeldiva boonuse osana saime selle vahemäluproxy, mille CPU on tegelikult throughout, kuna sisu edastamiseks ei ole see nii vajalik. Ja seal oleme NGINX+ Lua abil rakendanud palju utiliitide loogikat.
Näiteks saame katsetada webp või progressive jpeg (need on tõhusad kaasaegsed formaadid), vaadata, kuidas see mõjutab liiklust, teha mingeid otsuseid, lubada teatud riikides jne; teha dünaamilist suuruse muutmist või fotosid kärpida reaalajas.
See on hea kasutusjuht, näiteks kui teil on mobiilirakendus, mis kuvab fotosid, ja mobiilirakendus ei soovi klientide CPU-d raisata, et küsida suurt fotot ja seejärel selle suurust vähendada, et see mahtuda vaateaknasse. Saame lihtsalt dünaamiliselt URL-is määrata mõningaid parameetreid ja fotovahemälu kärbib foto ise. Tüüpiliselt valib see suuruse, mis meil füüsiliselt kettal on, maksimaalselt lähedase taotletavale, ja skaleerib selle konkreetsetes koordinaatides.
Muide, oleme teinud viimaste viie aasta arendajate konverentside videosalvestused avalikuks. Vaadake, uurige, jagage ja tellige meie .
Samuti saame sinna lisada palju tooteloogikat. Näiteks saame URL parameetrite põhjal lisada erinevaid vesimärke, saame fotosid uduseks muuta, udune või piksliline. See on siis, kui soovime näidata inimese fotot, kuid mitte näidata tema nägu, see töötab hästi, kõik on siin realiseeritud.
Mida me saavutasime? Saime kolm kohaloleku punkti, hea hitrate, ja samal ajal ei seisa CPU nende masinate peal. See on nüüd kindlasti olulisem kui varem. Me peame panema endale võimsamad masinad, aga see on seda väärt.
See on see, mis puudutab fotode edastamist. Siin on kõik piisavalt selge ja ilmselge. Arvan, et ei ole avanud Ameerikat, nii töötab praktiliselt iga CDN.
Ja tõenäoliselt võiks kogenud kuulajal tekkida küsimus: miks mitte lihtsalt võtta ja vahetada kõik CDN-iks? See oleks umbes sama, kõik kaasaegsed CDNd oskavad seda. Ja siin on mõned põhjused.
Esiteks — need on fotod.
See on üks meie infrastruktuuri võtmeelemente, ja meil on vaja nende üle võimalikult palju kontrolli. Kui see on mingisugune lahendus kolmandalt osapoolelt, ja teil ei ole selle üle mingit võimu, on teiega sellel rasket elada, kui teil on suur andmestik ja väga suur kasutajate päringute voog.
Toodan näite. Praegu oma infrastruktuuris saame näiteks, kui tekivad mingid probleemid või maapinna helid, minna masinasse ja seal vigade parandust teha, nii-öelda. Saame lisada kogumise teatud meetrikatest, mis on vaid meile olulised, ning katsetada, vaadata, kuidas see graafikutele mõjub jne. Praegu kogutakse selle vahemälu klastriga palju statistikat. Ja me vaatame seda perioodiliselt ning uurime põhjalikult teatud anomaaliaid. Kui see oleks CDN-i poolel, oleks palju raskem kontrollida. Või näiteks, kui juhtub mingi avarii, teame, mida teha, teame, kuidas sellega toime tulla ja seda ületada. See on esimene järeldus.
Teine järeldus on pigem ajalooline, kuna süsteem on juba pikka aega arenenud ja erinevaid ärinõudeid on olnud erinevatel etappidel, ning need ei mahu alati CDN-i kontseptsiooni.
Ja punkt, mis tuleneb eelmisest –
See, et meie fotoväcache'ides on palju spetsiifilist loogikat, mida ei saa alati lisada soovi korral. Vähesed CDN-id lisaksid teie palve peale mingeid kohandusi. Näiteks URL-ide krüpteerimine, kui te ei soovi, et klient saaks midagi muuta. Soovite muuta URL-i serveris ja krüpteerida selle ning seejärel edastada mingeid dünaamilisi parameetreid.
Kumb järeldus toob? Meie puhul ei ole CDN väga hea alternatiiv.
Teie puhul, kui teil on spetsiifilised ärinõuded, saate täiesti rahulikult ellu viia seda, mida ma teile näitasin. Ja see töötab suurepäraselt sarnaste koormusprofiilide korral.
Aga kui teil on mingi üldine lahendus ja probleem ei ole väga eriline, võite täiesti rahulikult valida CDN-i. Või kui teie jaoks on piiratud aeg ja ressursid tähtsamad kui kontroll.
Ja kaasaegsed CDN-id omavad praktiliselt kõike seda, millest ma teile praegu rääkisin. V.a mõned funktsioonid.
See oli rääkides piltide edastamisest.
Liigume nüüd natuke edasi meie retrospektiivis ja räägime ladustamisest.
Aasta 2013.
Vahemälu serverid on lisandunud, jõudlusprobleemid on kadunud. Kõik on hästi. Dataset kasvab. 2013. aastal oli meil umbes 80 serverit, mis olid ühendatud salvestusseadmetega, ja umbes 40 vahemälu igas DС-s. See on 560 terabaiti andmeid igas DС-s, st kokku umbes petabait.
Ja koos dataset'i kasvuga hakkasid operatsioonikulud tõsiselt kasvama. Milles see väljendus?
Selles skeemis, mis on joonistatud - SAN-iga, selle juurde ühendatud masinate ja vahemäludega - on väga palju rikkeid. Kui me juba leppisime kokku vahemälu serverite riketega, seal on kõik enam-vähem ennustatav ja arusaadav, siis salvestusseadmest oli olukord palju halvem.
Esiteks, ise Storage Area Network (SAN), mis võib ebaõnnestuda.
Teiseks, see on ühendatud optikaga lõppmasinatega. Võivad olla probleemid optiliste kaartide ja lülititega.
Nende hulk, muidugi, ei ole nii suur kui SAN-i enda puhul, kuid siiski on need ka rikke kohad.
Järgmine, masin, mis on ühendatud salvestusseadmega. Ka see võib ebaõnnestuda.
Seega on meil kolm rikke kohta.
Lisaks rikke kohtadele on ka salvestusseadmete keeruline hooldus.
See on keeruline koostisosade süsteem, ja süsteeminseneridel on selle haldamine keeruline.
Ja viimane, kõige olulisem punkt. Kui mis tahes kolmandas punktis juhtub rike, on meil olemas mitte-null tõenäosus kaotada kasutajaandmeid, kuna failisüsteem võib kahjustuda.
Oletame, et meil on failisüsteem kahjustunud. Selle taastamine võtab aega, eeskujuks, võib see kesta nädal aega suure andmemahtude puhul. Ja teiseks, lõppkokkuvõttes saame tõenäoliselt palju arusaamatuid faile, mida tuleb kasutajate piltidega mingil moel kokku sobitada. Ja me riskime andmete kaotamisega. Risk on piisavalt kõrge. Ja mida sagedamini sellised olukorrad juhtuvad, ja mida rohkem probleeme kogu selles ahelas tekib, seda suurem on see risk.
Sellega pidi midagi tegema. Otsustasime, et peame lihtsalt andmed varundama. See on tegelikult ilmne ja hea lahendus. Mida me tegime?
Nii välja nägi meie server, mis oli varem ühendatud salvestusseadmega. See oli üks peamine partitsioon, see on lihtsalt blokiseade, mis tõeliselt esindab kaugel asuvat salvestusseadet optiliselt.
Lihtsalt lisasime teise partitsiooni.
Me installisime kõrvale teise salvestusseadme (õnneks ei ole see rahaliselt väga kallis) ja nimetasime selle varukoopia partitsiooniks. See on samuti ühendatud optikaga, sama masin on seal. Kuid peame nende andmeid mingil moel sünkroonima.
Siin teeme lihtsalt kõrval asünkroonse järjekorra.
See ei ole väga koormatud. Me teame, et meil on vähe записи. Ootejärjekord on lihtsalt tabel MySQLis, kuhu kirjutatakse read, nagu „on vaja varundada see foto“. Iga muudatuse või üleslaadimise korral kopeerime põhiosast varundusse asünkroonselt või lihtsalt mingi taustatöötaja abil.
Nii saame alati kaks konsistentset osa. Isegi kui üks osa sellest süsteemist tõrkub, saame alati vahetada põhiosa varunduse vastu ja kõik töötab jätkuvalt.
Kuid seetõttu suureneb oluliselt lugemise koormus, kuna lisaks klientidele, kes loevad põhiosast, sest nad vaatavad esialgu fotot seal (see on ju ajakohasem), otsivad nad varundusest, kui nad ei leia (aga selle teeb lihtsalt NGINX), meie varundussüsteem loevad nüüd samuti põhiosast. See ei olnud just kitsaskoht, kuid ei tahtnud koormust lihtsalt niisama suurendada.
Lisame kolmanda ketta, mis on väike SSD, ja nimetame selle puhvriuks.
Kuidas see nüüd töötab.
Kasutaja laadib foto puhvri, seejärel saadetakse sündmus ootejärjekorda, et see tuleb kopeerida kahte ossa. See kopeeritakse, ja foto elab mingi aja (ütleme, päeva) puhvris ning alles siis see kustutatakse. See parandab kasutajakogemust, kuna kasutaja laadib foto ja tavaliselt saadetakse selle järele kohe päringud, või ta ise uuendab lehte, värskendab seda. Kuid see sõltub rakendusest, mis üleslaadimist teeb.
Või näiteks teised inimesed, kellele ta on hakanud fotot näitama, saadavad kohe sellele foto järele päringud. Vahemälus seda veel ei ole, esimene päring toimub väga kiiresti. Põhimõtteliselt sama nagu fotovahemäel. Aeglane salvestus ei osale üldse selles. Ja kui see päev hiljem kustutatakse, on see juba kas meie vahemälus või on tõenäoliselt enam kellelegi vajalik. See tähendab, et kasutajakogemus on oluliselt paranenud selliste lihtsate manipulatsioonide tõttu.
Noh, ja kõige olulisem: me oleme lõpetanud andmete kadumise.
Me, ütleme nii, lõpetasime potentsiaalset andmete kaotamise, sest me ei kaotanud neid tegelikult. Kuid oht oli olemas. Näeme, et selline lahendus on kindlasti hea, kuid see meenutab veidi sümptomeid, mitte lõplikku probleemi lahendamist. Ja teatud probleemid on endiselt olemas.
Esiteks, see on tõrke koht füüsilise hosti kujul, millel kogu see masin töötab, see ei ole kuhugi kadunud.
Teiseks, olid mured SANidega, jäi üle nende keeruline hooldamine jne. See ei olnud just kriitiline tegur, kuid tahtsime proovida, kuidas ära elada ilma selleta.
Ja me tegime kolmanda versiooni (põhimõtteliselt teise tõeliselt) — varundusversioon. Kuidas see välja nägi?
See, mis oli –
Meie põhiprobleem on see, et see on füüsiline host.
Esiteks, me eemaldame SANid, sest tahame eksperimenteerida, tahame proovida lihtsalt kohalikke kõvakettasid.
See on juba 2014-2015 aasta, ja sel ajal oli olukord ketaste ja nende mahutavuse osas ühes hostis palju parem. Me otsustasime, miks mitte proovida.
Ja seejärel võtame lihtsalt meie varundusosa ja liigutame selle füüsiliselt eraldi masinasse.
Nii saame sellise skeemi. Meil on kaks masinat, mis hoiavad samu andmebaase. Need varundavad teineteist täielikult ja sünkroniseerivad andmeid üle võrgu asünkroonses järjekorras samas MySQLis.
Miks see hästi töötab, on see, et meil on vähe записи. Kui записи oleks sama suur kui lugemine, võib-olla oleksime saanud mingit võrgu ülekoormust ja probleeme. записы on vähe, lugemisi palju — see meetod töötab hästi, see tähendab, et me kopeerime fotosid mõlema serveri vahel piisavalt harva.
Kuidas see töötab, kui vaadata pisut lähemalt.
Üleslaadimine. Koormuste tasandaja valib lihtsalt juhuslikud hostid paaris ja teeb üleslaadimise. Samal ajal teeb ta loomulikult tervisekontrolle, et vaadata, et masin ei oleks välja langenud. See tähendab, et ta laadib fotosid ainult elavale serverile, ja siis kopeeritakse see kõik asünkroonses järjekorras tema naabri juurde. Üleslaadimisega on kõik ülimalt lihtne.
Küsimus on veidi keerulisem.
Siin aitas meid Lua, sest puhtal NGINXil on sellise loogika tegemine keeruline. Esiteks teeme päringu esimeses serveris, vaatame, kas foto on seal, sest see võib olla näiteks naabri juurde üles laaditud, kuid siia pole veel jõudnud. Kui foto on seal, on see hea. Anname selle kohe kliendile ja võib-olla vahemälust.
Kui seda ei ole, teeme lihtsalt päringu naabrile ja saame selle sealt garanteeritult.
Seega, võib jälle öelda: võivad olla probleemid jõudlusega, sest pidevad round trip'id — pildi üleslaadimine, seda pole, teeme kaks päringut ühe asemel, see peaks aeglaselt töötama.
Meie olukorras see ei tööta aeglaselt.
Meil koguneb selle süsteemi järgi palju mõõdikuid, ja selle mehhanismi tinglik hitrate on umbes 95%. Seega, selle backup'i viivitus on väike ja tänu sellele saame pärast pildi üleslaadimist selle esmakordselt kätte ja ei pea kahel korral minema.
Seega, mida me veel saime, ja mis on väga äge?
Varem olid meil peamised backup-ossad, ja me lugesime neid järjestikku. St, et me otsisime alati esmalt peamisest ja seejärel backup'ist. See oli üks käik.
Nüüd kasutame kahe masina samaaegset lugemist. Jagame päringud Round Robin'i meetsodil. Väikeses protsendis juhtumitel teeme kaks päringut. Kuid igal juhul on meil nüüd kahekordne lugemisruum võrreldes varasema olukorraga. Ning koormus on tõeliselt vähenenud nii teenindavatel masinatel kui ka salvestustel, mis meil sel ajal samuti olid.
Mis puudutab tõrkevõimet. Selle nimel me põhiliselt töötasime. Tõrkevõime on siin suurepäraselt toimiv.
Üks masin läheb rikki.
Ei mingit probleemi! Süsteemitehnik ei pea isegi öösel ärkama, ta kannatab hommikuni, ei juhtu midagi halba.
Isegi kui selle masina rikki minekul tekib järjekord, pole mingeid probleeme, lihtsalt logi hakkab kogunema esmalt elavale masinale ja seejärel jõuab juba järjekorda, ja hiljem masinasse, mis naaseb teenistusse mingil hetkel.
Sama kehtib ka hoolduse kohta. Me lihtsalt lülitame ühe masina välja, eemaldame selle käsitsi kõigist rühmades, sellele ei suunata enam liiklust, teeme mingit hooldust, korrigeerime midagi, ja pärast seda suuname ta tagasi teenistusse, ning see backup jõuab kiiresti kohale. St, et ühe masina seisakuaeg tagatakse kuskil paariks minutiks. See on tõeliselt väike. Tõrkevõime osas, veelkord ütlen, et siin on kõik suurepärane.
Milliseid järeldusi me saame selle reservohje skeemi põhjal teha?
Saime tõrkevõime.
Lihtne kasutamine. Kuna masinatel on kohalikud kõvakettad, on see inseneride töötamiseks palju mugavam.
Saime kahekordse lugemisruumi varu.
See on tõeliselt hea boonus tõrkevõime täienduseks.
Aga on ka probleeme. Nüüd on meil palju keerulisem arendada funktsioone, mis sellega seonduvad, sest süsteem on muutunud 100% lõpuks järjepidevaks.
Me peame näiteks mingisuguses taustatöös pidevalt mõtlema: "Millisel serveril me nüüd töötame?", "Kas siin on kindlasti ajakohane pilt?" jne. Loomulikult on see kõik kotitud ümber erinevatesse kihtidesse, ja programmeerijale, kes kirjutab äriloogikat, on see läbipaistav. Kuid sellegipoolest on see suur keeruline kiht tekinud. Kuid me oleme valmis sellega leppima vastutasuks nende eeliste eest, mida me sellega saime.
Ja siin tekib jälle teatud konflikt.
Ma ütlesin alguses, et kõik kohalike kõvaketaste hoidmine on halb. Ja nüüd ütlen, et see meeldib meile.
Jah, tõepoolest, aja jooksul on olukord palju muutunud ja nüüd on selle lähenemisega palju eeliseid. Esiteks saame me palju lihtsamat kasutust.
Teiseks on see tõhusam, kuna meil pole neid automaatseid kontrollerid, mis on ühendatud ketasüsteemidega.
Seal on tohutu masinavärk, kuid need on lihtsalt mõned kettad, mis on siin konkreetselt masinas RAID'is kokku pandud.
Aga on ka puudusi.
See on umbes 1,5 korda kallim kui SAN'ide kasutamine isegi tänaste hindadega. Seetõttu me ei otsustanud kogu meie suurt klastrit julgelt konverteerida kohalike kõvaketaste masinateks ja otsustasime jätta hübriidlahenduse.
Pool masinatest töötab kõvaketastega (noh, mitte pool – tõenäoliselt umbes 30%). Ja ülejäänud osa on vanad masinad, millel oli varem esimene reservohje skeem. Me lihtsalt remondime neid, kuna me ei vaja uusi andmeid ega midagi muud, lihtsalt liigsime mount'id ühest füüsilisest hostist kahele.
Ja meil on suur lugemisruumi varu, ja me oleme suurendanud. Kui varem monteerisime ühe masina kohta ühe salvestuse, siis nüüd monteerime ühe paari kohta neli, näiteks. Ja see töötab normaalselt.
Kokkuvõttes, mis meil siin on, millega me tegelesime, ja kas see meil õnnestus.
Kokkuvõte
Meil on kasutajaid — kokku 33 miljonit.
Meil on kolm kohaloleku punkti — Praha, Miami, Hongkong.
Neis on vahemälu kiht, mis koosneb kiiretest lokaalsetest ketastest (SSD), mille peal töötab kerge masinavärk NGINX, tema access.log ja Pythonis jooksvaid deemonid, mis seda kõike töötlevad ja haldavad.
Kui soovite, saate oma projektis, kui fotode kvaliteet ei ole teie jaoks nii kriitiline nagu meil, või kui teete kompromissi kontrolli ja arendamise kiirusest ning ressursside kuludest, siis võite rahulikult asendada selle CDN-iga, tänapäeva CDN-d teevad seda hästi.
Järgmiseks on salvestuse kiht, kus asuvad paaride klastrid, mis üksteist varundavad, asünkroonselt kopeerivad faile ühest teise mistahes muudatuse korral.
Samuti toimib osa neist masinatest lokaalsete kõvakettadega.
Osa nendest masinatest on ühendatud SAN-idega.
Ühel poolt on see kasutuses mugavam ja pisut tootlikum, teine pool on see tiheduse ja gigabaidi hinna poolest mugav.
See on kiire ülevaade meie arhitektuurist ja selle arengust.
Veel mõned nõuanded kogenud isikult, väga lihtsad.
Esiteks, kui te äkki otsustate, et peate oma fotoinfrastruktuuri kiiresti parandama, siis minge esmalt mõõtke, sest võib-olla pole midagi paranevat.
Kodaniku näide. Meil on masinaklaster, mis edastab fotosid vestluste manustest, ja seal töötab endiselt 2009. aasta skeem ning keegi ei kannata selle all. Kõik on rahul ja kõigile meeldib.
Mõõtmiseks riputage esmalt üles hulk mõõdikuid, vaadake neid ja seejärel otsustage, mis teie arvates ei ole rahuldav, mida tuleb parandada. Selleks on meil suurepärane tööriist, mida nimetatakse Pinba.
See võimaldab koguda NGINX-i süsteemilt väga detailset statistikat iga päringu ja vastuse koodide kohta, sealhulgas vastuste ajajaotust — kõike, mida soovite. Sellel on sidemed erinevate analüütiliste süsteemidega ning saate seda kõike kenasti vaadata.
Esmalt mõõtsime — seejärel parandasime.
Edasi. Loeme me optimeerime vahemäluga, kirjutame — jagamisega, kuid see on ilmne punkt.
Edasi. Kui te alles hakkate oma süsteemi üles ehitama, siis on palju parem teha fotod mitte-muutuvate failidena. Nii kaotate kohe terve klassi probleeme vahemälu tühistamisega, kuidas loogika peab leidma õige versiooni fotost jne.
Oletame, et laadisite üles sada, pärast seda pöörate selle ümber, saate teha seda nii, et see oleks füüsiliselt teine fail. Ei ole vaja mõelda: praegu säästan ma natuke ruumi, salvestan sama faili, muudan versiooni. See töötab alati halvasti ja see toob endaga kaasa palju peavalu.
Järgmiseks punktiks. Kuidas pilti kohapeal muuta.
Varem, kui kasutajad üles laadisid foto, lõikasime me kohe välja mitu suurust igaks juhuks, erinevate klientide jaoks, ja need kõik olid kettal. Nüüd oleme sellest loobunud.
Oleme jätnud ainult kolm põhisuurust: väike, keskmine ja suur. Kõik muu nende suuruste jaoks, mida me Uportis küsime, lihtsalt vähendame ja anname kasutajale.
CPU vahemälu kiht on siin tunduvalt odavam kui kui me pidevalt need suurused iga salvestuse juures uuesti genereeriksime. Oletame, et soovime lisada uue, see võtab kuu — käitame igal pool skripti, mis selle kõik korralikult teeb, samas mitte klastrit maas. Seega, kui on võimalus valida, on parem teha nii vähe füüsilisi suurusi kui võimalik, kuid et oleks mingisugune jaotus, ütleme, et kolm. Ja kõik muu lihtsalt muudetakse kohapeal olemasolevate moodulite abil. See on nüüd kõik väga lihtne ja kergesti kätte saadav.
Ja inkrementaalne asünkroonne varundamine on hea.
Kuna meie praktika on näidanud, toimib selline skeem suurepäraselt muudetud failide edasilükatud kopeerimisega.
Viimane punkt on samuti ilmne. Kui teie infrastruktuuris pole selliseid probleeme, kuid on midagi, mis võib puruneda, puruneb see kindlasti, kui sellest saab natukene rohkem. Seega on parem mõelda sellele eelnevalt ning mitte kogeda sellega seotud probleeme. Mul on kõik.
Kontaktid
»
»
See ettekande on ühe parima esitluse transkriptsioon kõrge laengu süsteemide arendajate konverentsil . Enne HighLoad++ 2017 konverentsi on vähem kui kuu aega.
Meil on juba valmis , kavandamine käib aktiivselt.
Sel aastal jätkame arhitektuuride ja skaleerimise teema uurimist:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филипп Дельгядо
Mõningaid neist materjalidest kasutame ka meie online-koolituses kõrge koormusega süsteemide arendamise kohta — see on spetsiaalselt valitud kirjade, artiklite, materjalide ja videote ahel. Meie õpikutes on juba üle 30 ainulaadse materjali. Liituge!
Allikas: habr.com
