![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/5e4fece0f5039f0fb1af5ead9e0e0089.jpg\")
<\/p>\n
<\/a><\/p>\n Configurare un front-end per un singolo sito, anche se molto grande, \u00e8 semplice. Prendiamo nginx o haproxy o lighttpd, lo configuriamo seguendo le guide e ce ne dimentichiamo. Se \u00e8 necessario modificare qualcosa, facciamo un reload e di nuovo ce ne dimentichiamo.<\/p>\n Tutto cambia quando gestisci in tempo reale grandi volumi di traffico, valuti la legittimit\u00e0 delle richieste, comprimi e memorizzi nella cache il contenuto degli utenti, e allo stesso tempo modifichi i parametri diverse volte al secondo. L'utente vuole vedere il risultato su tutti i nodi esterni subito dopo aver modificato le impostazioni nel proprio pannello. Inoltre, l'utente pu\u00f2 caricare tramite API diverse migliaia (talvolta anche decine di migliaia) di domini con parametri di elaborazione del traffico personalizzati. Tutto questo deve funzionare immediatamente sia in America, che in Europa e in Asia: un compito non banale, considerando che solo a Mosca ci sono diversi nodi di filtraggio fisicamente distanti.<\/p>\n Le configurazioni dei servizi devono essere distribuite a tutti i nodi front-end il pi\u00f9 rapidamente possibile (idealmente in modo istantaneo). Non \u00e8 possibile semplicemente modificare i file di configurazione testuali e riavviare i demoni a ogni cambiamento: lo stesso nginx mantiene i processi in chiusura (worker shutting down) per alcuni minuti (e potrebbero essere anche ore se ci sono sessioni websocket prolungate).<\/p>\n Durante il riavvio della configurazione, \u00e8 abbastanza normale osservare la seguente situazione:<\/p>\n Per quanto riguarda l'uso della memoria:<\/p>\n I vecchi worker consumano memoria, inclusa quella non necessariamente lineare al numero di connessioni, \u2014 \u00e8 normale. Quando le connessioni dei client si chiudono, questa memoria verr\u00e0 liberata.<\/p>\n Perch\u00e9 non era un problema quando nginx stava appena cominciando a svilupparsi? Non c'erano HTTP\/2, WebSocket, n\u00e9 connessioni keep-alive lunghe e massicce. Il 70% del nostro traffico web \u00e8 HTTP\/2, e si tratta di connessioni molto lunghe.<\/p>\n La soluzione \u00e8 semplice: non usare nginx, non gestire i front-end basandosi su file di testo, e di certo non inviare configurazioni testuali compressi attraverso i canali trans-oceanici. I canali sono, ovviamente, garantiti e riservati, ma ci\u00f2 non li rende meno transcontinentali.<\/p>\n Abbiamo un proprio server bilanciatore front-end, di cui parler\u00f2 nei prossimi articoli. La cosa principale che sa fare \u00e8 applicare migliaia di modifiche alle configurazioni al secondo, al volo, senza riavvii, ricariche, picchi imprevisti nell'uso della memoria e tutto il resto. \u00c8 molto simile al Hot Code Reload, ad esempio in Erlang. I dati sono memorizzati in un database key-value geo-distribuito e vengono letti immediatamente dai meccanismi esecutivi front-end. Ovvero, hai caricato un certificato SSL tramite interfaccia web o API a Mosca, e dopo pochi secondi \u00e8 gi\u00e0 pronto per essere utilizzato nel nostro centro di pulizia a Los Angeles. Se improvvisamente scoppiasse una guerra mondiale e Internet scomparisse in tutto il mondo, i nostri nodi continuerebbero a funzionare in modo autonomo e riparerebbero il split-brain, non appena uno dei canali dedicati Los Angeles-Amsterdam-Mosca, Mosca-Amsterdam-Hong Kong-Los Angeles, o almeno uno dei canali di sovrapposizione di riserva, diventa disponibile.<\/p>\n Questo stesso meccanismo ci consente di emettere e prolungare istantaneamente certificati Let\u2019s Encrypt.<\/a> In modo molto semplificato funziona cos\u00ec:<\/p>\n Proprio adesso stiamo ruotando in tempo reale 350.000 certificati in modo del tutto trasparente per gli utenti.<\/p>\n Nei prossimi articoli del ciclo parler\u00f2 di altre caratteristiche dell'elaborazione in tempo reale di un grande traffico web, ad esempio, dell'analisi RTT su dati incompleti per migliorare la qualit\u00e0 del servizio ai clienti in transito e in generale della protezione del traffico in transito da attacchi terabit, della consegna e aggregazione delle informazioni sul traffico, del WAF, di una CDN quasi illimitata e di molti meccanismi per ottimizzare la resa dei contenuti.<\/p>\n Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a>, per favore.<\/p>\nPerch\u00e9 avere tanti grandi nodi affidabili in tutto il mondo?<\/h3>\n
\n
Come gestire tutto ci\u00f2?<\/h3>\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/6a1ffc01ad9bac1e51d46c3130ea2a37.jpg\")
<\/p>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/d356134b0866b8c92a3d5f7a3a8df208.jpg\")
<\/p>\n\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/20830ee7c4ea57ec1d0833f0bc25412d.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/1c8b295065f27c1b69c810ff74ce4018.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/e4fc349089fbf7cbe7824ea539865daf.jpg\")
<\/li>\nDi cosa ti piacerebbe sapere prima di tutto?<\/h2>\n