Netflix Interneteko telebista-merkatuko liderra da - segmentu hau sortu eta aktiboki garatzen ari den konpainia. Netflix ez da ezaguna planetako ia txoko guztietatik eta pantaila duen edozein gailutik eskuragarri dauden pelikula eta telesailen katalogo zabalagatik, baita azpiegitura fidagarriagatik eta ingeniaritza kultura bereziagatik ere.
DevOops 2019-n sistema konplexuak garatzeko eta laguntzeko Netflix-en ikuspegiaren adibide garbia aurkeztu zen. - Netflixeko Garapen zuzendaria. Nizhny Novgorod Estatuko Unibertsitateko Matematika eta Matematika Konputazionalen Fakultateko lizentziaduna. Lobachevsky, Sergey Open Connect-eko CDN taldeko lehen ingeniarietako bat Netflix-en. Bideo-datuak monitorizatzeko eta aztertzeko sistemak eraiki zituen, FAST.com Interneteko konexioaren abiadura ebaluatzeko zerbitzu ezaguna jarri zuen martxan, eta azken urteotan Interneteko eskaerak optimizatzen aritu da Netflix aplikazioa erabiltzaileentzat ahalik eta azkarren funtzionatzeko.
Txostenak kongresuko parte-hartzaileen iritzi onenak jaso ditu, eta testu-bertsio bat prestatu dizugu.
Bere txostenean, Sergei xehetasunez hitz egin zuen
- bezeroaren eta zerbitzariaren arteko Interneteko eskaeren atzerapenari buruz;
- nola murriztu atzerapen hori;
- nola diseinatu, mantendu eta kontrolatu errore-jasotzaileak diren sistemak;
- nola lortu emaitzak denbora laburrean, eta negozioarentzat arrisku minimoarekin;
- emaitzak nola aztertu eta akatsetatik ikasi.
Galdera hauen erantzunak ez dituzte soilik korporazio handietan lan egiten dutenek behar.
Aurkeztutako printzipioak eta teknikak Interneteko produktuak garatzen eta onartzen dituzten guztiek ezagutu eta landu behar dituzte.
Jarraian, hizlariaren ikuspegitik kontakizuna da.
Interneteko abiaduraren garrantzia
Interneteko eskaeren abiadura negozioarekin zuzenean lotuta dago. Demagun erosketa-industria: Amazon 2009an 100 ms-ko atzerapen batek salmenten % 1 galtzen duela.
Gero eta gailu mugikor gehiago daude, eta ondoren mugikorrentzako guneak eta aplikazioak daude. Zure orria 3 segundo baino gehiago behar bada kargatzen, erabiltzaileen erdia inguru galtzen ari zara. EKIN Google-k zure orriaren karga-abiadura hartzen du kontuan bilaketa-emaitzetan: zenbat eta azkarragoa izan orrialdea, orduan eta posizio handiagoa izango du Googlen.
Konexio-abiadura garrantzitsua da latentzia funtsezkoa den finantza-erakundeetan ere. 2015ean, Hibernia Sareak New York eta Londres arteko 400 milioi dolarreko kable bat hirien arteko latentzia 6ms murrizteko. Imajinatu 66 milioi $ 1 ms latentzia murrizteko!
Arabera , 5 Mbit/s-tik gorako konexio-abiadurek jada ez dute zuzenean eragiten webgune arrunt baten karga-abiaduran. Hala ere, harreman lineal bat dago konexio-latentziaren eta orriak kargatzeko abiaduraren artean:
Hala ere, Netflix ez da ohiko produktua. Latentziaren eta abiaduraren eragina erabiltzailearengan analisiaren eta garapenaren eremu aktiboa da. Aplikazioen karga eta edukia hautatzea latentziaren araberakoa da, baina elementu estatikoak kargatzea eta streaming-a ere konexio-abiaduraren araberakoa da. Erabiltzailearen esperientzian eragina duten funtsezko faktoreak aztertzea eta optimizatzea Netflix-eko hainbat talderen garapen-eremu aktiboa da. Helburuetako bat Netflix gailuen eta hodeiko azpiegituren arteko eskaeren latentzia murriztea da.
Txostenean bereziki latentzia murriztean zentratuko gara Netflix azpiegituraren adibidea erabiliz. Azter dezagun ikuspuntu praktikotik nola jorratu sistema banatu konplexuen diseinu, garapen eta funtzionamendu prozesuetara eta berrikuntza eta emaitzetan denbora eman, funtzionamendu-arazoak eta matxurak diagnostikatu beharrean.
Netflix-en barruan
Milaka gailu ezberdinek Netflix aplikazioak onartzen dituzte. Lau talde ezberdinek garatzen dituzte, eta bezeroaren bertsio bereiziak egiten dituzte Android, iOS, telebista eta web arakatzaileetarako. Eta ahalegin handia egiten dugu erabiltzailearen esperientzia hobetzen eta pertsonalizatzen. Horretarako, ehunka A/B proba egiten ditugu paraleloan.
Pertsonalizazioa AWS hodeian ehunka mikrozerbitzuk onartzen dute, erabiltzaileen datu pertsonalizatuak, kontsultak bidaltzea, telemetria, Big Data eta kodeketa eskainiz. Trafikoaren bistaratzea honelakoa da:
Ezkerrean sarrera-puntua dago, eta ondoren, trafikoa backend talde ezberdinek onartzen duten ehunka mikrozerbitzuen artean banatzen da.
Gure azpiegituraren beste osagai garrantzitsu bat Open Connect CDN da, azken erabiltzaileari eduki estatikoa ematen diona - bideoak, irudiak, bezero-kodea, etab. CDN zerbitzari pertsonalizatuetan dago (OCA - Open Connect Appliance). Barruan FreeBSD optimizatua exekutatzen duten SSD eta HDD unitateak daude, NGINX eta zerbitzu multzo batekin. Hardware eta software osagaiak diseinatzen eta optimizatzen ditugu, honela CDN zerbitzari batek erabiltzaileei ahalik eta datu gehien bidal ditzan.
Interneteko trafikoa trukatzeko puntuan (Internet eXchange - IX) zerbitzari hauen "horma" itxura hau du:
Internet Exchange-k Interneteko zerbitzu-hornitzaileek eta eduki-hornitzaileek elkarren artean "konektatzeko" gaitasuna eskaintzen die Interneten datuak zuzenean trukatzeko. Gure zerbitzariak instalatuta dauden 70-80 Internet Exchange puntu inguru daude mundu osoan, eta modu independentean instalatzen eta mantentzen ditugu:
Horrez gain, zerbitzariak zuzenean eskaintzen dizkiegu Interneteko hornitzaileei, hauek beren sarean instalatzen dituztenak, Netflix trafikoaren lokalizazioa eta erabiltzaileen streaming-aren kalitatea hobetuz:
AWS zerbitzu multzo bat bezeroen bideo-eskaerak CDN zerbitzarietara bidaltzeaz arduratzen da, baita zerbitzariak beraiek konfiguratzeaz ere - edukia, programa-kodea, ezarpenak eta abar eguneratzeaz. Azken horretarako, Internet Exchange puntuetako zerbitzariak AWSrekin lotzen dituen bizkarrezurreko sare bat ere eraiki dugu. Backbone sarea zuntz optikoko kable eta bideratzaileen sare global bat da, gure beharren arabera diseinatu eta konfigura dezakeguna.
On , gure CDN azpiegiturak munduko Interneteko trafikoaren β gutxi gorabehera ematen du puntako orduetan eta Ipar Amerikako trafikoaren β gutxi gorabehera, Netflix-ek denbora gehien izan duen tokian. Zenbaki ikusgarriak, baina niretzat lorpen harrigarrienetako bat da CDN sistema osoa 150 pertsona baino gutxiagoko talde batek garatu eta mantentzen duela.
Hasieran, CDN azpiegitura bideo datuak emateko diseinatu zen. Hala ere, denborarekin konturatu ginen AWS hodeian bezeroen eskaera dinamikoak optimizatzeko ere erabil dezakegula.
Interneten azelerazioari buruz
Gaur egun, Netflix-ek 3 AWS eskualde ditu, eta hodeirako eskaeren latentzia bezeroa gertuen dagoen eskualdetik noraino dagoenaren araberakoa izango da. Aldi berean, eduki estatikoa emateko erabiltzen diren CDN zerbitzari asko ditugu. Ba al dago marko hau kontsulta dinamikoak bizkortzeko modurik? Hala ere, zoritxarrez, ezinezkoa da eskaera hauek cachean gordetzea - ββAPIak pertsonalizatuak dira eta emaitza bakoitza bakarra da.
Egin dezagun proxy bat CDN zerbitzarian eta has gaitezen trafikoa bidaltzen. Azkarragoa izango al da?
Materiala
Gogora dezagun nola funtzionatzen duten sare-protokoloak. Gaur egun, Interneteko trafiko gehienek HTTPs erabiltzen dute, TCP eta TLS beheko geruzen protokoloen araberakoa. Bezero bat zerbitzarira konektatzeko, esku-eskubidea egiten du, eta konexio segurua ezartzeko, bezeroak hiru aldiz trukatu behar ditu mezuak zerbitzariarekin eta gutxienez beste behin datuak transferitzeko. Joan-etorriko bidaia bakoitzeko (RTT) 100 ms-ko latentziarekin, 400 ms beharko genituzke lehen datu bitak jasotzeko:
Ziurtagiriak CDN zerbitzarian jartzen baditugu, orduan bezeroaren eta zerbitzariaren arteko esku-emate denbora nabarmen murriztu daiteke CDN hurbilago badago. Demagun CDN zerbitzariaren latentzia 30 ms-koa dela. Ondoren, 220 ms beharko dira lehenengo bita jasotzeko:
Baina abantailak ez dira hor amaitzen. Konexio bat ezarri ondoren, TCP-k pilaketa-leihoa handitzen du (konexio horren bidez paraleloki transmiti dezakeen informazio kopurua). Datu-pakete bat galtzen bada, TCP protokoloaren inplementazio klasikoek (TCP New Reno bezalakoak) irekitako "leihoa" erdira murrizten dute. Kongestio-leihoaren hazkundea eta galeretatik berriro berreskuratzeko abiadura zerbitzariaren atzerapenaren (RTT) araberakoa da. Konexio hau CDN zerbitzariraino iristen bada, berreskuratze hori azkarragoa izango da. Aldi berean, pakete-galera fenomeno estandarra da, batez ere haririk gabeko sareetan.
Interneteko banda-zabalera murriztu daiteke, batez ere puntako orduetan, erabiltzaileen trafikoaren ondorioz, eta horrek auto-ilarak sor ditzake. Hala ere, Interneten ez dago eskaera batzuei besteei lehentasuna emateko modurik. Esate baterako, eman lehentasuna eskaera txikiei eta latentziari dagokienean sarea kargatzen duten datu-korronte "astunak" baino. Hala ere, gure kasuan, gure bizkarrezurreko sarea izateak hau egiteko aukera ematen digu eskaeraren bidearen zati batean - CDN eta hodeiaren artean, eta guztiz konfiguratu dezakegu. Ziurtatu dezakezu pakete txikiei eta latentziari eragiten dietenak lehenesten direla, eta datu-fluxu handiak pixka bat beranduago joaten direla. CDN bezeroarengandik zenbat eta gertuago egon, orduan eta eraginkortasun handiagoa.
Aplikazio-mailako protokoloek (OSI 7. maila) ere eragina dute latentzian. HTTP/2 bezalako protokolo berriek eskaera paraleloen errendimendua optimizatzen dute. Hala ere, Netflix bezeroak baditugu protokolo berriak onartzen ez dituzten gailu zaharragoekin. Bezero guztiak ezin dira eguneratu edo modu egokian konfiguratu. Aldi berean, CDN proxyaren eta hodeiaren artean kontrol osoa dago eta protokolo eta ezarpen berriak eta optimoak erabiltzeko gaitasuna dago. Protokolo zaharrekin eraginkortasunik gabeko zatiak bezeroaren eta CDN zerbitzariaren artean bakarrik funtzionatuko du. Gainera, CDN eta hodeiaren artean dagoeneko ezarritako konexio batean multiplex eskaerak egin ditzakegu, TCP mailan konexioaren erabilera hobetuz:
Neurtzen dugu
Teoriak hobekuntzak agintzen dituen arren, ez dugu berehala sistema ekoizpenean abiarazteko presarik. Horren ordez, lehenik eta behin ideiak praktikan funtzionatuko duela frogatu behar dugu. Horretarako hainbat galdera erantzun behar dituzu:
- Abiadura: proxy bat azkarragoa izango al da?
- Fidagarritasuna: Maizago hautsiko al da?
- konplexutasuna: nola integratu aplikazioekin?
- Kostua: Zenbat kostatzen da azpiegitura gehigarriak zabaltzea?
Azter dezagun zehatz-mehatz lehen puntua baloratzeko dugun ikuspegia. Gainontzekoak antzera jorratzen dira.
Eskaeren abiadura aztertzeko, erabiltzaile guztien datuak lortu nahi ditugu, garapenean denbora asko eman gabe eta ekoizpena hautsi gabe. Horretarako hainbat ikuspegi daude:
- RUM, edo eskaera pasiboaren neurketa. Erabiltzaileen egungo eskaeren exekuzio denbora neurtzen dugu eta erabiltzaileen estaldura osoa bermatzen dugu. Desabantaila da seinalea ez dela oso egonkorra faktore askorengatik, adibidez, eskaeraren tamaina desberdinengatik, zerbitzarian eta bezeroan prozesatzeko denboragatik. Horrez gain, ezin duzu konfigurazio berri bat probatu ekoizpenean eraginik gabe.
- Laborategiko probak. Bezeroak simulatzen dituzten zerbitzari eta azpiegitura bereziak. Haien laguntzarekin beharrezko probak egiten ditugu. Horrela neurketen emaitzen kontrol osoa eta seinale argia lortzen dugu. Baina ez dago gailuen eta erabiltzaileen kokapenen erabateko estaldurarik (batez ere mundu osoko zerbitzu eta milaka gailu modeloentzako laguntzarekin).
Nola uztar ditzakezu bi metodoen abantailak?
Gure taldeak irtenbide bat aurkitu du. Kode zati txiki bat idatzi genuen - lagin bat - gure aplikazioan txertatu genuena. Zundek gure gailuetatik guztiz kontrolatutako sareko probak egiteko aukera ematen digute. Honela funtzionatzen du:
- Aplikazioa kargatu eta hasierako jarduera amaitu eta gutxira, gure zundaketak exekutatzen ditugu.
- Bezeroak zerbitzariari eskaera bat egiten dio eta probarako "errezeta" bat jasotzen du. Errezeta HTTP(k) eskaera egin behar zaien URLen zerrenda da. Gainera, errezetak eskaera-parametroak konfiguratzen ditu: eskaeren arteko atzerapenak, eskatutako datu kopurua, HTTP(k) goiburuak, etab. Aldi berean, hainbat errezeta proba ditzakegu paraleloan; konfigurazio bat eskatzerakoan, ausaz zehazten dugu zein errezeta eman.
- Zunda abiarazteko ordua hautatzen da bezeroaren sareko baliabideen erabilera aktiboarekin gatazkarik ez izateko. Funtsean, bezeroa aktibo ez dagoenean aukeratzen da ordua.
- Errezeta jaso ondoren, bezeroak eskaerak egiten dizkio URL bakoitzari, paraleloki. Helbide bakoitzari egindako eskaera errepikatu daiteke - deiturikoak. "pultsuak". Lehenengo pultsuan, konexioa ezartzeko eta datuak deskargatzeko zenbat denbora behar izan den neurtzen dugu. Bigarren pultsuan, datuak kargatzeko behar den denbora neurtzen dugu dagoeneko ezarritako konexio baten bidez. Hirugarrenaren aurretik, atzerapen bat ezarri eta birkonexio bat ezartzeko abiadura neur dezakegu, etab.
Probak zehar, gailuak lor ditzakeen parametro guztiak neurtzen ditugu:
- DNS eskaeraren ordua;
- TCP konexioa konfiguratzeko ordua;
- TLS konexioa konfiguratzeko ordua;
- datuen lehen bytea jasotzeko ordua;
- kargatzeko denbora osoa;
- egoeraren emaitza kodea.
- Pultsu guztiak amaitu ondoren, laginak neurketa guztiak kargatzen ditu aztertzeko.
Funtsezko puntuak bezeroarekiko logikarekiko menpekotasun minimoa, zerbitzarian datuen prozesamendua eta eskaera paraleloen neurketa dira. Horrela, kontsultaren errendimenduan eragina duten hainbat faktoreren eragina isolatu eta probatzeko gai gara, errezeta bakarrean aldatzeko eta benetako bezeroen emaitzak lortzeko.
Azpiegitura hau erabilgarria izan da kontsulta-errendimenduaren analisia baino gehiago egiteko. Gaur egun 14 errezeta aktibo ditugu, segundoko 6000 lagin baino gehiago, lurreko bazter guztietako datuak eta gailuaren estaldura osoa jasotzen dutenak. Netflixek hirugarren bati antzeko zerbitzu bat erosiko balu, urtean milioika dolar kostatuko litzaioke, askoz estaldura okerragoa izanda.
Teoria praktikan probatzea: prototipoa
Sistema horrekin, CDN proxien eraginkortasuna ebaluatu ahal izan dugu eskaeraren latentzian. Orain behar duzu:
- proxy prototipo bat sortu;
- jarri prototipoa CDN batean;
- zehaztu nola bideratu bezeroak CDN zerbitzari jakin bateko proxy batera;
- Konparatu errendimendua proxyrik gabeko AWS-ko eskaerekin.
Eginkizuna proposatutako irtenbidearen eraginkortasuna ahalik eta azkarren ebaluatzea da. Prototipoa inplementatzeko Go aukeratu genuen sareko liburutegi onen erabilgarritasunagatik. CDN zerbitzari bakoitzean, proxy prototipoa bitar estatiko gisa instalatu dugu menpekotasunak minimizatzeko eta integrazioa errazteko. Hasierako inplementazioan, osagai estandarrak ahalik eta gehien eta aldaketa txikiak erabili genituen HTTP/2 konexioen bilketarako eta multiplexazio eskaera egiteko.
AWS eskualdeen arteko oreka egiteko, DNS datu-base geografiko bat erabili dugu, bezeroak orekatzeko erabiltzen den bera. Bezeroarentzat CDN zerbitzari bat hautatzeko, TCP Anycast erabiltzen dugu Internet Exchange (IX) zerbitzarietarako. Aukera honetan, IP helbide bat erabiltzen dugu CDN zerbitzari guztietarako, eta bezeroa IP hop gutxien duen CDN zerbitzarira zuzenduko da. Interneteko hornitzaileek (ISP) instalatutako CDN zerbitzarietan, ez dugu bideratzailearen gaineko kontrolik TCP Anycast konfiguratzeko, beraz, erabiltzen dugu , bezeroak Interneteko hornitzaileengana bideratzen dituena bideo-streaminga egiteko.
Beraz, hiru eskaera-bide mota ditugu: hodeira Internet irekiaren bidez, IX-en CDN zerbitzari baten bidez edo Internet hornitzaile batean kokatutako CDN zerbitzari baten bidez. Gure helburua zein den hobeto ulertzea da eta proxy baten onura zein den, eskaerak ekoizpenera bidaltzen direnarekin alderatuta. Horretarako, honako laginketa sistema bat erabiltzen dugu:
Bide bakoitza helburu bereizi bihurtzen da, eta lortu dugun denborari erreparatzen diogu. Aztertzeko, proxy-emaitzak talde batean konbinatzen ditugu (hautatu IX eta ISP proxyen arteko denborarik onena), eta proxyrik gabe hodeirako eskaeren denborarekin alderatzen ditugu:
Ikus dezakezunez, emaitzak nahasiak izan ziren - kasu gehienetan proxyak bizkortze ona ematen du, baina egoera nabarmen okertuko den bezero kopuru nahikoa ere badago.
Ondorioz, hainbat gauza garrantzitsu egin genituen:
- Bezeroek hodeira egindako eskaeren espero den errendimendua ebaluatu dugu CDN proxy baten bidez.
- Benetako bezeroen datuak jaso ditugu, mota guztietako gailuetatik.
- Konturatu ginen teoria ez zegoela %100ean baieztatu eta CDN proxy batekin hasierako eskaintzak ez zigula balioko.
- Ez dugu arriskurik hartu; ez ditugu bezeroen produkzio-konfigurazioak aldatu.
- Ez zen ezer hautsi.
2.0 prototipoa
Beraz, itzuli taulara eta errepikatu prozesua berriro.
Ideia da %100eko proxy bat erabili beharrean, bezero bakoitzaren biderik azkarrena zehaztuko dugula, eta eskaerak bertara bidaliko ditugula, hau da, bezeroen gidaritza deritzona egingo dugu.
Nola ezarri hau? Zerbitzariaren aldetik ezin dugu logika erabili, zeren... Helburua zerbitzari honetara konektatzea da. Hori egiteko moduren bat egon behar da bezeroarengan. Egokiena, logika konplexu minimo batekin egin ezazu, bezero-plataforma ugarirekin integrazioaren arazoa ez konpontzeko.
Erantzuna DNS erabiltzea da. Gure kasuan, gure DNS azpiegitura dugu, eta gure zerbitzariak autoritarioak izango diren domeinu-eremu bat ezarri dezakegu. Honela funtzionatzen du:
- Bezeroak eskaera bat egiten dio DNS zerbitzariari ostalari bat erabiliz, adibidez api.netflix.xom.
- Eskaera gure DNS zerbitzarira iristen da
- DNS zerbitzariak badaki zein bide den azkarrena bezero honentzat eta dagokion IP helbidea ematen du.
Konponbideak konplexutasun gehigarri bat du: DNS hornitzaile autoritarioek ez dute bezeroaren IP helbidea ikusten eta bezeroak erabiltzen duen ebatzaile errekurtsiboaren IP helbidea soilik irakur dezakete.
Ondorioz, gure konponbide autoritarioak erabaki bat hartu behar du ez bezero indibidualarentzat, baizik eta ebatzaile errekurtsiboan oinarritutako bezero talde batena.
Ebazteko, lagin berdinak erabiltzen ditugu, bezeroen neurketa-emaitzak batzen ditugu ebatzaile errekurtsibo bakoitzeko eta horietako talde hori nora bidali erabakitzen dugu: proxy bat IX bidez TCP Anycast erabiliz, ISP proxy baten bidez edo zuzenean hodeira.
Sistema hau lortuko dugu:
Ondorioz, DNS gidatzeko ereduak bezeroak hodeirako konexioen abiaduraren behaketa historikoetan oinarrituta bideratzeko aukera ematen du.
Berriro ere, galdera da zein eraginkortasunez funtzionatuko duen ikuspegi honek? Erantzuteko, berriz ere gure zunda-sistema erabiltzen dugu. Hori dela eta, aurkezlearen konfigurazioa konfiguratzen dugu, non helburuetako batek DNS gidaritzapenaren norabidea jarraitzen duen, bestea zuzenean hodeira doan (egungo ekoizpena).
Ondorioz, emaitzak alderatzen ditugu eta eraginkortasunaren balorazioa lortzen dugu:
Ondorioz, hainbat gauza garrantzitsu ikasi genituen:
- Bezeroek hodeira egindako eskaeren espero den errendimendua ebaluatu dugu DNS Steering erabiliz.
- Benetako bezeroen datuak jaso ditugu, mota guztietako gailuetatik.
- Proposatutako ideiaren eraginkortasuna frogatu da.
- Ez dugu arriskurik hartu; ez ditugu bezeroen produkzio-konfigurazioak aldatu.
- Ez zen ezer hautsi.
Orain zati zailari buruz - ekoizpenean abiarazten dugu
Alde erraza orain amaitu da - funtzionatzen duen prototipo bat dago. Orain zaila da Netflix-en trafiko osorako irtenbide bat abian jartzea, 150 milioi erabiltzaileri, milaka gailuri, ehunka mikrozerbitzuri eta etengabe aldatzen ari den produktu eta azpiegiturari zabaltzea. Netflix zerbitzariek milioika eskaera jasotzen dituzte segundoko, eta erraza da zerbitzua apurtzea arduragabekeriaz. Aldi berean, trafikoa modu dinamikoan bideratu nahi dugu Interneteko milaka CDN zerbitzarietatik, non zerbait aldatzen eta apurtzen den etengabe eta momentu desegokienean.
Eta honekin guztiarekin, taldeak sistemaren garapenaz, hedapenaz eta euskarri osoaz arduratzen diren 3 ingeniari ditu.
Hori dela eta, lo lasaigarri eta osasuntsuaz hitz egiten jarraituko dugu.
Nola jarraitu garapenean eta ez zure denbora guztia laguntzan eman? Gure ikuspegia 3 printzipiotan oinarritzen da:
- Matxuren eskala potentziala murrizten dugu (eztandaren erradioa).
- Ezustekoak prestatzen ari gara; zerbait hautsiko dela espero dugu, probak eta esperientzia pertsonalak izan arren.
- Graceful degradation - zerbaitek ondo funtzionatzen ez badu, automatikoki konpondu beharko litzateke, modu eraginkorrenean ez bada ere.
Gertatu zen gure kasuan, arazoaren ikuspegi honekin, irtenbide sinple eta eraginkor bat aurki dezakegula eta sistemaren laguntza nabarmen sinplifikatu. Konturatu ginen bezeroari kode txiki bat gehitu genezakeela eta sare-eskaeraren akatsen jarraipena egin genezakeela konexio-arazoek eragindakoak. Sareko akatsak izanez gero, hodeira zuzenean erorketa egiten dugu. Irtenbide honek ez die esfortzu handirik eskatzen bezero-taldeei, baina ustekabeko matxurak eta ezusteko arriskuak asko murrizten ditu guretzat.
Jakina, atzera egin arren, garapenean zehar diziplina argi bat jarraitzen dugu:
- Lagin-proba.
- A/B probak edo Kanariak.
- Inplementazio progresiboa.
Laginekin, ikuspegia deskribatu da - aldaketak lehenik eta behin pertsonalizatutako errezeta erabiliz probatzen dira.
Kanariar probak egiteko, zerbitzari pare konparagarriak lortu behar ditugu, sistemak aldaketen aurretik eta ondoren nola funtzionatzen duen alderatu ahal izateko. Horretarako, gure CDN gune askotatik, trafiko konparagarria jasotzen duten zerbitzari bikoteak hautatzen ditugu:
Ondoren, Canary zerbitzarian aldaketekin eraikitzea instalatzen dugu. Emaitzak ebaluatzeko, gutxi gorabehera 100-150 metrika alderatzen dituen sistema bat exekutatzen dugu Kontrol-zerbitzarien lagin batekin:
Kanariarren probak arrakasta izanez gero, pixkanaka-pixkanaka askatzen dugu, olatuetan. Ez ditugu gune bakoitzeko zerbitzariak aldi berean eguneratzen - arazoengatik gune oso bat galtzeak eragin nabarmenagoa du erabiltzaileentzat zerbitzuan, kokapen ezberdinetan zerbitzari kopuru bera galtzeak baino.
Oro har, hurbilketa honen eraginkortasuna eta segurtasuna bildutako neurketen kantitatearen eta kalitatearen araberakoa da. Gure kontsultak bizkortzeko sistemarako, osagai posible guztien neurketak biltzen ditugu:
- bezeroen partetik - saio eta eskaera kopurua, atzerapen tasak;
- proxy - eskaera kopuruari eta denborari buruzko estatistikak;
- DNS - eskaeren kopurua eta emaitzak;
- cloud edge - hodeian eskaerak prozesatzeko kopurua eta ordua.
Hori guztia kanalizazio bakar batean biltzen da, eta, beharren arabera, erabakitzen dugu zein neurketa bidali denbora errealeko analitiketara, eta zein Elasticsearch edo Big Datara diagnostiko zehatzagoak egiteko.
Jarraipena egiten dugu
Gure kasuan, bezeroaren eta zerbitzariaren arteko eskaeren bide kritikoan aldaketak egiten ari gara. Aldi berean, bezeroan, zerbitzarian eta Interneten zehar dauden osagaien kopurua izugarria da. Bezeroan eta zerbitzarian aldaketak etengabe gertatzen dira - dozenaka talderen lanean eta ekosisteman aldaketa naturalak dira. Erdian gaude: arazoak diagnostikatzeko orduan, aukera handia dago parte hartzeko. Hori dela eta, argi ulertu behar dugu nola definitu, bildu eta aztertzen diren metrikak arazoak azkar isolatzeko.
Egokiena, neurketa eta iragazki mota guztietarako sarbide osoa denbora errealean. Baina metrika asko daude, beraz, kostuaren galdera sortzen da. Gure kasuan, neurriak eta garapen tresnak honela bereizten ditugu:
Arazoak detektatzeko eta probatzeko gure kode irekiko denbora errealeko sistema erabiltzen dugu ΠΈ - bistaratzeko. Metriko agregatuak memorian gordetzen ditu, fidagarria da eta alerta sistemarekin integratzen da. Lokalizaziorako eta diagnostikorako, Elasticsearch eta Kibanako erregistroetarako sarbidea dugu. Analisi estatistikoa eta modelizazioa egiteko, datu handiak eta bistaratzea erabiltzen ditugu Tableau-n.
Badirudi ikuspegi hau oso zaila dela lantzea. Hala ere, metrikak eta tresnak hierarkikoki antolatuz, arazo bat azkar aztertu, arazo mota zehaztu eta, ondoren, neurri zehatzak sakondu ditzakegu. Oro har, 1-2 minutu inguru ematen ditugu matxuraren jatorria identifikatzeko. Horren ostean, talde zehatz batekin lan egiten dugu diagnostikoetan - hamarnaka minututik hainbat ordu arte.
Diagnostikoa azkar egiten bada ere, ez dugu nahi hori maiz gertatzea. Egokiena, zerbitzuan eragin handia dagoenean soilik jasoko dugu alerta kritikoa. Gure kontsultak bizkortzeko sistemarako, 2 alerta besterik ez ditugu jakinaraziko:
- Bezeroaren Fallback ehunekoa - bezeroen portaeraren ebaluazioa;
- ehunekoa Zunda-erroreak - sareko osagaien egonkortasun-datuak.
Alerta kritiko hauek sistema erabiltzaile gehienentzat funtzionatzen ari den kontrolatzen dute. Begiratzen dugu zenbat bezerok erabili zuten errekurtsoa eskaeraren azelerazioa lortu ezin bazuten. Bataz beste, alerta kritiko bat baino gutxiago izaten dugu astean, nahiz eta sisteman aldaketa asko gertatzen ari diren. Zergatik da hau nahikoa guretzat?
- Gure proxy-ak funtzionatzen ez badu bezeroaren babesa dago.
- Arazoei erantzuten dien zuzendaritza sistema automatiko bat dago.
Azken honi buruzko xehetasun gehiago. Gure proba-sistemak eta bezeroaren hodeirako eskaeren bide optimoa automatikoki zehazteko sistemak arazo batzuei automatikoki aurre egiteko aukera ematen digu.
Itzuli gaitezen gure lagin-konfiguraziora eta 3 bide-kategoriara. Kargatzeko denboraz gain, entregaren berari erreparatu diezaiokegu. Datuak kargatu ezinezkoa izan bada, emaitzak bide ezberdinetatik begiratuz zehaztu dezakegu non eta zer hautsi den, eta eskaeraren bidea aldatuz automatikoki konpondu dezakegun ala ez.
Adibideak:
Prozesu hau automatizatu egin daiteke. Sartu gidatzeko sisteman. Eta irakatsi errendimendu eta fidagarritasun arazoei erantzuten. Zerbait apurtzen hasten bada, erreakzionatu aukera hoberik badago. Aldi berean, berehalako erreakzioa ez da kritikoa, bezeroenganako errekurtsoari esker.
Beraz, sistemaren laguntzaren printzipioak honela formulatu daitezke:
- matxuren eskala murriztea;
- metrikoak biltzea;
- Matxurak automatikoki konpontzen ditugu ahal badugu;
- ezin bada, jakinarazten dizugu;
- Erantzun azkarra lortzeko aginte-panelak eta triage-tresna-multzoa lantzen ari gara.
Ikasgaiak
Ez da denbora asko behar prototipo bat idazteko. Gure kasuan, 4 hilabeteren buruan prest zegoen. Harekin metrika berriak jaso genituen, eta garapena hasi eta 10 hilabetera lehen ekoizpen trafikoa jaso genuen. Orduan, lan neketsu eta oso zaila hasi zen: pixkanaka sistema ekoiztu eta eskalatu, trafiko nagusia migratu eta akatsetatik ikasi. Hala ere, prozesu eraginkor hau ez da lineala izango - ahalegin guztiak egin arren, ezin da dena aurreikusi. Askoz eraginkorragoa da datu berriei azkar errepikatzea eta erantzutea.
Gure esperientzian oinarrituta, honako hauek gomenda ditzakegu:
- Ez fidatu zure intuizioan.
Gure intuizioak huts egin zigun etengabe, gure taldekideen esperientzia handia izan arren. Esate baterako, CDN proxy bat erabiltzeagatik espero zen bizkortzea edo TCP Anycast-en portaera oker aurreikusi genuen.
- Lortu ekoizpenetik datuak.
Garrantzitsua da ahalik eta azkarren produkzio-datu kopuru txiki baterako sarbidea lortzea. Ia ezinezkoa da kasu, konfigurazio eta ezarpen bakarrak laborategiko baldintzetan lortzea. Emaitzetara sarbide azkarrak arazo potentzialak azkar ezagutzeko eta sistemaren arkitekturan kontuan hartzeko aukera emango dizu.
- Ez jarraitu besteen aholkuak eta emaitzak - bildu zure datuak.
Jarraitu datuak biltzeko eta aztertzeko printzipioak, baina ez onartu itsu-itsuan besteen emaitzak eta adierazpenak. Zuk bakarrik jakin dezakezu zer funtzionatzen duen zure erabiltzaileentzat. Zure sistemak eta zure bezeroak beste enpresekiko nabarmen desberdinak izan daitezke. Zorionez, analisi-tresnak eskuragarri daude orain eta erabiltzeko erraza. Lortzen dituzun emaitzak agian ez dira Netflix, Facebook, Akamai eta beste konpainia batzuek diotena. Gure kasuan, TLS, HTTP2 edo DNS eskaeren estatistiken errendimendua desberdina da Facebook, Uber, Akamai-ren emaitzekin, gailu, bezero eta datu-fluxu desberdinak ditugulako.
- Ez jarraitu modaren joerak alferrik eta ebaluatu eraginkortasuna.
Hasi sinplea. Hobe da denbora laburrean lan-sistema sinple bat egitea behar ez dituzun osagaiak garatzen denbora asko igarotzea baino. Ebatzi garrantzia duten zereginak eta arazoak zure neurketetan eta emaitzetan oinarrituta.
- Presta zaitez aplikazio berrietarako.
Arazo guztiak aurreikustea zaila den bezala, aldez aurretik onurak eta aplikazioak aurreikustea zaila da. Hartu abiapuntu startupetatik: bezeroen baldintzetara egokitzeko duten gaitasuna. Zure kasuan, arazo berriak eta haien konponbideak aurki ditzakezu. Gure proiektuan, eskaeraren latentzia murrizteko helburua ezarri dugu. Hala ere, azterketa eta eztabaidetan zehar, proxy zerbitzariak ere erabil ditzakegula konturatu ginen:
- AWS eskualdeetako trafikoa orekatzeko eta kostuak murrizteko;
- CDN egonkortasuna modelatzea;
- DNS konfiguratzeko;
- TLS/TCP konfiguratzeko.
Ondorioa
Txostenean, Netflix-ek bezeroen eta hodeiaren arteko Interneteko eskaerak bizkortzearen arazoa nola konpontzen duen deskribatu nuen. Nola biltzen ditugun datuak bezeroen laginketa-sistema bat erabiliz, eta bildutako datu historikoak nola erabiltzen ditugun bezeroen produkzio-eskaerak Interneteko bide azkarrenetik bideratzeko. Nola erabiltzen ditugun sare-protokoloen printzipioak, gure CDN azpiegitura, bizkarrezurreko sarea eta DNS zerbitzariak zeregin hori lortzeko.
Hala ere, gure irtenbidea Netflix-en sistema hori nola inplementatu genuenaren adibide bat besterik ez da. Zer funtzionatu zigun. Nire txostenaren zati aplikatua jarraitzen dugu eta emaitza onak lortzen ditugun garapen eta laguntza printzipioak dira.
Arazoari gure irtenbidea agian ez zaizu egokituko. Hala ere, teoria eta diseinuaren printzipioak mantentzen dira, nahiz eta ez izan zure CDN azpiegiturarik, edo gurearekin nabarmen ezberdintzen bada.
Negozioen eskaeren abiaduraren garrantziak ere garrantzitsua izaten jarraitzen du. Eta zerbitzu sinple baterako ere aukera bat egin behar duzu: hodeiko hornitzaileen, zerbitzariaren kokapena, CDN eta DNS hornitzaileen artean. Zure aukerak zure bezeroentzako Interneteko kontsulten eraginkortasunean eragingo du. Eta garrantzitsua da eragin hori neurtzea eta ulertzea.
Hasi irtenbide sinpleetatik, zaindu produktua nola aldatzen duzun. Ikasi joan ahala eta hobetu sistema zure bezeroen, zure azpiegituretako eta zure negozioaren datuetan oinarrituta. Pentsatu diseinu-prozesuan ustekabeko matxurak izateko aukera. Eta gero zure garapen-prozesua bizkortu dezakezu, irtenbideen eraginkortasuna hobetu, alferrikako laguntza zama saihestu eta lasai lo egin dezakezu.
Aurten online formatuan. Galderak egin diezazkiokezu DevOps-en gurasoetako bati, John Willis berari!
Iturria: www.habr.com