{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Accelera le richieste Internet e dormi sonni tranquilli.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix \u00e8 il leader del mercato della televisione via internet e ha creato e sviluppa attivamente questo segmento. Netflix \u00e8 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. <\/p>\n<p>Un chiaro esempio dell'approccio di Netflix allo sviluppo e al supporto di sistemi complessi \u00e8 stato presentato al DevOops 2019 da <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergej Fedorov<\/a><\/noindex> \u2014 direttore dello sviluppo in Netflix. Laureato presso il dipartimento di VMC dell'Universit\u00e0 NNGU di Lobachevskij, Sergej \u00e8 uno dei primi ingegneri nel team Open Connect \u2014 CDN di Netflix. Ha creato sistemi di monitoraggio e analisi dei dati video, ha lanciato il popolare servizio per valutare la velocit\u00e0 della connessione a Internet FAST.com e negli ultimi anni ha lavorato all'ottimizzazione delle richieste Internet affinch\u00e9 l'app di Netflix funzionasse il pi\u00f9 velocemente possibile per gli utenti.<\/p>\n<p>La presentazione ha ricevuto il migliore feedback dai partecipanti alla conferenza e abbiamo preparato per voi la versione testuale.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"Riproduci video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Nella sua presentazione, Sergej ha parlato in dettaglio<\/h2>\n<p><\/p>\n<ul>\n<li>di cosa influisce sulla latenza delle richieste Internet tra il client e il server;<\/li>\n<li>di come ridurre questa latenza;<\/li>\n<li>come progettare, mantenere e monitorare sistemi resistenti agli errori;<\/li>\n<li>come raggiungere risultati in tempi brevi e con il minimo rischio per il business;<\/li>\n<li>come analizzare i risultati e imparare dagli errori.<\/li>\n<\/ul>\n<p>\nLe risposte a queste domande servono non solo a chi lavora in grandi aziende. <\/p>\n<p>I principi e le tecniche presentati dovrebbero essere conosciuti e praticati da chiunque sviluppi e mantenga prodotti online.<\/p>\n<p><b>Di seguito \u2014 un racconto dal punto di vista del relatore.<\/b><\/p>\n<h2>L'importanza della velocit\u00e0 di internet<\/h2>\n<p>\nLa velocit\u00e0 delle richieste internet \u00e8 direttamente correlata al business. Prendiamo in considerazione il settore dello shopping: nel 2009, l'azienda Amazon <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">ha dichiarato<\/a><\/noindex>, che un ritardo di 100 ms comporta una perdita dell'1% delle vendite.<\/p>\n<p>Sempre pi\u00f9 dispositivi mobili stanno emergendo, seguito da siti e applicazioni mobili. Se la tua pagina impiega pi\u00f9 di 3 secondi a caricarsi, perdi circa la met\u00e0 degli utenti. A partire dal <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">luglio 2018<\/a><\/noindex> , Google tiene conto della velocit\u00e0 di caricamento della tua pagina nel ranking dei risultati di ricerca: pi\u00f9 veloce \u00e8 la pagina, migliore sar\u00e0 la sua posizione su Google.<\/p>\n<p>Anche la velocit\u00e0 di connessione \u00e8 importante nelle istituzioni finanziarie, dove il ritardo \u00e8 critico. Nel 2015, Hibernia Networks <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">ha completato<\/a><\/noindex> una connessione in fibra tra New York e Londra costata 400 milioni di dollari, per ridurre il ritardo tra le due citt\u00e0 di 6 ms. Immagina, 66 milioni di dollari per 1 ms di riduzione del ritardo!<\/p>\n<p>Secondo <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">uno studio<\/a><\/noindex>, la velocit\u00e0 di connessione superiore a 5 Mbps smette di influenzare direttamente la velocit\u00e0 di caricamento di un sito web tipico. Tuttavia, esiste una relazione lineare tra il ritardo della connessione e la velocit\u00e0 di caricamento della pagina:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTuttavia, Netflix non \u00e8 un prodotto tipico. L'impatto del ritardo e della velocit\u00e0 sull'utente \u00e8 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\u00e0 di connessione. L'analisi e l'ottimizzazione dei fattori chiave che influenzano la qualit\u00e0 del servizio per l'utente \u00e8 un'area di sviluppo attiva di diversi team in Netflix. Uno degli obiettivi \u00e8 ridurre il ritardo delle richieste tra i dispositivi Netflix e l'infrastruttura cloud.<\/p>\n<p>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.<\/p>\n<h2>All'interno di Netflix<\/h2>\n<p>\nMigliaia di dispositivi diversi supportano le app Netflix. Il loro sviluppo \u00e8 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.<\/p>\n<p>La personalizzazione \u00e8 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\u00ec:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link al video con dimostrazione (6:04-6:23)<\/a><\/noindex><\/p>\n<p>A sinistra c'\u00e8 il punto di ingresso, dopo di che il traffico viene distribuito tra diverse centinaia di microservizi, sostenuti da vari team di backend.<\/p>\n<p>Un altro componente importante della nostra infrastruttura \u00e8 il Open Connect CDN, che fornisce contenuti statici agli utenti finali \u2014 video, immagini, codice per i clienti, ecc. Il CDN si trova su server personalizzati (OCA \u2014 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. <\/p>\n<p>La \"muraglia\" di questi server presso il punto di scambio del traffico internet (Internet eXchange \u2014 IX) appare cos\u00ec:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'Internet Exchange offre ai fornitori di servizi internet e ai fornitori di contenuti la possibilit\u00e0 di \"collegarsi\" tra loro per uno scambio di dati pi\u00f9 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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInoltre, forniamo anche server direttamente ai fornitori di servizi internet, che li installano nella loro rete, migliorando la localizzazione del traffico Netflix e la qualit\u00e0 dello streaming per gli utenti:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl set di servizi AWS \u00e8 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.<\/p>\n<p>Secondo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">valutazioni Sandvine<\/a><\/noindex>, la nostra infrastruttura CDN gestisce nelle ore di punta circa \u215b del traffico internet mondiale e \u2153 del traffico in Nord America, dove Netflix \u00e8 attiva da pi\u00f9 tempo. Numeri impressionanti, ma per me uno dei successi pi\u00f9 sorprendenti \u00e8 che l'intero sistema CDN \u00e8 sviluppato e gestito da un team di meno di 150 persone.<\/p>\n<p>Inizialmente, l'infrastruttura CDN \u00e8 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.<\/p>\n<h2>Sull'accelerazione di Internet<\/h2>\n<p>\nOggi Netflix ha 3 regioni AWS, e la latenza delle richieste nel cloud dipender\u00e0 da quanto \u00e8 lontano il cliente dalla regione pi\u00f9 vicina. Abbiamo anche molti server CDN che vengono utilizzati per consegnare contenuti statici. \u00c8 possibile utilizzare questa infrastruttura per accelerare le richieste dinamiche? Purtroppo non \u00e8 possibile memorizzare nella cache queste richieste, poich\u00e9 le API sono personalizzate e ogni risultato \u00e8 unico.<\/p>\n<p>Facciamo un proxy su un server CDN e iniziamo a instradare il traffico attraverso di esso. Sar\u00e0 pi\u00f9 veloce?<\/p>\n<h2>Materiale<\/h2>\n<p>\nRicordiamo 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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe posizioniamo i certificati su un server CDN, possiamo ridurre significativamente il tempo di \u00abhandshake\u00bb tra il client e il server, se il CDN \u00e8 pi\u00f9 vicino. Supponiamo che la latenza verso il server CDN sia di 30 ms. Allora, per ricevere il primo bit, saranno necessari gi\u00e0 220 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa i vantaggi non finiscono qui. Dopo che la connessione \u00e8 stata stabilita, TCP aumenta la congestion window (la quantit\u00e0 di informazioni che pu\u00f2 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\u00e0 la \u00abfinestra\u00bb aperta. L'aumento della congestion window e la velocit\u00e0 di ripristino dalla perdita dipendono nuovamente dalla latenza (RTT) verso il server. Se questa connessione va solo al server CDN, il ripristino sar\u00e0 pi\u00f9 rapido. Inoltre, la perdita di pacchetti \u00e8 un fenomeno standard, specialmente per le reti wireless.<\/p>\n<p>La capacit\u00e0 di internet pu\u00f2 diminuire, specialmente durante le ore di punta a causa del traffico degli utenti, il che pu\u00f2 portare a \"ingorghi\". Non esiste un modo per dare priorit\u00e0 a alcune richieste rispetto ad altre. Ad esempio, non \u00e8 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 \u2014 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\u00f9 grandi vengano processati leggermente dopo. Maggiore \u00e8 la vicinanza del CDN al cliente, maggiore \u00e8 l'efficacia.<\/p>\n<p>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\u00e0 di utilizzare protocolli e configurazioni nuovi e ottimali. La parte inefficiente con i vecchi protocolli si attiver\u00e0 solo tra il cliente e il server CDN. Inoltre, possiamo multiplexare le richieste su una connessione gi\u00e0 stabilita tra il CDN e il cloud, migliorando l'utilizzo della connessione a livello TCP:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Misuriamo<\/h2>\n<p>\nNonostante la teoria prometta miglioramenti, non lanciamo subito il sistema in produzione. Invece, dobbiamo prima dimostrare che l'idea funzioner\u00e0 nella pratica. Per questo \u00e8 necessario rispondere a diverse domande:<\/p>\n<ul>\n<li><b>Velocit\u00e0<\/b>: il proxy sar\u00e0 pi\u00f9 veloce?<\/li>\n<li><b>Affidabilit\u00e0<\/b>: dar\u00e0 pi\u00f9 spesso problemi?<\/li>\n<li><b>Complesso<\/b>: come integrare con le applicazioni?<\/li>\n<li><b>Costo<\/b>: quanto costa implementare un'infrastruttura aggiuntiva?<\/li>\n<\/ul>\n<p>\nEsaminiamo in dettaglio il nostro approccio alla valutazione del primo punto. Gli altri vengono analizzati in modo simile.<\/p>\n<p>Per analizzare la velocit\u00e0 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:<\/p>\n<ol>\n<li>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 \u00e8 che il segnale non \u00e8 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 \u00e8 possibile testare una nuova configurazione senza effetti sulla produzione.<\/li>\n<li>Test di laboratorio. Server e infrastrutture speciali che simulano i clienti. Con questi conduciamo i test necessari. Cos\u00ec otteniamo il pieno controllo sui risultati delle misurazioni e un segnale chiaro. Tuttavia, non c'\u00e8 una copertura completa dei dispositivi e delle posizioni degli utenti (soprattutto con un servizio globale e il supporto per migliaia di modelli di dispositivi).<\/li>\n<\/ol>\n<p>\nCome si possono combinare i vantaggi di entrambi i metodi?<\/p>\n<p>Il nostro team ha trovato una soluzione. Abbiamo scritto un piccolo codice \u2014 una prova \u2014 che abbiamo integrato nella nostra applicazione. Le prove ci consentono di effettuare test di rete completamente controllati dai nostri dispositivi. Funziona in questo modo: <\/p>\n<ol>\n<li>Poco dopo aver caricato l'applicazione e completato l'attivit\u00e0 iniziale, avviamo le nostre prove. <\/li>\n<li>Il cliente invia una richiesta al server e riceve una \"ricetta\" per il test. La ricetta \u00e8 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 \u2014 quando si richiede la configurazione, verr\u00e0 scelto casualmente quale ricetta fornire. <\/li>\n<li>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 \u00e8 attivo.<\/li>\n<li>Dopo aver ricevuto la prescrizione, il cliente invia richieste a ciascuno degli URL in parallelo. La richiesta a ciascun indirizzo pu\u00f2 essere ripetuta, ovvero i cosiddetti \"pulse\". Nel primo pulse misuriamo quanto tempo \u00e8 necessario per stabilire la connessione e caricare i dati. Nel secondo pulse misuriamo il tempo di caricamento dei dati attraverso la connessione gi\u00e0 stabilita. Prima del terzo, possiamo impostare un ritardo e misurare la velocit\u00e0 di stabilimento della riconnessione, ecc.\n<p>Durante il test, misuriamo tutti i parametri che il dispositivo pu\u00f2 ottenere:<\/p>\n<ul>\n<li>tempo di richiesta DNS;<\/li>\n<li>tempo di stabilimento della connessione TCP;<\/li>\n<li>tempo di stabilimento della connessione TLS;<\/li>\n<li>tempo di ricezione del primo byte di dati;<\/li>\n<li>tempo totale di caricamento;<\/li>\n<li>codice di stato del risultato.<\/li>\n<\/ul>\n<\/li>\n<li> Al termine di tutti i pulse, il campione carica i risultati di tutte le misurazioni per l'analisi.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI 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\u00e0 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.<\/p>\n<p>Questa infrastruttura si \u00e8 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.<\/p>\n<h2>Mettiamo alla prova la teoria: prototipo<\/h2>\n<p>\nCon un sistema del genere abbiamo potuto valutare l'efficacia del proxy CDN sulla latenza delle richieste. Ora \u00e8 necessario:<\/p>\n<ul>\n<li>creare un prototipo di proxy;<\/li>\n<li>ospitare il prototipo su un CDN;<\/li>\n<li>determinare come indirizzare i clienti al proxy su un server CDN specifico;<\/li>\n<li>confrontare le prestazioni con le richieste su AWS senza proxy.<\/li>\n<\/ul>\n<p>\nL'obiettivo \u00e8 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.<\/p>\n<p>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 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">la stessa logica<\/a><\/noindex>, secondo la quale i clienti sono indirizzati ai fornitori di servizi Internet per lo streaming video.<\/p>\n<p>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 \u00e8 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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCiascuno 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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome si pu\u00f2 vedere, i risultati sono stati ambivalenti: nella maggior parte dei casi, il proxy offre un buon aumento della velocit\u00e0, ma ci sono anche un numero sufficiente di clienti per i quali la situazione peggiorerebbe significativamente. <\/p>\n<p>Alla fine, abbiamo fatto alcune cose importanti:<\/p>\n<ol>\n<li>Abbiamo valutato le prestazioni attese delle richieste dei clienti verso il cloud tramite il proxy CDN.<\/li>\n<li>Abbiamo ottenuto dati da veri clienti, provenienti da tutti i tipi di dispositivi.<\/li>\n<li>Abbiamo capito che la teoria non si \u00e8 confermata al 100% e che l'offerta iniziale con il proxy CDN non funzioner\u00e0 per noi.<\/li>\n<li>Non abbiamo rischiato \u2014 non abbiamo modificato la configurazione di produzione per i clienti.<\/li>\n<li>Non abbiamo rotto nulla. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prototipo 2.0<\/h2>\n<p>\nQuindi torniamo alla lavagna e ripetiamo il processo da capo.<\/p>\n<p>L'idea \u00e8 che, invece di utilizzare un proxy al 100%, per ogni cliente definiamo il percorso pi\u00f9 veloce e indirizziamo le richieste l\u00ec \u2014 in altre parole, faremo ci\u00f2 che viene chiamato client steering.<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome realizzare questo? Non possiamo utilizzare la logica sul lato server, poich\u00e9 l'obiettivo \u00e8 connettersi a quel server. Dobbiamo in qualche modo fare questo lato client. E idealmente, farlo con la minima quantit\u00e0 di logica complessa, in modo da non dover affrontare l'integrazione con un vasto numero di piattaforme client. <\/p>\n<p>La risposta \u00e8 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\u00ec:<\/p>\n<ol>\n<li>Il cliente invia una richiesta al server DNS utilizzando l'host, ad esempio api.netflix.xom.<\/li>\n<li>La richiesta arriva al nostro server DNS<\/li>\n<li>Il server DNS sa qual \u00e8 il percorso pi\u00f9 veloce per questo cliente e restituisce l'indirizzo IP corrispondente. <\/li>\n<\/ol>\n<p>\nC'\u00e8 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. <\/p>\n<p>Di conseguenza, il nostro resolver autoritativo deve prendere decisioni non per un singolo cliente, ma per un gruppo di clienti basato sul resolver ricorsivo. <\/p>\n<p>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.<\/p>\n<p>Otteniamo un sistema del genere:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl modello DNS steering ottenuto consente di indirizzare i clienti in base alle osservazioni storiche sulla velocit\u00e0 delle connessioni dai clienti al cloud. <\/p>\n<p>Ancora una volta, ci chiediamo: quanto sar\u00e0 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).<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlla fine, confrontiamo i risultati e otteniamo una valutazione dell'efficacia:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi conseguenza, abbiamo appreso alcune cose importanti:<\/p>\n<ol>\n<li>Abbiamo valutato le aspettative di prestazione delle richieste dei clienti verso il cloud utilizzando DNS Steering.<\/li>\n<li>Abbiamo ottenuto dati da veri clienti, provenienti da tutti i tipi di dispositivi.<\/li>\n<li>Abbiamo dimostrato l\u2019efficacia dell'idea proposta.<\/li>\n<li>Non abbiamo rischiato \u2014 non abbiamo modificato la configurazione di produzione per i clienti.<\/li>\n<li>Non abbiamo rotto nulla.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Ora passiamo al difficile: lanciamo in produzione.<\/h2>\n<p>\nLa parte pi\u00f9 semplice \u00e8 ormai alle spalle: abbiamo un prototipo funzionante. Ora la parte complicata \u00e8 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\u00f2 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. <\/p>\n<p>E in tutto questo, nel team ci sono 3 ingegneri responsabili dello sviluppo, del deployment e del completo supporto del sistema.<\/p>\n<p>Pertanto, parleremo ora di un sonno tranquillo e sano.<\/p>\n<p>Come continuare a sviluppare, senza spendere tutto il tempo nel supporto? Alla base del nostro approccio ci sono 3 principi:<\/p>\n<ol>\n<li>Riduciamo il potenziale impatto dei guasti (blast radius). <\/li>\n<li>Prepariamoci alle sorprese: ci aspettiamo che qualcosa si rompa, nonostante i test e l'esperienza personale.<\/li>\n<li>Degradazione graduale (graceful degradation): se qualcosa non funziona come dovrebbe, deve ripararsi automaticamente, anche se non nel modo pi\u00f9 efficiente.<\/li>\n<\/ol>\n<p>\nCi siamo resi conto che nel nostro caso, con questo approccio al problema, \u00e8 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.<\/p>\n<p>Naturalmente, nonostante il fallback, seguiamo comunque una rigorosa disciplina nello sviluppo:<\/p>\n<ol>\n<li>Test su campioni.<\/li>\n<li>Test A\/B o Canarie.<\/li>\n<li>Rilascio graduale (progressive rollout).<\/li>\n<\/ol>\n<p>\nCon i campioni, l'approccio \u00e8 stato descritto: le modifiche vengono prima testate utilizzando una ricetta configurata.<\/p>\n<p>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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSuccessivamente, 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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe 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\u00f9 significativo sul servizio per gli utenti rispetto alla perdita dello stesso numero di server, ma in luoghi diversi.<\/p>\n<p>In generale, l'efficacia e la sicurezza di questo approccio dipendono dalla quantit\u00e0 e dalla qualit\u00e0 delle metriche raccolte. Per il nostro sistema di accelerazione delle richieste, raccogliamo metriche da tutti i componenti possibili: <\/p>\n<ul>\n<li>dai client \u2014 numero di sessioni e richieste, tassi di fallback; <\/li>\n<li>proxy \u2014 statistiche sul numero e sui tempi delle richieste;<\/li>\n<li>DNS \u2014 numero e risultati delle richieste;<\/li>\n<li>cloud edge \u2014 numero e tempo di elaborazione delle richieste nel cloud.<\/li>\n<\/ul>\n<p>\nTutto ci\u00f2 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\u00f9 dettagliata.<\/p>\n<h2>Monitoriamo<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNel 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 \u00e8 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\u00e0 strada: durante la diagnosi dei problemi \u00e8 probabile che siamo coinvolti. Pertanto, dobbiamo avere una chiara comprensione di come definire, raccogliere e analizzare le metriche per una rapida localizzazione dei problemi. <\/p>\n<p>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:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer rilevare e classificare i problemi utilizziamo il nostro sistema di analisi in tempo reale con codice sorgente aperto. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 per la visualizzazione. Essa conserva metriche aggregate in memoria, \u00e8 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.<\/p>\n<p>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 \u2014 approfondire le metriche dettagliate. Per identificare la fonte del malfunzionamento, in media impieghiamo circa 1-2 minuti. Dopo ci\u00f2, lavoriamo gi\u00e0 con il team specifico sulla diagnosi \u2014 da decine di minuti a diverse ore.<\/p>\n<p>Anche se la diagnosi avviene rapidamente, non desideriamo che accada frequentemente. Idealmente, riceveremo un avviso critico solo quando c'\u00e8 un impatto significativo sul servizio. Per il nostro sistema di accelerazione delle richieste, abbiamo solo 2 avvisi che notificheranno:<\/p>\n<ul>\n<li>percentuale Client Fallback \u2014 valutazione del comportamento dei clienti;<\/li>\n<li>percentuale Probe errors \u2014 dati sulla stabilit\u00e0 dei componenti di rete.<\/li>\n<\/ul>\n<p>\nQuesti 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\u00e9 ci basta questo?<\/p>\n<ol>\n<li>C'\u00e8 un fallback per i clienti nel caso in cui la nostra proxy non funzioni.<\/li>\n<li>Esiste un sistema di steering automatico che risponde ai problemi.<\/li>\n<\/ol>\n<p>\nParlando 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. <\/p>\n<p>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 \u00e8 rotto e se possiamo risolverlo automaticamente modificando il percorso della richiesta.<\/p>\n<p>Esempi:<\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto processo pu\u00f2 essere automatizzato. Integrare nel sistema di steering. E insegnare a reagire a problemi di prestazioni e affidabilit\u00e0. Se qualcosa inizia a guastarsi, reagire, se c'\u00e8 un'opzione migliore. In questo caso, la reazione istantanea non \u00e8 critica, grazie al fallback sui clienti.<\/p>\n<p>Pertanto, i principi di supporto del sistema possono essere formulati cos\u00ec:<\/p>\n<ul>\n<li>ridurre l'impatto dei guasti;<\/li>\n<li>raccogliere metriche;<\/li>\n<li>riparare i guasti automaticamente, se possibile;<\/li>\n<li>se non \u00e8 possibile, avvisare;<\/li>\n<li>lavorare su dashboards e toolset di triage per una reazione rapida.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Lezioni apprese<\/h2>\n<p>\nPer scrivere un prototipo non serve molto tempo. Nel nostro caso, era pronto gi\u00e0 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 \u00e8 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\u00e0 lineare: nonostante tutti gli sforzi, non si pu\u00f2 prevedere tutto. \u00c8 molto pi\u00f9 efficace iterare rapidamente e rispondere ai nuovi dati. <\/p>\n<p><img decoding=\"async\" alt=\"Accelera le richieste Internet e dormi sonni tranquilli.\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBasandoci sulla nostra esperienza, possiamo consigliare quanto segue:<\/p>\n<ol>\n<li>Non fidatevi dell'intuizione.\n<p>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.<\/li>\n<li>Ottieni dati dalla produzione.\n<p>\u00c8 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 \u00e8 praticamente impossibile. Un rapido accesso ai risultati permetter\u00e0 di conoscere prima le potenziali problematiche e di tenerle in considerazione nell'architettura del sistema.<\/li>\n<li>Non seguire i consigli e i risultati altrui: raccogli i tuoi dati.\n<p>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\u00f2 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 \u2014 poich\u00e9 abbiamo dispositivi, clienti e flussi di dati diversi.<\/li>\n<li>Non inseguire le mode senza necessit\u00e0 e senza una valutazione dell'efficacia.\n<p>Inizia con qualcosa di semplice. \u00c8 meglio creare un sistema funzionante e semplice in poco tempo, piuttosto che spendere un'enorme quantit\u00e0 di tempo nello sviluppo di componenti inutili. Risolvi compiti e problemi che sono importanti in base alle tue misurazioni e ai tuoi risultati. <\/li>\n<li>Sii pronto a nuove applicazioni.\n<p>Proprio come \u00e8 difficile prevedere tutti i problemi, \u00e8 altrettanto complesso anticipare i vantaggi e le applicazioni. Prendete esempio dalle startup: la loro capacit\u00e0 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:<\/p>\n<ul>\n<li>per bilanciare il traffico tra le regioni AWS e ridurre i costi;<\/li>\n<li>per modellare la stabilit\u00e0 del CDN;<\/li>\n<li>per configurare il DNS;<\/li>\n<li>per configurare TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Conclusione<\/h2>\n<p>\nNella 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\u00f9 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.<\/p>\n<p>Tuttavia, la nostra soluzione \u00e8 solo un esempio di come abbiamo implementato un sistema simile in Netflix. Ci\u00f2 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.<\/p>\n<p>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 \u00e8 significativamente diversa dalla nostra. <\/p>\n<p>Rimane anche l'importanza della velocit\u00e0 delle richieste per il business. E anche per un servizio semplice, \u00e8 necessario fare una scelta: tra fornitori 'cloud', posizione dei server, fornitori di CDN e DNS. La vostra scelta influenzer\u00e0 l'efficacia delle richieste internet per i vostri clienti. \u00c8 importante per voi misurare e comprendere questa influenza.<\/p>\n<p>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\u00e0. Pensate alla possibilit\u00e0 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.<\/p>\n<blockquote><p>Quest'anno <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">la conferenza si terr\u00e0 dal 6 al 10 luglio<\/a><\/noindex> in formato online. Sar\u00e0 possibile porre domande a uno dei padri del DevOps, il grande John Willis!<\/p><\/blockquote>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Accelera le richieste di Internet e dormi sereno | ProHoster","description":"Netflix \u2014 leader del mercato della televisione via Internet \u2014 \u00e8 l'azienda che ha creato e continua a sviluppare questo segmento. Netflix \u00e8 conosciuta non solo per il suo ampio catalogo di film e serie disponibili da quasi ogni angolo del pianeta e da qualsiasi dispositivo dotato di schermo, ma anche per la sua infrastruttura affidabile e la sua cultura ingegneristica unica. Esempi tangibili dell'approccio di Netflix allo sviluppo e al supporto di sistemi complessi sono stati presentati al DevOops 2019","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}