16 Dec 21
El WAF y la vulnerabilidad log4j
Detrás de las siglas WAF se esconde una de las mejores herramientas para proteger una web del tráfico malicioso. El […]
Garantizar el máximo rendimiento de la CDN
Todo proyecto en Internet necesita de una infraestructura que lo soporte y que debe estar lo suficientemente dimensionada para cada fase. Esto significa que los consumos no sean excesivos cuando no sea necesario, que los recursos no estén ociosos cuando no se precisen y que puedan crecer cuando más los necesitemos. Todo ello sin dejar de lado la seguridad para no sufrir a posteriori una deuda técnica que nos cueste muchísimo pagar debido a los cambios que tengamos que acometer o, en el peor de los casos, al robo de información del que seamos víctimas.
Al frente de mi equipo en Transparent Edge, llevo muchos años ayudando a empresas y otras organizaciones en la gestión integral de sus plataformas de origen.
La realidad es que muchas carecen de experiencia en la implementación de plataforma web o no tienen manos suficientes para poder llevar a cabo este tipo de trabajos, que requieren equipos senior de Sistemas y Seguridad tanto en el diseño como en la implementación y en la administración posterior de la infraestructura en Internet.
Hablamos de equipos que, como el nuestro, trabajan en el origen y están enfocados en todo momento al rendimiento, la escalabilidad, el beneficio operativo y la seguridad.
En base a un caso real, en este post quiero contarte un ejemplo de cómo trabajamos en Transparent Edge para garantizar el máximo rendimiento de nuestra CDN de nueva generación y lo que hacemos por las organizaciones que quieren y necesitan introducir una en su servicio pero no saben cómo o no se atreven a hacerlo.
Hace algún tiempo llegó a nosotros una empresa con serios problemas de inestabilidad en su plataforma web. Esta plataforma estaba basada en microservicios y servía su producto en producción.
Lo primero que hay que hacer en estos casos es un análisis de la situación. Para ello implementamos diferentes soluciones de monitorización que nos permitieran obtener datos en los que basarnos para, después, poder tomar decisiones de cara a lograr el mayor rendimiento de la CDN.
Gracias a esta monitorización, y gracias al contacto directo entre nuestros equipos técnicos y los equipos técnicos internos del cliente, pudimos detectar cuellos de botella, defectos de configuración y otros problemas que hacían que la entrega del contenido no fuese todo lo eficiente que el cliente necesitaba y el usuario final deseaba.
En paralelo, nuestro cliente, que hasta entonces contaba con uno de los grandes proveedores no europeos de servicios de CDN, decidió cambiar y contratar la CDN de nueva generación de Transparent Edge.
El cambio fue sencillo: dimos de alta las configuraciones en nuestro dashboard y cambiamos un CNAME en el DNS del cliente. Todo su tráfico empezó a pasar por los nodos edge de nuestra CDN. Y entonces nos dimos de bruces con la cruda realidad: ninguna de las peticiones se estaba cacheando.
La investigación que iniciamos inmediatamente nos permitió ver que todas las peticiones mostraban una configuración de no-cache que impedía no solo aprovechar la CDN, sino que incluso metía algún milisegundo más a cada petición porque los servidores de CDN, aunque no se utilizasen, estaban actuando como proxis por los que pasaba todo el tráfico,
El anterior proveedor no había dado nunca la señal de alarma y estaba facturando por el tráfico originado. ¿Por qué? Porque el resto de las CDN carecen de servicios en el origen. Nosotros no solo contamos con una CDN de nueva generación, respaldada en su funcionamiento diario por un equipo de ingenieros. También tenemos un equipo de ingenieros senior de Sistemas y Seguridad que trabajan como si fueran parte del equipo del cliente, buscando potenciales problemas y oportunidades para que la CDN pueda funcionar a pleno rendimiento y para maximizar los beneficios operativos del área IT.
Volviendo a nuestro cliente, este nos confirmó entonces que en el pasado habían tenido bastantes problemas para poder actualizar el contenido y, por tanto, habían decidido introducir las cabeceras de no-cache para impedir que se cachease cualquier cosa.
Gracias a la simbiosis entre nuestros equipos técnicos y los equipos del cliente, llegamos a la propuesta de una solución. De esta manera, empezamos a cachear solo el contenido estático de sus aplicaciones: imágenes, javascript, CSS, etc., dejando para una segunda fase el contenido más dinámico.
Con esta medida se podría pensar que el tráfico habría quedado bastante reducido, pero no fue así, ya que todas las peticiones iban acompañadas por una cabecera Vary: Cookie que hacía que, por cada petición, se generase un objeto en caché solo accesible para ese usuario, lo que fragmentaba muchísimo la caché y la hacía poco eficaz.
La solución de urgencia que dimos entonces fue configurar algo similar a esto en los nodos en el edge:
if(bereq.url~”^(avi|bmp|doc|flv|ico|mov|mp3|pdf|png|jpg|jpeg|css|js|xml)$”) {
unset beresp.http.set-cookie;
unset beresp.http.pragma;
unset beresp.http.etag;
set beresp.ttl=86400;
}
Hay soluciones más elaboradas que no delegan en la URL de la petición qué hacer, que hacen honor a las cabeceras de caché que reciben desde el origen y que permiten generar imágenes de modo dinámico. Pero en aquel momento necesitábamos una solución rápida que redujera la carga en los servidores de origen y esta era la más adecuada para nuestro cliente.
Tras esto llegó el momento de decidir qué y dónde queríamos cachear. ¿En cualquier sitio? ¿En los navegadores? ¿También en los servidores edge de nuestra CDN de última generación?
El cliente dudaba de que cachear una parte de su contenido en los navegadores fuera buena idea y le propusimos cachear solo en los nodos de edge introduciendo algo similar a esto en sus orígenes:
Cache-control “max-age=0, s-maxage=2629800”
Esos objetos se cacheaban así en los edge por hasta un mes, pero no en los navegadores de los usuarios. Esto permitía a nuestro cliente controlar en todo momento qué entregaba, invalidando a discreción aquello que necesitaba invalidar. Para ello se pudo apoyar en nuestra solución de invalidación en tiempo real, fácilmente integrable vía API y la cual permite invalidar de manera programática. La invalidación se produce en cuestión de segundos en nuestros nodos en el edge, sin que haya que preocuparse por que los navegadores tengan almacenado contenido obsoleto en sus cachés internas.
Con esto y algunas cosas más que implicaban tanto a nuestros ingenieros de arquitectura como al equipo de desarrollo del cliente, conseguimos que el servicio fuese estable. Además, logramos el máximo rendimiento de la CDN, así como que los usuarios tuvieran una experiencia de navegación excelente en cuanto a velocidad de entrega.
Nuestro trabajo para este cliente le permitió aumentar el beneficio operativo del área IT al reducir considerablemente los costes de infraestructura. En la actualidad, está sirviendo una media de unas 70.000 peticiones por segundo diarias con una plataforma de origen muy reducida, gracias a un 99% de objetos cacheados.
Fermín Manzanedo es cofundador y director de Operaciones de Transparent Edge.
De pensamiento crítico y en busca de la mejora continua, Fermín ha contribuido al desarrollo de un buen número de compañías, entre ellas grandes grupos de comunicación, resolviendo sus problemas de tecnología de la información con soluciones pensadas para los objetivos específicos de sus negocios. Es, además, uno de los ‘padres’ de la primera CDN española. Físico de formación, aporta siempre una visión estratégica a la administración de sistemas IT.
Compartir:
