![\"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, haproxy o lighttpd, ci seguiamo le guide e ci dimentichiamo. Se c'\u00e8 bisogno di apportare modifiche, facciamo un reload e ci dimentichiamo di nuovo.<\/p>\n Tutto cambia quando gestisci flussi di traffico massicci in tempo reale, valuti la legittimit\u00e0 delle richieste, comprimi e memorizzi nella cache i contenuti degli utenti, e cambi i parametri pi\u00f9 volte al secondo. L'utente vuole vedere il risultato su tutti i nodi esterni immediatamente dopo aver modificato le impostazioni nel proprio pannello. Inoltre, l'utente pu\u00f2 caricare tramite API migliaia (e a volte decine di migliaia) di domini con parametri di trattamento del traffico personalizzati. Tutto questo deve funzionare immediatamente sia in America che in Europa e Asia: si tratta di un compito non banale, considerando che solo a Mosca ci sono diversi nodi fisicamente distanziati per la filtrazione.<\/p>\n Le configurazioni dei servizi devono diffondersi il pi\u00f9 rapidamente possibile (idealmente istantaneamente) su tutti i nodi front-end. Non \u00e8 possibile semplicemente modificare i file di configurazione di testo e riavviare i demoni a ogni modifica: lo stesso nginx mantiene i processi in fase di conclusione (worker shutting down) per alcuni minuti (o anche ore, se ci sono sessioni websocket lunghe).<\/p>\n Durante il riavvio della configurazione, \u00e8 abbastanza normale osservare la seguente situazione:<\/p>\n Per quanto riguarda l'utilizzo della memoria:<\/p>\n I vecchi worker utilizzano memoria, anche se non in modo lineare rispetto al numero di connessioni, il che \u00e8 normale. Quando le connessioni dei clienti si chiudono, questa memoria verr\u00e0 liberata.<\/p>\n Perch\u00e9 questo non era un problema quando nginx era appena stato sviluppato? Non c'erano n\u00e9 HTTP\/2 n\u00e9 WebSocket, n\u00e9 connessioni keep-alive lunghe e numerose. Il 70% del nostro traffico web \u00e8 HTTP\/2, e queste sono connessioni molto lunghe.<\/p>\n La soluzione \u00e8 semplice: non utilizzare nginx, non gestire i front-end basandosi su file di testo e assolutamente non inviare configurazioni di testo compresse attraverso i canali transpacifici. I canali, chiaramente, sono garantiti e riservati, ma ci\u00f2 non li rende meno transcontinentali.<\/p>\n Abbiamo un nostro server-bilanciatore front-end, di cui parler\u00f2 nei prossimi articoli. La cosa principale \u00e8 che \u00e8 in grado di applicare migliaia di modifiche di configurazione al secondo in tempo reale, senza riavvii o reload, senza picchi nel consumo di memoria e tutto il resto. Questo \u00e8 molto simile al Hot Code Reload, ad esempio in Erlang. I dati sono memorizzati in un database key-value geograficamente distribuito e vengono letti immediatamente dai meccanismi esecutivi dei front-end. Ovvero, hai caricato un certificato SSL tramite interfaccia web o API a Mosca, e dopo pochi secondi \u00e8 gi\u00e0 pronto per l'uso nel nostro centro di pulizia a Los Angeles. Se dovesse scoppiare una guerra mondiale e Internet sparisse in tutto il mondo, i nostri nodi continueranno a funzionare in modo autonomo e riparano il divario di separazione, non appena diventa disponibile uno dei canali dedicati Los Angeles-Amsterdam-Mosca, Mosca-Amsterdam-Hong Kong-Los Angeles, o perlomeno uno dei canali di riserva overlay GRE.<\/p>\n Questo stesso meccanismo ci permette di rilasciare e rinnovare immediatamente certificati Let's Encrypt.<\/a> Funziona in modo molto semplificato cos\u00ec:<\/p>\n In questo momento stiamo ruotando in tempo reale 350.000 certificati in modo del tutto trasparente per gli utenti.<\/p>\n Nei prossimi articoli di questa serie parler\u00f2 di altre caratteristiche del processamento in tempo reale di un grande traffico web \u2014 ad esempio, dell'analisi del RTT su dati incompleti per migliorare la qualit\u00e0 del servizio ai clienti di transito e in generale sulla protezione del traffico di transito da attacchi di terabit, sulla fornitura e aggregazione delle informazioni sul traffico, sul WAF, su una CDN quasi illimitata e su una moltitudine di meccanismi di ottimizzazione della consegna dei contenuti.<\/p>\n Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a>, per favore.<\/p>\nPerch\u00e9 avere numerosi e robusti nodi 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>\nCosa vorreste sapere innanzitutto?<\/h2>\n