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
