Netflix â marknadsledare inom internet-TV â Ă€r företaget som skapade och aktivt utvecklar detta segment. Netflix Ă€r inte bara kĂ€nt för sin omfattande katalog av filmer och serier, tillgĂ€ngliga frĂ„n nĂ€stan vilken plats som helst pĂ„ planeten och pĂ„ alla enheter med skĂ€rm, utan ocksĂ„ för sin pĂ„litliga infrastruktur och unika ingenjörskultur.
Ett tydligt exempel pĂ„ Netflix strategi för att utveckla och underhĂ„lla komplexa system presenterades pĂ„ DevOops 2019. â chef för utveckling pĂ„ Netflix. Han Ă€r alumn frĂ„n fakulteten för Datavetenskap pĂ„ NNGU, och Sergey Ă€r en av de första ingenjörerna i Open Connect â CDN-teamet pĂ„ Netflix. Han har byggt övervaknings- och analyssystem för videodata, lanserat den populĂ€ra tjĂ€nsten FAST.com för att mĂ€ta internethastighet och har de senaste Ă„ren arbetat med att optimera internetförfrĂ„gningar sĂ„ att Netflix-appen fungerar sĂ„ snabbt som möjligt för anvĂ€ndarna.
Föredraget fick utmÀrkta recensioner frÄn konferensens deltagare, och vi har förberett en textversion för er.
I föredraget berÀttade Sergey detaljerat
- om vad som pÄverkar fördröjningen av internetförfrÄgningar mellan klienten och servern;
- hur man minskar dessa fördröjningar;
- hur man designar, upprÀtthÄller och övervakar felresistenta system;
- hur man uppnÄr resultat pÄ kort tid med minimal risk för verksamheten;
- hur man analyserar resultat och lÀr sig av misstagen.
Svar pÄ dessa frÄgor Àr viktiga inte bara för dem som arbetar i stora företag.
De presenterade principerna och teknikerna bör varje person som utvecklar och underhÄller internetprodukter kÀnna till och praktisera.
Vidare â berĂ€ttelsen frĂ„n talarens perspektiv.
Vikten av internethastighet
Hastigheten pÄ internetförfrÄgningar Àr direkt kopplad till affÀrer. LÄt oss ta shoppingomrÄdet som exempel: företaget Amazon sa 2009 Antalet mobila enheter ökar, liksom antalet mobilsidor och appar. Om din sida laddar lÀngre Àn 3 sekunder, förlorar du cirka hÀlften av anvÀndarna.
Sedan sÄ tar Google hÀnsyn till hur snabbt din sida laddar i sökresultaten: ju snabbare sidan Àr, desto högre placering fÄr den i Google.
Anslutningshastighet Àr ocksÄ viktig inom finansiella institutioner dÀr fördröjning Àr kritisk. à r 2015 avslutade företaget Hibernia Networks en kabeldragning mellan New York och London för 400 miljoner dollar för att minska fördröjningen mellan stÀderna med 6 ms. TÀnk dig, 66 miljoner dollar för 1 ms minskning av fördröjning!
Enligt , hastigheten pÄ anslutningen över 5 Mbit/s slutar pÄverka laddningstiden för en typisk webbplats direkt. Det finns dock en linjÀr relation mellan fördröjningen av anslutningen och laddningstiden för sidan:
Men Netflix Àr inte en typisk produkt. Effekten av fördröjning och hastighet pÄ anvÀndaren Àr ett aktivt forsknings- och utvecklingsomrÄde. Det finns laddning av applikationen och val av innehÄll som beror pÄ fördröjning, men laddning av statiska element och streaming beror ocksÄ pÄ hastigheten pÄ anslutningen. Analys och optimering av de nyckelfaktorer som pÄverkar kvaliteten pÄ tjÀnsten för anvÀndaren Àr ett aktivt forskningsomrÄde för flera team inom Netflix. Ett av mÄlen Àr att minska fördröjningen mellan Netflix-enheter och den molnbaserade infrastrukturen.
I rapporten kommer vi att fokusera pÄ att minska fördröjningen (latency) med exempel frÄn Netflix-infrastrukturen. Vi kommer att se pÄ hur vi praktiskt kan nÀrma oss design-, utvecklings- och driftprocesser för komplexa distribuerade system och anvÀnda tiden pÄ innovation och resultat snarare Àn pÄ att diagnostisera driftsproblem och fel.
Inom Netflix
Tusentals olika enheter stöder Netflix-appar. Deras utveckling hanteras av fyra olika team som gör separata versioner av klienter för Android, iOS, TV och webblÀsare. Vi lÀgger mycket tid och kraft pÄ att förbÀttra och anpassa anvÀndargrÀnssnittet. För detta ÀndamÄl genomför vi parallellt hundratals A/B-tester.
Personalisering stöds av hundratals mikrotjÀnster i AWS-molnet som tillhandahÄller personligt anpassade data för anvÀndaren, begÀrningshantering, telemetri, Big Data och Encoding. Trafikvisualiseringen ser ut sÄ hÀr:
Till vÀnster finns entry point, och sedan fördelas trafiken mellan flera hundra mikrotjÀnster som stöds av olika backend-team.
En annan viktig komponent i vĂ„r infrastruktur Ă€r Open Connect CDN, som levererar statiskt innehĂ„ll till slutanvĂ€ndaren â video, bilder, kod för klienter, osv. CDN ligger pĂ„ anpassade servrar (OCA â Open Connect Appliance). Inuti finns SSD- och HDD-disksystem som styrs av en optimerad FreeBSD, med NGINX och en uppsĂ€ttning tjĂ€nster. Vi designar och optimerar hĂ„rdvaru- och programkomponenter sĂ„ att en sĂ„dan CDN-server kan skicka sĂ„ mycket data som möjligt till anvĂ€ndarna.
"VĂ€ggen" av dessa servrar pĂ„ internettrafikens utbytespunkt (Internet eXchange â IX) ser ut sĂ„ hĂ€r:
Internet Exchange ger möjlighet för internetleverantörer och innehÄllsleverantörer att "koppla ihop" med varandra för en mer direkt datautbyte pÄ internet. Det finns cirka 70-80 Internet Exchange-punkter runt om i vÀrlden dÀr vÄra servrar Àr installerade, och vi hanterar sjÀlva deras installation och underhÄll:
Dessutom tillhandahÄller vi ocksÄ servrar direkt till internetleverantörer, som de installerar i sitt nÀtverk, vilket förbÀttrar lokaliseringen av Netflix-trafiken och strömmande kvalitet för anvÀndarna:
En uppsĂ€ttning AWS-tjĂ€nster ansvarar för dirigering av videoförfrĂ„gningar frĂ„n kunder till CDN-servrar, samt konfiguration av sjĂ€lva servrarna â uppdatering av innehĂ„ll, programkod, instĂ€llningar osv. För detta har vi ocksĂ„ byggt ett backbone-nĂ€tverk som ansluter servrar pĂ„ Internet Exchange-punkter med AWS. Backbone-nĂ€tverket Ă€r ett globalt nĂ€tverk av fiberoptiska kablar och routrar, som vi kan designa och konfigurera utifrĂ„n vĂ„ra behov.
uttalandet , vĂ„r CDN-infrastruktur levererar under peak timmar ungefĂ€r â av det globala internettrafiken och â av trafiken i Nordamerika, dĂ€r Netflix har funnits lĂ€ngst. Imponerande siffror, men för mig Ă€r en av de mest otroliga prestationerna att hela CDN-systemet utvecklas och underhĂ„lls av ett team pĂ„ mindre Ă€n 150 personer.
Ursprungligen var CDN-infrastrukturen designad för att leverera videodata. Men med tiden insÄg vi att vi Àven kunde anvÀnda den för att optimera dynamiska förfrÄgningar frÄn kunder till AWS-molnet.
Om att pÄskynda internet
I dag har Netflix 3 AWS-regioner, og forsinkelsen av forespĂžrselen til skyen vil avhenge av hvor langt kunden er fra den nĂŠrmeste regionen. Samtidig har vi en rekke CDN-servere som brukes til levering av statisk innhold. Er det en mĂ„te Ă„ bruke denne infrastrukturen pĂ„ for Ă„ akselerere dynamiske forespĂžrsel? Dessverre kan vi ikke cache disse forespĂžrslene â APIene er personaliserte og hvert resultat er unikt.
La oss lage en proxy pÄ CDN-serveren og begynne Ä kjÞre trafikken gjennom den. Vil dette vÊre raskere?
Materie
La oss huske hvordan nettverksprotokoller fungerer. I dag bruker stÞrstedelen av trafikken pÄ internett HTTPs, som er avhengig av lavere nivÄ protokoller som TCP og TLS. For at klienten skal koble seg til serveren, gjennomfÞrer den et handshake, og for Ä opprette en sikker forbindelse mÄ klienten utveksle meldinger med serveren tre ganger, og minst én gang til for Ä overfÞre data. Med en forsinkelse pÄ ett utvekslingsparti (RTT) pÄ 100 ms trenger vi 400 ms for Ä motta det fÞrste databit:
Hvis sertifikatene er plassert pÄ CDN-serveren, kan vi betydelig redusere tiden for «hÄndtrykk» mellom klienten og serveren, hvis CDN er nÊrmere. Anta at forsinkelsen til CDN-serveren er 30 ms. Da vil det ta 220 ms for Ä fÄ det fÞrste databit:
Men fordelene slutter ikke der. NĂ„r forbindelsen allerede er opprettet, Ăžker TCP congestion window (mengden informasjon som kan overfĂžres parallelt over denne forbindelsen). Hvis et dataparti gĂ„r tapt, reduserer de klassiske implementasjonene av TCP-protokollen (som TCP New Reno) det Ă„pne «vinduet» med halvparten. Ăkningen av congestion window, og hastigheten pĂ„ gjenoppretting fra tap, avhenger igjen av forsinkelsen (RTT) til serveren. Hvis denne forbindelsen bare gĂ„r til CDN-serveren, vil gjenopprettingen vĂŠre raskere. Tap av pakker er en standardforeteelse, spesielt for trĂ„dlĂžse nettverk.
Internetkapaciteten kan minska, sĂ€rskilt under rusningstid pĂ„ grund av trafik frĂ„n anvĂ€ndare, vilket kan leda till "köer". Det finns ingen möjlighet pĂ„ internet att ge prioritet Ă„t vissa förfrĂ„gningar framför andra. Till exempel, att ge prioritet Ă„t mindre och tidskĂ€nsliga förfrĂ„gningar i förhĂ„llande till "tunga" datastreams som belastar nĂ€tverket. I vĂ„rt fall gör dock vĂ„r egen backbone-nĂ€tverk det möjligt att göra detta pĂ„ en del av begĂ€ran â mellan CDN och molnet, och vi kan konfigurera det helt. Vi kan stĂ€lla in sĂ„ att smĂ„ och fördröjningskĂ€nsliga paket prioriteras, medan större datastreams skickas nĂ„got senare. Ju nĂ€rmare CDN Ă€r kunden, desto mer effektivitet.
Dessutom pÄverkar aprotokollen pÄ applikationsnivÄ (OSI-nivÄ 7) latensen. Nya protokoll som HTTP/2 gör det möjligt att optimera prestandan för parallella förfrÄgningar. Men vi har Netflix-kunder med Àldre enheter som inte stöder nya protokoll. Inte alla kunder kan uppgraderas eller optimeras. Medan mellan CDN-proxy och molnet har vi full kontroll och möjlighet att anvÀnda nya, optimala protokoll och instÀllningar. Den ineffektiva delen med gamla protokoll kommer endast att agera mellan kunden och CDN-servern. Dessutom kan vi multiplexera förfrÄgningar pÄ en redan etablerad anslutning mellan CDN och molnet, vilket förbÀttrar utnyttjandet av anslutningen pÄ TCP-nivÄn:
MĂ€ta
Trots att teorin lovar förbÀttringar, kastar vi oss inte direkt in i produktion. IstÀllet mÄste vi först bevisa att idén fungerar i praktiken. För detta behöver vi svara pÄ nÄgra frÄgor:
- Hastighet: Kommer proxy vara snabbare?
- PÄlitlighet: Kommer det oftare att gÄ sönder?
- Komplexitet: Hur integrera med applikationer?
- Kostnad: Hur mycket kostar det att driftsÀtta ytterligare infrastruktur?
LÄt oss titta nÀrmare pÄ vÄr metod för att utvÀrdera den första punkten. De övriga behandlas pÄ liknande sÀtt.
För att analysera hastigheten pÄ förfrÄgningar vill vi fÄ data för alla anvÀndare, utan att spendera mycket tid pÄ utveckling och utan att bryta produktionen. För detta finns det flera angreppssÀtt:
- RUM, eller passiv mÀtning av förfrÄgningar. Vi mÀter tiden för nuvarande förfrÄgningar frÄn anvÀndarna och sÀkerstÀller fullstÀndig anvÀndartÀckning. Nackdelen Àr en inte sÀrskilt stabil signal pÄ grund av mÄnga faktorer, sÄsom olika storlekar pÄ förfrÄgningarna, behandlingstid pÄ servern och klienten. Dessutom kan man inte testa en ny konfiguration utan effekt pÄ produktion.
- Laboratorietester. Speciella servrar och infrastruktur som imiterar kunder. Genom dessa utför vi nödvÀndiga tester. PÄ sÄ sÀtt fÄr vi fullstÀndig kontroll över mÀtresultaten och ett tydligt signal. Men det finns ingen fullstÀndig tÀckning av enheter och anvÀndarlÀgen (sÀrskilt med en tjÀnst över hela vÀrlden och stöd för tusentals enhetsmodeller).
Hur kan man kombinera fördelarna med bÄda metoderna?
VĂ„rt team har hittat en lösning. Vi skrev en liten kodsnutt â en probe â som vi integrerade i vĂ„r applikation. Prober lĂ„ter oss göra helt kontrollerade nĂ€tverkstester frĂ„n vĂ„ra enheter. Det fungerar pĂ„ följande sĂ€tt:
- Strax efter att appen har laddats ner och den initiala aktiviteten har avslutats startar vi vÄra prober.
- Kunden gör en begĂ€ran till servern och fĂ„r ett "recept" för testet. Receptet Ă€r en lista med URL-adresser som HTTP(s) begĂ€ran ska göras mot. Utöver detta konfigurerar receptet begĂ€rningsparametrar: fördröjningar mellan begĂ€rningar, mĂ€ngd begĂ€rda data, HTTP(s) headers osv. Dessutom kan vi parallellt testa flera olika recept â vid begĂ€ran om konfiguration bestĂ€ms slumpmĂ€ssigt vilket recept som ska ges.
- Tidpunkten för start av proben vÀljs sÄ att den inte krockar med aktiv anvÀndning av nÀtverksresurser pÄ kunden. I praktiken vÀljs tiden nÀr kunden inte Àr aktiv.
- Efter att ha mottagit receptet gör kunden begĂ€rningar till var och en av URL-adresserna parallellt. BegĂ€ran till varje adress kan upprepas â sĂ„ kallade "pulser". Vid den första pulsen mĂ€ter vi hur lĂ„ng tid det tog att etablera en koppling och ladda ner data. Vid den andra pulsen mĂ€ter vi tiden för att ladda ner data via den redan etablerade kopplingen. Före den tredje kan vi sĂ€tta en fördröjning och mĂ€ta hastigheten för att Ă„teretablera kopplingen osv.
Under test, we measure all parameters that the device can obtain:
- DNS request time;
- TCP connection setup time;
- TLS connection setup time;
- time to receive the first byte of data;
- total loading time;
- status code result.
- After all pulses are completed, the sample downloads the results of all measurements for analytics.
Key points include minimal dependence on client logic, data processing on the server, and measuring concurrent requests. This allows us to isolate and test the impact of various factors influencing request performance, varying them within a single recipe, and obtaining results from real clients.
Such infrastructure has proven useful not only for analyzing request performance. Currently, we have 14 active recipes, over 6,000 samples per second, receiving data from all corners of the earth with full device coverage. If Netflix were to purchase such a service from third-party companies, it would cost millions of dollars a year, with much worse coverage.
Testing the theory in practice: prototype
With such a system, we were able to assess the efficiency of the CDN proxy on request latency. Now we need to:
- create a proxy prototype;
- deploy the prototype on the CDN;
- determine how to route clients to the proxy on a specific CDN server;
- compare performance with requests to AWS without a proxy.
The task is to quickly evaluate the effectiveness of the proposed solution. For the prototype implementation, we chose Go due to its good network libraries. We installed the proxy prototype as a static binary on each CDN server to minimize dependencies and simplify integration. In the initial implementation, we maximized the use of standard components and made small modifications for HTTP/2 connection pooling and request multiplexing.
För att balansera mellan AWS-regioner har vi anvÀnt en geografisk DNS-databas, samma som anvÀnds för att balansera kunder. För att vÀlja en CDN-server för kunden anvÀnder vi TCP Anycast för servrar i Internet Exchange (IX). I detta alternativ anvÀnder vi en IP-adress för alla CDN-servrar, vilket gör att kunden dirigeras till CDN-servern med det minsta antalet IP-hops. Vi har ingen kontroll över routern för att konfigurera TCP Anycast pÄ CDN-servrar som Àr installerade hos internetleverantörer (ISP), sÄ vi anvÀnder , enligt vilken kunder dirigeras till internetleverantörer för videostreaming.
SÄ, vi har tre typer av vÀgar för begÀran: till molnet via öppna internet, via en CDN-server i IX eller via en CDN-server belÀgen hos internetleverantören. VÄrt mÄl Àr att förstÄ vilken vÀg som Àr bÀst och vilken nytta vi fÄr av proxy jÀmfört med hur begÀrningar dirigeras i produktion. För detta anvÀnder vi ett testsystem pÄ följande sÀtt:
Varje vÀg blir ett separat mÄl, och vi ser pÄ den tid vi fÄtt. För analysen slÄr vi samman proxyresultaten i en grupp (vÀljer den bÀsta tiden mellan IX och ISP-proxy), och jÀmför med tiden för begÀrningar till molnet utan proxy:
Som man kan se, visade resultaten sig vara otydiga â i de flesta fall ger proxy en bra acceleration, men det finns ocksĂ„ tillrĂ€ckligt med kunder dĂ€r situationen avsevĂ€rt försĂ€mras.
I slutÀndan gjorde vi flera viktiga saker:
- UtvÀrderade den förvÀntade prestandan för begÀrningar frÄn kunder till molnet via CDN-proxy.
- Fick data frÄn riktiga kunder, frÄn alla typer av enheter.
- Förstod att teorin inte bekrÀftades till 100% och det initiala förslaget med CDN-proxy skulle inte fungera för oss.
- Vi riskerade inte â vi Ă€ndrade inte produktionskonfigurationen för kunderna.
- Vi brakade ingenting.
Prototyp 2.0
SÄ, vi gÄr tillbaka till ritbordet och upprepar processen frÄn början.
IdĂ©n â istĂ€llet för 100% proxy kommer vi för varje kund att bestĂ€mma den snabbaste vĂ€gen och dirigera begĂ€rningar dit â det vill sĂ€ga, vi kommer att göra det som kallas klientstyrning.
Hur ska vi implementera detta? Vi kan inte anvÀnda logik pÄ serversidan, eftersom syftet Àr att ansluta till denna server. Vi mÄste pÄ nÄgot sÀtt göra detta pÄ klienten. Och helst ska vi göra det med minsta möjliga komplexitet för att undvika integrationsfrÄgor med ett stort antal klientplattformar.
Svaret Àr att anvÀnda DNS. I vÄrt fall har vi en egen DNS-infrastruktur, och vi kan stÀlla in en domÀnzon för vilken vÄra servrar kommer att vara auktoritativa. Det fungerar sÄ hÀr:
- Klienten gör en begÀran till DNS-servern med hjÀlp av en vÀrd, till exempel api.netflix.com.
- BegÀran nÄr vÄr DNS-server.
- DNS-servern vet vilken vÀg som Àr snabbast för denna klient och ger den motsvarande IP-adressen.
Det finns en ytterligare komplexitet i lösningen: auktoritativa DNS-leverantörer ser inte klientens IP-adress och kan endast se IP-adressen till den rekursiva resolver som klienten anvÀnder.
I slutÀndan mÄste vÄr auktoritativa resolver fatta beslut inte för enskilda klienter, utan för en grupp av klienter baserat pÄ den rekursiva resolvern.
För att lösa detta anvĂ€nder vi samma probes, aggregerar mĂ€tresultaten frĂ„n klienterna mot varje rekursiv resolver och avgör vart denna grupp ska dirigeras â via proxy genom IX med hjĂ€lp av TCP Anycast, genom ISP-proxy eller direkt till molnet.
Vi fÄr ett sÄdant system:
Den resulterande modellen för DNS-styrning gör att vi kan rikta klienter baserat pÄ historiska observationer av hastigheten pÄ anslutningar frÄn klienter till molnet.
Ă„terigen, frĂ„gan Ă€r â hur effektivt kommer detta tillvĂ€gagĂ„ngssĂ€tt att fungera? För att svara pĂ„ detta anvĂ€nder vi Ă„terigen vĂ„rt system för probes. SĂ„ vi stĂ€ller in en konfiguration av recency, dĂ€r en av mĂ„len följer DNS-styrning, den andra gĂ„r direkt till molnet (nuvarande produktion).
I slutÀndan jÀmför vi resultaten och fÄr en uppskattning av effektiviteten:
Som ett resultat lÀrde vi oss flera viktiga saker:
- Vi utvÀrderade den förvÀntade prestandan för begÀrningar frÄn klienter till molnet med hjÀlp av DNS-styrning.
- Fick data frÄn riktiga kunder, frÄn alla typer av enheter.
- Vi bevisade effektiviteten av den föreslagna idén.
- Vi riskerade inte â vi Ă€ndrade inte produktionskonfigurationen för kunderna.
- Vi brakade ingenting.
Nu till det svĂ„ra â vi kör i produktion.
Det lĂ€ttaste ligger nu bakom oss â vi har en fungerande prototyp. Den svĂ„ra delen Ă€r att skala lösningen för all Netflix-trafik, rulla ut den till 150 miljoner anvĂ€ndare, tusentals enheter, hundratals mikrotjĂ€nster och stĂ€ndigt förĂ€nderliga produkter och infrastruktur. Netflix-servrarna tar emot miljoner förfrĂ„gningar per sekund, och det Ă€r lĂ€tt att bryta tjĂ€nsten med en oförsiktig handling. Samtidigt vill vi dynamiskt styra trafiken genom tusentals CDN-servrar pĂ„ internet, dĂ€r saker stĂ€ndigt förĂ€ndras och gĂ„r sönder, ofta vid de mest olĂ€mpliga tillfĂ€llena.
Och trots allt detta finns det tre ingenjörer i teamet som ansvarar för utveckling, distribution och fullstÀndig support av systemet.
SÄ vi kommer att prata om lugn och hÀlsosam sömn hÀrnÀst.
Hur fortsÀtter vi utvecklingen istÀllet för att spendera all tid pÄ support? KÀrnan i vÄrt tillvÀgagÄngssÀtt bygger pÄ tre principer:
- Vi minskar den potentiella skalan av fel (blast radius).
- Vi förbereder oss för överraskningar â förvĂ€ntar oss att saker gĂ„r sönder, oavsett testning och personlig erfarenhet.
- Gradvis nedgradering (graceful degradation) â om nĂ„got inte fungerar som det ska, ska det automatiskt repareras, Ă€ven om det inte Ă€r det mest effektiva sĂ€ttet.
Det visade sig att i vÄrt fall, med detta tillvÀgagÄngssÀtt för problem, kan vi hitta en enkel och effektiv lösning och betydligt förenkla systemsupporten. Vi insÄg att vi kunde lÀgga till en liten mÀngd kod i klienten för att övervaka fel med nÀtverksförfrÄgningar orsakade av anslutningsproblem. Vid nÀtverksfel gör vi en fallback direkt till molnet. Denna lösning krÀver inte stora anstrÀngningar frÄn klientteam, men minskar avsevÀrt risken för ovÀntade fel och överraskningar för oss.
Naturligtvis, trots fallback, följer vi fortfarande en strikt disciplin i utvecklingsprocessen:
- Test pÄ prover.
- A/B-testning eller Canaries.
- Gradvis lansering (progressive rollout).
Med prover har tillvĂ€gagĂ„ngssĂ€ttet beskrivits â förĂ€ndringar testas först med hjĂ€lp av en konfigurerad recept.
För canary-testning behöver vi fÄ jÀmförbara par av servrar, dÀr vi kan jÀmföra hur systemet fungerar före och efter förÀndringar. För detta vÀljer vi par av servrar frÄn vÄra mÄnga CDN-webbplatser som fÄr jÀmförbar trafik:
DÀrefter placerar vi byggnaden med Àndringar pÄ Canary-servrar. För att utvÀrdera resultaten kör vi ett system som jÀmför cirka 100-150 metriker med en kontrollgrupp av servrar:
Om Canary-testningen lyckas gör vi en gradvis release i vĂ„gor. PĂ„ varje webbplats uppdaterar vi inte servrarna samtidigt â förlusten av en hel webbplats vid problem har en större pĂ„verkan pĂ„ anvĂ€ndartjĂ€nsten Ă€n förlusten av samma antal servrar, men pĂ„ olika platser.
Ăverlag beror effektiviteten och sĂ€kerheten i tillvĂ€gagĂ„ngssĂ€ttet pĂ„ mĂ€ngden och kvaliteten av insamlade metriker. För vĂ„rt system för att pĂ„skynda förfrĂ„gningar samlar vi in metriker frĂ„n alla möjliga komponenter:
- frĂ„n kunder â antal sessioner och förfrĂ„gningar, fallback rates;
- proxy â statistik om antal och tid för förfrĂ„gningar;
- DNS â antal och resultat av förfrĂ„gningar;
- cloud edge â antal och tid för behandling av förfrĂ„gningar i molnet.
Allt detta samlas i en enhetlig pipeline, och beroende pÄ behov beslutar vi vilka metriker som ska skickas till realtidsanalys och vilka som ska gÄ till Elasticsearch eller Big Data för mer detaljerad diagnostik.
Ăvervakar
I vĂ„rt fall gör vi Ă€ndringar pĂ„ den kritiska vĂ€gen för förfrĂ„gningar mellan klienten och servern. Under tiden Ă€r antalet olika komponenter pĂ„ klienten, servern och vĂ€gen genom internet enorma. Ăndringar pĂ„ klienten och servern sker stĂ€ndigt â genom arbetet av tiotals team och naturliga förĂ€ndringar i ekosystemet. Vi Ă€r i mitten â vid diagnostik av problem finns det stor risk att vi Ă€r involverade. DĂ€rför behöver vi tydligt förstĂ„ hur vi ska definiera, samla in och analysera metriker för att snabbt lokalisera problem.
Idealiskt sett â full tillgĂ„ng till alla typer av metriker och filter i realtid. Men det finns vĂ€ldigt mĂ„nga metriker, sĂ„ kostnadsfrĂ„gan kommer upp. I vĂ„rt fall separerar vi metriker och utvecklingsverktyg enligt följande:
För att upptĂ€cka och triagera problem anvĂ€nder vi vĂ„rt eget realtids system med öppen kĂ€llkod och â för visualisering. Det lagrar aggreggaterade metriker i minnet, Ă€r pĂ„litligt och integreras med alertsystemet. För lokalisering och diagnostik har vi tillgĂ„ng till loggar frĂ„n Elasticsearch och Kibana. För statistisk analys och modellering â anvĂ€nder vi big data och visualisering i Tableau.
Det verkar som att det Ă€r mycket svĂ„rt att arbeta med en sĂ„dan metod. Men med en hierarkisk organisation av mĂ€tningar och verktyg kan vi snabbt analysera problemet, identifiera typ av problem och sedan fördjupa oss i detaljerade mĂ€tningar. För att lokalisera kĂ€llan till ett fel tar vi i genomsnitt omkring 1-2 minuter. Efter det arbetar vi redan med det specifika teamet pĂ„ diagnostik â frĂ„n tiotals minuter till flera timmar.
Ăven om diagnosen görs snabbt, vill vi inte att det ska hĂ€nda ofta. I bĂ€sta fall fĂ„r vi ett kritiskt alert bara nĂ€r det finns en betydande pĂ„verkan pĂ„ tjĂ€nsten. För vĂ„rt system för cachning av förfrĂ„gningar har vi bara 2 alert som kommer att informera oss:
- andel av Client Fallback â bedömning av kundbeteende;
- andel av Probe errors â data om stabiliteten hos nĂ€tverkskomponenter.
Dessa kritiska alert övervakar om systemet fungerar för de flesta anvÀndare. Vi tittar pÄ hur mÄnga kunder som utnyttjade fallback om de inte kunde fÄ en snabbare förfrÄgan. I genomsnitt har vi mindre Àn 1 kritisk notis per vecka, Àven om det sker en stor mÀngd förÀndringar i systemet. Varför Àr det tillrÀckligt för oss?
- Det finns en klientfallback om vÄr proxy inte fungerar.
- Det finns ett automatiskt styrsystem som reagerar pÄ problem.
Om det senaste, vÄr probesystem och systemet för automatisk vÀgval för förfrÄgningar frÄn klienten till molnet, gör det möjligt att automatiskt hantera vissa problem.
LÄt oss ÄtergÄ till vÄr konfiguration av proverna och 3 kategorier av vÀgar. Förutom laddningstid kan vi Àven titta pÄ faktiskt leverans. Om det inte gick att ladda data, kan vi genom att titta pÄ resultaten frÄn olika vÀgar avgöra var och vad som har gÄtt fel, och om vi kan ÄterstÀlla det automatiskt genom att Àndra begÀrans vÀg.
Exempel:
Denna process kan automatiseras. Integrera den i styrsystemet. Och lĂ€ra det att reagera pĂ„ problem med prestanda och tillförlitlighet. Om nĂ„got börjar gĂ„ fel â reagera, om det finns en bĂ€ttre alternativ. Samtidigt Ă€r en omedelbar reaktion inte kritisk, tack vare fallback pĂ„ klienterna.
SÄledes kan principerna för systemunderhÄll formuleras sÄ hÀr:
- minska omfattningen av fel;
- samla mÀtningar;
- automatiskt ÄtgÀrda fel, om vi kan;
- om vi inte kan â meddela;
- Vi arbetar med dashboards och triage-verktyg för snabb respons.
LĂ€rdomar
Det tar inte mycket tid att skriva en prototyp. I vĂ„rt fall var den klar redan efter 4 mĂ„nader. Med den fick vi nya mĂ€tvĂ€rden, och efter 10 mĂ„nader frĂ„n utvecklingens början fick vi vĂ„r första produktions trafik. Sedan började det trĂ„kiga och mycket svĂ„ra arbetet: att gradvis produktifiera och skala systemet, migrera den huvudsakliga trafiken och lĂ€ra av misstagen. Denna effektiva process kommer inte att vara linjĂ€r â trots alla anstrĂ€ngningar kan man inte förutsĂ€ga allt. Mycket mer effektivt Ă€r snabb iteration och respons pĂ„ nya data.
Baserat pÄ vÄr erfarenhet kan vi rekommendera följande:
- Lita inte pÄ din intuition.
VÄr intuition har stÀndigt svikit oss, trots den enorma erfarenheten hos teammedlemmarna. Till exempel, vi felbedömde den uppskattade förbÀttringen frÄn att anvÀnda CDN-proxyer eller beteendet hos TCP Anycast.
- HÀmta data frÄn produktion.
Det Àr viktigt att sÄ snabbt som möjligt fÄ tillgÄng till Ätminstone en liten mÀngd produktionsdata. Antalet unika fall, konfigurationer och instÀllningar i labbmiljöer Àr praktiskt taget omöjligt att fÄ. Snabb tillgÄng till resultaten gör att vi snabbare kan upptÀcka potentiella problem och beakta dem i systemarkitekturen.
- Följ inte andras rĂ„d och resultat â samla dina egna data.
Följ principerna för insamling och analys av data, men ta inte blint andras resultat och pĂ„stĂ„enden. Endast du kan veta exakt vad som fungerar för dina anvĂ€ndare. Ditt system och dina kunder kan skilja sig avsevĂ€rt frĂ„n andra företag. Lyckligtvis Ă€r verktyg för analys nu tillgĂ€ngliga och lĂ€tta att anvĂ€nda. De resultat du fĂ„r kanske inte stĂ€mmer överens med vad Netflix, Facebook, Akamai och andra företag hĂ€vdar. I vĂ„rt fall skiljer sig prestandan för TLS, HTTP2 eller statistiken för DNS-förfrĂ„gningar frĂ„n resultaten frĂ„n Facebook, Uber, Akamai â eftersom vi har andra enheter, kunder och datastreamar.
- StrÀva inte efter trendiga fenomen utan behov och utvÀrdering av effektivitet.
Börja enkelt. Det Àr bÀttre att skapa ett enkelt fungerande system pÄ kort tid Àn att lÀgga ner enormt mycket tid pÄ att utveckla komponenter som du inte behöver. Lös de problem och utmaningar som Àr viktiga baserat pÄ dina mÀtningar och resultat.
- Var beredd pÄ nya tillÀmpningar.
Precis som det Ă€r svĂ„rt att förutsĂ€ga alla problem Ă€r det ocksĂ„ svĂ„rt att pĂ„ förhand förutsĂ€ga fördelarna och tillĂ€mpningarna. LĂ„t dig inspireras av startups â deras förmĂ„ga att anpassa sig efter kundernas behov. I ditt fall kan du upptĂ€cka nya problem och lösningar. I vĂ„rt projekt hade vi som mĂ„l att minska fördröjningen av förfrĂ„gningar. Men under analysen och diskussionerna insĂ„g vi att vi Ă€ven kunde anvĂ€nda proxyservrar:
- för att balansera trafik mellan AWS-regioner och minska kostnader;
- för att modellera stabilitet i CDN;
- för att konfigurera DNS;
- för att konfigurera TLS/TCP.
Slutsats
I presentationen beskriver jag hur Netflix löser utmaningen att snabba upp internetförfrÄgningar mellan kunder och molnet. Hur vi samlar in data genom att anvÀnda mÀtpunkter hos kunderna, och anvÀnder den insamlade historiska datan för att styra produktionsförfrÄgningar frÄn kunder genom den snabbaste vÀgen pÄ internet. Hur vi anvÀnder principerna för nÀtverksprotokoll, vÄr CDN-infrastruktur, backbone-nÀtverket och DNS-servrar för att uppnÄ detta.
Men vÄr lösning Àr bara ett exempel pÄ hur vi pÄ Netflix har implementerat ett sÄdant system. Vad som fungerade för oss. Den praktiska delen av min presentation för er handlar om de principer för utveckling och underhÄll som vi följer för att uppnÄ bra resultat.
VÄr lösning pÄ problemet kanske inte passar er. Men teorin och utvecklingsprinciperna kvarstÄr, Àven om ni inte har en egen CDN-infrastruktur, eller om den skiljer sig avsevÀrt frÄn vÄr.
Betydelsen av hastighet pÄ förfrÄgningar för verksamheten kvarstÄr ocksÄ. Och Àven för en enkel tjÀnst mÄste du göra val: mellan "moln"-leverantörer, serverens placering, CDN och DNS-leverantörer. Ditt val kommer att pÄverka effektiviteten av internetförfrÄgningar för dina kunder. Och för dig Àr det viktigt att mÀta och förstÄ denna pÄverkan.
Börja med enkla lösningar, och tÀnk pÄ hur du förÀndrar produkten. LÀr dig under processen och förbÀttra systemet baserat pÄ data frÄn dina kunder, din infrastruktur och ditt företag. TÀnk pÄ möjligheten av ovÀntade fel under designfasen. DÄ kan du snabba upp din utvecklingsprocess, förbÀttra lösningens effektivitet, undvika överbelastning pÄ supporten och sova gott.
I Är i onlineformat. Du kommer att kunna stÀlla frÄgor till en av DevOps-fÀderna, John Willis sjÀlv!
KĂ€lla: habr.com
