Il traffico legittimo nella rete DDoS-Guard ha recentemente superato i cento gigabit al secondo. Attualmente, il 50% del nostro traffico è generato dai servizi web dei clienti. Si tratta di decine di migliaia di domini, molto diversi tra loro e, nella maggior parte dei casi, richiedenti un approccio personalizzato.
Di seguito spiegheremo come gestiamo i nodi front-end e distribuiamo Certificati SSL per centinaia di migliaia di siti web.
Configurare un front-end per un singolo sito, anche se molto grande, è semplice. Prendiamo nginx, haproxy o lighttpd, ci seguiamo le guide e ci dimentichiamo. Se c'è bisogno di apportare modifiche, facciamo un reload e ci dimentichiamo di nuovo.
Tutto cambia quando gestisci flussi di traffico massicci in tempo reale, valuti la legittimità delle richieste, comprimi e memorizzi nella cache i contenuti degli utenti, e cambi i parametri più 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ò 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.
Perché avere numerosi e robusti nodi in tutto il mondo?
- La qualità del servizio per il traffico dei clienti è fondamentale: le richieste dagli Stati Uniti devono essere elaborate negli Stati Uniti (inclusi gli attacchi, il parsing e altre anomalie), piuttosto che essere riportate a Mosca o in Europa, aumentando in modo imprevedibile il ritardo di elaborazione.
- Il traffico di attacco deve essere localizzato: gli operatori di transito possono degradare durante gli attacchi, i cui volumi spesso superano 1 Tbps. Trasportare il traffico di attacco attraverso linee transatlantiche o transasiatiche non è una buona idea. Abbiamo avuto casi reali in cui operatori Tier-1 hanno affermato: "I volumi di attacco che ricevete sono per noi pericolosi". È proprio per questo motivo che accettiamo i flussi in ingresso il più vicino possibile alle loro fonti.
- Severe esigenze di continuità del servizio: i centri di pulizia non devono dipendere l'uno dall'altro o da eventi locali nel nostro mondo in rapido cambiamento. Se si interrompono l'elettricità per una settimana a tutti gli 11 piani del MMTS-9? Non è un problema. Nessun cliente subirà conseguenze se non è fisicamente connesso a quella locazione e i servizi web non subiranno danni in nessuna circostanza.
Come gestire tutto ciò?
Le configurazioni dei servizi devono diffondersi il più rapidamente possibile (idealmente istantaneamente) su tutti i nodi front-end. Non è 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).
Durante il riavvio della configurazione, è abbastanza normale osservare la seguente situazione:
Per quanto riguarda l'utilizzo della memoria:
I vecchi worker utilizzano memoria, anche se non in modo lineare rispetto al numero di connessioni, il che è normale. Quando le connessioni dei clienti si chiudono, questa memoria verrà liberata.
Perché questo non era un problema quando nginx era appena stato sviluppato? Non c'erano né HTTP/2 né WebSocket, né connessioni keep-alive lunghe e numerose. Il 70% del nostro traffico web è HTTP/2, e queste sono connessioni molto lunghe.
La soluzione è 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ò non li rende meno transcontinentali.
Abbiamo un nostro server-bilanciatore front-end, di cui parlerò nei prossimi articoli. La cosa principale è che è 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 è 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 è già 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.
Questo stesso meccanismo ci permette di rilasciare e rinnovare immediatamente certificati Let’s Encrypt. Funziona in modo molto semplificato così:
- Non 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 da Let’s Encrypt, il centro di certificazione genera un CSR, ottiene un token di conferma da LE e lo distribuisce a tutti i fronti tramite un canale crittografato. Ora qualsiasi nodo può confermare la richiesta di validazione da LE.
- Dopo pochi istanti riceveremo un certificato valido e una chiave privata e li distribuirà nuovamente ai fronti. Ancora una volta, senza riavviare i demoni.
- Sette giorni prima della data di scadenza, inizia la procedura di riottenimento del certificato.
In questo momento stiamo ruotando in tempo reale 350.000 certificati in modo del tutto trasparente per gli utenti.
Nei prossimi articoli di questa serie parlerò di altre caratteristiche del processamento in tempo reale di un grande traffico web — ad esempio, dell'analisi del RTT su dati incompleti per migliorare la qualità 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.
Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.
Cosa vorreste sapere innanzitutto?
- 14,3%Algoritmi di clustering e analisi della qualità del traffico web<3
- 33,3%Interni dei bilanciatori DDoS-Guard7
- 9,5%Protezione del traffico L3/L4 transitivo2
- 0,0%Protezione dei siti web sul traffico di transito0
- 14,3%Web Application Firewall3
- 28,6%Protezione da scraping e click fraud6
Ha votato 21 utenti. 6 utenti si sono astenuti.
Fonte: habr.com
