Netflix â lideri i tregut tĂ« televizionit pĂ«rmes internetit â Ă«shtĂ« njĂ« kompani qĂ« ka krijuar dhe po zhvillon kĂ«tĂ« segment. Netflix Ă«shtĂ« i njohur jo vetĂ«m pĂ«r katalogun e tij tĂ« gjerĂ« tĂ« filmave dhe serialeve, tĂ« cilat janĂ« tĂ« disponueshme nga pothuajse çdo cep i globit dhe nĂ« çdo pajisje me ekran, por edhe pĂ«r infrastrukturĂ«n e tij tĂ« besueshme dhe kulturĂ«n inxhinierike unike.
NjĂ« shembull i dukshĂ«m i qasjes sĂ« Netflix pĂ«r zhvillimin dhe mbĂ«shtetje tĂ« sistemeve komplekse nĂ« DevOops 2019 u paraqit nga â drejtori i zhvillimit nĂ« Netflix. Absolvent i Fakultetit tĂ« VMK tĂ« NNGU-sĂ« me emrin Lobachevsky, Sergio Ă«shtĂ« njĂ« nga inxhinierĂ«t e parĂ« nĂ« Open Connect â ekipin CDN nĂ« Netflix. Ai ka ndĂ«rtuar sisteme monitorimi dhe analize tĂ« tĂ« dhĂ«nave video, ka lançuar shĂ«rbimin e njohur pĂ«r vlerĂ«simin e shpejtĂ«sisĂ« sĂ« lidhjes sĂ« internetit FAST.com, dhe nĂ« vitet e fundit ka punuar pĂ«r optimizimin e kĂ«rkesave tĂ« internetit, qĂ« aplikacioni Netflix tĂ« funksionojĂ« sa mĂ« shpejt pĂ«r pĂ«rdoruesit.
Referati mori vlerësime më të mira nga pjesëmarrësit e konferencës, dhe ne kemi përgatitur për ju një version të shkruar.
Në referat, Sergio tregoi në detaje
- çfarë ndikon në vonesën e kërkesave të internetit midis klientit dhe serverit;
- si të reduktohet kjo vonesë;
- si të projektosh, mbash dhe monitorosh sisteme të qëndrueshme ndaj gabimeve;
- si të arrish rezultate brenda kohës së kufizuar dhe me rrezik minimal për biznesin;
- si të analizosh rezultatet dhe të mësosh nga gabimet.
Përgjigjet për këto pyetje janë të nevojshme jo vetëm për ata që punojnë në korporata të mëdha.
Principet dhe teknikat e paraqitura duhet t'i njohë dhe praktikojë çdo kush që zhvillon dhe mban produkte të internetit.
Më pas - një rrëfim nga vetë folësi.
Rëndësia e shpejtësisë së internetit
Shpejtësia e kërkesave në internet është drejtpërdrejt e lidhur me biznesin. Le të shqyrtojmë fushën e blerjeve: kompania Amazon në vitin 2009 , se një vonesë prej 100 ms çon në humbjen e 1% të shitjeve.
Po bëhet gjithnjë e më shumë përdorim i pajisjeve mobile, dhe si pasojë, po ashtu edhe i faqeve dhe aplikacioneve mobile. Nëse faqja juaj ngarkohet më gjatë se 3 sekonda, humbni rreth gjysmën e përdoruesve. S Google merr në konsideratë shpejtësinë e ngarkesës së faqes tuaj në rezultatet e kërkimit: sa më shpejtë të jetë faqja, aq më lart është pozita e saj në Google.
Shpejtësia e lidhjes është gjithashtu e rëndësishme edhe në organizatat financiare, ku vonesa është kritike. Në vitin 2015, kompania Hibernia Networks një kabllo lidhës midis Nju Jorkut dhe Londrës me një kosto prej 400 milion dollarësh, për të zvogëluar vonesën midis qyteteve me 6 ms. Imagjinoni, 66 milion dollarë për 1 ms reduktim vonese!
Sipas , shpejtësia e lidhjes mbi 5 Mbit/s nuk ndikon më drejtpërdrejt në shpejtësinë e ngarkimit të një faqeje tipike. Sidoqoftë, ekziston një lidhje lineare midis vonesës së lidhjes dhe shpejtësisë së ngarkimit të faqes:
Megjithatë, Netflix nuk është një produkt tipik. Ndikimi i vonesës dhe shpejtësisë mbi përdoruesin është një fushë aktive analize dhe zhvillimi. Ka ngarkim të aplikacionit dhe përzgjedhje përmbajtjeje që varen nga vonesa, por ngarkimi i elementeve statike dhe transmetimi gjithashtu varen nga shpejtësia e lidhjes. Analiza dhe optimizimi i faktorëve kyç që ndikojnë në cilësinë e shërbimit për përdoruesin është një fushë aktive zhvillimi për disa ekipe në Netflix. Një nga detyrat është zvogëlimi i vonesave të kërkesave midis pajisjeve Netflix dhe infrastrukturës përkatëse në re.
Në raport do të përqendrohemi specifikisht në reduktimin e vonesave (latency) duke marrë si shembull infrastrukturën e Netflix. Do të shqyrtojmë nga një perspektivë praktike se si të qasemi ndaj proceseve të dizajnit, zhvillimit dhe operimit të sistemeve komplekse të shpërndara, duke shpenzuar kohë në inovacion dhe rezultate, e jo në diagnostikimin e problemeve operative dhe defekteve.
Brenda Netflix
Mijëra pajisje të ndryshme mbështesin aplikacionet e Netflix. Zhvillimi i tyre bëhet nga katër ekipe të ndryshme, që krijojnë versione të veçanta të klientit për Android, iOS, TV dhe shfletuesit e internetit. Dhe ne investojmë shumë përpjekje në përmirësimin dhe personalizimin e ndërfaqes përdoruesit. Për këtë, ne realizojmë paralelisht qindra teste A/B.
Personalizimi mbĂ«shtetet nga njĂ«qind mikrov ŰźŰŻÙ Ű§ŰȘ nĂ« cloud-in AWS, qĂ« ofrojnĂ« tĂ« dhĂ«na tĂ« personalizuara pĂ«r pĂ«rdoruesin, menaxhimin e kĂ«rkesave, telemetrinĂ«, Big Data dhe Kodimin. Vizualizimi i trafikut duket kĂ«shtu:
NĂ« tĂ« majtĂ« ndodhet pika hyrĂ«se, e mĂ« pas trafiku shpĂ«rndahet midis disa qindra mikrov ŰźŰŻÙ Ű§ŰȘ, tĂ« cilat mbĂ«shteten nga ekipe tĂ« ndryshme backend.
NjĂ« komponent tjetĂ«r i rĂ«ndĂ«sishĂ«m i infrastrukturĂ«s sonĂ« Ă«shtĂ« Open Connect CDN, i cili dĂ«rgon pĂ«rmbajtje statike te pĂ«rdoruesi pĂ«rfundimtar â video, imazhe, kod pĂ«r klientĂ«t etj. CDN Ă«shtĂ« e vendosur nĂ« serverĂ« tĂ« personalizuar (OCA â Open Connect Appliance). Brenda janĂ« grupe SSD dhe HDD, tĂ« menaxhuara nga njĂ« FreeBSD e optimizuar, me NGINX dhe njĂ« grup shĂ«rbimesh. Ne projektojmĂ« dhe optimizojmĂ« komponentĂ«t harduerikĂ« dhe softuerikĂ« nĂ« mĂ«nyrĂ« qĂ« ky server CDN tĂ« mund tĂ« dĂ«rgojĂ« sa mĂ« shumĂ« tĂ« dhĂ«na te pĂ«rdoruesit.
«Muri» i kĂ«tyre serverĂ«ve nĂ« pikĂ«n eäș€æą internetit (Internet eXchange â IX), duket kĂ«shtu:
Internet Exchange ofron mundësinë për ofruesit e internetit dhe ofruesit e përmbajtjes të «lidhen» me njëri-tjetrin për shkëmbim më të drejtpërdrejtë të të dhënave në internet. Në të gjithë botën ka rreth 70-80 pika Internet Exchange, ku janë instaluar serverët tanë, dhe ne merremi vetë me instalim dhe mirëmbajtje:
Përveç kësaj, ne gjithashtu ofrojmë serverë drejtpërdrejt për ofruesit e internetit, të cilët i instalojnë në rrjetin e tyre, duke përmirësuar lokalizimin e trafikut të Netflix dhe cilësinë e transmetimit për përdoruesit:
Grupi i shĂ«rbimeve AWS Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r menaxhimin e kĂ«rkesave pĂ«r video nga klientĂ«t nĂ« serverat CDN, si dhe konfigurimin e vetĂ« serverĂ«ve â pĂ«rditĂ«simin e pĂ«rmbajtjes, kodit programor, konfigurimeve, etj. PĂ«r kĂ«tĂ«, ne gjithashtu kemi ndĂ«rtuar njĂ« rrjet backbone, i cili lidh serverĂ«t nĂ« pikĂ«n e shkĂ«mbimit tĂ« internetit me AWS. Rrjeti backbone pĂ«rfaqĂ«son njĂ« rrjet global me fibra optike dhe routera qĂ« ne mund ta projektojmĂ« dhe ta konfiguroni sipas nevojave tona.
Sipas , infrastruktura jonĂ« CDN dorĂ«zon nĂ« orĂ«t kulmore rreth â e trafikut global tĂ« internetit dhe â tĂ« trafikut nĂ« AmerikĂ«n Veriore, ku Netflix ekziston mĂ« gjatĂ«. Numra tĂ« mahnitshĂ«m, por pĂ«r mua, njĂ« nga arritjet mĂ« tĂ« habitshme Ă«shtĂ« se e gjithĂ« sistemi CDN zhvillohet dhe mbĂ«shtetet nga njĂ« ekip prej mĂ« pak se 150 personash.
Fillimisht, infrastruktura CDN ishte e dizajnuar për të dorëzuar të dhëna video. Megjithatë, me kalimin e kohës, ne kuptuam se mund ta përdornim gjithashtu për të optimizuar kërkesat dinamike nga klientët në AWS cloud.
Për përshpejtimin e internetit
SotĂ«r sot Netflix ka 3 rajone AWS, dhe vonesat e kĂ«rkesave nĂ« cloud do tĂ« varen nga sa larg Ă«shtĂ« klienti nga rajoni mĂ« i afĂ«rt. Ne gjithashtu kemi njĂ« numĂ«r tĂ« madh serverĂ«sh CDN, qĂ« pĂ«rdoren pĂ«r shpĂ«rndarjen e pĂ«rmbajtjes statike. A mund ta pĂ«rdorim kĂ«tĂ« infrastrukturĂ« pĂ«r tĂ« pĂ«rshpejtuar kĂ«rkesat dinamike? MegjithatĂ«, fatkeqĂ«sisht, nuk mund tĂ« cache-ojmĂ« kĂ«to kĂ«rkesa â API-tĂ« janĂ« tĂ« personalizuara dhe çdo rezultat Ă«shtĂ« unik.
Le të krijojmë një proxy në serverin CDN dhe fillojmë ta kalojmë trafikun përmes tij. A do të jetë më shpejt?
Materiali
Le të kujtojmë se si funksionojnë protokollet e rrjetit. Sot, shumica e trafikut në internet përdor HTTPs, i cili varet nga protokollet në nivele më të ulta TCP dhe TLS. Për të lidhur klientin me serverin, ai bën një handshake, dhe për të vendosur një lidhje të sigurt, klienti duhet të shkëmbejë mesazhe me serverin tri herë dhe së paku një herë tjetër për të transferuar të dhënat. Me një vonesë për një shkëmbim (RTT) prej 100 ms, na nevojiten 400 ms për të marrë bitin e parë të të dhënave:
Nëse i vendosim certifikatat në serverin CDN, mund ta reduktojmë ndjeshëm kohën e "përshëndetjes" midis klientit dhe serverit, nëse CDN është më afër. Le të supozojmë se vonesa deri te serveri CDN është 30 ms. Atëherë, për të marrë bitin e parë do të nevojiten tashmë 220 ms:
Por avantazhet nuk përfundojnë këtu. Pas pasjen e lidhjes, TCP rrit dritaren e tregtisë (sasia e informacionit që mund të transmetohet në këtë lidhje paralelisht). Nëse humbet një paketë të dhënash, zbatimet tradicionale të protokollit TCP (siç është TCP New Reno) e reduktojnë dritaren e hapur në gjysmën e saj. Rritja e dritares së tregtisë dhe shpejtësia e rikuperimit nga humbja varen përsëri nga vonesa (RTT) deri te serveri. Nëse kjo lidhje shkon vetëm deri te serveri CDN, rikuperimi do të jetë më i shpejtë. Gjithashtu, humbjet e paketimeve janë një fenomen standard, veçanërisht për rrjetet wireless.
Kapaciteti i internetit mund tĂ« zvogĂ«lohen, veçanĂ«risht nĂ« orĂ«t e pikut pĂ«r shkak tĂ« trafikut nga pĂ«rdoruesit, çka mund tĂ« çojĂ« nĂ« "trafik". MegjithatĂ«, nĂ« internet nuk ka njĂ« mĂ«nyrĂ« pĂ«r tĂ« dhĂ«nĂ« prioritet kĂ«rkesave tĂ« caktuara nĂ« krahasim me tĂ« tjerat. PĂ«r shembull, pĂ«r tĂ« dhĂ«nĂ« prioritet kĂ«rkesave nga volum tĂ« vogĂ«l dhe qĂ« janĂ« tĂ« ndjeshme ndaj vonesave nĂ« krahasim me "rrjedhat e mĂ«dha" tĂ« tĂ« dhĂ«nave qĂ« ngarkojnĂ« rrjetin. MegjithatĂ«, nĂ« rastin tonĂ«, prezenca e njĂ« rrjeti backbone nĂ« pronĂ«si na lejon ta bĂ«jmĂ« kĂ«tĂ« nĂ« njĂ« pjesĂ« tĂ« rrugĂ«s sĂ« kĂ«rkesĂ«s â mes CDN-sĂ« dhe cloud-it, dhe ne e kemi atĂ« tĂ«rĂ«sisht tĂ« konfiguruar. Mund tĂ« bĂ«jmĂ« qĂ« paketa tĂ« vogla dhe tĂ« ndjeshme ndaj vonesave tĂ« kenĂ« prioritet, ndĂ«rsa rrjedhat e mĂ«dha tĂ« dhĂ«nash tĂ« kalojnĂ« pak mĂ« vonĂ«. Sa mĂ« afĂ«r tĂ« jetĂ« CDN pĂ« klientin, aq mĂ« e lartĂ« Ă«shtĂ« efikasiteti.
Një ndikim tjetër në vonesë kanë protokollet e nivelit të aplikacionit (OSI Level 7). Protokollet e reja, si HTTP/2, lejojnë optimizimin e performancës së kërkesave paralel. Megjithatë, Netflix ka klientë me pajisje të vjetra që nuk mbështesin protokollet e reja. Jo të gjithë klientët mund të përditësohen ose të konfigurohen optimalisht. Në këtë rast, midis CDN proxy dhe cloud-it, ka një kontroll të plotë dhe mundësinë për të përdorur protokollet dhe konfigurimet më të reja dhe optimale. Pjesa joefikase me protokollet e vjetra do të funksionojë vetëm midis klientit dhe serverit CDN. Për më tepër, ne mund të kryejmë multiplex kërkesash në një nyje të vendosur tashmë midis CDN dhe cloud-it, duke përmirësuar shfrytëzimin e lidhjes në nivelin TCP:
Masa
Pavarësisht se teoria premton përmirësime, ne nuk nxitim të lançojmë sistemin në prodhim menjëherë. Në vend të kësaj, duhet së pari të dëshmojmë se ideja do të funksionojë në praktikë. Për këtë, duhet t'i përgjigjemi disa pyetjeve:
- Shpejtësia: a do të jetë proxy më i shpejtë?
- Besueshmëria: a do të dështojë më shpesh?
- Kompleksiteti: si të integrohet me aplikacionet?
- Ămimi: sa kushton vendosja e infrastrukturĂ«s sĂ« shtuar?
Le të shqyrtojmë në detaje qasjen tonë ndaj vlerësimit të pikës së parë. Të tjerat shqyrtohen në mënyrë të ngjashme.
Për analizën e shpejtësisë së kërkesave, ne duam të marrim të dhëna për të gjithë përdoruesit, pa humbur shumë kohë në zhvillim dhe pa prishur production. Ka disa qasje për këtë:
- RUM, ose matja pasive e kërkesave. Matim koha e përfundimit të kërkesave aktuale nga përdoruesit dhe sigurojmë mbulim të plotë të përdoruesve. Disavantazhi - sinjali nuk është shumë stabil për shkak të shumë faktorëve, siç janë madhësitë e ndryshme të kërkesave, koha e përpunimit në server dhe në klient. Për më tepër, nuk është e mundur të testosh një konfigurim të ri pa pasur ndikim në production.
- Testet laboratorike. Servera dhe infrastrukturë të posaçme që imitojnë klientët. Me ndihmën e tyre, ne realizojmë testet e nevojshme. Kështu, ne sigurojmë kontroll të plotë mbi rezultatet e matjeve dhe një sinjal të qartë. Por, nuk ka mbulim të plotë të pajisjeve dhe lokacioneve të përdoruesve (veçanërisht me shërbimin që ofrohet në të gjithë botën dhe mbështetje për mijëra modele pajisjesh).
Si mund të kombinohen përfitimet e të dyjave?
Ekipi ynĂ« gjeti njĂ« zgjidhje. Ne shkruam njĂ« copĂ« kod-iâprobeâe cila Ă«shtĂ« integruar nĂ« aplikacionin tonĂ«. Probat na lejojnĂ« tĂ« kryejmĂ« teste rrjetĂ«sh tĂ« plota tĂ« kontrolluara nga pajisjet tona. Kjo funksionon si mĂ« poshtĂ«:
- Shpejt pas ngarkimit të aplikacionit dhe përfundimit të aktivitetit fillestar, ne lançojmë prokat tona.
- K clienti bĂ«n njĂ« kĂ«rkesĂ« nĂ« server dhe merr njĂ« «recetë» testi. Receta pĂ«rbĂ«het nga njĂ« listĂ« URL-sh qĂ« duhet tĂ« bĂ«hen kĂ«rkesa HTTP(s). PĂ«rveç kĂ«saj, receta konfiguronk parametrat e kĂ«rkesave: ndĂ«rprerjet midis kĂ«rkesave, sasia e tĂ« dhĂ«nave tĂ« kĂ«rkuara, HTTP(s) headers, etj. NĂ« kĂ«tĂ« mĂ«nyrĂ«, ne mund tĂ« testojmĂ« paralelisht disa receta tĂ« ndryshmeânĂ« kĂ«rkesĂ«n pĂ«r konfigurim, ne pĂ«rcaktojmĂ« rastĂ«sisht se cila recetĂ« t'i japim.
- Koha e lançimit të prokës zgjidhet në mënyrë që të mos përputhet me përdorimin aktiv të burimeve rrjetore nga klienti. Në thelb, zgjidhet një kohë kur klienti nuk është aktiv.
- Pas miratimit tĂ« reçetĂ«s, klienti bĂ«n kĂ«rkesa pĂ«r çdo URL, njĂ«kohĂ«sisht. KĂ«rkesa pĂ«r çdo adresĂ« mund tĂ« pĂ«rsĂ«ritet â e ashtuquajtura "puls". NĂ« pulsin e parĂ« matim sa kohĂ« i duhen pĂ«r tĂ« vendosur lidhjen dhe ngarkuar tĂ« dhĂ«nat. NĂ« pulsin e dytĂ«, ne matim kohĂ«n e ngarkimit tĂ« tĂ« dhĂ«nave pĂ«rmes lidhjes sĂ« vendosur tashmĂ«. Para pulsin tĂ« tretĂ«, mund tĂ« vendosim njĂ« vonesĂ« dhe tĂ« matim shpejtĂ«sinĂ« e vendosjes sĂ« rivendosjes sĂ« lidhjes etj.
Gjatë testit, ne matim të gjitha parametrat që mund të marrë pajisja:
- kohën e kërkesës DNS;
- kohën e vendosjes së lidhjes përmes TCP;
- kohën e vendosjes së lidhjes përmes TLS;
- kohën e marrjes së bajtit të parë të të dhënave;
- kohën totale të ngarkimit;
- kodin e statusit të rezultatit.
- Pas përfundimit të të gjitha pulseve, proba ngarkon rezultatet e të gjitha matjeve për analizë.
Pikat kyç janë minimalja varësi nga logjika në klient, përpunimi i të dhënave në server dhe matja e kërkesave paralele. Kështu, ne fitojmë mundësinë për të izoluara dhe testuar ndikimin e faktorëve të ndryshëm që ndikojnë në performancën e kërkesave, duke variabilizuar ato brenda një recete, dhe duke marrë rezultate nga klientët realë.
Një infrastrukturë e tillë ka rezultuar e dobishme jo vetëm për analizën e performancës së kërkesave. Në këtë moment, ne kemi 14 receta aktive, më shumë se 6000 mostra në sekondë, që marrin të dhëna nga të gjitha anët e botës dhe me mbulim të plotë të pajisjeve. Nëse Netflix do të blinte një shërbim të tillë nga kompani të jashtme, kjo do të kostonte miliona dollarë në vit, me një mbulim shumë më të dobët.
Po testojmë teorinë në praktikë: prototipi
Me një sistem të tillë kemi fituar mundësinë për të vlerësuar efikasitetin e CDN proxy në vonesën e kërkesave. Tani duhet:
- të krijojmë një prototip proxy;
- të vendosim prototipin në CDN;
- të përcaktojmë se si t'i drejtojmë klientët te proxy në një server specifik të CDN;
- të krahasojmë performancën me kërkesat në AWS pa proxy.
Detyra është të vlerësojmë sa më shpejt efektivitetin e zgjidhjes së propozuar. Për realizimin e prototipit, ne zgjodhëm Go, falë pranisë së librarive të mira për rrjet. Në çdo server CDN instaluam prototipin e proksit si një binar statik, për të minimizuar varësitë dhe për të thjeshtuar integrimin. Në implementimin fillestar, ne përdorëm maksimalisht komponentët standard dhe disa modifikime të vogla për pishinat e lidhjeve HTTP/2 dhe shumëfishe të kërkesave.
Për balancimin mes rajoneve AWS, ne përdorëm një bazë të dhënash gjeografike DNS, të njëjtën që përdoret për balancimin e klientëve. Për të zgjedhur serverin CDN për klientin, ne përdorim TCP Anycast për serverët në Internet Exchange (IX). Në këtë variant, ne përdorim një adresë IP për të gjithë serverat CDN, duke e drejtuar klientin te serveri CDN me numrin më të vogël të hoveve IP. Në serverët CDN të instaluar te ofruesit e internetit (ISP), nuk kemi kontroll mbi routerin për konfigurimin e TCP Anycast, prandaj përdorim , sipas së cilës klientët drejtohen te ofruesit e internetit për transmetimin e videove.
Pra ndaj, kemi tri lloje rrugësh për kërkesën: në cloud përmes internetit të hapur, përmes një serveri CDN në IX ose përmes një serveri CDN të vendosur te ofruesi i internetit. Qëllimi ynë është të kuptojmë se cila rrugë është më e mira dhe çfarë dobi ka proxy në krahasim me mënyrën si dërgohen kërkesat në prodhim. Për këtë, përdorim sistemin e testimeve në këtë mënyrë:
Ădo njĂ« nga rrugĂ«t bĂ«het njĂ« target i veçantĂ« dhe ne shohim kohĂ«n qĂ« kemi arritur. PĂ«r analizĂ«, bashkojmĂ« rezultatet e proxy-t nĂ« njĂ« grup (zgjedhim kohĂ«n mĂ« tĂ« mirĂ« ndĂ«rmjet proxy-t IX dhe ISP) dhe e krahasojmĂ« me kohĂ«n e kĂ«rkesave nĂ« cloud pa proxy:
Siç duket, rezultatet rezultuan të paqarta - në shumicën e rasteve, proxy-i ofron përshpejtim të mirë, por gjithashtu ka numër të mjaftueshëm të klientëve për të cilët situata do të përkeqësohet ndjeshëm.
Në fund, ne bëmë disa gjëra të rëndësishme:
- Vlerësuam performancën e pritur të kërkesave nga klientët në cloud përmes proxy-t CDN.
- Morrëm të dhëna nga klientë të vërtetë, nga të gjitha llojet e pajisjeve.
- Kuptuam se teoria nuk u konfirmua 100% dhe propozimi fillestar me proxy-t CDN për ne nuk do të funksionojë.
- Nuk kemi rrezikuar â nuk kemi ndĂ«rruar konfigurimet e production pĂ«r klientĂ«t.
- Nuk kemi prishur asgjë.
Prototipi 2.0
Pra, kthehemi përsëri në tabelën e skicave dhe përsërisim procesin nga fillimi.
Ideja Ă«shtĂ« qĂ« nĂ« vend tĂ« 100% proxy, pĂ«r secilin klient tĂ« pĂ«rcaktojmĂ« rrugĂ«n mĂ« tĂ« shpejtĂ« dhe tĂ« drejtojmĂ« kĂ«rkesat atje â domethĂ«nĂ« do tĂ« bĂ«jmĂ« atĂ« qĂ« quhet client steering.
Si ta realizojmë këtë? Nuk mund të përdorim logjikën në anën e serverit, pasi që synimi është të lidhemi me atë server. Duhet ta bëjmë këtë në anën e klientit. Dhe idealisht, ta bëjmë me sa më pak logjikë të komplikuar, për të mos pasur çështje integrimi me një sërë platformash klientësh.
PĂ«rgjigjja â pĂ«rdorimi i DNS. NĂ« rastin tonĂ«, kemi infrastrukturĂ«n tonĂ« DNS, dhe mund tĂ« konfigurojmĂ« zonĂ«n e domenit, pĂ«r tĂ« cilĂ«n serverĂ«t tanĂ« do tĂ« jenĂ« autoritarĂ«. KĂ«shtu funksionon:
- Klienti bën një kërkesë në serverin DNS duke përdorur hostin, për shembull api.netflix.xom.
- Kërkesa shkon në serverin tonë DNS
- Serveri DNS di se cila rrugë është më e shpejtë për këtë klient dhe jep adresën ip përkatëse.
Zgjidhja ka një kompleksitet shtesë: ofruesit autoritarë të DNS nuk e shohin adresën IP të klientit dhe mund të konsiderojnë vetëm adresën IP të resolverit rekursiv që përdor klienti.
Si rezultat, resolveri ynë autoritar duhet të marrë vendime jo për një klient të veçantë, por për një grup klientësh në bazë të resolverit rekursiv.
PĂ«r zgjidhjen pĂ«rdorim tĂ« njĂ«jtat prova, agregojmĂ« rezultatet e matjeve nga klientĂ«t pĂ«r çdo njĂ« nga resolverĂ«t rekursiv dhe vendosim se ku ta dĂ«rgojmĂ« kĂ«tĂ« grup â nĂ«pĂ«rmjet njĂ« proxy pĂ«rmes IX me TCP Anycast, pĂ«rmes njĂ« proxy ISP, ose drejtpĂ«rdrejt nĂ« re.
Kështu, ne kemi një sistem të tillë:
Modeli i marrë nga DNS steering lejon që të dërgojmë klientët në bazë të vëzhgimeve historike mbi shpejtësinë e lidhjeve nga klientët në re.
PĂ«rsĂ«ri, pyetja Ă«shtĂ« â sa efektiv do tĂ« funksionojĂ« ky qasje? PĂ«r tĂ« pĂ«rgjigjur, ne pĂ«rsĂ«ri pĂ«rdorim sistemin tonĂ« tĂ« provave. Prandaj, ne konfigurojmĂ« rregullimin e fundit, ku njĂ« nga targetet ndjek drejtimin e DNS steering, tjetri shkon drejtpĂ«rdrejt nĂ« re (produksioni aktual).
Si rezultat, ne krahasojmë rezultatet dhe marrim një vlerësim të efektivitetit:
Si rezultat, mësuam disa gjëra të rëndësishme:
- Vlerësuam performancën e pritur të kërkesave nga klientët për në cloud duke përdorur DNS Steering.
- Morrëm të dhëna nga klientë të vërtetë, nga të gjitha llojet e pajisjeve.
- Demonstruam efikasitetin e ideve të propozuara.
- Nuk kemi rrezikuar â nuk kemi ndĂ«rruar konfigurimet e production pĂ«r klientĂ«t.
- Nuk kemi prishur asgjë.
Tani pĂ«r tĂ« komplikuar â po e lançojmĂ« nĂ« production.
Gjëja më e lehtë tani është prapa dhe kemi një prototip funksional. Tani pjesa e vështirë është të lançojmë zgjidhjen për gjithë trafikun e Netflix, të zbatojmë për 150 milion përdorues, mijëra pajisje, qindra mikroshërbime dhe përprodukte dhe infrastrukturë që ndryshon vazhdimisht. Në serverat e Netflix vijnë miliona kërkesa në sekondë, dhe është lehtë të dëmtohet shërbimi me një veprim të pamatur. Në të njëjtën kohë, ne duam të drejtojmë trafikun dinamikisht përmes mijëra serverëve CDN, në internet, ku gjithçka ndryshon dhe dëmtohet vazhdimisht dhe në momentin më të papritur.
Dhe për të gjitha këto, në ekip kemi 3 inxhinierë përgjegjës për zhvillimin, implementimin dhe mbështetje të plotë të sistemit.
Prandaj, tani do të flasim për gjumë të qetë dhe të shëndetshëm.
Si të vazhdojmë zhvillimin, pa harxhuar të gjithë kohën në mbështetje? Në thelb të qasjes sonë qëndrojnë 3 principe:
- Ulim përmasat e mundshme të dështimeve (blast radius).
- Jemi gati pĂ«r surpriza â presim qĂ« diçka do tĂ« prishĂ«t, pavarĂ«sisht testimeve dhe pĂ«rvojĂ«s personale.
- Degenerimi gradual (graceful degradation) â nĂ«se diçka nuk funksionon siç duhet, ajo duhet tĂ« riparohen automatikisht, ndonĂ«se ndoshta jo nĂ« mĂ«nyrĂ«n mĂ« efektive.
Doli se në rastin tonë, me këtë qasje ndaj problemit, mund të gjejmë një zgjidhje të thjeshtë dhe efektive dhe të thjeshtojmë ndjeshëm mbështetje sistemin. Kuptuam se mund të shtojmë një copëz kod në klient dhe të monitorojmë gabimet e kërkesave rrjetit, të shkaktuara nga problemet e lidhjes. Njëherë kur ndodhin gabime rrjetesh, bëjmë fallback direkt në cloud. Kjo zgjidhje nuk kërkon përpjekje të mëdha nga ekipet e klientëve, por ndjeshëm zvogëlon rrezikun nga prishjet dhe surprizat e papritura për ne.
Sigurisht, pavarësisht fallback-ut, ne gjithashtu ndjekim një disiplinë të qartë gjatë zhvillimit:
- Test në mostra.
- Testimi A/B ose Canaries.
- Shpërndarje graduale (progressive rollout).
Me mostra, qasja Ă«shtĂ« pĂ«rshkruar â ndryshimet fillimisht testohet duke pĂ«rdorur njĂ« recetĂ« tĂ« vendosur.
Për testimin canary, na nevojitet të marrim palë serverësh të krahasueshme, mbi të cilat mund të përfitojmë si funksionon sistemi para dhe pas ndryshimeve. Për këtë, nga shumëfaqet tona të CDN, bëjmë një mostër të palëve të serverëve që marrin trafik të krahasueshëm:
Pastaj, ne vendosim ndërtimin me ndryshime në serverët Canary. Për të vlerësuar rezultatet, aktivizojmë një sistem që krahason rreth 100-150 metrika me mostrat e serverëve Control:
NĂ«se testimi Canary kalon me sukses, ne bĂ«jmĂ« lĂ«shimin gradualisht, nĂ« valle. NĂ« çdo njĂ« nga sitet, ne nuk i azhurnojmĂ« serverĂ«t njĂ«kohĂ«sisht â humbja e njĂ« site tĂ« tĂ«rĂ« nĂ« rast problemesh ka njĂ« ndikim mĂ« tĂ« madh nĂ« shĂ«rbimin pĂ«r pĂ«rdoruesit, sesa humbja e njĂ« sasi tĂ« njĂ«jtĂ« serverĂ«sh, por nĂ« vende tĂ« ndryshme.
Në përgjithësi, efikasiteti dhe siguria e këtij qasjeje varen nga numri dhe cilësia e metrës të mbledhura. Për sistemin tonë të përshpejtimit të kërkesave, ne mbledhim metrikë nga të gjitha komponentët e mundshëm:
- nga klientĂ«t â numri i seancave dhe kĂ«rkesave, norma e rikthimit;
- proxy â statistika mbi numrin dhe kohĂ«n e kĂ«rkesave;
- DNS â numri dhe rezultatet e kĂ«rkesave;
- cloud edge â sasia dhe koha pĂ«r pĂ«rpunimin e kĂ«rkesave nĂ« cloud.
Të gjitha këto mblidhen në një pipeline të vetëm, dhe, në varësi të nevojave, ne vendosim cilat metrika të dërgojmë në analitikën në kohë reale, dhe cilat në Elasticsearch ose Big Data për diagnoza më të detajuara.
Monitorojmë
NĂ« rastin tonĂ«, ne bĂ«jmĂ« ndryshime nĂ« rrugĂ«n kryesore tĂ« kĂ«rkesave midis klientit dhe serverit. NĂ« kĂ«tĂ« drejtim, numri i komponenteve tĂ« ndryshme nĂ« klient, nĂ« server dhe nĂ« rrugĂ«n pĂ«rmes internetit Ă«shtĂ« shumĂ« i madh. Ndryshimet nĂ« klient dhe server ndodhin vazhdimisht â gjatĂ« punĂ«s sĂ« dhjetĂ«ra ekipeve dhe ndryshimeve natyrore nĂ« ekosistemin e teknologjisĂ«. Ne jemi nĂ« mes â kur diagnostikojmĂ« probleme, ka shumĂ« mundĂ«si qĂ« ne do tĂ« jemi tĂ« pĂ«rfshirĂ«. Prandaj, na nevojitet qĂ« tĂ« kuptojmĂ« qartĂ« si tĂ« identifikojmĂ«, tĂ« mblidhemi dhe tĂ« analizohemi metrikat pĂ«r lokalizimin e shpejtĂ« tĂ« problemeve.
Ideali â qasje e plotĂ« nĂ« tĂ« gjitha llojet e metrikave dhe filtrave nĂ« kohĂ« reale. Por ka shumĂ« metrika, prandaj lind pyetja e kostos. NĂ« rastin tonĂ«, ne ndajmĂ« metrikat dhe mjetet e zhvillimit nĂ« kĂ«tĂ« mĂ«nyrĂ«:
PĂ«r identifikimin dhe triage tĂ« problemeve, ne pĂ«rdorim sistemin tonĂ« nĂ« kohĂ« reale me kod tĂ« hapur. dhe â pĂ«r vizualizimin. Ajo ruan metrikat e agreguara nĂ« memorie, Ă«shtĂ« e besueshme dhe integrohet me sistemin e alarmit. PĂ«r lokalizimin dhe diagnostikimin, kemi qasje nĂ« log-at me Elasticsearch dhe Kibana. PĂ«r analizĂ«n statistikore dhe modelimin â pĂ«rfshijmĂ« big data dhe vizualizimin nĂ« Tableau.
Duket se me njĂ« qasje tĂ« tillĂ« Ă«shtĂ« shumĂ« e komplikuar tĂ« punosh. MegjithatĂ«, me organizimin hierarhik tĂ« metrikave dhe veglave, mund tĂ« analizojmĂ« shpejt problemin, tĂ« pĂ«rcaktojmĂ« llojin e problemit dhe pastaj â tĂ« thellojmĂ« nĂ« metrikat e detajuara. PĂ«r identifikimin e burimit tĂ« defektit, nĂ« pĂ«rgjithĂ«si na duhen rreth 1-2 minuta. Pas kĂ«saj, ne punojmĂ« me ekipin e caktuar pĂ«r diagnostikimin â nga dhjetĂ«ra minuta deri nĂ« disa orĂ«.
Edhe nëse diagnostikimi bëhet shpejt, nuk duam që kjo të ndodhë shpesh. Në rastin ideal, do të marrim vetëm alarmin kritik kur ka një ndikim të rëndësishëm në shërbim. Për sistemin tonë të përshpejtimit të kërkesave, kemi vetëm 2 alarme që do të njoftojnë:
- pĂ«rqindja e Client Fallback â vlerĂ«simi i sjelljes sĂ« klientĂ«ve;
- pĂ«rqindja e Probe errors â tĂ« dhĂ«nat e qĂ«ndrueshmĂ«risĂ« sĂ« komponenteve rrjetore.
Këto alarma kritike monitorojnë nëse sistemi funksionon për shumicën e përdoruesve. Ne shohim numrin e klientëve që kanë përdorur fallback nëse nuk kanë mundur të marrin përshpejtimin e kërkesave. Mesatarisht kemi më pak se 1 alarm kritik në javë, edhe pse sistemi kalon për një sërë ndryshimesh. Pse na mjafton kjo?
- Ka një fallback klienti nëse proksi ynë nuk funksionon.
- Ka një sistem automatik steerimi që reagon ndaj problemeve.
Për më shumë detaje rreth kësaj. Sistemi ynë i prozave dhe sistemi automatik i përcaktimit të rrugës optimale për kërkesat nga klienti në cloud, lejojnë që të përballojmë automatikisht disa probleme.
Të kthehemi te konfigurimi ynë i prozave dhe 3 kategori rrugësh. Përveç kohës së ngarkesës, mund të shohim edhe faktin e dërgimit. Nëse nuk arrihet të ngarkohen të dhënat, duke vlerësuar rezultatet nga rrugë të ndryshme mund të përcaktojmë se ku dhe çfarë ka shkaktuar problemin dhe nëse mund ta rregullojmë automatikisht duke ndryshuar rrugën e kërkesës.
Shembuj:
Ky kĂ«tij procesi mund tâi jepet automatizimi. Ta pĂ«rfshijmĂ« atĂ« nĂ« sistemin e menaxhimit. Dhe ta mĂ«sojmĂ« tĂ« reagojĂ« ndaj problemeve me performancĂ«n dhe besueshmĂ«rinĂ«. NĂ«se diçka fillon tĂ« dĂ«shtojĂ« â tĂ« reagojĂ«, nĂ«se ka njĂ« opsion mĂ« tĂ« mirĂ«. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, reagimi momental nuk Ă«shtĂ« kritik, falĂ« fallback nĂ« klientĂ«.
Prandaj, parimet për mbështetje të sistemit mund të formulohet kështu:
- përmirësojmë shkallën e dëmtimeve;
- mblidhni metrika;
- automatikisht riparojmë dëmtimet, nëse mundemi;
- nĂ«se nuk mundemi â njoftojmĂ«;
- punojmë mbi dashboards dhe setet e mjeteve për triage për reagim të shpejtë.
MĂ«simet e nxjerra
PĂ«r tĂ« shkruar njĂ« prototip nuk kĂ«rkohet shumĂ« kohĂ«. NĂ« rastin tonĂ«, ai ishte gati brenda 4 muajve. Me tĂ« morĂ«m metrika tĂ« reja, dhe pas 10 muajve qĂ« nga fillimi i zhvillimit, morĂ«m trafik tĂ« parĂ« nĂ« prodhim. MĂ« pas filloi njĂ« punĂ« e lodhshme dhe shumĂ« e komplikuar: gradualisht tĂ« produktizojmĂ« dhe tĂ« shkallĂ«zojmĂ« sistemin, tĂ« migronim trafik kryesor dhe tĂ« mĂ«sonim nga gabimet. MegjithatĂ«, ky proces efikas nuk do tĂ« jetĂ« linear â pavarĂ«sisht nga tĂ« gjitha pĂ«rpjekjet, nuk mund tĂ« parashikohet çdo gjĂ«. ShumĂ« mĂ« efektive Ă«shtĂ« â itera dhe reagim tĂ« shpejtĂ« ndaj tĂ« dhĂ«nave tĂ« reja.
Duke përvojës sonë, mund të rekomandojmë sa vijon:
- Mos e besoni intuicionin.
Intuicioni ynë na ka tradhtuar përsëri e përsëri, ndonëse kemi shumë përvojë në ekip. Për shembull, parashikuam gabim përfitimin e pritur nga përdorimi i CDN proxy, ose sjelljen e TCP Anycast.
- Merrni të dhëna nga production.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« merrni sa mĂ« shpejt akses nĂ« tĂ« paktĂ«n njĂ« sasi tĂ« vogĂ«l tĂ« tĂ« dhĂ«nave nga production. Numri i rasteve unike, konfigurimeve dhe cilĂ«simeve nĂ« kushte laboratorike Ă«shtĂ« praktikisht i pamundur tĂ« arrihet. Aksesi i shpejtĂ« nĂ« rezultatet do tĂ« lejojĂ« qĂ« tĂ« mĂ«soni mĂ« shpejt pĂ«r problemet potenciale dhe t'i merrni parasysh nĂ« arkitekturĂ«n e sistemit.
- Mos ndiqni këshillat dhe rezultatet e të tjerëve - mbledhni të dhënat tuaja.
Ndihmoni parimet pĂ«r mbledhjen dhe analizĂ«n e tĂ« dhĂ«nave, por mos i merrni verbĂ«risht rezultatet dhe pretendimet e tĂ« tjerĂ«ve. VetĂ«m ju mund ta dini saktĂ«sisht se çfarĂ« funksionon pĂ«r pĂ«rdoruesit tuaj. Sistemet tuaja dhe klientĂ«t tuaj mund tĂ« jenĂ« ndjeshĂ«m ndryshe nga ato tĂ« kompanive tĂ« tjera. FatmirĂ«sisht, mjetet pĂ«r analizĂ« tani janĂ« tĂ« disponueshme dhe tĂ« lehta pĂ«r t'u pĂ«rdorur. Rezultatet qĂ« merrni mund tĂ« mos pĂ«rputhen me ato qĂ« pretendon Netflix, Facebook, Akamai dhe kompani tĂ« tjera. NĂ« rastin tonĂ«, performanca e TLS, HTTP2 apo statistikat e kĂ«rkesave DNS janĂ« tĂ« ndryshme nga rezultatet e Facebook, Uber, Akamai â sepse kemi pajisje, klientĂ« dhe flukse tĂ« dhĂ«nash tĂ« ndryshme.
- Mos ndjeki trendet e modës pa nevojë dhe vlerësim të efektivitetit.
Filloni me të thjeshtën. Më mirë të krijoni një sistem të thjeshtë funksional në një kohë të shkurtër, sesa të kaloni një sasi të madhe kohore për zhvillimin e komponenteve të panevojshme për ju. Zgjidhni problemet dhe sfidat që janë të rëndësishme bazuar në matjet dhe rezultatet tuaja.
- Jini të gatshëm për aplikime të reja.
Po aqĂ«nĂ«s, siç Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikosh tĂ« gjithĂ« problemet, ashtu Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikosh pĂ«rfitimet dhe pĂ«rdorimet e tij. Merrni shembull nga startup-Ă«t â aftĂ«sia e tyre pĂ«r t'u adaptuar ndaj kushteve tĂ« klientĂ«ve. NĂ« rastin tuaj, ju mund tĂ« zbuloni probleme tĂ« reja dhe zgjidhjet e tyre. NĂ« projektin tonĂ«, vendosĂ«m si qĂ«llim reduktimin e vonesave nĂ« kĂ«rkesa. MegjithatĂ«, gjatĂ« analizĂ«s dhe diskutimeve, kuptuam se mund tĂ« pĂ«rdorim serverĂ«t proxy gjithashtu:
- për balancimin e trafikut në regjionet të AWS dhe për uljen e kostove;
- për modelimin e stabilitetit të CDN;
- për konfiguarimin e DNS;
- për konfiguarimin e TLS/TCP.
PĂ«rfundimi
Në raport, unë përshkrova se si Netflix e zgjidh problemin e përshpejtimit të kërkesave të internetit midis klientëve dhe cloud-it. Si mblidhemi të dhënat nëpërmjet sistemit të mostrave te klientët dhe si i përdorim të dhënat historike të mbledhura për të drejtuar kërkesat në production nga klientët përmes rrugës më të shpejtë në internet. Si i përdorim principe të protokolleve rrjetore, infrastrukturën tonë CDN, rrjetin backbone dhe serverat DNS për arritjen e këtij qëllimi.
MegjithatĂ«, zgjidhja jonĂ« Ă«shtĂ« vetĂ«m njĂ« shembull se si ne nĂ« Netflix e kemi zbatuar njĂ« sistem tĂ« tillĂ«. ĂfarĂ« ka funksionuar pĂ«r ne. Pjesa praktike e prezantimit tim pĂ«r ju Ă«shtĂ« parimet e zhvillimit dhe mbĂ«shtetjes, qĂ« ndjekim dhe arijmĂ« rezultate tĂ« mira.
Zgjidhja jonë për problematiken tuaj mund të mos jetë e përshtatshme. Megjithatë, teoria dhe principe e zhvillimit mbeten, edhe nëse nuk keni një infrastrukturë CDN të vetën, ose nëse ajo është ndjeshëm ndryshe nga e jona.
Po ashtu mbetet rëndësia e shpejtësisë së kërkesave për biznesin. Dhe madje për një shërbim të thjeshtë duhet të bëni zgjedhjen: ndërmjet ofruesve 'cloud', vendndodhjes së serverëve, CDN dhe ofruesve të DNS. Zgjedhja juaj do të ndikojë në efikasitetin e kërkesave në internet për klientët tuaj. Dhe për ju është e rëndësishme që ky ndikim ta matni dhe ta kuptoni.
Filloni me zgjidhje të thjeshta, kujdesuni për atë se si e ndryshoni produktin. Mësoni gjatë procesit dhe përmirësoni sistemin bazuar në të dhënat nga klientët tuaj, infrastruktura juaj dhe biznesi juaj. Mendoni për mundësinë e prishjeve të papritura gjatë dizajnimit. Kështu do të jeni në gjendje të shpejtoni procesin tuaj të zhvillimit, përmirësoni efikasitetin e zgjidhjes, shmangni ngarkesën e tepërt në mbështetje dhe flini qetë.
Këtë vit në format online. Do të jetë e mundur të bëni pyetje njërit nga baballarët e DevOps, vetë John Willisit!
Burimi: habr.com
