Netflix is de leider op de internettelevisiemarkt - het bedrijf dat dit segment heeft gecreëerd en actief ontwikkelt. Netflix staat niet alleen bekend om zijn uitgebreide catalogus met films en tv-series die vanuit bijna elke hoek van de planeet en elk apparaat met een beeldscherm beschikbaar zijn, maar ook om zijn betrouwbare infrastructuur en unieke technische cultuur.
Een duidelijk voorbeeld van de Netflix-aanpak voor het ontwikkelen en ondersteunen van complexe systemen werd gepresenteerd op DevOops 2019 - Directeur Ontwikkeling bij Netflix. Afgestudeerd aan de faculteit Computationele Wiskunde en Wiskunde van de Staatsuniversiteit van Nizjni Novgorod. Lobatsjevski, Sergey, een van de eerste ingenieurs in het Open Connect - CDN-team bij Netflix. Hij bouwde systemen voor het monitoren en analyseren van videogegevens, lanceerde een populaire dienst voor het beoordelen van de snelheid van de internetverbinding FAST.com, en heeft de afgelopen jaren gewerkt aan het optimaliseren van internetverzoeken zodat de Netflix-applicatie zo snel mogelijk werkt voor gebruikers.
Het rapport kreeg de beste recensies van conferentiedeelnemers en we hebben een tekstversie voor u opgesteld.
In zijn rapport sprak Sergei gedetailleerd
- over wat de vertraging van internetverzoeken tussen de client en server beïnvloedt;
- hoe deze vertraging kan worden verminderd;
- hoe je fouttolerante systemen ontwerpt, onderhoudt en monitort;
- hoe u in korte tijd resultaten kunt bereiken, en met minimaal risico voor het bedrijf;
- hoe u resultaten kunt analyseren en van fouten kunt leren.
Antwoorden op deze vragen zijn niet alleen nodig voor degenen die in grote bedrijven werken.
De gepresenteerde principes en technieken moeten bekend zijn en in de praktijk worden gebracht door iedereen die internetproducten ontwikkelt en ondersteunt.
Vervolgens volgt het verhaal vanuit het perspectief van de spreker.
Het belang van internetsnelheid
De snelheid van internetverzoeken houdt rechtstreeks verband met het bedrijfsleven. Neem de winkelindustrie: Amazon in 2009 dat een vertraging van 100 ms resulteert in een omzetverlies van 1%.
Er zijn steeds meer mobiele apparaten, gevolgd door mobiele sites en applicaties. Als het laden van uw pagina langer dan drie seconden duurt, verliest u ongeveer de helft van uw gebruikers. MET Google houdt rekening met de laadsnelheid van uw pagina in de zoekresultaten: hoe sneller de pagina, hoe hoger de positie in Google.
Verbindingssnelheid is ook belangrijk in financiële instellingen waar latentie van cruciaal belang is. In 2015, Hibernia-netwerken een kabel van $ 400 miljoen tussen New York en Londen om de latentie tussen de steden met 6 ms te verminderen. Stel je voor: $ 66 miljoen voor een latentiereductie van 1 ms!
Volgens , verbindingssnelheden boven 5 Mbit/s hebben niet langer rechtstreeks invloed op de laadsnelheid van een typische website. Er is echter een lineair verband tussen de latentie van de verbinding en de laadsnelheid van de pagina:
Netflix is echter geen typisch product. De impact van latentie en snelheid op de gebruiker is een actief gebied van analyse en ontwikkeling. Het laden van applicaties en het selecteren van inhoud zijn afhankelijk van de latentie, maar het laden van statische elementen en streaming is ook afhankelijk van de verbindingssnelheid. Het analyseren en optimaliseren van de belangrijkste factoren die de gebruikerservaring beïnvloeden, is een actief ontwikkelgebied voor verschillende teams bij Netflix. Een van de doelen is het verminderen van de latentie van verzoeken tussen Netflix-apparaten en de cloudinfrastructuur.
In het rapport zullen we ons specifiek richten op het verminderen van de latency aan de hand van het voorbeeld van de Netflix-infrastructuur. Laten we vanuit een praktisch oogpunt bekijken hoe we de processen van ontwerp, ontwikkeling en werking van complexe gedistribueerde systemen kunnen benaderen en tijd kunnen besteden aan innovatie en resultaten, in plaats van het diagnosticeren van operationele problemen en storingen.
Binnen Netflix
Duizenden verschillende apparaten ondersteunen Netflix-apps. Ze zijn ontwikkeld door vier verschillende teams, die aparte versies van de client maken voor Android, iOS, TV en webbrowsers. En we besteden veel aandacht aan het verbeteren en personaliseren van de gebruikerservaring. Om dit te doen, voeren we honderden A/B-tests parallel uit.
Personalisatie wordt ondersteund door honderden microservices in de AWS-cloud, die gepersonaliseerde gebruikersgegevens, het verzenden van zoekopdrachten, telemetrie, Big Data en codering bieden. Verkeersvisualisatie ziet er als volgt uit:
Aan de linkerkant bevindt zich het toegangspunt en vervolgens wordt het verkeer verdeeld over enkele honderden microservices die worden ondersteund door verschillende backend-teams.
Een ander belangrijk onderdeel van onze infrastructuur is het Open Connect CDN, dat statische inhoud aan de eindgebruiker levert: video's, afbeeldingen, clientcode, enz. Het CDN bevindt zich op aangepaste servers (OCA - Open Connect Appliance). Binnenin bevinden zich arrays van SSD- en HDD-schijven waarop geoptimaliseerd FreeBSD draait, met NGINX en een reeks services. Wij ontwerpen en optimaliseren hardware- en softwarecomponenten zodat zo’n CDN-server zoveel mogelijk data naar gebruikers kan sturen.
De “muur” van deze servers op het internetverkeersuitwisselingspunt (Internet eXchange - IX) ziet er als volgt uit:
Internet Exchange biedt internetserviceproviders en contentproviders de mogelijkheid om met elkaar te 'verbinden' om directer gegevens op internet uit te wisselen. Er zijn ongeveer 70-80 Internet Exchange-punten over de hele wereld waar onze servers zijn geïnstalleerd, en we installeren en onderhouden deze onafhankelijk:
Daarnaast leveren we ook servers rechtstreeks aan internetproviders, die zij in hun netwerk installeren, waardoor de lokalisatie van Netflix-verkeer en de kwaliteit van streaming voor gebruikers worden verbeterd:
Een reeks AWS-services is verantwoordelijk voor het verzenden van videoverzoeken van clients naar CDN-servers, en voor het configureren van de servers zelf: het bijwerken van inhoud, programmacode, instellingen, enz. Voor dat laatste hebben we ook een backbone-netwerk gebouwd dat servers in Internet Exchange-punten verbindt met AWS. Het backbone-netwerk is een wereldwijd netwerk van glasvezelkabels en routers dat we kunnen ontwerpen en configureren op basis van onze behoeften.
Op , levert onze CDN-infrastructuur ongeveer ⅛ van het internetverkeer ter wereld tijdens piekuren en ⅓ van het verkeer in Noord-Amerika, waar Netflix het langst bestaat. Indrukwekkende cijfers, maar voor mij is een van de meest verbazingwekkende prestaties dat het gehele CDN-systeem wordt ontwikkeld en onderhouden door een team van nog geen 150 mensen.
Aanvankelijk was de CDN-infrastructuur ontworpen om videogegevens te leveren. Na verloop van tijd realiseerden we ons echter dat we het ook kunnen gebruiken om dynamische verzoeken van klanten in de AWS-cloud te optimaliseren.
Over internetversnelling
Tegenwoordig heeft Netflix drie AWS-regio's en de latentie van verzoeken aan de cloud zal afhangen van hoe ver de klant verwijderd is van de dichtstbijzijnde regio. Tegelijkertijd hebben we veel CDN-servers die worden gebruikt om statische inhoud te leveren. Is er een manier om dit raamwerk te gebruiken om dynamische zoekopdrachten te versnellen? Helaas is het echter onmogelijk om deze verzoeken in de cache op te slaan: API's zijn gepersonaliseerd en elk resultaat is uniek.
Laten we een proxy maken op de CDN-server en er verkeer doorheen sturen. Zal het sneller zijn?
Materieel
Laten we onthouden hoe netwerkprotocollen werken. Tegenwoordig maakt het meeste verkeer op internet gebruik van HTTPs, wat afhankelijk is van de lagere protocollen TCP en TLS. Om een client verbinding te laten maken met de server, wordt er een handshake uitgevoerd. Om een veilige verbinding tot stand te brengen, moet de client drie keer berichten uitwisselen met de server en nog minstens één keer om gegevens over te dragen. Met een latentie per round trip (RTT) van 100 ms zou het ons 400 ms kosten om het eerste stukje gegevens te ontvangen:
Als we de certificaten op de CDN-server plaatsen, kan de handshake-tijd tussen de client en de server aanzienlijk worden verkort als de CDN dichterbij is. Laten we aannemen dat de latentie naar de CDN-server 30 ms is. Vervolgens duurt het 220 ms om het eerste bit te ontvangen:
Maar daar houden de voordelen niet op. Zodra een verbinding tot stand is gebracht, vergroot TCP het congestievenster (de hoeveelheid informatie die het parallel via die verbinding kan verzenden). Als een datapakket verloren gaat, verkleinen klassieke implementaties van het TCP-protocol (zoals TCP New Reno) het open “venster” met de helft. De groei van het congestievenster en de snelheid van het herstel na verlies zijn opnieuw afhankelijk van de vertraging (RTT) naar de server. Als deze verbinding slechts tot aan de CDN-server gaat, zal dit herstel sneller verlopen. Tegelijkertijd is pakketverlies een standaardverschijnsel, vooral bij draadloze netwerken.
De internetbandbreedte kan worden verminderd, vooral tijdens piekuren, als gevolg van verkeer van gebruikers, wat tot files kan leiden. Er is echter op internet geen manier om voorrang te geven aan sommige verzoeken boven andere. Geef bijvoorbeeld voorrang aan kleine en latentiegevoelige verzoeken boven ‘zware’ datastromen die het netwerk belasten. In ons geval stelt het hebben van ons eigen backbone-netwerk ons echter in staat dit te doen op een deel van het verzoekpad – tussen het CDN en de cloud, en we kunnen het volledig configureren. U kunt ervoor zorgen dat kleine en latentiegevoelige pakketten prioriteit krijgen, en dat grote gegevensstromen iets later plaatsvinden. Hoe dichter het CDN bij de klant staat, hoe groter de efficiëntie.
Protocollen op applicatieniveau (OSI Level 7) hebben ook invloed op de latentie. Nieuwe protocollen zoals HTTP/2 optimaliseren de prestaties van parallelle verzoeken. We hebben echter wel Netflix-clients met oudere apparaten die de nieuwe protocollen niet ondersteunen. Niet alle clients kunnen worden bijgewerkt of optimaal worden geconfigureerd. Tegelijkertijd is er tussen de CDN-proxy en de cloud volledige controle en de mogelijkheid om nieuwe, optimale protocollen en instellingen te gebruiken. Het ineffectieve deel met oude protocollen werkt alleen tussen de client en de CDN-server. Bovendien kunnen we multiplexverzoeken doen op een reeds bestaande verbinding tussen het CDN en de cloud, waardoor het verbindingsgebruik op TCP-niveau wordt verbeterd:
Wij meten
Ondanks dat de theorie verbeteringen belooft, haasten wij ons niet om het systeem meteen in productie te nemen. In plaats daarvan moeten we eerst bewijzen dat het idee in de praktijk zal werken. Om dit te doen, moet u verschillende vragen beantwoorden:
- snelheid: zal een proxy sneller zijn?
- Betrouwbaarheid: Zal het vaker kapot gaan?
- Ingewikkeldheid: hoe integreren met applicaties?
- kosten: Hoeveel kost het om extra infrastructuur in te zetten?
Laten we eens in detail bekijken hoe we het eerste punt beoordelen. De rest wordt op soortgelijke wijze behandeld.
Om de snelheid van verzoeken te analyseren, willen we gegevens van alle gebruikers verkrijgen, zonder veel tijd aan de ontwikkeling te besteden en zonder de productie te onderbreken. Hiervoor zijn verschillende benaderingen:
- RUM, of passieve verzoekmeting. We meten de uitvoeringstijd van huidige verzoeken van gebruikers en zorgen voor volledige gebruikersdekking. Het nadeel is dat het signaal door veel factoren niet erg stabiel is, bijvoorbeeld vanwege verschillende verzoekgroottes, verwerkingstijd op de server en client. Bovendien kunt u een nieuwe configuratie niet zonder effect in productie testen.
- Laboratorium testen. Speciale servers en infrastructuur die clients simuleren. Met hun hulp voeren wij de nodige tests uit. Zo krijgen wij volledige controle over de meetresultaten en een helder signaal. Maar er is geen volledige dekking van apparaten en gebruikerslocaties (vooral met een wereldwijde service en ondersteuning voor duizenden apparaatmodellen).
Hoe combineer je de voordelen van beide methoden?
Ons team heeft een oplossing gevonden. We schreven een klein stukje code – een voorbeeld – dat we in onze applicatie inbouwden. Met probes kunnen we volledig gecontroleerde netwerktests uitvoeren vanaf onze apparaten. Het werkt als volgt:
- Kort nadat de applicatie is geladen en de eerste activiteit is voltooid, voeren we onze tests uit.
- De client doet een verzoek aan de server en ontvangt een “recept” voor de test. Het recept is een lijst met URL's waarnaar een HTTP(s)-verzoek moet worden gedaan. Bovendien configureert het recept verzoekparameters: vertragingen tussen verzoeken, hoeveelheid opgevraagde gegevens, HTTP(s)-headers, enz. Tegelijkertijd kunnen we verschillende recepten parallel testen - bij het aanvragen van een configuratie bepalen we willekeurig welk recept we moeten uitgeven.
- De starttijd van de probe wordt zo gekozen dat deze niet conflicteert met het actieve gebruik van netwerkbronnen op de client. In wezen wordt het tijdstip geselecteerd waarop de client niet actief is.
- Na ontvangst van het recept doet de klant parallel verzoeken aan elk van de URL's. Het verzoek aan elk van de adressen kan worden herhaald - de zogenaamde. "pulsen". Bij de eerste impuls meten we hoe lang het duurde om een verbinding tot stand te brengen en gegevens te downloaden. Bij de tweede puls meten we de tijd die nodig is om gegevens te laden via een reeds tot stand gebrachte verbinding. Vóór de derde kunnen we een vertraging instellen en de snelheid meten waarmee een herverbinding tot stand wordt gebracht, enz.
Tijdens de test meten we alle parameters die het apparaat kan verkrijgen:
- DNS-verzoektijd;
- Tijd voor het instellen van de TCP-verbinding;
- Tijd voor het instellen van de TLS-verbinding;
- tijdstip waarop de eerste byte aan gegevens wordt ontvangen;
- totale laadtijd;
- statusresultaatcode.
- Nadat alle pulsen zijn voltooid, laadt het monster alle metingen voor analyse.
Kernpunten zijn een minimale afhankelijkheid van logica op de client, dataverwerking op de server en het meten van parallelle verzoeken. Zo kunnen we de invloed van verschillende factoren die de prestaties van zoekopdrachten beïnvloeden, isoleren en testen, deze binnen één recept variëren en resultaten van echte klanten verkrijgen.
Deze infrastructuur is nuttig gebleken voor meer dan alleen analyse van queryprestaties. Momenteel hebben we 14 actieve recepten, meer dan 6000 monsters per seconde, ontvangen we gegevens uit alle hoeken van de aarde en hebben we volledige apparaatdekking. Als Netflix een soortgelijke dienst van een derde partij zou kopen, zou dit miljoenen dollars per jaar kosten, met een veel slechtere dekking.
Theorie testen in de praktijk: prototype
Met een dergelijk systeem konden we de effectiviteit van CDN-proxy’s op verzoeklatentie evalueren. Nu heb je nodig:
- maak een proxy-prototype;
- plaats het prototype op een CDN;
- bepalen hoe clients naar een proxy op een specifieke CDN-server moeten worden geleid;
- Vergelijk de prestaties met verzoeken in AWS zonder proxy.
De taak is om de effectiviteit van de voorgestelde oplossing zo snel mogelijk te evalueren. We hebben voor Go gekozen om het prototype te implementeren vanwege de beschikbaarheid van goede netwerkbibliotheken. Op elke CDN-server hebben we de prototype-proxy geïnstalleerd als een statisch binair bestand om de afhankelijkheden te minimaliseren en de integratie te vereenvoudigen. Bij de initiële implementatie hebben we zoveel mogelijk gebruik gemaakt van standaardcomponenten en kleine aanpassingen voor het poolen van HTTP/2-verbindingen en het multiplexen van verzoeken.
Om de balans tussen de AWS-regio's in evenwicht te brengen, hebben we een geografische DNS-database gebruikt, dezelfde database die werd gebruikt om de clients in evenwicht te brengen. Om een CDN-server voor de client te selecteren, gebruiken we TCP Anycast voor servers in Internet Exchange (IX). Bij deze optie gebruiken we één IP-adres voor alle CDN-servers en wordt de client doorgestuurd naar de CDN-server met het minste aantal IP-hops. Bij CDN-servers die door internetproviders (ISP's) zijn geïnstalleerd, hebben we geen controle over de router om TCP Anycast te configureren, daarom gebruiken we , dat klanten naar internetproviders verwijst voor videostreaming.
We hebben dus drie soorten verzoekpaden: naar de cloud via het open internet, via een CDN-server in IX, of via een CDN-server bij een internetprovider. Ons doel is om te begrijpen welke manier beter is, en wat het voordeel is van een proxy, vergeleken met hoe verzoeken naar productie worden gestuurd. Om dit te doen, gebruiken we een bemonsteringssysteem als volgt:
Elk van de paden wordt een afzonderlijk doelwit en we kijken naar de tijd die we hebben. Voor analyse combineren we de proxyresultaten in één groep (selecteer de beste tijd tussen IX- en ISP-proxy's) en vergelijken we deze met de tijd van verzoeken aan de cloud zonder proxy:
Zoals u kunt zien waren de resultaten gemengd: in de meeste gevallen geeft de proxy een goede versnelling, maar er zijn ook voldoende klanten voor wie de situatie aanzienlijk zal verslechteren.
Daarom hebben we een aantal belangrijke dingen gedaan:
- We beoordeelden de verwachte prestaties van verzoeken van klanten naar de cloud via een CDN-proxy.
- We ontvingen gegevens van echte klanten, van allerlei soorten apparaten.
- We realiseerden ons dat de theorie niet 100% bevestigd was en dat het initiële aanbod met een CDN-proxy niet voor ons zou werken.
- We hebben geen risico's genomen; we hebben de productieconfiguraties voor klanten niet gewijzigd.
- Er was niets kapot.
Prototype 2.0
Dus terug naar de tekentafel en herhaal het proces opnieuw.
Het idee is dat we, in plaats van een 100% proxy te gebruiken, voor elke cliënt het snelste pad zullen bepalen, en daar verzoeken naartoe zullen sturen. Dat wil zeggen dat we zullen doen wat cliëntsturing wordt genoemd.
Hoe dit te implementeren? We kunnen geen logica aan de serverkant gebruiken, omdat... Het doel is om verbinding te maken met deze server. Er moet een manier zijn om dit op de client te doen. En doe dit idealiter met een minimale hoeveelheid complexe logica, om het probleem van de integratie met een groot aantal clientplatforms niet op te lossen.
Het antwoord is om DNS te gebruiken. In ons geval hebben we onze eigen DNS-infrastructuur en kunnen we een domeinzone opzetten waarvoor onze servers autoritair zullen zijn. Het werkt als volgt:
- De client doet een verzoek aan de DNS-server met behulp van een host, bijvoorbeeld api.netflix.xom.
- Het verzoek arriveert bij onze DNS-server
- De DNS-server weet welk pad het snelste is voor deze client en geeft het bijbehorende IP-adres uit.
De oplossing heeft een extra complexiteit: autoritaire DNS-providers zien het IP-adres van de klant niet en kunnen alleen het IP-adres lezen van de recursieve solver die de klant gebruikt.
Als gevolg hiervan moet onze autoritaire oplosser niet voor een individuele cliënt een beslissing nemen, maar voor een groep cliënten op basis van de recursieve oplosser.
Om dit op te lossen, gebruiken we dezelfde voorbeelden, aggregeren we de meetresultaten van clients voor elk van de recursieve solvers en beslissen waar we deze groep naartoe moeten sturen: een proxy via IX met behulp van TCP Anycast, via een ISP-proxy, of rechtstreeks naar de cloud.
We krijgen het volgende systeem:
Met het resulterende DNS-stuurmodel kunt u clients aansturen op basis van historische observaties van de snelheid van verbindingen van clients naar de cloud.
Nogmaals, de vraag is: hoe effectief zal deze aanpak werken? Om te antwoorden gebruiken we opnieuw ons sondesysteem. Daarom configureren we de presentatorconfiguratie, waarbij een van de doelen de richting volgt van DNS-sturing, de andere rechtstreeks naar de cloud gaat (huidige productie).
Als resultaat vergelijken we de resultaten en krijgen we een beoordeling van de effectiviteit:
Hierdoor hebben we een aantal belangrijke dingen geleerd:
- Met behulp van DNS Steering hebben we de verwachte prestaties van verzoeken van clients aan de cloud beoordeeld.
- We ontvingen gegevens van echte klanten, van allerlei soorten apparaten.
- De effectiviteit van het voorgestelde idee is bewezen.
- We hebben geen risico's genomen; we hebben de productieconfiguraties voor klanten niet gewijzigd.
- Er was niets kapot.
Nu over het moeilijke deel: we lanceren het in productie
Het makkelijke gedeelte is nu voorbij: er is een werkend prototype. Het moeilijkste deel is nu het lanceren van een oplossing voor al het Netflix-verkeer, dat wordt ingezet voor 150 miljoen gebruikers, duizenden apparaten, honderden microservices en een steeds veranderend product en infrastructuur. Netflix-servers ontvangen miljoenen verzoeken per seconde en het is gemakkelijk om de service te verbreken door onzorgvuldig handelen. Tegelijkertijd willen we verkeer dynamisch door duizenden CDN-servers op internet leiden, waar voortdurend en op het meest ongelegen moment iets verandert en kapot gaat.
En met dit alles heeft het team drie ingenieurs die verantwoordelijk zijn voor de ontwikkeling, implementatie en volledige ondersteuning van het systeem.
Daarom zullen we blijven praten over een goede en gezonde slaap.
Hoe kunt u doorgaan met de ontwikkeling zonder al uw tijd aan ondersteuning te besteden? Onze aanpak is gebaseerd op 3 principes:
- We verminderen de potentiële omvang van storingen (straal van de explosie).
- We bereiden ons voor op verrassingen - we verwachten dat er iets kapot zal gaan, ondanks testen en persoonlijke ervaring.
- Sierlijke degradatie - als iets niet goed werkt, moet het automatisch worden opgelost, ook al is het niet op de meest efficiënte manier.
Het bleek dat we in ons geval met deze benadering van het probleem een eenvoudige en effectieve oplossing kunnen vinden en de systeemondersteuning aanzienlijk kunnen vereenvoudigen. We realiseerden ons dat we een klein stukje code aan de client konden toevoegen en konden controleren op netwerkverzoekfouten veroorzaakt door verbindingsproblemen. Bij netwerkfouten maken we direct een terugval naar de cloud. Deze oplossing vergt geen grote inspanning van klantteams, maar verkleint voor ons de kans op onverwachte storingen en verrassingen aanzienlijk.
Uiteraard volgen we ondanks de terugval toch een duidelijke discipline tijdens de ontwikkeling:
- Voorbeeldtest.
- A/B-testen of Canarische Eilanden.
- Geleidelijke uitrol.
Met monsters is de aanpak beschreven; wijzigingen worden eerst getest aan de hand van een recept op maat.
Voor canary-tests hebben we vergelijkbare paren servers nodig waarop we kunnen vergelijken hoe het systeem voor en na de wijzigingen werkt. Om dit te doen, selecteren we uit onze vele CDN-sites paren servers die vergelijkbaar verkeer ontvangen:
Vervolgens installeren we de build met de wijzigingen op de Canary-server. Om de resultaten te evalueren, gebruiken we een systeem dat ongeveer 100-150 statistieken vergelijkt met een voorbeeld van Control-servers:
Als het testen van de kanarie succesvol is, laten we het geleidelijk vrij, in golven. We updaten de servers niet op elke site tegelijkertijd. Het verlies van een hele site als gevolg van problemen heeft een grotere impact op de service voor gebruikers dan het verlies van hetzelfde aantal servers op verschillende locaties.
Over het algemeen hangt de effectiviteit en veiligheid van deze aanpak af van de kwantiteit en kwaliteit van de verzamelde statistieken. Voor ons zoekversnellingssysteem verzamelen we statistieken van alle mogelijke componenten:
- van klanten - aantal sessies en verzoeken, terugvalpercentages;
- proxy - statistieken over het aantal en het tijdstip van verzoeken;
- DNS - aantal en resultaten van verzoeken;
- cloud edge - aantal en tijd voor het verwerken van verzoeken in de cloud.
Dit alles wordt verzameld in één pijplijn, en afhankelijk van de behoeften beslissen we welke statistieken we naar realtime analyses sturen, en welke naar Elasticsearch of Big Data voor meer gedetailleerde diagnostiek.
Wij monitoren
In ons geval brengen we wijzigingen aan op het kritieke pad van verzoeken tussen de client en de server. Tegelijkertijd is het aantal verschillende componenten op de client, op de server en op de weg via internet enorm. Veranderingen op de client en server vinden voortdurend plaats - tijdens het werk van tientallen teams en natuurlijke veranderingen in het ecosysteem. Wij zitten er middenin: bij het diagnosticeren van problemen is de kans groot dat wij erbij betrokken worden. Daarom moeten we duidelijk begrijpen hoe we statistieken kunnen definiëren, verzamelen en analyseren om problemen snel te kunnen isoleren.
Idealiter volledige toegang tot alle soorten statistieken en filters in realtime. Maar er zijn veel meetgegevens, dus de kwestie van de kosten rijst. In ons geval scheiden we statistieken en ontwikkelingstools als volgt:
Om problemen op te sporen en te beoordelen, gebruiken we ons eigen open-source realtime systeem и - voor visualisatie. Het slaat geaggregeerde statistieken op in het geheugen, is betrouwbaar en kan worden geïntegreerd met het waarschuwingssysteem. Voor lokalisatie en diagnostiek hebben we toegang tot logs van Elasticsearch en Kibana. Voor statistische analyse en modellering gebruiken we big data en visualisatie in Tableau.
Het lijkt erop dat deze aanpak erg moeilijk is om mee te werken. Door statistieken en hulpmiddelen echter hiërarchisch te organiseren, kunnen we een probleem snel analyseren, het type probleem bepalen en vervolgens dieper ingaan op gedetailleerde statistieken. Over het algemeen besteden we ongeveer 1-2 minuten aan het identificeren van de oorzaak van de storing. Hierna werken we met een specifiek team aan diagnostiek - van tientallen minuten tot enkele uren.
Zelfs als de diagnose snel wordt gesteld, willen we niet dat dit vaak gebeurt. Idealiter ontvangen wij alleen een kritische melding als er sprake is van een significante impact op de dienstverlening. Voor ons systeem voor het versnellen van zoekopdrachten hebben we slechts twee waarschuwingen die u op de hoogte stellen:
- Klantterugvalpercentage - beoordeling van klantgedrag;
- percentage Sondefouten - stabiliteitsgegevens van netwerkcomponenten.
Deze kritische waarschuwingen controleren of het systeem voor de meeste gebruikers werkt. We kijken hoeveel klanten gebruik maakten van fallback als ze geen verzoekversnelling konden krijgen. We krijgen gemiddeld minder dan één kritieke waarschuwing per week, ook al vinden er heel wat veranderingen plaats in het systeem. Waarom is dit genoeg voor ons?
- Er is een terugval van de client als onze proxy niet werkt.
- Er is een automatisch stuursysteem dat reageert op problemen.
Meer details over dit laatste. Ons proefsysteem, en het systeem om automatisch het optimale pad voor verzoeken van de klant naar de cloud te bepalen, stelt ons in staat om bepaalde problemen automatisch op te lossen.
Laten we terugkeren naar onze voorbeeldconfiguratie en drie padcategorieën. Naast de laadtijd kunnen we kijken naar het feit van de bezorging zelf. Als het niet mogelijk was om de gegevens te laden, kunnen we, door naar de resultaten langs verschillende paden te kijken, bepalen waar en wat kapot is gegaan, en of we dit automatisch kunnen repareren door het verzoekpad te wijzigen.
Voorbeelden:
Dit proces kan worden geautomatiseerd. Neem het op in het stuursysteem. En leer hem te reageren op prestatie- en betrouwbaarheidsproblemen. Als er iets kapot gaat, reageer dan als er een betere optie is. Tegelijkertijd is een onmiddellijke reactie niet cruciaal, dankzij de terugval op klanten.
De principes van systeemondersteuning kunnen dus als volgt worden geformuleerd:
- het verminderen van de omvang van storingen;
- het verzamelen van statistieken;
- We repareren storingen automatisch als dat mogelijk is;
- als dit niet mogelijk is, stellen wij u hiervan op de hoogte;
- We werken aan dashboards en triagetools voor een snelle reactie.
Les geleerd
Het schrijven van een prototype kost niet veel tijd. In ons geval was het na 4 maanden klaar. Hiermee ontvingen we nieuwe statistieken en 10 maanden na de start van de ontwikkeling ontvingen we het eerste productieverkeer. Toen begon het vervelende en zeer moeilijke werk: het systeem geleidelijk aan produceren en opschalen, het belangrijkste verkeer migreren en leren van fouten. Dit effectieve proces zal echter niet lineair verlopen; ondanks alle inspanningen kan niet alles worden voorspeld. Het is veel effectiever om snel te herhalen en te reageren op nieuwe gegevens.
Op basis van onze ervaring kunnen wij het volgende aanbevelen:
- Vertrouw niet op je intuïtie.
Onze intuïtie liet ons voortdurend in de steek, ondanks de ruime ervaring van onze teamleden. We hebben bijvoorbeeld de verwachte snelheid bij het gebruik van een CDN-proxy of het gedrag van TCP Anycast verkeerd voorspeld.
- Haal gegevens uit de productie op.
Het is belangrijk om zo snel mogelijk toegang te krijgen tot minimaal een kleine hoeveelheid productiegegevens. Het is vrijwel onmogelijk om het aantal unieke cases, configuraties en instellingen onder laboratoriumomstandigheden te achterhalen. Snelle toegang tot de resultaten stelt u in staat snel potentiële problemen te leren kennen en hiermee rekening te houden in de systeemarchitectuur.
- Volg niet het advies en de resultaten van anderen, maar verzamel uw eigen gegevens.
Volg de principes voor het verzamelen en analyseren van gegevens, maar accepteer niet blindelings de resultaten en uitspraken van anderen. Alleen u kunt precies weten wat voor uw gebruikers werkt. Uw systemen en uw klanten kunnen aanzienlijk verschillen van die van andere bedrijven. Gelukkig zijn er nu analysehulpmiddelen beschikbaar en gemakkelijk te gebruiken. De resultaten die u krijgt, zijn mogelijk niet wat Netflix, Facebook, Akamai en andere bedrijven beweren. In ons geval verschillen de prestaties van TLS, HTTP2 of statistieken over DNS-verzoeken van de resultaten van Facebook, Uber, Akamai - omdat we verschillende apparaten, clients en datastromen hebben.
- Volg modetrends niet onnodig en evalueer de effectiviteit.
Begin eenvoudig. Het is beter om in korte tijd een eenvoudig werkend systeem te maken dan een enorme hoeveelheid tijd te besteden aan het ontwikkelen van componenten die je niet nodig hebt. Los taken en problemen op die er toe doen op basis van uw metingen en resultaten.
- Maak je klaar voor nieuwe toepassingen.
Net zoals het moeilijk is om alle problemen te voorspellen, is het ook moeilijk om de voordelen en toepassingen vooraf te voorspellen. Neem een voorbeeld aan startups: hun vermogen om zich aan te passen aan de omstandigheden van de klant. In uw geval ontdekt u mogelijk nieuwe problemen en hun oplossingen. In ons project hebben we ons ten doel gesteld de latentie van verzoeken te verminderen. Tijdens de analyse en discussies realiseerden we ons echter dat we ook proxyservers kunnen gebruiken:
- om het verkeer tussen AWS-regio's in evenwicht te brengen en de kosten te verlagen;
- het modelleren van CDN-stabiliteit;
- DNS configureren;
- om TLS/TCP te configureren.
Conclusie
In het rapport beschreef ik hoe Netflix het probleem oplost van het versnellen van internetverzoeken tussen clients en de cloud. Hoe we gegevens verzamelen met behulp van een bemonsteringssysteem over klanten, en de verzamelde historische gegevens gebruiken om productieaanvragen van klanten via het snelste pad op internet te routeren. Hoe we de principes van netwerkprotocollen, onze CDN-infrastructuur, backbone-netwerk en DNS-servers gebruiken om deze taak te volbrengen.
Onze oplossing is echter slechts een voorbeeld van hoe wij bij Netflix een dergelijk systeem hebben geïmplementeerd. Wat voor ons werkte. Het toegepaste deel van mijn rapport voor u zijn de principes van ontwikkeling en ondersteuning die we volgen en goede resultaten behalen.
Onze oplossing voor het probleem past mogelijk niet bij u. De theorie en ontwerpprincipes blijven echter bestaan, ook als je niet over een eigen CDN-infrastructuur beschikt, of als deze aanzienlijk afwijkt van de onze.
Ook het belang van de snelheid van zakelijke verzoeken blijft belangrijk. En zelfs voor een simpele dienst moet je een keuze maken: tussen cloudproviders, serverlocatie, CDN- en DNS-providers. Uw keuze heeft invloed op de effectiviteit van internetzoekopdrachten voor uw klanten. En het is belangrijk dat u deze invloed meet en begrijpt.
Begin met eenvoudige oplossingen, let op hoe u het product verandert. Leer gaandeweg en verbeter het systeem op basis van gegevens van uw klanten, uw infrastructuur en uw bedrijf. Denk na over de mogelijkheid van onverwachte storingen tijdens het ontwerpproces. En dan kunt u uw ontwikkelingsproces versnellen, de efficiëntie van oplossingen verbeteren, onnodige ondersteuningslasten vermijden en rustig slapen.
Dit jaar in online-formaat. Vragen kun je stellen aan één van de grondleggers van DevOps, John Willis zelf!
Bron: www.habr.com