Netflix er førende på internet-tv-markedet - virksomheden, der har skabt og aktivt udvikler dette segment. Netflix er ikke kun kendt for sit omfattende katalog over film og tv-serier, der er tilgængelige fra næsten alle hjørner af planeten og enhver enhed med en skærm, men også for sin pålidelige infrastruktur og unikke ingeniørkultur.
Et tydeligt eksempel på Netflix-tilgangen til at udvikle og understøtte komplekse systemer blev præsenteret på DevOops 2019 - Udviklingsdirektør hos Netflix. Uddannet fra fakultetet for beregningsmatematik og matematik ved Nizhny Novgorod State University. Lobachevsky, Sergey en af de første ingeniører i Open Connect - CDN-teamet hos Netflix. Han byggede systemer til overvågning og analyse af videodata, lancerede en populær tjeneste til vurdering af internetforbindelseshastighed FAST.com og har de sidste par år arbejdet på at optimere internetanmodninger, så Netflix-applikationen fungerer så hurtigt som muligt for brugerne.
Rapporten fik de bedste anmeldelser fra konferencedeltagere, og vi har udarbejdet en tekstversion til dig.
I sin rapport talte Sergei i detaljer
- om, hvad der påvirker forsinkelsen af internetanmodninger mellem klienten og serveren;
- hvordan man kan reducere denne forsinkelse;
- hvordan man designer, vedligeholder og overvåger fejltolerante systemer;
- hvordan man opnår resultater på kort tid og med minimal risiko for virksomheden;
- hvordan man analyserer resultater og lærer af fejl.
Svar på disse spørgsmål er ikke kun nødvendige for dem, der arbejder i store virksomheder.
De præsenterede principper og teknikker bør kendes og praktiseres af alle, der udvikler og understøtter internetprodukter.
Dernæst er fortællingen fra talerens perspektiv.
Vigtigheden af internethastighed
Hastigheden af internetanmodninger er direkte relateret til forretning. Overvej shoppingbranchen: Amazon i 2009 at en 100 ms forsinkelse resulterer i et tab på 1 % af salget.
Der er flere og flere mobile enheder, efterfulgt af mobilsider og applikationer. Hvis din side tager længere tid end 3 sekunder at indlæse, mister du omkring halvdelen af dine brugere. MED Google tager højde for din sides indlæsningshastighed i søgeresultaterne: Jo hurtigere siden er, jo højere er dens placering i Google.
Forbindelseshastighed er også vigtig i finansielle institutioner, hvor latency er kritisk. I 2015, Hibernia Networks et kabel på 400 millioner dollars mellem New York og London for at reducere ventetiden mellem byerne med 6 ms. Forestil dig $66 millioner for 1 ms forsinkelsesreduktion!
Ifølge , forbindelseshastigheder over 5 Mbit/s påvirker ikke længere direkte indlæsningshastigheden på et typisk websted. Der er dog et lineært forhold mellem forbindelsesforsinkelse og sideindlæsningshastighed:
Netflix er dog ikke et typisk produkt. Indvirkningen af latens og hastighed på brugeren er et aktivt område for analyse og udvikling. Der er applikationsindlæsning og indholdsvalg, der afhænger af latency, men indlæsning af statiske elementer og streaming afhænger også af forbindelseshastigheden. Analyse og optimering af nøglefaktorer, der påvirker brugeroplevelsen, er et aktivt udviklingsområde for flere teams hos Netflix. Et af målene er at reducere forsinkelsen af anmodninger mellem Netflix-enheder og cloud-infrastrukturen.
I rapporten vil vi fokusere specifikt på at reducere latens ved at bruge eksemplet med Netflix-infrastrukturen. Lad os overveje fra et praktisk synspunkt, hvordan man griber processerne til design, udvikling og drift af komplekse distribuerede systemer og bruger tid på innovation og resultater, snarere end at diagnosticere operationelle problemer og nedbrud.
Inde på Netflix
Tusindvis af forskellige enheder understøtter Netflix-apps. De er udviklet af fire forskellige teams, som laver separate versioner af klienten til Android, iOS, TV og webbrowsere. Og vi bruger mange kræfter på at forbedre og tilpasse brugeroplevelsen. For at gøre dette kører vi hundredvis af A/B-tests parallelt.
Personalisering understøttes af hundredvis af mikrotjenester i AWS-skyen, der leverer personlige brugerdata, forespørgselsafsendelse, telemetri, Big Data og kodning. Trafikvisualisering ser sådan ud:
Til venstre er indgangspunktet, og så er trafikken fordelt på flere hundrede mikrotjenester, der understøttes af forskellige backend-teams.
En anden vigtig komponent i vores infrastruktur er Open Connect CDN, som leverer statisk indhold til slutbrugeren - videoer, billeder, klientkode osv. CDN er placeret på brugerdefinerede servere (OCA - Open Connect Appliance). Indeni er der arrays af SSD- og HDD-drev, der kører optimeret FreeBSD, med NGINX og et sæt tjenester. Vi designer og optimerer hardware- og softwarekomponenter, så en sådan CDN-server kan sende så meget data som muligt til brugerne.
"Væggen" på disse servere ved internettrafikudvekslingspunktet (Internet eXchange - IX) ser sådan ud:
Internet Exchange giver internetudbydere og indholdsudbydere mulighed for at "forbindelse" med hinanden for mere direkte at udveksle data på internettet. Der er cirka 70-80 Internet Exchange-punkter rundt om i verden, hvor vores servere er installeret, og vi installerer og vedligeholder dem uafhængigt:
Derudover leverer vi også servere direkte til internetudbydere, som de installerer i deres netværk, hvilket forbedrer lokaliseringen af Netflix-trafik og kvaliteten af streaming for brugerne:
Et sæt AWS-tjenester er ansvarlige for at sende videoanmodninger fra klienter til CDN-servere, samt konfigurere selve serverne - opdatering af indhold, programkode, indstillinger osv. Til sidstnævnte byggede vi også et backbone-netværk, der forbinder servere i Internet Exchange-punkter med AWS. Backbone-netværket er et globalt netværk af fiberoptiske kabler og routere, som vi kan designe og konfigurere ud fra vores behov.
On , leverer vores CDN-infrastruktur cirka ⅛ af verdens internettrafik i myldretiden og ⅓ af trafikken i Nordamerika, hvor Netflix har eksisteret længst. Imponerende tal, men for mig er en af de mest fantastiske præstationer, at hele CDN-systemet er udviklet og vedligeholdt af et team på mindre end 150 personer.
Oprindeligt blev CDN-infrastrukturen designet til at levere videodata. Men med tiden indså vi, at vi også kan bruge det til at optimere dynamiske anmodninger fra klienter i AWS-skyen.
Om internetacceleration
I dag har Netflix 3 AWS-regioner, og forsinkelsen af anmodninger til skyen vil afhænge af, hvor langt kunden er fra den nærmeste region. Samtidig har vi mange CDN-servere, der bruges til at levere statisk indhold. Er der nogen måde at bruge denne ramme til at fremskynde dynamiske forespørgsler? Men desværre er det umuligt at cache disse anmodninger - API'er er personlige, og hvert resultat er unikt.
Lad os lave en proxy på CDN-serveren og begynde at sende trafik igennem den. Vil det være hurtigere?
Materiel
Lad os huske, hvordan netværksprotokoller fungerer. I dag bruger den meste trafik på internettet HTTPs, hvilket afhænger af de lavere lags protokoller TCP og TLS. For at en klient kan oprette forbindelse til serveren, foretager den et håndtryk, og for at etablere en sikker forbindelse skal klienten udveksle beskeder med serveren tre gange og mindst én gang mere for at overføre data. Med en latency per round trip (RTT) på 100 ms, ville det tage os 400 ms at modtage den første bit data:
Hvis vi placerer certifikaterne på CDN-serveren, så kan handshake-tiden mellem klienten og serveren reduceres væsentligt, hvis CDN er tættere på. Lad os antage, at latensen til CDN-serveren er 30ms. Derefter vil det tage 220 ms at modtage den første bit:
Men fordelene stopper ikke der. Når først en forbindelse er etableret, øger TCP overbelastningsvinduet (mængden af information, som den kan transmittere over denne forbindelse parallelt). Hvis en datapakke går tabt, reducerer klassiske implementeringer af TCP-protokollen (som TCP New Reno) det åbne "vindue" til det halve. Væksten af overbelastningsvinduet og hastigheden af dets genopretning fra tab afhænger igen af forsinkelsen (RTT) til serveren. Hvis denne forbindelse kun går så langt som til CDN-serveren, vil denne gendannelse være hurtigere. Samtidig er pakketab et standardfænomen, især for trådløse netværk.
Internetbåndbredden kan være reduceret, især i myldretiden, på grund af trafik fra brugere, hvilket kan føre til trafikpropper. Der er dog ingen måde på internettet at give prioritet til nogle anmodninger frem for andre. Giv for eksempel prioritet til små og latensfølsomme anmodninger frem for "tunge" datastrømme, der indlæser netværket. Men i vores tilfælde giver vores eget backbone-netværk os mulighed for at gøre dette på en del af anmodningsstien - mellem CDN og skyen, og vi kan konfigurere det fuldt ud. Du kan sørge for, at små og latensfølsomme pakker prioriteres, og store datastrømme går lidt senere. Jo tættere CDN er på klienten, jo større effektivitet.
Protokoller på applikationsniveau (OSI niveau 7) har også indflydelse på latens. Nye protokoller såsom HTTP/2 optimerer ydeevnen af parallelle anmodninger. Vi har dog Netflix-klienter med ældre enheder, der ikke understøtter de nye protokoller. Ikke alle klienter kan opdateres eller konfigureres optimalt. Samtidig er der mellem CDN-proxyen og skyen fuld kontrol og mulighed for at bruge nye, optimale protokoller og indstillinger. Den ineffektive del med gamle protokoller vil kun fungere mellem klienten og CDN-serveren. Desuden kan vi lave multipleksanmodninger på en allerede etableret forbindelse mellem CDN og skyen, hvilket forbedrer forbindelsesudnyttelsen på TCP-niveau:
Vi måler
På trods af at teorien lover forbedringer, skynder vi os ikke umiddelbart med at lancere systemet i produktion. I stedet skal vi først bevise, at ideen fungerer i praksis. For at gøre dette skal du besvare flere spørgsmål:
- hastighed: vil en proxy være hurtigere?
- Pålidelighed: Går den i stykker oftere?
- Kompleksitet: hvordan integreres med applikationer?
- Omkostninger: Hvor meget koster det at implementere yderligere infrastruktur?
Lad os i detaljer overveje vores tilgang til at vurdere det første punkt. Resten behandles på samme måde.
For at analysere hastigheden af anmodninger ønsker vi at skaffe data til alle brugere, uden at bruge en masse tid på udvikling og uden at bryde produktionen. Der er flere tilgange til dette:
- RUM, eller passiv anmodningsmåling. Vi måler eksekveringstiden for aktuelle anmodninger fra brugere og sikrer fuld brugerdækning. Ulempen er, at signalet ikke er særlig stabilt på grund af mange faktorer, for eksempel på grund af forskellige anmodningsstørrelser, behandlingstid på server og klient. Derudover kan du ikke teste en ny konfiguration uden effekt i produktionen.
- Laboratorieundersøgelser. Særlige servere og infrastruktur, der simulerer klienter. Med deres hjælp udfører vi de nødvendige tests. På den måde får vi fuld kontrol over måleresultaterne og et klart signal. Men der er ingen fuldstændig dækning af enheder og brugerplaceringer (især med en verdensomspændende service og support til tusindvis af enhedsmodeller).
Hvordan kan du kombinere fordelene ved begge metoder?
Vores team har fundet en løsning. Vi skrev et lille stykke kode - et eksempel - som vi indbyggede i vores applikation. Prober giver os mulighed for at udføre fuldt kontrollerede netværkstests fra vores enheder. Det fungerer sådan her:
- Kort efter indlæsning af applikationen og afslutning af den indledende aktivitet, kører vi vores sonder.
- Klienten sender en anmodning til serveren og modtager en "opskrift" på testen. Opskriften er en liste over URL'er, som en HTTP(s)-anmodning skal sendes til. Derudover konfigurerer opskriften anmodningsparametre: forsinkelser mellem forespørgsler, mængden af forespurgte data, HTTP(s) headers osv. Samtidig kan vi teste flere forskellige opskrifter parallelt - når vi anmoder om en konfiguration, bestemmer vi tilfældigt, hvilken opskrift der skal udstedes.
- Sondens starttidspunkt er valgt for ikke at komme i konflikt med den aktive brug af netværksressourcer på klienten. I det væsentlige vælges tidspunktet, når klienten ikke er aktiv.
- Efter at have modtaget opskriften, sender klienten anmodninger til hver af URL'erne parallelt. Anmodningen til hver af adresserne kan gentages - den såkaldte. "pulser". På den første puls måler vi, hvor lang tid det tog at etablere en forbindelse og downloade data. På den anden puls måler vi den tid, det tager at indlæse data over en allerede etableret forbindelse. Før den tredje kan vi indstille en forsinkelse og måle hastigheden for at etablere en genforbindelse osv.
Under testen måler vi alle de parametre, som enheden kan opnå:
- DNS-anmodningstid;
- TCP-forbindelse opsætningstid;
- TLS forbindelse opsætningstid;
- tidspunktet for modtagelse af den første byte med data;
- samlet indlæsningstid;
- status resultatkode.
- Når alle pulser er afsluttet, indlæser prøven alle målinger til analyse.
Nøglepunkterne er minimal afhængighed af logik på klienten, databehandling på serveren og måling af parallelle anmodninger. Således er vi i stand til at isolere og teste indflydelsen af forskellige faktorer, der påvirker forespørgselsydelsen, variere dem inden for en enkelt opskrift og opnå resultater fra rigtige kunder.
Denne infrastruktur har vist sig nyttig til mere end blot analyse af forespørgselsydeevne. I øjeblikket har vi 14 aktive opskrifter, mere end 6000 prøver i sekundet, der modtager data fra alle verdenshjørner og fuld enhedsdækning. Hvis Netflix købte en lignende tjeneste fra en tredjepart, ville det koste millioner af dollars om året med meget dårligere dækning.
Testteori i praksis: prototype
Med et sådant system var vi i stand til at evaluere effektiviteten af CDN-proxyer på anmodningsforsinkelse. Nu skal du bruge:
- oprette en proxy prototype;
- placere prototypen på et CDN;
- bestemme, hvordan man dirigerer klienter til en proxy på en specifik CDN-server;
- Sammenlign ydeevne med anmodninger i AWS uden en proxy.
Opgaven er at evaluere effektiviteten af den foreslåede løsning så hurtigt som muligt. Vi valgte Go til at implementere prototypen på grund af tilgængeligheden af gode netværksbiblioteker. På hver CDN-server installerede vi prototypeproxyen som en statisk binær for at minimere afhængigheder og forenkle integrationen. I den indledende implementering brugte vi så vidt muligt standardkomponenter og mindre ændringer til HTTP/2-forbindelsespooling og anmodningsmultipleksing.
For at balancere mellem AWS-regioner brugte vi en geografisk DNS-database, den samme som bruges til at balancere klienter. For at vælge en CDN-server til klienten bruger vi TCP Anycast til servere i Internet Exchange (IX). I denne mulighed bruger vi én IP-adresse til alle CDN-servere, og klienten vil blive dirigeret til CDN-serveren med det mindste antal IP-hop. I CDN-servere installeret af internetudbydere (ISP'er), har vi ikke kontrol over routeren til at konfigurere TCP Anycast, så vi bruger , som dirigerer kunder til internetudbydere for videostreaming.
Så vi har tre typer anmodningsstier: til skyen via det åbne internet, via en CDN-server i IX eller via en CDN-server placeret hos en internetudbyder. Vores mål er at forstå, hvilken vej der er bedre, og hvad der er fordelen ved en proxy sammenlignet med, hvordan anmodninger sendes til produktion. For at gøre dette bruger vi et prøveudtagningssystem som følger:
Hver af stierne bliver et separat mål, og vi ser på den tid, vi fik. Til analyse kombinerer vi proxy-resultaterne i én gruppe (vælg den bedste tid mellem IX- og ISP-proxyer) og sammenligner dem med tidspunktet for anmodninger til skyen uden en proxy:
Som du kan se, var resultaterne blandede - i de fleste tilfælde giver proxyen en god speedup, men der er også et tilstrækkeligt antal klienter, for hvem situationen vil forværres væsentligt.
Som et resultat gjorde vi flere vigtige ting:
- Vi vurderede den forventede ydeevne af anmodninger fra klienter til skyen via en CDN-proxy.
- Vi modtog data fra rigtige kunder, fra alle typer enheder.
- Vi indså, at teorien ikke var 100 % bekræftet, og det oprindelige tilbud med en CDN-proxy ville ikke fungere for os.
- Vi tog ikke risici - vi ændrede ikke produktionskonfigurationer for kunder.
- Intet var i stykker.
Prototype 2.0
Så tilbage til tegnebrættet og gentag processen igen.
Ideen er, at vi i stedet for at bruge en 100% proxy bestemmer den hurtigste vej for hver klient, og vi sender forespørgsler dertil - det vil sige, at vi laver det, der kaldes klientstyring.
Hvordan implementerer man dette? Vi kan ikke bruge logik på serversiden, fordi... Målet er at oprette forbindelse til denne server. Der skal være en måde at gøre dette på hos klienten. Og ideelt set gør dette med et minimum af kompleks logik for ikke at løse problemet med integration med et stort antal klientplatforme.
Svaret er at bruge DNS. I vores tilfælde har vi vores egen DNS-infrastruktur, og vi kan oprette en domænezone, som vores servere vil være autoritære for. Det fungerer sådan her:
- Klienten laver en anmodning til DNS-serveren ved hjælp af en vært, for eksempel api.netflix.xom.
- Anmodningen ankommer til vores DNS-server
- DNS-serveren ved, hvilken sti der er den hurtigste for denne klient og udsteder den tilsvarende IP-adresse.
Løsningen har en ekstra kompleksitet: autoritære DNS-udbydere kan ikke se klientens IP-adresse og kan kun læse IP-adressen på den rekursive resolver, som klienten bruger.
Som følge heraf skal vores autoritære resolver træffe en beslutning ikke for en individuel klient, men for en gruppe klienter baseret på den rekursive resolver.
For at løse det bruger vi de samme prøver, samler måleresultaterne fra klienter for hver af de rekursive resolvere og beslutter, hvor vi skal sende denne gruppe af dem - en proxy gennem IX ved hjælp af TCP Anycast, gennem en ISP-proxy eller direkte til skyen.
Vi får følgende system:
Den resulterende DNS-styringsmodel giver dig mulighed for at dirigere klienter baseret på historiske observationer af hastigheden af forbindelser fra klienter til skyen.
Igen er spørgsmålet, hvor effektivt denne tilgang vil fungere? For at svare bruger vi igen vores sondesystem. Derfor konfigurerer vi presenter-konfigurationen, hvor et af målene følger retningen fra DNS-styring, det andet går direkte til skyen (aktuel produktion).
Som et resultat sammenligner vi resultaterne og får en vurdering af effektiviteten:
Som et resultat lærte vi flere vigtige ting:
- Vi vurderede den forventede ydeevne af anmodninger fra klienter til skyen ved hjælp af DNS Steering.
- Vi modtog data fra rigtige kunder, fra alle typer enheder.
- Effektiviteten af den foreslåede idé er blevet bevist.
- Vi tog ikke risici - vi ændrede ikke produktionskonfigurationer for kunder.
- Intet var i stykker.
Nu om den svære del - vi lancerer den i produktion
Den nemme del er nu forbi - der er en fungerende prototype. Nu er den svære del at lancere en løsning til al Netflix' trafik, der implementeres til 150 millioner brugere, tusindvis af enheder, hundredvis af mikrotjenester og et produkt og infrastruktur i konstant forandring. Netflix-servere modtager millioner af anmodninger i sekundet, og det er nemt at bryde tjenesten med skødesløs handling. Samtidig ønsker vi dynamisk at dirigere trafik gennem tusindvis af CDN-servere på internettet, hvor noget ændrer sig og går i stykker konstant og på det mest uhensigtsmæssige tidspunkt.
Og med alt dette har teamet 3 ingeniører, der er ansvarlige for udvikling, implementering og fuld support af systemet.
Derfor vil vi fortsætte med at tale om afslappende og sund søvn.
Hvordan fortsætter du udviklingen og ikke bruger al din tid på support? Vores tilgang er baseret på 3 principper:
- Vi reducerer det potentielle omfang af nedbrud (sprængningsradius).
- Vi forbereder os på overraskelser - vi forventer, at noget går i stykker, trods test og personlig erfaring.
- Yndefuld nedbrydning - hvis noget ikke fungerer korrekt, bør det ordnes automatisk, selvom det ikke er på den mest effektive måde.
Det viste sig, at i vores tilfælde, med denne tilgang til problemet, kan vi finde en enkel og effektiv løsning og væsentligt forenkle systemsupporten. Vi indså, at vi kunne tilføje et lille stykke kode til klienten og overvåge netværksanmodningsfejl forårsaget af forbindelsesproblemer. I tilfælde af netværksfejl laver vi et fallback direkte til skyen. Denne løsning kræver ikke væsentlig indsats for kundeteams, men reducerer i høj grad risikoen for uventede nedbrud og overraskelser for os.
På trods af tilbagefaldet følger vi selvfølgelig en klar disciplin under udviklingen:
- Prøveprøve.
- A/B-test eller Kanariske Øer.
- Progressiv udrulning.
Med prøver er fremgangsmåden beskrevet - ændringer testes først ved hjælp af en tilpasset opskrift.
Til kanarietest skal vi have sammenlignelige par servere, hvorpå vi kan sammenligne, hvordan systemet fungerer før og efter ændringerne. For at gøre dette vælger vi fra vores mange CDN-websteder et par servere, der modtager sammenlignelig trafik:
Derefter installerer vi buildet med ændringerne på Canary-serveren. For at evaluere resultaterne kører vi et system, der sammenligner ca. 100-150 metrics med en prøve af kontrolservere:
Hvis Canary-testen lykkes, frigiver vi den gradvist i bølger. Vi opdaterer ikke servere på hver side på samme tid - at miste en hel side på grund af problemer har en mere væsentlig indflydelse på tjenesten for brugerne end at miste det samme antal servere på forskellige lokationer.
Generelt afhænger effektiviteten og sikkerheden af denne tilgang af mængden og kvaliteten af de indsamlede metrics. Til vores forespørgselsaccelerationssystem indsamler vi metrics fra alle mulige komponenter:
- fra kunder - antal sessioner og anmodninger, fallback rater;
- proxy - statistik over antallet og tidspunktet for anmodninger;
- DNS - antal og resultater af anmodninger;
- cloud edge - antal og tid for behandling af anmodninger i skyen.
Alt dette samles i en enkelt pipeline, og afhængigt af behovene beslutter vi, hvilke metrics der skal sendes til realtidsanalyser, og hvilke til Elasticsearch eller Big Data for mere detaljeret diagnostik.
Vi overvåger
I vores tilfælde foretager vi ændringer på den kritiske vej for anmodninger mellem klienten og serveren. Samtidig er antallet af forskellige komponenter på klienten, på serveren og på vejen gennem internettet enormt. Ændringer på klienten og serveren sker konstant - under arbejdet i snesevis af teams og naturlige ændringer i økosystemet. Vi er i midten - når vi diagnosticerer problemer, er der en god chance for, at vi bliver involveret. Derfor er vi nødt til klart at forstå, hvordan man definerer, indsamler og analyserer metrics for hurtigt at isolere problemer.
Ideelt set fuld adgang til alle typer målinger og filtre i realtid. Men der er mange målinger, så spørgsmålet om omkostninger opstår. I vores tilfælde adskiller vi metrics og udviklingsværktøjer som følger:
Til at opdage og triage problemer bruger vi vores eget open source realtidssystem и - til visualisering. Den gemmer aggregerede metrics i hukommelsen, er pålidelig og integrerer med alarmsystemet. Til lokalisering og diagnostik har vi adgang til logfiler fra Elasticsearch og Kibana. Til statistisk analyse og modellering bruger vi big data og visualisering i Tableau.
Det ser ud til, at denne tilgang er meget svær at arbejde med. Ved at organisere metrics og værktøjer hierarkisk kan vi dog hurtigt analysere et problem, bestemme typen af problem og derefter bore ned i detaljerede metrics. Generelt bruger vi omkring 1-2 minutter på at identificere kilden til sammenbruddet. Herefter arbejder vi med et specifikt team om diagnostik – fra snesevis af minutter til flere timer.
Selvom diagnosen stilles hurtigt, ønsker vi ikke, at det sker ofte. Ideelt set vil vi kun modtage en kritisk advarsel, når der er en væsentlig indvirkning på tjenesten. Til vores forespørgselsaccelerationssystem har vi kun 2 advarsler, der giver besked:
- Client Fallback-procent - vurdering af kundeadfærd;
- procent Probe fejl - stabilitetsdata for netværkskomponenter.
Disse kritiske advarsler overvåger, om systemet fungerer for de fleste brugere. Vi ser på, hvor mange kunder der brugte fallback, hvis de ikke var i stand til at få anmodningsacceleration. Vi har i gennemsnit mindre end 1 kritisk alarm om ugen, selvom der er et væld af ændringer i gang i systemet. Hvorfor er det nok for os?
- Der er en kundetilbagegang, hvis vores proxy ikke virker.
- Der er et automatisk styresystem, der reagerer på problemer.
Flere detaljer om sidstnævnte. Vores prøvesystem, og systemet til automatisk at bestemme den optimale vej for anmodninger fra klienten til skyen, giver os mulighed for automatisk at håndtere nogle problemer.
Lad os vende tilbage til vores eksempelkonfiguration og 3 stikategorier. Ud over indlæsningstid kan vi se på selve leveringen. Hvis det ikke var muligt at indlæse dataene, så kan vi ved at se på resultaterne langs forskellige stier bestemme, hvor og hvad der gik i stykker, og om vi automatisk kan rette det ved at ændre anmodningsstien.
Eksempler:
Denne proces kan automatiseres. Inkluder det i styresystemet. Og lær den at reagere på problemer med ydeevne og pålidelighed. Hvis noget begynder at gå i stykker, så reager, hvis der er en bedre mulighed. Samtidig er en øjeblikkelig reaktion ikke kritisk, takket være tilbagefald på kunder.
Principperne for systemunderstøttelse kan således formuleres som følger:
- reduktion af omfanget af nedbrud;
- indsamling af metrikker;
- Vi reparerer automatisk nedbrud, hvis vi kan;
- hvis det ikke kan, giver vi dig besked;
- Vi arbejder på dashboards og triage-værktøjssæt for hurtig respons.
Erfaringer
Det tager ikke meget tid at skrive en prototype. I vores tilfælde var den klar efter 4 måneder. Med den fik vi nye målinger, og 10 måneder efter udviklingsstart modtog vi den første produktionstrafik. Derefter begyndte det kedelige og meget vanskelige arbejde: gradvist produktiser og skaler systemet, migrér hovedtrafikken og lær af fejl. Denne effektive proces vil dog ikke være lineær - på trods af alle anstrengelser kan alt ikke forudsiges. Det er meget mere effektivt hurtigt at gentage og reagere på nye data.
Baseret på vores erfaring kan vi anbefale følgende:
- Stol ikke på din intuition.
Vores intuition svigtede os konstant, på trods af vores teammedlemmers store erfaring. For eksempel forudsagde vi forkert den forventede hastighedsstigning fra brug af en CDN-proxy eller adfærden hos TCP Anycast.
- Få data fra produktionen.
Det er vigtigt at få adgang til mindst en lille mængde produktionsdata så hurtigt som muligt. Det er næsten umuligt at opnå antallet af unikke tilfælde, konfigurationer og indstillinger under laboratorieforhold. Hurtig adgang til resultaterne giver dig mulighed for hurtigt at lære om potentielle problemer og tage højde for dem i systemarkitekturen.
- Følg ikke andres råd og resultater – saml dine egne data.
Følg principperne for indsamling og analyse af data, men accepter ikke blindt andres resultater og udsagn. Kun du kan vide præcis, hvad der virker for dine brugere. Dine systemer og dine kunder kan være væsentligt forskellige fra andre virksomheder. Heldigvis er analyseværktøjer nu tilgængelige og nemme at bruge. De resultater, du får, er muligvis ikke, hvad Netflix, Facebook, Akamai og andre virksomheder hævder. I vores tilfælde adskiller udførelsen af TLS, HTTP2 eller statistik på DNS-anmodninger sig fra resultaterne af Facebook, Uber, Akamai - fordi vi har forskellige enheder, klienter og datastrømme.
- Følg ikke modetrends unødigt og evaluer effektiviteten.
Start enkelt. Det er bedre at lave et simpelt fungerende system på kort tid end at bruge en enorm mængde tid på at udvikle komponenter, som du ikke har brug for. Løs opgaver og problemer, der betyder noget ud fra dine målinger og resultater.
- Gør dig klar til nye applikationer.
Ligesom det er svært at forudsige alle problemerne, er det svært at forudsige fordele og anvendelser på forhånd. Tag udgangspunkt i startups - deres evne til at tilpasse sig kundernes forhold. I dit tilfælde kan du opdage nye problemer og deres løsninger. I vores projekt satte vi et mål om at reducere anmodningsforsinkelse. Men under analysen og diskussionerne indså vi, at vi også kan bruge proxy-servere:
- at balancere trafik på tværs af AWS-regioner og reducere omkostningerne;
- at modellere CDN-stabilitet;
- at konfigurere DNS;
- for at konfigurere TLS/TCP.
Konklusion
I rapporten beskrev jeg, hvordan Netflix løser problemet med at accelerere internetanmodninger mellem klienter og skyen. Hvordan vi indsamler data ved hjælp af et prøveudtagningssystem på kunder og bruger de indsamlede historiske data til at dirigere produktionsanmodninger fra kunder gennem den hurtigste vej på internettet. Hvordan vi bruger principperne for netværksprotokoller, vores CDN-infrastruktur, backbone-netværk og DNS-servere til at udføre denne opgave.
Vores løsning er dog blot et eksempel på, hvordan vi hos Netflix implementerede sådan et system. Hvad virkede for os. Den anvendte del af min rapport til dig er principperne for udvikling og støtte, som vi følger og opnår gode resultater.
Vores løsning på problemet passer måske ikke dig. Teorien og designprincipperne forbliver dog, selvom du ikke har din egen CDN-infrastruktur, eller hvis den adskiller sig væsentligt fra vores.
Vigtigheden af hastigheden af forretningsanmodninger er også fortsat vigtig. Og selv for en simpel tjeneste skal du træffe et valg: mellem cloud-udbydere, serverplacering, CDN- og DNS-udbydere. Dit valg vil påvirke effektiviteten af internetforespørgsler for dine kunder. Og det er vigtigt for dig at måle og forstå denne indflydelse.
Start med enkle løsninger, vær opmærksom på, hvordan du ændrer produktet. Lær mens du går og forbedre systemet baseret på data fra dine kunder, din infrastruktur og din virksomhed. Tænk på muligheden for uventede nedbrud under designprocessen. Og så kan du fremskynde din udviklingsproces, forbedre løsningseffektiviteten, undgå unødvendig supportbyrde og sove roligt.
I år i online format. Du kan stille spørgsmål til en af DevOps' fædre, selveste John Willis!
Kilde: www.habr.com