Netflix yw'r arweinydd yn y farchnad deledu Rhyngrwyd - y cwmni a greodd ac sy'n datblygu'r segment hwn yn weithredol. Mae Netflix yn adnabyddus nid yn unig am ei gatalog helaeth o ffilmiau a chyfresi teledu sydd ar gael o bron bob cornel o'r blaned ac unrhyw ddyfais ag arddangosfa, ond hefyd am ei seilwaith dibynadwy a'i ddiwylliant peirianneg unigryw.
Cyflwynwyd enghraifft glir o ddull Netflix o ddatblygu a chefnogi systemau cymhleth yn DevOops 2019 - Cyfarwyddwr Datblygu Netflix. Graddedig o Gyfadran Mathemateg Gyfrifiadurol a Mathemateg Prifysgol Talaith Nizhny Novgorod. Lobachevsky, Sergey un o'r peirianwyr cyntaf yn Open Connect - tîm CDN yn Netflix. Adeiladodd systemau ar gyfer monitro a dadansoddi data fideo, lansiodd wasanaeth poblogaidd ar gyfer asesu cyflymder cysylltiad Rhyngrwyd FAST.com, ac am yr ychydig flynyddoedd diwethaf mae wedi bod yn gweithio ar optimeiddio ceisiadau Rhyngrwyd fel bod cymhwysiad Netflix yn gweithio cyn gynted â phosibl i ddefnyddwyr.
Derbyniodd yr adroddiad yr adolygiadau gorau gan gyfranogwyr y gynhadledd, ac rydym wedi paratoi fersiwn testun i chi.
Yn ei adroddiad, siaradodd Sergei yn fanwl
- am yr hyn sy'n effeithio ar yr oedi o ran ceisiadau Rhyngrwyd rhwng y cleient a'r gweinydd;
- sut i leihau'r oedi hwn;
- sut i ddylunio, cynnal a monitro systemau sy'n gallu goddef gwallau;
- sut i gyflawni canlyniadau mewn amser byr, a chyda'r risg lleiaf posibl i'r busnes;
- sut i ddadansoddi canlyniadau a dysgu o gamgymeriadau.
Mae angen atebion i'r cwestiynau hyn nid yn unig gan y rhai sy'n gweithio mewn corfforaethau mawr.
Dylai'r egwyddorion a'r technegau a gyflwynir fod yn hysbys ac yn cael eu hymarfer gan bawb sy'n datblygu ac yn cefnogi cynhyrchion Rhyngrwyd.
Nesaf yw'r naratif o safbwynt y siaradwr.
Pwysigrwydd cyflymder rhyngrwyd
Mae cyflymder ceisiadau Rhyngrwyd yn uniongyrchol gysylltiedig â busnes. Ystyriwch y diwydiant siopa: Amazon yn 2009 bod oedi o 100ms yn arwain at golli 1% o werthiannau.
Mae mwy a mwy o ddyfeisiau symudol, ac yna gwefannau a chymwysiadau symudol. Os yw'ch tudalen yn cymryd mwy na 3 eiliad i'w llwytho, rydych chi'n colli tua hanner eich defnyddwyr. GYDA Mae Google yn ystyried cyflymder llwytho eich tudalen mewn canlyniadau chwilio: y cyflymaf yw'r dudalen, yr uchaf yw ei safle yn Google.
Mae cyflymder cysylltu hefyd yn bwysig mewn sefydliadau ariannol lle mae hwyrni yn hollbwysig. Yn 2015, Hibernia Networks cebl $400 miliwn rhwng Efrog Newydd a Llundain i leihau 6ms yr hwyrni rhwng y dinasoedd. Dychmygwch $66 miliwn ar gyfer 1 ms o ostyngiad hwyrni!
Yn ôl , nid yw cyflymderau cysylltu dros 5 Mbit yr eiliad yn effeithio'n uniongyrchol ar gyflymder llwytho gwefan nodweddiadol mwyach. Fodd bynnag, mae perthynas linellol rhwng hwyrni cysylltiad a chyflymder llwytho tudalen:
Fodd bynnag, nid yw Netflix yn gynnyrch nodweddiadol. Mae effaith hwyrni a chyflymder ar y defnyddiwr yn faes gweithredol o ddadansoddi a datblygu. Mae llwytho cymhwysiad a dewis cynnwys sy'n dibynnu ar hwyrni, ond mae llwytho elfennau statig a ffrydio hefyd yn dibynnu ar gyflymder cysylltiad. Mae dadansoddi ac optimeiddio'r ffactorau allweddol sy'n dylanwadu ar brofiad y defnyddiwr yn faes datblygu gweithredol i sawl tîm yn Netflix. Un o'r nodau yw lleihau hwyrni ceisiadau rhwng dyfeisiau Netflix a seilwaith y cwmwl.
Yn yr adroddiad byddwn yn canolbwyntio'n benodol ar leihau hwyrni gan ddefnyddio'r enghraifft o seilwaith Netflix. Gadewch i ni ystyried o safbwynt ymarferol sut i fynd at y prosesau dylunio, datblygu a gweithredu systemau gwasgaredig cymhleth a threulio amser ar arloesi a chanlyniadau, yn hytrach na gwneud diagnosis o broblemau gweithredol a methiant.
Y tu mewn i Netflix
Mae miloedd o wahanol ddyfeisiau yn cefnogi apps Netflix. Maent yn cael eu datblygu gan bedwar tîm gwahanol, sy'n gwneud fersiynau ar wahân o'r cleient ar gyfer Android, iOS, teledu a phorwyr gwe. Ac rydym yn treulio llawer o ymdrech ar wella a phersonoli profiad y defnyddiwr. I wneud hyn, rydym yn cynnal cannoedd o brofion A/B ochr yn ochr.
Cefnogir personoli gan gannoedd o ficrowasanaethau yn y cwmwl AWS, sy'n darparu data defnyddwyr personol, anfon ymholiad, telemetreg, Data Mawr ac Amgodio. Mae delweddu traffig yn edrych fel hyn:
Ar y chwith mae'r pwynt mynediad, ac yna mae'r traffig yn cael ei ddosbarthu ymhlith cannoedd o ficrowasanaethau sy'n cael eu cefnogi gan wahanol dimau backend.
Elfen bwysig arall o'n seilwaith yw'r CDN Open Connect, sy'n darparu cynnwys statig i'r defnyddiwr terfynol - fideos, delweddau, cod cleient, ac ati. Mae'r CDN wedi'i leoli ar weinyddion personol (OCA - Open Connect Appliance). Y tu mewn mae yna araeau o yriannau SSD a HDD sy'n rhedeg FreeBSD wedi'i optimeiddio, gyda NGINX a set o wasanaethau. Rydym yn dylunio ac yn gwneud y gorau o gydrannau caledwedd a meddalwedd fel y gall gweinydd CDN o'r fath anfon cymaint o ddata â phosibl at ddefnyddwyr.
Mae “wal” y gweinyddion hyn yn y man cyfnewid traffig Rhyngrwyd (Internet eXchange - IX) yn edrych fel hyn:
Mae Cyfnewid Rhyngrwyd yn darparu'r gallu i ddarparwyr gwasanaethau Rhyngrwyd a darparwyr cynnwys “gysylltu” â'i gilydd i gyfnewid data yn fwy uniongyrchol ar y Rhyngrwyd. Mae tua 70-80 o bwyntiau Cyfnewid Rhyngrwyd ledled y byd lle mae ein gweinyddion wedi'u gosod, ac rydym yn eu gosod a'u cynnal yn annibynnol:
Yn ogystal, rydym hefyd yn darparu gweinyddwyr yn uniongyrchol i ddarparwyr Rhyngrwyd, y maent yn eu gosod yn eu rhwydwaith, gan wella lleoleiddio traffig Netflix ac ansawdd ffrydio i ddefnyddwyr:
Mae set o wasanaethau AWS yn gyfrifol am anfon ceisiadau fideo gan gleientiaid i weinyddion CDN, yn ogystal â ffurfweddu'r gweinyddwyr eu hunain - diweddaru cynnwys, cod rhaglen, gosodiadau, ac ati. Ar gyfer yr olaf, fe wnaethom hefyd adeiladu rhwydwaith asgwrn cefn sy'n cysylltu gweinyddwyr mewn pwyntiau Cyfnewid Rhyngrwyd ag AWS. Mae'r rhwydwaith asgwrn cefn yn rhwydwaith byd-eang o geblau a llwybryddion ffibr optig y gallwn eu dylunio a'u ffurfweddu yn seiliedig ar ein hanghenion.
Ar , mae ein seilwaith CDN yn darparu tua ⅛ o draffig Rhyngrwyd y byd yn ystod oriau brig a ⅓ o'r traffig yng Ngogledd America, lle mae Netflix wedi bod o gwmpas hiraf. Niferoedd trawiadol, ond i mi un o'r cyflawniadau mwyaf anhygoel yw bod y system CDN gyfan yn cael ei datblygu a'i chynnal gan dîm o lai na 150 o bobl.
I ddechrau, cynlluniwyd y seilwaith CDN i ddarparu data fideo. Fodd bynnag, dros amser sylweddolom y gallwn hefyd ei ddefnyddio i wneud y gorau o geisiadau deinamig gan gleientiaid yn y cwmwl AWS.
Ynglŷn â chyflymiad Rhyngrwyd
Heddiw, mae gan Netflix 3 rhanbarth AWS, a bydd hwyrni ceisiadau i'r cwmwl yn dibynnu ar ba mor bell yw'r cwsmer o'r rhanbarth agosaf. Ar yr un pryd, mae gennym lawer o weinyddion CDN a ddefnyddir i gyflwyno cynnwys statig. A oes unrhyw ffordd i ddefnyddio'r fframwaith hwn i gyflymu ymholiadau deinamig? Fodd bynnag, yn anffodus, mae'n amhosibl celu'r ceisiadau hyn - mae APIs wedi'u personoli ac mae pob canlyniad yn unigryw.
Gadewch i ni wneud dirprwy ar y gweinydd CDN a dechrau anfon traffig drwyddo. A fydd yn gyflymach?
Materiel
Gadewch i ni gofio sut mae protocolau rhwydwaith yn gweithio. Heddiw, mae'r rhan fwyaf o draffig ar y Rhyngrwyd yn defnyddio HTTPs, sy'n dibynnu ar y protocolau haen isaf TCP a TLS. Er mwyn i gleient gysylltu â'r gweinydd, mae'n ysgwyd llaw, ac i sefydlu cysylltiad diogel, mae angen i'r cleient gyfnewid negeseuon gyda'r gweinydd dair gwaith ac o leiaf unwaith eto i drosglwyddo data. Gyda hwyrni fesul taith gron (RTT) o 100 ms, byddai'n cymryd 400 ms i ni dderbyn y darn cyntaf o ddata:
Os byddwn yn gosod y tystysgrifau ar y gweinydd CDN, yna gellir lleihau'r amser ysgwyd llaw rhwng y cleient a'r gweinydd yn sylweddol os yw'r CDN yn agosach. Gadewch i ni dybio mai 30ms yw'r hwyrni i'r gweinydd CDN. Yna bydd yn cymryd 220 ms i dderbyn y did cyntaf:
Ond nid yw'r manteision yn dod i ben yno. Unwaith y bydd cysylltiad wedi'i sefydlu, mae TCP yn cynyddu'r ffenestr tagfeydd (swm y wybodaeth y gall ei throsglwyddo dros y cysylltiad hwnnw ochr yn ochr). Os collir pecyn data, yna mae gweithrediadau clasurol y protocol TCP (fel TCP New Reno) yn lleihau'r “ffenestr” agored i hanner. Mae twf y ffenestr tagfeydd, a chyflymder ei adferiad o golled eto yn dibynnu ar yr oedi (RTT) i'r gweinydd. Os yw'r cysylltiad hwn ond yn mynd mor bell â'r gweinydd CDN, bydd yr adferiad hwn yn gyflymach. Ar yr un pryd, mae colli pecynnau yn ffenomen safonol, yn enwedig ar gyfer rhwydweithiau diwifr.
Gall lled band rhyngrwyd gael ei leihau, yn enwedig yn ystod oriau brig, oherwydd traffig gan ddefnyddwyr, a all arwain at dagfeydd traffig. Fodd bynnag, nid oes unrhyw ffordd ar y Rhyngrwyd i roi blaenoriaeth i rai ceisiadau dros eraill. Er enghraifft, rhowch flaenoriaeth i geisiadau bach sy’n sensitif i hwyrni dros ffrydiau data “trwm” sy’n llwytho’r rhwydwaith. Fodd bynnag, yn ein hachos ni, mae cael ein rhwydwaith asgwrn cefn ein hunain yn caniatáu inni wneud hyn ar ran o'r llwybr cais - rhwng y CDN a'r cwmwl, a gallwn ei ffurfweddu'n llawn. Gallwch wneud yn siŵr bod pecynnau bach sy'n sensitif i hwyrni yn cael eu blaenoriaethu, a bod llif data mawr yn mynd ychydig yn ddiweddarach. Po agosaf yw'r CDN at y cleient, y mwyaf yw'r effeithlonrwydd.
Mae protocolau lefel cais (Lefel 7 OSI) hefyd yn cael effaith ar hwyrni. Mae protocolau newydd fel HTTP/2 yn gwneud y gorau o berfformiad ceisiadau cyfochrog. Fodd bynnag, mae gennym gleientiaid Netflix gyda dyfeisiau hŷn nad ydynt yn cefnogi'r protocolau newydd. Ni ellir diweddaru neu ffurfweddu pob cleient yn y ffordd orau bosibl. Ar yr un pryd, rhwng y dirprwy CDN a'r cwmwl mae rheolaeth lwyr a'r gallu i ddefnyddio protocolau a gosodiadau newydd, gorau posibl. Bydd y rhan aneffeithiol gyda hen brotocolau yn gweithredu rhwng y cleient a'r gweinydd CDN yn unig. Ar ben hynny, gallwn wneud ceisiadau amlblecs ar gysylltiad sydd eisoes wedi'i sefydlu rhwng y CDN a'r cwmwl, gan wella'r defnydd o gysylltiad ar lefel TCP:
Rydym yn mesur
Er gwaethaf y ffaith bod y ddamcaniaeth yn addo gwelliannau, nid ydym yn rhuthro ar unwaith i lansio'r system mewn cynhyrchu. Yn hytrach, rhaid i ni yn gyntaf brofi y bydd y syniad yn gweithio yn ymarferol. I wneud hyn mae angen ichi ateb sawl cwestiwn:
- Cyflymder: a fydd dirprwy yn gyflymach?
- Dibynadwyedd: A fydd yn torri'n amlach?
- Cymhlethdod: sut i integreiddio â cheisiadau?
- Cost: Faint mae'n ei gostio i ddefnyddio seilwaith ychwanegol?
Gadewch inni ystyried yn fanwl ein dull o asesu’r pwynt cyntaf. Ymdrinnir â'r gweddill yn yr un modd.
Er mwyn dadansoddi cyflymder ceisiadau, rydym am gael data ar gyfer pob defnyddiwr, heb dreulio llawer o amser ar ddatblygu a heb dorri'r cynhyrchiad. Mae yna nifer o ddulliau ar gyfer hyn:
- RUM, neu fesur cais goddefol. Rydym yn mesur amser gweithredu ceisiadau cyfredol gan ddefnyddwyr ac yn sicrhau sylw llawn gan ddefnyddwyr. Yr anfantais yw nad yw'r signal yn sefydlog iawn oherwydd llawer o ffactorau, er enghraifft, oherwydd gwahanol feintiau cais, amser prosesu ar y gweinydd a'r cleient. Yn ogystal, ni allwch brofi cyfluniad newydd heb effaith wrth gynhyrchu.
- Profion labordy. Gweinyddwyr arbennig a seilwaith sy'n efelychu cleientiaid. Gyda'u cymorth nhw rydyn ni'n cynnal y profion angenrheidiol. Fel hyn rydym yn cael rheolaeth lawn dros y canlyniadau mesur a signal clir. Ond nid oes sylw cyflawn i ddyfeisiau a lleoliadau defnyddwyr (yn enwedig gyda gwasanaeth byd-eang a chefnogaeth i filoedd o fodelau dyfais).
Sut allwch chi gyfuno manteision y ddau ddull?
Mae ein tîm wedi dod o hyd i ateb. Fe wnaethon ni ysgrifennu darn bach o god - sampl - a adeiladwyd yn ein cais. Mae stilwyr yn ein galluogi i wneud profion rhwydwaith a reolir yn llawn o'n dyfeisiau. Mae'n gweithio fel hyn:
- Yn fuan ar ôl llwytho'r cais a chwblhau'r gweithgaredd cychwynnol, rydym yn rhedeg ein chwilwyr.
- Mae'r cleient yn gwneud cais i'r gweinydd ac yn derbyn “rysáit” ar gyfer y prawf. Mae'r rysáit yn rhestr o URLau y mae angen gwneud cais HTTP(s) iddynt. Yn ogystal, mae'r rysáit yn ffurfweddu paramedrau ceisiadau: oedi rhwng ceisiadau, faint o ddata y gofynnwyd amdano, penawdau HTTP(s), ac ati. Ar yr un pryd, gallwn brofi sawl rysáit gwahanol ochr yn ochr - wrth ofyn am ffurfweddiad, rydym yn penderfynu ar hap pa rysáit i'w gyhoeddi.
- Mae amser lansio'r chwiliwr yn cael ei ddewis er mwyn peidio â gwrthdaro â'r defnydd gweithredol o adnoddau rhwydwaith ar y cleient. Yn y bôn, dewisir yr amser pan nad yw'r cleient yn weithredol.
- Ar ôl derbyn y rysáit, mae'r cleient yn gwneud ceisiadau i bob un o'r URLs, ochr yn ochr. Gall y cais i bob un o'r cyfeiriadau yn cael ei ailadrodd - yr hyn a elwir. "corbys". Ar y pwls cyntaf, rydym yn mesur faint o amser a gymerodd i sefydlu cysylltiad a lawrlwytho data. Ar yr ail guriad, rydym yn mesur yr amser y mae'n ei gymryd i lwytho data dros gysylltiad sydd eisoes wedi'i sefydlu. Cyn y trydydd un, gallwn osod oedi a mesur cyflymder sefydlu ailgysylltu, ac ati.
Yn ystod y prawf, rydym yn mesur yr holl baramedrau y gall y ddyfais eu cael:
- Amser cais DNS;
- amser sefydlu cysylltiad TCP;
- amser sefydlu cysylltiad TLS;
- amser derbyn y beit cyntaf o ddata;
- cyfanswm amser llwytho;
- cod canlyniad statws.
- Ar ôl i'r holl gorbys ddod i ben, mae'r sampl yn llwytho'r holl fesuriadau i'w dadansoddi.
Y pwyntiau allweddol yw'r ddibyniaeth fach iawn ar resymeg ar y cleient, prosesu data ar y gweinydd a mesur ceisiadau cyfochrog. Felly, rydym yn gallu ynysu a phrofi dylanwad ffactorau amrywiol sy'n effeithio ar berfformiad ymholiad, eu hamrywio o fewn un rysáit, a chael canlyniadau gan gleientiaid go iawn.
Mae'r seilwaith hwn wedi bod yn ddefnyddiol ar gyfer mwy na dadansoddi perfformiad ymholi yn unig. Ar hyn o bryd mae gennym 14 o ryseitiau gweithredol, mwy na 6000 o samplau yr eiliad, gan dderbyn data o bob cornel o'r ddaear a sylw dyfais lawn. Pe bai Netflix yn prynu gwasanaeth tebyg gan drydydd parti, byddai'n costio miliynau o ddoleri y flwyddyn, gyda sylw llawer gwaeth.
Profi theori ar waith: prototeip
Gyda system o'r fath, roeddem yn gallu gwerthuso effeithiolrwydd dirprwyon CDN ar gais hwyr. Nawr mae angen:
- creu prototeip dirprwy;
- gosod y prototeip ar CDN;
- penderfynu sut i gyfeirio cleientiaid at ddirprwy ar weinydd CDN penodol;
- Cymharwch berfformiad â cheisiadau yn AWS heb ddirprwy.
Y dasg yw gwerthuso effeithiolrwydd y datrysiad arfaethedig cyn gynted â phosibl. Fe wnaethom ddewis Go i weithredu'r prototeip oherwydd bod llyfrgelloedd rhwydweithio da ar gael. Ar bob gweinydd CDN, fe wnaethom osod y procsi procsi fel deuaidd statig i leihau dibyniaethau a symleiddio integreiddio. Yn y gweithredu cychwynnol, gwnaethom ddefnyddio cydrannau safonol cymaint â phosibl a mân addasiadau ar gyfer cronni cysylltiadau HTTP/2 a gwneud cais am amlblecsio.
I gydbwyso rhwng rhanbarthau AWS, gwnaethom ddefnyddio cronfa ddata DNS daearyddol, yr un un a ddefnyddiwyd i gydbwyso cleientiaid. I ddewis gweinydd CDN ar gyfer y cleient, rydym yn defnyddio TCP Anycast ar gyfer gweinyddwyr yn Internet Exchange (IX). Yn yr opsiwn hwn, rydym yn defnyddio un cyfeiriad IP ar gyfer pob gweinydd CDN, a bydd y cleient yn cael ei gyfeirio at y gweinydd CDN gyda'r nifer lleiaf o hopys IP. Mewn gweinyddwyr CDN a osodwyd gan ddarparwyr Rhyngrwyd (ISPs), nid oes gennym reolaeth dros y llwybrydd i ffurfweddu TCP Anycast, felly rydym yn defnyddio , sy'n cyfeirio cwsmeriaid at ddarparwyr Rhyngrwyd ar gyfer ffrydio fideo.
Felly, mae gennym dri math o lwybr cais: i'r cwmwl trwy'r Rhyngrwyd agored, trwy weinydd CDN yn IX, neu drwy weinydd CDN sydd wedi'i leoli mewn darparwr Rhyngrwyd. Ein nod yw deall pa ffordd sy'n well, a beth yw budd dirprwy, o'i gymharu â sut mae ceisiadau'n cael eu hanfon i'r cynhyrchiad. I wneud hyn, rydym yn defnyddio system samplu fel a ganlyn:
Mae pob un o'r llwybrau yn dod yn darged ar wahân, ac edrychwn ar yr amser a gawsom. I'w dadansoddi, rydym yn cyfuno'r canlyniadau dirprwy yn un grŵp (dewiswch yr amser gorau rhwng dirprwyon IX ac ISP), a'u cymharu ag amser ceisiadau i'r cwmwl heb ddirprwy:
Fel y gwelwch, roedd y canlyniadau'n gymysg - yn y rhan fwyaf o achosion mae'r dirprwy yn rhoi cyflymiad da, ond mae yna hefyd nifer ddigonol o gleientiaid y bydd y sefyllfa'n gwaethygu'n sylweddol ar eu cyfer.
O ganlyniad, fe wnaethom nifer o bethau pwysig:
- Fe wnaethom asesu perfformiad disgwyliedig ceisiadau gan gleientiaid i'r cwmwl trwy ddirprwy CDN.
- Cawsom ddata gan gleientiaid go iawn, o bob math o ddyfeisiau.
- Sylweddolom nad oedd y ddamcaniaeth wedi'i chadarnhau 100% ac na fyddai'r cynnig cychwynnol gyda dirprwy CDN yn gweithio i ni.
- Ni wnaethom gymryd risgiau - ni wnaethom newid ffurfweddiadau cynhyrchu ar gyfer cleientiaid.
- Ni thorrwyd dim.
Prototeip 2.0
Felly, yn ôl at y bwrdd lluniadu ac ailadroddwch y broses eto.
Y syniad yw, yn lle defnyddio dirprwy 100%, y byddwn yn pennu'r llwybr cyflymaf ar gyfer pob cleient, a byddwn yn anfon ceisiadau yno - hynny yw, byddwn yn gwneud yr hyn a elwir yn llywio cleient.
Sut i weithredu hyn? Ni allwn ddefnyddio rhesymeg ar ochr y gweinydd, oherwydd ... Y nod yw cysylltu â'r gweinydd hwn. Mae angen rhyw ffordd i wneud hyn ar y cleient. Ac yn ddelfrydol, gwnewch hyn gydag isafswm o resymeg gymhleth, er mwyn peidio â datrys y mater o integreiddio â nifer fawr o lwyfannau cleientiaid.
Yr ateb yw defnyddio DNS. Yn ein hachos ni, mae gennym ein seilwaith DNS ein hunain, a gallwn sefydlu parth parth y bydd ein gweinyddwyr yn awdurdodol ar ei gyfer. Mae'n gweithio fel hyn:
- Mae'r cleient yn gwneud cais i'r gweinydd DNS gan ddefnyddio gwesteiwr, er enghraifft api.netflix.xom.
- Mae'r cais yn cyrraedd ein gweinydd DNS
- Mae'r gweinydd DNS yn gwybod pa lwybr yw'r cyflymaf i'r cleient hwn ac yn cyhoeddi'r cyfeiriad IP cyfatebol.
Mae gan yr ateb gymhlethdod ychwanegol: nid yw darparwyr DNS awdurdodaidd yn gweld cyfeiriad IP y cleient a gallant ddarllen cyfeiriad IP y datrysiad ailadroddus y mae'r cleient yn ei ddefnyddio yn unig.
O ganlyniad, mae'n rhaid i'n datryswr awdurdodaidd wneud penderfyniad nid ar gyfer cleient unigol, ond ar gyfer grŵp o gleientiaid yn seiliedig ar y datryswr ailadroddus.
I'w datrys, rydym yn defnyddio'r un samplau, yn agregu'r canlyniadau mesur gan gleientiaid ar gyfer pob un o'r datrysiadau ailadroddus ac yn penderfynu ble i anfon y grŵp hwn ohonynt - dirprwy trwy IX gan ddefnyddio TCP Anycast, trwy ddirprwy ISP, neu'n uniongyrchol i'r cwmwl.
Rydym yn cael y system ganlynol:
Mae'r model llywio DNS sy'n deillio o hyn yn eich galluogi i gyfeirio cleientiaid yn seiliedig ar arsylwadau hanesyddol o gyflymder cysylltiadau o gleientiaid i'r cwmwl.
Unwaith eto, y cwestiwn yw pa mor effeithiol y bydd y dull hwn yn gweithio? I ateb, rydym eto'n defnyddio ein system archwilio. Felly, rydym yn ffurfweddu cyfluniad y cyflwynydd, lle mae un o'r targedau yn dilyn y cyfeiriad o lywio DNS, mae'r llall yn mynd yn uniongyrchol i'r cwmwl (cynhyrchu cyfredol).
O ganlyniad, rydym yn cymharu'r canlyniadau ac yn cael asesiad o'r effeithiolrwydd:
O ganlyniad, rydym wedi dysgu nifer o bethau pwysig:
- Fe wnaethom asesu perfformiad disgwyliedig ceisiadau gan gleientiaid i'r cwmwl gan ddefnyddio DNS Steering.
- Cawsom ddata gan gleientiaid go iawn, o bob math o ddyfeisiau.
- Mae effeithiolrwydd y syniad arfaethedig wedi'i brofi.
- Ni wnaethom gymryd risgiau - ni wnaethom newid ffurfweddiadau cynhyrchu ar gyfer cleientiaid.
- Ni thorrwyd dim.
Nawr am y rhan anodd - rydym yn ei lansio wrth gynhyrchu
Mae'r rhan hawdd bellach drosodd - mae yna brototeip sy'n gweithio. Nawr y rhan galed yw lansio datrysiad ar gyfer holl draffig Netflix, gan ddefnyddio i 150 miliwn o ddefnyddwyr, miloedd o ddyfeisiau, cannoedd o ficrowasanaethau, a chynnyrch a seilwaith sy'n newid yn barhaus. Mae gweinyddwyr Netflix yn derbyn miliynau o geisiadau yr eiliad, ac mae'n hawdd torri'r gwasanaeth â gweithredu diofal. Ar yr un pryd, rydym am lwybro traffig yn ddeinamig trwy filoedd o weinyddion CDN ar y Rhyngrwyd, lle mae rhywbeth yn newid ac yn torri'n gyson ac ar yr eiliad fwyaf amhriodol.
A chyda hyn oll, mae gan y tîm 3 peiriannydd sy'n gyfrifol am ddatblygu, lleoli a chefnogi'r system yn llawn.
Felly, byddwn yn parhau i siarad am gwsg aflonydd ac iach.
Sut i barhau i ddatblygu a pheidio â threulio'ch holl amser ar gymorth? Mae ein hymagwedd yn seiliedig ar 3 egwyddor:
- Rydym yn lleihau graddfa bosibl y dadansoddiadau (radiws chwyth).
- Rydym yn paratoi ar gyfer syrpreisys - rydym yn disgwyl y bydd rhywbeth yn torri, er gwaethaf profion a phrofiad personol.
- Diraddio gosgeiddig - os nad yw rhywbeth yn gweithio'n iawn, dylid ei drwsio'n awtomatig, hyd yn oed os nad yn y ffordd fwyaf effeithlon.
Mae'n troi allan, yn ein hachos ni, gyda'r ymagwedd hon at y broblem, y gallwn ddod o hyd i ateb syml ac effeithiol a symleiddio cymorth system yn sylweddol. Sylweddolom y gallem ychwanegu darn bach o god at y cleient a monitro am wallau cais rhwydwaith a achosir gan broblemau cysylltiad. Yn achos gwallau rhwydwaith, rydym yn gwneud wrth gefn yn uniongyrchol i'r cwmwl. Nid yw'r datrysiad hwn yn gofyn am ymdrech sylweddol i dimau cleientiaid, ond mae'n lleihau'n fawr y risg o chwalu annisgwyl a syrpréis i ni.
Wrth gwrs, er gwaethaf yr wrth gefn, rydym serch hynny yn dilyn disgyblaeth glir yn ystod datblygiad:
- Prawf sampl.
- Profi A/B neu Dedwydd.
- Cyflwyno blaengar.
Gyda samplau, disgrifiwyd y dull gweithredu - caiff newidiadau eu profi yn gyntaf gan ddefnyddio rysáit wedi'i deilwra.
Ar gyfer profion caneri, mae angen i ni gael parau tebyg o weinyddion y gallwn gymharu sut mae'r system yn gweithio arnynt cyn ac ar ôl y newidiadau. I wneud hyn, o'n nifer o wefannau CDN, rydym yn dewis parau o weinyddion sy'n derbyn traffig tebyg:
Yna rydyn ni'n gosod yr adeilad gyda'r newidiadau ar y gweinydd Canary. I werthuso'r canlyniadau, rydym yn rhedeg system sy'n cymharu tua 100-150 metrig gyda sampl o weinyddion Rheoli:
Os bydd profion Canary yn llwyddiannus, yna rydyn ni'n ei ryddhau'n raddol, mewn tonnau. Nid ydym yn diweddaru gweinyddion ar bob safle ar yr un pryd - mae colli safle cyfan oherwydd problemau yn cael effaith fwy arwyddocaol ar y gwasanaeth i ddefnyddwyr na cholli'r un nifer o weinyddion mewn gwahanol leoliadau.
Yn gyffredinol, mae effeithiolrwydd a diogelwch y dull hwn yn dibynnu ar faint ac ansawdd y metrigau a gasglwyd. Ar gyfer ein system cyflymu ymholiadau, rydym yn casglu metrigau o'r holl gydrannau posibl:
- gan gleientiaid - nifer y sesiynau a cheisiadau, cyfraddau wrth gefn;
- dirprwy - ystadegau ar nifer ac amser ceisiadau;
- DNS - nifer a chanlyniadau ceisiadau;
- ymyl cwmwl - nifer ac amser ar gyfer prosesu ceisiadau yn y cwmwl.
Cesglir hyn i gyd mewn un biblinell, ac, yn dibynnu ar yr anghenion, rydym yn penderfynu pa fetrigau i'w hanfon at ddadansoddeg amser real, a pha rai i Elasticsearch neu Big Data i gael diagnosteg fanylach.
Rydym yn monitro
Yn ein hachos ni, rydym yn gwneud newidiadau ar y llwybr critigol o geisiadau rhwng y cleient a'r gweinydd. Ar yr un pryd, mae nifer y gwahanol gydrannau ar y cleient, ar y gweinydd, ac ar y ffordd trwy'r Rhyngrwyd yn enfawr. Mae newidiadau ar y cleient a'r gweinydd yn digwydd yn gyson - yn ystod gwaith dwsinau o dimau a newidiadau naturiol yn yr ecosystem. Rydyn ni yn y canol - wrth wneud diagnosis o broblemau, mae siawns dda y byddwn ni'n cymryd rhan. Felly, mae angen inni ddeall yn glir sut i ddiffinio, casglu a dadansoddi metrigau i ynysu problemau yn gyflym.
Yn ddelfrydol, mynediad llawn i bob math o fetrigau a hidlwyr mewn amser real. Ond mae yna lawer o fetrigau, felly mae'r cwestiwn o gost yn codi. Yn ein hachos ni, rydym yn gwahanu metrigau ac offer datblygu fel a ganlyn:
I ganfod a brysbennu problemau rydym yn defnyddio ein system amser real ffynhonnell agored ein hunain и - ar gyfer delweddu. Mae'n storio metrigau agregedig yn y cof, yn ddibynadwy ac yn integreiddio â'r system rybuddio. Ar gyfer lleoleiddio a diagnosteg, mae gennym fynediad at logiau gan Elasticsearch a Kibana. Ar gyfer dadansoddi ystadegol a modelu, rydym yn defnyddio data mawr a delweddu yn Tableau.
Mae'n ymddangos ei bod yn anodd iawn gweithio gyda'r dull hwn. Fodd bynnag, trwy drefnu metrigau ac offer yn hierarchaidd, gallwn ddadansoddi problem yn gyflym, pennu'r math o broblem, ac yna drilio i lawr i fetrigau manwl. Yn gyffredinol, rydym yn treulio tua 1-2 funud i nodi ffynhonnell y dadansoddiad. Ar ôl hyn, rydym yn gweithio gyda thîm penodol ar ddiagnosteg - o ddegau o funudau i sawl awr.
Hyd yn oed os gwneir y diagnosis yn gyflym, nid ydym am i hyn ddigwydd yn aml. Yn ddelfrydol, dim ond pan fydd effaith sylweddol ar y gwasanaeth y byddwn yn derbyn rhybudd critigol. Ar gyfer ein system cyflymu ymholiadau, dim ond 2 rybudd sydd gennym a fydd yn hysbysu:
- Canran Cleient wrth Gefn - asesiad o ymddygiad cwsmeriaid;
- canran Gwallau probe - data sefydlogrwydd cydrannau rhwydwaith.
Mae'r rhybuddion hanfodol hyn yn monitro a yw'r system yn gweithio i'r mwyafrif o ddefnyddwyr. Edrychwn ar faint o gleientiaid a ddefnyddiodd wrth gefn os nad oeddent yn gallu cael cyflymiad cais. Rydym ar gyfartaledd yn llai nag 1 rhybudd critigol yr wythnos, er bod tunnell o newidiadau yn digwydd yn y system. Pam fod hyn yn ddigon i ni?
- Mae cleient wrth gefn os nad yw ein dirprwy yn gweithio.
- Mae yna system llywio awtomatig sy'n ymateb i broblemau.
Mwy o fanylion am yr olaf. Mae ein system dreialu, a'r system ar gyfer pennu'r llwybr gorau posibl ar gyfer ceisiadau gan y cleient i'r cwmwl yn awtomatig, yn caniatáu inni ymdopi'n awtomatig â rhai problemau.
Gadewch i ni ddychwelyd i'n cyfluniad sampl a 3 chategori llwybr. Yn ogystal ag amser llwytho, gallwn edrych ar y ffaith cyflawni ei hun. Os nad oedd yn bosibl llwytho'r data, yna trwy edrych ar y canlyniadau ar hyd gwahanol lwybrau gallwn benderfynu ble a beth dorrodd, ac a allwn ei drwsio'n awtomatig trwy newid y llwybr cais.
Enghreifftiau:
Gall y broses hon fod yn awtomataidd. Cynhwyswch ef yn y system lywio. A'i ddysgu i ymateb i broblemau perfformiad a dibynadwyedd. Os bydd rhywbeth yn dechrau torri, ymatebwch os oes opsiwn gwell. Ar yr un pryd, nid yw ymateb ar unwaith yn hanfodol, diolch i wrth gefn ar gleientiaid.
Felly, gellir llunio egwyddorion cymorth system fel a ganlyn:
- lleihau maint y dadansoddiadau;
- casglu metrigau;
- Rydym yn atgyweirio achosion o dorri i lawr yn awtomatig os gallwn;
- os na all, rydym yn eich hysbysu;
- Rydym yn gweithio ar ddangosfyrddau a set offer brysbennu ar gyfer ymateb cyflym.
Gwersi a Ddysgwyd
Nid yw'n cymryd llawer o amser i ysgrifennu prototeip. Yn ein hachos ni, roedd yn barod ar ôl 4 mis. Ag ef cawsom fetrigau newydd, a 10 mis ar ôl dechrau'r datblygiad cawsom y traffig cynhyrchu cyntaf. Yna dechreuodd y gwaith diflas ac anodd iawn: cynhyrchu a graddio'r system yn raddol, mudo'r prif draffig a dysgu o gamgymeriadau. Fodd bynnag, ni fydd y broses effeithiol hon yn llinol - er gwaethaf pob ymdrech, ni ellir rhagweld popeth. Mae'n llawer mwy effeithiol i ailadrodd ac ymateb yn gyflym i ddata newydd.
Yn seiliedig ar ein profiad, gallwn argymell y canlynol:
- Peidiwch ag ymddiried yn eich greddf.
Methodd ein greddf ni yn gyson, er gwaethaf profiad helaeth aelodau ein tîm. Er enghraifft, gwnaethom ragfynegi'n anghywir y cyflymder disgwyliedig o ddefnyddio dirprwy CDN, neu ymddygiad TCP Anycast.
- Cael data o gynhyrchu.
Mae'n bwysig cael mynediad at o leiaf ychydig bach o ddata cynhyrchu cyn gynted â phosibl. Mae bron yn amhosibl cael nifer yr achosion, cyfluniadau a gosodiadau unigryw mewn amodau labordy. Bydd mynediad cyflym i'r canlyniadau yn eich galluogi i ddysgu'n gyflym am broblemau posibl a'u cymryd i ystyriaeth ym mhensaernïaeth y system.
- Peidiwch â dilyn cyngor a chanlyniadau pobl eraill - casglwch eich data eich hun.
Dilynwch yr egwyddorion ar gyfer casglu a dadansoddi data, ond peidiwch â derbyn canlyniadau a datganiadau pobl eraill yn ddall. Dim ond chi all wybod yn union beth sy'n gweithio i'ch defnyddwyr. Gall eich systemau a'ch cwsmeriaid fod yn sylweddol wahanol i gwmnïau eraill. Yn ffodus, mae offer dadansoddi bellach ar gael ac yn hawdd eu defnyddio. Efallai nad y canlyniadau a gewch yw'r hyn y mae Netflix, Facebook, Akamai a chwmnïau eraill yn ei honni. Yn ein hachos ni, mae perfformiad TLS, HTTP2 neu ystadegau ar geisiadau DNS yn wahanol i ganlyniadau Facebook, Uber, Akamai - oherwydd bod gennym ni wahanol ddyfeisiau, cleientiaid a llif data.
- Peidiwch â dilyn tueddiadau ffasiwn yn ddiangen a gwerthuso effeithiolrwydd.
Dechreuwch yn syml. Mae'n well gwneud system waith syml mewn amser byr na threulio llawer iawn o amser yn datblygu cydrannau nad oes eu hangen arnoch chi. Datrys tasgau a phroblemau sy'n bwysig yn seiliedig ar eich mesuriadau a'ch canlyniadau.
- Paratowch ar gyfer ceisiadau newydd.
Yn union fel ei bod yn anodd rhagweld yr holl broblemau, mae'n anodd rhagweld y manteision a'r ceisiadau ymlaen llaw. Cymerwch awgrym gan fusnesau newydd - eu gallu i addasu i amodau cwsmeriaid. Yn eich achos chi, efallai y byddwch chi'n darganfod problemau newydd a'u hatebion. Yn ein prosiect, rydym yn gosod nod i leihau hwyrni ceisiadau. Fodd bynnag, yn ystod y dadansoddiad a'r trafodaethau, sylweddolom y gallwn hefyd ddefnyddio gweinyddion dirprwyol:
- cydbwyso traffig ar draws rhanbarthau AWS a lleihau costau;
- i fodelu sefydlogrwydd CDN;
- i ffurfweddu DNS;
- i ffurfweddu TLS/TCP.
Casgliad
Yn yr adroddiad, disgrifiais sut mae Netflix yn datrys y broblem o gyflymu ceisiadau Rhyngrwyd rhwng cleientiaid a'r cwmwl. Sut rydym yn casglu data gan ddefnyddio system samplu ar gleientiaid, ac yn defnyddio'r data hanesyddol a gasglwyd i gyfeirio ceisiadau cynhyrchu gan gleientiaid trwy'r llwybr cyflymaf ar y Rhyngrwyd. Sut rydym yn defnyddio egwyddorion protocolau rhwydwaith, ein seilwaith CDN, rhwydwaith asgwrn cefn, a gweinyddwyr DNS i gyflawni'r dasg hon.
Fodd bynnag, dim ond enghraifft yw ein datrysiad o sut y gwnaethom ni yn Netflix weithredu system o'r fath. Beth weithiodd i ni. Y rhan gymhwysol o'm hadroddiad i chi yw'r egwyddorion datblygu a chymorth yr ydym yn eu dilyn ac yn cyflawni canlyniadau da.
Efallai na fydd ein datrysiad i'r broblem yn addas i chi. Fodd bynnag, erys yr egwyddorion theori a dylunio, hyd yn oed os nad oes gennych eich seilwaith CDN eich hun, neu os yw'n wahanol iawn i'n un ni.
Mae pwysigrwydd cyflymder ceisiadau busnes hefyd yn parhau i fod yn bwysig. A hyd yn oed ar gyfer gwasanaeth syml mae angen i chi wneud dewis: rhwng darparwyr cwmwl, lleoliad gweinydd, darparwyr CDN a DNS. Bydd eich dewis yn dylanwadu ar effeithiolrwydd ymholiadau Rhyngrwyd ar gyfer eich cwsmeriaid. Ac mae'n bwysig i chi fesur a deall y dylanwad hwn.
Dechreuwch gydag atebion syml, gofalwch sut rydych chi'n newid y cynnyrch. Dysgwch wrth fynd a gwella'r system yn seiliedig ar ddata gan eich cwsmeriaid, eich seilwaith, a'ch busnes. Meddyliwch am y posibilrwydd o fethiant annisgwyl yn ystod y broses ddylunio. Ac yna gallwch chi gyflymu'ch proses ddatblygu, gwella effeithlonrwydd datrysiad, osgoi baich cymorth diangen a chysgu'n heddychlon.
Eleni mewn fformat ar-lein. Gallwch ofyn cwestiynau i un o dadau DevOps, John Willis ei hun!
Ffynhonnell: hab.com