Netflix është lideri i tregut të televizionit në internet, kompania që e krijoi dhe e zhvillon aktivisht këtë segment. Netflix është i njohur jo vetëm për katalogun e gjerë të filmave dhe serive, të disponueshëm nga pothuajse çdo kënd të planetit dhe çdo pajisje me ekran, por edhe për infrastrukturen e besueshme dhe kulturën unike inxhinierike.
NjĂ« shembull i qartĂ« i qasjes sĂ« Netflix nĂ« zhvillimin dhe mbĂ«shtetjen e sistemeve tĂ« komplikuara nĂ« DevOops 2019 Ă«shtĂ« paraqitur nga â drejtor i zhvillimit nĂ« Netflix. Diplomuar nĂ« Fakultetin e Shkencave Natyrore tĂ« Universitetit tĂ« Nizhny Novgorod, Sergei Ă«shtĂ« njĂ« nga inxhinierĂ«t e parĂ« nĂ« Open Connect â ekipin CDN nĂ« Netflix. Ai ndihmoi nĂ« ndĂ«rtimin e sistemeve tĂ« monitorimit dhe analizĂ«s sĂ« tĂ« dhĂ«nave tĂ« videove, lançooi shĂ«rbimin e njohur pĂ«r vlerĂ«simin e shpejtĂ«sisĂ« sĂ« lidhjes nĂ« internet FAST.com dhe gjatĂ« disa viteve tĂ« fundit ka punuar pĂ«r optimizimin e kĂ«rkesave nĂ« internet, pĂ«r tĂ« bĂ«rĂ« qĂ« aplikacioni Netflix tĂ« funksionojĂ« sa mĂ« shpejt pĂ«r pĂ«rdoruesit.
Diskutimi mori komente të shkëlqyera nga pjesëmarrësit e konferencës, dhe ne kemi përgatitur një version të shkruar për ju.
Në diskutim, Sergei tregoi hollësisht
- çfarë ndikon në vonesën e kërkesave në internet mes klientit dhe serverit;
- si të reduktoni këtë vonesë;
- si të projektoni, mbani dhe monitoroni sistemi që janë të qëndrueshëm ndaj gabimeve;
- si të arrini rezultate në kohë të shkurtër dhe me rrezik minimal për biznesin;
- si të analizoni rezultatet dhe të mësoni nga gabimet.
Përgjigjet në këto pyetje janë të nevojshme jo vetëm për ata që punojnë në korporata të mëdha.
Parimet dhe teknikat e paraqitura duhet t'i dijë dhe t'i praktikojë çdo njëri që zhvillon dhe mban produkte në internet.
MĂ« poshtĂ« â njĂ« tregim nga pikĂ«pamja e folĂ«sit.
Rëndësia e shpejtësisë së internetit
Shpejtësia e kërkesave në internet është direkt e lidhur me biznesin. Le të shqyrtojmë fushën e tregtisë: kompania Amazon në vitin 2009 , që një vonesë prej 100 ms shkakton humbjen e 1% të shitjeve.
Po rritet numri i pajisjeve mobile, dhe si pasojë, i faqeve dhe aplikacioneve mobile. Nëse faqja juaj ngarkohet më gjatë se 3 sekonda, humbni rreth gjysmën e përdoruesve. Nga Google merr parasysh shpejtësinë e ngarkimit të 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 në organizatat financiare, ku vonesa është kritike. Në vitin 2015, kompania Hibernia Networks kabllin e kabllit midis Nju Jorkut dhe Londrës me një çmim prej 400 milion dollarësh, për të reduktuar vonesën midis qyteteve me 6 ms. Imagjinoni, 66 milion dollarë për 1 ms reduktim vonese!
Sipas , shpejtësia e lidhjes mbi 5 Mbps ndalon të ndikojë drejtpërdrejt në shpejtësinë e ngarkesës së një faqeje tipike. Megjithatë, ekziston një varësi lineare midis vonesës së lidhjes dhe shpejtësisë së ngarkesës së faqes:
Megjithatë, Netflix nuk është një produkt tipik. Ndikimi i vonesës dhe shpejtësisë te përdoruesi është një fushë aktive analize dhe zhvillimi. Ka ngarkesë aplikacionesh dhe zgjedhje përmbajtjeje, që varen nga vonesa, por ngarkesat e 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ë sferë aktive zhvillimi për disa ekipe në Netflix. Një nga objektivat është reduktimi i vonesës së kërkesave midis pajisjeve Netflix dhe infrastrukturës në cloud.
Në këtë raport ne do të fokusohemi pikërisht në reduktimin e vonesës (latency) duke marrë si shembull infrastrukturën e Netflix. Do të shikojmë nga një këndvështrim praktik se si t'i qasemi proceseve të projektimit, zhvillimit dhe operimit të sistemeve të shpërndara komplekse dhe të shpenzojmë kohë në inovacione dhe rezultate, e jo në diagnostikimin e problemeve operative dhe prishjeve.
Brenda Netflix
Mijëra pajisje të ndryshme mbështesin aplikacionet e Netflix. Zhvillimi i tyre bëhet nga katër ekipe të ndryshme, të cilat krijojnë versione të veçanta të klientit për Android, iOS, TV dhe shfletuesin web. Dhe ne kemi shpenzuar shumë energji për të përmirësuar dhe personalizuar ndërfaqen e përdoruesit. Për këtë, ne realizojmë paralelisht qindra teste A/B.
Personalizimi mbështetet nga qindra mikroshërbimesh në cloud AWS, që ofrojnë të dhëna të personalizuara për përdoruesin, menaxhimin e kërkesave, telemetrinë, Big Data dhe Encoding. Vizualizimi i trafikëve duket kështu:
Në majtas është pika e hyrjes, dhe pastaj trafiku shpërndahet midis disa qindra mikroshërbimeve, të cilat mbështeten nga ekipe të ndryshme backend.
NjĂ« komponent tjetĂ«r i rĂ«ndĂ«sishĂ«m i infrastrukturĂ«s tonĂ« Ă«shtĂ« Open Connect CDN, i cili shpĂ«rndan pĂ«rmbajtjen statike te pĂ«rdoruesi pĂ«rfundimtar â video, imazhe, kode pĂ«r klientĂ«t etj. CDN Ă«shtĂ« vendosur nĂ« serverĂ« tĂ« personalizuar (OCA â Open Connect Appliance). Brenda saj ka grupe SSD dhe HDD nĂ«n menaxhimin e FreeBSD tĂ« optimizuar, me NGINX dhe njĂ« set shĂ«rbimesh. Ne projektojmĂ« dhe optimizojmĂ« komponentĂ«t harduerikĂ« dhe softuerikĂ« nĂ« mĂ«nyrĂ« qĂ« njĂ« 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 shkĂ«mbimit tĂ« trafikut internet (Internet eXchange â IX), duket kĂ«shtu:
Internet Exchange ofron mundësinë që 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 instalimin dhe mirëmbajtjen e tyre:
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 te serverĂ«t CDN, si dhe konfigurimin e vetĂ« serverĂ«ve â pĂ«rditĂ«simi i pĂ«rmbajtjes, kodit tĂ« programit, konfigurimeve etj. PĂ«r kĂ«tĂ« tĂ« fundit, ne gjithashtu ndĂ«rtuam njĂ« rrjet backbone, i cili lidh serverĂ«t nĂ« pikat e Internet Exchange me AWS. Rrjeti backbone pĂ«rbĂ«n njĂ« rrjet global kabllor me fibra optike dhe routera, tĂ« cilĂ«t mund tâi projektojmĂ« dhe konfigurim sipas nevojave tona.
Sipas , infrastruktura jonĂ« CDN dĂ«rgon nĂ« orĂ«t e pikut rreth â e trafikut global tĂ« internetit dhe â tĂ« trafikut nĂ« AmerikĂ«n e Veriut, ku Netflix Ă«shtĂ« i pranishĂ«m mĂ« shumĂ« kohĂ«. Numra mbresĂ«lĂ«nĂ«s, por pĂ«r mua njĂ« nga arritjet mĂ« tĂ« habitshme Ă«shtĂ« se e gjithĂ« sistemi CDN Ă«shtĂ« e zhvilluar dhe mbajtur nga njĂ« ekip prej mĂ« pak se 150 personash.
Në fillim, infrastruktura CDN ishte projektuar për të dërguar të dhënat video. Megjithatë, me kalimin e kohës ne e kuptuam se mund ta përdorim atë gjithashtu për optimizimin e kërkesave dinamike nga klientët në cloud-in AWS.
Për përshpejtimin e internetit
Sot ndodhet Netflix nĂ« 3 rajone AWS, dhe vonesa e kĂ«rkesave nĂ« nube do tĂ« varet nga sa larg ndodhet klienti nga rajoni mĂ« i afĂ«rt. MegjithatĂ«, ne kemi shumĂ« serverĂ« CDN, qĂ« pĂ«rdoren pĂ«r shpĂ«rndarjen e pĂ«rmbajtjes statike. A mund ta pĂ«rdorim ndonjĂ« mĂ«nyrĂ« kĂ«tĂ« infrastrukturĂ« pĂ«r tĂ« pĂ«rshpejtuar kĂ«rkesat dinamike? MegjithatĂ«, me keqardhje, nuk mund tĂ« keqinterpretohen kĂ«to kĂ«rkesa â API-tĂ« janĂ« tĂ« personalizuara dhe çdo rezultat Ă«shtĂ« unik.
Le të bëjmë një proxy në serverin CDN dhe të fillojmë të kalojmë trafik përmes tij. A do të jetë kjo më e shpejtë?
Materiali
Le të rikujtojmë se si funksionojnë protokollet rrjetike. Sot, pjesa më e madhe e trafikut në internet përdor HTTPs, që varet nga protokollet e nivelit të poshtëm 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 tre herë dhe më pas 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, do të na duhen 400 ms për të marrë bitin e parë të të dhënave:
Nëse certifikatat e vendosim në serverin CDN, atëherë koha e "ruppozit" midis klientit dhe serverit mund të shkurtohet ndjeshëm, nëse CDN është më afër. Le të supozojmë se vonesa deri në serverin CDN është 30 ms. Atëherë, për të marrë bitin e parë do të kërkohen tashmë 220 ms:
Por avantazhet nuk përfundojnë këtu. Pasi lidhja është vendosur, TCP rrit dritaren e trafikimit (sasia e informacionit që mund të transmetohet përmes kësaj lidhjeje në parallel). Nëse humbet një paketë të dhënash, zbatimet klasike të protokollit TCP (si TCP New Reno) e zvogëlojnë dritaren e hapur me gjysmë. Rritja e dritares së trafikimit dhe shpejtësia e rimëkëmbjes nga humbja përsëri varet nga vonesa (RTT) deri në server. Nëse kjo lidhje shkon vetëm deri në serverin CDN, kjo rimëkëmbje do të jetë më e shpejtë. Në këtë rast, humbja e paketave është një fenomen standard, veçanërisht për rrjetet wireless.
Kapaciteti i internetit mund tĂ« ulen, veçanĂ«risht nĂ« orĂ«t e pikut pĂ«r shkak tĂ« trafikut nga pĂ«rdoruesit, gjĂ« qĂ« mund tĂ« çojĂ« nĂ« "tĂ« ngjeshura". NĂ« kĂ«tĂ« rast, nuk ka mĂ«nyrĂ« nĂ« internet pĂ«r tĂ« dhĂ«nĂ« prioritet disa kĂ«rkesave nĂ« krahasim me tĂ« tjerat. PĂ«r shembull, pĂ«r tĂ« dhĂ«nĂ« prioritet kĂ«rkesave tĂ« vogla nĂ« volum dhe tĂ« ndjeshme ndaj vonesĂ«s nĂ« krahasim me "rrjedhat e mĂ«dha" tĂ« tĂ« dhĂ«nave, tĂ« cilat e ngarkojnĂ« rrjetin. MegjithatĂ«, nĂ« rastin tonĂ«, prania e njĂ« rjeti backbone tĂ« vetin e bĂ«n kĂ«tĂ« tĂ« mundur nĂ« njĂ« pjesĂ« tĂ« rrugĂ«s sĂ« kĂ«rkesĂ«s â mes CDN dhe cloud-it, dhe ne mund ta konfigurojmĂ« plotĂ«sisht atĂ«. Mund tĂ« bĂ«jmĂ« nĂ« mĂ«nyrĂ« qĂ« paketat e vogla dhe tĂ« ndjeshme ndaj vonesĂ«s tĂ« kenĂ« prioritet, ndĂ«rsa rrjedhat e mĂ«dha tĂ« tĂ« dhĂ«nave tĂ« shkojnĂ« pak mĂ« vonĂ«. Sa mĂ« afĂ«rt tĂ« jetĂ« CDN me klientin, aq mĂ« e madhe Ă«shtĂ« efikasiteti.
NjĂ« tjetĂ«r ndikim mbi vonesĂ«n kanĂ« protokollet e nivelit tĂ« aplikacionit (OSI Nivel 7). Protokolle tĂ« reja, si HTTP/2, lejojnĂ« optimizimin e performancĂ«s sĂ« kĂ«rkesave paralele. MegjithatĂ«, kemi Netflix si 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 nĂ« mĂ«nyrĂ« optimale. NĂ« kĂ«tĂ« rast, mes CDN proxy dhe cloud-it â Ă«shtĂ« kontrolli i plotĂ« dhe mundĂ«sia pĂ«r tĂ« pĂ«rdorur protokollet dhe konfigurimet mĂ« tĂ« reja dhe optimale. Pjesa joefikase me protokollet e vjetra do tĂ« funksionojĂ« vetĂ«m mes klientit dhe serverit CDN. MĂ« shumĂ« se kaq, ne mund tĂ« bĂ«jmĂ« multiplexing tĂ« kĂ«rkesave nĂ« njĂ« lidhje tashmĂ« tĂ« vendosur mes CDN dhe cloud-it, duke pĂ«rmirĂ«suar shfrytĂ«zimin e lidhjes nĂ« nivelin TCP:
TĂ« masim
Megjithëse teoria premton përmirësime, ne nuk shkojmë menjëherë për të lançuar sistemin në production. Në vend të kësaj, duhet së pari të dëshmojmë se ideja do të funksionojë në praktikë. Për këtë, duhet të përgjigjemi ndaj 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 shtesĂ«?
Le të shqyrtojmë me kujdes qasjen tonë ndaj vlerësimit të pikës së parë. Pikat e tjera shqyrtohen në mënyrë të ngjashme.
Për të analizuar shpejtësinë e kërkesave, duam të marim të dhëna për të gjithë përdoruesit, pa shpenzuar shumë kohë në zhvillim dhe pa prishur production. Për këtë, ka disa qasje:
- RUM, ose matja pasive e kërkesave. Ne matim kohën e ekzekutimit të kërkesave aktuale nga përdoruesit dhe sigurojmë mbulimin e plotë të përdoruesve. Disavantazhi është se 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 klient. Përveç kësaj, nuk është e mundur të testohet një konfigurim i ri pa ndikuar në prodhim.
- Testet laboratorike. Serverë dhe infrastrukturë të posaçme që simulojnë klientët. Me ndihmën e tyre kryejmë testet e nevojshme. Kështu marrim kontroll të plotë mbi rezultatet e matjeve dhe një sinjal të qartë. Megjithatë, nuk kemi një mbulim të plotë të pajisjeve dhe vendndodhjes së përdoruesve (sidomos me shërbime të gjithë botës dhe mbështetje për mijëra modele pajisjesh).
Si mund të bashkojmë përfitimet e të dy metodave?
Ekipi ynĂ« gjeti njĂ« zgjidhje. Ne shkruam njĂ« copĂ« kod â njĂ« mostĂ«r â tĂ« cilĂ«n e integromĂ« nĂ« aplikacionin tonĂ«. Mostrat na lejojnĂ« tĂ« bĂ«jmĂ« teste rrjetesh plotĂ«sisht tĂ« kontrolluara nga pajisjet tona. KĂ«shtu funksionon:
- Shpejt pas ngarkimit të aplikacionit dhe përfundimit të aktiviteteve fillestare, ne aktivizojmë mostrën tonë.
- Klienti bĂ«n njĂ« kĂ«rkesĂ« nĂ« server dhe merr njĂ« "recetĂ«" testi. Receta pĂ«rbĂ«het nga njĂ« listĂ« URL-esh, pĂ«r tĂ« cilat duhet tĂ« bĂ«jmĂ« njĂ« kĂ«rkesĂ« HTTP(s). PĂ«rveç kĂ«saj, receta konfiguron parametrat e kĂ«rkesave: vonesat midis kĂ«rkesave, volumet e tĂ« dhĂ«nave tĂ« kĂ«rkuara, HTTP(s) headers, etj. NĂ« kĂ«tĂ« mĂ«nyrĂ«, ne mund tĂ« testojmĂ« disa receta tĂ« ndryshme paralelisht â gjatĂ« kĂ«rkesĂ«s pĂ«r konfigurimin ne pĂ«rzgjidhen rastĂ«sisht se cila recetĂ« do t'u jepet.
- Koha e aktivizimit të mostrës zgjidhet në mënyrë që të mos krijohet konflikt me përdorimin aktiv të burimeve rrjetore nga klienti. Në thelb, zgjedhim një kohë kur klienti nuk është aktiv.
- Pas marrjes sĂ« recetĂ«s, klienti bĂ«n kĂ«rkesa nĂ« secilĂ«n nga URL-tĂ«, paralelisht. KĂ«rkesa nĂ« secilĂ«n adresĂ« mund tĂ« pĂ«rsĂ«ritet â tĂ« ashtuquajturat "pulsa". NĂ« pulsin e parĂ« matim se sa kohĂ« ka marrĂ« pĂ«r tĂ« vendosur lidhjen dhe shkarkuar tĂ« dhĂ«nat. NĂ« pulsin e dytĂ« matim kohĂ«n e ngarkimit tĂ« tĂ« dhĂ«nave pĂ«rmes lidhjes tashmĂ« tĂ« vendosur. Para pulsin tĂ« tretĂ«, ne mund tĂ« vendosim njĂ« vonesĂ« dhe tĂ« matim shpejtĂ«sinĂ« e vendosjes sĂ« lidhjes sĂ« ripĂ«rsĂ«ritur etj.
Gjatë testit ne masim të gjitha parametrat që mund të marrë pajisja:
- koha e kërkesës DNS;
- koha e vendosjes së lidhjes TCP;
- koha e vendosjes së lidhjes TLS;
- koha për të marrë bajtin e parë të të dhënave;
- koha totale e ngarkesës;
- statusi i kodit të rezultatit.
- Pas përfundimit të të gjitha impulsave, proba ngarkon rezultatet e të gjitha matjeve për analizë.
Pikat kryesore janë varësia minimale nga logjika në klient, përpunimi i të dhënave në server dhe matja e kërkesave paralele. Kështu, ne fitojmë mundësinë të izolojmë dhe të testojmë ndikimin e faktorëve të ndryshëm që ndikojnë në performancën e kërkesave, t'i ndryshojmë ato brenda një recete, dhe të marrim rezultate nga klientë të vërtetë.
Kjo infrastrukturë ka provuar të jetë e dobishme jo vetëm për analizë të performancës së kërkesave. Aktualisht, ne kemi 14 receta aktive, më shumë se 6000 proba në sekondë, që marrin të dhëna nga të gjitha cepet e botës dhe me mbulim të plotë të pajisjeve. Nëse Netflix do të blente një shërbim të tillë nga kompani të jashtme, do të kushtonte miliona dollarë në vit, me mbulim shumë më të keq.
Kthejmë teorinë në praktikë: prototipi
Me një sistem të tillë arritëm të vlerësojmë efikasitetin e proxy-së CDN mbi vonesat 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 tĂ« caktuar CDN;
- të krahasojmë performancën me kërkesat në AWS pa proxy.
Detyra është të vlerësojmë sa më shpejt efikasitetin e zgjidhjes së propozuar. Për realizimin e prototipit zgjodhëm Go, falë bibliotekave të mira të rrjetit. Në çdo server CDN instaluam prototipin e proxy si një binar statik, për të minimalizuar varësitë dhe për të thjeshtuar integrimin. Në realizimin fillestar përdorëm sa më shumë që mundëm komponentët standardë dhe disa modifikime për pooling të lidhjeve HTTP/2 dhe shumëkërkesa.
Për të balancuar midis rajoneve të 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, 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ë serverët CDN, duke e orientuar klientin drejt serverit CDN me numrin më të vogël të IP hops. Në serverët CDN të vendosur tek ofruesit e internetit (ISP), ne nuk kemi kontroll mbi routerin për të konfiguruar TCP Anycast, prandaj angazhojmë , sipas së cilës klientët orientohen te ofruesit e internetit për transmetim video.
Pra, kemi tre lloje rrugësh për kërkesën: në cloud përmes internetit të hapur, përmes serverit CDN në IX, ose përmes serverit CDN të vendosur te ofruesi i internetit. Qëllimi ynë është të kuptojmë cila rrugë është më e mirë dhe çfarë dobie ka nga proksi, krahasuar me mënyrën se si kërkesat janë orientuar në prodhim. Për këtë, përdorim sistemin e provave në këtë mënyrë:
Ădo njĂ« nga rrugĂ«t bĂ«het njĂ« objektiv i veçantĂ«, dhe ne shikojmĂ« kohĂ«n qĂ« kemi arritur. PĂ«r analizĂ«, bashkojmĂ« rezultatet e proksit nĂ« njĂ« grup (zgjedhim kohĂ«n mĂ« tĂ« mirĂ« midis proksit IX dhe ISP) dhe e krahasojmĂ« me kohĂ«n e kĂ«rkesave nĂ« cloud pa proksi:
Siç duket, rezultatet ishin tĂ« paqarta â nĂ« shumicĂ«n e rasteve, proksi ofron njĂ« pĂ«rshpejtim tĂ« mirĂ«, por gjithashtu ka mjaft klientĂ« pĂ«r tĂ« cilĂ«t situata do tĂ« pĂ«rkeqĂ«sohej ndjeshĂ«m.
Si rezultat, 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 proksit CDN.
- Morrëm të dhëna nga klientë të vërtetë, nga të gjitha llojet e pajisjeve.
- E kuptuam se teoria nuk u konfirmua 100% dhe propozimi fillestar me proksi CDN nuk funksionoi për ne.
- Nuk rrezikuam â nuk ndryshuam konfigurimet e prodhimit pĂ«r klientĂ«t.
- Nuk thyem asgjë.
Prototipi 2.0
Pra, kthehemi në tavolinën e hartimit dhe përsërisim procesin nga fillimi.
Ideja Ă«shtĂ« qĂ«, nĂ« vend tĂ« 100% proksit, pĂ«r çdo klient tĂ« pĂ«rcaktojmĂ« rrugĂ«n mĂ« tĂ« shpejtĂ« dhe tĂ« drejtojmĂ« kĂ«rkesat aty â dmth. do tĂ« bĂ«jmĂ« atĂ« qĂ« quhet klienti orientimi.
Si e realizohet kjo? Ne nuk mund të përdorim logjikën në anën e serverit, pasi që qëllimi është të lidhemi me këtë server. Duhet ta bëjmë këtë në klient, dhe idealisht me sa më pak logjikë komplekse që të mos kemi nevojë të zgjidhim çështjen e integrimit me një numër të madh platformash klientësh.
Zgjidhja është përdorimi i DNS. Në rastin tonë, ne kemi infrastrukturën tonë DNS dhe mund të konfigurim zonën domene për të cilën serverët tanë do të jenë autoritarë. Kjo funksionon kështu:
- Klienti bën një kërkesë ndaj serverit DNS duke përdorur host-in, për shembull api.netflix.com.
- Kërkesa arrin në serverin tonë DNS
- Serveri DNS e di se cili është rrugë për këtë klienti më e shpejtë dhe jep adresën përkatëse IP.
Në zgjidhje ka një kompleksitet shtesë: ofruesit e DNS autoritarë nuk e shohin adresën IP të klientit dhe mund të shohin vetëm adresën IP të resolver-it rekursiv që përdoret nga klienti.
Përfundimisht, resolver-i ynë autoritar duhet të marrë vendimin jo për një klient të veçantë, por për një grup klientësh në bazë të resolver-it rekursiv.
PĂ«r zgjidhjen e kĂ«saj ne pĂ«rdorim tĂ« njĂ«jtat proba, agregojmĂ« rezultatet e matjeve nga klientĂ«t pĂ«r çdo resolver rekursiv dhe vendosim se ku ta drejtojmĂ« kĂ«tĂ« grup â pĂ«rmes proxy-it pĂ«rmes IX me TCP Anycast, pĂ«rmes ISP proxy ose direkt nĂ« cloud.
Ne marrim një sistem të tillë:
Modeli i marrë DNS steering lejon të drejtojë klientët në bazë të vëzhgimeve historike të shpejtësive të lidhjeve nga klientët deri në cloud.
Edhe njĂ« herĂ«, çështja Ă«shtĂ« â sa efektiv do tĂ« funksionojĂ« njĂ« qasje e tillĂ«? PĂ«r t'u pĂ«rgjigjur, ne pĂ«rsĂ«ri pĂ«rdorim sistemin tonĂ« tĂ« mostrave. KĂ«shtu, ne konfigurajmĂ« njĂ« konfigurim tĂ« fundit, ku njĂ« nga targetet ndjek drejtimin nga DNS steering, tjetri shkon direkt nĂ« cloud (produksioni aktual).
Në fund, 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 në cloud duke përdorur DNS Steering.
- Morrëm të dhëna nga klientë të vërtetë, nga të gjitha llojet e pajisjeve.
- Demonstruam efektivitetin e ideve të propozuara.
- Nuk rrezikuam â nuk ndryshuam konfigurimet e prodhimit pĂ«r klientĂ«t.
- Nuk thyem asgjë.
Tani pĂ«r tĂ« vĂ«shtirĂ«n â e vendosim nĂ« produkte.
TĂ« keqijat mĂ« tĂ« lehta tani janĂ« mbrapa â kemi njĂ« prototip funksional. Tani pjesa e vĂ«shtirĂ« Ă«shtĂ« tĂ« fillojmĂ« zgjidhjen pĂ«r tĂ« gjithĂ« trafikun e Netflix-it, ta implementojmĂ« pĂ«r 150 milion pĂ«rdorues, mijĂ«ra aparate, qindra mikro-shĂ«rbime dhe produkte dhe infrastrukturĂ« qĂ« ndryshon vazhdimisht. NĂ« serverat e Netflix po vijnĂ« miliona kĂ«rkesa nĂ« sekondĂ« dhe mund tĂ« dĂ«mtohet lehtĂ«sisht shĂ«rbimi nga njĂ« veprim i papĂ«rgjegjshĂ«m. MegjithatĂ«, ne duam tĂ« drejtojmĂ« trafik dinamikisht pĂ«rmes mijĂ«ra serverĂ«ve CDN, nĂ« internet, ku diçka ndryshon dhe prishet vazhdimisht nĂ« momentin mĂ« tĂ« papĂ«rshtatshĂ«m.
Dhe në të gjithë këtë, në ekip janë 3 inxhinierë, të përgjegjshëm për zhvillimin, implementimin dhe mbështetje të plotë të sistemit.
Prandaj, tani do flasim për gjumin e qetë dhe të shëndetshëm.
Si të vazhdojmë zhvillimin, pa e shpenzuar tërë kohën në mbështetje? Në bazë të qasjes tonë, janë 3 parime:
- Ulin rrezikun e mundshëm të defekteve (blast radius).
- Jemi tĂ« pĂ«rgatitur pĂ«r surpriza â presim qĂ« diçka do tĂ« prishet, pavarĂ«sisht nga testimi dhe pĂ«rvoja personale.
- Degenerimi i gradualt (graceful degradation) - nëse diçka nuk funksionon si duhet, ajo duhet të riparojë automatikisht, ndoshta në një mënyrë jo shumë efikase.
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ështetjen e sistemit. Ne kuptuam se mund të shtojmë një copëz të vogël kodi te klienti dhe të monitorojmë gabimet në kërkesat rrjetore që shkaktohen nga probleme me lidhjen. Në rastin e dëmtimeve në rrjet, bëjmë fallback direkt në re. Ky zgjidhje nuk kërkon përpjekje të mëdha nga ekipet e klientëve, por ndjeshëm ul rrezikun nga dështimet dhe surprizat e papritura për ne.
Sigurisht, përkundër fallback-ut, ne megjithatë ndjekim një disiplinë të qartë gjatë zhvillimit:
- Testi në prova.
- TĂ« testuar A/B ose Canaries.
- Shpërndarje graduale (progressive rollout).
Për provat, qasja është përshkruar - ndryshimet testohen fillimisht përmes një recepti të konfiguruar.
Për testimin canary, na nevojiten çiftet e serverëve për t'u krahasuar se si funksionon sistemi para dhe pas ndryshimeve. Për këtë, nga shumë site tonat CDN, ne bëjmë një mostër të çift serverësh që marrin trafik të krahasueshëm:
Pastaj ne vendosim ndërtimin me ndryshime në serverat Canary. Për të vlerësuar rezultatet, nisëm një sistem që përcakton përafërsisht 100-150 metrika me një grup Kontrol:
NĂ«se testimi i Canary-it kalon me sukses, ne bĂ«jmĂ« publikimin nĂ« mĂ«nyrĂ« graduale, nĂ« valĂ«. NĂ« secilin nga faqet, ne nuk pĂ«rditĂ«sojmĂ« serverat njĂ«kohĂ«sisht â humbja e njĂ« faqeje tĂ« tĂ«rĂ« nĂ« rast problemesh ka njĂ« ndikim mĂ« tĂ« madh pĂ«r shĂ«rbimin pĂ«r pĂ«rdoruesit, sesa humbja e tĂ« njĂ«jtit numĂ«r serverash, por nĂ« vende tĂ« ndryshme.
Në përgjithësi, efikasiteti dhe siguria e këtij qasjes varen nga numri dhe cilësia e metrikave të mbledhura. Për sistemin tonë të përshpejtimit të kërkesave, ne mbledhim metrika nga të gjitha komponentët e mundshëm:
- nga klientĂ«t â numri i sesioneve dhe kĂ«rkesave, norma e rĂ«nies;
- proxy â statistika mbi numrin dhe kohĂ«n e kĂ«rkesave;
- DNS â numri dhe rezultatet e kĂ«rkesave;
- cloud edge â numri dhe koha e pĂ«rpunimit tĂ« kĂ«rkesave nĂ« cloud.
TĂ« gjitha kĂ«to mblidhen nĂ« njĂ« pipeline tĂ« vetĂ«m, dhe, nĂ« varĂ«si tĂ« nevojave, ne vendosim se cilat metrika tĂ« dĂ«rgojmĂ« pĂ«r analitikĂ« nĂ« kohĂ« reale, dhe cilat â nĂ« Elasticsearch ose Big Data pĂ«r diagnostikim mĂ« tĂ« detajuar.
Monitorojmë
NĂ« rastin tonĂ«, bĂ«jmĂ« ndryshime nĂ« rrugĂ«n kritike tĂ« kĂ«rkesave midis klientit dhe serverit. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, numri i komponentĂ«ve tĂ« ndryshĂ«m nĂ« klient, nĂ« server dhe nĂ« rrugĂ«n pĂ«rmes internetit â Ă«shtĂ« i madh. Ndryshimet nĂ« klient dhe server ndodhin vazhdimisht â gjatĂ« punĂ«s sĂ« dhjetra ekipeve dhe ndryshimeve natyrore nĂ« ekosistem. Ne jemi nĂ« mes â gjatĂ« diagnostikimit tĂ« problemeve ka njĂ« mundĂ«si tĂ« madhe qĂ« ne do tĂ« jemi tĂ« pĂ«rfshirĂ« nĂ« kĂ«tĂ«. Prandaj, na nevojitet njĂ« kuptim i qartĂ« pĂ«r si tĂ« pĂ«rcaktojmĂ«, mbledhim dhe analizojmĂ« metrikat pĂ«r lokalizimin e shpejtĂ« tĂ« problemeve.
Idealisht â qasje e plotĂ« nĂ« tĂ« gjitha llojet e metrikave dhe filtrave nĂ« kohĂ« reale. Por ka shumĂ« metrika, kĂ«shtu qĂ« lind pyetja e kostos. NĂ« rastin tonĂ«, ne ndajmĂ« metrikat dhe mjetet e zhvillimit si mĂ« poshtĂ«:
PĂ«r zbulesĂ«n dhe triage-n e problemeve, ne pĂ«rdorim sistemin tonĂ« real-time me kod tĂ« hapur dhe â pĂ«r vizualizim. Ajo ruan metrikat e agreguara nĂ« memorie, Ă«shtĂ« e besueshme dhe integrohet me sistemin e alarmit. PĂ«r lokalizimin dhe diagnostikimin, kemi qasje nĂ« logjet nga Elasticsearch dhe Kibana. PĂ«r analizĂ«n statistikore dhe modelimin â angazhojmĂ« big data dhe vizualizimin nĂ« Tableau.
Duket se me njĂ« qasje tĂ« tillĂ« Ă«shtĂ« shumĂ« e vĂ«shtirĂ« tĂ« punosh. MegjithatĂ«, me organizimin hierarkik tĂ« metrikave dhe mjeteve, ne mund tĂ« analizojmĂ« shpejt problemin, tĂ« pĂ«rcaktojmĂ« llojin e problemit dhe pastaj tĂ« thellohemi nĂ« metrikat e detajuara. PĂ«r tĂ« identifikuar burimin e defektit, ne pĂ«rgjithĂ«sisht harxhojmĂ« rreth 1-2 minuta. Pas kĂ«saj, ne punojmĂ« me ekipin e caktuar mbi diagnostikimin â nga dhjetĂ«ra minuta deri nĂ« disa orĂ«.
Edhe nëse diagnostikimi bëhet shpejt, ne nuk duam që kjo të ndodhë shpesh. Në rastin ideal, ne do të merrnim një alert kritik vetëm kur ka një ndikim të rëndësishëm në shërbim. Për sistemin tonë të përshpejtimit të kërkesave, ne kemi vetëm 2 alerta që do të na njoftojnë:
- procenti i Client Fallback â vlerĂ«simi i sjelljes sĂ« klientĂ«ve;
- procenti i Probe errors â tĂ« dhĂ«na pĂ«r stabilitetin e komponentĂ«ve tĂ« rrjetit.
Këto alerta kritike mbajnë nën kontroll nëse sistemi funksionon për shumicën e përdoruesve. Ne shikojmë se sa klientë kanë përfituar nga fallback, nëse ata nuk arritën të marrin përshpejtim kërkesash. Mesatarisht kemi më pak se 1 alarm kritik në javë, megjithëse në sistem ndodhin një sërë ndryshimesh. Pse na mjafton kjo?
- Ka client fallback në rast se proksi ynë nuk funksionon.
- Ka një sistem automatizimi steering, i cili reagon ndaj problemeve.
Më shumë për të fundit. Sistemi ynë i probe-ve, dhe sistemi automatizues për përcaktimin e rrugës optimale për kërkesat nga klienti në cloud, lejojnë të përballen automatikisht me disa probleme.
Le të kthehemi te konfigurimi ynë i probe-ve dhe 3 kategoritë e rrugëve. Përveç kohës së ngarkesës, ne mund të shikojmë në vetë faktin e dorëzimit. Nëse nuk arrijmë të ngarkojmë të dhënat, duke shqyrtuar rezultatet për rrugë të ndryshme, ne mund të përcaktojmë se ku dhe çfarë ka dështuar, dhe nëse mund ta riparojmë automatikisht duke ndryshuar rrugën e kërkesës.
Shembuj:
Ky proces mund tĂ« automatizohet. Ta pĂ«rfshijmĂ« atĂ« nĂ« sistemin steering. 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Ă« kĂ«tĂ« mĂ«nyrĂ«, reagimi momental nuk Ă«shtĂ« kritik, falĂ« fallback pĂ«r klientĂ«t.
Kështu, parimet e mbështetjes së sistemit mund të përmblidhen kështu:
- minimizojmë shkallën e defekteve;
- mbledhim metrika;
- riparojmë defektet automatikisht, nëse mundemi;
- nĂ«se nuk mundemi â njoftojmĂ«;
- Ne jemi duke punuar në dashboards dhe triage toolset për reagim të shpejtë.
MĂ«simet e nxjerra
PĂ«r tĂ« shkruar njĂ« prototip, nuk nevojitet shumĂ« kohĂ«. NĂ« rastin tonĂ«, ai ishte gati pas vetĂ«m 4 muajsh. Me tĂ« ne morĂ«m metrika tĂ« reja, dhe pas 10 muajsh qĂ« nga fillimi i zhvillimit morĂ«m trafikun e parĂ« nĂ« production. Pastaj filloi puna e lodhshme dhe shumĂ« e komplikuar: gradualisht produktizimi dhe shkallĂ«zimi i sistemit, migruar trafik kryesor dhe mĂ«suar nga gabimet. Ky proces efektiv nuk do tĂ« jetĂ« lineare â pavarĂ«sisht nga tĂ« gjitha pĂ«rpjekjet, nuk mund tĂ« parashikoni gjithçka. MĂ« efikase Ă«shtĂ« iterimi i shpejtĂ« dhe reagimi ndaj tĂ« dhĂ«nave tĂ« reja.
Duke u bazuar në përvojën tonë, mund të rekomandojmë sa vijon:
- Mos e besoni intuitën.
Intuita jonë na ka mashtruar vazhdimisht, pavarësisht përvojës së madhe të anëtarëve të ekipit. Për shembull, ne parashikuam gabim rritjen 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Ă« keni akses sa mĂ« shpejt 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Ă« merret. Aksesi i shpejtĂ« nĂ« rezultatet do t'ju ndihmojĂ« tĂ« mĂ«soni mĂ« shpejt pĂ«r problemet potenciale dhe t'i merrni parasysh ato nĂ« arkitekturĂ«n e sistemit.
- Mos ndiqni kĂ«shillat dhe rezultatet e tĂ« tjerĂ«ve â mbledhni tĂ« dhĂ«nat tuaja.
Ndihuni pas parimeve pĂ«r mbledhjen dhe analizimin e tĂ« dhĂ«nave, por mos merrni verbĂ«risht rezultatet dhe pohimet e tĂ« tjerĂ«ve. VetĂ«m ju mund tĂ« dini saktĂ«sisht se çfarĂ« funksionon pĂ«r pĂ«rdoruesit tuaj. Sistemet tuaja dhe klientĂ«t tuaj mund tĂ« ndryshojnĂ« ndjeshĂ«m nga kompanitĂ« e tjera. FatmirĂ«sisht, mjetet pĂ«r analizĂ« tani janĂ« tĂ« disponueshme dhe tĂ« lehta pĂ«r t'u pĂ«rdorur. Rezultatet e marra nga ju mund tĂ« mos pĂ«rputhen me ato qĂ« pohon Netflix, Facebook, Akamai dhe kompani tĂ« tjera. NĂ« rastin tonĂ«, performanca e TLS, HTTP2 ose statistikat pĂ«r kĂ«rkesat DNS ndryshojnĂ« nga rezultatet e Facebook, Uber, Akamai â sepse kemi pajisje, klientĂ« dhe flukse tĂ« dhĂ«nash tĂ« ndryshme.
- Mos u ngjitni pas trendeve të modës pa nevojë dhe pa vlerësuar efektivitetin.
Filloni me tĂ« thjeshtĂ«n. ĂshtĂ« mĂ« mirĂ« tĂ« krijoni njĂ« sistem funksional tĂ« thjeshtĂ« brenda njĂ« kohe tĂ« shkurtĂ«r, sesa tĂ« investoni njĂ« sasi tĂ« madhe kohe nĂ« zhvillimin e komponentĂ«ve qĂ« nuk ju nevojiten. Zgjidhni detyra dhe probleme qĂ« janĂ« tĂ« rĂ«ndĂ«sishme bazuar nĂ« matjet dhe rezultatet tuaja.
- Jini të gatshëm për aplikime të reja.
Ashtu siç Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikohet çdo problem, ashtu Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikosh pĂ«rfitimet dhe aplikimet pĂ«rpara. Merrni shembull nga startup-et â aftĂ«sia e tyre pĂ«r t'u adaptuar nĂ« kushtet e klientĂ«ve. NĂ« rastin tuaj, mund tĂ« zbuloni probleme tĂ« reja dhe zgjidhje pĂ«r to. NĂ« projektin tonĂ«, qĂ«llimi ynĂ« ishte tĂ« paksonim vonesat e kĂ«rkesave. MegjithatĂ«, gjatĂ« analizĂ«s dhe diskutimeve, kuptuam se mund tĂ« aplikonim serverĂ«t proxy gjithashtu:
- për balancimin e trafikut në regionet e AWS-së dhe uljen e kostove;
- për modelimin e stabilitetit të CDN;
- për konfigurimin e DNS;
- për konfigurimin e TLS/TCP.
PĂ«rfundim
Në raportin e prezantova si Netflix zgjidh problemin e përshpejtimit të kërkesave të internetit mes klientëve dhe cloud-it. Si mbledhim të dhëna përmes sistemit të mostrave te klientët, dhe përdorim të dhënat historike të mbledhura për të drejtuar kërkesat e prodhimit nga klientët përmes rrugës më të shpejtë në internet. Si përdorim parimet e punës së protokolleve rrjetërore, infrastrukturën tonë CDN, rrjetin backbone dhe serverët DNS për të arritur këtë qëllim.
MegjithatĂ«, zgjidhja jonĂ« Ă«shtĂ« vetĂ«m njĂ« shembull i asaj se si ne nĂ« Netflix kemi realizuar njĂ« sistem tĂ« tillĂ«. ĂfarĂ« ka funksionuar pĂ«r ne. Pjesa aplikative e raportit tim pĂ«r ju janĂ« parimet e zhvillimit dhe mbĂ«shtetjes, qĂ« ndjekim dhe arrijmĂ« rezultate tĂ« mira.
Zgjidhja jonë për problemin mund të mos ju përshtatet. Megjithatë, teoria dhe parimet e zhvillimit mbeten, edhe nëse ju nuk keni një infrastrukturë CDN të vetën, ose nëse ajo ndryshon nd significantly nga e jona.
Gjithashtu mbetet rëndësia e shpejtësisë së kërkesave për biznesin. Edhe për një shërbim të thjeshtë duhet të bëni një zgjedhje: midis ofruesve 'cloud', vendndodhjes së serverëve, CDN dhe ofruesve të DNS. Zgjedhja juaj do të ndikojë në efikasitetin e muajve të kërkesave për klientët tuaj. Dhe është e rëndësishme për ju të matni dhe kuptoni këtë ndikim.
Filloni me zgjidhje të thjeshta, kujdesuni për mënyrën se si e ndryshoni produktin. Mësoni gjatë procesit dhe përmirësoni sistemin në bazë të të dhënave nga klientët tuaj, infrastrukturës tuaj dhe biznesit tuaj. Mendoni për mundësitë e dështimeve të papritura gjatë projektimit. Më pas do të mund të përshpejtoni procesin tuaj të zhvillimit, përmirësoni efikasitetin e zgjidhjes, shmangni ngarkesën e tepërt në mbështetje dhe flini rehat.
Këtë vit në format online. Do të keni mundësinë të bëni pyetje njërit prej prindërve të DevOps, John Willis-it vetë!
Burimi: habr.com
