Netflix er leiðandi á netsjónvarpsmarkaði - fyrirtækið sem skapaði og er að þróa þennan hluta. Netflix er ekki aðeins þekkt fyrir umfangsmikla vörulista yfir kvikmyndir og sjónvarpsþætti sem eru fáanlegar frá næstum hverju horni plánetunnar og hvaða tæki sem er með skjá, heldur einnig fyrir áreiðanlega innviði og einstaka verkfræðimenningu.
Skýrt dæmi um Netflix nálgun til að þróa og styðja flókin kerfi var kynnt á DevOops 2019 - Framkvæmdastjóri hjá Netflix. Útskrifaðist frá reiknifræði- og stærðfræðideild Nizhny Novgorod State University. Lobachevsky, Sergey einn af fyrstu verkfræðingunum í Open Connect - CDN teyminu hjá Netflix. Hann smíðaði kerfi til að fylgjast með og greina myndbandsgögn, opnaði vinsæla þjónustu til að meta nettengingarhraða FAST.com og hefur undanfarin ár unnið að hagræðingu á netbeiðnum þannig að Netflix forritið virki eins fljótt og auðið er fyrir notendur.
Skýrslan fékk bestu dóma ráðstefnuþátttakenda og við höfum útbúið textaútgáfu fyrir þig.
Í skýrslu sinni talaði Sergei ítarlega
- um hvað hefur áhrif á seinkun netbeiðna milli viðskiptavinar og netþjóns;
- hvernig á að draga úr þessari töf;
- hvernig á að hanna, viðhalda og fylgjast með villuþolnum kerfum;
- hvernig á að ná árangri á stuttum tíma og með lágmarks áhættu fyrir fyrirtækið;
- hvernig á að greina niðurstöður og læra af mistökum.
Svör við þessum spurningum þurfa ekki aðeins þeir sem starfa í stórum fyrirtækjum.
Framkomnar meginreglur og tækni ættu að vera þekkt og æft af öllum sem þróa og styðja netvörur.
Næst er frásögnin frá sjónarhóli ræðumanns.
Mikilvægi nethraða
Hraði netbeiðna er í beinum tengslum við viðskipti. Hugleiddu verslunariðnaðinn: Amazon árið 2009 að 100 ms seinkun leiðir til taps upp á 1% af sölu.
Það eru fleiri og fleiri farsímatæki, þar á eftir koma farsímasíður og forrit. Ef það tekur lengri tíma en 3 sekúndur að hlaða síðuna þína missir þú um helming notenda þinna. MEÐ Google tekur mið af hleðsluhraða síðunnar þinnar í leitarniðurstöðum: því hraðar sem síðan er, því hærra er staða hennar á Google.
Tengingarhraði er einnig mikilvægur í fjármálastofnunum þar sem leynd er mikilvæg. Árið 2015, Hibernia Networks 400 milljón dollara snúru milli New York og London til að draga úr biðtíma milli borganna um 6 ms. Ímyndaðu þér 66 milljónir dala fyrir 1 ms af leynd minnkun!
Samkvæmt , tengihraði yfir 5 Mbit/s hefur ekki lengur bein áhrif á hleðsluhraða dæmigerðrar vefsíðu. Hins vegar er línulegt samband á milli biðtíma tengingar og hleðsluhraða síðu:
Hins vegar er Netflix ekki dæmigerð vara. Áhrif leynd og hraða á notandann er virkt svið greiningar og þróunar. Það er hleðsla forrita og efnisval sem fer eftir leynd, en hleðsla kyrrstæðra þátta og streymi fer einnig eftir tengihraða. Að greina og fínstilla lykilþættina sem hafa áhrif á notendaupplifunina er virkt þróunarsvið fyrir nokkur teymi hjá Netflix. Eitt af markmiðunum er að draga úr biðtíma beiðna milli Netflix tækja og skýjainnviða.
Í skýrslunni munum við einbeita okkur sérstaklega að því að draga úr leynd með því að nota dæmið um Netflix innviðina. Við skulum skoða frá hagnýtu sjónarhorni hvernig eigi að nálgast ferla hönnunar, þróunar og rekstrar flókinna dreifðra kerfa og eyða tíma í nýsköpun og árangur, frekar en að greina rekstrarvandamál og bilanir.
Inni á Netflix
Þúsundir mismunandi tækja styðja Netflix forrit. Þau eru þróuð af fjórum mismunandi teymum, sem búa til aðskildar útgáfur af biðlaranum fyrir Android, iOS, sjónvarp og netvafra. Og við eyðum miklu átaki í að bæta og sérsníða notendaupplifunina. Til að gera þetta keyrum við hundruð A/B prófana samhliða.
Sérstilling er studd af hundruðum örþjónustu í AWS skýinu, sem veitir sérsniðin notendagögn, sendingu fyrirspurna, fjarmæling, stór gögn og kóðun. Umferðarsýn lítur svona út:
Vinstra megin er inngangsstaðurinn og síðan er umferðin dreift á nokkur hundruð örþjónustur sem eru studdar af mismunandi bakendateymum.
Annar mikilvægur þáttur innviða okkar er Open Connect CDN, sem skilar kyrrstöðu efni til endanotandans - myndbönd, myndir, kóða viðskiptavinar o.s.frv. CDN er staðsett á sérsniðnum netþjónum (OCA - Open Connect Appliance). Inni eru arrays af SSD og HDD drifum sem keyra bjartsýni FreeBSD, með NGINX og mengi þjónustu. Við hönnum og fínstillum vélbúnaðar- og hugbúnaðaríhluti þannig að slíkur CDN þjónn geti sent sem mest gögn til notenda.
„Múrinn“ þessara netþjóna á netumferðarskiptapunktinum (Internet eXchange - IX) lítur svona út:
Internet Exchange veitir netþjónustuveitum og efnisveitum möguleika á að „tengjast“ sín á milli til að skiptast á gögnum beint á internetinu. Það eru um það bil 70-80 Internet Exchange punktar um allan heim þar sem netþjónarnir okkar eru settir upp og við sjálfstætt setjum upp og viðhaldum þeim:
Að auki útvegum við netþjóna beint til netveitenda, sem þeir setja upp á neti sínu, sem bætir staðsetningu Netflix umferðar og gæði streymis fyrir notendur:
AWS þjónustur eru ábyrgir fyrir því að senda myndbandsbeiðnir frá viðskiptavinum til CDN netþjóna, auk þess að stilla netþjónana sjálfa - uppfæra efni, forritskóða, stillingar osfrv. Fyrir hið síðarnefnda byggðum við einnig grunnnet sem tengir netþjóna í Internet Exchange punktum við AWS. Grunnnetið er alþjóðlegt net ljósleiðara og beina sem við getum hannað og stillt út frá þörfum okkar.
Á , CDN innviðir okkar skila u.þ.b. ⅛ af netumferð heimsins á álagstímum og ⅓ af umferðinni í Norður-Ameríku, þar sem Netflix hefur verið lengst af. Glæsilegar tölur, en fyrir mér er eitt magnaðasta afrekið að allt CDN kerfið er þróað og viðhaldið af innan við 150 manns teymi.
Upphaflega var CDN innviðinn hannaður til að afhenda myndbandsgögn. Hins vegar komumst við að því með tímanum að við getum líka notað það til að hámarka kraftmikla beiðnir frá viðskiptavinum í AWS skýinu.
Um nethröðun
Í dag er Netflix með 3 AWS svæði og biðtími beiðna til skýsins fer eftir því hversu langt viðskiptavinurinn er frá næsta svæði. Á sama tíma höfum við marga CDN netþjóna sem eru notaðir til að skila kyrrstöðu efni. Er einhver leið til að nota þennan ramma til að flýta fyrir kraftmiklum fyrirspurnum? Hins vegar, því miður, er ómögulegt að vista þessar beiðnir - API eru sérsniðin og hver niðurstaða er einstök.
Við skulum búa til proxy á CDN netþjóninum og byrja að senda umferð í gegnum hann. Verður það hraðari?
Efni
Við skulum muna hvernig netsamskiptareglur virka. Í dag notar meirihluti umferðar á internetinu HTTPs, sem fer eftir samskiptareglum fyrir neðri lag TCP og TLS. Til þess að viðskiptavinur geti tengst þjóninum gerir hann handaband og til að koma á öruggri tengingu þarf viðskiptavinurinn að skiptast á skilaboðum við þjóninn þrisvar sinnum og að minnsta kosti einu sinni enn til að flytja gögn. Með leynd á fram og til baka (RTT) upp á 100 ms, myndi það taka okkur 400 ms að fá fyrsta bita af gögnum:
Ef við setjum skírteinin á CDN netþjóninn, þá getur handabandstími milli biðlara og netþjóns minnkað verulega ef CDN er nær. Gerum ráð fyrir að leynd til CDN netþjónsins sé 30ms. Þá mun það taka 220 ms að fá fyrsta bitann:
En kostirnir enda ekki þar. Þegar tenging hefur verið komið á, eykur TCP þrengslugluggann (magn upplýsinga sem það getur sent um þá tengingu samhliða). Ef gagnapakki tapast, þá minnka klassískar útfærslur á TCP samskiptareglunum (eins og TCP New Reno) opna „gluggann“ um helming. Vöxtur þrengslugluggans og hraði bata hans frá tapi fer aftur eftir seinkun (RTT) á netþjóninn. Ef þessi tenging nær aðeins eins langt og CDN netþjóninn verður þessi bati hraðari. Á sama tíma er pakkatap staðlað fyrirbæri, sérstaklega fyrir þráðlaus net.
Bandbreidd internetsins gæti minnkað, sérstaklega á álagstímum, vegna umferðar frá notendum, sem getur leitt til umferðartappa. Hins vegar er engin leið á netinu til að gefa sumum beiðnum forgang fram yfir aðrar. Til dæmis, gefðu litlum og töf-næmum beiðnum forgang fram yfir „þunga“ gagnastrauma sem hlaða netið. Hins vegar, í okkar tilviki, að hafa okkar eigið burðarnet gerir okkur kleift að gera þetta á hluta af beiðnileiðinni - milli CDN og skýsins, og við getum stillt það að fullu. Þú getur tryggt að litlir og leyndarviðkvæmir pakkar séu settir í forgang og stór gagnaflæði fer aðeins seinna. Því nær sem CDN er viðskiptavininum, því meiri skilvirkni.
Samskiptareglur um forritastig (OSI Level 7) hafa einnig áhrif á leynd. Nýjar samskiptareglur eins og HTTP/2 hámarka árangur samhliða beiðna. Hins vegar höfum við Netflix viðskiptavini með eldri tæki sem styðja ekki nýju samskiptareglurnar. Ekki er hægt að uppfæra alla viðskiptavini eða stilla sem best. Á sama tíma, á milli CDN umboðsins og skýsins, er fullkomin stjórn og getu til að nota nýjar, bestu samskiptareglur og stillingar. Óvirki hlutinn með gömlum samskiptareglum mun aðeins starfa á milli viðskiptavinarins og CDN netþjónsins. Þar að auki getum við lagt fram margfeldisbeiðnir um þegar komið er á tengingu milli CDN og skýsins, og bætt tengingarnýtingu á TCP stigi:
Við mælum
Þrátt fyrir þá staðreynd að kenningin lofi umbótum, flýtum við okkur ekki strax til að setja kerfið í framleiðslu. Þess í stað verðum við fyrst að sanna að hugmyndin gangi í framkvæmd. Til að gera þetta þarftu að svara nokkrum spurningum:
- Speed: verður umboð hraðari?
- Áreiðanleiki: Mun það brotna oftar?
- Erfiðleikar: hvernig á að samþætta við forrit?
- Kostnaður: Hvað kostar að setja upp viðbótarinnviði?
Við skulum skoða ítarlega nálgun okkar til að meta fyrsta atriðið. Afganginum er tekið á svipaðan hátt.
Til að greina hraða beiðna viljum við afla gagna fyrir alla notendur, án þess að eyða miklum tíma í þróun og án þess að rjúfa framleiðslu. Það eru nokkrar aðferðir við þetta:
- RUM, eða óvirk beiðnarmæling. Við mælum framkvæmdartíma núverandi beiðna frá notendum og tryggjum fulla umfang notenda. Ókosturinn er sá að merkið er ekki mjög stöðugt vegna margra þátta, til dæmis vegna mismunandi stærðar beiðni, vinnslutíma á netþjóni og biðlara. Að auki geturðu ekki prófað nýja uppsetningu án áhrifa í framleiðslu.
- Rannsóknarstofupróf. Sérstakir netþjónar og innviðir sem líkja eftir viðskiptavinum. Með hjálp þeirra framkvæmum við nauðsynlegar prófanir. Þannig fáum við fulla stjórn á niðurstöðum mælinga og skýrt merki. En það er engin fullkomin umfjöllun um tæki og notendastaðsetningar (sérstaklega með alheimsþjónustu og stuðningi fyrir þúsundir tækjagerða).
Hvernig er hægt að sameina kosti beggja aðferða?
Lið okkar hefur fundið lausn. Við skrifuðum lítið stykki af kóða - sýnishorn - sem við byggðum inn í forritið okkar. Kannar gera okkur kleift að gera fullstýrðar netprófanir úr tækjunum okkar. Það virkar svona:
- Stuttu eftir að forritið hefur verið hlaðið inn og fyrstu aðgerðinni er lokið keyrum við könnurnar okkar.
- Viðskiptavinurinn gerir beiðni til netþjónsins og fær „uppskrift“ fyrir prófið. Uppskriftin er listi yfir vefslóðir sem þarf að senda HTTP(s) beiðni á. Að auki stillir uppskriftin beiðnifæribreytur: tafir á milli beiðna, magn umbeðna gagna, HTTP(s) hausa osfrv. Á sama tíma getum við prófað nokkrar mismunandi uppskriftir samhliða - þegar beðið er um uppsetningu ákveðum við af handahófi hvaða uppskrift á að gefa út.
- Kynningartími rannsakanda er valinn til að stangast ekki á við virka notkun netauðlinda á biðlaranum. Í meginatriðum er tíminn valinn þegar viðskiptavinurinn er ekki virkur.
- Eftir að hafa fengið uppskriftina gerir viðskiptavinurinn beiðnir til hverrar vefslóðar, samhliða. Beiðnin til hvers heimilisföng er hægt að endurtaka - svokallaða. "pulsur". Við fyrsta púls mælum við hversu langan tíma það tók að koma á tengingu og hlaða niður gögnum. Á öðrum púlsinum mælum við tímann sem það tekur að hlaða gögnum yfir þegar komið er á tengingu. Fyrir þann þriðja getum við stillt seinkun og mælt hraðann á að koma á endurtengingu osfrv.
Meðan á prófinu stendur mælum við allar færibreytur sem tækið getur fengið:
- DNS beiðni tími;
- TCP tenging uppsetningartími;
- Uppsetningartími TLS tengingar;
- tími móttöku fyrsta bæti gagna;
- heildar hleðslutími;
- stöðu niðurstöðukóða.
- Eftir að öllum púlsum er lokið hleður sýnið allar mælingar til greiningar.
Lykilatriðin eru lágmarks háð rökfræði á viðskiptavininum, gagnavinnsla á þjóninum og mæling á samhliða beiðnum. Þannig getum við einangrað og prófað áhrif ýmissa þátta sem hafa áhrif á árangur fyrirspurna, breytt þeim innan einni uppskrift og fengið niðurstöður frá raunverulegum viðskiptavinum.
Þessi innviði hefur reynst gagnlegur fyrir meira en bara greining á frammistöðu fyrirspurna. Eins og er erum við með 14 virkar uppskriftir, meira en 6000 sýni á sekúndu, taka við gögnum frá öllum hornum jarðar og fulla umfang tækja. Ef Netflix keypti svipaða þjónustu frá þriðja aðila myndi það kosta milljónir dollara á ári, með mun verri umfjöllun.
Prófunarkenning í framkvæmd: frumgerð
Með slíku kerfi gátum við metið virkni CDN umboða á biðtíma. Nú þarftu:
- búa til proxy frumgerð;
- setja frumgerðina á CDN;
- ákvarða hvernig á að beina viðskiptavinum að umboði á tilteknum CDN netþjóni;
- Berðu saman árangur við beiðnir í AWS án umboðs.
Verkefnið er að meta árangur fyrirhugaðrar lausnar eins fljótt og auðið er. Við völdum Go til að innleiða frumgerðina vegna þess að góð netbókasöfn eru til staðar. Á hverjum CDN netþjóni settum við upp frumgerð umboðsins sem kyrrstæður tvíundir til að lágmarka ósjálfstæði og einfalda samþættingu. Í fyrstu innleiðingu notuðum við staðlaða íhluti eins mikið og mögulegt var og minniháttar breytingar fyrir HTTP/2 tengingar og biðja um margföldun.
Til að halda jafnvægi á milli AWS svæða notuðum við landfræðilegan DNS gagnagrunn, þann sama og notaður var til að koma jafnvægi á viðskiptavini. Til að velja CDN netþjón fyrir viðskiptavininn notum við TCP Anycast fyrir netþjóna í Internet Exchange (IX). Í þessum valmöguleika notum við eina IP tölu fyrir alla CDN netþjóna og viðskiptavinurinn verður beint á CDN netþjóninn með minnsta fjölda IP hoppa. Í CDN netþjónum sem internetveitur (ISP) setja upp, höfum við ekki stjórn á beini til að stilla TCP Anycast, svo við notum , sem vísar viðskiptavinum til netveitna til að streyma myndbandi.
Þannig að við höfum þrjár gerðir af beiðnileiðum: til skýsins í gegnum opna internetið, í gegnum CDN netþjón í IX, eða í gegnum CDN netþjón sem staðsettur er hjá netveitu. Markmið okkar er að skilja hvaða leið er betri og hver er ávinningurinn af umboði, samanborið við hvernig beiðnir eru sendar til framleiðslu. Til að gera þetta notum við sýnatökukerfi sem hér segir:
Hver af leiðunum verður að sérstöku skotmarki og við lítum á tímann sem við fengum. Til greiningar sameinum við umboðsniðurstöðurnar í einn hóp (veljum besta tímann á milli IX og ISP umboðs) og berum þær saman við tíma beiðna til skýsins án umboðs:
Eins og þú sérð voru niðurstöðurnar misjafnar - í flestum tilfellum gefur umboðið góða hraðaupphlaup, en það eru líka nægjanlegur fjöldi viðskiptavina sem ástandið mun versna verulega.
Fyrir vikið gerðum við nokkra mikilvæga hluti:
- Við metum væntanlegur árangur beiðna frá viðskiptavinum til skýsins í gegnum CDN umboð.
- Við fengum gögn frá raunverulegum viðskiptavinum, frá öllum gerðum tækja.
- Við áttum okkur á því að kenningin var ekki 100% staðfest og upphafstilboðið með CDN umboði myndi ekki virka fyrir okkur.
- Við tókum ekki áhættu - við breyttum ekki framleiðslustillingum fyrir viðskiptavini.
- Ekkert var brotið.
Frumgerð 2.0
Svo, aftur á teikniborðið og endurtaktu ferlið aftur.
Hugmyndin er sú að í stað þess að nota 100% umboð, munum við ákvarða hraðasta leiðina fyrir hvern viðskiptavin og við sendum beiðnir þangað - það er að segja við gerum það sem kallast viðskiptavinastýring.
Hvernig á að útfæra þetta? Við getum ekki notað rökfræði á þjóninum, vegna þess að... Markmiðið er að tengjast þessum netþjóni. Það þarf að vera einhver leið til að gera þetta á viðskiptavininn. Og helst, gerðu þetta með lágmarks magni flókinnar rökfræði, svo að ekki leysist vandamálið um samþættingu við fjölda viðskiptavinarkerfa.
Svarið er að nota DNS. Í okkar tilviki höfum við okkar eigin DNS innviði og við getum sett upp lénssvæði sem netþjónar okkar munu vera valdsmenn fyrir. Það virkar svona:
- Viðskiptavinurinn gerir beiðni til DNS-þjónsins með því að nota hýsil, til dæmis api.netflix.xom.
- Beiðnin berst á DNS netþjóninn okkar
- DNS þjónninn veit hvaða leið er fljótlegast fyrir þennan biðlara og gefur út samsvarandi IP tölu.
Lausnin hefur aukið flókið: auðvaldsbundnir DNS veitendur sjá ekki IP tölu viðskiptavinarins og geta aðeins lesið IP tölu endurkvæma lausnarans sem viðskiptavinurinn notar.
Þar af leiðandi verður auðvaldslausamaður okkar að taka ákvörðun ekki fyrir einstakan skjólstæðing heldur hóp viðskiptavina sem byggir á endurkvæma lausnaranum.
Til að leysa, notum við sömu sýnishornin, tökum saman mæliniðurstöður frá viðskiptavinum fyrir hvern endurkvæma lausnaraðila og ákveðum hvert á að senda þennan hóp af þeim - umboð í gegnum IX með TCP Anycast, í gegnum ISP umboð eða beint í skýið.
Við fáum eftirfarandi kerfi:
DNS stýrislíkanið sem myndast gerir þér kleift að beina viðskiptavinum út frá sögulegum athugunum á hraða tenginga frá viðskiptavinum til skýsins.
Aftur er spurningin hversu áhrifarík þessi nálgun mun virka? Til að svara, notum við aftur rannsaka kerfið okkar. Þess vegna stillum við kynningarstillinguna, þar sem eitt af markmiðunum fylgir stefnu frá DNS-stýringu, hitt fer beint í skýið (núverandi framleiðsla).
Fyrir vikið berum við saman niðurstöðurnar og fáum mat á virkni:
Fyrir vikið lærðum við nokkra mikilvæga hluti:
- Við metum væntanlegur árangur beiðna frá viðskiptavinum í skýið með DNS stýri.
- Við fengum gögn frá raunverulegum viðskiptavinum, frá öllum gerðum tækja.
- Virkni fyrirhugaðrar hugmyndar hefur verið sannað.
- Við tókum ekki áhættu - við breyttum ekki framleiðslustillingum fyrir viðskiptavini.
- Ekkert var brotið.
Nú um erfiða hlutann - við setjum það í framleiðslu
Auðvelda hlutanum er nú lokið - það er frumgerð sem virkar. Nú er erfiði hlutinn að setja af stað lausn fyrir alla umferð Netflix, dreift til 150 milljón notenda, þúsunda tækja, hundruð örþjónustu og síbreytilegra vara og innviða. Netflix netþjónar fá milljónir beiðna á sekúndu og það er auðvelt að brjóta þjónustuna með kærulausum aðgerðum. Á sama tíma viljum við beina umferð á virkan hátt í gegnum þúsundir CDN netþjóna á netinu, þar sem eitthvað breytist og bilar stöðugt og á óhentugasta augnabliki.
Og með öllu þessu hefur teymið 3 verkfræðinga sem bera ábyrgð á þróun, uppsetningu og fullum stuðningi kerfisins.
Þess vegna munum við halda áfram að tala um rólegan og heilbrigðan svefn.
Hvernig á að halda áfram þróun og eyða ekki öllum tíma þínum í stuðning? Nálgun okkar byggir á þremur meginreglum:
- Við minnkum hugsanlega umfang bilana (sprengjuradíus).
- Við erum að búa okkur undir óvæntar uppákomur - við gerum ráð fyrir að eitthvað brotni, þrátt fyrir prófanir og persónulega reynslu.
- Þokkafull niðurbrot - ef eitthvað virkar ekki rétt ætti að laga það sjálfkrafa, jafnvel þó ekki á sem hagkvæmastan hátt.
Það kom í ljós að í okkar tilviki, með þessari nálgun á vandamálið, getum við fundið einfalda og skilvirka lausn og einfaldað kerfisstuðning verulega. Við komumst að því að við gætum bætt litlum kóða við biðlarann og fylgst með villum í netbeiðnum af völdum tengingarvandamála. Ef um netvillur er að ræða, gerum við fallback beint í skýið. Þessi lausn krefst ekki verulegrar fyrirhafnar fyrir teymi viðskiptavina, en dregur verulega úr hættu á óvæntum bilunum og óvæntum uppákomum fyrir okkur.
Auðvitað, þrátt fyrir bakslag, fylgjum við engu að síður skýrum aga við þróun:
- Dæmi um próf.
- A/B próf eða Kanarí.
- Framsækin útfærsla.
Með sýnum hefur nálguninni verið lýst - breytingar eru fyrst prófaðar með sérsniðinni uppskrift.
Fyrir kanarípróf þurfum við að fá sambærileg netþjónapör sem við getum borið saman hvernig kerfið virkar á fyrir og eftir breytingar. Til að gera þetta, af mörgum CDN síðum okkar, veljum við pör af netþjónum sem fá sambærilega umferð:
Síðan setjum við upp bygginguna með breytingunum á Canary servernum. Til að meta niðurstöðurnar keyrum við kerfi sem ber saman um það bil 100-150 mælikvarða við sýnishorn af stjórnunarþjónum:
Ef Kanaríprófið gengur vel, þá sleppum við því smám saman, í bylgjum. Við uppfærum ekki netþjóna á hverri síðu á sama tíma - að missa heila síðu vegna vandamála hefur meiri áhrif á þjónustuna fyrir notendur en að missa sama fjölda netþjóna á mismunandi stöðum.
Almennt séð er skilvirkni og öryggi þessarar nálgun háð magni og gæðum mælinganna sem safnað er. Fyrir fyrirspurnarhröðunarkerfið okkar söfnum við mælingum úr öllum mögulegum íhlutum:
- frá viðskiptavinum - fjöldi funda og beiðna, varahlutfall;
- umboð - tölfræði um fjölda og tíma beiðna;
- DNS - fjöldi og niðurstöður beiðna;
- skýjabrún - fjöldi og tími til að vinna úr beiðnum í skýinu.
Öllu þessu er safnað saman í eina leiðslu og, eftir þörfum, ákveðum við hvaða mælikvarða á að senda í rauntímagreiningu og hverja til Elasticsearch eða Big Data til að fá ítarlegri greiningu.
Við fylgjumst með
Í okkar tilviki erum við að gera breytingar á mikilvægri leið beiðna milli viðskiptavinar og netþjóns. Á sama tíma er fjöldi mismunandi íhluta á biðlaranum, á þjóninum og á leiðinni í gegnum internetið gríðarlegur. Breytingar á biðlara og netþjóni eiga sér stað stöðugt - meðan á vinnu tugum teyma stendur og náttúrulegar breytingar á vistkerfinu. Við erum í miðjunni - þegar vandamál eru greind eru góðar líkur á að við tökum þátt. Þess vegna þurfum við að skilja greinilega hvernig á að skilgreina, safna og greina mælikvarða til að einangra vandamál fljótt.
Helst fullur aðgangur að öllum gerðum mælikvarða og síum í rauntíma. En það er fullt af mælingum, þannig að spurningin um kostnað vaknar. Í okkar tilviki aðskiljum við mælikvarða og þróunarverkfæri sem hér segir:
Til að greina og laga vandamál notum við okkar eigin opna rauntímakerfi и - fyrir sjón. Það geymir samanlagðar mæligildi í minni, er áreiðanlegt og samþættir viðvörunarkerfið. Til staðsetningar og greiningar höfum við aðgang að annálum frá Elasticsearch og Kibana. Fyrir tölfræðilega greiningu og líkanagerð notum við stór gögn og sjónmynd í Tableau.
Svo virðist sem mjög erfitt sé að vinna með þessa nálgun. Hins vegar, með því að skipuleggja mælikvarða og verkfæri stigveldis, getum við fljótt greint vandamál, ákvarðað tegund vandamálsins og síðan borið niður í ítarlegar mælingar. Almennt eyðum við um 1-2 mínútum í að finna upptök bilunarinnar. Að þessu loknu vinnum við með ákveðnu teymi að greiningu - allt frá tugum mínútna til nokkurra klukkustunda.
Jafnvel þótt greiningin sé gerð fljótt, viljum við ekki að þetta gerist oft. Helst fáum við aðeins mikilvæga viðvörun þegar það hefur veruleg áhrif á þjónustuna. Fyrir fyrirspurnarhröðunarkerfið okkar höfum við aðeins 2 viðvaranir sem munu láta vita:
- Fallback prósenta viðskiptavina - mat á hegðun viðskiptavina;
- hlutfall rannsaka villur - stöðugleika gögn nethluta.
Þessar mikilvægu viðvaranir fylgjast með því hvort kerfið virki fyrir meirihluta notenda. Við skoðum hversu margir viðskiptavinir notuðu fallback ef þeir gátu ekki fengið beiðni um hröðun. Við erum að meðaltali innan við 1 mikilvæg viðvörun á viku, jafnvel þó að það séu fullt af breytingum í gangi í kerfinu. Af hverju er þetta nóg fyrir okkur?
- Það er tilfallandi viðskiptavinur ef umboðið okkar virkar ekki.
- Það er sjálfvirkt stýrikerfi sem bregst við vandamálum.
Nánari upplýsingar um hið síðarnefnda. Reynslukerfið okkar, og kerfið til að ákvarða sjálfkrafa bestu leiðina fyrir beiðnir frá viðskiptavininum til skýsins, gerir okkur kleift að takast á við sum vandamál sjálfkrafa.
Snúum okkur aftur að sýnishorninu okkar og 3 leiðaflokkum. Auk hleðslutíma getum við litið á þá staðreynd að afhendingin sjálf er. Ef það var ekki hægt að hlaða gögnunum, þá með því að skoða niðurstöðurnar eftir mismunandi leiðum getum við ákvarðað hvar og hvað bilaði og hvort við getum sjálfkrafa lagað það með því að breyta beiðnileiðinni.
Dæmi:
Þetta ferli er hægt að gera sjálfvirkt. Settu það inn í stýrikerfið. Og kenndu því að bregðast við vandamálum með frammistöðu og áreiðanleika. Ef eitthvað byrjar að bila skaltu bregðast við ef það er betri kostur. Á sama tíma eru tafarlaus viðbrögð ekki mikilvæg, þökk sé afturför á viðskiptavini.
Þannig er hægt að móta meginreglur kerfisstuðnings sem hér segir:
- minnka umfang bilana;
- söfnun mæligilda;
- Við gerum sjálfkrafa bilanir ef við getum;
- ef það getur ekki, látum við þig vita;
- Við erum að vinna í mælaborðum og triage verkfærasetti fyrir skjót viðbrögð.
Lexía lærð
Það tekur ekki mikinn tíma að skrifa frumgerð. Í okkar tilviki var það tilbúið eftir 4 mánuði. Með henni fengum við nýjar mælikvarða og 10 mánuðum eftir að þróun hófst fengum við fyrstu framleiðsluumferðina. Síðan hófst hið leiðinlega og mjög erfiða verk: Framleiða og skala kerfið smám saman, flytja aðalumferðina og læra af mistökum. Hins vegar verður þetta árangursríka ferli ekki línulegt - þrátt fyrir alla viðleitni er ekki hægt að spá fyrir um allt. Það er miklu áhrifaríkara að endurtaka og bregðast við nýjum gögnum fljótt.
Byggt á reynslu okkar getum við mælt með eftirfarandi:
- Treystu ekki innsæi þínu.
Innsæi okkar brást okkur stöðugt, þrátt fyrir mikla reynslu liðsmanna okkar. Til dæmis spáðum við rangt fyrir um væntanlegan hraða með því að nota CDN umboð eða hegðun TCP Anycast.
- Sækja gögn frá framleiðslu.
Mikilvægt er að fá aðgang að að minnsta kosti litlu magni af framleiðslugögnum eins fljótt og auðið er. Það er næstum ómögulegt að fá fjölda einstakra tilvika, stillinga og stillinga við rannsóknarstofuaðstæður. Skjótur aðgangur að niðurstöðunum gerir þér kleift að læra fljótt um hugsanleg vandamál og taka tillit til þeirra í kerfisarkitektúrnum.
- Ekki fylgja ráðum og niðurstöðum annarra - safnaðu þínum eigin gögnum.
Fylgdu meginreglum um söfnun og greiningu gagna, en taktu ekki í blindni niðurstöður og staðhæfingar annarra. Aðeins þú getur vitað nákvæmlega hvað virkar fyrir notendur þína. Kerfin þín og viðskiptavinir þínir gætu verið verulega frábrugðnir öðrum fyrirtækjum. Sem betur fer eru nú greiningartæki fáanleg og auðveld í notkun. Niðurstöðurnar sem þú færð eru kannski ekki það sem Netflix, Facebook, Akamai og önnur fyrirtæki halda fram. Í okkar tilviki er frammistaða TLS, HTTP2 eða tölfræði um DNS-beiðnir frábrugðin niðurstöðum Facebook, Uber, Akamai - vegna þess að við höfum mismunandi tæki, viðskiptavini og gagnaflæði.
- Ekki fylgja tískustraumum að óþörfu og meta árangur.
Byrjaðu einfalt. Það er betra að búa til einfalt vinnukerfi á stuttum tíma en að eyða miklum tíma í að þróa íhluti sem þú þarft ekki. Leystu verkefni og vandamál sem skipta máli út frá mælingum þínum og niðurstöðum.
- Vertu tilbúinn fyrir nýjar umsóknir.
Rétt eins og erfitt er að spá fyrir um öll vandamálin er erfitt að spá fyrir um kosti og umsóknir fyrirfram. Taktu mark á sprotafyrirtækjum - hæfni þeirra til að laga sig að aðstæðum viðskiptavina. Í þínu tilviki gætirðu uppgötvað ný vandamál og lausnir þeirra. Í verkefninu okkar settum við okkur markmið um að draga úr biðtíma. Hins vegar, við greininguna og umræðurnar, komumst við að því að við getum líka notað proxy-þjóna:
- að koma jafnvægi á umferð yfir AWS svæði og draga úr kostnaði;
- að fyrirmynd CDN stöðugleika;
- til að stilla DNS;
- til að stilla TLS/TCP.
Ályktun
Í skýrslunni lýsti ég því hvernig Netflix leysir vandamálið við að flýta fyrir netbeiðnum milli viðskiptavina og skýsins. Hvernig við söfnum gögnum með því að nota sýnatökukerfi um viðskiptavini og notum söfnuð söguleg gögn til að beina framleiðslubeiðnum frá viðskiptavinum í gegnum hraðasta leiðina á netinu. Hvernig við notum meginreglur netsamskiptareglur, CDN innviði okkar, burðarnet og DNS netþjóna til að ná þessu verkefni.
Hins vegar er lausnin okkar bara dæmi um hvernig við hjá Netflix innleiddum slíkt kerfi. Hvað virkaði fyrir okkur. Hagnýti hluti skýrslunnar minnar fyrir þig eru meginreglur um þróun og stuðning sem við fylgjum og náum góðum árangri.
Lausn okkar á vandamálinu hentar þér kannski ekki. Hins vegar eru kenningarnar og hönnunarreglurnar áfram, jafnvel þótt þú hafir ekki þína eigin CDN innviði, eða ef það er verulega frábrugðið okkar.
Mikilvægi hraða viðskiptabeiðna er einnig enn mikilvægt. Og jafnvel fyrir einfalda þjónustu þarftu að velja: á milli skýjaveitna, staðsetningar miðlara, CDN og DNS veitenda. Val þitt mun hafa áhrif á virkni netfyrirspurna fyrir viðskiptavini þína. Og það er mikilvægt fyrir þig að mæla og skilja þessi áhrif.
Byrjaðu á einföldum lausnum, hugsaðu um hvernig þú breytir vörunni. Lærðu á meðan þú ferð og bættu kerfið byggt á gögnum frá viðskiptavinum þínum, innviðum þínum og fyrirtæki þínu. Hugsaðu um möguleikann á óvæntum bilunum meðan á hönnunarferlinu stendur. Og þá geturðu flýtt fyrir þróunarferlinu þínu, bætt skilvirkni lausna, forðast óþarfa stuðningsbyrði og sofið rólega.
Í ár á netformi. Þú getur spurt spurninga til eins af feðrum DevOps, sjálfum John Willis!
Heimild: www.habr.com