{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Vi accelererer internetanmodninger og sover trygt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix \u2014 markededsf\u00f8rer inden for internet-tv \u2014 selskabet, der har skabt og aktivt udvikler dette segment. Netflix er kendt ikke kun for sit omfattende katalog af film og serier, der er tilg\u00e6ngelige fra n\u00e6sten enhver del af verden og p\u00e5 enhver enhed med en sk\u00e6rm, men ogs\u00e5 for sin p\u00e5lidelige infrastruktur og unikke ingeni\u00f8rkultur. <\/p>\n<p>Et tydeligt eksempel p\u00e5 Netflix' tilgang til udvikling og vedligeholdelse af komplekse systemer blev pr\u00e6senteret p\u00e5 DevOops 2019 af <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergey Fedorov<\/a><\/noindex> \u2014 udviklingsdirekt\u00f8r hos Netflix. Kandidat fra Fakultetet for Matematik, Informatik og Naturvidenskab ved NNGU opkaldt efter Lobatchevsky. Sergey var en af de f\u00f8rste ingeni\u00f8rer i Open Connect \u2014 CDN-teamet hos Netflix. Han har bygget overv\u00e5gnings- og analyse-systemer for video data, lanceret den popul\u00e6re tjeneste FAST.com til at vurdere hastigheden af internetforbindelsen og har i de seneste par \u00e5r arbejdet p\u00e5 at optimere internetanmodninger, s\u00e5 Netflix-applikationen fungerer hurtigere for brugerne.<\/p>\n<p>Pr\u00e6sentationen fik de bedste anmeldelser fra konferencedeltagerne, og vi har forberedt en tekstversion til dig.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"Afspil video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>I pr\u00e6sentationen fortalte Sergey detaljeret<\/h2>\n<p><\/p>\n<ul>\n<li>om, hvad der p\u00e5virker forsinkelsen af internetanmodninger mellem klienten og serveren;<\/li>\n<li>hvordan man kan reducere denne forsinkelse;<\/li>\n<li>hvordan man designer, vedligeholder og overv\u00e5ger fejlresistente systemer;<\/li>\n<li>hvordan man opn\u00e5r resultater p\u00e5 kort tid, med minimal risiko for forretningen;<\/li>\n<li>hvordan man analyserer resultaterne og l\u00e6rer af fejlene.<\/li>\n<\/ul>\n<p>\nSvarene p\u00e5 disse sp\u00f8rgsm\u00e5l er vigtige ikke kun for dem, der arbejder i store virksomheder. <\/p>\n<p>De pr\u00e6senterede principper og teknikker b\u00f8r kendes og praktiseres af alle, der udvikler og vedligeholder internetprodukter.<\/p>\n<p><b>Herefter \u2014 fort\u00e6llingen fra taleren.<\/b><\/p>\n<h2>Vigtigheden af hastigheden p\u00e5 internettet<\/h2>\n<p>\nHastigheden af internetanmodninger er direkte forbundet med forretningen. Lad os se p\u00e5 shoppingomr\u00e5det: Amazon sagde i 2009, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">at en forsinkelse p\u00e5 100 ms f\u00f8rer til et tab p\u00e5 1% i salget.<\/a><\/noindex>Der bliver flere og flere mobile enheder, og dermed mobile hjemmesider og applikationer. Hvis din side indl\u00e6ses l\u00e6ngere end 3 sekunder, mister du omkring halvdelen af brugerne. Siden<\/p>\n<p>juli 2018 <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">har Google taget h\u00f8jde for indl\u00e6sningstiden for din side i s\u00f8geresultaterne: jo hurtigere siden er, jo h\u00f8jere er dens placering i Google.<\/a><\/noindex> Hastigheden af forbindelsen er ogs\u00e5 vigtig i finansielle institutioner, hvor forsinkelse er kritisk. I 2015 afsluttede Hibernia Networks<\/p>\n<p>arbejdet med <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">af<\/a><\/noindex> kabelstr\u00e6kningen mellem New York og London til en pris p\u00e5 400 millioner dollars, for at reducere forsinkelsen mellem byerne med 6 ms. Forestil dig, 66 millioner dollars for 1 ms reduktion i forsinkelse!<\/p>\n<p>If\u00f8lge <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">unders\u00f8gelsen<\/a><\/noindex>, hastigheden p\u00e5 forbindelsen over 5 Mbit\/s stopper med at have en direkte indflydelse p\u00e5 hastigheden af indl\u00e6sning af en typisk hjemmeside. Men der er en line\u00e6r sammenh\u00e6ng mellem forbindelsesforsinkelse og siden indl\u00e6sningshastighed:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen Netflix er ikke et typisk produkt. Indflydelsen af forsinkelse og hastighed p\u00e5 brugeren er et aktivt omr\u00e5de for analyse og udvikling. Der er appindl\u00e6sning og indholdsvalg, som afh\u00e6nger af forsinkelse, men indl\u00e6sning af statiske elementer og streaming afh\u00e6nger ogs\u00e5 af hastigheden p\u00e5 forbindelsen. Analyse og optimering af de n\u00f8glefaktorer, der p\u00e5virker brugerens servicekvalitet, er et aktivt udviklingsomr\u00e5de for flere teams i Netflix. En af opgaverne er at reducere forsinkelsen af foresp\u00f8rgsler mellem Netflix-enheder og den cloud-infrastruktur.<\/p>\n<p>I denne rapport vil vi fokusere specifikt p\u00e5 reduktion af forsinkelse (latency) ved at tage udgangspunkt i Netflix-infrastrukturen. Vi vil se fra et praktisk synspunkt p\u00e5, hvordan man griber design-, udviklings- og driftsprocesserne af komplekse distribuerede systemer an, og bruge tid p\u00e5 innovation og resultater i stedet for diagnose af driftsproblemer og nedbrud.<\/p>\n<h2>Inden for Netflix<\/h2>\n<p>\nTusindvis af forskellige enheder underst\u00f8tter Netflix-applikationer. Deres udvikling h\u00e5ndteres af fire forskellige teams, der laver separate versioner af klienten til Android, iOS, TV og webbrowsere. Og vi bruger en masse ressourcer p\u00e5 at forbedre og personalisere brugergr\u00e6nsefladen. Derfor k\u00f8rer vi samtidig hundreder af A\/B-tests.<\/p>\n<p>Personalisering underst\u00f8ttes af hundrede mikrotjenester i AWS-clouden, som leverer personaliserede data til brugeren, anmodningsh\u00e5ndtering, telemetri, Big Data og kodning. Visualiseringen af trafik ser s\u00e5ledes ud:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link til video med demonstration (6:04-6:23)<\/a><\/noindex><\/p>\n<p>Til venstre er entry point, og derefter fordeles trafikken mellem flere hundrede mikrotjenester, der underst\u00f8ttes af forskellige backend-teams.<\/p>\n<p>En anden vigtig komponent i vores infrastruktur er Open Connect CDN, som leverer statisk indhold til slutbrugeren \u2014 videoer, billeder, kode til klienter osv. CDN er placeret p\u00e5 tilpassede servere (OCA \u2014 Open Connect Appliance). Inden i findes der SSD- og HDD-diskarrays, der k\u00f8rer p\u00e5 den optimerede FreeBSD, med NGINX og en r\u00e6kke tjenester. Vi designer og optimerer hardware- og softwarekomponenter, s\u00e5 en s\u00e5dan CDN-server kan sende s\u00e5 meget data som muligt til brugerne. <\/p>\n<p>\u201eV\u00e6ggen\u201c af disse servere ved internettrafikudvekslingspunktet (Internet eXchange \u2014 IX) ser s\u00e5ledes ud:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInternet Exchange giver internetudbydere og indholdsleverand\u00f8rer mulighed for at \u201eforbinde\u201c sig til hinanden for en mere direkte dataudveksling p\u00e5 internettet. Der er omkring 70-80 Internet Exchange-punkter i hele verden, hvor vores servere er installeret, og vi st\u00e5r selv for installation og vedligeholdelse af dem:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerudover leverer vi ogs\u00e5 servere direkte til internetudbydere, som de installerer i deres netv\u00e6rk, hvilket forbedrer lokaliseringsmuligheden for Netflix-trafik og kvaliteten af streaming for brugerne:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt s\u00e6t af AWS-tjenester er ansvarlige for at dirigere videoforekomster fra kunder til CDN-servere, samt konfigurere selve serverne \u2014 opdatering af indhold, programkode, indstillinger osv. Til dette har vi ogs\u00e5 bygget et backbone-netv\u00e6rk, som forbinder servere i Internet Exchange-punkter med AWS. Backbone-netv\u00e6rket best\u00e5r af et globalt netv\u00e6rk af fiberkabler og routere, som vi kan designe og konfigurere baseret p\u00e5 vores behov.<\/p>\n<p>If\u00f8lge <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">vurderinger fra Sandvine<\/a><\/noindex>, vores CDN-infrastruktur leverer i peak-timer cirka \u215b af den globale internettrafik og \u2153 af trafikken i Nordamerika, hvor Netflix har v\u00e6ret l\u00e6ngst. Imponerende tal, men for mig er en af de mest overraskende pr\u00e6stationer, at hele CDN-systemet udvikles og vedligeholdes af et team p\u00e5 mindre end 150 personer.<\/p>\n<p>Oprindeligt blev CDN-infrastrukturen designet til at levere videodata. Men over tid har vi indset, at vi ogs\u00e5 kan bruge den til at optimere dynamiske foresp\u00f8rgsler fra kunder til AWS-skyen.<\/p>\n<h2>Om at accelerere internettet<\/h2>\n<p>\nI dag har Netflix 3 AWS-regioner, og forsinkelsen p\u00e5 foresp\u00f8rgsler til skyen vil afh\u00e6nge af, hvor langt kunden er fra den n\u00e6rmeste region. Samtidig har vi mange CDN-servere, der bruges til at levere statisk indhold. Kan vi p\u00e5 en eller anden m\u00e5de bruge denne infrastruktur til at accelerere dynamiske foresp\u00f8rgsler? Desv\u00e6rre er det ikke muligt at cache disse foresp\u00f8rgsler \u2014 API'er er personaliserede, og hvert resultat er unikt.<\/p>\n<p>Lad os lave en proxy p\u00e5 CDN-serveren og begynde at lede trafikken gennem den. Vil det v\u00e6re hurtigere?<\/p>\n<h2>Materiale<\/h2>\n<p>\nLad os huske, hvordan netv\u00e6rksprotokoller fungerer. I dag bruger st\u00f8rstedelen af trafikken p\u00e5 internettet HTTPS, som afh\u00e6nger af lavere niveau protokoller, TCP og TLS. For at kunden kan oprette forbindelse til serveren, udf\u00f8rer de et handshake, og for at etablere en sikker forbindelse skal kunden udveksle beskeder med serveren tre gange og mindst \u00e9n gang til for at overf\u00f8re data. Ved en forsinkelse p\u00e5 \u00e9n udveksling (RTT) p\u00e5 100 ms vil vi have brug for 400 ms for at f\u00e5 det f\u00f8rste databit:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis vi placerer certifikaterne p\u00e5 CDN-serveren, kan vi v\u00e6sentligt forkorte \"handshake\"-tiden mellem kunden og serveren, hvis CDN ligger t\u00e6ttere p\u00e5. Lad os antage, at forsinkelsen til CDN-serveren er 30 ms. S\u00e5 vil det tage 220 ms for at f\u00e5 det f\u00f8rste databit:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen fordelene stopper ikke her. Efter at forbindelsen er blevet etableret, \u00f8ger TCP congestion vinduet (m\u00e6ngden af information, som den kan overf\u00f8re via denne forbindelse parallelt). Hvis et datapakke g\u00e5r tabt, reducerer klassiske implementeringer af TCP-protokollen (som TCP New Reno) det \u00e5bne \"vindue\" med halvdelen. Stigningen i congestion vinduet, og hastigheden af genopretning efter tab afh\u00e6nger igen af forsinkelsen (RTT) til serveren. Hvis forbindelsen kun g\u00e5r til CDN-serveren, vil denne genopretning v\u00e6re hurtigere. Desuden er pakke tab en standardf\u00e6nomen, is\u00e6r for tr\u00e5dl\u00f8se netv\u00e6rk.<\/p>\n<p>Internetkapaciteten kan falde, is\u00e6r i myldretiden p\u00e5 grund af trafik fra brugerne, hvilket kan f\u00f8re til \"trafikpropper\". P\u00e5 internettet er der ingen m\u00e5de at prioritere nogle anmodninger over andre. For eksempel at prioritere sm\u00e5 og forsinkelsessensitive anmodninger i forhold til \"tunge\" datastreams, der belaster netv\u00e6rket. Men i vores tilf\u00e6lde g\u00f8r vores eget backbone-netv\u00e6rk dette muligt p\u00e5 en del af anmodningens rejse \u2014 mellem CDN og skyen, og vi kan konfigurere det fuldt ud. Vi kan prioritere sm\u00e5 og forsinkelsessensitive pakker, mens store datastreams kan sendes lidt senere. Jo t\u00e6ttere CDN er p\u00e5 kunden \u2014 jo mere effektivt bliver det.<\/p>\n<p>Derudover har applikationslagsprotokoller (OSI niveau 7) ogs\u00e5 indflydelse p\u00e5 forsinkelsen. Nye protokoller som HTTP\/2 tillader en optimering af ydeevnen for parallelle anmodninger. Dog har vores klienter hos Netflix nogle \u00e6ldre enheder, som ikke underst\u00f8tter de nye protokoller. Ikke alle klienter kan opdateres eller optimalt konfigureres. Mellem CDN-proxyen og skyen har vi imidlertid fuld kontrol og muligheden for at bruge nye, optimale protokoller og indstillinger. Den ineffektive del med de gamle protokoller vil kun fungere mellem klienten og CDN-serveren. Desuden kan vi multiplexe anmodninger p\u00e5 det allerede etablerede forbindelsen mellem CDN og skyen, hvilket forbedrer udnyttelsen af forbindelsen p\u00e5 TCP-niveau:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>M\u00e5ling<\/h2>\n<p>\nSelvom teorien lover forbedringer, kaster vi os ikke straks ud i at lancere systemet i produktion. I stedet skal vi f\u00f8rst bevise, at id\u00e9en fungerer i praksis. For at g\u00f8re dette skal vi besvare flere sp\u00f8rgsm\u00e5l:<\/p>\n<ul>\n<li><b>Hastighed<\/b>: Bliver proxyen hurtigere?<\/li>\n<li><b>P\u00e5lidelighed<\/b>: Vil den bryde oftere?<\/li>\n<li><b>Kompleksitet<\/b>: Hvordan integreres det med applikationer?<\/li>\n<li><b>Omkostninger<\/b>: Hvad koster det at implementere yderligere infrastruktur?<\/li>\n<\/ul>\n<p>\nLad os se n\u00e6rmere p\u00e5 vores tilgang til vurderingen af det f\u00f8rste punkt. De andre behandles p\u00e5 en lignende m\u00e5de.<\/p>\n<p>For at analysere hastigheden af anmodninger \u00f8nsker vi at indhente data fra alle brugere uden at bruge meget tid p\u00e5 udvikling og uden at nedbringe produktionen. Der er flere tilgange til dette:<\/p>\n<ol>\n<li>RUM, eller passiv m\u00e5ling af anmodninger. Vi m\u00e5ler den tid, det tager at udf\u00f8re aktuelle anmodninger fra brugere og sikrer fuld d\u00e6kning af brugerne. Ulempen er, at signalet ikke er helt stabilt p\u00e5 grund af mange faktorer, for eksempel forskellige anmodningsst\u00f8rrelser, behandlingstid p\u00e5 serveren og klienten. Derudover kan man ikke teste en ny konfiguration uden effekt p\u00e5 produktionen.<\/li>\n<li>Laboratorietests. Specialiserede servere og infrastruktur, som simulerer kunder. Med dem udf\u00f8rer vi de n\u00f8dvendige tests. P\u00e5 den m\u00e5de opn\u00e5r vi fuld kontrol over m\u00e5leresultaterne og et klart signal. Men der er ikke fuld d\u00e6kning af enheder og brugerplaceringer (is\u00e6r med tjenesten p\u00e5 globalt plan og underst\u00f8ttelse af tusindvis af enhedsmodeller).<\/li>\n<\/ol>\n<p>\nHvordan kan man kombinere fordelene ved begge metoder?<\/p>\n<p>Vores team har fundet en l\u00f8sning. Vi har skrevet et lille stykke kode \u2014 en pr\u00f8vning \u2014 som vi har integreret i vores applikation. Pr\u00f8verne g\u00f8r det muligt for os at udf\u00f8re fuldt kontrollerede netv\u00e6rkstests fra vores enheder. Det fungerer p\u00e5 f\u00f8lgende m\u00e5de: <\/p>\n<ol>\n<li>Kort efter indl\u00e6sningen af applikationen og afslutningen af den indledende aktivitet, starter vi vores pr\u00f8ver. <\/li>\n<li>Klienten sender en anmodning til serveren og modtager 'opskriften' p\u00e5 testen. Opskriften er en liste af URL-adresser, som der skal laves HTTP(s) anmodninger til. Desuden konfigurerer opskriften anmodningens parametre: forsinkelser mellem anmodninger, m\u00e6ngde af forespurgte data, HTTP(s) headers osv. Samtidig kan vi teste flere forskellige opskrifter parallelt \u2014 ved anmodning om konfiguration v\u00e6lges det tilf\u00e6ldigt, hvilken opskrift der skal gives. <\/li>\n<li>Tiden for start af pr\u00f8ven v\u00e6lges, s\u00e5 det ikke konflikerer med aktiv brug af netv\u00e6rksressourcer p\u00e5 klienten. I princippet v\u00e6lges et tidspunkt, n\u00e5r klienten ikke er aktiv.<\/li>\n<li>Efter modtagelsen af opskriften sender klienten anmodninger til hver af URL-adresserne parallelt. Anmodningen til hver af adresserne kan gentages \u2014 de s\u00e5kaldte 'pulser'. Ved den f\u00f8rste puls m\u00e5ler vi, hvor lang tid det tog at oprette forbindelsen og downloade data. Ved den anden puls m\u00e5ler vi tidsforbruget ved overf\u00f8rslen af data gennem den allerede etablerede forbindelse. F\u00f8r den tredje puls kan vi indstille en forsinkelse og m\u00e5le hastigheden for at genoprette forbindelsen osv.\n<p>Under testen m\u00e5ler vi alle parametre, som enheden kan opn\u00e5:<\/p>\n<ul>\n<li>DNS foresp\u00f8rgsels tid;<\/li>\n<li>TCP forbindelsestid;<\/li>\n<li>TLS forbindelsestid;<\/li>\n<li>tid til at modtage det f\u00f8rste byte data;<\/li>\n<li>den samlede indl\u00e6sningstid;<\/li>\n<li>statuskode for resultatet.<\/li>\n<\/ul>\n<\/li>\n<li> Efter alle m\u00e5linger er afsluttet, downloader pr\u00f8ven resultaterne af alle m\u00e5linger til analyse.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00f8glepunkterne er minimal afh\u00e6ngighed af logikken p\u00e5 klienten, databehandling p\u00e5 serveren og m\u00e5ling af parallelle foresp\u00f8rgsler. P\u00e5 denne m\u00e5de f\u00e5r vi mulighed for at isolere og teste indflydelsen af forskellige faktorer, der p\u00e5virker foresp\u00f8rgslernes ydeevne, variere dem inden for en opskrift og opn\u00e5 resultater fra rigtige kunder.<\/p>\n<p>Denne infrastruktur har vist sig nyttig ikke kun til analyse af foresp\u00f8rgslernes ydeevne. I \u00f8jeblikket har vi 14 aktive opskrifter, over 6000 pr\u00f8ver pr. sekund, der indsamler data fra hele verden og d\u00e6kker alle enheder. Hvis Netflix skulle k\u00f8be en s\u00e5dan tjeneste fra tredjepartsfirmaer, ville det koste millioner af dollars om \u00e5ret med meget d\u00e5rligere d\u00e6kning.<\/p>\n<h2>Vi tester teorien i praksis: prototype<\/h2>\n<p>\nMed et s\u00e5dant system har vi f\u00e5et mulighed for at vurdere effektiviteten af CDN proxyen p\u00e5 foresp\u00f8rgselslatens. Nu skal vi:<\/p>\n<ul>\n<li>oprette en proxyprototype;<\/li>\n<li>placere prototypen p\u00e5 CDN;<\/li>\n<li>bestemme, hvordan man dirigerer kunder til proxyen p\u00e5 en bestemt CDN-server;<\/li>\n<li>sammenligne ydeevnen med foresp\u00f8rgsler i AWS uden proxy.<\/li>\n<\/ul>\n<p>\nOpgaven er at vurdere effektiviteten af den foresl\u00e5ede l\u00f8sning s\u00e5 hurtigt som muligt. Til at implementere prototypen valgte vi Go, takket v\u00e6re de gode netv\u00e6rksbiblioteker. P\u00e5 hver CDN-server installerede vi proxyprototypen som en statisk bin\u00e6r fil for at minimere afh\u00e6ngigheder og lette integrationen. I den indledende implementering brugte vi i videst muligt omfang standardkomponenter samt mindre modifikationer til HTTP\/2 connection pooling og request multiplexing.<\/p>\n<p>For balancing between AWS regions, we used a geographical DNS database, the same one used for client balancing. To select a CDN server for the client, we use TCP Anycast for servers in Internet Exchange (IX). In this scenario, we use one IP address for all CDN servers, while the client will be directed to the CDN server with the least number of IP hops. For the CDN servers installed with internet providers (ISP), we have no control over the router to configure TCP Anycast, so we engage <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">the same logic<\/a><\/noindex>, by which clients are directed to internet providers for video streaming.<\/p>\n<p>So, we have three types of paths for the request: to the cloud via the open internet, through a CDN server in IX, or through a CDN server located at the internet provider. Our goal is to understand which path is better, and what benefits a proxy provides compared to how requests are directed in production. To do this, we use a probing system in the following way:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEach path becomes a separate target, and we look at the time we achieved. For analysis, we combine the proxy results into one group (selecting the best time between IX and ISP proxy) and compare it with the time of requests to the cloud without a proxy:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs seen, the results turned out to be ambiguous \u2014 in most cases, the proxy provides a good speedup, but there are also a sufficient number of clients for whom the situation noticeably worsens. <\/p>\n<p>As a result, we accomplished several important things:<\/p>\n<ol>\n<li>We evaluated the expected performance of requests from clients to the cloud via CDN proxy.<\/li>\n<li>We obtained data from real clients across all types of devices.<\/li>\n<li>We understood that the theory was not confirmed 100%, and the initial proposal with CDN proxy will not work for us.<\/li>\n<li>We did not take risks \u2014 we did not change the production configurations for clients.<\/li>\n<li>We did not break anything. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prototype 2.0<\/h2>\n<p>\nSo, we return to the drawing board and repeat the process from scratch.<\/p>\n<p>The idea is to instead of 100% proxy, we will determine the fastest path for each client and direct requests there \u2014 that is, we will do what is called client steering.<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvordan implementerer vi det? Vi kan ikke bruge logik p\u00e5 serversiden, eftersom m\u00e5let er at oprette forbindelse til denne server. Det skal g\u00f8res p\u00e5 klienten, og ideelt set med minimal kompleks logik for at undg\u00e5 integrationsproblemer med et stort antal klientplatforme. <\/p>\n<p>Svaret er brugen af DNS. I vores tilf\u00e6lde har vi vores egen DNS-infrastruktur, og vi kan konfigurere et dom\u00e6neomr\u00e5de, hvor vores servere vil v\u00e6re autoritative. Det fungerer s\u00e5dan:<\/p>\n<ol>\n<li>Klienten sender en anmodning til DNS-serveren ved at bruge en v\u00e6rt, f.eks. api.netflix.com.<\/li>\n<li>Anmodningen n\u00e5r vores DNS-server.<\/li>\n<li>DNS-serveren ved, hvilken rute der er hurtigst for denne klient, og leverer den relevante IP-adresse. <\/li>\n<\/ol>\n<p>\nDer er en ekstra kompleksitet i l\u00f8sningen: autoritative DNS-udbydere ser ikke klientens IP-adresse og kan kun se IP-adressen p\u00e5 den rekursive resolver, som klienten bruger. <\/p>\n<p>I sidste ende skal vores autoritative resolver tr\u00e6ffe beslutninger ikke for en enkelt klient, men for en gruppe af klienter baseret p\u00e5 den rekursive resolver. <\/p>\n<p>For at l\u00f8se dette bruger vi de samme probes, samler m\u00e5leresultater fra klienter fra hver af de rekursive resolvere og beslutter, hvor denne gruppe skal hen \u2014 gennem en proxy via IX ved hj\u00e6lp af TCP Anycast, gennem ISP-proxy eller direkte til skyen.<\/p>\n<p>Vi f\u00e5r et system som dette:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen resulterende model for DNS steering g\u00f8r det muligt at lede klienter baseret p\u00e5 historiske observationer af forbindelseshastigheder fra klienter til skyen. <\/p>\n<p>Igen er sp\u00f8rgsm\u00e5let \u2014 hvor effektivt vil denne tilgang fungere? For at finde ud af det bruger vi igen vores system af probes. Derfor konfigurerer vi en recent-konfiguration, hvor et m\u00e5l f\u00f8lger DNS steering, og et andet g\u00e5r direkte til skyen (nuv\u00e6rende produktion).<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI sidste ende sammenligner vi resultaterne og f\u00e5r en vurdering af effektiviteten:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi har i sidste ende l\u00e6rt nogle vigtige ting:<\/p>\n<ol>\n<li>Vi har vurderet den forventede ydeevne for anmodninger fra kunder til skyen ved hj\u00e6lp af DNS Steering.<\/li>\n<li>We obtained data from real clients across all types of devices.<\/li>\n<li>Vi har bevist effektiviteten af den foresl\u00e5ede id\u00e9.<\/li>\n<li>We did not take risks \u2014 we did not change the production configurations for clients.<\/li>\n<li>We did not break anything.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Nu til det sv\u00e6re \u2014 vi starter i produktion.<\/h2>\n<p>\nDet letteste er nu bag os \u2014 vi har en fungerende prototype. Den sv\u00e6re del nu er at implementere l\u00f8sningen for al Netflix-trafik, udrulle den til 150 millioner brugere, tusindvis af enheder, hundreder af mikroservices og konstant skiftende produkter og infrastruktur. Netflix-serverne modtager millioner af foresp\u00f8rgsler i sekundet, og man kan nemt bryde tjenesten med en uforsigtig handling. Samtidig \u00f8nsker vi at dirigere trafikken dynamisk gennem tusindvis af CDN-servere, i en verden, hvor tingene konstant \u00e6ndrer sig og g\u00e5r i stykker p\u00e5 de mest upassende tidspunkter. <\/p>\n<p>Og p\u00e5 trods af alt dette er der tre ingeni\u00f8rer i teamet, som er ansvarlige for udvikling, implementering og fuld support af systemet.<\/p>\n<p>Derfor vil vi nu tale om rolig og sund s\u00f8vn.<\/p>\n<p>Hvordan forts\u00e6tter man udviklingen, uden at bruge al tiden p\u00e5 support? Vores tilgang bygger p\u00e5 tre principper:<\/p>\n<ol>\n<li>Vi reducerer det potentielle omfang af nedbrud (blast radius). <\/li>\n<li>Vi forbereder os p\u00e5 overraskelser \u2014 vi forventer, at noget g\u00e5r i stykker, p\u00e5 trods af testning og personlig erfaring.<\/li>\n<li>Gradvis nedbrydning (graceful degradation) \u2014 hvis noget ikke fungerer korrekt, skal det automatisk repareres, selvom det m\u00e5ske ikke er den mest effektive m\u00e5de.<\/li>\n<\/ol>\n<p>\nDet viste sig, at i vores tilf\u00e6lde, med denne tilgang til problemet, kunne vi finde en enkel og effektiv l\u00f8sning og g\u00f8re systemsupporten betydeligt enklere. Vi inds\u00e5, at vi kunne tilf\u00f8je et lille stykke kode til klienten og overv\u00e5ge fejl i netv\u00e6rksanmodninger for\u00e5rsaget af forbindelsesproblemer. Ved netv\u00e6rksfejl laver vi fallback direkte til skyen. Denne l\u00f8sning kr\u00e6ver ikke betydelige anstrengelser fra klientteams, men reducerer betydeligt risikoen for uventede nedbrud og overraskelser for os.<\/p>\n<p>Selvf\u00f8lgelig, p\u00e5 trods af fallback, f\u00f8lger vi stadig en klar disciplin i udviklingsprocessen:<\/p>\n<ol>\n<li>Pr\u00f8vetest.<\/li>\n<li>A\/B-test eller Canaries.<\/li>\n<li>Graduel udrulning (progressive rollout).<\/li>\n<\/ol>\n<p>\nMed pr\u00f8verne er tilgangen beskrevet \u2014 \u00e6ndringer testes f\u00f8rst ved hj\u00e6lp af en opsat opskrift.<\/p>\n<p>Til canary-testning skal vi have sammenlignelige par servere, hvor vi kan se, hvordan systemet fungerer f\u00f8r og efter \u00e6ndringer. For dette udtager vi par af servere fra vores mange CDN-sites, som modtager sammenlignelig trafik:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerefter implementerer vi bygningen med \u00e6ndringer p\u00e5 Canary-serverne. For at vurdere resultaterne k\u00f8rer vi et system, der sammenligner cirka 100-150 metrikker med et kontroludvalg af servere:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis Canary-testen er vellykket, ruller vi gradvist op, b\u00f8lge for b\u00f8lge. P\u00e5 hver hjemmeside opdaterer vi ikke serverne samtidigt \u2014 tabet af en hel hjemmeside ved problemer har en mere betydelig indflydelse p\u00e5 servicen for brugerne end tabet af samme antal servere, men p\u00e5 forskellige steder.<\/p>\n<p>Generelt afh\u00e6nger effektiviteten og sikkerheden af denne tilgang af antallet og kvaliteten af de indsamlede metrikker. For vores anmodningsaccelerationssystem indsamler vi metrikker fra alle mulige komponenter: <\/p>\n<ul>\n<li>fra kunder \u2014 antal sessioner og foresp\u00f8rgsler, fallback rates; <\/li>\n<li>proxy \u2014 statistik over antal og tid af foresp\u00f8rgsler;<\/li>\n<li>DNS \u2014 antal og resultater af foresp\u00f8rgsler;<\/li>\n<li>cloud edge \u2014 antal og tid til behandling af foresp\u00f8rgsler i skyen.<\/li>\n<\/ul>\n<p>\nAlt dette samles i en samlet pipeline, og alt efter behov beslutter vi, hvilke metrikker der skal sendes til real-time analyse, og hvilke der skal sendes til Elasticsearch eller Big Data for mere detaljeret diagnose.<\/p>\n<h2>Overv\u00e5gning<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI vores tilf\u00e6lde laver vi \u00e6ndringer p\u00e5 den kritiske vej for foresp\u00f8rgsler mellem kunden og serveren. Antallet af forskellige komponenter p\u00e5 klienten, p\u00e5 serveren og p\u00e5 vejen gennem internettet er enormt. \u00c6ndringer p\u00e5 klienten og serveren sker konstant \u2014 under arbejdet af mange forskellige teams og naturlige \u00e6ndringer i \u00f8kosystemet. Vi er midt imellem \u2014 ved diagnosticering af problemer er der stor chance for, at vi er involveret. Derfor skal vi klart forst\u00e5, hvordan vi definerer, indsamler og analyserer metrikker for hurtig lokaliserings af problemer. <\/p>\n<p>Ideelt set \u2014 fuld adgang til alle slags metrikker og filtre i realtid. Men der er mange metrikker, s\u00e5 sp\u00f8rgsm\u00e5let om omkostninger opst\u00e5r. I vores tilf\u00e6lde adskiller vi metrikker og udviklingsv\u00e6rkt\u00f8jer p\u00e5 f\u00f8lgende m\u00e5de:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTil opdagelse og triage af problemer bruger vi vores egen real-time system med open source <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 til visualisering. Det gemmer aggregerede metrikker i hukommelsen, er p\u00e5lideligt og integreres med alerts-systemet. Til lokaliserings- og diagnoseform\u00e5l har vi adgang til logs fra Elasticsearch og Kibana. Til statistisk analyse og modellering bruger vi big data og visualisering i Tableau.<\/p>\n<p>Det virker som om det er meget besv\u00e6rligt at arbejde med en s\u00e5dan tilgang. Men med en hierarkisk organisering af metrikker og v\u00e6rkt\u00f8jer kan vi hurtigt analysere problemet, identificere problemetypen og derefter - dykke ned i de detaljerede metrikker. For at identificere fejlkilden bruger vi generelt omkring 1-2 minutter. Derefter arbejder vi med et specifikt team p\u00e5 diagnosticeringen - fra flere minutter til nogle timer.<\/p>\n<p>Selv hvis diagnosticeringen foreg\u00e5r hurtigt, \u00f8nsker vi ikke, at det sker ofte. Ideelt set \u00f8nsker vi kun at modtage en kritisk alert, n\u00e5r der er betydelig indflydelse p\u00e5 servicen. For vores foresp\u00f8rgselsaccelerationssystem har vi kun 2 alerts, som vil underrette:<\/p>\n<ul>\n<li>procent Client Fallback - vurdering af kundeadf\u00e6rd;<\/li>\n<li>procent Probe errors - data om stabiliteten af netv\u00e6rkskomponenter.<\/li>\n<\/ul>\n<p>\nDisse kritiske alerts holder \u00f8je med, om systemet fungerer for de fleste brugere. Vi ser p\u00e5, hvor mange kunder der har anvendt fallback, hvis de ikke kunne f\u00e5 accelerationen af foresp\u00f8rgsler. I gennemsnit har vi mindre end 1 kritisk alert om ugen, selvom der sker et enormt antal \u00e6ndringer i systemet. Hvorfor er det tilstr\u00e6kkeligt for os?<\/p>\n<ol>\n<li>Der er client fallback i tilf\u00e6lde af, at vores proxy ikke fungerer.<\/li>\n<li>Der er et automatisk styresystem, der reagerer p\u00e5 problemer.<\/li>\n<\/ol>\n<p>\nLad os g\u00e5 mere i dybden med det sidste. Vores probesystem og systemet til automatisk bestemmelse af den optimale rute for foresp\u00f8rgsler fra klienten til skyen g\u00f8r det muligt automatisk at h\u00e5ndtere nogle problemer. <\/p>\n<p>Lad os vende tilbage til vores konfiguration af probes og 3 kategorier af ruter. Udover indl\u00e6sningstiden kan vi se p\u00e5 selve leveringen. Hvis det ikke lykkes at indl\u00e6se data, kan vi ved at kigge p\u00e5 resultaterne p\u00e5 forskellige ruter bestemme, hvor og hvad der gik galt, og om vi kan reparere det automatisk ved at \u00e6ndre foresp\u00f8rgselsruten.<\/p>\n<p>Eksempler:<\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDenne proces kan automatiseres. Integreres i styresystemet. Og l\u00e6re det at reagere p\u00e5 problemer med ydeevne og p\u00e5lidelighed. Hvis noget begynder at g\u00e5 i stykker - reagere, hvis der er en bedre mulighed. Herudover er \u00f8jeblikkelig reaktion ikke kritisk takket v\u00e6re fallback p\u00e5 klienterne.<\/p>\n<p>Derfor kan principperne for systemunderst\u00f8ttelse formuleres som f\u00f8lger:<\/p>\n<ul>\n<li>reducerer omfanget af fejl;<\/li>\n<li>indsamler metrikker;<\/li>\n<li>reparerer automatisk fejl, hvis vi kan;<\/li>\n<li>hvis ikke, underretter vi;<\/li>\n<li>Vi arbejder p\u00e5 dashboards og triage v\u00e6rkt\u00f8jer for hurtig reaktion.<\/li>\n<\/ul>\n<p><\/p>\n<h2>L\u00e6rte lektioner<\/h2>\n<p>\nDet tager ikke lang tid at skrive en prototype. I vores tilf\u00e6lde var den klar efter blot 4 m\u00e5neder. Med den fik vi nye m\u00e5linger, og efter 10 m\u00e5neder fra udviklingens start modtog vi den f\u00f8rste produktionstrafik. S\u00e5 begyndte det kedelige og meget komplekse arbejde: gradvist at produktivere og skalerer systemet, migrere hovedtrafikken og l\u00e6re af fejlene. Denne effektive proces vil ikke v\u00e6re line\u00e6r \u2014 p\u00e5 trods af alle bestr\u00e6belser kan man ikke forudse alt. Hurtig iteration og respons p\u00e5 nye data er meget mere effektivt. <\/p>\n<p><img decoding=\"async\" alt=\"Vi accelererer internetanmodninger og sover trygt\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUd fra vores erfaring kan vi anbefale f\u00f8lgende:<\/p>\n<ol>\n<li>Tro ikke p\u00e5 din intuition.\n<p>Vores intuition har konstant svigtet os, p\u00e5 trods af det store erfaringsniveau blandt teammedlemmerne. For eksempel foruds\u00e5 vi forkert den forventede acceleration ved brug af CDN-proxyer eller adf\u00e6rden af TCP Anycast.<\/li>\n<li>F\u00e5 data fra produktionen.\n<p>Det er vigtigt at f\u00e5 adgang til mindst en lille m\u00e6ngde produktionsdata s\u00e5 hurtigt som muligt. Antallet af unikke tilf\u00e6lde, konfigurationer og indstillinger under laboratorieforhold er n\u00e6sten umulige at opn\u00e5. Hurtig adgang til resultaterne giver mulighed for hurtigt at opdage potentielle problemer og tage dem med i systemarkitekturen.<\/li>\n<li>F\u00f8lg ikke andres r\u00e5dgivning og resultater \u2014 indsamle dine egne data.\n<p>F\u00f8lg principperne for indsamling og analyse af data, men tag ikke blindt andres resultater og p\u00e5stande. Kun du kan vide pr\u00e6cist, hvad der fungerer for dine brugere. Dine systemer og dine kunder kan v\u00e6re betydeligt forskellige fra andre virksomheder. Heldigvis er v\u00e6rkt\u00f8jerne til analyse nu tilg\u00e6ngelige og lette at bruge. De resultater, du opn\u00e5r, kan ikke stemme overens med det, som Netflix, Facebook, Akamai og andre virksomheder h\u00e6vder. I vores tilf\u00e6lde adskiller ydeevnen af TLS, HTTP2 eller statistikken om DNS-foresp\u00f8rgsler sig fra resultaterne fra Facebook, Uber, Akamai \u2014 fordi vi har andre enheder, kunder og datastreams.<\/li>\n<li>Str\u00e6b ikke efter modetrends un\u00f8digt og uden vurdering af effektiviteten.\n<p>Start simpelt. Det er bedre at lave et simpelt fungerende system p\u00e5 kort tid, end at bruge en enorm m\u00e6ngde tid p\u00e5 at udvikle un\u00f8dvendige komponenter. L\u00f8s opgaver og problemer, der er vigtige baseret p\u00e5 dine m\u00e5linger og resultater. <\/li>\n<li>V\u00e6r klar til nye anvendelser.\n<p>Ligesom det er sv\u00e6rt at forudse alle problemer, er det ogs\u00e5 sv\u00e6rt at forudse fordele og anvendelser. Tag et eksempel fra startups \u2014 deres evne til at tilpasse sig kundernes forhold. I dit tilf\u00e6lde kan du opdage nye problemer og deres l\u00f8sninger. I vores projekt havde vi som m\u00e5l at reducere ventetiden p\u00e5 foresp\u00f8rgsler. Men under analysen og diskussionerne inds\u00e5 vi, at vi ogs\u00e5 kan anvende proxy-servere til:<\/p>\n<ul>\n<li>at fordele trafik mellem AWS-regioner og reducere omkostninger;<\/li>\n<li>at modellere stabiliteten af CDN;<\/li>\n<li>at konfigurere DNS;<\/li>\n<li>at konfigurere TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Konklusion<\/h2>\n<p>\nI rapporten beskrev jeg, hvordan Netflix l\u00f8ser problemet med at fremskynde internetforesp\u00f8rgsler mellem kunder og cloud. Hvordan vi indsamler data ved hj\u00e6lp af systemet til pr\u00f8ver hos kunderne, og bruger de indsamlede historiske data til at dirigere produktionsforesp\u00f8rgsler fra kunderne gennem den hurtigste rute p\u00e5 internettet. Hvordan vi bruger netv\u00e6rksprotokollers principper, vores CDN-infrastruktur, backbone-netv\u00e6rk, og DNS-servere for at opn\u00e5 dette m\u00e5l.<\/p>\n<p>Men vores l\u00f8sning er blot et eksempel p\u00e5, hvordan vi i Netflix implementerede et s\u00e5dant system. Hvad der fungerede for os. Den praktiske del af min rapport til jer \u2014 de udviklings- og supportprincipper, som vi f\u00f8lger for at opn\u00e5 gode resultater.<\/p>\n<p>Vores l\u00f8sning p\u00e5 problemet er m\u00e5ske ikke passende for jer. Men teorien og udviklingsprincipperne forbliver, selv hvis I ikke har jeres egen CDN-infrastruktur, eller hvis jeres infrastruktur er v\u00e6sentligt anderledes end vores. <\/p>\n<p>Vigtigheden af hastigheden af foresp\u00f8rgsler p\u00e5 forretningen forbliver ogs\u00e5. Og selv for en enkel service skal I tr\u00e6ffe valg mellem \"cloud\"-udbydere, serverplaceringer, CDN og DNS-udbydere. Jeres valg vil p\u00e5virke effektiviteten af internetforesp\u00f8rgsler for jeres kunder. Og det er vigtigt for jer at m\u00e5le og forst\u00e5 denne indflydelse.<\/p>\n<p>Start med enkle l\u00f8sninger, v\u00e6r opm\u00e6rksom p\u00e5, hvordan I \u00e6ndrer produktet. L\u00e6r i processen og forbedr systemet baseret p\u00e5 data fra jeres kunder, jeres infrastruktur, og jeres forretning. T\u00e6nk p\u00e5 muligheden for uventede nedbrud under designprocessen. S\u00e5 vil I kunne fremskynde jeres udviklingsproces, forbedre l\u00f8sningens effektivitet, undg\u00e5 un\u00f8dvendig belastning p\u00e5 supporten og sove roligt.<\/p>\n<blockquote><p>I \u00e5r <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">finder konferencen sted fra den 6. til den 10. juli<\/a><\/noindex> i online-formatet. Du vil have mulighed for at stille sp\u00f8rgsm\u00e5l til en af DevOps-f\u00e6drene, nemlig John Willis!<\/p><\/blockquote>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Vi fremskynder internetanmodninger og sover roligt | ProHoster","description":"Netflix er markedslederen inden for internet-tv.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}