Le trafic légitime sur le réseau DDoS-Guard a récemment dépassé les cent gigabits par seconde. Actuellement, 50 % de tout notre trafic est généré par les services Web clients. Il s’agit de plusieurs dizaines de milliers de domaines, très différents et nécessitant dans la plupart des cas une approche individuelle.
Sous la coupe se trouve la façon dont nous gérons les nœuds frontaux et émettons des certificats SSL pour des centaines de milliers de sites.
Mettre en place une façade pour un site, même très grand, est facile. Nous prenons nginx ou haproxy ou lighttpd, le configurons selon les guides et l'oublions. Si nous devons changer quelque chose, nous rechargeons et oublions à nouveau.
Tout change lorsque vous traitez de gros volumes de trafic à la volée, évaluez la légitimité des demandes, compressez et mettez en cache le contenu utilisateur et modifiez en même temps les paramètres plusieurs fois par seconde. L'utilisateur souhaite voir le résultat sur tous les nœuds externes immédiatement après avoir modifié les paramètres de son compte personnel. Un utilisateur peut également télécharger plusieurs milliers (et parfois des dizaines de milliers) de domaines avec des paramètres de traitement de trafic individuels via l'API. Tout cela devrait également fonctionner immédiatement en Amérique, en Europe et en Asie - la tâche n'est pas des plus triviales, étant donné qu'à Moscou seulement, il existe plusieurs nœuds de filtration physiquement séparés.
Pourquoi existe-t-il de nombreux grands nœuds fiables dans le monde ?
-
Qualité de service pour le trafic client - les demandes en provenance des États-Unis doivent être traitées aux États-Unis (y compris en cas d'attaques, d'analyses et autres anomalies) et non acheminées vers Moscou ou l'Europe, ce qui augmente de manière imprévisible le délai de traitement.
-
Le trafic d'attaque doit être localisé - les opérateurs de transit peuvent se dégrader lors d'attaques dont le volume dépasse souvent 1 Tbps. Transporter du trafic d’attaque sur des liaisons transatlantiques ou transasiatiques n’est pas une bonne idée. Nous avons eu des cas réels où des opérateurs de niveau 1 ont déclaré : « Le volume d'attaques que vous recevez est dangereux pour nous. » C'est pourquoi nous acceptons les flux entrants aussi près que possible de leurs sources.
-
Des exigences strictes en matière de continuité de service - les centres de nettoyage ne doivent dépendre ni les uns des autres ni des événements locaux dans notre monde en évolution rapide. Avez-vous coupé le courant aux 11 étages du MMTS-9 pendant une semaine ? - aucun problème. Pas un seul client qui ne dispose pas d’une connexion physique à cet endroit particulier n’en souffrira, et les services Web ne souffriront en aucun cas.
Comment gérer tout cela ?
Les configurations de service doivent être distribuées à tous les nœuds frontaux aussi rapidement que possible (idéalement instantanément). Vous ne pouvez pas simplement prendre et reconstruire les configurations de texte et redémarrer les démons à chaque changement - le même nginx maintient les processus fermés (arrêt du travailleur) pendant quelques minutes supplémentaires (ou peut-être des heures s'il y a de longues sessions Websocket).
Lors du rechargement de la configuration nginx, l'image suivante est tout à fait normale :
Sur l'utilisation de la mémoire :
Les anciens travailleurs consomment de la mémoire, y compris de la mémoire qui ne dépend pas linéairement du nombre de connexions - c'est normal. Lorsque les connexions clients sont fermées, cette mémoire sera libérée.
Pourquoi n'était-ce pas un problème au début de nginx ? Il n’y avait pas de HTTP/2, pas de WebSocket, pas de connexions massives et persistantes. 70 % de notre trafic Web est HTTP/2, ce qui signifie des connexions très longues.
La solution est simple : n'utilisez pas nginx, ne gérez pas de fronts basés sur des fichiers texte et n'envoyez certainement pas de configurations de texte compressées sur les canaux transpacifiques. Les chaînes sont certes garanties et réservées, mais cela ne les rend pas moins transcontinentales.
Nous avons notre propre équilibreur de serveur frontal, dont je parlerai des composants internes dans les articles suivants. La principale chose qu'il peut faire est d'appliquer des milliers de changements de configuration par seconde à la volée, sans redémarrages, recharges, augmentations soudaines de la consommation de mémoire, et tout ça. Ceci est très similaire à Hot Code Reload, par exemple en Erlang. Les données sont stockées dans une base de données clé-valeur géodistribuée et sont lues immédiatement par les actionneurs frontaux. Ceux. vous téléchargez le certificat SSL via l'interface web ou l'API à Moscou, et en quelques secondes il est prêt à être envoyé à notre centre de nettoyage à Los Angeles. Si une guerre mondiale éclate soudainement et qu'Internet disparaît partout dans le monde, nos nœuds continueront à fonctionner de manière autonome et à réparer le cerveau divisé dès que l'un des canaux dédiés Los Angeles-Amsterdam-Moscou, Moscou-Amsterdam-Hong Kong- Los-Los devient disponible.Angeles ou au moins une des superpositions de sauvegarde GRE.
Ce même mécanisme nous permet d'émettre et de renouveler instantanément les certificats Let's Encrypt. Très simplement, cela fonctionne comme ceci :
-
Dès que nous voyons au moins une requête HTTPS pour le domaine de notre client sans certificat (ou avec un certificat expiré), le nœud externe qui a accepté la requête le signale à l'autorité de certification interne.
-
Si l'utilisateur n'a pas interdit l'émission de Let's Encrypt, l'autorité de certification génère un CSR, reçoit un jeton de confirmation de LE et l'envoie à tous les fronts via un canal crypté. Désormais, n'importe quel nœud peut confirmer une demande de validation de LE.
-
Dans quelques instants, nous recevrons le bon certificat et la clé privée et les enverrons aux fronts de la même manière. Encore une fois sans redémarrer les démons
-
7 jours avant la date d'expiration, la procédure de ré-réception du certificat est engagée
À l’heure actuelle, nous effectuons une rotation de 350 XNUMX certificats en temps réel, de manière totalement transparente pour les utilisateurs.
Dans les articles suivants de la série, je parlerai d'autres fonctionnalités du traitement en temps réel d'un trafic Web important - par exemple, de l'analyse du RTT à l'aide de données incomplètes pour améliorer la qualité de service pour les clients du transit et, en général, de la protection du trafic de transit contre attaques térabits, sur la livraison et l'agrégation d'informations sur le trafic, sur le WAF, le CDN presque illimité et de nombreux mécanismes d'optimisation de la livraison de contenu.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Que voudriez-vous savoir en premier ?
-
14,3%Algorithmes de clustering et d'analyse de la qualité du trafic web<3
-
33,3%Composants internes des équilibreurs DDoS-Guard7
-
9,5%Protection du trafic de transit L3/L4
-
0,0%Protéger les sites Web du trafic de transit0
-
14,3%Pare-feu d'applications Web3
-
28,6%Protection contre l'analyse et le clic6
21 utilisateurs ont voté. 6 utilisateurs se sont abstenus.
Source: habr.com