Få fart på internettforespørsler og sov rolig

Netflix er ledende innen internett-TV-markedet - selskapet som opprettet og aktivt utvikler dette segmentet. Netflix er ikke bare kjent for sin omfattende katalog over filmer og TV-serier tilgjengelig fra nesten alle hjørner av planeten og alle enheter med skjerm, men også for sin pålitelige infrastruktur og unike ingeniørkultur.

Et tydelig eksempel på Netflix-tilnærmingen til å utvikle og støtte komplekse systemer ble presentert på DevOops 2019 Sergei Fedorov - Utviklingsdirektør hos Netflix. Utdannet ved fakultetet for beregningsmatematikk og matematikk ved Nizhny Novgorod State University. Lobachevsky, Sergey en av de første ingeniørene i Open Connect - CDN-teamet hos Netflix. Han bygde systemer for overvåking og analyse av videodata, lanserte en populær tjeneste for å vurdere Internett-tilkoblingshastighet FAST.com, og har de siste årene jobbet med å optimalisere Internett-forespørsler slik at Netflix-applikasjonen fungerer så raskt som mulig for brukerne.

Rapporten fikk de beste anmeldelser fra konferansedeltakerne, og vi har utarbeidet en tekstversjon for deg.

I sin rapport snakket Sergei i detalj

• om hva som påvirker forsinkelsen av Internett-forespørsler mellom klienten og serveren;
• hvordan redusere denne forsinkelsen;
• hvordan designe, vedlikeholde og overvåke feiltolerante systemer;
• hvordan oppnå resultater på kort tid, og med minimal risiko for virksomheten;
• hvordan analysere resultater og lære av feil.

Svar på disse spørsmålene trengs ikke bare av de som jobber i store selskaper.

De presenterte prinsippene og teknikkene bør være kjent og praktisert av alle som utvikler og støtter Internett-produkter.

Neste er fortellingen fra foredragsholderens perspektiv.

Viktigheten av internetthastighet

Hastigheten på Internett-forespørsler er direkte relatert til virksomheten. Tenk på shoppingbransjen: Amazon i 2009 snakketat en 100 ms forsinkelse resulterer i et tap på 1 % av salget.

Det er flere og flere mobile enheter, etterfulgt av mobilsider og applikasjoner. Hvis siden din tar mer enn 3 sekunder å laste, mister du omtrent halvparten av brukerne. MED juli 2018 Google tar hensyn til lastehastigheten til siden din i søkeresultatene: jo raskere siden, desto høyere plassering i Google.

Tilkoblingshastighet er også viktig i finansinstitusjoner hvor latens er kritisk. I 2015, Hibernia Networks ferdig en kabel på 400 millioner dollar mellom New York og London for å redusere ventetiden mellom byene med 6 ms. Tenk deg $66 millioner for 1 ms reduksjon i ventetid!

Ifølge Lete, tilkoblingshastigheter over 5 Mbit/s påvirker ikke lenger lastehastigheten til et typisk nettsted direkte. Det er imidlertid et lineært forhold mellom tilkoblingsforsinkelse og sidelastingshastighet:

Netflix er imidlertid ikke et typisk produkt. Virkningen av latens og hastighet på brukeren er et aktivt område for analyse og utvikling. Det er applikasjonslasting og innholdsvalg som avhenger av latens, men lasting av statiske elementer og streaming avhenger også av tilkoblingshastighet. Å analysere og optimalisere nøkkelfaktorene som påvirker brukeropplevelsen er et aktivt utviklingsområde for flere team hos Netflix. Et av målene er å redusere ventetiden for forespørsler mellom Netflix-enheter og skyinfrastrukturen.

I rapporten vil vi fokusere spesifikt på å redusere ventetiden ved å bruke eksemplet med Netflix-infrastrukturen. La oss vurdere fra et praktisk synspunkt hvordan vi skal nærme oss prosessene for design, utvikling og drift av komplekse distribuerte systemer og bruke tid på innovasjon og resultater, i stedet for å diagnostisere driftsproblemer og sammenbrudd.

Inne på Netflix

Tusenvis av forskjellige enheter støtter Netflix-apper. De er utviklet av fire forskjellige team, som hver lager separate klientversjoner for Android, iOS, TV og nettlesere. Vi jobber også hardt med å forbedre og tilpasse brukeropplevelsen, og kjører hundrevis av A/B-tester parallelt.

Personalisering støttes av hundrevis av mikrotjenester i AWS-skyen, som gir personlig tilpassede brukerdata, sending av spørringer, telemetri, Big Data og koding. Trafikkvisualisering ser slik ut:

Link til video med demonstrasjon (6:04-6:23)

Til venstre er inngangspunktet, og deretter fordeles trafikken på flere hundre mikrotjenester som støttes av forskjellige backend-team.

En annen viktig komponent i infrastrukturen vår er Open Connect CDN, som leverer statisk innhold til sluttbrukeren – videoer, bilder, klientkode osv. CDN er plassert på egendefinerte servere (OCA - Open Connect Appliance). Inne er det en rekke SSD- og HDD-stasjoner som kjører optimalisert FreeBSD, med NGINX og et sett med tjenester. Vi designer og optimaliserer maskinvare- og programvarekomponenter slik at en slik CDN-server kan sende så mye data som mulig til brukerne.

"Veggen" til disse serverne ved utvekslingspunktet for Internett-trafikk (Internet eXchange - IX) ser slik ut:

Internet Exchange gir Internett-tjenesteleverandører og innholdsleverandører muligheten til å "koble seg" til hverandre for å utveksle data mer direkte på Internett. Det er omtrent 70-80 Internet Exchange-punkter rundt om i verden hvor serverne våre er installert, og vi installerer og vedlikeholder dem uavhengig:

I tillegg leverer vi også servere direkte til Internett-leverandører, som de installerer i nettverket sitt, noe som forbedrer lokaliseringen av Netflix-trafikk og kvaliteten på strømming for brukere:

Et sett med AWS-tjenester er ansvarlig for å sende videoforespørsler fra klienter til CDN-servere, samt konfigurere selve serverne - oppdatering av innhold, programkode, innstillinger osv. For sistnevnte bygde vi også et ryggradsnettverk som kobler servere i Internet Exchange-punkter med AWS. Stamnettverket er et globalt nettverk av fiberoptiske kabler og rutere som vi kan designe og konfigurere basert på våre behov.

På Sandvine anslår, leverer CDN-infrastrukturen vår omtrent ⅛ av verdens Internett-trafikk i rushtiden og ⅓ av trafikken i Nord-Amerika, der Netflix har eksistert lengst. Imponerende tall, men for meg er en av de mest fantastiske prestasjonene at hele CDN-systemet er utviklet og vedlikeholdt av et team på mindre enn 150 personer.

Opprinnelig ble CDN-infrastrukturen designet for å levere videodata. Men over tid innså vi at vi også kan bruke det til å optimalisere dynamiske forespørsler fra klienter i AWS-skyen.

Om Internett-akselerasjon

I dag har Netflix 3 AWS-regioner, og ventetiden på forespørsler til skyen vil avhenge av hvor langt kunden er fra nærmeste region. Samtidig har vi mange CDN-servere som brukes til å levere statisk innhold. Er det noen måte å bruke dette rammeverket for å øke hastigheten på dynamiske spørringer? Imidlertid er det dessverre umulig å cache disse forespørslene - APIer er personlig tilpasset og hvert resultat er unikt.

La oss lage en proxy på CDN-serveren og begynne å sende trafikk gjennom den. Blir det raskere?

materiell

La oss huske hvordan nettverksprotokoller fungerer. I dag bruker mesteparten av trafikken på Internett HTTP-er, noe som avhenger av de lavere lagprotokollene TCP og TLS. For at en klient skal koble til serveren, utfører den et håndtrykk, og for å etablere en sikker tilkobling, må klienten utveksle meldinger med serveren tre ganger og minst én gang til for å overføre data. Med en ventetid per rundtur (RTT) på 100 ms, vil det ta oss 400 ms å motta den første databiten:

Hvis vi plasserer sertifikatene på CDN-serveren, kan håndtrykktiden mellom klienten og serveren reduseres betydelig hvis CDN-en er nærmere. La oss anta at ventetiden til CDN-serveren er 30 ms. Deretter vil det ta 220 ms å motta den første biten:

Men fordelene slutter ikke der. Når en forbindelse er opprettet, øker TCP overbelastningsvinduet (mengden informasjon den kan overføre over den forbindelsen parallelt). Hvis en datapakke går tapt, reduserer klassiske implementeringer av TCP-protokollen (som TCP New Reno) det åpne "vinduet" med det halve. Veksten av overbelastningsvinduet og hastigheten på dets utvinning fra tap avhenger igjen av forsinkelsen (RTT) til serveren. Hvis denne tilkoblingen bare går så langt som til CDN-serveren, vil denne gjenopprettingen gå raskere. Samtidig er pakketap et standardfenomen, spesielt for trådløse nettverk.

Internett-båndbredden kan reduseres, spesielt i rushtiden, på grunn av trafikk fra brukere, noe som kan føre til trafikkork. Imidlertid er det ingen måte på Internett å prioritere noen forespørsler fremfor andre. Gi for eksempel prioritet til små og latenssensitive forespørsler fremfor "tunge" datastrømmer som laster nettverket. Men i vårt tilfelle lar det å ha vårt eget ryggradsnettverk oss gjøre dette på en del av forespørselsbanen - mellom CDN og skyen, og vi kan konfigurere det fullt ut. Du kan sørge for at små og latenssensitive pakker blir prioritert, og store dataflyter går litt senere. Jo nærmere CDN er klienten, jo større effektivitet.

Protokoller på applikasjonsnivå (OSI Level 7) har også innvirkning på latens. Nye protokoller som HTTP/2 optimerer ytelsen til parallelle forespørsler. Imidlertid har vi Netflix-klienter med eldre enheter som ikke støtter de nye protokollene. Ikke alle klienter kan oppdateres eller konfigureres optimalt. Samtidig er det mellom CDN-proxyen og skyen full kontroll og muligheten til å bruke nye, optimale protokoller og innstillinger. Den ineffektive delen med gamle protokoller vil kun fungere mellom klienten og CDN-serveren. Dessuten kan vi lage multiplekse forespørsler på en allerede etablert forbindelse mellom CDN og skyen, og forbedre tilkoblingsutnyttelsen på TCP-nivå:

Vi måler

Til tross for at teorien lover forbedringer, haster vi ikke umiddelbart med å lansere systemet i produksjon. I stedet må vi først bevise at ideen vil fungere i praksis. For å gjøre dette må du svare på flere spørsmål:

• Fart: vil en proxy være raskere?
• Pålitelighet: Vil den gå i stykker oftere?
• Kompleksitet: hvordan integrere med applikasjoner?
• Koste: Hvor mye koster det å distribuere ekstra infrastruktur?

La oss vurdere i detalj vår tilnærming til å vurdere det første punktet. Resten behandles på lignende måte.

For å analysere hastigheten på forespørsler ønsker vi å skaffe data for alle brukere, uten å bruke mye tid på utvikling og uten å bryte produksjonen. Det er flere tilnærminger for dette:

1. RUM, eller passiv forespørselsmåling. Vi måler gjennomføringstiden for aktuelle forespørsler fra brukere og sikrer full brukerdekning. Ulempen er at signalet er lite stabilt på grunn av mange faktorer, for eksempel på grunn av ulike forespørselsstørrelser, behandlingstid på server og klient. I tillegg kan du ikke teste en ny konfigurasjon uten effekt i produksjonen.
2. Laboratorietester. Spesielle servere og infrastruktur som simulerer klienter. Med deres hjelp utfører vi de nødvendige testene. På denne måten får vi full kontroll over måleresultatene og et tydelig signal. Men det er ingen fullstendig dekning av enheter og brukerplasseringer (spesielt med en verdensomspennende tjeneste og støtte for tusenvis av enhetsmodeller).

Hvordan kan du kombinere fordelene med begge metodene?

Teamet vårt har funnet en løsning. Vi skrev en liten kodebit – en prøve – som vi bygde inn i applikasjonen vår. Prober lar oss utføre fullstendig kontrollerte nettverkstester fra enhetene våre. Det fungerer slik:

1. Kort tid etter at applikasjonen er lastet inn og den første aktiviteten er fullført, kjører vi sonder.
2. Klienten sender en forespørsel til serveren og mottar en "oppskrift" for testen. Oppskriften er en liste over URL-er som en HTTP(e)-forespørsel må sendes til. I tillegg konfigurerer oppskriften forespørselsparametere: forsinkelser mellom forespørsler, mengde forespurte data, HTTP(e)-header, etc. Samtidig kan vi teste flere forskjellige oppskrifter parallelt - når vi ber om en konfigurasjon, bestemmer vi tilfeldig hvilken oppskrift som skal utstedes.
3. Probelanseringstiden velges for ikke å komme i konflikt med aktiv bruk av nettverksressurser på klienten. I hovedsak velges tidspunktet når klienten ikke er aktiv.
4. Etter å ha mottatt oppskriften, sender klienten forespørsler til hver av URL-ene, parallelt. Forespørselen til hver av adressene kan gjentas - den såkalte. "pulser". På første puls måler vi hvor lang tid det tok å opprette en forbindelse og laste ned data. På den andre pulsen måler vi tiden det tar å laste data over en allerede etablert forbindelse. Før den tredje kan vi stille inn en forsinkelse og måle hastigheten for å etablere en gjentilkobling osv.

   Under testen måler vi alle parameterne som enheten kan oppnå:

   • DNS-forespørselstid;
   • Oppsetttid for TCP-tilkobling;
   • Oppsetttid for TLS-tilkobling;
   • tidspunkt for mottak av den første byten med data;
   • total lastetid;
   • status resultatkode.
5. Etter at alle pulser er fullført, laster prøven alle målinger for analyse.

Nøkkelpunktene er minimal avhengighet av logikk på klienten, databehandling på serveren og måling av parallelle forespørsler. Dermed er vi i stand til å isolere og teste påvirkningen av ulike faktorer som påvirker søkeytelsen, variere dem innenfor en enkelt oppskrift og få resultater fra ekte kunder.

Denne infrastrukturen har vist seg nyttig for mer enn bare analyse av spørringsytelse. For øyeblikket har vi 14 aktive oppskrifter, mer enn 6000 prøver per sekund, som mottar data fra alle verdenshjørner og full enhetsdekning. Hvis Netflix kjøpte en lignende tjeneste fra en tredjepart, ville det koste millioner av dollar i året, med mye dårligere dekning.

Testteori i praksis: prototype

Med et slikt system var vi i stand til å evaluere effektiviteten til CDN-proxyer på forespørselsforsinkelse. Nå trenger du:

• lage en proxy-prototype;
• plasser prototypen på en CDN;
• bestemme hvordan klienter skal dirigeres til en proxy på en spesifikk CDN-server;
• Sammenlign ytelse med forespørsler i AWS uten proxy.

Oppgaven er å evaluere effektiviteten til den foreslåtte løsningen så raskt som mulig. Vi valgte Go for å implementere prototypen på grunn av tilgjengeligheten av gode nettverksbiblioteker. På hver CDN-server installerte vi prototypeproxyen som en statisk binær for å minimere avhengigheter og forenkle integrasjonen. I den første implementeringen brukte vi standardkomponenter så mye som mulig og mindre modifikasjoner for HTTP/2-tilkoblingspooling og forespørselsmultipleksing.

For å balansere mellom AWS-regioner brukte vi en geografisk DNS-database, den samme som ble brukt til å balansere klienter. For å velge en CDN-server for klienten bruker vi TCP Anycast for servere i Internet Exchange (IX). I dette alternativet bruker vi én IP-adresse for alle CDN-servere, og klienten vil bli dirigert til CDN-serveren med minst antall IP-hopp. I CDN-servere installert av Internett-leverandører (ISP-er), har vi ikke kontroll over ruteren for å konfigurere TCP Anycast, så vi bruker samme logikk, som leder kunder til Internett-leverandører for videostreaming.

Så vi har tre typer forespørselsstier: til skyen via det åpne Internett, via en CDN-server i IX, eller via en CDN-server som ligger hos en Internett-leverandør. Målet vårt er å forstå hvilken vei som er bedre, og hva som er fordelen med en proxy, sammenlignet med hvordan forespørsler sendes til produksjon. For å gjøre dette bruker vi et prøvetakingssystem som følger:

Hver av stiene blir et eget mål, og vi ser på tiden vi fikk. For analyse kombinerer vi proxy-resultatene i én gruppe (velg den beste tiden mellom IX- og ISP-proxyer), og sammenligner dem med tidspunktet for forespørsler til skyen uten proxy:

Som du kan se, var resultatene blandede - i de fleste tilfeller gir proxyen en god hastighet, men det er også et tilstrekkelig antall klienter som situasjonen vil forverres betydelig for.

Som et resultat gjorde vi flere viktige ting:

1. Vi vurderte forventet ytelse av forespørsler fra klienter til skyen via en CDN-proxy.
2. Vi mottok data fra ekte kunder, fra alle typer enheter.
3. Vi innså at teorien ikke var 100 % bekreftet, og det første tilbudet med en CDN-proxy ville ikke fungere for oss.
4. Vi tok ikke risiko - vi endret ikke produksjonskonfigurasjoner for klienter.
5. Ingenting var ødelagt.

Prototype 2.0

Så tilbake til tegnebrettet og gjenta prosessen på nytt.

Tanken er at i stedet for å bruke en 100 % proxy, skal vi bestemme den raskeste veien for hver klient, og vi vil sende forespørsler dit – det vil si at vi skal gjøre det som kalles klientstyring.

Hvordan implementere dette? Vi kan ikke bruke logikk på serversiden, fordi... Målet er å koble til denne serveren. Det må være en måte å gjøre dette på hos klienten. Og ideelt sett gjør dette med et minimum av kompleks logikk, for ikke å løse problemet med integrasjon med et stort antall klientplattformer.

Svaret er å bruke DNS. I vårt tilfelle har vi vår egen DNS-infrastruktur, og vi kan sette opp en domenesone som våre servere vil være autoritære for. Det fungerer slik:

1. Klienten sender en forespørsel til DNS-serveren ved å bruke en vert, for eksempel api.netflix.xom.
2. Forespørselen kommer til vår DNS-server
3. DNS-serveren vet hvilken bane som er den raskeste for denne klienten og utsteder den tilsvarende IP-adressen.

Løsningen har en ekstra kompleksitet: autoritære DNS-leverandører ser ikke klientens IP-adresse og kan kun lese IP-adressen til den rekursive resolveren som klienten bruker.

Som et resultat må vår autoritære resolver ikke ta en beslutning for en individuell klient, men for en gruppe klienter basert på den rekursive resolveren.

For å løse det bruker vi de samme prøvene, samler måleresultatene fra klienter for hver av de rekursive resolverne og bestemmer hvor vi skal sende denne gruppen av dem - en proxy gjennom IX ved hjelp av TCP Anycast, gjennom en ISP-proxy, eller direkte til skyen.

Vi får følgende system:

Den resulterende DNS-styringsmodellen lar deg dirigere klienter basert på historiske observasjoner av hastigheten på tilkoblinger fra klienter til skyen.

Igjen er spørsmålet hvor effektivt denne tilnærmingen vil fungere? For å svare bruker vi igjen sondesystemet vårt. Derfor konfigurerer vi presentatørkonfigurasjonen, der ett av målene følger retningen fra DNS-styring, det andre går direkte til skyen (nåværende produksjon).

Som et resultat sammenligner vi resultatene og får en vurdering av effektiviteten:

Som et resultat lærte vi flere viktige ting:

1. Vi vurderte forventet ytelse av forespørsler fra klienter til skyen ved hjelp av DNS Steering.
2. Vi mottok data fra ekte kunder, fra alle typer enheter.
3. Effektiviteten til den foreslåtte ideen er bevist.
4. Vi tok ikke risiko - vi endret ikke produksjonskonfigurasjoner for klienter.
5. Ingenting var ødelagt.

Nå om den vanskelige delen - vi lanserer den i produksjon

Den enkle delen er nå over - det er en fungerende prototype. Nå er den vanskelige delen å lansere en løsning for all Netflix-trafikk, som distribueres til 150 millioner brukere, tusenvis av enheter, hundrevis av mikrotjenester og et produkt og infrastruktur i stadig endring. Netflix-servere mottar millioner av forespørsler per sekund, og det er lett å bryte tjenesten med uforsiktig handling. Samtidig ønsker vi å rute trafikk dynamisk gjennom tusenvis av CDN-servere på Internett, hvor noe endres og går i stykker konstant og i det mest uleilige øyeblikk.

Og med alt dette har teamet 3 ingeniører som er ansvarlige for utvikling, distribusjon og full støtte for systemet.

Derfor vil vi fortsette å snakke om avslappende og sunn søvn.

Hvordan fortsette utviklingen og ikke bruke all tid på support? Vår tilnærming er basert på 3 prinsipper:

1. Vi reduserer det potensielle omfanget av havari (eksplosjonsradius).
2. Vi forbereder oss på overraskelser – vi forventer at noe går i stykker, til tross for testing og personlig erfaring.
3. Grasiøs nedbrytning - hvis noe ikke fungerer som det skal, bør det fikses automatisk, selv om det ikke er på den mest effektive måten.

Det viste seg at i vårt tilfelle, med denne tilnærmingen til problemet, kan vi finne en enkel og effektiv løsning og betydelig forenkle systemstøtten. Vi innså at vi kunne legge til en liten kodebit til klienten og overvåke for nettverksforespørselsfeil forårsaket av tilkoblingsproblemer. Ved nettverksfeil gjør vi en fallback direkte til skyen. Denne løsningen krever ikke betydelig innsats for kundeteamene, men reduserer risikoen for uventede sammenbrudd og overraskelser i stor grad for oss.

Til tross for fallback følger vi selvfølgelig en klar disiplin under utviklingen:

1. Prøveprøve.
2. A/B-testing eller Kanariøyene.
3. Progressiv utrulling.

Med prøver er tilnærmingen beskrevet - endringer testes først ved hjelp av en tilpasset oppskrift.

For kanaritesting må vi få sammenlignbare serverpar som vi kan sammenligne hvordan systemet fungerer på før og etter endringene. For å gjøre dette, fra våre mange CDN-nettsteder, velger vi serverpar som mottar sammenlignbar trafikk:

Deretter installerer vi bygget med endringene på Canary-serveren. For å evaluere resultatene kjører vi et system som sammenligner omtrent 100–150 beregninger med et utvalg av kontrollservere:

Hvis Canary-testingen er vellykket, slipper vi den gradvis, i bølger. Vi oppdaterer ikke servere på hver side samtidig - å miste en hel side på grunn av problemer har en større innvirkning på tjenesten for brukere enn å miste samme antall servere på forskjellige steder.

Generelt avhenger effektiviteten og sikkerheten til denne tilnærmingen av kvantiteten og kvaliteten på de innsamlede beregningene. For søkeakselerasjonssystemet vårt samler vi inn beregninger fra alle mulige komponenter:

• fra klienter - antall økter og forespørsler, reservefrekvenser;
• proxy - statistikk over antall og tidspunkt for forespørsler;
• DNS - antall og resultater av forespørsler;
• cloud edge - antall og tid for behandling av forespørsler i skyen.

Alt dette samles i én enkelt pipeline, og avhengig av behovene bestemmer vi hvilke beregninger som skal sendes til sanntidsanalyse, og hvilke til Elasticsearch eller Big Data for mer detaljert diagnostikk.

Vi overvåker

I vårt tilfelle gjør vi endringer på den kritiske banen for forespørsler mellom klienten og serveren. Samtidig er antallet forskjellige komponenter på klienten, på serveren og på veien gjennom Internett enormt. Endringer på klienten og serveren skjer konstant - under arbeidet til dusinvis av team og naturlige endringer i økosystemet. Vi er i midten - når vi diagnostiserer problemer, er det en god sjanse for at vi blir involvert. Derfor må vi tydelig forstå hvordan vi definerer, samler inn og analyserer beregninger for raskt å isolere problemer.

Ideelt sett full tilgang til alle typer beregninger og filtre i sanntid. Men det er mange beregninger, så spørsmålet om kostnad oppstår. I vårt tilfelle skiller vi beregninger og utviklingsverktøy som følger:

For å oppdage og triage problemer bruker vi vårt eget åpen kildekode sanntidssystem Atlas и Lumen - for visualisering. Den lagrer aggregerte beregninger i minnet, er pålitelig og integreres med varslingssystemet. For lokalisering og diagnostikk har vi tilgang til logger fra Elasticsearch og Kibana. For statistisk analyse og modellering bruker vi big data og visualisering i Tableau.

Det ser ut til at denne tilnærmingen er svært vanskelig å jobbe med. Men ved å organisere beregninger og verktøy hierarkisk, kan vi raskt analysere et problem, bestemme typen problem og deretter se nærmere på detaljerte beregninger. Generelt bruker vi omtrent 1-2 minutter på å identifisere kilden til sammenbruddet. Etter dette jobber vi med et spesifikt team om diagnostikk – fra titalls minutter til flere timer.

Selv om diagnosen stilles raskt, ønsker vi ikke at dette skal skje ofte. Ideelt sett vil vi bare motta et kritisk varsel når det er en betydelig innvirkning på tjenesten. For søkeakselerasjonssystemet vårt har vi bare to varsler som vil varsle:

• Client Fallback-prosent - vurdering av kundeadferd;
• prosent sondefeil - stabilitetsdata for nettverkskomponenter.

Disse kritiske varslene overvåker om systemet fungerer for de fleste brukere. Vi ser på hvor mange kunder som brukte fallback hvis de ikke var i stand til å få forespørselsakselerasjon. Vi gjennomsnittlig mindre enn 1 kritisk varsling per uke, selv om det er massevis av endringer på gang i systemet. Hvorfor er dette nok for oss?

1. Det er et tilbakefall av klienten hvis proxyen vår ikke fungerer.
2. Det er et automatisk styresystem som reagerer på problemer.

Flere detaljer om sistnevnte. Vårt prøvesystem, og systemet for automatisk å bestemme den optimale banen for forespørsler fra klienten til skyen, lar oss automatisk takle noen problemer.

La oss gå tilbake til vår eksempelkonfigurasjon og 3 banekategorier. I tillegg til lastetid kan vi se på selve leveringen. Hvis det ikke var mulig å laste inn dataene, kan vi ved å se på resultatene langs forskjellige baner finne ut hvor og hva som brøt, og om vi automatisk kan fikse det ved å endre forespørselsbanen.

Eksempler:

Denne prosessen kan automatiseres. Ta den med i styresystemet. Og lær den å reagere på ytelses- og pålitelighetsproblemer. Hvis noe begynner å gå i stykker, reager hvis det er et bedre alternativ. Samtidig er en umiddelbar reaksjon ikke kritisk, takket være tilbakefall på klienter.

Derfor kan prinsippene for systemstøtte formuleres som følger:

• redusere omfanget av sammenbrudd;
• samle inn beregninger;
• Vi reparerer automatisk havari hvis vi kan;
• hvis det ikke kan, varsler vi deg;
• Vi jobber med dashbord og triage-verktøysett for rask respons.

Lærdom

Det tar ikke mye tid å skrive en prototype. I vårt tilfelle var den klar etter 4 måneder. Med den fikk vi nye målinger, og 10 måneder etter utviklingsstart fikk vi den første produksjonstrafikken. Så begynte det kjedelige og svært vanskelige arbeidet: Produktiser og skaler systemet gradvis, migrér hovedtrafikken og lær av feil. Denne effektive prosessen vil imidlertid ikke være lineær - til tross for all innsats, kan ikke alt forutsies. Det er mye mer effektivt å raskt gjenta og svare på nye data.

Basert på vår erfaring kan vi anbefale følgende:

1. Ikke stol på intuisjonen din.

   Intuisjonen vår sviktet oss hele tiden, til tross for teammedlemmenes enorme erfaring. For eksempel spådde vi feil forventet hastighetsøkning fra bruk av en CDN-proxy, eller oppførselen til TCP Anycast.

2. Få data fra produksjonen.

   Det er viktig å få tilgang til minst en liten mengde produksjonsdata så raskt som mulig. Det er nesten umulig å få tak i antall unike tilfeller, konfigurasjoner og innstillinger under laboratorieforhold. Rask tilgang til resultatene lar deg raskt lære om potensielle problemer og ta hensyn til dem i systemarkitekturen.

3. Ikke følg andres råd og resultater – samle inn dine egne data.

   Følg prinsippene for innsamling og analyse av data, men aksepter ikke blindt andres resultater og utsagn. Bare du kan vite nøyaktig hva som fungerer for brukerne dine. Dine systemer og dine kunder kan være vesentlig forskjellige fra andre selskaper. Heldigvis er analyseverktøy nå tilgjengelige og enkle å bruke. Resultatene du får er kanskje ikke det Netflix, Facebook, Akamai og andre selskaper hevder. I vårt tilfelle avviker ytelsen til TLS, HTTP2 eller statistikk på DNS-forespørsler fra resultatene til Facebook, Uber, Akamai – fordi vi har forskjellige enheter, klienter og dataflyter.

4. Ikke følg motetrender unødvendig og vurder effektiviteten.

   Start enkelt. Det er bedre å lage et enkelt fungerende system på kort tid enn å bruke mye tid på å utvikle komponenter som du ikke trenger. Løs oppgaver og problemer som betyr noe basert på dine målinger og resultater.

5. Gjør deg klar for nye applikasjoner.

   Akkurat som det er vanskelig å forutsi alle problemene, er det vanskelig å forutsi fordelene og anvendelsene på forhånd. Ta en pekepinn fra startups - deres evne til å tilpasse seg kundenes forhold. I ditt tilfelle kan du oppdage nye problemer og deres løsninger. I prosjektet vårt har vi satt et mål om å redusere forespørselsforsinkelse. Under analysen og diskusjonene innså vi imidlertid at vi også kan bruke proxy-servere:

   • å balansere trafikk på tvers av AWS-regioner og redusere kostnadene;
   • å modellere CDN-stabilitet;
   • å konfigurere DNS;
   • for å konfigurere TLS/TCP.

Konklusjon

I rapporten beskrev jeg hvordan Netflix løser problemet med å akselerere Internett-forespørsler mellom klienter og skyen. Hvordan vi samler inn data ved hjelp av et prøvetakingssystem på klienter, og bruker de innsamlede historiske dataene til å rute produksjonsforespørsler fra klienter gjennom den raskeste banen på Internett. Hvordan vi bruker prinsippene for nettverksprotokoller, vår CDN-infrastruktur, ryggradsnettverk og DNS-servere for å oppnå denne oppgaven.

Løsningen vår er imidlertid bare et eksempel på hvordan vi i Netflix implementerte et slikt system. Hva fungerte for oss. Den anvendte delen av rapporten min for deg er prinsippene for utvikling og støtte som vi følger og oppnår gode resultater.

Vår løsning på problemet passer kanskje ikke deg. Teorien og designprinsippene består imidlertid, selv om du ikke har din egen CDN-infrastruktur, eller om den skiller seg vesentlig fra vår.

Viktigheten av hastigheten på forretningsforespørsler er fortsatt viktig. Og selv for en enkel tjeneste må du ta et valg: mellom skyleverandører, serverplassering, CDN- og DNS-leverandører. Ditt valg vil påvirke effektiviteten til Internett-søk for kundene dine. Og det er viktig for deg å måle og forstå denne påvirkningen.

Start med enkle løsninger, bry deg om hvordan du endrer produktet. Lær mens du går og forbedre systemet basert på data fra kundene dine, infrastrukturen din og virksomheten din. Tenk på muligheten for uventede sammenbrudd under designprosessen. Og så kan du øke hastigheten på utviklingsprosessen, forbedre løsningseffektiviteten, unngå unødvendig støttebelastning og sove rolig.

dette året konferansen holdes fra 6. til 10. juli i nettformat. Du kan stille spørsmål til en av fedrene til DevOps, selveste John Willis!

Kilde: www.habr.com