{"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 su internet, un'azienda che ha creato e sviluppa attivamente questo segmento. Netflix \u00e8 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. <\/p>\n<p>Un chiaro esempio dell'approccio di Netflix allo sviluppo e al supporto di sistemi complessi \u00e8 stato presentato <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Serghiei F\u00ebdorov<\/a><\/noindex> \u2014 direttore dello sviluppo in Netflix. Laureato nella facolt\u00e0 di VMC dell'Universit\u00e0 di N.N. Lobac\u00ebvski, Serghiei \u00e8 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\u00e0 della connessione Internet FAST.com e negli ultimi anni si \u00e8 concentrato sull'ottimizzazione delle richieste Internet per garantire che l'applicazione Netflix funzioni il pi\u00f9 velocemente possibile per gli utenti.<\/p>\n<p>La presentazione ha ricevuto ottime opinioni dai partecipanti alla conferenza e abbiamo preparato per voi una 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=\"Guarda il 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>Nel suo intervento, Serghiei ha parlato in dettaglio<\/h2>\n<p><\/p>\n<ul>\n<li>di che cosa influisce sui tempi di latenza delle richieste Internet tra client e server;<\/li>\n<li>di come ridurre questa latenza;<\/li>\n<li>di come progettare, mantenere e monitorare sistemi resilienti agli errori;<\/li>\n<li>di come raggiungere risultati in tempi brevi, con il minor rischio possibile per il business;<\/li>\n<li>di come analizzare i risultati e imparare dagli errori.<\/li>\n<\/ul>\n<p>\nLe risposte a queste domande sono necessarie non solo a chi lavora in grandi aziende. <\/p>\n<p>I principi e le tecniche presentati devono essere conosciuti e praticati da chiunque sviluppi e mantenga prodotti internet.<\/p>\n<p><b>Di seguito \u2014 una narrazione dalla voce del relatore.<\/b><\/p>\n<h2>L'importanza della velocit\u00e0 di internet<\/h2>\n<p>\nLa velocit\u00e0 delle richieste internet \u00e8 strettamente legata al business. Consideriamo il settore dello shopping: nel 2009, la societ\u00e0 Amazon <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">ha affermato<\/a><\/noindex>, che un ritardo di 100 ms porta a una perdita dell'1% delle vendite.<\/p>\n<p>Ci sono sempre pi\u00f9 dispositivi mobili, e con essi sempre pi\u00f9 siti e applicazioni mobili. Se la tua pagina impiega pi\u00f9 di 3 secondi a caricarsi, perdi circa la met\u00e0 degli utenti. Dal <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">luglio 2018<\/a><\/noindex> , Google considera la velocit\u00e0 di caricamento della tua pagina nei risultati di ricerca: pi\u00f9 veloce \u00e8 la pagina, migliore \u00e8 la sua posizione su Google.<\/p>\n<p>La velocit\u00e0 di connessione \u00e8 importante anche nelle organizzazioni finanziarie, dove la latenza \u00e8 critica. Nel 2015, la societ\u00e0 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 concluso<\/a><\/noindex> un cavo tra New York e Londra del valore di 400 milioni di dollari, per ridurre il ritardo tra le citt\u00e0 di 6 ms. Immaginate, 66 milioni di dollari per ogni millisecondo 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 della connessione sopra i 5 Mbit\/s smette di influenzare direttamente la velocit\u00e0 di caricamento di un sito web standard. Tuttavia, tra il ritardo di connessione e la velocit\u00e0 di caricamento della pagina si osserva una dipendenza lineare:<\/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 standard. L'impatto del ritardo e della velocit\u00e0 sull'utente \u00e8 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\u00e0 della connessione. L'analisi e l'ottimizzazione dei fattori chiave che influenzano la qualit\u00e0 del servizio per l'utente sono un'area attiva di sviluppo per 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 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.<\/p>\n<h2>Dentro Netflix<\/h2>\n<p>\nMigliaia di dispositivi diversi supportano le applicazioni Netflix. Il loro sviluppo \u00e8 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.<\/p>\n<p>La personalizzazione \u00e8 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\u00ec:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link al video con la dimostrazione (6:04-6:23)<\/a><\/noindex><\/p>\n<p>A sinistra si trova il punto d'entrata, dopodich\u00e9 il traffico viene distribuito tra diverse centinaia di microservizi, supportati da diversi team di backend.<\/p>\n<p>Un altro componente importante della nostra infrastruttura \u00e8 Open Connect CDN, che consegna contenuti statici agli utenti finali, come video, immagini, codice per i client, ecc. La CDN \u00e8 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\u00f9 informazioni possibile agli utenti. <\/p>\n<p>La \"parete\" di questi server nel punto di scambio del traffico internet (Internet eXchange - 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 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:<\/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 propria 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 per la gestione delle richieste video dai client ai server CDN, cos\u00ec come per la configurazione stessa dei server \u2014 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.<\/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\">stime Sandvine<\/a><\/noindex>, la nostra infrastruttura CDN consegna durante le ore di punta circa \u215b del traffico internet mondiale e \u2153 del traffico in Nord America, dove Netflix esiste da pi\u00f9 tempo. Numeri impressionanti, ma per me uno dei risultati pi\u00f9 straordinari \u00e8 che l'intero sistema CDN \u00e8 sviluppato e mantenuto da un team di meno di 150 persone.<\/p>\n<p>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.<\/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. 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 \u00e8 possibile memorizzare nella cache queste richieste: 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>Materie prime<\/h2>\n<p>\nRicordiamo 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\u00ec che il cliente si connetta al server, \u00e8 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\u00f9 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:<\/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, il tempo di \"stretta di mano\" tra il cliente e il server pu\u00f2 essere notevolmente ridotto se il CDN \u00e8 pi\u00f9 vicino. Supponiamo che la latenza verso il server CDN sia di 30 ms. Allora per ottenere il primo bit avremo bisogno di 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 si fermano qui. Dopo che la connessione \u00e8 stata stabilita, TCP aumenta la congestion window (la quantit\u00e0 di informazioni che pu\u00f2 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\u00e0. La crescita della congestion window e la velocit\u00e0 del suo recupero dalla perdita dipendono nuovamente dalla latenza (RTT) verso il server. Se questa connessione va solo al server CDN, il recupero sar\u00e0 pi\u00f9 veloce. 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, soprattutto durante le ore di punta a causa del traffico degli utenti, il che pu\u00f2 portare a \"ingorghi\". Tuttavia, su internet non esiste un metodo per dare priorit\u00e0 a certe richieste rispetto ad altre. Ad esempio, dare priorit\u00e0 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\u2014tra 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\u00f9 tardi. Pi\u00f9 vicino \u00e8 il CDN al cliente, maggiore \u00e8 l'efficienza.<\/p>\n<p>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'\u00e8 un controllo completo e la possibilit\u00e0 di usare protocolli e impostazioni nuovi e ottimali. La parte inefficiente con i vecchi protocolli agir\u00e0 solo tra il cliente e il server CDN. Inoltre, possiamo effettuare il multiplexing delle richieste su una connessione gi\u00e0 stabilita tra CDN e 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>\nSebbene la teoria prometta miglioramenti, non ci affrettiamo a lanciare il sistema in produzione. 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>: sar\u00e0 il proxy pi\u00f9 veloce?<\/li>\n<li><b>Affidabilit\u00e0<\/b>: si romper\u00e0 pi\u00f9 spesso?<\/li>\n<li><b>Complessit\u00e0<\/b>: come integrare con le applicazioni?<\/li>\n<li><b>Prezzo<\/b>: quanto costa implementare un'infrastruttura aggiuntiva?<\/li>\n<\/ul>\n<p>\nEsaminiamo in dettaglio il nostro approccio per valutare il 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 rompere la produzione. Per questo 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 molti fattori, ad esempio, a causa delle diverse dimensioni delle richieste, del tempo di elaborazione lato server e lato client. Inoltre, non \u00e8 possibile testare una nuova configurazione senza effetti sulla produzione.<\/li>\n<li>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'\u00e8 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).<\/li>\n<\/ol>\n<p>\nCome \u00e8 possibile combinare i vantaggi di entrambi i metodi?<\/p>\n<p>Il nostro team ha trovato una soluzione. Abbiamo scritto un piccolo pezzo di codice \u2014 una prova \u2014 che abbiamo integrato nella nostra applicazione. Le prove ci consentono di effettuare test di rete completamente controllabili dai nostri dispositivi. Funziona nel modo seguente: <\/p>\n<ol>\n<li>Subito dopo il caricamento dell'applicazione e il completamento delle attivit\u00e0 iniziali, avviamo le nostre prove. <\/li>\n<li>Il cliente fa una richiesta al server e riceve una \"ricetta\" per il test. La ricetta \u00e8 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 \u2014 per la richiesta di configurazione determiniamo casualmente quale ricetta fornire. <\/li>\n<li>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 \u00e8 attivo.<\/li>\n<li>Dopo aver ricevuto la ricetta, il cliente effettua richieste a ciascuno degli URL, parallelamente. La richiesta a ciascuno degli indirizzi pu\u00f2 essere ripetuta \u2014 i cosiddetti \"pulsanti\". Nel primo impulso misuriamo quanto tempo ci \u00e8 voluto per stabilire la connessione e scaricare i dati. Nel secondo impulso misuriamo il tempo di caricamento dei dati su una connessione gi\u00e0 stabilita. Prima del terzo possiamo impostare un ritardo e misurare la velocit\u00e0 di stabilimento della connessione ripetuta, ecc.\n<p>Durante il test misuriamo tutti i parametri che il dispositivo pu\u00f2 acquisire:<\/p>\n<ul>\n<li>tempo della richiesta DNS;<\/li>\n<li>tempo di stabilizzazione della connessione TCP;<\/li>\n<li>tempo di stabilizzazione 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 cicli, 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'influenza di vari fattori sulle prestazioni delle richieste, variandoli all'interno di una singola configurazione 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 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.<\/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 sulle latenze delle richieste. Ora \u00e8 necessario:<\/p>\n<ul>\n<li>creare un prototipo di proxy;<\/li>\n<li>disporre il prototipo sul CDN;<\/li>\n<li>definire come indirizzare i client verso il 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 l'efficacia della soluzione proposta il pi\u00f9 rapidamente possibile. Per implementare il prototipo abbiamo scelto Go, grazie alla disponibilit\u00e0 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.<\/p>\n<p>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 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">la stessa logica<\/a><\/noindex>, secondo la quale i clienti vengono indirizzati ai fornitori di servizi Internet per lo streaming video.<\/p>\n<p>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 \u00e8 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:<\/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 \/>\nOgni 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:<\/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 ambigui\u2014nella maggior parte dei casi il proxy fornisce un buon aumento di velocit\u00e0, ma ci sono anche un numero sufficiente di clienti per i quali la situazione peggiorer\u00e0 significativamente. <\/p>\n<p>In definitiva, abbiamo fatto alcune cose importanti:<\/p>\n<ol>\n<li>Abbiamo valutato le prestazioni attese delle richieste dai clienti verso il cloud attraverso il proxy CDN.<\/li>\n<li>Abbiamo ottenuto dati da clienti reali, da tutti i tipi di dispositivi.<\/li>\n<li>Abbiamo capito che la teoria non si \u00e8 confermata al 100% e che la nostra proposta iniziale con il proxy CDN non funzioner\u00e0.<\/li>\n<li>Non abbiamo preso rischi\u2014non abbiamo modificato le configurazioni 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\u2014anzich\u00e9 un proxy al 100%, per ogni cliente definiamo il percorso pi\u00f9 veloce e indirizziamo le richieste verso di esso\u2014quindi faremo ci\u00f2 che si chiama 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 questo server. Dobbiamo fare in qualche modo questo sul client. E idealmente, farlo con la minima quantit\u00e0 di logica complessa, per 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 la nostra infrastruttura DNS e possiamo configurare una zona di dominio per la quale i nostri server saranno autoritativi. Funziona in questo modo:<\/p>\n<ol>\n<li>Il client effettua una richiesta al server DNS utilizzando un 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 client e fornisce l'indirizzo IP corrispondente. <\/li>\n<\/ol>\n<p>\nNella soluzione c'\u00e8 una complessit\u00e0 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. <\/p>\n<p>Di conseguenza, il nostro resolver autoritativo deve prendere decisioni non per un singolo client, ma per un gruppo di client basate sul resolver ricorsivo. <\/p>\n<p>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.<\/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 di DNS steering ottenuto consente di indirizzare i client sulla base di osservazioni storiche sulla velocit\u00e0 delle connessioni dai client al cloud. <\/p>\n<p>Ancora una volta, la questione \u00e8: quanto sar\u00e0 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).<\/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 scoperto alcune cose importanti:<\/p>\n<ol>\n<li>Abbiamo valutato le prestazioni attese delle richieste dai client al cloud utilizzando DNS Steering.<\/li>\n<li>Abbiamo ottenuto dati da clienti reali, da tutti i tipi di dispositivi.<\/li>\n<li>Abbiamo dimostrato l'efficacia dell'idea proposta.<\/li>\n<li>Non abbiamo preso rischi\u2014non abbiamo modificato le configurazioni di produzione per i clienti.<\/li>\n<li>Non abbiamo rotto nulla.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Ora la parte difficile: avviamo in produzione<\/h2>\n<p>\nIl pi\u00f9 facile \u00e8 ora alle spalle: abbiamo un prototipo funzionante. La parte difficile \u00e8 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\u00f2 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. <\/p>\n<p>E nonostante tutto questo, nel team ci sono 3 ingegneri responsabili dello sviluppo, del deployment e del completo supporto del sistema.<\/p>\n<p>Pertanto, continueremo a parlare di sonno tranquillo e sano.<\/p>\n<p>Come continuare a sviluppare senza spendere tutto il tempo nella manutenzione? La nostra strategia si basa su 3 principi:<\/p>\n<ol>\n<li>Riduciamo il potenziale impatto dei guasti (blast radius). <\/li>\n<li>Ci prepariamo alle sorprese: ci aspettiamo che qualcosa si rompa, nonostante i test e l\u2019esperienza personale.<\/li>\n<li>Degradazione graduale (graceful degradation) \u2014 se qualcosa non funziona, deve ripararsi automaticamente, anche se non nel modo pi\u00f9 efficiente.<\/li>\n<\/ol>\n<p>\nSi \u00e8 scoperto che, con questo approccio al problema, \u00e8 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.<\/p>\n<p>Naturalmente, nonostante il fallback, seguiamo una chiara disciplina nel processo di sviluppo:<\/p>\n<ol>\n<li>Test di campionamento.<\/li>\n<li>Test A\/B o Canaries.<\/li>\n<li>Rilascio graduale (progressive rollout).<\/li>\n<\/ol>\n<p>\nPer quanto riguarda il campionamento, l'approccio \u00e8 stato descritto: le modifiche vengono inizialmente testate utilizzando una ricetta configurata.<\/p>\n<p>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:<\/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 \/>\nPoi 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:<\/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 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.<\/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 possibili componenti: <\/p>\n<ul>\n<li>dai client - numero di sessioni e richieste, tassi di fallback; <\/li>\n<li>proxy - statistiche sul numero e il tempo delle richieste;<\/li>\n<li>DNS - numero e risultati delle richieste;<\/li>\n<li>cloud edge - 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 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 \u00e8 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, \u00e8 molto probabile che saremo coinvolti. Pertanto, dobbiamo sapere chiaramente come identificare, raccogliere e analizzare le metriche per una rapida localizzazione dei problemi. <\/p>\n<p>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:<\/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 fare triage dei problemi utilizziamo un nostro sistema real-time open source <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. Memorizza metriche aggregate in memoria, \u00e8 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.<\/p>\n<p>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\u00e0 con un team specifico sulla diagnostica \u2014 da decine di minuti a diverse ore.<\/p>\n<p>Anche se la diagnostica viene eseguita rapidamente, non vogliamo che accada spesso. In un caso ideale, 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 ci 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. 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\u00e9 ci basta?<\/p>\n<ol>\n<li>C'\u00e8 un client fallback nel caso in cui il nostro proxy non funzioni.<\/li>\n<li>C'\u00e8 un sistema di gestione automatica che reagisce ai problemi.<\/li>\n<\/ol>\n<p>\nParliamo 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. <\/p>\n<p>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 \u00e8 rotto, e se possiamo ripararlo 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. Integrarlo nel sistema di gestione. E insegnargli a reagire ai problemi di prestazioni e affidabilit\u00e0. Se qualcosa inizia a guastarsi \u2014 deve reagire, se c'\u00e8 un'opzione migliore. In questo caso, una reazione immediata non \u00e8 critica, grazie al fallback sui client.<\/p>\n<p>In questo modo, i principi di supporto del sistema possono essere riassunti cos\u00ec:<\/p>\n<ul>\n<li>riduciamo l'entit\u00e0 dei guasti;<\/li>\n<li>raccogliamo metriche;<\/li>\n<li>ripariamo automaticamente i guasti, se possiamo;<\/li>\n<li>se non possiamo \u2014 notifichiamo;<\/li>\n<li>stiamo lavorando su dashboard e triage toolset 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 di produzione. Poi \u00e8 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\u00e0 lineare: nonostante i diversi sforzi, non si pu\u00f2 prevedere tutto. \u00c8 molto pi\u00f9 efficace una rapida iterazione e reazione 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 sottovalutato il previsto accelerazione dall'utilizzo della CDN proxy, o il comportamento del TCP Anycast.<\/li>\n<li>Raccogliete dati dalla produzione.\n<p>\u00c8 importante avere accesso il prima possibile a un numero anche ridotto di dati di produzione. \u00c8 praticamente impossibile ottenere il numero unico di casi, configurazioni, impostazioni in condizioni di laboratorio. Un rapido accesso ai risultati consentir\u00e0 di scoprire pi\u00f9 rapidamente potenziali problemi e di tenerli in considerazione nell'architettura del sistema.<\/li>\n<li>Non seguite i consigli e i risultati altrui: raccogliete i vostri dati.\n<p>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\u00f2 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 \u2014 perch\u00e9 abbiamo dispositivi, clienti e flussi di dati diversi.<\/li>\n<li>Non inseguite le tendenze senza motivo e senza valutare l'efficacia.\n<p>Iniziate con qualcosa di semplice. \u00c8 meglio realizzare un sistema semplice e funzionante in poco tempo piuttosto che spendere un'enorme quantit\u00e0 di tempo nello sviluppo di componenti non necessari. Affrontate le sfide e i problemi che sono importanti sulla base delle vostre misurazioni e risultati. <\/li>\n<li>Siate pronti a nuove applicazioni.\n<p>Cos\u00ec come \u00e8 difficile prevedere tutti i problemi, \u00e8 difficile anticipare i vantaggi e le applicazioni. Prendete esempio dalle startup: la loro capacit\u00e0 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:<\/p>\n<ul>\n<li>per il bilanciamento del traffico tra le regioni AWS e per ridurre i costi;<\/li>\n<li>per modellare la stabilit\u00e0 della CDN;<\/li>\n<li>per la configurazione del DNS;<\/li>\n<li>per la configurazione di TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Conclusione<\/h2>\n<p>\nNel 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\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 noi di Netflix abbiamo implementato un tale sistema. Ci\u00f2 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.<\/p>\n<p>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. <\/p>\n<p>Rimane anche l'importanza della velocit\u00e0 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\u00e0 sull'efficienza delle richieste internet per i vostri clienti. E per voi \u00e8 importante misurare e comprendere quest'impatto.<\/p>\n<p>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\u00e0 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.<\/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 di DevOps, il stesso 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 5.0.1.1 - 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.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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 internet e dormi tranquillo | ProHoster","description":"Netflix \u00e8 il leader di mercato della televisione via internet.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}