Netflix è il leader del mercato della televisione via internet e ha creato e sviluppa attivamente questo segmento. Netflix è conosciuto non solo per il suo ampio catalogo di film e serie disponibili da quasi ogni angolo del pianeta e da qualsiasi dispositivo con schermo, 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 da — direttore dello sviluppo in Netflix. Laureato presso il dipartimento di VMC dell'Università NNGU di Lobachevskij, Sergej è uno dei primi ingegneri nel team Open Connect — CDN di Netflix. Ha creato sistemi di monitoraggio e analisi dei dati video, ha lanciato il popolare servizio per valutare la velocità della connessione a Internet FAST.com e negli ultimi anni ha lavorato all'ottimizzazione delle richieste Internet affinché l'app di Netflix funzionasse il più velocemente possibile per gli utenti.
La presentazione ha ricevuto il migliore feedback dai partecipanti alla conferenza e abbiamo preparato per voi la versione testuale.
Nella sua presentazione, Sergej ha parlato in dettaglio
- di cosa influisce sulla latenza delle richieste Internet tra il client e il server;
- di come ridurre questa latenza;
- come progettare, mantenere e monitorare sistemi resistenti agli errori;
- come raggiungere risultati in tempi brevi e con il minimo rischio per il business;
- come analizzare i risultati e imparare dagli errori.
Le risposte a queste domande servono non solo a chi lavora in grandi aziende.
I principi e le tecniche presentati dovrebbero essere conosciuti e praticati da chiunque sviluppi e mantenga prodotti online.
Di seguito — un racconto dal punto di vista del relatore.
L'importanza della velocità di internet
La velocità delle richieste internet è direttamente correlata al business. Prendiamo in considerazione il settore dello shopping: nel 2009, l'azienda Amazon , che un ritardo di 100 ms comporta una perdita dell'1% delle vendite.
Sempre più dispositivi mobili stanno emergendo, seguito da siti e applicazioni mobili. Se la tua pagina impiega più di 3 secondi a caricarsi, perdi circa la metà degli utenti. A partire dal , Google tiene conto della velocità di caricamento della tua pagina nel ranking dei risultati di ricerca: più veloce è la pagina, migliore sarà la sua posizione su Google.
Anche la velocità di connessione è importante nelle istituzioni finanziarie, dove il ritardo è critico. Nel 2015, Hibernia Networks una connessione in fibra tra New York e Londra costata 400 milioni di dollari, per ridurre il ritardo tra le due città di 6 ms. Immagina, 66 milioni di dollari per 1 ms di riduzione del ritardo!
Secondo , la velocità di connessione superiore a 5 Mbps smette di influenzare direttamente la velocità di caricamento di un sito web tipico. Tuttavia, esiste una relazione lineare tra il ritardo della connessione e la velocità di caricamento della pagina:
Tuttavia, Netflix non è un prodotto tipico. L'impatto del ritardo e della velocità sull'utente è un'area attiva di analisi e sviluppo. Ci sono il caricamento delle applicazioni e la scelta dei contenuti che dipendono dal ritardo, ma anche il caricamento degli elementi statici e lo streaming dipendono dalla velocità di connessione. L'analisi e l'ottimizzazione dei fattori chiave che influenzano la qualità del servizio per l'utente è un'area di sviluppo attiva di diversi team in Netflix. Uno degli obiettivi è ridurre il ritardo delle richieste tra i dispositivi Netflix e l'infrastruttura cloud.
Nel rapporto ci concentreremo sulla riduzione della latenza utilizzando l'infrastruttura di Netflix come esempio. Esamineremo dal punto di vista pratico come affrontare i processi di progettazione, sviluppo e gestione di sistemi distribuiti complessi, investendo tempo in innovazione e risultati piuttosto che nella diagnosi di problemi operativi e guasti.
All'interno di Netflix
Migliaia di dispositivi diversi supportano le app Netflix. Il loro sviluppo è gestito da quattro team distinti, ognuno dei quali crea versioni separate del client per Android, iOS, TV e browser web. Investiamo molte risorse per migliorare e personalizzare l'interfaccia utente. A tal fine, lanciamo centinaia di test A/B contemporaneamente.
La personalizzazione è supportata da centinaia di microservizi nel cloud AWS, che forniscono dati personalizzati per l'utente, gestiscono le richieste, la telemetria, Big Data e Encoding. La visualizzazione del traffico appare così:
A sinistra c'è il punto di ingresso, dopo di che il traffico viene distribuito tra diverse centinaia di microservizi, sostenuti da vari team di backend.
Un altro componente importante della nostra infrastruttura è il Open Connect CDN, che fornisce contenuti statici agli utenti finali — video, immagini, codice per i clienti, ecc. Il CDN si trova su server personalizzati (OCA — Open Connect Appliance). Al suo interno ci sono array di dischi SSD e HDD gestiti con FreeBSD ottimizzato, insieme a NGINX e una serie di servizi. Progettiamo e ottimizziamo i componenti hardware e software in modo che il server CDN possa inviare il maggior numero possibile di dati agli utenti.
La "muraglia" di questi server presso il punto di scambio del traffico internet (Internet eXchange — IX) appare così:
L'Internet Exchange offre ai fornitori di servizi internet e ai fornitori di contenuti la possibilità di "collegarsi" tra loro per uno scambio di dati più diretto su internet. In tutto il mondo ci sono circa 70-80 punti di Internet Exchange dove sono installati i nostri server, e ci occupiamo autonomamente della loro installazione e manutenzione:
Inoltre, forniamo anche server direttamente ai fornitori di servizi internet, che li installano nella loro rete, migliorando la localizzazione del traffico Netflix e la qualità dello streaming per gli utenti:
Il set di servizi AWS è responsabile della gestione delle richieste video dei clienti verso i server CDN, oltre alla configurazione stessa dei server, come aggiornamenti di contenuti, codice e impostazioni, ecc. Per questo abbiamo anche costruito una backbone network che collega i server nei punti di Internet Exchange con AWS. La backbone network consiste in una rete globale di cavi in fibra ottica e router che possiamo progettare e configurare in base alle nostre esigenze.
Secondo , la nostra infrastruttura CDN gestisce nelle ore di punta circa ⅛ del traffico internet mondiale e ⅓ del traffico in Nord America, dove Netflix è attiva da più tempo. Numeri impressionanti, ma per me uno dei successi più sorprendenti è che l'intero sistema CDN è sviluppato e gestito da un team di meno di 150 persone.
Inizialmente, l'infrastruttura CDN è stata progettata per la consegna di dati video. Tuttavia, nel tempo abbiamo realizzato che potevamo utilizzarla anche per ottimizzare le richieste dinamiche dei clienti nel cloud AWS.
Sull'accelerazione di Internet
Oggi Netflix ha 3 regioni AWS, e la latenza delle richieste nel cloud dipenderà da quanto è lontano il cliente dalla regione più vicina. Abbiamo anche molti server CDN che vengono utilizzati per consegnare contenuti statici. È possibile utilizzare questa infrastruttura per accelerare le richieste dinamiche? Purtroppo non è possibile memorizzare nella cache queste richieste, poiché le API sono personalizzate e ogni risultato è unico.
Facciamo un proxy su un server CDN e iniziamo a instradare il traffico attraverso di esso. Sarà più veloce?
Materiale
Ricordiamo come funzionano i protocolli di rete. Oggi la maggior parte del traffico su Internet utilizza HTTPS, che dipende dai protocolli a livello inferiore TCP e TLS. Per connettersi a un server, il client esegue un handshake e, per stabilire una connessione sicura, deve scambiare messaggi con il server tre volte e almeno un'altra volta per trasferire i dati. Con una latenza di un scambio (RTT) di 100 ms, ci vorranno 400 ms per ricevere il primo bit di dati:
Se posizioniamo i certificati su un server CDN, possiamo ridurre significativamente il tempo di «handshake» tra il client e il server, se il CDN è più vicino. Supponiamo che la latenza verso il server CDN sia di 30 ms. Allora, per ricevere il primo bit, saranno necessari già 220 ms:
Ma i vantaggi non finiscono qui. Dopo che la connessione è stata stabilita, TCP aumenta la congestion window (la quantità di informazioni che può trasmettere su questa connessione in parallelo). Se un pacchetto di dati viene perso, le implementazioni classiche del protocollo TCP (come TCP New Reno) riducono a metà la «finestra» aperta. L'aumento della congestion window e la velocità di ripristino dalla perdita dipendono nuovamente dalla latenza (RTT) verso il server. Se questa connessione va solo al server CDN, il ripristino sarà più rapido. Inoltre, la perdita di pacchetti è un fenomeno standard, specialmente per le reti wireless.
La capacità di internet può diminuire, specialmente durante le ore di punta a causa del traffico degli utenti, il che può portare a "ingorghi". Non esiste un modo per dare priorità a alcune richieste rispetto ad altre. Ad esempio, non è possibile dare precedenza a richieste di piccole dimensioni e sensibili ai ritardi rispetto a flussi di dati "pesanti" che sovraccaricano la rete. Tuttavia, nel nostro caso, avere una rete backbone propria ci consente di farlo in parte lungo il percorso della richiesta — tra il CDN e il cloud, e possiamo configurarla completamente. Possiamo fare in modo che pacchetti piccoli e sensibili ai ritardi vengano prioritizzati, mentre flussi di dati più grandi vengano processati leggermente dopo. Maggiore è la vicinanza del CDN al cliente, maggiore è l'efficacia.
Anche i protocolli di livello applicazione (OSI Livello 7) influenzano ulteriormente la latenza. Nuovi protocolli, come HTTP/2, consentono di ottimizzare le prestazioni delle richieste parallele. Tuttavia, Netflix ha clienti con dispositivi datati che non supportano i nuovi protocolli. Non tutti i clienti possono essere aggiornati o ottimizzati. Allo stesso tempo, tra il proxy CDN e il cloud, abbiamo il pieno controllo e la possibilità di utilizzare protocolli e configurazioni nuovi e ottimali. La parte inefficiente con i vecchi protocolli si attiverà solo tra il cliente e il server CDN. Inoltre, possiamo multiplexare le richieste su una connessione già stabilita tra il CDN e il cloud, migliorando l'utilizzo della connessione a livello TCP:
Misuriamo
Nonostante la teoria prometta miglioramenti, non lanciamo subito il sistema in produzione. Invece, dobbiamo prima dimostrare che l'idea funzionerà nella pratica. Per questo è necessario rispondere a diverse domande:
- Velocità: il proxy sarà più veloce?
- Affidabilità: darà più spesso problemi?
- Complesso: come integrare con le applicazioni?
- Costo: quanto costa implementare un'infrastruttura aggiuntiva?
Esaminiamo in dettaglio il nostro approccio alla valutazione del primo punto. Gli altri vengono analizzati in modo simile.
Per analizzare la velocità delle richieste, vogliamo ottenere dati per tutti gli utenti, senza spendere troppo tempo nello sviluppo e senza compromettere la produzione. A questo scopo, ci sono diversi approcci:
- RUM, o misurazione passiva delle richieste. Misuriamo il tempo di esecuzione delle richieste attuali degli utenti e garantiamo una copertura totale degli utenti. Lo svantaggio è che il segnale non è molto stabile a causa di diversi fattori, ad esempio, a causa delle dimensioni diverse delle richieste, del tempo di elaborazione sul server e sul client. Inoltre, non è possibile testare una nuova configurazione senza effetti sulla produzione.
- Test di laboratorio. Server e infrastrutture speciali che simulano i clienti. Con questi conduciamo i test necessari. Così otteniamo il pieno controllo sui risultati delle misurazioni e un segnale chiaro. Tuttavia, non c'è una copertura completa dei dispositivi e delle posizioni degli utenti (soprattutto con un servizio globale e il supporto per migliaia di modelli di dispositivi).
Come si possono combinare i vantaggi di entrambi i metodi?
Il nostro team ha trovato una soluzione. Abbiamo scritto un piccolo codice — una prova — che abbiamo integrato nella nostra applicazione. Le prove ci consentono di effettuare test di rete completamente controllati dai nostri dispositivi. Funziona in questo modo:
- Poco dopo aver caricato l'applicazione e completato l'attività iniziale, avviamo le nostre prove.
- Il cliente invia una richiesta al server e riceve una "ricetta" per il test. La ricetta è un elenco di URL a cui devono essere effettuate richieste HTTP(s). Inoltre, la ricetta configura i parametri delle richieste: ritardi tra le richieste, volume dei dati richiesti, intestazioni HTTP(s), ecc. Possiamo anche testare contemporaneamente diverse ricette — quando si richiede la configurazione, verrà scelto casualmente quale ricetta fornire.
- Il tempo di avvio delle prove viene scelto in modo da non interferire con l'uso attivo delle risorse di rete del cliente. In sostanza, viene scelto un momento in cui il cliente non è attivo.
- Dopo aver ricevuto la prescrizione, il cliente invia richieste a ciascuno degli URL in parallelo. La richiesta a ciascun indirizzo può essere ripetuta, ovvero i cosiddetti "pulse". Nel primo pulse misuriamo quanto tempo è necessario per stabilire la connessione e caricare i dati. Nel secondo pulse misuriamo il tempo di caricamento dei dati attraverso la connessione già stabilita. Prima del terzo, possiamo impostare un ritardo e misurare la velocità di stabilimento della riconnessione, ecc.
Durante il test, misuriamo tutti i parametri che il dispositivo può ottenere:
- tempo di richiesta DNS;
- tempo di stabilimento della connessione TCP;
- tempo di stabilimento della connessione TLS;
- tempo di ricezione del primo byte di dati;
- tempo totale di caricamento;
- codice di stato del risultato.
- Al termine di tutti i pulse, il campione carica i risultati di tutte le misurazioni per l'analisi.
I punti chiave sono la minima dipendenza dalla logica lato client, l'elaborazione dei dati sul server e la misurazione delle richieste parallele. In questo modo, abbiamo la possibilità di isolare e testare l'impatto di diversi fattori che influenzano le prestazioni delle richieste, variandoli all'interno di una singola ricetta e ottenendo risultati da clienti reali.
Questa infrastruttura si è rivelata utile non solo per analizzare le prestazioni delle richieste. Attualmente abbiamo 14 ricette attive, oltre 6000 campioni al secondo, che ricevono dati da ogni angolo della terra e coprendo tutti i dispositivi. Se Netflix dovesse acquistare un servizio simile da aziende esterne, costerebbe milioni di dollari all'anno, con una copertura molto peggiore.
Mettiamo alla prova la teoria: prototipo
Con un sistema del genere abbiamo potuto valutare l'efficacia del proxy CDN sulla latenza delle richieste. Ora è necessario:
- creare un prototipo di proxy;
- ospitare il prototipo su un CDN;
- determinare come indirizzare i clienti al proxy su un server CDN specifico;
- confrontare le prestazioni con le richieste su AWS senza proxy.
L'obiettivo è valutare nel minor tempo possibile l'efficacia della soluzione proposta. Per realizzare il prototipo abbiamo scelto Go, grazie alla sua eccellente libreria per reti. Su ogni server CDN abbiamo installato il prototipo di proxy come binary statico, per minimizzare le dipendenze e semplificare l'integrazione. Nella realizzazione iniziale abbiamo sfruttato al massimo i componenti standard e apportato piccole modifiche per il connection pooling HTTP/2 e il request multiplexing.
Per l'equilibrio tra le regioni AWS abbiamo utilizzato un database DNS geografico, lo stesso utilizzato per il bilanciamento dei client. Per selezionare il server CDN per il cliente utilizziamo TCP Anycast per i server nell'Internet Exchange (IX). In questa configurazione utilizziamo un solo indirizzo IP per tutti i server CDN, indirizzando il cliente verso il server CDN con il minor numero di IP hops. Nei server CDN installati presso i fornitori di servizi Internet (ISP) non abbiamo il controllo sul router per configurare TCP Anycast, quindi adoptiamo , secondo la quale i clienti sono indirizzati ai fornitori di servizi Internet per lo streaming video.
Quindi, abbiamo tre tipi di percorsi per la richiesta: nel cloud attraverso Internet aperto, attraverso un server CDN in IX o attraverso un server CDN situato presso il fornitore di servizi Internet. Il nostro obiettivo è capire quale percorso sia migliore e quale vantaggio porti un proxy, rispetto al modo in cui le richieste vengono indirizzate in produzione. Per questo utilizziamo un sistema di prove nel seguente modo:
Ciascuno di questi percorsi diventa un target separato, e osserviamo il tempo che siamo riusciti a ottenere. Per l'analisi, raggruppiamo i risultati proxy in un unico gruppo (selezionando il miglior tempo tra il proxy IX e quello ISP) e lo confrontiamo con il tempo delle richieste nel cloud senza proxy:
Come si può vedere, i risultati sono stati ambivalenti: nella maggior parte dei casi, il proxy offre un buon aumento della velocità, ma ci sono anche un numero sufficiente di clienti per i quali la situazione peggiorerebbe significativamente.
Alla fine, abbiamo fatto alcune cose importanti:
- Abbiamo valutato le prestazioni attese delle richieste dei clienti verso il cloud tramite il proxy CDN.
- Abbiamo ottenuto dati da veri clienti, provenienti da tutti i tipi di dispositivi.
- Abbiamo capito che la teoria non si è confermata al 100% e che l'offerta iniziale con il proxy CDN non funzionerà per noi.
- Non abbiamo rischiato — non abbiamo modificato la configurazione di produzione per i clienti.
- Non abbiamo rotto nulla.
Prototipo 2.0
Quindi torniamo alla lavagna e ripetiamo il processo da capo.
L'idea è che, invece di utilizzare un proxy al 100%, per ogni cliente definiamo il percorso più veloce e indirizziamo le richieste lì — in altre parole, faremo ciò che viene chiamato client steering.
Come realizzare questo? Non possiamo utilizzare la logica sul lato server, poiché l'obiettivo è connettersi a quel server. Dobbiamo in qualche modo fare questo lato client. E idealmente, farlo con la minima quantità di logica complessa, in modo da non dover affrontare l'integrazione con un vasto numero di piattaforme client.
La risposta è l'uso del DNS. Nel nostro caso abbiamo una nostra infrastruttura DNS e possiamo configurare la zona di dominio per la quale i nostri server saranno autoritativi. Funziona così:
- Il cliente invia una richiesta al server DNS utilizzando l'host, ad esempio api.netflix.xom.
- La richiesta arriva al nostro server DNS
- Il server DNS sa qual è il percorso più veloce per questo cliente e restituisce l'indirizzo IP corrispondente.
C'è una complicazione aggiuntiva nella soluzione: i fornitori di DNS autoritativi non vedono l'indirizzo IP del cliente e possono considerare solo l'indirizzo IP del resolver ricorsivo utilizzato dal cliente.
Di conseguenza, il nostro resolver autoritativo deve prendere decisioni non per un singolo cliente, ma per un gruppo di clienti basato sul resolver ricorsivo.
Per risolvere il problema, utilizziamo gli stessi campioni, aggregando i risultati delle misurazioni dai clienti per ciascun resolver ricorsivo e decidiamo dove reindirizzare questo gruppo: tramite proxy IX utilizzando TCP Anycast, tramite proxy ISP o direttamente nel cloud.
Otteniamo un sistema del genere:
Il modello DNS steering ottenuto consente di indirizzare i clienti in base alle osservazioni storiche sulla velocità delle connessioni dai clienti al cloud.
Ancora una volta, ci chiediamo: quanto sarà efficace questo approccio? Per rispondere, utilizziamo nuovamente il nostro sistema di campionamento. Quindi configuriamo la configurazione di recente, in cui uno degli obiettivi segue la direzione del DNS steering, mentre l'altro va direttamente nel cloud (produzione attuale).
Alla fine, confrontiamo i risultati e otteniamo una valutazione dell'efficacia:
Di conseguenza, abbiamo appreso alcune cose importanti:
- Abbiamo valutato le aspettative di prestazione delle richieste dei clienti verso il cloud utilizzando DNS Steering.
- Abbiamo ottenuto dati da veri clienti, provenienti da tutti i tipi di dispositivi.
- Abbiamo dimostrato l’efficacia dell'idea proposta.
- Non abbiamo rischiato — non abbiamo modificato la configurazione di produzione per i clienti.
- Non abbiamo rotto nulla.
Ora passiamo al difficile: lanciamo in produzione.
La parte più semplice è ormai alle spalle: abbiamo un prototipo funzionante. Ora la parte complicata è lanciare la soluzione per tutto il traffico di Netflix, distribuendola a 150 milioni di utenti, migliaia di dispositivi, centinaia di microservizi e una continua evoluzione di prodotto e infrastruttura. I server di Netflix ricevono milioni di richieste al secondo, e un'azione imprudente può facilmente compromettere il servizio. Vogliamo, nel contempo, indirizzare dinamicamente il traffico attraverso migliaia di server CDN, in un ambiente dove le condizioni cambiano e si rompono continuamente, soprattutto nei momenti meno opportuni.
E in tutto questo, nel team ci sono 3 ingegneri responsabili dello sviluppo, del deployment e del completo supporto del sistema.
Pertanto, parleremo ora di un sonno tranquillo e sano.
Come continuare a sviluppare, senza spendere tutto il tempo nel supporto? Alla base del nostro approccio ci sono 3 principi:
- Riduciamo il potenziale impatto dei guasti (blast radius).
- Prepariamoci alle sorprese: ci aspettiamo che qualcosa si rompa, nonostante i test e l'esperienza personale.
- Degradazione graduale (graceful degradation): se qualcosa non funziona come dovrebbe, deve ripararsi automaticamente, anche se non nel modo più efficiente.
Ci siamo resi conto che nel nostro caso, con questo approccio al problema, è possibile trovare una soluzione semplice ed efficace e semplificare notevolmente la manutenzione del sistema. Abbiamo capito che possiamo aggiungere un piccolo pezzo di codice al cliente per monitorare gli errori delle richieste di rete causati da problemi di connessione. In caso di errori di rete, facciamo un fallback direttamente nel cloud. Questa soluzione non richiede sforzi significativi per i team clienti, ma riduce notevolmente il rischio di guasti non previsti e sorprese per noi.
Naturalmente, nonostante il fallback, seguiamo comunque una rigorosa disciplina nello sviluppo:
- Test su campioni.
- Test A/B o Canarie.
- Rilascio graduale (progressive rollout).
Con i campioni, l'approccio è stato descritto: le modifiche vengono prima testate utilizzando una ricetta configurata.
Per il test canary abbiamo bisogno di ottenere coppie di server comparabili sui quali confrontare come funziona il sistema prima e dopo le modifiche. A tal fine, selezioniamo coppie di server dai nostri numerosi siti CDN che ricevono un traffico comparabile:
Successivamente, implementiamo la build con le modifiche sui server Canary. Per valutare i risultati, avviamo un sistema che confronta circa 100-150 metriche con un campione di server di controllo:
Se il test canary ha successo, rilasciamo gradualmente, a ondate. Su ciascuno dei siti non aggiorniamo i server contemporaneamente: la perdita di un intero sito in caso di problemi ha un impatto più significativo sul servizio per gli utenti rispetto alla perdita dello stesso numero di server, ma in luoghi diversi.
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 richieste, raccogliamo metriche da tutti i componenti possibili:
- dai client — numero di sessioni e richieste, tassi di fallback;
- proxy — statistiche sul numero e sui tempi delle richieste;
- DNS — numero e risultati delle richieste;
- cloud edge — numero e tempo di elaborazione delle richieste nel cloud.
Tutto ciò viene raccolto in un'unica pipeline e, a seconda delle esigenze, decidiamo quali metriche inviare all'analisi in tempo reale e quali a Elasticsearch o Big Data per una diagnosi più dettagliata.
Monitoriamo
Nel nostro caso apportiamo modifiche nel percorso critico delle richieste tra client e server. Nel frattempo, il numero di componenti diversi sul client, sul server e lungo il percorso attraverso Internet è enorme. Le modifiche al client e al server avvengono continuamente, a seguito dell'operato di decine di team e dei cambiamenti naturali nell'ecosistema. Siamo a metà strada: durante la diagnosi dei problemi è probabile che siamo coinvolti. Pertanto, dobbiamo avere una chiara comprensione di come definire, raccogliere e analizzare le metriche per una rapida localizzazione dei problemi.
Idealmente, accesso completo a tutti i tipi di metriche e filtri in tempo reale. Ma ci sono molte metriche, quindi si pone la questione dei costi. Nel nostro caso, separiamo metriche e strumenti di sviluppo nel seguente modo:
Per rilevare e classificare i problemi utilizziamo il nostro sistema di analisi in tempo reale con codice sorgente aperto. e — per la visualizzazione. Essa conserva metriche aggregate in memoria, è affidabile e si integra con il sistema di allerta. Per la localizzazione e la diagnostica, abbiamo accesso ai log con Elasticsearch e Kibana. Per l'analisi statistica e la modellazione, utilizziamo big data e visualizzazione in Tableau.
Sembra che con questo approccio sia molto difficile lavorare. Tuttavia, con un'organizzazione gerarchica delle metriche e degli strumenti, possiamo analizzare rapidamente il problema, identificare il tipo di problema e poi — approfondire le metriche dettagliate. Per identificare la fonte del malfunzionamento, in media impieghiamo circa 1-2 minuti. Dopo ciò, lavoriamo già con il team specifico sulla diagnosi — da decine di minuti a diverse ore.
Anche se la diagnosi avviene rapidamente, non desideriamo che accada frequentemente. Idealmente, riceveremo un avviso critico solo quando c'è un impatto significativo sul servizio. Per il nostro sistema di accelerazione delle richieste, abbiamo solo 2 avvisi che notificheranno:
- percentuale Client Fallback — valutazione del comportamento dei clienti;
- percentuale Probe errors — dati sulla stabilità dei componenti di rete.
Questi avvisi critici monitorano se il sistema funziona per la maggior parte degli utenti. Osserviamo quante volte i clienti hanno utilizzato il fallback quando non sono riusciti a ottenere un miglioramento delle richieste. In media ricevono meno di 1 avviso critico a settimana, nonostante il numero elevato di cambiamenti nel sistema. Perché ci basta questo?
- C'è un fallback per i clienti nel caso in cui la nostra proxy non funzioni.
- Esiste un sistema di steering automatico che risponde ai problemi.
Parlando dell'ultimo punto. Il nostro sistema di probe e il sistema di identificazione automatica del percorso ottimale per le richieste del cliente verso il cloud ci permettono di gestire automaticamente alcuni problemi.
Torniamo alla nostra configurazione di probe e ai 3 tipi di percorsi. Oltre al tempo di caricamento, possiamo anche monitorare il semplice fatto della consegna. Se un caricamento non riesce, analizzando i risultati attraverso 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. Integrare nel sistema di steering. E insegnare a reagire a problemi di prestazioni e affidabilità. Se qualcosa inizia a guastarsi, reagire, se c'è un'opzione migliore. In questo caso, la reazione istantanea non è critica, grazie al fallback sui clienti.
Pertanto, i principi di supporto del sistema possono essere formulati così:
- ridurre l'impatto dei guasti;
- raccogliere metriche;
- riparare i guasti automaticamente, se possibile;
- se non è possibile, avvisare;
- lavorare su dashboards e toolset di triage per una reazione rapida.
Lezioni apprese
Per scrivere un prototipo non serve molto tempo. Nel nostro caso, era pronto già dopo 4 mesi. Con esso abbiamo ottenuto nuove metriche, e dopo 10 mesi dall'inizio dello sviluppo abbiamo ricevuto il primo traffico in produzione. Poi è iniziato un lavoro noioso e molto complesso: produrre e scalare il sistema gradualmente, migrare il traffico principale e imparare dagli errori. Inoltre, questo processo efficace non sarà lineare: nonostante tutti gli sforzi, non si può prevedere tutto. È molto più efficace iterare rapidamente e rispondere ai nuovi dati.
Basandoci sulla nostra esperienza, possiamo consigliare quanto segue:
- Non fidatevi dell'intuizione.
La nostra intuizione ci ha spesso ingannato, nonostante l'enorme esperienza dei membri del team. Ad esempio, abbiamo erroneamente previsto l'accelerazione attesa dall'uso di CDN proxy, o il comportamento di TCP Anycast.
- Ottieni dati dalla produzione.
È importante accedere il prima possibile a almeno un piccolo insieme di dati di produzione. Il numero di casi unici, configurazioni e impostazioni che si possono ottenere in condizioni di laboratorio è praticamente impossibile. Un rapido accesso ai risultati permetterà di conoscere prima le potenziali problematiche e di tenerle in considerazione nell'architettura del sistema.
- Non seguire i consigli e i risultati altrui: raccogli i tuoi dati.
Segui i principi di raccolta e analisi dei dati, ma non accettare ciecamente i risultati e le affermazioni altrui. Solo tu puoi sapere con certezza cosa funziona per i tuoi utenti. I tuoi sistemi e i tuoi clienti possono differire notevolmente da quelli di altre aziende. Fortunatamente, gli strumenti di analisi sono ora disponibili e facili da usare. I risultati che ottieni potrebbero non corrispondere a ciò che affermano Netflix, Facebook, Akamai e altre aziende. Nel nostro caso, le prestazioni TLS, HTTP2 o le statistiche sui DNS differiscono dai risultati di Facebook, Uber, Akamai — poiché abbiamo dispositivi, clienti e flussi di dati diversi.
- Non inseguire le mode senza necessità e senza una valutazione dell'efficacia.
Inizia con qualcosa di semplice. È meglio creare un sistema funzionante e semplice in poco tempo, piuttosto che spendere un'enorme quantità di tempo nello sviluppo di componenti inutili. Risolvi compiti e problemi che sono importanti in base alle tue misurazioni e ai tuoi risultati.
- Sii pronto a nuove applicazioni.
Proprio come è difficile prevedere tutti i problemi, è altrettanto complesso anticipare i vantaggi e le applicazioni. Prendete esempio dalle startup: la loro capacità di adattarsi alle esigenze dei clienti. Nel vostro caso, potreste 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, abbiamo realizzato che possiamo anche applicare i server proxy:
- per bilanciare il traffico tra le regioni AWS e ridurre i costi;
- per modellare la stabilità del CDN;
- per configurare il DNS;
- per configurare TLS/TCP.
Conclusione
Nella relazione, ho descritto come Netflix affronta il problema di accelerare le richieste Internet tra clienti e cloud. Come raccogliamo dati tramite un sistema di campionamento sui clienti e utilizziamo i dati storici raccolti per indirizzare le richieste di produzione dai clienti attraverso il percorso più veloce su Internet. Come utilizziamo i principi di funzionamento dei protocolli di rete, la nostra infrastruttura CDN, la rete backbone e i server DNS per raggiungere questo obiettivo.
Tuttavia, la nostra soluzione è solo un esempio di come abbiamo implementato un sistema simile in Netflix. Ciò che ha funzionato per noi. La parte applicativa della mia relazione per voi sono i principi di sviluppo e supporto che seguiamo e che ci portano a ottenere buoni risultati.
La nostra soluzione ai problemi potrebbe non adattarsi a voi. Tuttavia, la teoria e i principi di sviluppo rimangono, anche se non avete una vostra infrastruttura CDN, o se è significativamente diversa dalla nostra.
Rimane anche l'importanza della velocità delle richieste per il business. E anche per un servizio semplice, è necessario fare una scelta: tra fornitori 'cloud', posizione dei server, fornitori di CDN e DNS. La vostra scelta influenzerà l'efficacia delle richieste internet per i vostri clienti. È importante per voi misurare e comprendere questa influenza.
Iniziate con soluzioni semplici, preoccupatevi di come modificate il prodotto. Imparate lungo il percorso e migliorate il sistema basandovi sui dati dei vostri clienti, della vostra infrastruttura e della vostra attività. Pensate alla possibilità di guasti inaspettati durante la progettazione. In questo modo, potrete accelerare il vostro processo di sviluppo, migliorare l'efficienza delle soluzioni, evitare un carico eccessivo sul supporto e dormire serenamente.
Quest'anno in formato online. Sarà possibile porre domande a uno dei padri del DevOps, il grande John Willis!
Fonte: habr.com
