Artem Denisov ( , )
Badoo estas la plej granda rendevua retejo de la mondo. Ni nuntempe havas ĉirkaŭ 330 milionojn da registritaj uzantoj tutmonde. Sed kio estas multe pli grava en la kunteksto de nia hodiaŭa konversacio estas, ke ni stokas ĉirkaŭ 3 petabajtojn da uzantfotoj. Ĉiutage niaj uzantoj alŝutas ĉirkaŭ 3,5 milionojn da novaj fotoj, kaj la legado estas proksimume 80 mil petoj sekundo. Ĉi tio estas sufiĉe multe por nia backend, kaj foje estas malfacilaĵoj kun ĉi tio.
Mi parolos pri la dezajno de ĉi tiu sistemo, kiu konservas kaj sendas fotojn ĝenerale, kaj mi rigardos ĝin el la vidpunkto de programisto. Estos mallonga retrospektivo pri kiel ĝi evoluis, kie mi skizos la ĉefajn mejloŝtonojn, sed mi nur parolos pli detale pri la solvoj, kiujn ni nuntempe uzas.
Nun ni komencu.
Kiel mi diris, ĉi tio estos retrospektivo, kaj por komenci ĝin ie, ni prenu la plej oftan ekzemplon.
Ni havas komunan taskon, ni devas akcepti, konservi kaj sendi uzantfotojn. En ĉi tiu formo, la tasko estas ĝenerala, ni povas uzi ion ajn:
- moderna nuba stokado,
- boksita solvo, el kiu estas ankaŭ multe nun;
- Ni povas instali plurajn maŝinojn en nia datumcentro kaj meti grandajn malmolajn diskojn sur ilin kaj konservi fotojn tie.
Badoo historie - kaj nun kaj tiam (tiutempe kiam ĝi estis nur en sia infanaĝo) - vivas sur siaj propraj serviloj, ene de niaj propraj DC-oj. Tial ĉi tiu opcio estis optimuma por ni.
Ni ĵus prenis plurajn maŝinojn, nomis ilin "fotoj", kaj ni ricevis areton, kiu stokas fotojn. Sed ŝajnas, ke io mankas. Por ke ĉio ĉi funkciu, ni devas iel determini sur kiu maŝino ni stokos kiujn fotojn. Kaj ĉi tie ankaŭ ne necesas malfermi Usonon.
Ni aldonas iun kampon al nia stokado kun informoj pri uzantoj. Ĉi tio estos la sharding-ŝlosilo. En nia kazo, ni nomis ĝin place_id, kaj ĉi tiu loko id montras al la loko kie uzantfotoj estas konservitaj. Ni faras mapojn.
En la unua etapo, ĉi tio eĉ povas esti farita permane - ni diras, ke foto de ĉi tiu uzanto kun tia loko surteriĝos sur tia servilo. Danke al ĉi tiu mapo, ni ĉiam scias kiam uzanto alŝutas foton, kie konservi ĝin, kaj ni scias de kie doni ĝin.
Ĉi tio estas absolute bagatela skemo, sed ĝi havas sufiĉe signifajn avantaĝojn. La unua estas, ke ĝi estas simpla, kiel mi diris, kaj la dua estas, ke kun ĉi tiu aliro ni povas facile grimpi horizontale simple liverante novajn aŭtojn kaj aldonante ilin al la mapo. Vi ne bezonas fari ion alian.
Tiel estis por ni dum kelka tempo.
Ĉi tio estis ĉirkaŭ 2009. Ili liveris aŭtojn, liveris...
Kaj iam ni komencis rimarki, ke ĉi tiu skemo havas iujn malavantaĝojn. Kio estas la malavantaĝoj?
Antaŭ ĉio, estas limigita kapablo. Ni ne povas ŝtopi tiom da malmolaj diskoj sur unu fizika servilo kiom ni ŝatus. Kaj ĉi tio fariĝis certa problemo kun la tempo kaj kun la kresko de la datumaro.
Kaj dua. Tio estas maltipa agordo de maŝinoj, ĉar tiaj maŝinoj estas malfacile reuzeblaj en iuj aliaj aretoj; ili estas sufiĉe specifaj, t.e. ili devus esti malfortaj en rendimento, sed samtempe kun granda malmola disko.
Ĉi tio estis ĉio por 2009, sed, principe, ĉi tiuj postuloj daŭre estas aktualaj hodiaŭ. Ni havas retrospektivon, do en 2009 ĉio estis tute malbona kun ĉi tio.
Kaj la lasta punkto estas la prezo.
La prezo estis tre kruta tiutempe, kaj ni bezonis serĉi iujn alternativojn. Tiuj. ni bezonis iel pli bone utiligi kaj la spacon en la datumcentroj kaj la fizikaj serviloj sur kiuj ĉio ĉi situas. Kaj niaj sistemaj inĝenieroj komencis grandan studon, en kiu ili reviziis amason da malsamaj opcioj. Ili ankaŭ rigardis amasigitajn dosiersistemojn kiel PolyCeph kaj Luster. Estis agado problemoj kaj sufiĉe malfacila operacio. Ili rifuzis. Ni provis munti la tutan datumaron per NFS sur ĉiu aŭto por iel grimpi ĝin. Legado ankaŭ malbone iris, ni provis malsamajn solvojn de diversaj vendistoj.
Kaj finfine, ni decidis uzi la tiel nomatan Stokan Reton.
Ĉi tiuj estas grandaj SHD-oj, kiuj estas specife dizajnitaj por stoki grandajn kvantojn da datumoj. Ili estas bretoj kun diskoj, kiuj estas muntitaj sur la finaj optikaj eligmaŝinoj. Tio. ni havas ian grupon da maŝinoj, sufiĉe malgrandaj, kaj ĉi tiuj SHD-oj, kiuj estas travideblaj al nia senda logiko, t.e. por nia nginx aŭ iu ajn alia por servi petojn por ĉi tiuj fotoj.
Ĉi tiu decido havis evidentajn avantaĝojn. Ĉi tio estas SHD. Ĝi celas konservi fotojn. Ĉi tio rezultas pli malmultekosta ol simple ekipi maŝinojn per malmolaj diskoj.
Dua pluso.
Ĉi tio estas, ke la kapablo fariĝis multe pli granda, t.e. ni povas akomodi multe pli da stokado en multe pli malgranda volumo.
Sed estis ankaŭ malavantaĝoj, kiuj aperis sufiĉe rapide. Ĉar la nombro da uzantoj kaj ŝarĝo sur ĉi tiu sistemo kreskis, efikecproblemoj komencis ekesti. Kaj la problemo ĉi tie estas sufiĉe evidenta - ajna SHD desegnita por stoki multajn fotojn en malgranda volumo, kutime, suferas de intensa legado. Ĉi tio efektive validas por iu ajn nuba stokado aŭ io alia. Nun ni ne havas idealan stokadon, kiu estus senfine skalebla, vi povus enŝtopi ion ajn en ĝin, kaj ĝi tre bone tolerus legadojn. Precipe hazardaj legaĵoj.
Kiel okazas ĉe niaj fotoj, ĉar fotoj estas petataj malkonsekvence, kaj tio multe influos ilian agadon.
Eĉ laŭ la hodiaŭaj ciferoj, se ni ricevas ie pli ol 500 RPS por fotoj sur maŝino al kiu stokado estas konektita, problemoj jam komenciĝas. Kaj ĝi estis sufiĉe malbona por ni, ĉar la nombro de uzantoj kreskas, aferoj nur plimalboniĝos. Ĉi tio devas esti optimumigita iel.
Por optimumigi, ni decidis tiam, evidente, rigardi la ŝarĝan profilon - kio, ĝenerale, okazas, kio devas esti optimumigita.
Kaj ĉi tie ĉio ludas en niajn manojn.
Mi jam diris en la unua diapozitivo: ni havas 80 mil legopetojn je sekundo kun nur 3,5 milionoj da alŝutoj ĉiutage. Tio estas, ĉi tio estas diferenco de tri grandordoj. Estas evidente, ke legado devas esti optimumigita kaj estas praktike klare kiel.
Estas unu pli malgranda punkto. La specifaĵoj de la servo estas tiaj, ke persono registras, alŝutas foton, tiam komencas aktive rigardi aliajn homojn, kiel ili, kaj estas aktive montrita al aliaj homoj. Tiam li trovas kunulon aŭ ne trovas kunulon, dependas de kiel ĝi rezultas, kaj ĉesas uzi la servon dum kelka tempo. En ĉi tiu momento, kiam li uzas ĝin, liaj fotoj estas tre varmaj - ili estas postulataj, multaj homoj rigardas ilin. Tuj kiam li ĉesas fari tion, sufiĉe rapide li foriĝas de tiom da eksponiĝo al aliaj homoj kiel li havis antaŭe, kaj liaj fotoj preskaŭ neniam estas petitaj.
Tiuj. Ni havas tre malgrandan varman datumaron. Sed samtempe estas multaj petoj por li. Kaj tute evidenta solvo ĉi tie estas aldoni kaŝmemoron.
Kaŝmemoro kun LRU solvos ĉiujn niajn problemojn. Kion ni faras?
Ni aldonas alian relative malgrandan antaŭ nia granda areto kun stokado, kiu nomiĝas fotokaŝoj. Ĉi tio estas esence nur kaŝmemorprokurilo.
Kiel ĝi funkcias de interne? Jen nia uzanto, jen stokado. Ĉio estas sama kiel antaŭe. Kion ni aldonas intere?
Ĝi estas nur maŝino kun fizika loka disko, kiu estas rapida. Ĉi tio estas kun SSD, ekzemple. Kaj ia loka kaŝmemoro estas konservita sur ĉi tiu disko.
Kiel ĝi aspektas? La uzanto sendas peton por foto. NGINX serĉas ĝin unue en la loka kaŝmemoro. Se ne, tiam simple proxy_pass al nia stokado, elŝutu la foton de tie kaj donu ĝin al la uzanto.
Sed ĉi tiu estas tre banala kaj estas neklara kio okazas interne. Ĝi funkcias io tia.
La kaŝmemoro estas logike dividita en tri tavolojn. Kiam mi diras "tri tavoloj", tio ne signifas, ke ekzistas ia kompleksa sistemo. Ne, ĉi tiuj estas kondiĉe nur tri dosierujoj en la dosiersistemo:
- Ĉi tio estas bufro, kie iras fotoj ĵus elŝutitaj de prokurilo.
- Ĉi tio estas varma kaŝmemoro, kiu konservas aktive petitajn fotojn.
- Kaj malvarma kaŝmemoro, kie fotoj estas iom post iom forpuŝitaj el la varma kaŝmemoro kiam malpli da petoj venas al ili.
Por ke ĉi tio funkciu, ni devas iel administri ĉi tiun kaŝmemoron, ni devas rearanĝi la fotojn en ĝi, ktp. Ĉi tio ankaŭ estas tre primitiva procezo.
Nginx simple skribas al la RAMDisk access.log por ĉiu peto, en kiu ĝi indikas la vojon al la foto, kiun ĝi nuntempe servis (relativa vojo, kompreneble), kaj kiun sekcion ĝi estis servita. Tiuj. ĝi povas diri "foto 1" kaj tiam aŭ bufro, aŭ varma kaŝmemoro, aŭ malvarma kaŝmemoro, aŭ prokurilo.
Depende de ĉi tio, ni devas iel decidi kion fari kun la foto.
Ni havas malgrandan demonon funkcianta sur ĉiu maŝino, kiu konstante legas ĉi tiun protokolon kaj konservas statistikojn pri la uzo de certaj fotoj en sia memoro.
Li simple kolektas tie, tenas la nombrilojn kaj periode faras la sekvantajn. Li movas aktive petitajn fotojn, por kiuj estas multaj petoj, al la varma kaŝmemoro, kie ajn ili estas.
Fotoj, kiuj estas malofte petitaj kaj malpli ofte petitaj, estas iom post iom forpuŝitaj el la varma kaŝmemoro en la malvarman.
Kaj kiam ni elĉerpas spacon en la kaŝmemoro, ni simple komencas forigi ĉion el la malvarma kaŝmemoro sendistinge. Kaj cetere, ĉi tio funkcias bone.
Por ke la foto estu tuj konservita kiam oni prokurigas ĝin al la bufro, ni uzas la direktivon proxy_store kaj la bufro ankaŭ estas RAMDisk, t.e. por la uzanto ĝi funkcias tre rapide. Ĉi tio koncernas la internaĵojn de la kaŝmemorservilo mem.
La restanta demando estas kiel distribui petojn tra ĉi tiuj serviloj.
Ni diru, ke ekzistas aro de dudek stokaj maŝinoj kaj tri kaŝmemorserviloj (tiel okazis).
Ni devas iel determini kiuj petoj estas por kiuj fotoj kaj kie surterigi ilin.
La plej kutima opcio estas Round Robin. Aŭ fari ĝin hazarde?
Ĉi tio evidente havas kelkajn malavantaĝojn ĉar ni uzus la kaŝmemoron tre malefike en tia situacio. Petoj surteriĝos sur iuj hazardaj maŝinoj: ĉi tie ĝi estis kaŝmemorigita, sed ĉe la sekva ĝi ne plu estas tie. Kaj se ĉio ĉi funkcios, ĝi estos tre malbona. Eĉ kun malgranda nombro da maŝinoj en la areto.
Ni devas iel malambigue determini kiun servilon surterigi kiun peton.
Estas banala maniero. Ni prenas la hash de la URL aŭ la hash de nia sharding-ŝlosilo, kiu estas en la URL, kaj dividas ĝin per la nombro da serviloj. Ĉu funkcios? Volo.
Tiuj. Ni havas 2% peton, ekzemple, por iu "example_url" ĝi ĉiam alteriĝos sur la servilon kun indekso "XNUMX", kaj la kaŝmemoro estos konstante forigita kiel eble plej bone.
Sed estas problemo pri redisigo en tia skemo. Resharding - Mi volas diri ŝanĝi la nombron da serviloj.
Ni supozu, ke nia kaŝmemorgrupo ne plu povas elteni kaj ni decidas aldoni alian maŝinon.
Ni aldonu.
Nun ĉio estas dividebla ne per tri, sed per kvar. Tiel, preskaŭ ĉiuj ŝlosiloj, kiujn ni antaŭe havis, preskaŭ ĉiuj URL-oj nun vivas sur aliaj serviloj. La tuta kaŝmemoro estis nuligita simple por momento. Ĉiuj petoj falis sur nian stokan areton, ĝi malboniĝis, misfunkciado de servo kaj malkontenta uzantoj. Mi ne volas fari tion.
Ĉi tiu opcio ankaŭ ne konvenas al ni.
Tio. kion ni devus fari? Ni devas iel efike uzi la kaŝmemoron, surterigi la saman peton sur la sama servilo denove kaj ree, sed esti rezistemaj al redisigo. Kaj ekzistas tia solvo, ĝi ne estas tiom komplika. Ĝi nomiĝas konsekvenca haŝado.
Kiel ĝi aspektas?
Ni prenas iun funkcion de la sharding-ŝlosilo kaj disvastigas ĉiujn ĝiajn valorojn sur la cirklo. Tiuj. ĉe la punkto 0, ĝiaj minimumaj kaj maksimumaj valoroj konverĝas. Poste ni metas ĉiujn niajn servilojn sur la saman cirklon proksimume jene:
Ĉiu servilo estas difinita per unu punkto, kaj la sektoro kiu iras dekstrume al ĝi, sekve, estas servata de ĉi tiu gastiganto. Kiam petoj venas al ni, ni tuj vidas, ke ekzemple peto A - ĝi havas haŝon tie - kaj ĝi estas servata de servilo 2. Peto B - de servilo 3. Kaj tiel plu.
Kio okazas en ĉi tiu situacio dum reharding?
Ni ne nuligas la tutan kaŝmemoron, kiel antaŭe, kaj ne movas ĉiujn klavojn, sed ni movas ĉiun sektoron mallongan distancon tiel ke, relative parolante, nia sesa servilo, kiun ni volas aldoni, enĝustigu en la liberan spacon, kaj ni aldonas ĝin tie.
Kompreneble, en tia situacio la ŝlosiloj ankaŭ elmoviĝas. Sed ili eliras multe pli malfortaj ol antaŭe. Kaj ni vidas, ke niaj unuaj du ŝlosiloj restis sur siaj serviloj, kaj la kaŝmemorservilo ŝanĝiĝis nur por la lasta ŝlosilo. Ĉi tio funkcias sufiĉe efike, kaj se vi aldonas novajn gastigantojn iom post iom, tiam ne estas granda problemo ĉi tie. Vi aldonas kaj aldonas iom post iom, atendu ĝis la kaŝmemoro denove pleniĝos, kaj ĉio funkcias bone.
La sola demando restas kun rifuzoj. Ni supozu, ke ia aŭtomobilo ne funkcias.
Kaj ni ne vere volus regeneri ĉi tiun mapon ĉi-momente, malvalidigi parton de la kaŝmemoro, kaj tiel plu, se, ekzemple, la maŝino estis rekomencita, kaj ni bezonas iel servi petojn. Ni simple konservas unu rezervan fotkaŝmemoron ĉe ĉiu retejo, kiu funkcias kiel anstataŭaĵo por iu ajn maŝino kiu estas nuntempe malfunkcia. Kaj se subite unu el niaj serviloj fariĝas neatingebla, la trafiko iras tien. Nature, ni havas neniun kaŝmemoron tie, t.e. estas malvarme, sed almenaŭ uzantpetoj estas traktataj. Se ĉi tio estas mallonga intervalo, tiam ni spertas ĝin tute trankvile. Estas nur pli da ŝarĝo pri stokado. Se ĉi tiu intervalo estas longa, tiam ni jam povas fari decidon - forigi ĉi tiun servilon de la mapo aŭ ne, aŭ eble anstataŭigi ĝin per alia.
Ĉi tio temas pri la kaŝmemorsistemo. Ni rigardu la rezultojn.
Ŝajnus, ke ĉi tie estas nenio komplika. Sed ĉi tiu metodo de administri la kaŝmemoron donis al ni lertrapidecon de ĉirkaŭ 98%. Tiuj. el ĉi tiuj 80 mil petoj sekundo, nur 1600 atingas stokadon, kaj ĉi tio estas tute normala ŝarĝo, ili trankvile eltenas ĝin, ni ĉiam havas rezervon.
Ni metis ĉi tiujn servilojn en tri el niaj DC-oj, kaj ricevis tri punktojn de ĉeesto - Prago, Miamo kaj Honkongo.
Tio. ili estas pli-malpli loke lokitaj al ĉiu el niaj celmerkatoj.
Kaj kiel belan gratifikon, ni ricevis ĉi tiun kaŝmemoran prokurilon, sur kiu la CPU estas efektive neaktiva, ĉar ĝi ne tiom bezonas por servi enhavon. Kaj tie, uzante NGINX+ Lua, ni efektivigis multan utilisman logikon.
Ekzemple, ni povas eksperimenti kun webp aŭ progresiva jpeg (ĉi tiuj estas efikaj modernaj formatoj), vidi kiel ĝi influas trafikon, fari kelkajn decidojn, ebligi ĝin por certaj landoj ktp.; faru dinamikan regrandigi aŭ tondi fotojn sur la flugo.
Ĉi tio estas bona uzokutimo kiam, ekzemple, vi havas poŝtelefonan aplikaĵon, kiu montras fotojn, kaj la poŝtelefona aplikaĵo ne volas malŝpari la CPU de la kliento petante grandan foton kaj poste regrandigi ĝin al certa grandeco por puŝi ĝin enen. la vido. Ni povas simple dinamike specifi iujn parametrojn en la kondiĉa URL de UPort, kaj la fota kaŝmemoro regrandigos la foton mem. Kiel regulo, ĝi elektos la grandecon, kiun ni fizike havas sur la disko, kiel eble plej proksime al la petita, kaj subvendos ĝin en specifaj koordinatoj.
Cetere, ni faris publike disponeblajn videoregistraĵojn de la lastaj kvin jaroj de la konferenco de programistoj de altŝarĝaj sistemoj. . Rigardu, lernu, dividu kaj abonu .
Ni ankaŭ povas aldoni multe da produkta logiko tie. Ekzemple, ni povas aldoni malsamajn akvomarkojn uzante URL-parametrojn, ni povas malklarigi, malklarigi aŭ pikseli fotojn. Jen kiam ni volas montri foton de homo, sed ni ne volas montri lian vizaĝon, ĉi tio funkcias bone, ĉio estas efektivigita ĉi tie.
Kion ni ricevis? Ni akiris tri punktojn de ĉeesto, bonan lertrapidecon, kaj samtempe ni ne havas neaktivan CPU sur ĉi tiuj maŝinoj. Li nun fariĝis, kompreneble, pli grava ol antaŭe. Ni devas doni al ni pli fortajn aŭtojn, sed ĝi valoras ĝin.
Ĉi tio koncernas la revenon de fotoj. Ĉio ĉi tie estas sufiĉe klara kaj evidenta. Mi pensas, ke mi ne malkovris Amerikon, preskaŭ ajna CDN funkcias tiel.
Kaj, plej verŝajne, altnivela aŭskultanto povus havi demandon: kial ne simple ŝanĝi ĉion al CDN? Estus proksimume la sama; ĉiuj modernaj CDN-oj povas fari tion. Kaj estas kelkaj kialoj.
La unua estas fotoj.
Ĉi tio estas unu el la ĉefaj punktoj de nia infrastrukturo, kaj ni bezonas kiel eble plej multe da kontrolo pri ĝi. Se ĉi tio estas ia solvo de triaparta vendisto, kaj vi ne havas potencon super ĝi, estos sufiĉe malfacile por vi vivi kun ĝi kiam vi havas grandan datuman aron, kaj kiam vi havas tre grandan fluon. de uzantpetoj.
Mi donu al vi ekzemplon. Nun, kun nia infrastrukturo, ni povas, ekzemple, en kazo de iuj problemoj aŭ subteraj frapoj, iri al la maŝino kaj fuŝi tie, relative parolante. Ni povas aldoni la kolekton de iuj metrikoj, kiujn ni nur bezonas, ni povas iel eksperimenti, vidi kiel ĉi tio influas la grafikaĵojn, ktp. Nun multaj statistikoj estas kolektitaj pri ĉi tiu kaŝmemorgrupo. Kaj ni periode rigardas ĝin kaj pasigas longan tempon esplorante iujn anomaliojn. Se ĝi estus ĉe la CDN-flanko, ĝi estus multe pli malfacile kontroli. Aŭ, ekzemple, se okazas ia akcidento, ni scias kio okazis, ni scias kiel vivi kun ĝi kaj kiel venki ĝin. Jen la unua konkludo.
La dua konkludo ankaŭ estas sufiĉe historia, ĉar la sistemo disvolviĝis delonge, kaj estis multaj malsamaj komercaj postuloj en malsamaj stadioj, kaj ili ne ĉiam kongruas en la koncepton de CDN.
Kaj la punkto kiu sekvas el la antaŭa estas
Ĉi tio estas ĉar ĉe fotkaŝmemoroj ni havas multan specifan logikon, kiu ne ĉiam povas esti aldonita laŭpeto. Estas neverŝajne, ke iu CDN aldonos al vi iujn kutimajn aferojn laŭ via peto. Ekzemple, ĉifri URL-ojn se vi ne volas, ke la kliento povu ŝanĝi ion. Ĉu vi volas ŝanĝi la URL en la servilo kaj ĉifri ĝin, kaj tiam sendi iujn dinamikajn parametrojn ĉi tie.
Kian konkludon ĉi tio sugestas? En nia kazo, CDN ne estas tre bona alternativo.
Kaj en via kazo, se vi havas specifajn komercajn postulojn, tiam vi povas sufiĉe facile efektivigi tion, kion mi montris al vi mem. Kaj ĉi tio funkcios perfekte kun simila ŝarĝa profilo.
Sed se vi havas ian ĝeneralan solvon, kaj la tasko ne estas tre specifa, vi povas absolute sekure preni CDN. Aŭ se tempo kaj rimedoj estas pli gravaj por vi ol kontrolo.
Kaj modernaj CDN-oj havas preskaŭ ĉion, pri kio mi nun rakontis al vi. Kun la escepto de plus aŭ minus iuj trajtoj.
Ĉi tio temas pri donado de fotoj.
Ni nun iom antaŭeniru en nia retrospektivo kaj parolu pri stokado.
2013 pasis.
Caching-serviloj estis aldonitaj, rendimentaj problemoj foriris. Ĉio estas en ordo. Datumararo kreskas. Aktuale en 2013, ni havis ĉirkaŭ 80 servilojn konektitajn al stokado, kaj ĉirkaŭ 40 kaŝmemorilojn en ĉiu DC. Ĉi tio estas 560 terabajtoj da datumoj sur ĉiu DC, t.e. ĉirkaŭ petabajto entute.
Kaj kun la kresko de la datumaro, operaciaj kostoj komencis pliiĝi signife. Kion ĉi tio signifis?
En ĉi tiu diagramo, kiu estas desegnita - kun SAN, kun maŝinoj kaj kaŝmemoroj konektitaj al ĝi - estas multaj punktoj de fiasko. Se ni jam antaŭe traktis la fiaskon de kaŝmemorserviloj, ĉio estis pli-malpli antaŭvidebla kaj komprenebla, sed ĉe la stokado ĉio estis multe pli malbona.
Unue, la Stoka Area Reto (SAN) mem, kiu povas malsukcesi.
Due, ĝi estas konektita per optiko al la finaj maŝinoj. Povas esti problemoj kun optikaj kartoj kaj sparkiloj.
Kompreneble, ne estas tiom da ili kiel ĉe la SAN mem, sed, tamen, ĉi tiuj ankaŭ estas punktoj de fiasko.
Poste estas la maŝino mem, kiu estas konektita al la stokado. Ĝi ankaŭ povas malsukcesi.
Entute, ni havas tri punktojn de fiasko.
Plue, krom punktoj de fiasko, estas peza prizorgado de la stokado mem.
Ĉi tio estas kompleksa mult-komponenta sistemo, kaj sistemaj inĝenieroj povas malfacile labori kun ĝi.
Kaj la lasta, plej grava punkto. Se malsukceso okazas ĉe iu el ĉi tiuj tri punktoj, ni havas nenulan ŝancon perdi uzantdatenojn ĉar la dosiersistemo povas kraŝi.
Ni diru, ke nia dosiersistemo estas rompita. Unue, ĝia reakiro daŭras longan tempon - ĝi povas daŭri semajnon kun granda kvanto da datumoj. Kaj due, finfine ni plej verŝajne finos kun amaso da nekompreneblaj dosieroj, kiuj devos esti iel kombinitaj en uzantfotojn. Kaj ni riskas perdi datumojn. La risko estas sufiĉe alta. Kaj ju pli ofte okazas tiaj situacioj, kaj ju pli da problemoj aperas en ĉi tiu tuta ĉeno, des pli alta ĉi tiu risko.
Oni devis fari ion pri tio. Kaj ni decidis, ke ni nur bezonas sekurkopii la datumojn. Ĉi tio fakte estas evidenta solvo kaj bona. Kion ni faris?
Jen kiel aspektis nia servilo kiam ĝi antaŭe estis konektita al stokado. Ĉi tio estas unu ĉefa sekcio, ĝi estas nur bloka aparato, kiu efektive reprezentas monton por fora stokado per optiko.
Ni ĵus aldonis duan sekcion.
Ni metis duan stokadon apud ĝi (feliĉe, ĝi ne estas tiom multekosta laŭ mono), kaj nomis ĝin rezerva sekcio. Ĝi ankaŭ estas konektita per optiko kaj situas sur la sama maŝino. Sed ni devas iel sinkronigi la datumojn inter ili.
Ĉi tie ni simple faras nesinkronan voston proksime.
Ŝi ne estas tre okupata. Ni scias, ke ni ne havas sufiĉe da rekordoj. Vico estas nur tabelo en MySQL en kiu linioj kiel "vi devas subteni ĉi tiun foton" estas skribitaj. Kun ajna ŝanĝo aŭ alŝuto, ni kopias de la ĉefdisko al sekurkopio uzante nesinkronan aŭ nur ia fonlaboristo.
Kaj tiel ni ĉiam havas du konsekvencajn sekciojn. Eĉ se unu parto de ĉi tiu sistemo malsukcesas, ni ĉiam povas ŝanĝi la ĉefdiskon per sekurkopio, kaj ĉio daŭre funkcios.
Sed pro tio, la legoŝarĝo multe pliiĝas, ĉar... krom klientoj, kiuj legas el la ĉefa sekcio, ĉar ili unue rigardas la foton tie (ĝi estas pli freŝa tie), kaj poste serĉas ĝin sur la sekurkopio, se ili ne trovis ĝin (sed NGINX nur faras tion), nia sistemo ankaŭ estas plusa sekurkopio nun legas de la ĉefa sekcio. Ne estas ke ĉi tio estis botelkolo, sed mi ne volis pliigi la ŝarĝon, esence, ĝuste tiel.
Kaj ni aldonis trian diskon, kiu estas malgranda SSD, kaj nomis ĝin bufro.
Kiel ĝi funkcias nun.
La uzanto alŝutas foton al la bufro, tiam okazaĵo estas ĵetita en la voston indikante ke ĝi devas esti kopiita en du sekciojn. Ĝi estas kopiita, kaj la foto vivas sur la bufro dum iom da tempo (diru, tage), kaj nur tiam estas elpurigita de tie. Ĉi tio multe plibonigas la sperton de uzanto, ĉar la uzanto alŝutas foton, kiel regulo, petoj tuj komencas sekvi, aŭ li mem ĝisdatigis la paĝon kaj refreŝigis ĝin. Sed ĉio dependas de la aplikaĵo, kiu faras la alŝuton.
Aŭ, ekzemple, aliaj homoj, al kiuj li komencis montri sin, tuj sendas petojn post ĉi tiu foto. Ĝi ankoraŭ ne estas en la kaŝmemoro; la unua peto okazas tre rapide. Esence la sama kiel de fota kaŝmemoro. Malrapida stokado tute ne estas implikita en ĉi tio. Kaj kiam tago poste ĝi estas purigita, ĝi jam estas aŭ kaŝita sur nia kaŝmemortavolo, aŭ, plej verŝajne, neniu plu bezonas ĝin. Tiuj. La sperto de uzanto ĉi tie tre bone kreskis pro tiaj simplaj manipuladoj.
Nu, kaj plej grave: ni ĉesis perdi datumojn.
Ni diru nur, ke ni ĉesis potenciale perdi datumojn, ĉar ni vere ne perdis ĝin. Sed estis danĝero. Ni vidas, ke ĉi tiu solvo estas, kompreneble, bona, sed ĝi estas iom kiel glatigi la simptomojn de la problemo, anstataŭ tute solvi ĝin. Kaj iuj problemoj restas ĉi tie.
Unue, ĉi tio estas punkto de fiasko en la formo de la fizika gastiganto mem, sur kiu ĉi tiu maŝinaro funkcias; ĝi ne foriris.
Due, ankoraŭ ekzistas problemoj kun SANoj, ilia peza prizorgado ktp restas. Ne estis ke ĝi estis kritika faktoro, sed mi volis provi iel vivi sen ĝi.
Kaj ni faris la trian version (fakte, la duan fakte) - la rezervversion. Kiel ĝi aspektis?
Jen kio ĝi estis -
Niaj ĉefaj problemoj estas kun la fakto, ke ĉi tio estas fizika gastiganto.
Unue, ni forigas SAN-ojn ĉar ni volas eksperimenti, ni volas provi nur lokajn malmolajn diskojn.
Ĉi tio jam estas 2014-2015, kaj tiutempe la situacio kun diskoj kaj ilia kapablo en unu gastiganto fariĝis multe pli bona. Ni decidis kial ne provi ĝin.
Kaj tiam ni simple prenas nian rezervan sekcion kaj fizike translokigas ĝin al aparta maŝino.
Tiel, ni ricevas ĉi tiun diagramon. Ni havas du aŭtojn, kiuj stokas la samajn datumajn arojn. Ili subtenas unu la alian tute kaj sinkronigas datumojn tra la reto per nesinkrona vosto en la sama MySQL.
Kial ĉi tio funkcias bone estas ĉar ni havas malmultajn rekordojn. Tiuj. se skribo estus komparebla al legado, eble ni havus ian retan superŝarĝon kaj problemojn. Estas malmulte da skribado, multe da legado - tiu ĉi metodo bone funkcias, t.e. Ni malofte kopias fotojn inter ĉi tiuj du serviloj.
Kiel ĉi tio funkcias, se vi rigardas iom pli detale.
Alŝutu. La ekvilibristo simple elektas hazardajn gastigantojn kun paro kaj alŝutas al ĝi. Samtempe, li nature faras sankontrolojn kaj certigas, ke la aŭto ne falu. Tiuj. li alŝutas fotojn nur al viva servilo, kaj poste per nesinkrona vico ĉio estas kopiita al sia najbaro. Kun alŝuto ĉio estas ege simpla.
La tasko estas iom pli malfacila.
Lua helpis nin i tie, ar povas esti malfacile fari tian logikon sur vanilo NGINX. Ni unue faras peton al la unua servilo, vidu ĉu la foto estas tie, ĉar eble ĝi povus esti alŝutita, ekzemple, al najbaro, sed ankoraŭ ne alvenis ĉi tien. Se la foto estas tie, tio estas bona. Ni tuj donas ĝin al la kliento kaj, eble, konservas ĝin.
Se ĝi ne estas tie, ni simple faras peton al nia najbaro kaj estas garantiitaj ricevi ĝin de tie.
Tio. denove ni povas diri: povas esti problemoj pri agado, ĉar estas konstantaj rondveturoj - la foto estis alŝutita, ĝi ne estas ĉi tie, ni faras du petojn anstataŭ unu, ĉi tio devus funkcii malrapide.
En nia situacio, ĉi tio ne funkcias malrapide.
Ni kolektas amason da metrikoj pri ĉi tiu sistemo, kaj la kondiĉa inteligenta indico de tia mekanismo estas ĉirkaŭ 95%. Tiuj. La malfruo de ĉi tiu sekurkopio estas malgranda, kaj pro tio ni estas preskaŭ garantiitaj, post kiam la foto estis alŝutita, ni prenos ĝin la unuan fojon kaj ne devos iri ien dufoje.
Do kion alian ni havas, kio estas vere bonega?
Antaŭe, ni havis la ĉefan rezervan sekcion, kaj ni legis el ili sinsekve. Tiuj. Ni ĉiam serĉis unue sur la ĉefa, kaj poste sur la sekurkopio. Estis unu movo.
Nun ni uzas legadon de du maŝinoj samtempe. Ni distribuas petojn per Round Robin. En malgranda procento de kazoj ni faras du petojn. Sed entute, ni nun havas duoble pli da legaĵoj ol antaŭe. Kaj la ŝarĝo estis multe reduktita kaj sur la sendaj maŝinoj kaj rekte sur la konservaj maŝinoj, kiujn ni ankaŭ havis tiutempe.
Koncerne al toleremo al misfaroj. Efektive, por tio ni ĉefe batalis. Kun kulp-toleremo, ĉio fariĝis bonega ĉi tie.
Unu aŭto paneiĝas.
Nedankinde! Sisteminĝeniero eble eĉ ne vekiĝos nokte, li atendos ĝis la mateno, nenio malbona okazos.
Se eĉ se ĉi tiu maŝino malsukcesas, la vico estas neorda, ankaŭ ne estas problemoj, la ŝtipo simple akumuliĝos unue sur la vivanta maŝino, kaj poste ĝi estos aldonita al la vico, kaj poste al la aŭto, kiu estos. ekfunkciu post iom da tempo.
Same kun prizorgado. Ni simple malŝaltas unu el la maŝinoj, mane eltiras ĝin el ĉiuj naĝejoj, ĝi ĉesas ricevi trafikon, ni faras ian prizorgadon, ni redaktas ion, poste ni resendas ĝin al servo, kaj ĉi tiu sekurkopio atingas sufiĉe rapide. Tiuj. tage, la malfunkcio de unu aŭto atingas ene de kelkaj minutoj. Ĉi tio estas vere tre malmulte. Kun kulpotoleremo, mi diras denove, ĉio estas bonega ĉi tie.
Kiajn konkludojn oni povas eltiri el tiu ĉi redunda skemo?
Ni ricevis toleremon al kulpo.
Facile uzebla. Ĉar la maŝinoj havas lokajn malmolajn diskojn, tio estas multe pli oportuna de operacia vidpunkto por la inĝenieroj, kiuj laboras kun ĝi.
Ni ricevis duoblan legadon.
Ĉi tio estas tre bona gratifiko aldone al faŭltoleremo.
Sed estas ankaŭ problemoj. Nun ni havas multe pli kompleksan disvolviĝon de iuj funkcioj rilataj al ĉi tio, ĉar la sistemo fariĝis 100% finfine konsekvenca.
Ni devas, ekzemple, en iu fona laboro, konstante pensi: "Sur kiu servilo ni funkcias nun?", "Ĉu vere estas aktuala foto ĉi tie?" ktp. Ĉi tio, kompreneble, estas tute envolvita, kaj por la programisto, kiu skribas komercan logikon, ĝi estas travidebla. Sed, tamen, ĉi tiu granda kompleksa tavolo aperis. Sed ni pretas toleri ĉi tion kontraŭ la bonaĵoj, kiujn ni ricevis de ĝi.
Kaj ĉi tie denove estiĝas iu konflikto.
Mi diris komence, ke stoki ĉion sur lokaj malmolaj diskoj estas malbona. Kaj nun mi diras, ke ĝi ŝatis al ni.
Jes, efektive, kun la tempo la situacio multe ŝanĝiĝis, kaj nun ĉi tiu aliro havas multajn avantaĝojn. Unue, ni ricevas multe pli simplan operacion.
Due, ĝi estas pli produktiva, ĉar ni ne havas ĉi tiujn aŭtomatajn regilojn aŭ konektojn al diskbretoj.
Estas grandega kvanto da maŝinaro tie, kaj ĉi tiuj estas nur kelkaj diskoj, kiuj estas kunvenitaj ĉi tie sur la maŝino en atakon.
Sed estas ankaŭ malavantaĝoj.
Ĉi tio estas proksimume 1,5 fojojn pli multekosta ol uzi SAN-ojn eĉ ĉe la hodiaŭaj prezoj. Tial ni decidis ne kuraĝe konverti nian tutan grandan areton en aŭtojn kun lokaj malmolaj diskoj kaj decidis lasi hibridan solvon.
Duono de niaj maŝinoj funkcias kun malmolaj diskoj (nu, ne duono - verŝajne 30 procentoj). Kaj la ceteraj estas malnovaj aŭtoj, kiuj antaŭe havis la unuan rezervadskemon. Ni simple remuntis ilin, ĉar ni ne bezonis novajn datumojn aŭ ion alian, ni simple movis la montojn de unu fizika gastiganto al du.
Kaj ni nun havas grandan stokon de legado, kaj ni vastigis ĝin. Se pli frue ni muntis unu stokaĵon sur unu maŝino, nun ni muntas kvar, ekzemple, sur unu paro. Kaj ĝi funkcias bone.
Ni prenu mallongan resumon pri tio, kion ni sukcesis, por kio ni batalis, kaj ĉu ni sukcesis.
Rezultoj
Ni havas uzantojn - eĉ 33 milionojn.
Ni havas tri punktojn de ĉeesto - Prago, Miamo, Honkongo.
Ili enhavas kaŝmemoro-tavolon, kiu konsistas el aŭtoj kun rapidaj lokaj diskoj (SSD-oj), sur kiuj funkcias simplaj maŝinoj de NGINX, ĝiaj access.log kaj Python-demonoj, kiuj prilaboras ĉion ĉi kaj administras la kaŝmemoron.
Se vi deziras, vi estas en via projekto, se fotoj ne estas tiel kritikaj por vi kiel ili estas por ni, aŭ se kompromiskontrolo kontraŭ disvolva rapideco kaj resursaj kostoj estas en la alia direkto por vi, tiam vi povas sekure anstataŭigi ĝin. kun CDN, modernaj CDN-oj ili fartas bone.
Poste venas la stokada tavolo, sur kiu ni havas aretojn de paroj da maŝinoj, kiuj sekurigas unu la alian, dosieroj estas nesinkrone kopiitaj de unu al alia kiam ajn ili ŝanĝiĝas.
Krome, iuj el ĉi tiuj maŝinoj funkcias kun lokaj malmolaj diskoj.
Kelkaj el ĉi tiuj maŝinoj estas konektitaj al SANoj.
Kaj, unuflanke, ĝi estas pli oportuna por uzi kaj iom pli produktiva, aliflanke, ĝi estas oportuna laŭ loka denseco kaj prezo por gigabajto.
Ĉi tio estas tiel mallonga superrigardo pri la arkitekturo de tio, kion ni akiris kaj kiel ĉio disvolviĝis.
Kelkaj pliaj konsiletoj de la kapitano, tre simplaj.
Unue, se vi subite decidas, ke vi urĝe bezonas plibonigi ĉion en via foto-infrastrukturo, unue mezuru, ĉar eble nenio devas esti plibonigita.
Mi donu al vi ekzemplon. Ni havas aron da maŝinoj, kiuj sendas fotojn el aldonaĵoj en babilejoj, kaj la skemo funkcias tie ekde 2009, kaj neniu suferas pro ĝi. Ĉiuj fartas bone, ĉiuj ŝatas ĉion.
Por mezuri, unue pendigu amason da metrikoj, rigardu ilin, kaj poste decidu pri kio vi estas malfeliĉa kaj kio devas esti plibonigita. Por mezuri ĉi tion, ni havas bonegan ilon nomatan Pinba.
Ĝi permesas vin kolekti tre detalajn statistikojn de NGINX por ĉiu peto kaj respondkodoj, kaj distribuo de tempoj - kion ajn vi volas. Ĝi havas ligojn al ĉiaj malsamaj analizaj sistemoj, kaj tiam vi povas rigardi ĉion bele.
Unue ni mezuris ĝin, poste ni plibonigis ĝin.
Plue. Ni optimumigas legadon per kaŝmemoro, skribadon per sharding, sed ĉi tio estas evidenta punkto.
Plue. Se vi ĵus komencas konstrui vian sistemon, tiam estas multe pli bone fari fotojn kiel neŝanĝeblaj dosieroj. Ĉar vi tuj perdas tutan klason da problemoj pri kaŝmemoro nevalidigo, kun kiel la logiko devus trovi la ĝustan version de la foto, ktp.
Ni diru, ke vi alŝutis cent, poste turnis ĝin, faru ĝin tiel ke ĝi estis fizike malsama dosiero. Tiuj. ne necesas pensi: nun mi ŝparos iom da spaco, skribos ĝin al la sama dosiero, ŝanĝos la version. Ĉi tio ĉiam ne funkcias bone kaj kaŭzas multajn kapdolorojn poste.
Sekva punkto. Pri regrandigo sur la muŝo.
Antaŭe, kiam uzantoj alŝutis foton, ni tuj tranĉis tutan aron da grandecoj por ĉiuj okazoj, por malsamaj klientoj, kaj ili ĉiuj estis sur la disko. Nun ni forlasis ĉi tion.
Ni lasis nur tri ĉefajn grandecojn: malgranda, meza kaj granda. Ni simple malgrandigas ĉion alian de la grandeco kiu estas malantaŭ tiu, kiu estis petita al ni ĉe Uport, ni simple faras la malaltigon kaj donas ĝin al la uzanto.
La CPU de la kaŝmemortavolo ĉi tie montriĝas multe pli malmultekosta ol se ni konstante regenerus ĉi tiujn grandecojn sur ĉiu stokado. Ni diru, ke ni volas aldoni novan, ĉi tio daŭros monaton - rulu ĉie skripton, kiu farus ĉion ĉi nete, sen detrui la areton. Tiuj. Se vi havas la ŝancon elekti nun, estas pli bone fari kiel eble plej malmultajn fizikajn grandecojn, sed tiel ke almenaŭ iu distribuado estu, ekzemple, tri. Kaj ĉio alia povas esti simple regrandigi sur la flugo uzante pretajn modulojn. Ĉio estas tre facila kaj alirebla nun.
Kaj pliiga nesinkrona sekurkopio estas bona.
Kiel nia praktiko montris, ĉi tiu skemo funkcias bonege kun malfrua kopiado de ŝanĝitaj dosieroj.
La lasta punkto ankaŭ estas evidenta. Se via infrastrukturo ne havas tiajn problemojn nun, sed estas io, kio povas rompi, ĝi certe rompiĝos kiam ĝi fariĝos iom pli. Tial, estas pli bone pripensi ĉi tion anticipe kaj ne sperti problemojn kun ĝi. Tion mi volis diri.
Kontaktoj
»
»
Ĉi tiu raporto estas transskribo de unu el la plej bonaj paroladoj ĉe la konferenco de programistoj de altŝarĝaj sistemoj . Restas malpli ol monato ĝis la HighLoad++ 2017-konferenco.
Ni jam havas ĝin preta , la horaro nun estas aktive formita.
Ĉi-jare ni daŭre esploras la temon de arkitekturoj kaj skalo:
- / Igor Vasiliev
- / Dmitrij Egorov
- / Anatolij Plaskovskij
- / Roman Ŝeĥovcov, Aleksej Gromaĉikov
- / Filipo Delgado
Ni ankaŭ uzas kelkajn el ĉi tiuj materialoj en nia interreta trejna kurso pri evoluigado de altŝarĝaj sistemoj estas ĉeno de speciale elektitaj leteroj, artikoloj, materialoj, filmetoj. Nia lernolibro jam enhavas pli ol 30 unikajn materialojn. Konektu!
fonto: www.habr.com