Netflix är ledaren på internet-tv-marknaden - företaget som skapade och aktivt utvecklar detta segment. Netflix är inte bara känt för sin omfattande katalog med filmer och TV-serier tillgängliga från nästan alla hörn av planeten och alla enheter med en skärm, utan också för sin pålitliga infrastruktur och unika ingenjörskultur.
Ett tydligt exempel på Netflix-metoden för att utveckla och stödja komplexa system presenterades på DevOops 2019 - Utvecklingschef på Netflix. Utexaminerad från fakulteten för beräkningsmatematik och matematik vid Nizhny Novgorod State University. Lobachevsky, Sergey en av de första ingenjörerna i Open Connect - CDN-teamet på Netflix. Han byggde system för övervakning och analys av videodata, lanserade en populär tjänst för att bedöma internetuppkopplingshastigheten FAST.com och har de senaste åren arbetat med att optimera Internetförfrågningar så att Netflix-applikationen fungerar så snabbt som möjligt för användarna.
Rapporten fick de bästa recensionerna från konferensdeltagarna och vi har förberett en textversion åt dig.
I sin rapport talade Sergei i detalj
- om vad som påverkar fördröjningen av Internetförfrågningar mellan klienten och servern;
- hur man minskar denna fördröjning;
- hur man designar, underhåller och övervakar feltoleranta system;
- hur man uppnår resultat på kort tid och med minimal risk för verksamheten;
- hur man analyserar resultat och lär sig av misstag.
Svar på dessa frågor behövs inte bara av de som arbetar i stora företag.
De presenterade principerna och teknikerna bör vara kända och praktiserade av alla som utvecklar och stödjer internetprodukter.
Nästa är berättelsen från talarens perspektiv.
Vikten av internethastighet
Hastigheten på Internetförfrågningar är direkt relaterad till verksamheten. Tänk på shoppingbranschen: Amazon 2009 att en 100 ms fördröjning resulterar i en förlust på 1 % av försäljningen.
Det finns fler och fler mobila enheter, följt av mobilsajter och applikationer. Om det tar längre tid än 3 sekunder att ladda din sida förlorar du ungefär hälften av dina användare. MED Google tar hänsyn till laddningshastigheten på din sida i sökresultaten: ju snabbare sidan är, desto högre position i Google.
Anslutningshastigheten är också viktig i finansiella institutioner där latens är avgörande. 2015, Hibernia Networks en kabel på 400 miljoner dollar mellan New York och London för att minska latensen mellan städerna med 6 ms. Föreställ dig 66 miljoner dollar för 1 ms fördröjning!
Enligt , anslutningshastigheter över 5 Mbit/s påverkar inte längre direkt laddningshastigheten för en typisk webbplats. Det finns dock ett linjärt samband mellan anslutningslatens och sidladdningshastighet:
Netflix är dock ingen typisk produkt. Effekten av latens och hastighet på användaren är ett aktivt område för analys och utveckling. Det finns applikationsladdning och innehållsval som beror på latens, men laddning av statiska element och streaming beror också på anslutningshastighet. Att analysera och optimera nyckelfaktorerna som påverkar användarupplevelsen är ett aktivt utvecklingsområde för flera team på Netflix. Ett av målen är att minska fördröjningen av förfrågningar mellan Netflix-enheter och molninfrastrukturen.
I rapporten kommer vi att fokusera specifikt på att minska latensen med hjälp av exemplet med Netflix-infrastrukturen. Låt oss överväga från en praktisk synvinkel hur man närmar sig processerna för design, utveckling och drift av komplexa distribuerade system och spenderar tid på innovation och resultat, snarare än att diagnostisera operativa problem och haverier.
Inuti Netflix
Tusentals olika enheter stöder Netflix-appar. De är utvecklade av fyra olika team, som gör separata versioner av klienten för Android, iOS, TV och webbläsare. Och vi lägger ner mycket kraft på att förbättra och anpassa användarupplevelsen. För att göra detta kör vi hundratals A/B-tester parallellt.
Personalisering stöds av hundratals mikrotjänster i AWS-molnet, som tillhandahåller personlig användardata, frågeutskick, telemetri, Big Data och kodning. Trafikvisualiseringen ser ut så här:
Till vänster finns ingångspunkten och sedan fördelas trafiken på 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 - videor, bilder, klientkod, etc. CDN finns på anpassade servrar (OCA - Open Connect Appliance). Inuti finns det arrayer av SSD- och HDD-enheter som kör optimerad FreeBSD, med NGINX och en uppsättning tjänster. Vi designar och optimerar hård- och mjukvarukomponenter så att en sådan CDN-server kan skicka så mycket data som möjligt till användarna.
"Väggen" för dessa servrar vid utbytespunkten för Internettrafik (Internet eXchange - IX) ser ut så här:
Internet Exchange ger möjlighet för Internetleverantörer och innehållsleverantörer att "ansluta" till varandra för att mer direkt utbyta data på Internet. Det finns cirka 70-80 Internet Exchange-punkter runt om i världen där våra servrar är installerade, och vi installerar och underhåller dem självständigt:
Dessutom tillhandahåller vi även servrar direkt till internetleverantörer, som de installerar i sitt nätverk, vilket förbättrar lokaliseringen av Netflix-trafik och kvaliteten på streaming för användare:
En uppsättning AWS-tjänster ansvarar för att skicka videoförfrågningar från klienter till CDN-servrar, samt konfigurera själva servrarna - uppdatering av innehåll, programkod, inställningar etc. För det senare byggde vi även ett stamnät som kopplar ihop servrar i Internet Exchange-punkter med AWS. Stamnätet är ett globalt nätverk av fiberoptiska kablar och routrar som vi kan designa och konfigurera utifrån våra behov.
På , vår CDN-infrastruktur levererar ungefär ⅛ av världens internettrafik under rusningstid och ⅓ av trafiken i Nordamerika, där Netflix har funnits längst. Imponerande siffror, men för mig är en av de mest fantastiska prestationerna att hela CDN-systemet utvecklas och underhålls av ett team på mindre än 150 personer.
Inledningsvis designades CDN-infrastrukturen för att leverera videodata. Men med tiden insåg vi att vi också kan använda det för att optimera dynamiska förfrågningar från klienter i AWS-molnet.
Om internetacceleration
Idag har Netflix 3 AWS-regioner, och fördröjningen av förfrågningar till molnet kommer att bero på hur långt kunden är från närmaste region. Samtidigt har vi många CDN-servrar som används för att leverera statiskt innehåll. Finns det något sätt att använda detta ramverk för att påskynda dynamiska frågor? Men tyvärr är det omöjligt att cache dessa förfrågningar - API:er är personliga och varje resultat är unikt.
Låt oss skapa en proxy på CDN-servern och börja skicka trafik genom den. Blir det snabbare?
materiel
Låt oss komma ihåg hur nätverksprotokoll fungerar. Idag använder den mesta trafiken på Internet HTTPs, vilket beror på de lägre lagerprotokollen TCP och TLS. För att en klient ska kunna ansluta till servern gör den en handskakning, och för att upprätta en säker anslutning måste klienten utbyta meddelanden med servern tre gånger och minst en gång till för att överföra data. Med en latens per tur och retur (RTT) på 100 ms skulle det ta oss 400 ms att ta emot den första databiten:
Om vi placerar certifikaten på CDN-servern kan handskakningstiden mellan klienten och servern reduceras avsevärt om CDN:n är närmare. Låt oss anta att latensen till CDN-servern är 30 ms. Sedan tar det 220 ms att ta emot den första biten:
Men fördelarna slutar inte där. När en anslutning väl har upprättats, ökar TCP överbelastningsfönstret (mängden information som den kan sända över den anslutningen parallellt). Om ett datapaket går förlorat, reducerar klassiska implementeringar av TCP-protokollet (som TCP New Reno) det öppna "fönstret" med hälften. Tillväxten av överbelastningsfönstret och hastigheten för dess återhämtning från förlust beror igen på fördröjningen (RTT) till servern. Om den här anslutningen bara går så långt som till CDN-servern kommer denna återställning att gå snabbare. Samtidigt är paketförlust ett standardfenomen, speciellt för trådlösa nätverk.
Internetbandbredden kan minska, särskilt under rusningstid, på grund av trafik från användare, vilket kan leda till trafikstockningar. Det finns dock inget sätt på Internet att prioritera vissa förfrågningar framför andra. Till exempel, prioritera små och latenskänsliga förfrågningar framför "tunga" dataströmmar som laddar nätverket. Men i vårt fall tillåter vårt eget stamnät oss att göra detta på en del av förfrågningsvägen - mellan CDN och molnet, och vi kan konfigurera det fullt ut. Du kan se till att små och latenskänsliga paket prioriteras, och stora dataflöden går lite senare. Ju närmare CDN är kunden, desto större effektivitet.
Protokoll på applikationsnivå (OSI Level 7) har också en inverkan på latens. Nya protokoll som HTTP/2 optimerar prestandan för parallella förfrågningar. Vi har dock Netflix-klienter med äldre enheter som inte stöder de nya protokollen. Alla klienter kan inte uppdateras eller konfigureras optimalt. Samtidigt finns det mellan CDN-proxyn och molnet full kontroll och möjlighet att använda nya, optimala protokoll och inställningar. Den ineffektiva delen med gamla protokoll fungerar bara mellan klienten och CDN-servern. Dessutom kan vi göra multiplexförfrågningar på en redan etablerad anslutning mellan CDN och molnet, vilket förbättrar anslutningsanvändningen på TCP-nivå:
Vi mäter
Trots att teorin lovar förbättringar, skyndar vi oss inte omedelbart att lansera systemet i produktion. Istället måste vi först bevisa att idén kommer att fungera i praktiken. För att göra detta måste du svara på flera frågor:
- Скорость: kommer en proxy att vara snabbare?
- Надежность: Kommer det att gå sönder oftare?
- Komplexitet: hur man integrerar med applikationer?
- Kostnad: Hur mycket kostar det att distribuera ytterligare infrastruktur?
Låt oss i detalj överväga vårt sätt att bedöma den första punkten. Resten hanteras på liknande sätt.
För att analysera hastigheten på förfrågningar vill vi skaffa data för alla användare, utan att lägga ner mycket tid på utveckling och utan att bryta produktionen. Det finns flera tillvägagångssätt för detta:
- RUM, eller passiv förfrågningsmätning. Vi mäter exekveringstiden för aktuella förfrågningar från användare och säkerställer full användartäckning. Nackdelen är att signalen inte är särskilt stabil på grund av många faktorer, till exempel på grund av olika förfrågningsstorlekar, bearbetningstid på server och klient. Dessutom kan du inte testa en ny konfiguration utan effekt i produktionen.
- Laboratorietester. Särskilda servrar och infrastruktur som simulerar klienter. Med deras hjälp utför vi nödvändiga tester. På så sätt får vi full kontroll över mätresultaten och en tydlig signal. Men det finns ingen fullständig täckning av enheter och användarplatser (särskilt med en världsomspännande tjänst och support för tusentals enhetsmodeller).
Hur kan du kombinera fördelarna med båda metoderna?
Vårt team har hittat en lösning. Vi skrev en liten bit kod - ett exempel - som vi byggde in i vår applikation. Prober tillåter oss att göra helt kontrollerade nätverkstester från våra enheter. Det fungerar så här:
- Kort efter att applikationen har laddats och den initiala aktiviteten har slutförts kör vi våra sonder.
- Klienten gör en begäran till servern och får ett "recept" för testet. Receptet är en lista över webbadresser till vilka en HTTP(s)-begäran måste göras. Dessutom konfigurerar receptet förfrågningsparametrar: fördröjningar mellan förfrågningar, mängd begärd data, HTTP(s)-rubriker, etc. Samtidigt kan vi testa flera olika recept parallellt - när vi begär en konfiguration avgör vi slumpmässigt vilket recept som ska utfärdas.
- Sondstarttiden väljs så att den inte kommer i konflikt med den aktiva användningen av nätverksresurser på klienten. I huvudsak väljs tiden när klienten inte är aktiv.
- Efter att ha mottagit receptet gör klienten förfrågningar till var och en av webbadresserna, parallellt. Begäran till var och en av adresserna kan upprepas - den sk. "pulser". Vid första pulsen mäter vi hur lång tid det tog att upprätta en anslutning och ladda ner data. På den andra pulsen mäter vi tiden det tar att ladda data över en redan etablerad anslutning. Innan den tredje kan vi ställa in en fördröjning och mäta hastigheten för att upprätta en återanslutning, etc.
Under testet mäter vi alla parametrar som enheten kan erhålla:
- DNS-begäranstid;
- TCP-anslutningens inställningstid;
- TLS-anslutningens inställningstid;
- tidpunkt för mottagning av den första byten med data;
- total laddningstid;
- status resultatkod.
- Efter att alla pulser har slutförts laddar provet alla mätningar för analys.
Nyckelpunkterna är minimalt beroende av logik på klienten, databehandling på servern och mätning av parallella förfrågningar. Således kan vi isolera och testa inverkan av olika faktorer som påverkar frågeprestanda, variera dem inom ett enda recept och få resultat från riktiga kunder.
Denna infrastruktur har visat sig användbar för mer än bara frågeprestandaanalys. För närvarande har vi 14 aktiva recept, mer än 6000 prover per sekund, som tar emot data från jordens alla hörn och full enhetstäckning. Om Netflix köpte en liknande tjänst från en tredje part skulle det kosta miljontals dollar om året, med mycket sämre täckning.
Testteori i praktiken: prototyp
Med ett sådant system kunde vi utvärdera effektiviteten av CDN-proxyer på begäran om latens. Nu behöver du:
- skapa en proxyprototyp;
- placera prototypen på ett CDN;
- bestämma hur man dirigerar klienter till en proxy på en specifik CDN-server;
- Jämför prestanda med förfrågningar i AWS utan proxy.
Uppgiften är att utvärdera effektiviteten av den föreslagna lösningen så snabbt som möjligt. Vi valde Go för att implementera prototypen på grund av tillgången på bra nätverksbibliotek. På varje CDN-server installerade vi prototypproxyn som en statisk binär för att minimera beroenden och förenkla integrationen. I den initiala implementeringen använde vi standardkomponenter så mycket som möjligt och mindre ändringar för HTTP/2-anslutningspooling och begäran om multiplexering.
För att balansera mellan AWS-regioner använde vi en geografisk DNS-databas, samma som används för att balansera klienter. För att välja en CDN-server för klienten använder vi TCP Anycast för servrar i Internet Exchange (IX). I det här alternativet använder vi en IP-adress för alla CDN-servrar, och klienten kommer att dirigeras till CDN-servern med det minsta antalet IP-hopp. I CDN-servrar installerade av Internetleverantörer (ISP) har vi inte kontroll över routern för att konfigurera TCP Anycast, så vi använder , som hänvisar kunder till internetleverantörer för videoströmning.
Så vi har tre typer av förfrågningsvägar: till molnet via det öppna Internet, via en CDN-server i IX eller via en CDN-server som finns hos en internetleverantör. Vårt mål är att förstå vilken väg som är bättre, och vad som är fördelen med en proxy, jämfört med hur förfrågningar skickas till produktion. För att göra detta använder vi ett provtagningssystem enligt följande:
Var och en av vägarna blir ett separat mål, och vi tittar på tiden vi fick. För analys kombinerar vi proxyresultaten i en grupp (välj den bästa tiden mellan IX- och ISP-proxyer) och jämför dem med tiden för förfrågningar till molnet utan proxy:
Som du kan se var resultaten blandade - i de flesta fall ger proxyn en bra hastighet, men det finns också ett tillräckligt antal klienter för vilka situationen kommer att förvärras avsevärt.
Som ett resultat gjorde vi flera viktiga saker:
- Vi bedömde den förväntade prestandan för förfrågningar från klienter till molnet via en CDN-proxy.
- Vi fick data från riktiga kunder, från alla typer av enheter.
- Vi insåg att teorin inte var 100 % bekräftad och det ursprungliga erbjudandet med en CDN-proxy skulle inte fungera för oss.
- Vi tog inga risker – vi ändrade inte produktionskonfigurationer för kunder.
- Ingenting var trasigt.
Prototyp 2.0
Så, tillbaka till ritbordet och upprepa processen igen.
Tanken är att istället för att använda en 100 % proxy, kommer vi att bestämma den snabbaste vägen för varje klient, och vi kommer att skicka förfrågningar dit – det vill säga vi kommer att göra det som kallas klientstyrning.
Hur implementerar man detta? Vi kan inte använda logik på serversidan, eftersom... Målet är att ansluta till denna server. Det måste finnas något sätt att göra detta på klienten. Och helst, gör detta med en minimal mängd komplex logik, för att inte lösa problemet med integration med ett stort antal klientplattformar.
Svaret är att använda DNS. I vårt fall har vi vår egen DNS-infrastruktur, och vi kan sätta upp en domänzon för vilken våra servrar kommer att vara auktoritära. 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.xom.
- Förfrågan kommer till vår DNS-server
- DNS-servern vet vilken sökväg som är snabbast för denna klient och utfärdar motsvarande IP-adress.
Lösningen har en ytterligare komplexitet: auktoritära DNS-leverantörer ser inte klientens IP-adress och kan bara läsa IP-adressen för den rekursiva resolver som klienten använder.
Som ett resultat måste vår auktoritära resolver fatta ett beslut inte för en enskild klient, utan för en grupp klienter baserat på den rekursiva resolvern.
För att lösa det använder vi samma prover, aggregerar mätresultaten från klienter för var och en av de rekursiva resolvrarna och bestämmer vart vi ska skicka denna grupp av dem - en proxy genom IX med TCP Anycast, via en ISP-proxy eller direkt till molnet.
Vi får följande system:
Den resulterande DNS-styrmodellen låter dig dirigera klienter baserat på historiska observationer av hastigheten på anslutningar från klienter till molnet.
Återigen är frågan hur effektivt detta tillvägagångssätt kommer att fungera? För att svara använder vi återigen vårt sondsystem. Därför konfigurerar vi presentatörskonfigurationen, där ett av målen följer riktningen från DNS-styrning, det andra går direkt till molnet (nuvarande produktion).
Som ett resultat jämför vi resultaten och får en bedömning av effektiviteten:
Som ett resultat lärde vi oss flera viktiga saker:
- Vi bedömde den förväntade prestandan för förfrågningar från klienter till molnet med hjälp av DNS-styrning.
- Vi fick data från riktiga kunder, från alla typer av enheter.
- Effektiviteten av den föreslagna idén har bevisats.
- Vi tog inga risker – vi ändrade inte produktionskonfigurationer för kunder.
- Ingenting var trasigt.
Nu om den svåra delen - vi lanserar den i produktion
Den enkla delen är nu över - det finns en fungerande prototyp. Nu är den svåra delen att lansera en lösning för all Netflix trafik, som distribueras till 150 miljoner användare, tusentals enheter, hundratals mikrotjänster och en produkt och infrastruktur som ständigt förändras. Netflix-servrar tar emot miljontals förfrågningar per sekund, och det är lätt att bryta tjänsten med slarvig handling. Samtidigt vill vi dynamiskt dirigera trafik genom tusentals CDN-servrar på Internet, där något förändras och går sönder hela tiden och i det mest olämpliga ögonblicket.
Och med allt detta har teamet 3 ingenjörer som är ansvariga för utveckling, driftsättning och fullständigt stöd för systemet.
Därför kommer vi att fortsätta prata om vilsam och hälsosam sömn.
Hur kan man fortsätta utvecklingen och inte lägga all tid på support? Vårt tillvägagångssätt bygger på tre principer:
- Vi minskar den potentiella omfattningen av haverier (sprängradie).
- Vi förbereder oss för överraskningar – vi förväntar oss att något går sönder, trots testning och personlig erfarenhet.
- Graciös nedbrytning – om något inte fungerar som det ska ska det åtgärdas automatiskt, även om det inte är på det mest effektiva sättet.
Det visade sig att vi i vårt fall, med detta förhållningssätt till problemet, kan hitta en enkel och effektiv lösning och avsevärt förenkla systemstödet. Vi insåg att vi kunde lägga till en liten bit kod till klienten och övervaka nätverksbegäranfel orsakade av anslutningsproblem. Vid nätverksfel gör vi en reserv direkt till molnet. Denna lösning kräver ingen betydande ansträngning för kundteam, men minskar avsevärt risken för oväntade haverier och överraskningar för oss.
Naturligtvis, trots fallbacken, följer vi ändå en tydlig disciplin under utvecklingen:
- Prov test.
- A/B-testning eller Kanarieöarna.
- Progressiv utbyggnad.
Med prover har tillvägagångssättet beskrivits – förändringar testas först med hjälp av ett skräddarsytt recept.
För kanariefågeltestning behöver vi få jämförbara par av servrar där vi kan jämföra hur systemet fungerar före och efter ändringarna. För att göra detta, från våra många CDN-webbplatser, väljer vi par av servrar som tar emot jämförbar trafik:
Sedan installerar vi bygget med ändringarna på Canary-servern. För att utvärdera resultaten kör vi ett system som jämför cirka 100-150 mätvärden med ett urval av kontrollservrar:
Om Canary-testningen är framgångsrik, släpper vi den gradvis, i vågor. Vi uppdaterar inte servrar på varje sajt samtidigt - att förlora en hel sajt på grund av problem har en mer betydande inverkan på tjänsten för användarna än att förlora samma antal servrar på olika platser.
I allmänhet beror effektiviteten och säkerheten för detta tillvägagångssätt på kvantiteten och kvaliteten på de insamlade mätvärdena. För vårt frågeaccelerationssystem samlar vi in mätvärden från alla möjliga komponenter:
- från kunder - antal sessioner och förfrågningar, reservfrekvenser;
- proxy - statistik över antalet och tidpunkten för förfrågningar;
- DNS - antal och resultat av förfrågningar;
- cloud edge - antal och tid för bearbetning av förfrågningar i molnet.
Allt detta samlas i en enda pipeline, och beroende på behoven bestämmer vi vilka mätvärden som ska skickas till realtidsanalyser och vilka till Elasticsearch eller Big Data för mer detaljerad diagnostik.
Vi övervakar
I vårt fall gör vi ändringar på den kritiska vägen för förfrågningar mellan klienten och servern. Samtidigt är antalet olika komponenter på klienten, på servern och på vägen genom Internet enormt. Förändringar på klienten och servern sker ständigt - under arbetet i dussintals team och naturliga förändringar i ekosystemet. Vi är i mitten - när vi diagnostiserar problem finns det en god chans att vi blir involverade. Därför måste vi tydligt förstå hur man definierar, samlar in och analyserar mått för att snabbt isolera problem.
Helst full tillgång till alla typer av mätvärden och filter i realtid. Men det finns många mått, så frågan om kostnad uppstår. I vårt fall separerar vi mätvärden och utvecklingsverktyg enligt följande:
För att upptäcka och triage problem använder vi vårt eget realtidssystem med öppen källkod и - för visualisering. Den lagrar aggregerade mätvärden i minnet, är pålitlig och integreras med varningssystemet. 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 detta tillvägagångssätt är mycket svårt att arbeta med. Men genom att organisera mätvärden och verktyg hierarkiskt kan vi snabbt analysera ett problem, bestämma typen av problem och sedan gå ner i detaljerade mätvärden. I allmänhet lägger vi cirka 1-2 minuter på att identifiera källan till haveriet. Efter detta arbetar vi med ett specifikt team kring diagnostik – från tiotals minuter till flera timmar.
Även om diagnosen görs snabbt vill vi inte att det ska hända ofta. Helst kommer vi bara att få en kritisk varning när det finns en betydande påverkan på tjänsten. För vårt frågeaccelerationssystem har vi bara två varningar som meddelar:
- Kundens reservprocent - bedömning av kundbeteende;
- procent Sondfel - stabilitetsdata för nätverkskomponenter.
Dessa kritiska varningar övervakar om systemet fungerar för majoriteten av användarna. Vi tittar på hur många kunder som använde reserv om de inte kunde få förfrågningsacceleration. Vi i genomsnitt mindre än 1 kritisk varning per vecka, även om det finns massor av förändringar på gång i systemet. Varför räcker detta för oss?
- Det finns en reserv för klienten om vår proxy inte fungerar.
- Det finns ett automatiskt styrsystem som svarar på problem.
Mer information om det senare. Vårt testsystem, och systemet för att automatiskt bestämma den optimala vägen för förfrågningar från klienten till molnet, gör att vi automatiskt kan hantera vissa problem.
Låt oss återgå till vår exempelkonfiguration och 3 sökvägskategorier. Förutom laddningstid kan vi titta på själva leveransen. Om det inte var möjligt att ladda data kan vi genom att titta på resultaten längs olika vägar avgöra var och vad som gick sönder, och om vi automatiskt kan fixa det genom att ändra sökvägen för begäran.
Exempel:
Denna process kan automatiseras. Inkludera det i styrsystemet. Och lär den att svara på prestanda- och tillförlitlighetsproblem. Om något börjar gå sönder, reagera om det finns ett bättre alternativ. Samtidigt är en omedelbar reaktion inte kritisk, tack vare fallback på kunder.
Således kan principerna för systemstöd formuleras enligt följande:
- minska omfattningen av haverier;
- samla in mått;
- Vi reparerar automatiskt haverier om vi kan;
- om det inte kan, meddelar vi dig;
- Vi arbetar med instrumentpaneler och triageverktyg för snabb respons.
Lärdomar
Det tar inte mycket tid att skriva en prototyp. I vårt fall var den klar efter 4 månader. Med den fick vi nya mätvärden och 10 månader efter utvecklingsstart fick vi den första produktionstrafiken. Sedan började det tråkiga och mycket svåra arbetet: gradvis produktisera och skala systemet, migrera huvudtrafiken och lära av misstag. Denna effektiva process kommer dock inte att vara linjär - trots alla ansträngningar kan allt inte förutsägas. Det är mycket effektivare att snabbt iterera och svara på ny data.
Baserat på vår erfarenhet kan vi rekommendera följande:
- Lita inte på din intuition.
Vår intuition svikit oss hela tiden, trots den stora erfarenheten hos våra teammedlemmar. Till exempel förutspådde vi felaktigt den förväntade hastigheten från att använda en CDN-proxy, eller beteendet hos TCP Anycast.
- Få data från produktionen.
Det är viktigt att få tillgång till åtminstone en liten mängd produktionsdata så snabbt som möjligt. Det är nästan omöjligt att få fram antalet unika fall, konfigurationer och inställningar under laboratorieförhållanden. Snabb åtkomst till resultaten gör att du snabbt kan lära dig om potentiella problem och ta hänsyn till dem i systemarkitekturen.
- Följ inte andras råd och resultat – samla in din egen data.
Följ principerna för att samla in och analysera data, men acceptera inte blint andras resultat och uttalanden. Bara du kan veta exakt vad som fungerar för dina användare. Dina system och dina kunder kan skilja sig betydligt från andra företag. Lyckligtvis finns nu analysverktyg tillgängliga och lätta att använda. Resultaten du får kanske inte är vad Netflix, Facebook, Akamai och andra företag hävdar. I vårt fall skiljer sig prestandan för TLS, HTTP2 eller statistik på DNS-förfrågningar från resultaten från Facebook, Uber, Akamai – eftersom vi har olika enheter, klienter och dataflöden.
- Följ inte modetrender i onödan och utvärdera effektiviteten.
Börja enkelt. Det är bättre att göra ett enkelt fungerande system på kort tid än att lägga enormt mycket tid på att utveckla komponenter som du inte behöver. Lös uppgifter och problem som är viktiga utifrån dina mätningar och resultat.
- Gör dig redo för nya applikationer.
Precis som det är svårt att förutse alla problem är det svårt att förutse fördelarna och tillämpningarna i förväg. Ta reda på startups - deras förmåga att anpassa sig till kundernas villkor. I ditt fall kan du upptäcka nya problem och deras lösningar. I vårt projekt satte vi ett mål att minska fördröjningen av förfrågningar. Men under analysen och diskussionerna insåg vi att vi också kan använda proxyservrar:
- att balansera trafik över AWS-regioner och minska kostnaderna;
- att modellera CDN-stabilitet;
- för att konfigurera DNS;
- för att konfigurera TLS/TCP.
Slutsats
I rapporten beskrev jag hur Netflix löser problemet med att accelerera Internetförfrågningar mellan klienter och molnet. Hur vi samlar in data med hjälp av ett samplingssystem på kunder och använder den insamlade historiska informationen för att dirigera 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, stamnätverk och DNS-servrar för att uppnå denna uppgift.
Vår lösning är dock bara ett exempel på hur vi på Netflix implementerade ett sådant system. Vad fungerade för oss. Den tillämpade delen av min rapport för dig är principerna för utveckling och stöd som vi följer och uppnår goda resultat.
Vår lösning på problemet kanske inte passar dig. Däremot kvarstår teorin och designprinciperna, även om du inte har din egen CDN-infrastruktur, eller om den skiljer sig väsentligt från vår.
Vikten av hastigheten på affärsförfrågningar är också fortfarande viktig. Och även för en enkel tjänst måste du göra ett val: mellan molnleverantörer, serverplats, CDN- och DNS-leverantörer. Ditt val kommer att påverka effektiviteten av Internetfrågor för dina kunder. Och det är viktigt för dig att mäta och förstå detta inflytande.
Börja med enkla lösningar, bry dig om hur du ändrar produkten. Lär dig allt eftersom 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 haverier under designprocessen. Och då kan du påskynda din utvecklingsprocess, förbättra lösningseffektiviteten, undvika onödig supportbörda och sova lugnt.
I år i onlineformat. Du kan ställa frågor till en av DevOps fäder, John Willis själv!
Källa: will.com