El tráfico legítimo en la red DDoS-Guard recientemente superó los cien gigabits por segundo. Actualmente, el 50% de todo nuestro tráfico es generado por los servicios web de los clientes. Esto incluye decenas de miles de dominios, muy variados y que, en la mayoría de los casos, requieren un enfoque individualizado.
A continuación, explicamos cómo gestionamos los nodos frontales y otorgamos Certificados SSL para cientos de miles de sitios web.
Configurar el frontend para un solo sitio, aunque sea muy grande, es sencillo. Tomamos nginx o haproxy o lighttpd, configuramos según las guías y nos olvidamos. Si es necesario hacer algún cambio, realizamos un reload y nuevamente nos olvidamos.
Todo cambia cuando procesas grandes volúmenes de tráfico en tiempo real, evalúas la legitimidad de las solicitudes, comprimes y cacheas contenido de usuario, y además modificas parámetros varias veces por segundo. El usuario quiere ver el resultado en todos los nodos externos inmediatamente después de cambiar la configuración en su panel de control. Además, el usuario puede cargar a través de la API varios miles (y a veces decenas de miles) de dominios con parámetros de procesamiento de tráfico individuales. Todo esto también debe funcionar de inmediato en América, Europa y Asia; la tarea no es trivial, teniendo en cuenta que en Moscú hay varios nodos de filtrado distribuidos físicamente.
¿Por qué tener muchos nodos grandes y confiables en todo el mundo?
- La calidad del servicio del tráfico del cliente — las solicitudes desde EE. UU. deben ser procesadas precisamente en EE. UU. (incluyendo en relación con ataques, scraping y otras anomalías), en lugar de ser enviadas a Moscú o Europa, lo que incrementaría impredeciblemente la latencia en el procesamiento.
- El tráfico de ataque debe ser localizado: los operadores de tránsito pueden degradarse durante los ataques, cuyos volúmenes a menudo superan 1Tbps. Transportar tráfico de ataque a través de enlaces transatlánticos o transasiáticos no es la mejor idea. Hemos tenido casos reales en los que operadores Tier-1 dijeron: 'Los volúmenes de ataques que reciben son peligrosos para nosotros'. Es por esto que aceptamos flujos entrantes lo más cerca posible de sus fuentes.
- Los estrictos requisitos de continuidad del servicio significan que los centros de limpieza no deben depender entre sí ni de acontecimientos locales en nuestro mundo en rápida transformación. ¿Se cortó la electricidad en los 11 pisos del MMTS-9 durante una semana? No hay problema. Ningún cliente se verá afectado si no tiene conexión física en esa ubicación, y los servicios web no se verán comprometidos bajo ninguna circunstancia.
¿Cómo gestionar todo esto?
Las configuraciones de los servicios deben distribuirse lo más rápido posible (idealmente de forma instantánea) en todos los nodos frontales. No se puede simplemente modificar los archivos de texto de configuración y reiniciar los demonios en cada cambio — el mismo nginx mantiene procesos en cierre (worker shutting down) durante varios minutos (y a veces horas si hay largas sesiones de websocket).
Al reiniciar la configuración, es bastante normal observar lo siguiente:
Sobre la utilización de memoria:
Los trabajadores antiguos consumen memoria, la cual no depende linealmente del número de conexiones, — eso es normal. Cuando las conexiones del cliente se cierren, esta memoria se liberará.
¿Por qué no fue un problema cuando nginx comenzó a desarrollarse? No había ni HTTP/2, ni WebSocket, ni conexiones keep-alive largas en masa. El 70% de nuestro tráfico web es HTTP/2, lo que implica conexiones muy prolongadas.
La solución es simple: no usar nginx, no gestionar los frontales basándose en archivos de texto, y definitivamente no enviar configuraciones de texto comprimidas a través de canales transoceánicos. Los canales, por supuesto, son garantizados y reservados, pero eso no los hace menos transcontinentales.
Tenemos nuestro propio servidor de equilibrio de carga en el front-end, del cual hablaré en artículos posteriores. Lo principal que puede hacer es aplicar miles de cambios de configuración por segundo en tiempo real, sin reinicios, recargas, picos en el consumo de memoria y todo eso. Es muy similar al Hot Code Reload, por ejemplo, en Erlang. Los datos se almacenan en una base de datos key-value geodistribuida y son leídos de inmediato por los mecanismos ejecutores del front-end. Es decir, has subido un certificado SSL a través de la interfaz web o API en Moscú, y en unos pocos segundos ya está listo para funcionar en nuestro centro de limpieza en Los Ángeles. Si por alguna razón ocurre una guerra mundial y se interrumpe el internet en todo el mundo, nuestras nodos seguirán funcionando de manera autónoma y arreglarán el split-brain tan pronto como se habilite uno de los canales dedicados Los Ángeles-Ámsterdam-Moscú, Moscú-Ámsterdam-Hong Kong-Los Ángeles o al menos uno de los reservados de GRE superpuestos.
Este mismo mecanismo nos permite emitir y renovar certificados de Let’s Encrypt al instante. Funciona de manera muy simplificada así:
- Tan pronto como vemos al menos una solicitud HTTPS para el dominio de nuestro cliente sin certificado (o con un certificado caducado), la nodo externa que recibió la solicitud informa a nuestro centro interno de certificación.
- Si el usuario no ha prohibido la emisión de Let’s Encrypt, el centro de certificación genera un CSR, obtiene un token de confirmación de LE y lo envía a todos los frontales a través de un canal cifrado. Ahora cualquier nodo puede confirmar la solicitud de validación de LE.
- En unos momentos recibiremos el certificado correcto y la clave privada y de la misma manera los distribuiremos a los frontales. Nuevamente, sin reiniciar demonios.
- Siete días antes de la fecha de expiración, se inicia el procedimiento de renovación del certificado.
Justo ahora estamos rotando en tiempo real 350k certificados de manera completamente transparente para los usuarios.
En los próximos artículos del ciclo hablaré sobre otras características del procesamiento en tiempo real de grandes volúmenes de tráfico web — por ejemplo, sobre el análisis de RTT con datos incompletos para mejorar la calidad del servicio de clientes de tránsito y sobre la protección del tráfico de tránsito contra ataques de terabits, sobre la entrega y agregación de información sobre el tráfico, sobre WAF, una CDN casi ilimitada y numerosos mecanismos de optimización de la entrega de contenido.
Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.
¿Sobre qué le gustaría saber primero?
- 14,3%Algoritmos de clustering y análisis de calidad del tráfico web<3
- 33,3%Entramados de los balanceadores DDoS-Guard7
- 9,5%Protección del tráfico L3/L4 en tránsito2
- 0,0%Protección de sitios web en tráfico de tránsito0
- 14,3%Cortafuegos de Aplicaciones Web3
- 28,6%Protección contra scraping y clics fraudulentos6
21 usuarios votaron. 6 usuarios se abstuvieron.
Fuente: habr.com
