Netflix è il leader nel mercato della televisione su Internet, la società che ha creato e sta sviluppando attivamente questo segmento. Netflix è noto non solo per il suo ampio catalogo di film e serie TV disponibili da quasi ogni angolo del pianeta e da qualsiasi dispositivo dotato di display, ma anche per la sua infrastruttura affidabile e una cultura ingegneristica unica.
Un chiaro esempio dell’approccio di Netflix allo sviluppo e al supporto di sistemi complessi è stato presentato al DevOops 2019 - Direttore dello sviluppo presso Netflix. Laureato alla Facoltà di Matematica Computazionale e Matematica dell'Università Statale di Nizhny Novgorod. Lobachevskij, Sergey uno dei primi ingegneri del team Open Connect - CDN di Netflix. Ha costruito sistemi per il monitoraggio e l'analisi dei dati video, ha lanciato il popolare servizio per valutare la velocità della connessione Internet FAST.com e negli ultimi anni ha lavorato all'ottimizzazione delle richieste Internet in modo che l'applicazione Netflix funzioni il più rapidamente possibile per gli utenti.
Il rapporto ha ricevuto le migliori recensioni dai partecipanti alla conferenza e abbiamo preparato per voi una versione testuale.
Nel suo rapporto, Sergei ha parlato in dettaglio
- su cosa influenza il ritardo delle richieste Internet tra client e server;
- come ridurre questo ritardo;
- come progettare, mantenere e monitorare i sistemi tolleranti agli errori;
- come ottenere risultati in breve tempo e con rischi minimi per l'azienda;
- come analizzare i risultati e imparare dagli errori.
Le risposte a queste domande non servono solo a chi lavora nelle grandi aziende.
I principi e le tecniche presentati dovrebbero essere conosciuti e praticati da chiunque sviluppi e supporti prodotti Internet.
La successiva è la narrazione dal punto di vista di chi parla.
L'importanza della velocità di internet
La velocità delle richieste Internet è direttamente correlata al business. Consideriamo il settore dello shopping: Amazon nel 2009 che un ritardo di 100 ms comporta una perdita dell'1% delle vendite.
Esistono sempre più dispositivi mobili, seguiti da siti e applicazioni mobili. Se il caricamento della tua pagina impiega più di 3 secondi, stai perdendo circa la metà dei tuoi utenti. CON Google tiene conto della velocità di caricamento della tua pagina nei risultati di ricerca: più veloce è la pagina, maggiore è la sua posizione su Google.
La velocità di connessione è importante anche negli istituti finanziari in cui la latenza è fondamentale. Nel 2015, Hibernia Networks un cavo da 400 milioni di dollari tra New York e Londra per ridurre la latenza tra le città di 6 ms. Immagina 66 milioni di dollari per 1 ms di riduzione della latenza!
Secondo , velocità di connessione superiori a 5 Mbit/s non influiscono più direttamente sulla velocità di caricamento di un tipico sito web. Tuttavia, esiste una relazione lineare tra latenza della connessione e velocità di caricamento della pagina:
Tuttavia, Netflix non è un prodotto tipico. L'impatto della latenza e della velocità sull'utente è un'area attiva di analisi e sviluppo. Il caricamento delle applicazioni e la selezione dei contenuti dipendono dalla latenza, ma il caricamento di elementi statici e lo streaming dipendono anche dalla velocità di connessione. L'analisi e l'ottimizzazione dei fattori chiave che influenzano l'esperienza dell'utente è un'area di sviluppo attiva per diversi team di Netflix. Uno degli obiettivi è ridurre la latenza delle richieste tra i dispositivi Netflix e l'infrastruttura cloud.
Nel rapporto ci concentreremo specificamente sulla riduzione della latenza utilizzando l'esempio dell'infrastruttura Netflix. Consideriamo da un punto di vista pratico come affrontare i processi di progettazione, sviluppo e funzionamento di sistemi distribuiti complessi e dedichiamo tempo all'innovazione e ai risultati, piuttosto che alla diagnosi di problemi operativi e guasti.
All'interno di Netflix
Migliaia di dispositivi diversi supportano le app Netflix. Sono sviluppati da quattro team diversi, che realizzano versioni separate del client per Android, iOS, TV e browser web. E dedichiamo molti sforzi al miglioramento e alla personalizzazione dell'esperienza dell'utente. Per fare ciò, eseguiamo centinaia di test A/B in parallelo.
La personalizzazione è supportata da centinaia di microservizi nel cloud AWS, che forniscono dati utente personalizzati, invio di query, telemetria, Big Data e codifica. La visualizzazione del traffico si presenta così:
Sulla sinistra c'è il punto di ingresso, quindi il traffico viene distribuito tra diverse centinaia di microservizi supportati da diversi team di backend.
Un altro componente importante della nostra infrastruttura è il CDN Open Connect, che fornisce contenuti statici all'utente finale: video, immagini, codice client, ecc. La CDN si trova su server personalizzati (OCA - Open Connect Appliance). All'interno ci sono array di unità SSD e HDD che eseguono FreeBSD ottimizzato, con NGINX e una serie di servizi. Progettiamo e ottimizziamo i componenti hardware e software in modo che tale server CDN possa inviare quanti più dati possibile agli utenti.
Il "muro" di questi server nel punto di scambio del traffico Internet (Internet eXchange - IX) si presenta così:
Internet Exchange offre la possibilità ai fornitori di servizi Internet e di contenuti di "connettersi" tra loro per scambiare più direttamente dati su Internet. Ci sono circa 70-80 punti di scambio Internet in tutto il mondo dove sono installati i nostri server e li installiamo e manteniamo in modo indipendente:
Inoltre, forniamo direttamente ai provider Internet anche server che installano nella loro rete, migliorando la localizzazione del traffico Netflix e la qualità dello streaming per gli utenti:
Una serie di servizi AWS è responsabile dell'invio delle richieste video dai client ai server CDN, nonché della configurazione dei server stessi: aggiornamento di contenuti, codice di programma, impostazioni, ecc. Per quest'ultimo abbiamo anche realizzato una rete backbone che collega i server nei punti Internet Exchange con AWS. La rete backbone è una rete globale di cavi e router in fibra ottica che possiamo progettare e configurare in base alle nostre esigenze.
Su , la nostra infrastruttura CDN fornisce circa ⅛ del traffico Internet mondiale durante le ore di punta e ⅓ del traffico in Nord America, dove Netflix è presente da più tempo. Numeri impressionanti, ma per me uno dei risultati più sorprendenti è che l’intero sistema CDN è sviluppato e mantenuto da un team di meno di 150 persone.
Inizialmente l’infrastruttura CDN era progettata per fornire dati video. Tuttavia, con il tempo ci siamo resi conto che possiamo utilizzarlo anche per ottimizzare le richieste dinamiche dei clienti nel cloud AWS.
Informazioni sull'accelerazione di Internet
Oggi Netflix ha 3 regioni AWS e la latenza delle richieste al cloud dipenderà dalla distanza del cliente dalla regione più vicina. Allo stesso tempo, disponiamo di molti server CDN che vengono utilizzati per fornire contenuti statici. Esiste un modo per utilizzare questo framework per accelerare le query dinamiche? Tuttavia, sfortunatamente, è impossibile memorizzare nella cache queste richieste: le API sono personalizzate e ogni risultato è unico.
Creiamo un proxy sul server CDN e iniziamo a inviare traffico attraverso di esso. Sarà più veloce?
materiale
Ricordiamo come funzionano i protocolli di rete. Oggi, la maggior parte del traffico su Internet utilizza HTTP, che dipende dai protocolli di livello inferiore TCP e TLS. Affinché un client possa connettersi al server, esegue un handshake e per stabilire una connessione sicura, il client deve scambiare messaggi con il server tre volte e almeno un'altra volta per trasferire i dati. Con una latenza per round trip (RTT) di 100 ms, ci vorrebbero 400 ms per ricevere il primo bit di dati:
Se inseriamo i certificati sul server CDN, il tempo di handshake tra client e server può essere notevolmente ridotto se il CDN è più vicino. Supponiamo che la latenza sul server CDN sia di 30 ms. Quindi ci vorranno 220 ms per ricevere il primo bit:
Ma i vantaggi non finiscono qui. Una volta stabilita una connessione, TCP aumenta la finestra di congestione (la quantità di informazioni che può trasmettere su quella connessione in parallelo). Se un pacchetto di dati viene perso, le implementazioni classiche del protocollo TCP (come TCP New Reno) riducono della metà la “finestra” aperta. La crescita della finestra di congestione e la velocità del suo recupero dalla perdita dipendono ancora una volta dal ritardo (RTT) sul server. Se questa connessione arriva solo fino al server CDN, il ripristino sarà più veloce. Allo stesso tempo, la perdita di pacchetti è un fenomeno standard, soprattutto per le reti wireless.
La larghezza di banda Internet potrebbe ridursi, soprattutto nelle ore di punta, a causa del traffico degli utenti, il che può causare ingorghi. Tuttavia, su Internet non è possibile dare priorità ad alcune richieste rispetto ad altre. Ad esempio, dai priorità alle richieste piccole e sensibili alla latenza rispetto ai flussi di dati “pesanti” che caricano la rete. Tuttavia, nel nostro caso, avere la nostra rete dorsale ci consente di farlo su una parte del percorso della richiesta, tra la CDN e il cloud, e possiamo configurarlo completamente. Puoi assicurarti che i pacchetti piccoli e sensibili alla latenza abbiano la priorità e che i flussi di dati di grandi dimensioni vadano un po' più tardi. Più la CDN è vicina al cliente, maggiore è l’efficienza.
Anche i protocolli a livello di applicazione (OSI Livello 7) hanno un impatto sulla latenza. Nuovi protocolli come HTTP/2 ottimizzano le prestazioni delle richieste parallele. Tuttavia, disponiamo di client Netflix con dispositivi meno recenti che non supportano i nuovi protocolli. Non tutti i client possono essere aggiornati o configurati in modo ottimale. Allo stesso tempo, tra il proxy CDN e il cloud c'è il controllo completo e la possibilità di utilizzare protocolli e impostazioni nuovi e ottimali. La parte inefficace con i vecchi protocolli funzionerà solo tra il client e il server CDN. Inoltre, possiamo effettuare richieste multiplex su una connessione già stabilita tra la CDN e il cloud, migliorando l'utilizzo della connessione a livello TCP:
Misuriamo
Nonostante la teoria prometta miglioramenti, non ci affrettiamo immediatamente a mettere in produzione il sistema. Dobbiamo invece prima dimostrare che l’idea funzionerà nella pratica. Per fare ciò è necessario rispondere a diverse domande:
- velocità: un proxy sarà più veloce?
- Affidabilità: Si romperà più spesso?
- complessità: come integrarsi con le applicazioni?
- costo: Quanto costa implementare un'infrastruttura aggiuntiva?
Consideriamo in dettaglio il nostro approccio alla valutazione del primo punto. Il resto viene trattato in modo simile.
Per analizzare la velocità delle richieste, vogliamo ottenere dati per tutti gli utenti, senza dedicare molto tempo allo sviluppo e senza interrompere la produzione. Esistono diversi approcci per questo:
- RUM, o misurazione della richiesta passiva. Misuriamo il tempo di esecuzione delle richieste attuali degli utenti e garantiamo la piena copertura degli utenti. Lo svantaggio è che il segnale non è molto stabile a causa di molti fattori, ad esempio a causa delle diverse dimensioni delle richieste, del tempo di elaborazione sul server e sul client. Inoltre, non è possibile testare una nuova configurazione senza effetti nella produzione.
- Test di laboratorio. Server speciali e infrastrutture che simulano i client. Con il loro aiuto effettuiamo i test necessari. In questo modo otteniamo il pieno controllo sui risultati della misurazione e un segnale chiaro. Ma non esiste una copertura completa dei dispositivi e delle posizioni degli utenti (soprattutto con un servizio mondiale e il supporto per migliaia di modelli di dispositivi).
Come puoi combinare i vantaggi di entrambi i metodi?
Il nostro team ha trovato una soluzione. Abbiamo scritto un piccolo pezzo di codice, un campione, che abbiamo integrato nella nostra applicazione. Le sonde ci consentono di eseguire test di rete completamente controllati dai nostri dispositivi. Funziona così:
- Poco dopo aver caricato l'applicazione e completato l'attività iniziale, eseguiamo le nostre sonde.
- Il client effettua una richiesta al server e riceve una "ricetta" per il test. La ricetta è un elenco di URL a cui è necessario effettuare una richiesta HTTP(s). Inoltre, la ricetta configura i parametri della richiesta: ritardi tra le richieste, quantità di dati richiesti, intestazioni HTTP(s), ecc. Allo stesso tempo, possiamo testare diverse ricette diverse in parallelo: quando richiediamo una configurazione, determiniamo casualmente quale ricetta emettere.
- L'ora di avvio della sonda viene selezionata in modo da non entrare in conflitto con l'uso attivo delle risorse di rete sul client. Essenzialmente, l'ora viene selezionata quando il client non è attivo.
- Dopo aver ricevuto la ricetta, il client effettua richieste a ciascuno degli URL, in parallelo. La richiesta a ciascuno degli indirizzi può essere ripetuta, la cosiddetta. "impulsi". Al primo impulso misuriamo il tempo impiegato per stabilire la connessione e scaricare i dati. Al secondo impulso misuriamo il tempo necessario per caricare i dati su una connessione già stabilita. Prima del terzo possiamo impostare un ritardo e misurare la velocità con cui si stabilisce una riconnessione, ecc.
Durante il test misuriamo tutti i parametri che il dispositivo può ottenere:
- Orario richiesta DNS;
- Tempo di configurazione della connessione TCP;
- Tempo di configurazione della connessione TLS;
- ora di ricezione del primo byte di dati;
- tempo di caricamento totale;
- codice risultato stato.
- Una volta completati tutti gli impulsi, il campione carica tutte le misurazioni per l'analisi.
I punti chiave sono la dipendenza minima dalla logica del client, l'elaborazione dei dati sul server e la misurazione delle richieste parallele. Pertanto, siamo in grado di isolare e testare l'influenza di vari fattori che influenzano le prestazioni delle query, variarli all'interno di un'unica ricetta e ottenere risultati da clienti reali.
Questa infrastruttura si è rivelata utile non solo per l'analisi delle prestazioni delle query. Attualmente disponiamo di 14 ricette attive, più di 6000 campioni al secondo, con ricezione di dati da tutti gli angoli della terra e copertura completa del dispositivo. Se Netflix acquistasse un servizio simile da una terza parte, costerebbe milioni di dollari all’anno, con una copertura molto peggiore.
Teoria dei test in pratica: prototipo
Con un tale sistema siamo stati in grado di valutare l'efficacia dei proxy CDN sulla latenza delle richieste. Ora hai bisogno di:
- creare un prototipo proxy;
- posizionare il prototipo su una CDN;
- determinare come indirizzare i client a un proxy su uno specifico server CDN;
- Confronta le prestazioni con le richieste in AWS senza proxy.
Il compito è valutare l'efficacia della soluzione proposta il più rapidamente possibile. Abbiamo scelto Go per implementare il prototipo grazie alla disponibilità di buone librerie di rete. Su ciascun server CDN abbiamo installato il prototipo del proxy come binario statico per ridurre al minimo le dipendenze e semplificare l'integrazione. Nell'implementazione iniziale abbiamo utilizzato il più possibile componenti standard e piccole modifiche per il pooling delle connessioni HTTP/2 e il multiplexing delle richieste.
Per bilanciare le regioni AWS, abbiamo utilizzato un database DNS geografico, lo stesso utilizzato per bilanciare i client. Per selezionare un server CDN per il client, utilizziamo TCP Anycast per i server in Internet Exchange (IX). In questa opzione, utilizziamo un indirizzo IP per tutti i server CDN e il client verrà indirizzato al server CDN con il minor numero di hop IP. Nei server CDN installati dai provider Internet (ISP), non abbiamo il controllo sul router per configurare TCP Anycast, quindi utilizziamo , che indirizza i clienti ai provider Internet per lo streaming video.
Quindi, abbiamo tre tipi di percorsi di richiesta: al cloud tramite Internet aperta, tramite un server CDN in IX o tramite un server CDN situato presso un provider Internet. Il nostro obiettivo è capire quale sia la modalità migliore e qual è il vantaggio di un proxy rispetto a come le richieste vengono inviate alla produzione. Per fare ciò, utilizziamo un sistema di campionamento come segue:
Ciascuno dei percorsi diventa un obiettivo separato e guardiamo il tempo che abbiamo ottenuto. Per l'analisi, combiniamo i risultati del proxy in un gruppo (selezionamo il momento migliore tra i proxy IX e ISP) e li confrontiamo con il tempo delle richieste al cloud senza proxy:
Come puoi vedere, i risultati sono contrastanti: nella maggior parte dei casi il proxy fornisce una buona accelerazione, ma c'è anche un numero sufficiente di clienti per i quali la situazione peggiorerà in modo significativo.
Di conseguenza, abbiamo fatto diverse cose importanti:
- Abbiamo valutato le prestazioni previste delle richieste dei clienti al cloud tramite un proxy CDN.
- Abbiamo ricevuto dati da clienti reali, da tutti i tipi di dispositivi.
- Ci siamo resi conto che la teoria non era confermata al 100% e che l'offerta iniziale con un proxy CDN non avrebbe funzionato per noi.
- Non abbiamo corso rischi: non abbiamo modificato le configurazioni di produzione per i clienti.
- Niente era rotto.
Prototipo 2.0
Quindi, torniamo al tavolo da disegno e ripetiamo il processo da capo.
L'idea è che invece di utilizzare un proxy al 100%, determineremo il percorso più veloce per ciascun cliente e lì invieremo le richieste, ovvero faremo ciò che viene chiamato client Steering.
Come implementarlo? Non possiamo usare la logica lato server perché... L'obiettivo è connettersi a questo server. È necessario che ci sia un modo per farlo sul client. E idealmente, farlo con una logica complessa minima, in modo da non risolvere il problema dell'integrazione con un gran numero di piattaforme client.
La risposta è usare il DNS. Nel nostro caso, disponiamo di una nostra infrastruttura DNS e possiamo impostare una zona di dominio per la quale i nostri server saranno autoritari. Funziona così:
- Il client effettua una richiesta al server DNS utilizzando un host, ad esempio api.netflix.xom.
- La richiesta arriva al nostro server DNS
- Il server DNS sa quale è il percorso più veloce per questo client e fornisce il corrispondente indirizzo IP.
La soluzione presenta un'ulteriore complessità: i provider DNS autoritari non vedono l'indirizzo IP del client e possono solo leggere l'indirizzo IP del risolutore ricorsivo utilizzato dal client.
Di conseguenza, il nostro risolutore autoritario deve prendere una decisione non per un singolo cliente, ma per un gruppo di clienti in base al risolutore ricorsivo.
Per risolvere, utilizziamo gli stessi campioni, aggreghiamo i risultati delle misurazioni dei client per ciascuno dei risolutori ricorsivi e decidiamo dove inviare questo gruppo di essi: un proxy tramite IX utilizzando TCP Anycast, tramite un proxy ISP o direttamente nel cloud.
Otteniamo il seguente sistema:
Il modello di gestione DNS risultante consente di indirizzare i client in base alle osservazioni storiche della velocità delle connessioni dai client al cloud.
Ancora una volta, la domanda è: quanto sarà efficace questo approccio? Per rispondere, utilizziamo nuovamente il nostro sistema di sonda. Pertanto, configuriamo la configurazione del presentatore, dove uno degli obiettivi segue la direzione del DNS Steering, l'altro va direttamente al cloud (produzione attuale).
Di conseguenza, confrontiamo i risultati e otteniamo una valutazione dell’efficacia:
Di conseguenza, abbiamo imparato diverse cose importanti:
- Abbiamo valutato le prestazioni previste delle richieste dai client al cloud utilizzando DNS Steering.
- Abbiamo ricevuto dati da clienti reali, da tutti i tipi di dispositivi.
- L'efficacia dell'idea proposta è stata dimostrata.
- Non abbiamo corso rischi: non abbiamo modificato le configurazioni di produzione per i clienti.
- Niente era rotto.
Veniamo ora alla parte difficile: lo mettiamo in produzione
La parte facile è ormai finita: c'è un prototipo funzionante. Ora la parte difficile è lanciare una soluzione per tutto il traffico di Netflix, distribuendola a 150 milioni di utenti, migliaia di dispositivi, centinaia di microservizi e un prodotto e un'infrastruttura in continua evoluzione. I server Netflix ricevono milioni di richieste al secondo ed è facile interrompere il servizio con un'azione imprudente. Allo stesso tempo, vogliamo instradare dinamicamente il traffico attraverso migliaia di server CDN su Internet, dove qualcosa cambia e si rompe costantemente e nel momento più inopportuno.
E con tutto ciò, il team dispone di 3 ingegneri responsabili dello sviluppo, dell'implementazione e del pieno supporto del sistema.
Pertanto, continueremo a parlare di sonno riposante e sano.
Come continuare lo sviluppo e non dedicare tutto il tempo al supporto? Il nostro approccio si basa su 3 principi:
- Riduciamo la potenziale entità dei guasti (raggio dell'esplosione).
- Ci prepariamo alle sorprese: ci aspettiamo che qualcosa si rompa, nonostante i test e l'esperienza personale.
- Degradazione aggraziata: se qualcosa non funziona correttamente, dovrebbe essere risolto automaticamente, anche se non nel modo più efficiente.
Si è scoperto che nel nostro caso, con questo approccio al problema, possiamo trovare una soluzione semplice ed efficace e semplificare notevolmente il supporto del sistema. Ci siamo resi conto che avremmo potuto aggiungere una piccola porzione di codice al client e monitorare gli errori di richiesta di rete causati da problemi di connessione. In caso di errori di rete, effettuiamo un fallback direttamente nel cloud. Questa soluzione non richiede uno sforzo significativo per i team dei clienti, ma riduce notevolmente il rischio di guasti e sorprese impreviste per noi.
Naturalmente, nonostante il fallback, durante lo sviluppo seguiamo comunque una chiara disciplina:
- Test di esempio.
- Test A/B o Canarini.
- Lancio progressivo.
L'approccio è stato descritto con i campioni: le modifiche vengono prima testate utilizzando una ricetta personalizzata.
Per i test Canary, dobbiamo ottenere coppie di server comparabili su cui possiamo confrontare il funzionamento del sistema prima e dopo le modifiche. Per fare ciò, dai nostri numerosi siti CDN, selezioniamo coppie di server che ricevono traffico comparabile:
Quindi installiamo la build con le modifiche sul server Canary. Per valutare i risultati, eseguiamo un sistema che confronta circa 100-150 parametri con un campione di server di controllo:
Se il test Canary ha esito positivo, lo rilasceremo gradualmente, a ondate. Non aggiorniamo i server su ciascun sito contemporaneamente: la perdita di un intero sito a causa di problemi ha un impatto più significativo sul servizio per gli utenti rispetto alla perdita dello stesso numero di server in posizioni diverse.
In generale, l’efficacia e la sicurezza di questo approccio dipendono dalla quantità e dalla qualità delle metriche raccolte. Per il nostro sistema di accelerazione delle query, raccogliamo metriche da tutti i possibili componenti:
- dai clienti: numero di sessioni e richieste, tassi di fallback;
- proxy - statistiche sul numero e l'ora delle richieste;
- DNS: numero e risultati delle richieste;
- cloud edge: numero e tempo per l'elaborazione delle richieste nel cloud.
Tutto questo viene raccolto in un'unica pipeline e, a seconda delle esigenze, decidiamo quali metriche inviare agli analisti in tempo reale e quali a Elasticsearch o Big Data per una diagnostica più dettagliata.
Monitoriamo
Nel nostro caso, stiamo apportando modifiche al percorso critico delle richieste tra client e server. Allo stesso tempo, il numero dei diversi componenti sul client, sul server e nel percorso in Internet è enorme. I cambiamenti sul client e sul server si verificano costantemente, durante il lavoro di dozzine di team e cambiamenti naturali nell'ecosistema. Siamo nel mezzo: quando diagnostichiamo i problemi, ci sono buone probabilità che saremo coinvolti. Pertanto, dobbiamo capire chiaramente come definire, raccogliere e analizzare i parametri per isolare rapidamente i problemi.
Idealmente, accesso completo a tutti i tipi di metriche e filtri in tempo reale. Ma ci sono molti parametri, quindi sorge la questione dei costi. Nel nostro caso, separiamo le metriche e gli strumenti di sviluppo come segue:
Per rilevare e valutare i problemi utilizziamo il nostro sistema in tempo reale open source и - per la visualizzazione. Memorizza le metriche aggregate in memoria, è affidabile e si integra con il sistema di avviso. Per la localizzazione e la diagnostica, abbiamo accesso ai log di Elasticsearch e Kibana. Per l'analisi statistica e la modellazione, utilizziamo i big data e la visualizzazione in Tableau.
Sembra che sia molto difficile lavorare con questo approccio. Tuttavia, organizzando le metriche e gli strumenti in modo gerarchico, possiamo analizzare rapidamente un problema, determinare il tipo di problema e quindi approfondire le metriche dettagliate. In generale, impieghiamo circa 1-2 minuti per identificare la fonte del guasto. Successivamente lavoriamo con un team specifico sulla diagnostica, da decine di minuti a diverse ore.
Anche se la diagnosi viene fatta rapidamente, non vogliamo che ciò accada spesso. Idealmente, riceveremo un avviso critico solo quando si verifica un impatto significativo sul servizio. Per il nostro sistema di accelerazione delle query, abbiamo solo 2 avvisi che avviseranno:
- Percentuale di fallback del cliente: valutazione del comportamento del cliente;
- percentuale Errori sonda - dati di stabilità dei componenti di rete.
Questi avvisi critici monitorano se il sistema funziona per la maggior parte degli utenti. Osserviamo quanti client hanno utilizzato il fallback se non sono stati in grado di ottenere l'accelerazione delle richieste. In media riceviamo meno di 1 avviso critico a settimana, anche se nel sistema sono in corso moltissimi cambiamenti. Perché questo ci basta?
- Esiste un fallback del client se il nostro proxy non funziona.
- C'è un sistema di sterzo automatico che risponde ai problemi.
Maggiori dettagli su quest'ultimo. Il nostro sistema di prova e il sistema per determinare automaticamente il percorso ottimale per le richieste dal cliente al cloud ci consentono di affrontare automaticamente alcuni problemi.
Torniamo alla nostra configurazione di esempio e alle 3 categorie di percorso. Oltre al tempo di caricamento, possiamo considerare il fatto stesso della consegna. Se non è stato possibile caricare i dati, esaminando i risultati lungo percorsi diversi possiamo determinare dove e cosa si è rotto e se possiamo risolverlo automaticamente modificando il percorso della richiesta.
Esempi:
Questo processo può essere automatizzato. Includerlo nel sistema di sterzo. E insegnargli a rispondere ai problemi di prestazioni e affidabilità. Se qualcosa inizia a rompersi, reagisci se esiste un'opzione migliore. Allo stesso tempo, una reazione immediata non è fondamentale, grazie al fallback sui client.
Pertanto, i principi del supporto del sistema possono essere formulati come segue:
- ridurre l'entità dei guasti;
- raccolta di parametri;
- Se possibile, ripariamo automaticamente i guasti;
- se non è possibile, ti informiamo;
- Stiamo lavorando su dashboard e strumenti di triage per una risposta rapida.
Lezioni imparate
Non ci vuole molto tempo per scrivere un prototipo. Nel nostro caso era pronto dopo 4 mesi. Con esso abbiamo ricevuto nuove metriche e 10 mesi dopo l'inizio dello sviluppo abbiamo ricevuto il primo traffico di produzione. Poi è iniziato il lavoro noioso e molto difficile: produrre e scalare gradualmente il sistema, migrare il traffico principale e imparare dagli errori. Tuttavia, questo processo efficace non sarà lineare: nonostante tutti gli sforzi, non è possibile prevedere tutto. È molto più efficace eseguire l'iterazione e rispondere rapidamente ai nuovi dati.
In base alla nostra esperienza possiamo consigliarvi quanto segue:
- Non fidarti del tuo intuito.
La nostra intuizione ci deludeva costantemente, nonostante la vasta esperienza dei membri del nostro team. Ad esempio, abbiamo previsto erroneamente l'aumento di velocità previsto dall'utilizzo di un proxy CDN o il comportamento di TCP Anycast.
- Ottieni dati dalla produzione.
È importante avere accesso almeno ad una piccola quantità di dati di produzione il più rapidamente possibile. È quasi impossibile ottenere il numero di casi, configurazioni e impostazioni unici in condizioni di laboratorio. L'accesso rapido ai risultati ti consentirà di conoscere rapidamente potenziali problemi e di tenerne conto nell'architettura del sistema.
- Non seguire i consigli e i risultati di altre persone: raccogli i tuoi dati.
Segui i principi per la raccolta e l'analisi dei dati, ma non accettare ciecamente i risultati e le dichiarazioni di altre persone. Solo tu puoi sapere esattamente cosa funziona per i tuoi utenti. I tuoi sistemi e i tuoi clienti potrebbero essere significativamente diversi da quelli di altre aziende. Fortunatamente, gli strumenti di analisi sono ora disponibili e facili da usare. I risultati ottenuti potrebbero non essere quelli dichiarati da Netflix, Facebook, Akamai e altre società. Nel nostro caso, le prestazioni di TLS, HTTP2 o le statistiche sulle richieste DNS differiscono dai risultati di Facebook, Uber, Akamai, perché abbiamo dispositivi, client e flussi di dati diversi.
- Non seguire inutilmente le tendenze della moda e valutarne l'efficacia.
Inizia in modo semplice. È meglio realizzare un sistema funzionante semplice in breve tempo piuttosto che dedicare un'enorme quantità di tempo allo sviluppo di componenti di cui non si ha bisogno. Risolvi attività e problemi importanti in base alle misurazioni e ai risultati.
- Preparati per nuove applicazioni.
Così come è difficile prevedere tutti i problemi, è difficile prevederne in anticipo i benefici e le applicazioni. Prendi spunto dalle startup: la loro capacità di adattarsi alle condizioni dei clienti. Nel tuo caso, potresti scoprire nuovi problemi e le loro soluzioni. Nel nostro progetto, ci siamo posti l'obiettivo di ridurre la latenza delle richieste. Tuttavia, durante l'analisi e le discussioni, ci siamo resi conto che possiamo utilizzare anche i server proxy:
- bilanciare il traffico tra le regioni AWS e ridurre i costi;
- modellare la stabilità della CDN;
- configurare DNS;
- per configurare TLS/TCP.
conclusione
Nel rapporto ho descritto come Netflix risolve il problema dell'accelerazione delle richieste Internet tra i client e il cloud. Come raccogliamo i dati utilizzando un sistema di campionamento sui clienti e utilizziamo i dati storici raccolti per instradare le richieste di produzione dai clienti attraverso il percorso più veloce su Internet. Come utilizziamo i principi dei protocolli di rete, della nostra infrastruttura CDN, della rete backbone e dei server DNS per raggiungere questo obiettivo.
Tuttavia, la nostra soluzione è solo un esempio di come noi di Netflix abbiamo implementato un sistema del genere. Cosa ha funzionato per noi. La parte applicata del mio rapporto per voi riguarda i principi di sviluppo e supporto che seguiamo e otteniamo buoni risultati.
La nostra soluzione al problema potrebbe non essere adatta a te. Tuttavia, la teoria e i principi di progettazione rimangono, anche se non si dispone di una propria infrastruttura CDN o se differisce in modo significativo dalla nostra.
Resta importante anche l’importanza della velocità delle richieste aziendali. E anche per un servizio semplice è necessario fare una scelta: tra provider cloud, ubicazione del server, provider CDN e DNS. La tua scelta influenzerà l'efficacia delle query Internet per i tuoi clienti. Ed è importante per te misurare e comprendere questa influenza.
Inizia con soluzioni semplici, presta attenzione a come cambi il prodotto. Impara mentre procedi e migliora il sistema in base ai dati dei tuoi clienti, della tua infrastruttura e della tua azienda. Pensa alla possibilità di guasti imprevisti durante il processo di progettazione. E poi potrai accelerare il processo di sviluppo, migliorare l'efficienza della soluzione, evitare inutili oneri di supporto e dormire sonni tranquilli.
Quest'anno in formato online. Puoi porre domande a uno dei padri di DevOps, John Willis in persona!
Fonte: habr.com