🥇Web-HighLoad: come gestiamo il traffico di decine di migliaia di domini

Il traffico legittimo nella rete DDoS-Guard ha recentemente superato cento gigabit al secondo. Attualmente, il 50% di tutto il nostro traffico è generato dai servizi web dei clienti. Si tratta di molte decine di migliaia di domini, molto diversi e che nella maggior parte dei casi richiedono un approccio personalizzato.

Di seguito — come gestiamo i nodi front-end e distribuiamo certificati SSL per centinaia di migliaia di siti.

Configurare un front-end per un singolo sito, anche se molto grande, è semplice. Prendiamo nginx o haproxy o lighttpd, lo configuriamo seguendo le guide e ce ne dimentichiamo. Se è necessario modificare qualcosa, facciamo un reload e di nuovo ce ne dimentichiamo.

Tutto cambia quando gestisci in tempo reale grandi volumi di traffico, valuti la legittimità 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ò 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.

Perché avere tanti grandi nodi affidabili in tutto il mondo?

La qualità del servizio del traffico dei clienti — le richieste dagli Stati Uniti devono essere elaborate proprio negli Stati Uniti (inclusi attacchi, parsing e altre anomalie), e non portate a Mosca o in Europa, aumentando imprevedibilmente la latenza di elaborazione.
Il traffico attaccante deve essere localizzato — gli operatori di transito possono degradare durante gli attacchi, il cui volume spesso supera 1Tbps. Trasportare il traffico attaccante attraverso collegamenti transatlantici o transasiatici non è la migliore idea. Abbiamo avuto casi reali in cui gli operatori Tier-1 hanno affermato: "I volumi di attacchi che state ricevendo sono per noi pericolosi". È proprio per questo che accettiamo i flussi in entrata il più vicino possibile alle loro fonti.
Severe requisiti di continuità del servizio: i centri di pulizia non devono dipendere l'uno dall'altro né da eventi locali del nostro mondo in rapido cambiamento. Sono rimasti senza elettricità per una settimana tutti i 11 piani del MMTS-9? — nessun problema. Nessun cliente senza un collegamento fisico in quella specifica località subirà conseguenze, e i servizi web non saranno interessati in nessun caso.

Come gestire tutto ciò?

Le configurazioni dei servizi devono essere distribuite a tutti i nodi front-end il più rapidamente possibile (idealmente in modo istantaneo). Non è 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).

Durante il riavvio della configurazione, è abbastanza normale osservare la seguente situazione:

Per quanto riguarda l'uso della memoria:

I vecchi worker consumano memoria, inclusa quella non necessariamente lineare al numero di connessioni, — è normale. Quando le connessioni dei client si chiudono, questa memoria verrà liberata.

Perché non era un problema quando nginx stava appena cominciando a svilupparsi? Non c'erano HTTP/2, WebSocket, né connessioni keep-alive lunghe e massicce. Il 70% del nostro traffico web è HTTP/2, e si tratta di connessioni molto lunghe.

La soluzione è 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ò non li rende meno transcontinentali.

Abbiamo un proprio server bilanciatore front-end, di cui parlerò nei prossimi articoli. La cosa principale che sa fare è applicare migliaia di modifiche alle configurazioni al secondo, al volo, senza riavvii, ricariche, picchi imprevisti nell'uso della memoria e tutto il resto. È 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 è già 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.

Questo stesso meccanismo ci consente di emettere e prolungare istantaneamente i certificati Let’s Encrypt. In modo molto semplificato funziona così:

Appena vediamo almeno una richiesta HTTPS per il dominio del nostro cliente senza certificato (o con certificato scaduto), il nodo esterno che ha ricevuto la richiesta informa il centro di certificazione interno.
Se l'utente non ha vietato l'emissione di Let’s Encrypt, il centro di certificazione genera CSR, riceve da LE un token di conferma e lo inoltra a tutti i front-end tramite canale crittografato. Ora qualsiasi nodo può confermare la richiesta di validazione da parte di LE.
Dopo pochi istanti riceveremo il certificato corretto e la chiave privata e li inoltreremo ai front-end. Di nuovo tutto senza riavviare i demoni.
Sette giorni prima della data di scadenza viene avviata la procedura di riottenimento del certificato.

Proprio adesso stiamo ruotando in tempo reale 350.000 certificati in modo del tutto trasparente per gli utenti.

Nei prossimi articoli del ciclo parlerò 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à 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.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.