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

Il traffico legittimo sulla rete DDoS-Guard ha recentemente superato i 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 ambiti, molto diversi tra loro e che nella maggior parte dei casi richiedono un approccio individuale.

Sotto il taglio è riportato il modo in cui gestiamo i nodi frontali ed emettiamo certificati SSL per centinaia di migliaia di siti.

Creare una facciata per un sito, anche molto grande, è facile. Prendiamo nginx o haproxy o lighttpd, lo configuriamo secondo le guide e ce ne dimentichiamo. Se dobbiamo cambiare qualcosa, ricarichiamo e dimentichiamo di nuovo.

Tutto cambia quando si elaborano al volo grandi volumi di traffico, si valuta la legittimità delle richieste, si comprimono e si memorizzano nella cache i contenuti degli utenti e allo stesso tempo si modificano i parametri più volte al secondo. L'utente desidera vedere il risultato su tutti i nodi esterni immediatamente dopo aver modificato le impostazioni nel proprio account personale. Un utente può anche scaricare diverse migliaia (e talvolta decine di migliaia) di domini con parametri di elaborazione del traffico individuali tramite l'API. Tutto ciò dovrebbe funzionare immediatamente anche in America, in Europa e in Asia: il compito non è dei più banali, considerando che solo a Mosca ci sono diversi nodi di filtraggio fisicamente separati.

Perché ci sono molti grandi nodi affidabili in tutto il mondo?

• Qualità del servizio per il traffico dei clienti: le richieste provenienti dagli Stati Uniti devono essere elaborate negli Stati Uniti (compresi attacchi, analisi e altre anomalie) e non trasferite a Mosca o in Europa, aumentando in modo imprevedibile il ritardo di elaborazione.

• Il traffico degli attacchi deve essere localizzato: gli operatori di transito possono degradarsi durante gli attacchi, il cui volume spesso supera 1 Tbps. Trasportare il traffico degli attacchi su collegamenti transatlantici o transasiatici non è una buona idea. Abbiamo avuto casi reali in cui gli operatori di livello 1 hanno affermato: “Il volume di attacchi che ricevete è pericoloso per noi”. Ecco perché accettiamo i flussi in arrivo il più vicino possibile alle loro fonti.

• Requisiti rigorosi per la continuità del servizio: i centri di pulizia non dovrebbero dipendere né gli uni dagli altri né dagli eventi locali nel nostro mondo in rapida evoluzione. Hai interrotto l'alimentazione a tutti gli 11 piani dell'MMTS-9 per una settimana? - Nessun problema. Nessun cliente che non disponga di una connessione fisica in questa particolare posizione ne soffrirà, e i servizi web non ne soffriranno in nessuna circostanza.

Come gestire tutto questo?

Le configurazioni del servizio dovrebbero essere distribuite a tutti i nodi frontali il più rapidamente possibile (idealmente istantaneamente). Non puoi semplicemente prendere e ricostruire le configurazioni di testo e riavviare i demoni ad ogni modifica: lo stesso nginx mantiene i processi chiusi (spegnimento del lavoratore) per qualche minuto in più (o forse ore se ci sono lunghe sessioni websocket).

Quando si ricarica la configurazione di nginx, la seguente immagine è abbastanza normale:

Sull'utilizzo della memoria:

I vecchi lavoratori divorano memoria, inclusa la memoria che non dipende linearmente dal numero di connessioni: questo è normale. Quando le connessioni client vengono chiuse, questa memoria verrà liberata.

Perché questo non era un problema quando nginx era appena iniziato? Non c'erano HTTP/2, né WebSocket, né enormi connessioni keep-alive a lungo termine. Il 70% del nostro traffico web è HTTP/2, il che significa connessioni molto lunghe.

La soluzione è semplice: non utilizzare nginx, non gestire fronti basati su file di testo e certamente non inviare configurazioni di testo compresse su canali transpacifici. I canali sono, ovviamente, garantiti e riservati, ma questo non li rende meno transcontinentali.

Abbiamo il nostro bilanciatore front server, dei cui interni parlerò nei seguenti articoli. La cosa principale che può fare è applicare al volo migliaia di modifiche alla configurazione al secondo, senza riavvii, ricaricamenti, aumenti improvvisi del consumo di memoria e tutto il resto. Questo è molto simile a Hot Code Reload, ad esempio in Erlang. I dati vengono archiviati in un database di valori-chiave geo-distribuito e vengono letti immediatamente dagli attuatori anteriori. Quelli. carichi il certificato SSL tramite l'interfaccia web o l'API a Mosca e in pochi secondi è pronto per essere inviato al 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 lavorare in modo autonomo e a riparare il cervello diviso non appena uno dei canali dedicati Los Angeles-Amsterdam-Mosca, Mosca-Amsterdam-Hong Kong- Los-Los diventa disponibile, Angeles o almeno uno degli overlay di backup GRE.

Questo stesso meccanismo ci consente di emettere e rinnovare istantaneamente i certificati Let's Encrypt. Molto semplicemente funziona così:

1. Non appena vediamo almeno una richiesta HTTPS per il dominio del nostro cliente senza certificato (o con certificato scaduto), il nodo esterno che ha accettato la richiesta lo segnala all'autorità di certificazione interna.

   

2. Se l'utente non ha vietato l'emissione di Let's Encrypt, l'autorità di certificazione genera un CSR, riceve un token di conferma da LE e lo invia a tutti i fronti su un canale crittografato. Ora qualsiasi nodo può confermare una richiesta di convalida da LE.

   

3. In pochi istanti riceveremo il certificato e la chiave privata corretti e li invieremo ai fronti con la stessa modalità. Ancora una volta, senza riavviare i demoni

   

4. 7 giorni prima della data di scadenza viene avviata la procedura per la nuova ricezione del certificato

In questo momento stiamo ruotando 350 certificati in tempo reale, in modo completamente trasparente per gli utenti.

Nei seguenti articoli della serie parlerò di altre funzionalità dell'elaborazione in tempo reale di un grande traffico web, ad esempio dell'analisi di RTT utilizzando dati incompleti per migliorare la qualità del servizio per i clienti di transito e in generale della protezione del traffico di transito da attacchi terabit, sulla consegna e l'aggregazione delle informazioni sul traffico, sul WAF, CDN quasi illimitato e molti meccanismi per ottimizzare la consegna dei contenuti.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Cosa vorresti sapere prima?

• 14,3%Algoritmi per il clustering e l'analisi della qualità del traffico web<3

• 33,3%Interni dei bilanciatori DDoS-Guard7

• 9,5%Protezione del traffico in transito L3/L4

• 0,0%Protezione dei siti web sul traffico in transito0

• 14,3%Firewall per applicazioni Web3

• 28,6%Protezione contro l'analisi e il clic6

21 utenti hanno votato. 6 utenti si sono astenuti.

Fonte: habr.com