Artem Denisov ( , )
Badoo mezintirîn malpera dating ya cîhanê ye. Niha li çaraliyê cîhanê nêzî 330 mîlyon bikarhênerên me yên qeydkirî hene. Lê ya ku di çarçoweya sohbeta meya îro de pir girîngtir e ev e ku em bi qasî 3 petabytes wêneyên bikarhêner hilînin. Her roj bikarhênerên me bi qasî 3,5 mîlyon wêneyên nû bar dikin, û barkirina xwendinê li ser e Di çirkeyê de 80 hezar daxwaz. Ev ji bo paşiya me pir pir e, û carinan bi vê yekê re dijwarî hene.
Ez ê li ser sêwirana vê pergalê, ku bi gelemperî wêneyan hilîne û dişîne, biaxivim, û ez ê ji nêrîna pêşdebirek lê binihêrim. Dê li ser çawaniya pêşkeftina wê paşverûyek kurt hebe, li wir ez ê qonaxên sereke diyar bikim, lê ez ê tenê bi hûrgulî li ser çareseriyên ku em niha bikar tînin biaxivim.
Niha em dest pê bikin.
Wekî ku min got, ev ê paşverûyek be, û ji bo ku ew li cîhek dest pê bike, em mînaka herî gelemperî bigirin.
Karê me yê hevpar heye, pêdivî ye ku em wêneyên bikarhêner qebûl bikin, hilînin û bişînin. Di vê formê de, peywir gelemperî ye, em dikarin her tiştî bikar bînin:
- hilanîna ewr a nûjen,
- çareseriyek qutkirî, ya ku niha jî pir in;
- Em dikarin di navenda daneya xwe de gelek makîneyan saz bikin û dîskên mezin deynin ser wan û wêneyan li wir hilînin.
Badoo ji hêla dîrokî ve - hem niha û hem jî wê hingê (di dema ku ew di destpêka xwe de bû) - li ser serverên xwe, di hundurê DC-yên me de dijî. Ji ber vê yekê, ev vebijark ji bo me çêtirîn bû.
Me tenê çend makîneyên xwe girtin, ji wan re digotin "wêne", û me komek stend ku wêneyan hilîne. Lê xuya ye ku tiştek winda ye. Ji bo ku ev hemî bixebitin, divê em bi rengekî diyar bikin ku em ê kîjan wêneyan li ser kîjan makîneyê hilînin. Û li vir jî ne hewce ye ku Amerîka veke.
Em bi agahdariya li ser bikarhêneran hin zeviyê li hilanîna xwe zêde dikin. Ev dê bibe mifteya parvekirinê. Di doza me de, me jê re got place_id, û ev id cîhê cîhê ku wêneyên bikarhêner lê têne hilanîn destnîşan dike. Em nexşeyan çêdikin.
Di qonaxa yekem de, ev dikare bi destan jî were kirin - em dibêjin ku wêneyek vî bikarhênerê bi cîhek wusa dê li ser serverek wusa be. Bi saya vê nexşeyê, em her gav dizanin dema ku bikarhêner wêneyek bar dike, li ku derê hilîne, û em dizanin ku em ji ku bidin.
Ev nexşeyek bêkêmasî ye, lê xwedan avantajên pir girîng e. Ya yekem ev e ku ew hêsan e, wekî ku min got, û ya duyemîn jî ev e ku bi vê nêzîkatiyê em dikarin bi hêsanî bi gihandina gerîdeyên nû û lê zêdekirina wan li nexşeyê bi asanî pîvaz bikin. Ne hewce ye ku hûn tiştek din bikin.
Ji bo demekê ji me re wisa bû.
Ev dora 2009 bû. Wan erebe teslîm kirin, teslîm kirin ...
Û di demekê de me dest pê kir ku vê planê hin kêmasiyên xwe hene. dezawantaj çi ne?
Berî her tiştî, kapasîteya sînor heye. Em nekarin bi qasî ku em dixwazin gelek dîskên hişk li ser serverek fizîkî daxin. Û ev bi demê re û bi mezinbûna databasê re bûye pirsgirêkek diyar.
Û duyemîn. Ev konfigurasyonek netîpîkî ya makîneyan e, ji ber ku makîneyên weha dijwar e ku di hin komên din de ji nû ve werin bikar anîn; ew pir taybetî ne, yanî. divê ew di performansê de qels bin, lê di heman demê de bi ajokerek mezin.
Ev hemî ji bo 2009-an bû, lê, di prensîbê de, van hewcedariyên îro hîn jî têkildar in. Paşverûyek me heye, ji ber vê yekê di sala 2009-an de her tişt bi vê yekê bi tevahî xirab bû.
Û xala dawîn bihayê ye.
Biha di wê demê de pir giran bû, û hewce bû ku em li hin alternatîfan bigerin. Ewan. me hewce bû ku em bi rengekî çêtir hem cîhê li navendên daneyê û hem jî serverên laşî yên ku ev hemî li ser hene baştir bikar bînin. Û endezyarên pergala me dest bi lêkolînek mezin kirin ku tê de wan komek vebijarkên cihêreng lêkolîn kirin. Wan her weha li pergalên pelan ên komkirî yên wekî PolyCeph û Luster jî mêze kirin. Pirsgirêkên performansê û operasyonek pir dijwar hebûn. Wan red kir. Me hewl da ku tevahiya databasê bi navgîniya NFS-ê li ser her gerîdeyê siwar bikin da ku bi rengekî wê mezin bikin. Xwendin jî nebaş derbas bû, me çareseriyên cihêreng ji firoşkarên cihê ceriband.
Û di dawiyê de, me li ser karanîna bi navê Tora Herêmê ya Storage bicîh kir.
Ev SHD-yên mezin in ku bi taybetî ji bo hilanîna mîqdarên mezin ên daneyê hatine çêkirin. Ew refên bi dîskên ku li ser makîneyên derketinê yên optîkî yên dawîn têne danîn in. Va. me cûreyek hewzek makîneyan, pir piçûk, û van SHD hene, ku ji mantiqa şandina me re zelal in, yanî. ji bo nginx me an kesek din ji bo daxwazên van wêneyan xizmetê bike.
Ev biryar xwedî avantajên eşkere bû. Ev SHD ye. Armanca wê hilanîna wêneyan e. Ev erzantir e ji tenê kirina makîneyan bi dîskên hişk.
Plus duyemîn.
Ev e ku kapasîteya pir mezintir bûye, ango. em dikarin di hêjmarek pir piçûk de pir zêde hilanînê bi cih bikin.
Lê kêmasiyên ku bi lez derketine holê jî hebûn. Her ku hejmara bikarhêner û barkirina vê pergalê mezin bû, pirsgirêkên performansê dest pê kir. Pirsgirêk li vir pir eşkere ye - her SHD-ya ku ji bo hilanîna gelek wêneyan di hêjmarek piçûk de hatî çêkirin, wekî qaîdeyek, ji xwendina zirav dikişîne. Ev bi rastî ji bo hilanîna ewr an tiştek din rast e. Naha me depoyek îdeal tune ku bêsînor berbelav be, hûn dikarin her tiştî têxin nav wê, û ew ê xwendinan pir baş tehemûl bike. Bi taybetî xwendinên casual.
Mîna ku bi wêneyên me re ye, ji ber ku wêne bi nakok têne xwestin, û ev yek dê bandorek mezin li performansa wan bike.
Tewra li gorî hejmarên îroyîn jî, heke em ji bo wêneyên li ser makîneyek ku hilanînê pê ve girêdayî ye li cîhek zêdetirî 500 RPS bistînin, pirsgirêk jixwe dest pê dikin. Û ew ji me re têra xwe xirab bû, ji ber ku hejmara bikarhêneran zêde dibe, tişt dê xirabtir bibin. Pêdivî ye ku ev bi rengek xweşbîn bibe.
Ji bo ku xweşbîn bikin, me wê demê biryar da, bê guman, em li profîla barkirinê binihêrin - bi gelemperî, çi diqewime, çi hewce dike ku were xweşbîn kirin.
Û li vir her tişt di destê me de dilîze.
Min berê di slideya yekem de got: Di çirkeyê de 80 hezar daxwazên me yên xwendinê hene ku rojane tenê 3,5 mîlyon barkirin hene. Ango ev ferqa sê rêzan e. Eşkere ye ku pêdivî ye ku xwendin were xweşbîn kirin û bi pratîkî zelal e ku çawa.
Xalek piçûktir jî heye. Taybetmendiyên karûbar bi vî rengî ne ku kesek qeyd dike, wêneyek bar dike, dûv re dest pê dike ku bi rengek çalak li mirovên din, mîna wan, mêze bike, û bi rengek çalak ji kesên din re were xuyang kirin. Dûv re ew hevalek dibîne an hevalek nabîne, ew girêdayî ye ku ew çawa çêdibe, û ji bo demekê dev ji karanîna xizmetê berdide. Di vê gavê de, gava ku ew wê bikar tîne, wêneyên wî pir germ in - ew daxwaz in, pir kes wan dibînin. Hema ku ew dev ji vî karî berdide, zû zû ew ji ber çavê xwe yê berê ji kesên din re derdikeve, û wêneyên wî hema bêje qet nayên xwestin.
Ewan. Me databasek germ a pir piçûk heye. Lê di heman demê de ji bo wî gelek daxwaz hene. Û li vir çareseriyek bi tevahî eşkere lê zêdekirina cache ye.
Keşeyek bi LRU re dê hemî pirsgirêkên me çareser bike. Em çi dikin?
Em yekî din ê nisbeten piçûk li ber koma xweya mezin a bi hilanînê, ku jê re tê gotin fotokaş, lê zêde dikin. Ev bi rastî tenê proxyek caching e.
Ew ji hundurê çawa dixebite? Li vir bikarhênerê me ye, li vir hilanînê ye. Her tişt wekî berê ye. Em di navberê de çi lê zêde bikin?
Ew tenê makîneyek bi dîskek herêmî ya fîzîkî ye, ku bilez e. Ji bo nimûne, ev bi SSD-ê ye. Û cûreyek cacheya herêmî li ser vê dîskê tê hilanîn.
Çawa xuya dike? Bikarhêner daxwazek wêneyek dişîne. NGINX pêşî li wê di cacheya herêmî de digere. Heke ne, wê hingê bi tenê proxy_pass li hilana me, wêneyê ji wir dakêşin û bidin bikarhêner.
Lê ev yek pir banal e û ne diyar e ka li hundur çi diqewime. Ew tiştek bi vî rengî dixebite.
The cache bi mantiqî li ser sê qatan dabeş. Dema ku ez dibêjim "sê qat", ev nayê wê wateyê ku celebek pergala tevlihev heye. Na, ev bi şertê tenê sê pelrêçan di pergala pelan de ne:
- Ev tamponek e ku wêneyên ku tenê ji proxy hatî dakêşandin diçin.
- Ev cacheyek germ e ku wêneyên ku niha bi rengek çalak daxwazkirî hilîne.
- Û cacheyek sar, ku gava ku kêm daxwaz ji wan re werin, wêne hêdî hêdî ji kaşê germ têne derxistin.
Ji bo ku ev kar bike, pêdivî ye ku em bi rengekî vê cache-ê birêve bibin, pêdivî ye ku em wêneyên tê de ji nû ve rêz bikin, hwd. Ev jî pêvajoyek pir prîmîtîv e.
Nginx ji bo her daxwazek tenê ji RAMDisk access.log re dinivîse, ku tê de ew riya wêneya ku niha jê re xizmet kiriye destnîşan dike (bê guman riya têkildar), û kîjan dabeşkirinê jê re hatî xizmet kirin. Ewan. dibe ku bêje "wêne 1" û dûv re an tamponek, an cacheyek germ, an cache sar, an proxy.
Bi vê ve girêdayî, pêdivî ye ku em bi rengekî biryar bidin ka bi wêneyê re çi bikin.
Li ser her makîneyek ku bi domdarî vê têketinê dixwîne û statîstîkên li ser karanîna hin wêneyan di bîranîna xwe de hilîne, şeydanek piçûk a me heye.
Ew bi tenê li wir berhev dike, jimarvanan digire û dem bi dem tiştên jêrîn dike. Ew wêneyên daxwazkirî yên çalak, ku ji bo wan gelek daxwaz têne, berbi cache-ya germ, li ku derê ne, diherike.
Wêneyên ku kêm têne xwestin û kêm caran hatine xwestin hêdî hêdî ji kaşê germ têne derxistin nav ya sar.
Û gava ku cîhê me di kaşê de kêm dibe, em bi tenê dest bi jêbirina her tiştî ji cacheya sar dikin bêserûber. Û bi awayê, ev baş dixebite.
Ji bo ku wêne tavilê dema prokskirina wê li tamponê were hilanîn, em rêbernameya proxy_store bikar tînin û tampon jî RAMDiskek e, yanî. ji bo bikarhêner ew pir zû dixebite. Ev bi hundurên servera caching bixwe re têkildar e.
Pirsa mayî ev e ku meriv çawa daxwazan li van serveran belav dike.
Ka em bibêjin komek ji bîst makîneyên hilanînê û sê serverên cachingê hene (bi vî rengî çêbû).
Pêdivî ye ku em bi rengekî diyar bikin ka kîjan daxwaz ji bo kîjan wêneyan in û li ku derê dakêşin.
Vebijarka herî gelemperî Round Robin e. An jî bi qezayê bikin?
Bê guman ev çend kêmasiyên xwe hene ji ber ku em ê di rewşek weha de cache-ê pir bêkêmasî bikar bînin. Daxwaz dê li ser hin makîneyên rasthatî bikevin: li vir ew hat girtin, lê li ya din ew nema li wir e. Û heger ev hemî bi kar bîne, ew ê pir xirab be. Tewra bi hejmareke piçûk a makîneyên di komê de.
Pêdivî ye ku em bi rengekî nezelal diyar bikin ka kîjan server kîjan daxwazê bi cih bike.
Rêyek banal heye. Em haş ji URL-ê an jî haş ji mifteya xweya parvekirinê ya ku di URL-ê de ye, digirin û bi hejmara pêşkêşkeran dabeş dikin. Dê bixebite? Xwestek.
Ewan. Daxwazek me ya 2% heye, mînakî, ji bo hin "example_url" ew ê her gav li servera bi nîşana "XNUMX"-ê vebike, û cache dê bi domdarî bi qasî ku pêkan çêtirîn were avêtin.
Lê di plansaziyek wiha de pirsgirêkek ji nûvekirinê heye. Nûvekirin - Mebesta min guhertina hejmara pêşkêşkeran e.
Ka em bihesibînin ku komika meya caching êdî nikare bi ser keve û em biryar didin ku makîneyek din lê zêde bikin.
Em lê zêde bikin.
Niha her tişt ne li ser sê, lê li ser çaran tê dabeş kirin. Bi vî rengî, hema hema hemî mifteyên ku me berê hebûn, hema hema hemî URL-an naha li ser serverên din dijîn. Tevahiya cache tenê ji bo bîskekê betal bû. Hemî daxwaz ketin ser koma hilanîna me, ew nebaş bû, têkçûna karûbarê û bikarhênerên nerazî bûn. Ez naxwazim wiya bikim.
Ev vebijêrk jî ne li gorî me ye.
Va. divê em çi bikin? Pêdivî ye ku em bi rengek bikêrhatî ji cache-ê bikar bînin, heman daxwazê li ser heman serverê careke din bi cih bînin, lê li hember reşeardkirinê berxwedêr bin. Û çareseriyek wusa heye, ew ne ew çend tevlihev e. Jê re tê gotin hashing domdar.
Whati xuya dike?
Em hin fonksiyonê ji mifteya parvekirinê digirin û hemî nirxên wê li ser çemberê belav dikin. Ewan. di xala 0 de, nirxên wê yên herî kêm û herî zêde digihêjin hev. Dûv re, em hemî serverên xwe bi qasî vî rengî li ser heman çemberê bi cih dikin:
Her server ji hêla yek xalê ve tête diyar kirin, û sektora ku li gorî demjimêrê ber bi wê ve diçe, li gorî vê yekê, ji hêla vê mêvandarê ve tê xizmet kirin. Dema ku daxwaz ji me re têne, em tavilê dibînin ku, mînakî, daxwaza A - li wir haş heye - û ew ji hêla server 2 ve tê pêşkêş kirin. Daxwaza B - ji hêla server 3. Û hwd.
Di vê rewşê de di dema nûvekirinê de çi dibe?
Em wekî berê tevaya cache-ê betal nakin, û hemî bişkokan naguhezînin, lê em her sektorek dûrek piçûk vediguhezînin da ku, bi nisbetî vebêjin, servera meya şeşemîn, ya ku em dixwazin lê zêde bikin, têkevin cîhê belaş, û em li wir lê zêde dikin.
Helbet di rewşeke wiha de kilît jî derdikevin. Lê ew ji berê pir lawaztir derdikevin. Û em dibînin ku du mifteyên me yên pêşîn li ser serverên wan mane, û servera caching tenê ji bo mifteya paşîn guherî. Ev pir bikêrhatî dixebite, û heke hûn mêvandarên nû bi gav zêde zêde bikin, wê hingê li vir pirsgirêkek mezin tune. Hûn di demekê de piçekî lê zêde dikin û lê zêde dikin, li bendê bimînin heya ku cache dîsa tije bibe, û her tişt baş dixebite.
Pirsa tenê bi redkirinê re dimîne. Ka em bihesibînin ku cûreyek otomobîl ji rêzê derketiye.
Û em ê bi rastî naxwazin vê gavê vê nexşeyê ji nû ve çêkin, beşek cache-ê betal bikin, û hwd, heke, mînakî, makîne ji nû ve hatibe destpêkirin, û pêdivî ye ku em bi rengekî daxwazên karûbarê bikin. Em bi tenê li her malperê yek cache wêneya hilanînê digirin, ku wekî şûna her makîneyek ku niha têkçûyî tevdigere. Û heke ji nişkê ve yek ji serverên me neberdest bibe, seyrûsefer diçe wir. Bi xwezayî, me li wir cache tune, yanî. sar e, lê bi kêmanî daxwazên bikarhêner têne kirin. Ger ev navberek kurt be, wê hingê em wê bi tevahî bi aramî biceribînin. Li ser hilanînê tenê barek zêde heye. Ger ev navber dirêj be, wê hingê em dikarin jixwe biryarek bidin - em vê serverê ji nexşeyê derxînin an na, an jî dibe ku wê bi yekî din veguherînin.
Ev li ser pergala caching e. Ka em li encaman binêrin.
Wusa dixuye ku li vir tiştek tevlihev tune. Lê vê rêbaza birêvebirina cache-ê rêjeyek xapandinê ya bi qasî 98% da me. Ewan. Ji van 80 hezar daxwazî di çirkeyê de, tenê 1600 digihîjin hilanînê, û ev barek bi tevahî normal e, ew bi aramî wê radigirin, her gav rezervek me heye.
Me van pêşkêşkeran li sê DC-yên xwe bi cih kir, û sê xalên hebûnê wergirtin - Prague, Miami û Hong Kong.
Va. ew kêm-zêde li her yek ji bazarên me yên armanca me cih digirin.
Û wekî bonusek xweş, me ev proxy caching, ya ku CPU bi rastî bêkar e, stend, ji ber ku ew qas ne hewce ye ku ji naverokê re xizmet bike. Û li wir, bi karanîna NGINX+ Lua, me gelek mantiqên utilitarîst bicîh anîn.
Mînakî, em dikarin bi webp an jpeg-ya pêşverû biceribînin (ev formatên nûjen ên bi bandor in), bibînin ka ew çawa bandorê li trafîkê dike, hin biryaran bidin, ji bo hin welatan çalak bikin, hwd.; Di firînê de mezinahiya dînamîk çêbikin an wêneyan jê bikin.
Dema ku, mînakî, we serîlêdanek mobîl heye ku wêneyan nîşan dide, û serîlêdana mobîl naxwaze CPU-ya xerîdar li ser daxwazkirina wêneyek mezin winda bike û dûv re pîvana wê bi pîvanek diyarkirî veguhezîne da ku wê bikeve hundurê. dîtinê. Em dikarin di URL-ya şertî ya UPort de bi rengek dînamîkî hin pîvanan diyar bikin, û cacheya wêneyê dê mezinahiya wêneyê bixwe biguherîne. Wekî qaîdeyek, ew ê mezinahiya ku me bi fizîkî li ser dîskê heye, bi qasî ku mimkun nêzîkê ya daxwazkirî ye hilbijêrin, û wê di koordînatên taybetî de bifroşe.
Bi awayê, me tomarên vîdyoyê yên pênc salên paşîn ên konferansa pêşdebirên pergalên bargiraniyê ji raya giştî re çêkir. . Temaşe bikin, fêr bibin, parve bikin û bibin abone .
Em dikarin li wir gelek mantiqa hilberê jî zêde bikin. Mînakî, em dikarin bi karanîna pîvanên URL-ê nîşaneyên cihêreng lê zêde bikin, em dikarin wêneyan bişewitînin, bişewitînin an pixel bikin. Ev gava ku em dixwazin wêneyek kesek nîşan bidin, lê em naxwazin rûyê wî nîşan bidin, ev baş dixebite, hemî li vir têne bicîh kirin.
Me çi girt? Me sê xalên hebûnê, rêjeyek xapandinê ya baş girt, û di heman demê de li ser van makîneyan CPU-ya betal tune. Ew niha, bê guman, ji berê girîngtir bûye. Pêdivî ye ku em otomobîlên bihêztir bidin xwe, lê ew hêja ye.
Ev li ser vegera wêneyan e. Li vir her tişt pir zelal û eşkere ye. Ez difikirim ku min Amerîka keşif nekir, hema hema her CDN bi vî rengî dixebite.
Û, bi îhtîmalek mezin, guhdarek sofîstîke dibe ku pirsek hebe: çima ne tenê her tiştî li CDN-ê biguhezîne? Ew ê bi heman rengî be; hemî CDN-yên nûjen dikarin vê yekê bikin. Û çend sedem hene.
Ya yekem wêne ye.
Ev yek ji xalên sereke yên binesaziya me ye, û hewcedariya me bi qasî ku tê kontrol kirin heye. Ger ev cûreyek çareseriyek ji firoşkarek sêyemîn be, û hêza we li ser wê tune be, dê ji we re pir dijwar be ku hûn pê re bijîn dema ku we danehevek mezin hebe, û gava we herikînek pir mezin hebe. daxwazên bikarhêner.
Ez ji we re mînakek bidim. Naha, bi binesaziya xwe, em dikarin, mînakî, di bûyera hin pirsgirêkan an lêdana binê erdê de, biçin makîneyê û li wir tevlihev bikin, bi nisbetî biaxivin. Em dikarin berhevoka hin metrîkên ku tenê ji me re hewce ne zêde bikin, em dikarin bi rengek ceribandinê bikin, bibînin ka ev çawa bandorê li grafikan dike, û hwd. Niha gelek îstatîstîk li ser vê komê caching têne berhev kirin. Û em bi awayekî periyodîk lê dinêrin û demek dirêj li hin anomaliyan digerin. Ger ew li ser milê CDN bûya, kontrolkirina wê pir dijwartir bû. An jî, wek nimûne, eger qezayek çêbibe, em dizanin ku çi bûye, em dizanin çawa bi wê re bijîn û çawa bi ser bikevin. Ev encama yekem e.
Encama duyemîn di heman demê de pir dîrokî ye, ji ber ku pergal ji demek dirêj ve pêşve çûye, û di qonaxên cihêreng de gelek pêdiviyên karsaziyê yên cihêreng hebûn, û ew her gav di konsepta CDN-ê de cih nagirin.
Û xala ku ji ya berê derdikeve ev e
Ev ji ber ku li ser kaşên wêneyan me gelek mantiqên taybetî hene, ku her gav li ser daxwazê nayê zêdekirin. Ne mimkûn e ku CDN li ser daxwaza we hin tiştên xwerû li we zêde bike. Mînakî, heke hûn nexwazin ku xerîdar bikaribe tiştek biguhezîne URLan şîfre bikin. Ma hûn dixwazin URL-ya serverê biguhezînin û wê şîfre bikin, û dûv re hin pîvanên dînamîkî bişînin vir.
Ev çi encam pêşniyar dike? Di doza me de, CDN ne alternatîfek pir baş e.
Di doza we de, heke we hewcedariyên karsaziyê yên taybetî hebin, wê hingê hûn dikarin bi hêsanî tiştê ku min bi xwe nîşanî we da bicîh bînin. Û ev ê bi profîlek barkirinê ya wekhev re bêkêmasî bixebite.
Lê heke we cûreyek çareseriyek gelemperî hebe, û peywir ne pir taybetî ye, hûn dikarin bi ewlehî CDN-ê bigirin. An jî heke dem û çavkanî ji we re ji kontrolê girîngtir in.
Û CDN-yên nûjen hema hema her tiştê ku min niha ji we re got heye. Ji bilî plus an kêm hin taybetmendiyên.
Ev li ser dayîna wêneyan e.
Naha em di paşverûtiya xwe de hinekî pêşde biçin û li ser hilanînê biaxivin.
2013 derbas bû.
Pêşkêşkerên caching hatin zêdekirin, pirsgirêkên performansê derketin. Her tişt baş e. Dataset mezin dibe. Ji sala 2013-an pê ve, me bi qasî 80 pêşkêşkerên ku bi hilanînê ve girêdayî bûn, û li her DC-yê nêzîkê 40 caching hebûn. Ev 560 terabytes daneyên li ser her DC-ê ye, i.e. bi tevahî li ser petabyte.
Û bi mezinbûna databasê re, lêçûnên xebitandinê bi girîngî dest pê kir. Wateya vê çi bû?
Di vê diyagrama ku hatiye xêzkirin - bi SAN, bi makîne û kaşên pê ve girêdayî - gelek xalên têkçûnê hene. Ger me berê berê bi têkçûna serverên caching re mijûl bibûya, her tişt kêm-zêde pêşbînîkirî û têgihîştî bû, lê ji hêla hilanînê ve her tişt pir xirabtir bû.
Pêşîn, Tora Herêmê ya Hilberînê (SAN) bixwe, ku dikare têk bibe.
Ya duyemîn, ew bi optîkê ve bi makîneyên paşîn ve girêdayî ye. Dibe ku pirsgirêk bi kartên optîkî û fîşekan re hebin.
Bê guman, ne bi qasî SAN bi xwe re ji wan hene, lê dîsa jî, ev jî xalên têkçûnê ne.
Piştre makîneya xwe ye, ku bi hilanînê ve girêdayî ye. Ew jî dikare têk bibe.
Bi tevahî, sê xalên me yên têkçûnê hene.
Digel vê yekê, ji bilî xalên têkçûnê, lênihêrîna giran a hilanînê bixwe jî heye.
Ev pergalek pir-pêkhatî ya tevlihev e, û endezyarên pergalê dikarin bi wê re bixebitin.
Û xala dawîn, ya herî girîng. Ger di yek ji van sê xalan de têkçûnek çêbibe, me şansek ne-sifir heye ku em daneyên bikarhêner winda bikin ji ber ku dibe ku pergala pelan têk bibe.
Em bêjin pergala pelê me şikestiye. Pêşîn, vegerandina wê demek dirêj digire - ew dikare hefteyek bi hejmarek mezin a daneyan bigire. Ya duyemîn jî, di dawiyê de bi îhtîmalek mezin em ê bi komek pelên nefêmkirî yên ku hewce ne bi rengekî di nav wêneyên bikarhêner de werin berhev kirin bi dawî bibin. Û em rîska windakirina daneyan. Rîsk pir zêde ye. Û her ku pir caran rewşên weha diqewimin, û di vê zincîrê de bêtir pirsgirêk derdikevin, ev xetere jî bilind dibe.
Diviyabû li ser vê yekê tiştek bihata kirin. Û me biryar da ku em tenê hewce ne ku daneyan paşde bikin. Ev bi rastî çareseriyek eşkere û baş e. Me çi kiriye?
Dema ku ew berê bi hilanînê ve girêdayî bû servera me bi vî rengî xuya dikir. Ev yek beşê sereke ye, ew tenê amûrek blokê ye ku bi rastî çiyayek ji bo hilanîna dûr bi riya optîkê temsîl dike.
Me tenê beşa duyemîn lê zêde kir.
Me li kêleka wê depoyek duyemîn danî (bextane, ew di warê drav de ne ew qas biha ye), û jê re dibêjin dabeşek paşvekişandinê. Ew jî bi rêya optîk ve girêdayî ye û li ser heman makîneyê ye. Lê divê em bi rengekî daneyan di navbera wan de hevdeng bikin.
Li vir em tenê li nêzê rêzek asynchronous çêdikin.
Ew ne pir mijûl e. Em dizanin ku têra qeydên me tune. Di MySQL de rêzek tenê tabloyek e ku tê de rêzikên mîna "pêdivî ye ku hûn vê wêneyê piştguh bikin" têne nivîsandin. Bi her guhertin an barkirinê re, em ji dabeşa sereke kopî dikin ku bi karanîna asynchronous an tenê celebek xebatkarek paşerojê bikar bînin.
Û bi vî awayî em her tim du beşên hevgirtî hene. Ger yek parçeyek vê pergalê têk biçe, em her gav dikarin bi paşvekişandinê ve dabeşkirina sereke biguhezînin, û her tişt dê berdewam bike.
Lê ji ber vê yekê, barê xwendinê pir zêde dibe, ji ber ku ... ji bilî xerîdarên ku ji beşa sereke dixwînin, ji ber ku ew pêşî li wêneyê li wir dinêrin (ew li wir nûtir e), û dûv re li paşvekişandinê digerin, heke wan ew nedîtibe (lê NGINX tenê vê yekê dike), pergala me di heman demê de piştgiriyek plus e ku naha ji dabeşa sereke dixwîne. Ne ew e ku ev kêşek bû, lê min nexwest ku bargiraniyê zêde bikim, bi rastî, bi vî rengî.
Û me dîska sêyem lê zêde kir, ku SSD-ya piçûk e, û jê re digotin tampon.
Çawa ew niha dixebite.
Bikarhêner wêneyek li tamponê bar dike, dûv re bûyerek tê avêtin nav rêzê ku destnîşan dike ku ew hewce ye ku di du beşan de were kopî kirin. Ew tê kopî kirin, û wêne demekê li ser tamponê dijî (bibêjin, rojek), û tenê hingê ji wir tê paqij kirin. Ev pir ezmûna bikarhêner çêtir dike, ji ber ku bikarhêner wêneyek bar dike, wekî qaîdeyek, daxwaz tavilê dest bi şopandinê dikin, an jî wî bixwe rûpelê nûve kir û nûve kir. Lê ew hemî bi serîlêdana ku barkirinê dike ve girêdayî ye.
An jî, wek nimûne, kesên din ên ku wî dest pê kir xwe nîşan bide, tavilê piştî vê wêneyê daxwazan dişînin. Ew hîn ne di cache de ye; daxwaza yekem pir zû pêk tê. Di bingeh de heman wekî ji cache wêneyê. Depokirina hêdî di vê yekê de qet nebe. Û gava ku rojek şûnda ew were paqij kirin, ew jixwe an li ser qata meya cachingê tê girtin, an jî, bi îhtîmalek mezin, êdî kes hewce nake. Ewan. Tecrûbeya bikarhêner li vir ji ber manipulasyonên weha hêsan pir baş mezin bûye.
Welê, û ya herî girîng: me windakirina daneyan rawestand.
Em bêjin em sekinîn potansiyel daneyan winda bikin, ji ber ku me ew bi rastî wenda nekir. Lê xeterî hebû. Em dibînin ku ev çareserî, bê guman, baş e, lê ew piçek mîna sivikkirina nîşanên pirsgirêkê ye, li şûna ku wê bi tevahî çareser bike. Û hin pirsgirêk li vir dimînin.
Ya yekem, ev xalek têkçûnek e ku di forma hosteya laşî bixwe de ye ku hemî vê makîneyê li ser dimeşîne; ew neçûye.
Ya duyemîn, hîn jî pirsgirêkên SAN hene, lênêrîna wan a giran, hwd. Ne ew bû ku ew faktorek krîtîk bû, lê min dixwest ku bi rengekî bêyî wê bijîm.
Û me guhertoya sêyemîn çêkir (bi rastî, ya duyemîn di rastiyê de) - guhertoya veqetandinê. Çawa xuya bû?
Ev çi bû -
Pirsgirêkên me yên sereke bi rastiya ku ev mêvandarek fîzîkî ye.
Pêşîn, em SAN-an jê dikin ji ber ku em dixwazin ceribandinê bikin, em dixwazin tenê dîskên hişk ên herêmî biceribînin.
Ev jixwe 2014-2015 e, û wê demê rewşa dîskan û kapasîteya wan di yek mêvandar de pir çêtir bû. Me biryar da ku çima wê neceribîne.
Dûv re em bi tenê dabeşkirina xweya paşde digirin û bi fizîkî wê vediguhezînin makîneyek cihê.
Bi vî rengî, em vê diagramê digirin. Du otomobîlên me hene ku heman danehevan hilînin. Ew hevûdu bi tevahî paşde vedigirin û daneyan li ser torê bi rêzek asynchronous di heman MySQL de hevdeng dikin.
Çima ev baş dixebite ji ber ku çend tomarên me hene. Ewan. ger nivîsandin bi xwendinê re bihata berawirdkirin, belkî hindek tor û problemên me hebin. Nivîsandin hindik e, pir xwendin - ev rêbaz baş dixebite, yanî. Em kêm kêm wêneyan di navbera van her du serveran de kopî dikin.
Ev çawa dixebite, heke hûn hinekî bi hûrgulî binêrin.
Upload. Balanser tenê bi cotek mêvandarên rasthatî hildibijêre û li wê bar dike. Di heman demê de, ew bi xwezayî vekolînên tenduristiyê dike û piştrast dike ku otomobîl dernakeve. Ewan. ew wêneyan tenê li serverek zindî bar dike, û dûv re bi rêzek asynkronî ew hemî ji cîranê xwe re tê kopî kirin. Bi barkirinê re her tişt pir hêsan e.
Kar hinekî dijwartir e.
Lua li vir alîkariya me kir, ji ber ku çêkirina mentiqek wusa li ser vanilla NGINX dijwar be. Em pêşî daxwazek ji servera yekem re dikin, bibînin ka wêne li wir e, ji ber ku potansiyel dikare were barkirin, mînakî, ji cîranek re, lê hîn nehatiye vir. Ger wêne li wir hebe, ew baş e. Em tavilê wê didin xerîdar û, dibe ku, wê cache bikin.
Ger ew ne li wir be, em bi tenê daxwazek ji cîranê xwe dikin û garantî dikin ku wê ji wir werbigirin.
Va. dîsa em dikarin bibêjin: dibe ku di performansê de pirsgirêk hebin, ji ber ku gerîdeyên domdar hene - wêne hate barkirin, ne li vir e, em li şûna yekê du daxwazan dikin, divê ev hêdî hêdî bixebite.
Di rewşa me de, ev hêdî hêdî naxebite.
Em li ser vê pergalê komek metrîkan berhev dikin, û rêjeya hişmendiya şertî ya mekanîzmayek wusa bi qasî 95%. Ewan. Derengiya vê paşvekişandinê piçûk e, û ji ber vê yekê em hema hema garantî ne, piştî ku wêne hate barkirin, em ê yekem car bigirin û neçar namînin ku du caran biçin deverek.
Ji ber vê yekê me çi din heye ku bi rastî xweş e?
Berê, me dabeşkirina paşgira sereke hebû, û me ji wan bi rêz dixwend. Ewan. Em her gav pêşî li ya sereke, û dûv re jî li paşvegirtinê geriyan. Ew yek tevger bû.
Naha em xwendina ji du makîneyan yekcar bikar tînin. Em daxwazan bi karanîna Round Robin belav dikin. Di rêjeyek piçûk de em du daxwazan dikin. Lê bi tevayî, me niha du qat zêdetir stokên xwendinê ji yên berê hene. Û bar hem li ser makîneyên şandinê û hem jî rasterast li ser makîneyên hilanînê, yên ku di wê demê de me jî hebûn, pir kêm bû.
Ji bo tolerasyona xeletiyê. Ya rastî me bi giranî ji bo vê şer kir. Bi tolerasyona xeletiyê, her tişt li vir mezin derket.
Otomobîlek diqelişe.
Bê pirsgirêkê! Endezyarek pergalê dibe ku bi şev jî şiyar nebe, ew ê heya sibehê li bendê bimîne, tiştek xirab nabe.
Ger ev makîne têk biçe jî, rêz ji rêzê dernakeve, ti pirsgirêk jî tune ne, dê têketin bi hêsanî pêşî li makîneya zindî were berhev kirin, û dûv re ew ê li dorê were zêdekirin, û dûv re jî li ser gerîdeya ku dê were zêde kirin. piştî demekê bikevin operasyonê.
Heman tişt bi lênêrînê re. Em bi tenê yek ji makîneyan dişewitînin, wê bi destan ji hemî hewzan derdixin, ew seyrûseferê distîne, em cûreyek lênihêrînê dikin, em tiştek diguhezînin, dûv re em wê vedigerînin karûbarê, û ev paşvekişandin pir zû digire. Ewan. her roj, dema daketina yek otomobîlê di nav çend hûrdeman de digire. Ev bi rastî pir hindik e. Bi tolerasyona xeletiyê, ez dîsa dibêjim, her tişt li vir xweş e.
Çi encam dikarin ji vê pilana zêdebûnê werin derxistin?
Me tolerasyona xeletiyê girt.
Bikaranîna hêsan e. Ji ber ku makîneyan xwedan dîskên hişk ên herêmî ne, ev ji bo endezyarên ku pê re dixebitin ji hêla xebitandinê ve pir hêsantir e.
Me ducar yarmetiya xwendinê wergirt.
Ev ji bilî tolerasyona xeletiyê bonusek pir baş e.
Lê pirsgirêk jî hene. Naha me pêşkeftinek pir tevlihev a hin taybetmendiyên bi vê yekê re têkildar heye, ji ber ku pergal di dawiyê de 100% hevgirtî bûye.
Divê em bibêjin, di hin karekî paşîn de, bi berdewamî bifikirin: "Em niha li ser kîjan serverê dixebitin?", "Gelo bi rastî wêneyek heyî li vir heye?" etc. Ev, bê guman, hemî pêçandî ye, û ji bo bernameçêkerê ku mantiqa karsaziyê dinivîse, ew zelal e. Lê, dîsa jî, ev tebeqeya tevlihev a mezin derketiye holê. Lê em amade ne ku di berdêla qenciyên ku me jê standine de vê yekê bitewînin.
Û li vir dîsa hinek nakokî derdikeve.
Min di destpêkê de got ku hilanîna her tiştî li ser dîskên hişk ên herêmî xirab e. Û niha ez dibêjim ku me jê hez kir.
Erê, bi rastî, bi demê re rewş pir guherî, û naha ev nêzîkatî gelek avantajên xwe hene. Ya yekem, em operasyonek pir hêsantir digirin.
Ya duyemîn, ew hilbertir e, ji ber ku em van kontrolkerên otomatîkî an girêdanên bi refên dîskê re nînin.
Li wir mîqdarek mezin a makîneyan heye, û ev tenê çend dîskên ku li vir li ser makîneyê di serdegirtinê de têne berhev kirin.
Lê kêmasî jî hene.
Ev bi qasî 1,5 carî ji karanîna SAN-ê bi bihayên îroyîn jî bihatir e. Ji ber vê yekê, me biryar da ku em bi wêrekî tevahiya koma xweya mezin veguherînin gerîdeyên hişk ên herêmî û biryar da ku em çareseriyek hîbrîd bihêlin.
Nîvê makîneyên me bi ajokarên hişk dixebitin (baş, ne nîv - dibe ku ji sedî 30). Û yên mayî otomobîlên kevn in ku berê xwedan nexşeya veqetandinê ya yekem bûn. Me bi hêsanî wan ji nû ve siwar kir, ji ber ku ne hewcedariya me dane daneyên nû an jî tiştek din bû, me bi tenê mount ji yek hosteyek laşî veguhezand du.
Û me niha stokek mezin a xwendinê heye, û me ew berfireh kir. Ger berê me yek hilanînê li ser yek makîneyek siwar kir, naha em çaran, mînakî, li ser yek cotek siwar dikin. Û ew baş dixebite.
Werin em bi kurtasî li ser tiştên ku me bi dest xistin, me ji bo çi şer kir, û gelo em bi ser ketine bi kurtî binihêrin.
Encam
Bikarhênerên me hene - bi qasî 33 mîlyon.
Sê xalên me hene - Prag, Miami, Hong Kong.
Di nav wan de qatek caching heye, ku ji otomobîlên bi dîskên herêmî yên bilez (SSD) pêk tê, ku li ser wan makîneyên hêsan ên NGINX, access.log û şeytanên wê yên Python dimeşînin, ku van hemîyan pêvajoyê dikin û cache-yê birêve dibin.
Ger hûn bixwazin, hûn di projeya xwe de ne, heke wêne ji bo we ne ew qas ji bo me krîtîk bin, an ger kontrolkirina bazirganiyê li hember leza pêşkeftinê û lêçûnên çavkaniyê ji we re di rêyek din de be, wê hingê hûn dikarin bi ewlehî wê biguhezînin. bi CDN re, CDN-yên nûjen ew baş dikin.
Dû re qata hilanînê tê, ku li ser me komek cot makîneyên ku pişta hev vedigirin hene, pelan her ku diguhezin bi asynkronî ji yek ji yekî din têne kopî kirin.
Wekî din, hin ji van makîneyan bi dîskên hişk ên herêmî re dixebitin.
Hin ji van makîneyan bi SAN ve girêdayî ne.
Û, ji aliyek ve, karanîna wê hêsantir e û hinekî hilberkertir e, ji hêla din ve, ew di warê dakêşana cîh û bihayê her gigabyte de hêsan e.
Ev nihêrînek wusa kurt e li ser mîmariya ku me çi girt û çawa ew hemî pêş ket.
Çend serişteyên din ji kaptan, yên pir hêsan.
Pêşîn, heke hûn ji nişkê ve biryar bidin ku hûn bi lezgîn hewce ne ku her tiştî di binesaziya wêneya xwe de baştir bikin, pêşî bipîvin, ji ber ku dibe ku tiştek ne hewce ye ku were çêtir kirin.
Ez ji we re mînakek bidim. Komek makîneyên me hene ku wêneyan ji pêvekan di sohbetan de dişîne, û nexşe ji sala 2009-an vir ve li wir dixebite, û kes jê aciz nabe. Her kes baş e, her kes ji her tiştî hez dike.
Ji bo pîvandinê, pêşî komek metrîkan daliqînin, li wan binihêrin, û dûv re biryar bidin ku hûn ji çi ne razî ne û çi hewce dike ku were çêtir kirin. Ji bo ku em vê yekê bipîvin, me amûrek xweş a bi navê Pinba heye.
Ew dihêle hûn ji bo her daxwaz û kodên bersivê, û dabeşkirina deman - her tiştê ku hûn dixwazin, statîstîkên pir berfireh ji NGINX berhev bikin. Ew bi her cûre pergalên analîtîk ên cihêreng ve girêdayî ye, û wê hingê hûn dikarin her tiştî bi xweşikî lê binêrin.
Pêşî me ew pîva, paşê me ew çêtir kir.
Berdewam. Em xwendina bi cache, nivîsandina bi parvekirinê xweştir dikin, lê ev xalek eşkere ye.
Berdewam. Heke hûn nuha dest bi avakirina pergala xwe dikin, wê hingê pir çêtir e ku hûn wêneyan wekî pelên neguhêrbar çêbikin. Ji ber ku hûn tavilê çînek tevahî pirsgirêkan bi betalkirina cache-ê winda dikin, digel ku meriv çawa divê guhertoya rast a wêneyê bibîne, û hwd.
Ka em bibêjin we sed barkir, dûv re zivirî, wusa bikin ku ew ji hêla fîzîkî ve pelek cûda bû. Ewan. ne hewce ye ku bifikirim: naha ez ê cîhek piçûk xilas bikim, wê li heman pelê binivîsim, guhertoyê biguherim. Ev her gav baş naxebite û paşê dibe sedema gelek serêş.
Xala Next. Der barê mezinbûnê de li ser firînê.
Berê, dema ku bikarhêneran wêneyek barkirin, me tavilê ji bo hemî bûyeran, ji bo xerîdarên cihêreng komek mezinahî qut kirin, û ew hemî li ser dîskê bûn. Niha me dev ji vê yekê berda.
Me tenê sê pîvanên sereke hiştin: piçûk, navîn û mezin. Em bi tenê her tiştê din ji mezinahiya ku li pişta ya ku li Uport ji me hatî xwestin kêm dikin, em bi tenê kêmkirina pîvanê dikin û didin bikarhêner.
CPU-ya qata caching-ê li vir ji ya ku em bi domdarî van pîvanan li ser her hilanînê ji nû ve nûve bikin pir erzantir derdikeve holê. Ka em bibêjin ku em dixwazin yek nû lê zêde bikin, ev dê mehekê bidome - li her deverê skrîptek bimeşîne ku dê van hemî bi rengek xweş bike, bêyî ku komê hilweşîne. Ewan. Ger fersenda weya hilbijartina nuha heye, çêtir e ku hûn bi qasî ku pêkan kêm pîvanên laşî çêbikin, lê bi vî rengî ku bi kêmanî hin belavkirin, bêje, sê be. Û her tiştê din dikare bi hêsanî bi karanîna modulên amadekirî di firînê de were guheztin. Ew niha pir hêsan û gihîştî ye.
Û paşvekêşana asynkron a zêdebûyî baş e.
Wekî ku pratîka me destnîşan kir, ev nexşe bi dereng kopîkirina pelên guhezbar re pir baş dixebite.
Xala dawî jî diyar e. Ger binesaziya we niha pirsgirêkên weha tunebe, lê tiştek heye ku dikare bişkîne, gava ku ew hinekî zêde bibe, bê guman dê bişkê. Ji ber vê yekê, çêtir e ku meriv di pêş de li ser vê yekê bifikire û bi wê re pirsgirêkan neke. Tiştê ku min dixwest bibêjim ev bû.
têkiliyên
»
»
Ev rapor ji yek ji baştirîn axaftinên konferansa pêşdebirên pergalên bargiraniya bilind e . Ji konferansa HighLoad++ 2017’an re ji mehekê kêmtir maye.
Jixwe me ew amade kiriye , bername niha bi awayekî aktîf tê çêkirin.
Îsal em lêkolîna mijara mîmarî û pîvandinê berdewam dikin:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Em di qursa xweya perwerdehiya serhêl de li ser pêşxistina pergalên bargiraniyê jî hin ji van materyalan bikar tînin zincîrek ji name, gotar, materyal, vîdyoyên taybetî yên bijartî ye. Pirtûka me ya dersê jixwe zêdetirî 30 materyalên bêhempa dihewîne. Bihevgirêdan!
Source: www.habr.com