Netflix è il leader del mercato della televisione su internet, un'azienda che ha creato e sviluppa attivamente questo segmento. Netflix è conosciuto non solo per il suo ampio catalogo di film e serie disponibili praticamente da ogni angolo del pianeta e su qualsiasi dispositivo con schermo, ma anche per la sua infrastruttura affidabile e la sua cultura ingegneristica unica.
Un chiaro esempio dell'approccio di Netflix allo sviluppo e al supporto di sistemi complessi è stato presentato — direttore dello sviluppo in Netflix. Laureato nella facoltà di VMC dell'Università di N.N. Lobacëvski, Serghiei è uno dei primi ingegneri di Open Connect, il team CDN di Netflix. Ha costruito sistemi di monitoraggio e analisi dei dati video, ha lanciato il popolare servizio di valutazione della velocità della connessione Internet FAST.com e negli ultimi anni si è concentrato sull'ottimizzazione delle richieste Internet per garantire che l'applicazione Netflix funzioni il più velocemente possibile per gli utenti.
La presentazione ha ricevuto ottime opinioni dai partecipanti alla conferenza e abbiamo preparato per voi una versione testuale.
Nel suo intervento, Serghiei ha parlato in dettaglio
- di che cosa influisce sui tempi di latenza delle richieste Internet tra client e server;
- di come ridurre questa latenza;
- di come progettare, mantenere e monitorare sistemi resilienti agli errori;
- di come raggiungere risultati in tempi brevi, con il minor rischio possibile per il business;
- di come analizzare i risultati e imparare dagli errori.
Le risposte a queste domande sono necessarie non solo a chi lavora in grandi aziende.
I principi e le tecniche presentati devono essere conosciuti e praticati da chiunque sviluppi e mantenga prodotti internet.
Di seguito — una narrazione dalla voce del relatore.
L'importanza della velocità di internet
La velocità delle richieste internet è strettamente legata al business. Consideriamo il settore dello shopping: nel 2009, la società Amazon , che un ritardo di 100 ms porta a una perdita dell'1% delle vendite.
Ci sono sempre più dispositivi mobili, e con essi sempre più siti e applicazioni mobili. Se la tua pagina impiega più di 3 secondi a caricarsi, perdi circa la metà degli utenti. Dal , Google considera la velocità di caricamento della tua pagina nei risultati di ricerca: più veloce è la pagina, migliore è la sua posizione su Google.
La velocità di connessione è importante anche nelle organizzazioni finanziarie, dove la latenza è critica. Nel 2015, la società Hibernia Networks un cavo tra New York e Londra del valore di 400 milioni di dollari, per ridurre il ritardo tra le città di 6 ms. Immaginate, 66 milioni di dollari per ogni millisecondo di riduzione del ritardo!
Secondo , la velocità della connessione sopra i 5 Mbit/s smette di influenzare direttamente la velocità di caricamento di un sito web standard. Tuttavia, tra il ritardo di connessione e la velocità di caricamento della pagina si osserva una dipendenza lineare:
Tuttavia, Netflix non è un prodotto standard. L'impatto del ritardo e della velocità sull'utente è un'area attiva di analisi e sviluppo. Ci sono tempi di caricamento dell'app e selezione dei contenuti che dipendono dal ritardo, ma anche il caricamento di elementi statici e lo streaming dipendono dalla velocità della connessione. L'analisi e l'ottimizzazione dei fattori chiave che influenzano la qualità del servizio per l'utente sono un'area attiva di sviluppo per diversi team in Netflix. Uno degli obiettivi è ridurre il ritardo delle richieste tra i dispositivi Netflix e l'infrastruttura cloud.
Nel rapporto ci concentreremo specificamente sulla riduzione del ritardo (latency) prendendo come esempio l'infrastruttura di Netflix. Esamineremo da un punto di vista pratico come affrontare i processi di progettazione, sviluppo e gestione di sistemi distribuiti complessi, dedicando tempo all'innovazione e ai risultati, piuttosto che alla diagnosi di problemi operativi e guasti.
Dentro Netflix
Migliaia di dispositivi diversi supportano le applicazioni Netflix. Il loro sviluppo è curato da quattro diversi team, che realizzano versioni separate del client per Android, iOS, TV e browser web. Investiamo molte risorse per migliorare e personalizzare l'interfaccia utente. Per questo motivo, lanciamo parallelamente centinaia di test A/B.
La personalizzazione è supportata da centinaia di microservizi nel cloud AWS, che offrono dati personalizzati per l'utente, gestione delle richieste, telemetria, Big Data e Encoding. La visualizzazione del traffico appare così:
A sinistra si trova il punto d'entrata, dopodiché il traffico viene distribuito tra diverse centinaia di microservizi, supportati da diversi team di backend.
Un altro componente importante della nostra infrastruttura è Open Connect CDN, che consegna contenuti statici agli utenti finali, come video, immagini, codice per i client, ecc. La CDN è collocata su server personalizzati (OCA - Open Connect Appliance). All'interno ci sono array di dischi SSD e HDD gestiti da un FreeBSD ottimizzato, con NGINX e un insieme di servizi. Progettiamo e ottimizziamo i componenti hardware e software in modo che un server CDN possa inviare quante più informazioni possibile agli utenti.
La "parete" di questi server nel 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 diretto di dati su internet. Ci sono circa 70-80 punti di Internet Exchange nel mondo dove sono installati i nostri server, e ci occupiamo personalmente della loro installazione e manutenzione:
Inoltre, forniamo anche server direttamente ai fornitori di servizi internet, che li installano nella propria rete, migliorando la localizzazione del traffico Netflix e la qualità dello streaming per gli utenti:
Il set di servizi AWS è responsabile per la gestione delle richieste video dai client ai server CDN, così come per la configurazione stessa dei server — aggiornamento dei contenuti, codice sorgente, impostazioni, ecc. Per quest'ultimo abbiamo anche costruito una rete backbone, che collega i server nei punti di Internet Exchange a AWS. La rete backbone 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 consegna durante le ore di punta circa ⅛ del traffico internet mondiale e ⅓ del traffico in Nord America, dove Netflix esiste da più tempo. Numeri impressionanti, ma per me uno dei risultati più straordinari è che l'intero sistema CDN è sviluppato e mantenuto da un team di meno di 150 persone.
Inizialmente, l'infrastruttura CDN era progettata per la consegna di dati video. Tuttavia, nel tempo abbiamo capito che possiamo utilizzarla anche per ottimizzare le richieste dinamiche dai client verso il 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. Tuttavia, abbiamo a disposizione numerosi server CDN che vengono utilizzati per la distribuzione di contenuti statici. Possiamo in qualche modo sfruttare questa infrastruttura per accelerare le richieste dinamiche? Purtroppo, non è possibile memorizzare nella cache queste richieste: 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?
Materie prime
Ricordiamo come funzionano i protocolli di rete. Oggi gran parte del traffico su Internet utilizza HTTPS, che dipende dai protocolli di livello inferiore TCP e TLS. Per far sì che il cliente si connetta al server, è necessario un handshake, e per stabilire una connessione sicura il cliente deve scambiare messaggi con il server tre volte, e almeno una volta di più per trasferire i dati. Con una latenza di una singola interazione (RTT) di 100 ms, avremo bisogno di 400 ms per ricevere il primo bit di dati:
Se posizioniamo i certificati su un server CDN, il tempo di "stretta di mano" tra il cliente e il server può essere notevolmente ridotto se il CDN è più vicino. Supponiamo che la latenza verso il server CDN sia di 30 ms. Allora per ottenere il primo bit avremo bisogno di 220 ms:
Ma i vantaggi non si fermano qui. Dopo che la connessione è stata stabilita, TCP aumenta la congestion window (la quantità di informazioni che può inviare attraverso questa connessione in parallelo). Se un pacchetto di dati viene perso, le implementazioni classiche del protocollo TCP (come TCP New Reno) riducono la "finestra" aperta della metà. La crescita della congestion window e la velocità del suo recupero dalla perdita dipendono nuovamente dalla latenza (RTT) verso il server. Se questa connessione va solo al server CDN, il recupero sarà più veloce. Inoltre, la perdita di pacchetti è un fenomeno standard, specialmente per le reti wireless.
La capacità di internet può diminuire, soprattutto durante le ore di punta a causa del traffico degli utenti, il che può portare a "ingorghi". Tuttavia, su internet non esiste un metodo per dare priorità a certe richieste rispetto ad altre. Ad esempio, dare priorità a richieste di piccole dimensioni e sensibili ai ritardi rispetto ai "grandi" flussi di dati che sovraccaricano la rete. Tuttavia, nel nostro caso, avere una rete backbone proprietaria ci consente di farlo lungo parte del percorso della richiesta—tra CDN e cloud, e possiamo configurarla completamente. Possiamo fare in modo che i pacchetti piccoli e sensibili ai ritardi vengano prioritizzati, mentre i grandi flussi di dati vengono inviati un po' più tardi. Più vicino è il CDN al cliente, maggiore è l'efficienza.
Inoltre, i protocolli di livello applicativo (OSI Level 7) influenzano il ritardo. Nuovi protocolli, come HTTP/2, consentono di ottimizzare le performance delle richieste parallele. Tuttavia, abbiamo clienti di Netflix con dispositivi vecchi che non supportano i nuovi protocolli. Non tutti i clienti possono essere aggiornati o configurati in modo ottimale. Tuttavia, tra il proxy CDN e il cloud, c'è un controllo completo e la possibilità di usare protocolli e impostazioni nuovi e ottimali. La parte inefficiente con i vecchi protocolli agirà solo tra il cliente e il server CDN. Inoltre, possiamo effettuare il multiplexing delle richieste su una connessione già stabilita tra CDN e cloud, migliorando l'utilizzo della connessione a livello TCP:
Misuriamo
Sebbene la teoria prometta miglioramenti, non ci affrettiamo a lanciare il sistema in produzione. Dobbiamo prima dimostrare che l'idea funzionerà nella pratica. Per questo è necessario rispondere a diverse domande:
- Velocità: sarà il proxy più veloce?
- Affidabilità: si romperà più spesso?
- Complessità: come integrare con le applicazioni?
- Prezzo: quanto costa implementare un'infrastruttura aggiuntiva?
Esaminiamo in dettaglio il nostro approccio per valutare il 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 rompere la produzione. Per questo 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 molti fattori, ad esempio, a causa delle diverse dimensioni delle richieste, del tempo di elaborazione lato server e lato client. Inoltre, non è possibile testare una nuova configurazione senza effetti sulla produzione.
- Test di laboratorio. Server e infrastruttura specializzati che simulano i clienti. Con il loro aiuto eseguiamo i test necessari. In questo modo otteniamo un controllo completo sui risultati delle misurazioni e un segnale chiaro. Tuttavia, non c'è una copertura totale dei dispositivi e delle posizioni degli utenti (soprattutto con il servizio a livello mondiale e supporto per migliaia di modelli di dispositivi).
Come è possibile combinare i vantaggi di entrambi i metodi?
Il nostro team ha trovato una soluzione. Abbiamo scritto un piccolo pezzo di codice — una prova — che abbiamo integrato nella nostra applicazione. Le prove ci consentono di effettuare test di rete completamente controllabili dai nostri dispositivi. Funziona nel modo seguente:
- Subito dopo il caricamento dell'applicazione e il completamento delle attività iniziali, avviamo le nostre prove.
- Il cliente fa una richiesta al server e riceve una "ricetta" per il test. La ricetta è un elenco di URL ai quali effettuare una richiesta HTTP(S). Inoltre, la ricetta configura i parametri delle richieste: ritardi tra le richieste, volume dei dati richiesti, intestazioni HTTP(S), ecc. In questo modo possiamo testare contemporaneamente diverse ricette — per la richiesta di configurazione determiniamo casualmente quale ricetta fornire.
- Il tempo di avvio della prova viene scelto in modo da non confliggere con l'utilizzo attivo delle risorse di rete da parte del cliente. In sostanza, viene scelto un momento in cui il cliente non è attivo.
- Dopo aver ricevuto la ricetta, il cliente effettua richieste a ciascuno degli URL, parallelamente. La richiesta a ciascuno degli indirizzi può essere ripetuta — i cosiddetti "pulsanti". Nel primo impulso misuriamo quanto tempo ci è voluto per stabilire la connessione e scaricare i dati. Nel secondo impulso misuriamo il tempo di caricamento dei dati su una connessione già stabilita. Prima del terzo possiamo impostare un ritardo e misurare la velocità di stabilimento della connessione ripetuta, ecc.
Durante il test misuriamo tutti i parametri che il dispositivo può acquisire:
- tempo della richiesta DNS;
- tempo di stabilizzazione della connessione TCP;
- tempo di stabilizzazione 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 cicli, 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'influenza di vari fattori sulle prestazioni delle richieste, variandoli all'interno di una singola configurazione e ottenendo risultati da clienti reali.
Questa infrastruttura si è rivelata utile non solo per analizzare le prestazioni delle richieste. Attualmente abbiamo 14 configurazioni attive, oltre 6000 campioni al secondo, che ottengono dati da ogni angolo del mondo e una copertura completa dei dispositivi. Se Netflix acquistasse un servizio simile da aziende terze, costerebbe milioni di dollari all'anno, con una copertura di gran lunga inferiore.
Mettiamo alla prova la teoria: prototipo
Con un sistema del genere abbiamo potuto valutare l'efficacia del proxy CDN sulle latenze delle richieste. Ora è necessario:
- creare un prototipo di proxy;
- disporre il prototipo sul CDN;
- definire come indirizzare i client verso il proxy su un server CDN specifico;
- confrontare le prestazioni con le richieste su AWS senza proxy.
L'obiettivo è valutare l'efficacia della soluzione proposta il più rapidamente possibile. Per implementare il prototipo abbiamo scelto Go, grazie alla disponibilità di ottime librerie di rete. Su ogni server CDN abbiamo installato il prototipo di proxy come binary statico, per minimizzare le dipendenze e semplificare l'integrazione. Nella prima implementazione abbiamo utilizzato al massimo i componenti standard e piccole modifiche per il pooling delle connessioni HTTP/2 e per il multiplexing delle richieste.
Per bilanciare tra le regioni AWS, abbiamo utilizzato un database DNS geografico, lo stesso utilizzato per bilanciare i clienti. Per selezionare il server CDN per il cliente, utilizziamo TCP Anycast per i server nell'Internet Exchange (IX). In questa soluzione utilizziamo un solo indirizzo IP per tutti i server CDN, in modo che il cliente venga indirizzato verso il server CDN con il minor numero di IP hops. Nei server CDN installati presso i fornitori di servizi Internet (ISP) non abbiamo controllo sul router per configurare TCP Anycast, quindi utilizziamo , secondo la quale i clienti vengono indirizzati ai fornitori di servizi Internet per lo streaming video.
Quindi, abbiamo tre tipi di percorsi per la richiesta: verso il cloud attraverso internet aperto, attraverso un server CDN nell'IX o attraverso un server CDN situato presso il fornitore di servizi Internet. Il nostro obiettivo è capire quale percorso sia migliore e quale vantaggio offra il proxy rispetto al modo in cui le richieste vengono indirizzate in produzione. A questo scopo utilizziamo un sistema di probe nel seguente modo:
Ogni percorso diventa un target separato, e osserviamo il tempo che abbiamo ottenuto. Per l'analisi uniamo i risultati dei proxy in un unico gruppo (selezionando il miglior tempo tra IX e proxy ISP) e lo confrontiamo con il tempo delle richieste verso il cloud senza proxy:
Come si può vedere, i risultati sono stati ambigui—nella maggior parte dei casi il proxy fornisce un buon aumento di velocità, ma ci sono anche un numero sufficiente di clienti per i quali la situazione peggiorerà significativamente.
In definitiva, abbiamo fatto alcune cose importanti:
- Abbiamo valutato le prestazioni attese delle richieste dai clienti verso il cloud attraverso il proxy CDN.
- Abbiamo ottenuto dati da clienti reali, da tutti i tipi di dispositivi.
- Abbiamo capito che la teoria non si è confermata al 100% e che la nostra proposta iniziale con il proxy CDN non funzionerà.
- Non abbiamo preso rischi—non abbiamo modificato le configurazioni di produzione per i clienti.
- Non abbiamo rotto nulla.
Prototipo 2.0
Quindi, torniamo alla lavagna e ripetiamo il processo da capo.
L'idea è—anziché un proxy al 100%, per ogni cliente definiamo il percorso più veloce e indirizziamo le richieste verso di esso—quindi faremo ciò che si chiama client steering.
Come realizzare questo? Non possiamo utilizzare la logica sul lato server, poiché l'obiettivo è connettersi a questo server. Dobbiamo fare in qualche modo questo sul client. E idealmente, farlo con la minima quantità di logica complessa, per non dover affrontare l'integrazione con un vasto numero di piattaforme client.
La risposta è l'uso del DNS. Nel nostro caso abbiamo la nostra infrastruttura DNS e possiamo configurare una zona di dominio per la quale i nostri server saranno autoritativi. Funziona in questo modo:
- 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 qual è il percorso più veloce per questo client e fornisce l'indirizzo IP corrispondente.
Nella soluzione c'è una complessità aggiuntiva: i provider DNS autoritativi non vedono l'indirizzo IP del client e possono vedere solo l'indirizzo IP del resolver ricorsivo utilizzato dal client.
Di conseguenza, il nostro resolver autoritativo deve prendere decisioni non per un singolo client, ma per un gruppo di client basate sul resolver ricorsivo.
Per risolvere utilizziamo gli stessi campioni, aggregando i risultati delle misurazioni dai client per ciascun resolver ricorsivo e decidendo dove indirizzare questo gruppo: proxy tramite IX utilizzando TCP Anycast, tramite proxy ISP o direttamente nel cloud.
Otteniamo un sistema del genere:
Il modello di DNS steering ottenuto consente di indirizzare i client sulla base di osservazioni storiche sulla velocità delle connessioni dai client al cloud.
Ancora una volta, la questione è: quanto sarà efficace questo approccio? Per rispondere utilizziamo di nuovo il nostro sistema di campionamento. Pertanto, configuriamo la configurazione di recente, dove uno degli obiettivi segue la direzione del DNS steering, l'altro va direttamente nel cloud (attuale produzione).
Alla fine, confrontiamo i risultati e otteniamo una valutazione dell'efficacia:
Di conseguenza, abbiamo scoperto alcune cose importanti:
- Abbiamo valutato le prestazioni attese delle richieste dai client al cloud utilizzando DNS Steering.
- Abbiamo ottenuto dati da clienti reali, da tutti i tipi di dispositivi.
- Abbiamo dimostrato l'efficacia dell'idea proposta.
- Non abbiamo preso rischi—non abbiamo modificato le configurazioni di produzione per i clienti.
- Non abbiamo rotto nulla.
Ora la parte difficile: avviamo in produzione
Il più facile è ora alle spalle: abbiamo un prototipo funzionante. La parte difficile è ora lanciare la soluzione per tutto il traffico di Netflix, distribuito a 150 milioni di utenti, migliaia di dispositivi, centinaia di microservizi e un prodotto e un'infrastruttura in continua evoluzione. I server di Netflix ricevono milioni di richieste al secondo e un'azione imprudente può facilmente mandare in tilt il servizio. Dobbiamo quindi indirizzare dinamicamente il traffico attraverso migliaia di server CDN, su Internet, dove tutto cambia e si rompe costantemente, e nei momenti meno opportuni.
E nonostante tutto questo, nel team ci sono 3 ingegneri responsabili dello sviluppo, del deployment e del completo supporto del sistema.
Pertanto, continueremo a parlare di sonno tranquillo e sano.
Come continuare a sviluppare senza spendere tutto il tempo nella manutenzione? La nostra strategia si basa su 3 principi:
- Riduciamo il potenziale impatto dei guasti (blast radius).
- Ci prepariamo alle sorprese: ci aspettiamo che qualcosa si rompa, nonostante i test e l’esperienza personale.
- Degradazione graduale (graceful degradation) — se qualcosa non funziona, deve ripararsi automaticamente, anche se non nel modo più efficiente.
Si è scoperto che, con questo approccio al problema, è possibile trovare una soluzione semplice ed efficace e semplificare notevolmente il supporto del sistema. Abbiamo capito che possiamo aggiungere un piccolo pezzo di codice al client e monitorare gli errori nelle richieste di rete causati da problemi di connessione. In caso di errori di rete, facciamo un fallback direttamente nel cloud. Questa soluzione non richiede notevoli sforzi per i team dei clienti, ma riduce notevolmente il rischio di guasti imprevisti e sorprese per noi.
Naturalmente, nonostante il fallback, seguiamo una chiara disciplina nel processo di sviluppo:
- Test di campionamento.
- Test A/B o Canaries.
- Rilascio graduale (progressive rollout).
Per quanto riguarda il campionamento, l'approccio è stato descritto: le modifiche vengono inizialmente testate utilizzando una ricetta configurata.
Per il testing canary, dobbiamo ottenere coppie di server comparabili, su cui possiamo confrontare come funziona il sistema prima e dopo le modifiche. A questo scopo, selezioniamo coppie di server dai nostri numerosi siti CDN, che ricevono un traffico comparabile:
Poi mettiamo l'assemblaggio 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 su Canary ha avuto esito positivo, rilasciamo gradualmente, a onde. Su ciascun sito non aggiorniamo i server contemporaneamente: la perdita di un intero sito in caso di problemi ha un impatto maggiore sul servizio per gli utenti rispetto alla perdita di un numero equivalente 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 possibili componenti:
- dai client - numero di sessioni e richieste, tassi di fallback;
- proxy - statistiche sul numero e il tempo 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 al percorso critico delle richieste tra il client e il server. Nel frattempo, il numero di diversi componenti sul client, sul server e nel percorso attraverso Internet è enorme. Le modifiche sul client e sul server avvengono costantemente, grazie al lavoro di decine di team e ai cambiamenti naturali nell'ecosistema. Siamo nel mezzo: durante la diagnosi dei problemi, è molto probabile che saremo coinvolti. Pertanto, dobbiamo sapere chiaramente come identificare, raccogliere e analizzare le metriche per una rapida localizzazione dei problemi.
Idealmente, un accesso completo a tutte le metriche e ai filtri in tempo reale. Ma ci sono molte metriche, quindi sorge la questione del costo. Nel nostro caso, separiamo le metriche e gli strumenti di sviluppo nel seguente modo:
Per rilevare e fare triage dei problemi utilizziamo un nostro sistema real-time open source e — per la visualizzazione. Memorizza metriche aggregate in memoria, è affidabile e si integra con il sistema di allerta. Per la localizzazione e la diagnosi abbiamo accesso ai log di Elasticsearch e Kibana. Per analisi statistiche e modellazione utilizziamo big data e visualizzazione in Tableau.
Sembra che sia molto difficile lavorare con questo approccio. Tuttavia, con un'organizzazione gerarchica delle metriche e degli strumenti, possiamo analizzare rapidamente il problema, definire il tipo di problema e poi approfondire le metriche dettagliate. In media, impieghiamo circa 1-2 minuti per identificare la fonte del guasto. Dopo di che, lavoriamo già con un team specifico sulla diagnostica — da decine di minuti a diverse ore.
Anche se la diagnostica viene eseguita rapidamente, non vogliamo che accada spesso. In un caso ideale, 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 ci 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. Controlliamo quanti clienti hanno utilizzato il fallback se non sono riusciti a ottenere accelerazione delle richieste. In media, abbiamo meno di 1 avviso critico alla settimana, nonostante il grande numero di modifiche che avvengono nel sistema. Perché ci basta?
- C'è un client fallback nel caso in cui il nostro proxy non funzioni.
- C'è un sistema di gestione automatica che reagisce ai problemi.
Parliamo di quest'ultimo in maggior dettaglio. Il nostro sistema di probe e il sistema di determinazione automatica del percorso ottimale per le richieste dal cliente al cloud consentono di gestire automaticamente alcuni problemi.
Torniamo alla nostra configurazione delle probe e alle 3 categorie di percorsi. Oltre al tempo di caricamento, possiamo osservare il semplice fatto di consegna. Se non riescono a caricare i dati, guardando i risultati sui diversi percorsi possiamo determinare dove e cosa si è rotto, e se possiamo ripararlo automaticamente modificando il percorso della richiesta.
Esempi:
Questo processo può essere automatizzato. Integrarlo nel sistema di gestione. E insegnargli a reagire ai problemi di prestazioni e affidabilità. Se qualcosa inizia a guastarsi — deve reagire, se c'è un'opzione migliore. In questo caso, una reazione immediata non è critica, grazie al fallback sui client.
In questo modo, i principi di supporto del sistema possono essere riassunti così:
- riduciamo l'entità dei guasti;
- raccogliamo metriche;
- ripariamo automaticamente i guasti, se possiamo;
- se non possiamo — notifichiamo;
- stiamo lavorando su dashboard e triage toolset 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 di produzione. Poi è iniziato un lavoro noioso e molto complesso: gradualmente productizzare e scalare il sistema, migrare il traffico principale e imparare dai propri errori. Questo processo efficace non sarà lineare: nonostante i diversi sforzi, non si può prevedere tutto. È molto più efficace una rapida iterazione e reazione 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 sottovalutato il previsto accelerazione dall'utilizzo della CDN proxy, o il comportamento del TCP Anycast.
- Raccogliete dati dalla produzione.
È importante avere accesso il prima possibile a un numero anche ridotto di dati di produzione. È praticamente impossibile ottenere il numero unico di casi, configurazioni, impostazioni in condizioni di laboratorio. Un rapido accesso ai risultati consentirà di scoprire più rapidamente potenziali problemi e di tenerli in considerazione nell'architettura del sistema.
- Non seguite i consigli e i risultati altrui: raccogliete i vostri dati.
Seguite i principi di raccolta e analisi dei dati, ma non accettate ciecamente i risultati e le affermazioni altrui. Solo voi potete sapere con certezza cosa funziona per i vostri utenti. I vostri sistemi e i vostri clienti possono differire notevolmente da altre aziende. Fortunatamente, gli strumenti per l'analisi sono attualmente accessibili e facili da usare. I risultati che ottenete potrebbero non corrispondere a ciò che affermano Netflix, Facebook, Akamai e altre aziende. Nel nostro caso, le prestazioni di TLS, HTTP2 o le statistiche sulle richieste DNS differiscono dai risultati di Facebook, Uber, Akamai — perché abbiamo dispositivi, clienti e flussi di dati diversi.
- Non inseguite le tendenze senza motivo e senza valutare l'efficacia.
Iniziate con qualcosa di semplice. È meglio realizzare un sistema semplice e funzionante in poco tempo piuttosto che spendere un'enorme quantità di tempo nello sviluppo di componenti non necessari. Affrontate le sfide e i problemi che sono importanti sulla base delle vostre misurazioni e risultati.
- Siate pronti a nuove applicazioni.
Così come è difficile prevedere tutti i problemi, è difficile anticipare i vantaggi e le applicazioni. Prendete esempio dalle startup: la loro capacità di adattarsi alle condizioni 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 capito che possiamo anche applicare i proxy server:
- per il bilanciamento del traffico tra le regioni AWS e per ridurre i costi;
- per modellare la stabilità della CDN;
- per la configurazione del DNS;
- per la configurazione di TLS/TCP.
Conclusione
Nel mio rapporto ho descritto come Netflix affronta il problema dell'accelerazione delle richieste internet tra i clienti e il cloud. Come raccogliamo dati tramite un sistema di campionamento sui clienti e utilizziamo i dati storici raccolti per instradare le richieste di produzione dai clienti lungo 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 noi di Netflix abbiamo implementato un tale sistema. Ciò che ha funzionato per noi. La parte pratica del mio intervento per voi sono i principi di sviluppo e mantenimento che seguiamo e che portano a buoni risultati.
La nostra soluzione al problema potrebbe non adattarsi a voi. Tuttavia, la teoria e i principi di sviluppo rimangono, anche se non avete una vostra infrastruttura CDN, o se essa differisce sostanzialmente dalla nostra.
Rimane anche l'importanza della velocità delle richieste per il business. Anche per un servizio semplice bisogna prendere decisioni: tra fornitori "cloud", posizioni dei server, CDN e fornitori di DNS. La vostra scelta influirà sull'efficienza delle richieste internet per i vostri clienti. E per voi è importante misurare e comprendere quest'impatto.
Iniziate con soluzioni semplici, preoccupatevi di come modificate il prodotto. Imparate nel processo e perfezionate il sistema sulla base dei dati provenienti dai vostri clienti, dalla vostra infrastruttura e dal vostro business. Pensate alla possibilità di guasti imprevisti durante la progettazione. Allora potrete accelerare il vostro processo di sviluppo, migliorare l'efficienza della soluzione, evitare un carico eccessivo sul supporto e dormire sonni tranquilli.
Quest'anno in formato online. Sarà possibile porre domande a uno dei padri di DevOps, il stesso John Willis!
Fonte: habr.com
