Netflix di bazara televîzyona Înternetê de pêşeng e - pargîdaniya ku vê beşê afirandiye û bi rengek çalak pêş dixe. Netflix ne tenê ji ber kataloga xweya berfireh a fîlim û rêzefîlmên TV-yê ku hema hema ji her quncikek gerstêrkê û her amûrek bi dîmender heye, di heman demê de ji bo binesaziya pêbawer û çanda endezyariya bêhempa jî tê zanîn.
Nimûneyek zelal a nêzîkatiya Netflix ji bo pêşkeftin û piştgirîkirina pergalên tevlihev di DevOops 2019 de hate pêşkêş kirin - Rêveberê Pêşkeftinê li Netflix. Derçûyê Fakulteya Matematîk û Matematîkê ya Hesabkirî ya Zanîngeha Dewletê ya Nîjnî Novgorodê ye. Lobachevsky, Sergey yek ji endezyarên yekem ên Open Connect - Tîma CDN li Netflix. Wî pergalên şopandin û analîzkirina daneyên vîdyoyê ava kir, karûbarek populer ji bo nirxandina leza pêwendiya Înternetê FAST.com da destpêkirin, û van çend salên dawîn li ser xweşbînkirina daxwazên Internetnternetê dixebite da ku serîlêdana Netflix bi zûtirîn dem ji bikarhêneran re bixebite.
Rapor ji beşdarên konferansê nirxandinên herî baş wergirt û me ji we re versiyonek nivîsê amade kir.
Di rapora xwe de Sergey bi berfirehî axivî
- li ser çi bandorê li derengiya daxwazên Înternetê di navbera xerîdar û serverê de dike;
- çawa ji bo kêmkirina vê derengiyê;
- çawa sêwirandin, parastin û çavdêrîkirina pergalên toleransê çewtiyê;
- meriv çawa di demek kin de, û bi xetereyek hindiktirîn ji karsaziyê re encam digire;
- meriv çawa encaman analîz dike û ji xeletiyan fêr dibe.
Bersivên van pirsan ne tenê ji hêla kesên ku di pargîdaniyên mezin de dixebitin hewce ne.
Divê prensîb û teknîkên pêşkêşkirî ji hêla her kesê ku hilberên Înternetê pêşve dike û piştgirî dike ve were zanîn û pratîk kirin.
Piştre vegotina ji perspektîfa axaftvan e.
Girîngiya leza înternetê
Leza daxwazên Înternetê rasterast bi karsaziyê ve girêdayî ye. Pîşesaziya kirînê bifikirin: Amazon di 2009 de ku derengiya 100ms dibe sedema windakirina% 1 ya firotanê.
Zêdetir û bêtir amûrên mobîl hene, li pey malper û serlêdanên mobîl hene. Ger barkirina rûpela we ji 3 çirkeyan dirêjtir digire, hûn bi qasî nîvê bikarhênerên xwe winda dikin. BI Google di encamên lêgerînê de leza barkirina rûpela we dihesibîne: rûpel çiqas zûtir be, ew qas pozîsyona wê di Google de bilindtir dibe.
Leza girêdanê di saziyên darayî de ku dereng krîtîk e jî girîng e. Di 2015 de, Hibernia Networks kabloyek 400 mîlyon dolarî di navbera New York û Londonê de da ku derengiya di navbera bajaran de 6ms kêm bike. Ji bo 66 ms kêmkirina derengbûnê 1 mîlyon dolar xeyal bikin!
Li gorî , Leza pêwendiyê li jor 5 Mbit/s êdî rasterast bandorê li leza barkirina malperek tîpîk nake. Lêbelê, di navbera derengiya girêdanê û leza barkirina rûpelê de têkiliyek rêzik heye:
Lêbelê, Netflix ne hilberek tîpîk e. Bandora dereng û lezê ya li ser bikarhêner herêmek çalak a analîz û pêşkeftinê ye. Barkirina serîlêdanê û bijartina naverokê heye ku bi derengbûnê ve girêdayî ye, lê barkirina hêmanên statîk û weşan jî bi leza girêdanê ve girêdayî ye. Analîzkirin û xweşbînkirina faktorên sereke yên ku bandorê li ser ezmûna bikarhêner dikin ji bo çend tîmên Netflix herêmek çalak a pêşkeftinê ye. Yek ji armanc kêmkirina derengiya daxwazên di navbera cîhazên Netflix û binesaziya ewr de ye.
Di raporê de em ê bi taybetî li ser kêmkirina derengiyê bi mînaka binesaziya Netflix bisekinin. Ka em ji nêrînek pratîkî bifikirin ka meriv çawa nêzikî pêvajoyên sêwirandin, pêşkeftin û xebitandina pergalên belavbûyî yên tevlihev dibe û wextê xwe li ser nûbûn û encaman xerc dike, ji bilî teşhîskirina pirsgirêkên xebitandinê û têkçûn.
Di hundurê Netflix de
Bi hezaran cîhazên cihêreng sepanên Netflix piştgirî dikin. Ew ji hêla çar tîmên cihêreng ve têne pêşve xistin, ku ji bo gerokên Android, iOS, TV û malperê guhertoyên cihêreng ên xerîdar çêdikin. Û em ji bo başkirin û kesanekirina ezmûna bikarhêner gelek hewl didin. Ji bo vê yekê, em bi sedan ceribandinên A/B bi paralel dimeşînin.
Kesanebûn ji hêla bi sedan mîkroxizmetên di ewrê AWS-ê de tê piştgirî kirin, daneyên bikarhêner ên kesane, şandina pirsê, telemetrî, Daneyên Mezin û şîfrekirinê peyda dike. Visualîzasyona trafîkê bi vî rengî xuya dike:
Li milê çepê xala têketinê ye, û dûv re seyrûsefer di nav çend sed mîkroxizmetên ku ji hêla tîmên paşverû yên cihêreng ve têne piştgirî kirin de tê belav kirin.
Parçeyek din a girîng a binesaziya me Open Connect CDN e, ku naveroka statîk ji bikarhênerê dawî re peyda dike - vîdyoy, wêne, koda xerîdar, hwd. CDN li ser serverên xwerû (OCA - Open Connect Appliance) cih digire. Di hundurê de rêzikên ajokarên SSD û HDD hene ku FreeBSD-ya xweşbînkirî, bi NGINX û komek karûbar dimeşînin. Em hêmanên hardware û nermalavê sêwiran dikin û xweşbîn dikin da ku serverek CDN-ya wusa bikaribe bi qasî ku pêkan data ji bikarhêneran re bişîne.
"Dîwar" van serveran li xala danûstendina seyrûsefera Înternetê (Internet eXchange - IX) bi vî rengî xuya dike:
Exchange Înternetê şiyana pêşkêşkerên karûbarê Înternetê û pêşkêşkerên naverokê peyda dike ku bi hev re "girêbidin" da ku rasterast daneyên li ser Înternetê biguhezînin. Nêzîkî 70-80 xalên Exchange Înternetê li çaraliyê cîhanê hene ku serverên me lê têne saz kirin, û em wan serbixwe saz dikin û diparêzin:
Digel vê yekê, em rasterast pêşkêşkeran jî pêşkêşî pêşkêşkerên Internetnternetê dikin, ku ew di tora xwe de saz dikin, herêmîkirina seyrûsefera Netflix û kalîteya weşanê ji bo bikarhêneran baştir dike:
Komek karûbarên AWS berpirsiyar e ku daxwazên vîdyoyê ji xerîdaran berbi serverên CDN-ê veguhezîne, û her weha mîhengkirina serveran bixwe - nûvekirina naverok, koda bernameyê, mîhengan, hwd. Ji bo ya paşîn, me di heman demê de torgilokek piştê jî ava kir ku serverên di xalên Exchange Înternetê bi AWS-ê ve girêdide. Tora piştê torgilokek gerdûnî ya kabloyên fiber optîk û rêweran e ku em dikarin li gorî hewcedariyên xwe sêwiran û mîheng bikin.
Bi , binesaziya meya CDN bi qasî ⅛ ji seyrûsefera Înternetê ya cîhanê di demjimêrên lûtkeyê de û ⅓ ji seyrûsefera li Amerîkaya Bakur, ku Netflix li dora herî dirêj e, peyda dike. Hejmarên berbiçav, lê ji bo min yek ji destkeftiyên herî ecêb ev e ku tevahiya pergala CDN-ê ji hêla tîmek kêmtirî 150 kesan ve hatî pêşve xistin û domandin.
Di destpêkê de, binesaziya CDN hate çêkirin ku daneyên vîdyoyê radest bike. Lêbelê, bi demê re me fêm kir ku em dikarin wê jî bikar bînin da ku daxwazên dînamîkî yên ji xerîdarên di ewrê AWS-ê de xweşbîn bikin.
Li ser lezkirina Înternetê
Îro, Netflix 3 herêmên AWS hene, û derengiya daxwazên ji ewr re girêdayî ye ku xerîdar çiqas ji herêma herî nêzîk dûr e. Di heman demê de, me gelek serverên CDN hene ku ji bo radestkirina naveroka statîk têne bikar anîn. Ma rêyek heye ku meriv vê çarçoveyê bikar bîne da ku pirsên dînamîkî bilez bike? Lêbelê, mixabin, ne gengaz e ku van daxwazan cache bikin - API kesane ne û her encam yekta ye.
Werin em li ser servera CDN proxyek çêbikin û dest bi şandina seyrûseferê bikin. Ma ew ê zûtir be?
Materiel
Ka em bînin bîra xwe ka protokolên torê çawa dixebitin. Îro, piraniya seyrûsefera li ser Înternetê HTTP-ê bikar tîne, ku bi protokolên qata jêrîn TCP û TLS ve girêdayî ye. Ji bo ku xerîdar bi serverê ve girêbide, ew destan dike, û ji bo pêwendiyek ewledar saz bike, pêdivî ye ku xerîdar sê caran bi serverê re peyaman biguhezîne û bi kêmî ve carek din ji bo veguheztina daneyan. Bi derengiya her gera dor (RTT) ya 100 ms, ji me re 400 ms hewce dike ku em bit yekem a daneyê bistînin:
Ger em sertîfîkayan li ser servera CDN bi cîh bikin, wê hingê dema destan di navbera xerîdar û serverê de dikare pir kêm bibe heke CDN nêzîktir be. Ka em bihesibînin ku derengiya servera CDN 30ms e. Dûv re ew ê 220 ms bigire ku bit yekem bistîne:
Lê avantajên li wir bi dawî nabin. Dema ku têkiliyek hate damezrandin, TCP pencereya tevliheviyê zêde dike (hejmara agahdariya ku ew dikare li ser wê pêwendiyê bi paralelî veguhezîne). Ger pakêtek daneyê winda bibe, wê hingê pêkanînên klasîk ên protokola TCP (mîna TCP New Reno) "pencereya" vekirî nîvî kêm dikin. Mezinbûna pencereya qelebalixiyê, û leza vegerandina wê ji windabûnê dîsa bi derengiya (RTT) ya serverê ve girêdayî ye. Ger ev girêdan tenê heya servera CDN-ê biçe, dê ev hilanîn zûtir be. Di heman demê de, windabûna pakêtê fenomenek standard e, nemaze ji bo torên bêtêl.
Dibe ku pêlava înternetê kêm bibe, nemaze di demjimêrên lûtkeyê de, ji ber seyrûsefera bikarhêneran, ku dibe sedema qelebalixiya trafîkê. Lêbelê, li ser Înternetê rêyek tune ku pêşî li hin daxwazan bide ser yên din. Mînakî, berê xwe bidin daxwazên piçûk û dereng-hesas ên daneya "giran" ên ku torê bar dikin. Lêbelê, di doza me de, hebûna tora pişta xweya me dihêle ku em vê yekê li ser beşek ji riya daxwazê - di navbera CDN û ewr de bikin, û em dikarin wê bi tevahî mîheng bikin. Hûn dikarin pê ewle bin ku pakêtên piçûk û dereng-hesas têne pêşîn kirin, û herikîna daneya mezin hinekî paşde diçin. CDN her ku nêzîkê xerîdar be, karîgerî jî mezintir dibe.
Protokolên asta serîlêdanê (OSI Level 7) jî bandorek li ser derengiyê heye. Protokolên nû yên wekî HTTP/2 performansa daxwazên paralel xweştir dikin. Lêbelê, me xerîdarên Netflix bi cîhazên kevntir ên ku protokolên nû piştgirî nakin hene. Ne hemî xerîdar dikarin bêne nûve kirin an bi rengek çêtirîn vesaz kirin. Di heman demê de, di navbera proxy CDN û ewr de kontrolek bêkêmasî û şiyana karanîna protokol û mîhengên nû, çêtirîn heye. Parçeyek bêbandor bi protokolên kevn dê tenê di navbera xerîdar û servera CDN de bixebite. Digel vê yekê, em dikarin li ser pêwendiyek jixwe sazkirî ya di navbera CDN û ewr de daxwazên piralî bikin, di asta TCP de karanîna pêwendiyê baştir bikin:
Em dipîvin
Tevî vê rastiyê ku teorî soza pêşketinan dide, em tavilê lez nakin ku pergalê di hilberînê de bidin destpêkirin. Di şûna wê de, divê em pêşî îspat bikin ku fikir dê di pratîkê de bixebite. Ji bo vê yekê hûn hewce ne ku çend pirsan bersiv bikin:
- Lez: dê proxy zûtir be?
- Ewlehiyê: Dê pirtir bişkê?
- Tevlîheviyê: Meriv çawa bi sepanan re entegre dibe?
- mesrefa: Mesrefa danîna binesaziya zêde çiqas e?
Ka em bi hûrgulî nêzîkatiya xwe ya ji bo nirxandina xala yekem binirxînin. Yên mayî jî bi heman şêweyî têne kirin.
Ji bo analîzkirina leza daxwazan, em dixwazin ji bo hemî bikarhêneran daneyan bi dest bixin, bêyî ku gelek dem li ser pêşkeftinê xerc bikin û bêyî ku hilberînê bişkînin. Ji bo vê çend rêbaz hene:
- RUM, an pîvana daxwaza pasîf. Em dema pêkanîna daxwazên heyî yên ji bikarhêneran dipîvin û vegirtina tevahî ya bikarhêner piştrast dikin. Kêmasî ev e ku sînyala ji ber gelek faktoran ne pir aram e, mînakî, ji ber mezinahiyên daxwaziya cihêreng, dema pêvajoyê li ser server û xerîdar. Wekî din, hûn nekarin mîhengek nû bêyî bandor di hilberînê de biceribînin.
- Testên laboratîf. Pêşkêşker û binesaziya taybetî ya ku xerîdaran simule dikin. Bi alîkariya wan em ceribandinên pêwîst dikin. Bi vî rengî em kontrola tam li ser encamên pîvandinê û nîşanek zelal digirin. Lê dorpêkek bêkêmasî ya cîhaz û cîhên bikarhêneran tune (nemaze bi karûbarek cîhanî û piştgirî ji hezaran modelên cîhazê re).
Hûn çawa dikarin avantajên her du rêbazan li hev bikin?
Tîma me çareseriyek dîtiye. Me kodek piçûk nivîsand - mînakek - ku me di serîlêdana xwe de çêkir. Lêpirsîn rê dide me ku em ceribandinên torê yên bi tevahî kontrolkirî ji cîhazên xwe bikin. Ew bi vî rengî dixebite:
- Demek kin piştî barkirina serîlêdanê û qedandina çalakiya destpêkê, em lêkolînên xwe dimeşînin.
- Xerîdar ji serverê re daxwazek dike û ji bo ceribandinê "reçete" distîne. Reçete navnîşek URL-an e ku hewce ye ku daxwazek HTTP(an) jê re were çêkirin. Wekî din, reçete pîvanên daxwaznameyê mîheng dike: dereng di navbera daxwazan de, mîqdara daneya daxwazkirî, sernavên HTTP(s), hwd. Di heman demê de, em dikarin çend reçeteyên cihêreng bi hev re biceribînin - dema ku veavakirinek daxwaz dikin, em bi rasthatinî diyar dikin ka kîjan reçeteyê derxînin.
- Dema destpêkirina lêpirsînê tê hilbijartin da ku bi karanîna çalak a çavkaniyên torê yên li ser xerîdar re nakokî nebe. Di bingeh de, dema ku xerîdar ne çalak be dem tê hilbijartin.
- Piştî wergirtina reçeteyê, xerîdar ji her yek ji URL-an re, paralelî daxwazan dike. Daxwaza her yek ji navnîşan dikare were dubare kirin - bi navê. "pişk". Di pulsa yekem de, em dipîvin ka çiqas dem ji bo sazkirina pêwendiyek û dakêşana daneyê girt. Li ser pêla duyemîn, em wextê ku ew ji bo barkirina daneyan li ser pêwendiyek jixwe hatî damezrandin dipîve. Berî ya sêyemîn, em dikarin derengiyek saz bikin û leza sazkirina vegirêdanek, hwd bipîvin.
Di dema ceribandinê de, em hemî pîvanên ku amûr dikare bi dest bixe dipîvin:
- Dema daxwaza DNS;
- dema sazkirina girêdana TCP;
- dema sazkirina girêdana TLS;
- dema wergirtina baytê yekem a daneyê;
- dema barkirinê ya tevahî;
- koda encama statûyê.
- Piştî ku hemî pêl biqedin, nimûne ji bo analîzê hemî pîvandinê bar dike.
Xalên sereke girêdayîbûna hindiktirîn a bi mantiqê li ser xerîdar, pêvajokirina daneyê li ser serverê û pîvandina daxwazên paralel in. Bi vî rengî, em dikarin bandora faktorên cihêreng ên ku li ser performansa pirsê bandor dikin veqetînin û ceribandin, wan di nav yek reçeteyekê de biguhezînin, û ji xerîdarên rastîn encam bistînin.
Vê binesaziyê ji analîza performansa pirsê wêdetir kêrhatî îsbat kiriye. Heya nuha 14 reçeteyên me yên çalak hene, ji 6000 zêdetir nimûne di çirkeyê de, wergirtina daneyan ji hemî kujên dinyayê û vegirtina cîhaza tevahî. Ger Netflix karûbarek wusa ji partiyek sêyemîn bikira, ew ê salê bi mîlyonan dolar lêçû, bi vegirtina pir xirabtir.
Teoriya ceribandinê di pratîkê de: prototîp
Bi pergalek wusa, me karîbû bandora proxeyên CDN li ser derengiya daxwazê binirxînin. Niha hûn hewce ne:
- prototîpek proxy çêbikin;
- prototîpa li ser CDN bi cih bikin;
- diyar bikin ka meriv çawa xerîdaran li ser proxyek li ser serverek CDN-ya taybetî rêve dike;
- Performansê bi daxwazên di AWS-ê de bêyî proxy berhev bikin.
Erk ev e ku bi lez û bez bandora çareseriya pêşniyarî binirxîne. Me ji ber hebûna pirtûkxaneyên torê yên baş Go ji bo pêkanîna prototîpê hilbijart. Li ser her serverek CDN, me proxeya prototîpa wekî binaryek statîk saz kir da ku pêwendiyan kêm bike û yekbûnê hêsan bike. Di pêkanîna destpêkê de, me bi qasî ku gengaz be pêkhateyên standard û guheztinên piçûk ji bo berhevkirina girêdana HTTP/2 bikar anîn û pirrengkirina daxwaz dikin.
Ji bo hevsengiya di navbera herêmên AWS de, me databasek DNS-ya erdnîgarî bikar anî, heman ku ji bo balanskirina xerîdaran tê bikar anîn. Ji bo ku ji bo xerîdar serverek CDN hilbijêrin, em TCP Anycast ji bo pêşkêşkerên di Exchange Internet (IX) de bikar tînin. Di vê vebijarkê de, em ji bo hemî pêşkêşkerên CDN yek navnîşana IP-yê bikar tînin, û xerîdar dê bi hindiktirîn hejmarên IP-ê ber bi servera CDN ve were rêve kirin. Di pêşkêşkerên CDN-ê de ku ji hêla pêşkêşkerên Înternetê (ISP) ve hatine saz kirin, kontrola me li ser routerê tune ku TCP Anycast mîheng bike, ji ber vê yekê em bikar tînin , ku xerîdar ji bo weşana vîdyoyê ber bi pêşkêşkerên Înternetê ve dibe.
Ji ber vê yekê, me sê celeb riyên daxwaznameyê hene: ber bi ewr ve bi riya Înternetê vekirî, bi serverek CDN-ê li IX, an bi navgîniya serverek CDN-ê ku li pêşkêşkerek Internetnternetê ye. Armanca me ev e ku em fêm bikin ka kîjan rê çêtir e, û çi feydeya proxy heye, li gorî ka çawa daxwaz ji hilberînê re têne şandin. Ji bo vê yekê, em pergala nimûneyê wekî jêrîn bikar tînin:
Her rêyek dibe armancek cihê, û em li dema ku me girtine dinêrin. Ji bo analîzê, em encamên proxy di yek komê de berhev dikin (dema çêtirîn di navbera IX û proxy ISP de hilbijêrin), û wan bi dema daxwaznameyên ewr re bêyî proxy berhev bikin:
Wekî ku hûn dikarin bibînin, encam tevlihev bûn - di pir rewşan de proxy bilezek baş dide, lê di heman demê de hejmareke têr xerîdar jî hene ku rewş dê bi giranî xirab bibe.
Di encamê de, me çend tiştên girîng kirin:
- Me performansa bendewar a daxwazên ji xerîdaran ji ewr re bi navgînek CDN-ê nirxand.
- Me daneyên ji xerîdarên rastîn, ji her cûre cîhazan wergirtin.
- Me fêm kir ku teorî% 100 nehatiye pejirandin û pêşniyara destpêkê ya bi proxy CDN re dê ji me re nexebite.
- Me rîsk negirt - me mîhengên hilberînê ji bo xerîdaran neguherand.
- Tiştek nehat şikandin.
Prototîpa 2.0
Ji ber vê yekê, vegerin ser tabloya xêzkirinê û pêvajoyê ji nû ve dubare bikin.
Fikir ev e ku li şûna ku em proxyek 100% bikar bînin, em ê ji bo her xerîdar riya herî bilez destnîşan bikin, û em ê daxwazan li wir bişînin - ango, em ê ya ku jê re tê gotin rêveberiya xerîdar bikin bikin.
Çawa pêkanîna vê yekê? Em nikarin mantiqê li aliyê serverê bikar bînin, ji ber ku ... Armanc girêdana vê serverê ye. Pêdivî ye ku rêyek hebe ku meriv vê yekê li ser xerîdar bike. Û bi îdeal, vê yekê bi hindiktirîn mentiqek tevlihev bikin, da ku hûn pirsgirêka yekbûnê bi hejmareke mezin ji platformên xerîdar re çareser nekin.
Bersiv karanîna DNS-ê ye. Di doza me de, me binesaziya xweya DNS heye, û em dikarin herêmek domainê saz bikin ku serverên me dê otorîter bin. Ew bi vî rengî dixebite:
- Xerîdar bi karanîna mêvandarek, mînakî api.netflix.xom, daxwazek ji servera DNS re dike.
- Daxwaz digihîje servera meya DNS
- Pêşkêşkara DNS dizane kîjan rê ji bo vê xerîdar zûtir e û navnîşana IP-ya têkildar derdixe.
Çareserî tevliheviyek din heye: Pêşkêşkerên DNS yên otorîter navnîşana IP-ya xerîdar nabînin û tenê dikarin navnîşana IP-ya çareserkerê vegerî ya ku xerîdar bikar tîne bixwînin.
Wekî encamek, çareserkerê me yê otorîter divê ne ji bo xerîdarek kesane, lê ji bo komek xerîdar li ser bingeha çareserkerê vegerî biryarek bide.
Ji bo çareserkirinê, em heman nimûneyan bikar tînin, encamên pîvandinê yên ji xerîdaran ji bo her yek ji çareserkerên paşverû berhev dikin û biryar didin ku em vê koma wan li ku derê bişînin - proxyek bi navgîniya IX ve bi karanîna TCP Anycast, bi navgînek ISP, an rasterast ji ewr re.
Em pergala jêrîn digirin:
Modela rêvekirina DNS-ê ya encam dide we dihêle ku hûn xerîdaran li ser bingeha çavdêriyên dîrokî yên leza girêdanên ji xerîdar bi ewr re rasterast bikin.
Dîsa, pirs ev e ku ev nêzîkatî dê çiqas bi bandor bixebite? Ji bo bersivê, em dîsa pergala xweya lêpirsînê bikar tînin. Ji ber vê yekê, em veavakirina pêşkêşkerê mîheng dikin, li cihê ku yek ji armanc rêwerzê ji rêberiya DNS dişopîne, ya din rasterast diçe ewr (hilberîna heyî).
Wekî encamek, em encaman berhev dikin û nirxandinek bandorbûnê digirin:
Di encamê de, em çend tiştên girîng fêr bûn:
- Me performansa bendewar a daxwazên ji xerîdaran ji ewr re bi karanîna Rêvebiriya DNS nirxand.
- Me daneyên ji xerîdarên rastîn, ji her cûre cîhazan wergirtin.
- Bandoriya ramana pêşniyarê hate îsbat kirin.
- Me rîsk negirt - me mîhengên hilberînê ji bo xerîdaran neguherand.
- Tiştek nehat şikandin.
Naha li ser beşa dijwar - em wê di hilberînê de didin destpêkirin
Beşa hêsan êdî qediya - prototîpek xebatê heye. Naha beşa dijwar ji bo hemî seyrûsefera Netflix-ê çareseriyek dest pê dike, ji 150 mîlyon bikarhêneran, bi hezaran cîhazan, bi sedan mîkro-servîs û hilberek û binesaziyek ku her gav diguhezîne. Pêşkêşkerên Netflix di çirkeyê de bi mîlyonan daxwazan distînin, û hêsan e ku karûbarê bi çalakiya bêhiş bişkînin. Di heman demê de, em dixwazin bi dînamîk seyrûseferê bi hezaran serverên CDN-ê yên li ser Înternetê rêve bibin, ku tiştek bi domdarî û di demek herî neguncan de diguhezîne û dişkîne.
Û digel van hemûyan, tîmê 3 endezyarên ku ji pêşkeftin, bicîhkirin û piştgirîya tevahî ya pergalê berpirsiyar in.
Ji ber vê yekê, em ê berdewam bikin ku li ser xewna aram û tendurist biaxivin.
Meriv çawa pêşkeftinê bidomîne û hemî wextê xwe li ser piştgirîyê xerc neke? Rêbaza me li ser 3 prensîban e:
- Em pîvana potansiyela têkçûnê (radyoya teqînê) kêm dikin.
- Em ji bo surprîz amade dikin - em li bendê ne ku her çend ceribandin û ezmûna kesane tiştek bişkê.
- Xerabûna dilşewat - heke tiştek rast nexebite, divê ew bixweber were rast kirin, her çend ne bi awayê herî bikêr be.
Derket holê ku di rewşa me de, bi vê nêzîkatiya pirsgirêkê re, em dikarin çareseriyek hêsan û bi bandor bibînin û piştgiriya pergalê bi girîngî hêsan bikin. Me fêm kir ku em dikarin perçeyek piçûk a kodê li xerîdar zêde bikin û xeletiyên daxwaza torê yên ku ji ber pirsgirêkên pêwendiyê derketine bişopînin. Di bûyera xeletiyên torê de, em rasterast li ser ewr paşvegerek çêdikin. Ev çareserî ji bo tîmên xerîdar hewildanek girîng hewce nake, lê xetera têkçûn û surprîzên nediyar ji bo me pir kêm dike.
Bê guman, tevî paşveçûnê, em dîsa jî di dema pêşkeftinê de dîsîplînek zelal dişopînin:
- Testa nimûne.
- A / B testkirina an Canaries.
- Pêşveçûnek pêşveçûyî.
Bi nimûneyan re, nêzîkatî hate ravekirin - guheztin yekem bi karanîna reçeteyek xwerû têne ceribandin.
Ji bo ceribandina canary, pêdivî ye ku em cotên pêşkêşkerên berawirdî bistînin ku li ser wan em dikarin çawa pergalê berî û piştî guheztinan bixebitin. Ji bo kirina vê yekê, ji gelek malperên me yên CDN, em cot pêşkêşkerên ku seyrûsefera hevber distînin hilbijêrin:
Dûv re em bi guheztinên li ser servera Canary re avahî saz dikin. Ji bo nirxandina encaman, em pergalek ku bi qasî 100-150 metrîkan bi nimûneyek serverên Kontrolê re berhev dike dimeşîne:
Ger ceribandina Kanaryayê serketî be, wê hingê em wê hêdî hêdî, di pêlan de berdidin. Em serverên li ser her malperê di heman demê de nûve nakin - windakirina tevahî malperek ji ber pirsgirêkan bandorek girîngtir li ser karûbarê bikarhêneran heye ji windakirina heman hejmarê pêşkêşkeran li cîhên cihê.
Bi gelemperî, bandor û ewlehiya vê nêzîkbûnê bi hejmar û kalîteya pîvanên berhevkirî ve girêdayî ye. Ji bo pergala bilezkirina lêpirsîna me, em metrîkan ji hemî hêmanên gengaz berhev dikin:
- ji xerîdaran - hejmara danişîn û daxwazan, rêjeyên paşveçûnê;
- proxy - statîstîkên li ser hejmar û dema daxwazan;
- DNS - hejmar û encamên daxwazan;
- qiraxa ewr - hejmar û dema ji bo pêkanîna daxwazên di ewr de.
Hemî ev di yek boriyek yekane de têne berhev kirin, û, li gorî hewcedariyan, em biryar didin ka kîjan metrikan bişînin analîtîkên rast-ê, û kîjan ji Elasticsearch an Daneyên Mezin re ji bo tespîtên hûrgulî.
Em çavdêriyê dikin
Di doza me de, em li ser riya krîtîk a daxwazên di navbera xerîdar û serverê de guhertinan dikin. Di heman demê de, hejmara hêmanên cihêreng ên li ser xerîdar, li ser server, û di riya Înternetê de pir e. Guhertinên li ser xerîdar û serverê bi domdarî diqewimin - di dema xebata bi dehan tîm û guhertinên xwezayî yên di ekosîstema de. Em di navîn de ne - dema ku pirsgirêkan teşhîs dikin, şansek baş heye ku em tevlê bibin. Ji ber vê yekê, pêdivî ye ku em bi zelalî fêm bikin ka meriv çawa metrîkan diyar dike, berhev dike û analîz dike da ku zû pirsgirêkan veqetîne.
Bi îdeal, gihîştina bêkêmasî ya her cûre metrîk û fîlteran di demek rast de. Lê gelek metrîk hene, ji ber vê yekê pirsa lêçûnê derdikeve holê. Di doza me de, em metrîk û amûrên pêşkeftinê wekî jêrîn ji hev vediqetînin:
Ji bo tespîtkirin û ceribandina pirsgirêkan em pergala xweya rast-çavkaniya vekirî bikar tînin и - ji bo dîtinê. Ew metrîkên berhevkirî di bîranînê de hilîne, pêbawer e û bi pergala hişyarkirinê re yek dike. Ji bo herêmîkirin û tespîtkirinê, me gihîştina têketinên ji Elasticsearch û Kibana heye. Ji bo analîz û modelkirina îstatîstîkî, em di Tableau de daneyên mezin û dîtbarî bikar tînin.
Wusa dixuye ku ev nêzîkatî pir dijwar e ku meriv pê re bixebite. Lêbelê, bi organîzekirina metrîk û amûran bi hiyerarşîk, em dikarin zû pirsgirêkek analîz bikin, celebê pirsgirêkê diyar bikin, û dûv re li metrîkên hûrgulî hûr bibin. Bi gelemperî, em bi qasî 1-2 hûrdeman derbas dikin da ku çavkaniya hilweşînê nas bikin. Piştî vê yekê, em bi tîmek taybetî re li ser tespîtkirinê dixebitin - ji deh hûrdeman heya çend demjimêran.
Ger teşhîs zû were kirin jî, em naxwazin ev pir caran çêbibe. Bi îdeal, em ê tenê hişyariyek krîtîk bistînin dema ku bandorek girîng li ser karûbarê hebe. Ji bo pergala bilezkirina lêpirsîna me, tenê 2 hişyariyên me hene ku dê agahdar bikin:
- Ji sedî paşveçûna xerîdar - nirxandina tevgera xerîdar;
- sedî Çewtiyên sondajê - Daneyên aramiya pêkhateyên torê.
Van hişyariyên krîtîk çavdêrî dikin ka pergal ji bo piraniya bikarhêneran dixebite. Em lê dinêrin ka çend xerîdar paşveçûn bikar anîne heke nikaribin bilezkirina daxwazê bistînin. Em di nav hefteyekê de ji 1 hişyariya krîtîk kêmtir in, her çend di pergalê de tonek guhertin hene. Çima ev têra me dike?
- Ger proxeya me nexebite paşveçûnek xerîdar heye.
- Pergalek rêvekirina otomatîkî heye ku bersivê dide pirsgirêkan.
Agahiyên bêtir li ser ya paşîn. Pergala ceribandina me, û pergala ji bo destnîşankirina riya çêtirîn ji bo daxwazên ji xerîdar ber bi ewr ve, dihêle ku em bixweber bi hin pirsgirêkan re mijûl bibin.
Ka em vegerin ser veavakirina nimûneya xwe û 3 kategoriyên rê. Digel dema barkirinê, em dikarin li rastiya radestkirinê bixwe jî binêrin. Ger barkirina daneyan ne mumkun bû, wê hingê bi dîtina encaman li ser riyên cihêreng em dikarin diyar bikin ka li ku û çi şikestiye, û gelo em dikarin bixweber bi guheztina riya daxwazê ve wê rast bikin.
wergerandî:
Ev pêvajo dikare otomatîk be. Di pergala rêvekirinê de têxin nav xwe. Û wê hîn bikin ku bersivê bide pirsgirêkên performans û pêbaweriyê. Ger tiştek dest bi şikandinê bike, heke vebijarkek çêtir hebe bertek nîşan bidin. Di heman demê de, reaksiyonek tavilê ne krîtîk e, bi saya paşveçûna li ser xerîdaran.
Ji ber vê yekê, prensîbên piştevaniya pergalê dikare wekî jêrîn were formulekirin:
- kêmkirina pîvana hilweşînan;
- berhevkirina metrîkan;
- Ger em bikarin em bixweber têkçûnên tamîr dikin;
- heke nekare, em we agahdar dikin;
- Ji bo bersivdana bilez em li ser dashboard û amûrek triage dixebitin.
Dersên hînbûyî
Ji bo nivîsandina prototîpek pir dem nagire. Li cem me piştî 4 mehan amade bû. Bi wê re me metrîkên nû wergirtin, û 10 meh piştî destpêkirina pêşkeftinê me yekem seyrûsefera hilberînê wergirt. Dûv re xebata bêhnteng û pir dijwar dest pê kir: hêdî hêdî pergalê hilberandin û mezin kirin, seyrûsefera sereke koç kirin û ji xeletiyan fêr bibin. Lêbelê, ev pêvajoyek bandorker dê ne rêzik be - tevî hemî hewildanan, her tişt nayê pêşbînîkirin. Pir bi bandortir e ku meriv zû dubare bike û bersiv bide daneyên nû.
Li ser bingeha ezmûna me, em dikarin jêrîn pêşniyar bikin:
- Ji intuitiona xwe bawer nekin.
Digel ezmûna mezin a endamên tîmê me, têgihîştina me bi berdewamî têk çû. Mînakî, me bi xeletî leza hêvîkirî ya ji karanîna proxy CDN, an tevgera TCP Anycast pêşbînî kir.
- Daneyên ji hilberînê bistînin.
Girîng e ku bi lez û bez xwe bigihînin bi kêmî ve hejmarek piçûk daneyên hilberînê. Hema hema ne gengaz e ku meriv di şert û mercên laboratîfê de hejmara dozên bêhempa, veavakirin û mîhengan bi dest bixe. Gihîştina bilez a encaman dê bihêle ku hûn zû li ser pirsgirêkên potansiyel fêr bibin û wan di mîmariya pergalê de hesab bikin.
- Li pey şîret û encamên kesên din nebin - daneyên xwe berhev bikin.
Prensîbên berhevkirin û analîzkirina daneyan bişopînin, lê encam û gotinên kesên din bi korayî qebûl nekin. Tenê hûn dikarin bi rastî bizanin ka çi ji bo bikarhênerên we dixebite. Dibe ku pergalên we û xerîdarên we ji pargîdaniyên din pir cûda bin. Xwezî, amûrên analîzê nuha berdest in û karanîna wan hêsan in. Encamên ku hûn digirin dibe ku ne ya ku Netflix, Facebook, Akamai û pargîdaniyên din îdîa dikin bin. Di doza me de, performansa TLS, HTTP2 an statîstîkên li ser daxwazên DNS-ê ji encamên Facebook, Uber, Akamai cûda dibe - ji ber ku cîhazên me, xerîdar û herikîna daneya cûda hene.
- Meylên modê yên nehewce neşopînin û bandorê binirxînin.
Hêsan dest pê bikin. Çêtir e ku meriv di demek kin de pergalek xebitandinê ya hêsan çêbike ji ber ku meriv demek pir mezin ji bo pêşxistina pêkhateyên ku hûn ne hewce ne derbas bikin. Li gorî pîvandin û encamên we kar û pirsgirêkên ku girîng in çareser bikin.
- Ji bo serîlêdanên nû amade bibin.
Çawa ku pêşbînkirina hemî pirsgirêkan dijwar e, pêşbînkirina feyde û sepanan jî dijwar e. Ji destpêkek vekêşanê bigirin - kapasîteya wan a ku bi şert û mercên xerîdar re adapte bibin. Di doza we de, hûn dikarin pirsgirêkên nû û çareseriyên wan bibînin. Di projeya xwe de, me armancek destnîşan kir ku derengiya daxwazê kêm bikin. Lêbelê, di dema analîz û nîqaşan de, me fêm kir ku em dikarin serverên proxy jî bikar bînin:
- hevsengkirina trafîkê li seranserê herêmên AWS û kêmkirina lêçûn;
- modela aramiya CDN;
- ji bo mîhengkirina DNS;
- ji bo mîhengkirina TLS/TCP.
encamê
Di raporê de, min diyar kir ku Netflix çawa pirsgirêka bilezkirina daxwazên Internetnternetê di navbera xerîdar û ewr de çareser dike. Em çawa bi karanîna pergalek nimûneyê li ser xerîdaran daneyan berhev dikin, û daneyên dîrokî yên berhevkirî bikar tînin da ku daxwazên hilberînê yên ji xerîdar bi riya herî bilez a li ser Înternetê rêve bibin. Em çawa prensîbên protokolên torê, binesaziya CDN-ya me, tora piştê, û serverên DNS-ê bikar tînin da ku bigihîjin vê peywirê.
Lêbelê, çareseriya me tenê mînakek e ku me çawa li Netflix pergalek weha bicîh kir. Çi ji bo me xebitî. Beşa sepandî ya rapora min ji bo we prensîbên pêşveçûn û piştgirîyê ne ku em dişopînin û encamên baş bi dest dixin.
Dibe ku çareseriya me ya ji bo pirsgirêkê ne li gorî we be. Lêbelê, teorî û prensîbên sêwiranê dimînin, tewra ku hûn binesaziya CDN-ya xwe nebin, an heke ew ji ya me pir cûda be.
Girîngiya leza daxwazên karsaziyê jî girîng dimîne. Tewra ji bo karûbarek hêsan jî hûn hewce ne ku bijartinek bikin: di navbera pêşkêşkerên ewr, cîhê server, pêşkêşkerên CDN û DNS de. Hilbijartina we dê bandorkeriya pirsên Înternetê ji bo xerîdarên we bandor bike. Û ji bo we girîng e ku hûn vê bandorê bipîvin û fêm bikin.
Bi çareseriyên hêsan dest pê bikin, bala xwe bidin ka hûn çawa hilberê biguherînin. Gava ku hûn diçin fêr bibin û pergalê li ser bingeha daneyên ji xerîdarên xwe, binesaziya we, û karsaziya we çêtir bikin. Di pêvajoya sêwiranê de li ser îhtîmala têkçûnên nediyar bifikirin. Dûv re hûn dikarin pêvajoya pêşkeftina xwe bilezînin, karbidestiya çareseriyê baştir bikin, ji bargiraniya piştevaniya nehewce dûr bixin û bi aramî razin.
Sal di forma serhêl de. Hûn dikarin pirsan ji yek ji bavê DevOps, John Willis bixwe, bipirsin!
Source: www.habr.com