Traficul legitim în rețeaua DDoS-Guard a depășit recent o sută de gigabiți pe secundă. Acum, 50% din tot traficul nostru este generat de serviciile web ale clienților. Acestea sunt zeci de mii de domenii, foarte variate și care, în cele mai multe cazuri, necesită o abordare individualizată.
Sub această secțiune — cum gestionăm nodurile de front și emitem Certificatul SSL pentru sute de mii de site-uri.
Configurarea frontului pentru un singur site, chiar și pentru unul foarte mare, este simplă. Luăm nginx sau haproxy sau lighttpd, configurăm conform ghidurilor și uităm de el. Dacă trebuie să schimbăm ceva — facem reload și iar uităm.
Totul se schimbă atunci când prelucrezi în timp real volume mari de trafic, evaluezi legitimitatea cererilor, comprimi și memorezi conținutul utilizatorilor și în același timp schimbi parametrii de mai multe ori pe secundă. Utilizatorul dorește să vadă rezultatul pe toate nodurile externe imediat după ce a modificat setările din contul său. În plus, utilizatorul poate încărca prin API câteva mii (iar uneori zeci de mii) de domenii cu parametru de procesare a traficului personalizat. Toate acestea trebuie să funcționeze imediat, atât în America, cât și în Europa sau Asia — sarcina nu este deloc trivială, având în vedere că în Moscova există mai multe noduri fizic separate pentru filtrare.
De ce atât de multe noduri mari și fiabile în întreaga lume?
- Calitatea serviciului pentru traficul clienților — cererile din SUA trebuie să fie procesate exact în SUA (inclusiv pentru atacuri, parsare și alte anomalii), și nu să fie trase în Moscova sau Europa, crescând imprevizibil latența procesării.
- Traficul de atac trebuie să fie localizat — operatorii de tranzit pot suferi degradare în timpul atacurilor, a căror volum depășește adesea 1Tbps. Transportarea traficului de atac prin linii transatlantice sau transasiatice nu este cea mai bună idee. Am avut cazuri reale în care operatorii Tier-1 au spus: „Volumele de atac pe care le acceptați sunt periculoase pentru noi”. De aceea, acceptăm fluxurile de intrare cât mai aproape de sursele lor.
- Cerințele stricte de continuitate a serviciului – centrele de curățare nu trebuie să depindă unii de alții sau de evenimentele locale din lumea noastră în continuă schimbare. A fost întreruptă energia timp de o săptămână pentru toate cele 11 etaje ale MMTs-9? – nu este o problemă. Niciun client care nu are o conectare fizică în această locație nu va fi afectat, iar serviciile web nu vor suferi în niciun caz.
Cum gestionăm toate acestea?
Configurațiile serviciilor trebuie să fie distribuite cât mai repede posibil (ideal instantaneu) pe toate nodurile frontale. Nu se poate pur și simplu să se modifice configurațiile textuale și să se repornească demonii la fiecare modificare – același nginx menține procesele închise (worker shutting down) încă câteva minute (sau poate ore dacă există sesiuni websocket lungi).
La repornirea configurației, este destul de normal următoarea situație:
În ceea ce privește utilizarea memoriei:
Vechele workere consumă memorie, inclusiv o cantitate care nu depinde liniar de numărul de conexiuni, – aceasta este o situație normală. Când conexiunile clientului se închid, această memorie va fi eliberată.
De ce aceasta nu era o problemă atunci când nginx a început să se dezvolte? Nu existau nici HTTP/2, nici WebSocket, nici conexiuni lungi keep-alive de masă. 70% din traficul nostru web este HTTP/2, iar aceste conexiuni sunt foarte lungi.
Soluția este simplă – nu folosiți nginx, nu gestionați fronturile pe baza fișierelor text și cu siguranță nu trimiteți configurații text zipate pe canalele trans-pacific. Canalele sunt, desigur, garantate și rezervate, dar nu devin mai puțin transcontinentale din acest motiv.
Avem un server front-end echilibror de sarcină, despre interiorul căruia voi povesti în articolele următoare. Principalul său atribut este capacitatea de a aplica mii de modificări de configurare pe secundă în timp real, fără reporniri, reîncărcări sau creșteri bruște ale consumului de memorie. Acest lucru este foarte asemănător cu Hot Code Reload, de exemplu în Erlang. Datele sunt stocate într-o bază de date key-value geodistribuită și sunt citite instantaneu de mecanismele de execuție ale serverului front-end. Cu alte cuvinte, dacă ați încărcat un certificat SSL prin intermediul interfeței web sau API-ului din Moscova, în câteva secunde acesta va fi pregătit pentru utilizare în centrul nostru de curățare din Los Angeles. Dacă cumva va avea loc o război mondial și internetul va dispărea la nivel global, nodurile noastre vor continua să funcționeze autonom și vor corecta split-brain, imediat ce unul dintre canalele dedicate Moscova-Amsterdam-Los Angeles sau cel puțin unul dintre canalele de rezervă GRE va deveni disponibil.
Același mecanism ne permite să emitem și să reînnoim instantaneu certificate Let’s Encrypt. Foarte simplificat, funcționează astfel:
- De îndată ce observăm măcar o solicitare HTTPS pentru domeniul clientului nostru fără certificat (sau cu un certificat expirat), nodul extern care a primit solicitarea notifică centrul nostru intern de certificare.
- Dacă utilizatorul nu a interzis emiterea Let’s Encrypt, centrul de certificare generează CSR, obține un token de confirmare de la LE și îl trimite tuturor fronturilor printr-un canal criptat. Acum, orice nod poate confirma solicitarea de validare de la LE.
- În câteva momente, vom primi un certificat corect și o cheie privată și le vom trimite la fel fronturilor. Din nou, fără a reporni demonii.
- Cu 7 zile înainte de data de expirare, se inițiază procedura de reobținere a certificatului.
Chiar acum, rotim în timp real 350k de certificate complet transparent pentru utilizatori.
În articolele următoare ale acestui ciclu, voi povesti despre alte caracteristici ale procesării în timp real a unui volum mare de trafic web — de exemplu, despre analiza RTT pe date incomplete pentru îmbunătățirea calității serviciilor pentru clienții de transit și despre protejarea traficului de transit împotriva atacurilor de tip terabit, despre livrarea și agregarea informațiilor de trafic, despre WAF, CDN aproape nelimitată și numeroase mecanisme de optimizare a livrării conținutului.
Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.
Ce ați dori să aflați în primul rând?
- 14,3%Algoritmi de clusterizare și analiză a calității traficului web<3
- 33,3%Interioarele echilibrarelor DDoS-Guard7
- 9,5%Protecția traficului L3/L4 în tranzit2
- 0,0%Protecția site-urilor web pe traficul de tranzit0
- 14,3%Firewall pentru aplicații web3
- 28,6%Protecție împotriva parsării și clicurilor automate6
21 de utilizatori au votat. 6 utilizatori s-au abținut.
Sursa: habr.com
