SetValue.NETSetValue.NET

Azure Front Door

March 20, 2021

Generic badge

Hoy me he decidido a hablar por un servicio de Azure que me gusta mucho por precio, funcionalidad y facilidad de puesta en marcha. Se trata de Azure Front Door, un CDN moderno que es un servicio global, robusto y escalable, con aceleración dinámica y balanceo de carga, y que nos permite, entre otras cosas, añadir una capa de seguridad a nuestras aplicaciones web sin perder rendimiento.

Front Door es un servicio que trabaja sobre la capa 7, utilizando el protocolo Anycast con split TCP. Dependiendo de la ubicación del usuario, enruta las solicitudes hacia el backend que provea menor latencia, de este modo, si tenemos un servicio con múltiples localizaciones los usuarios obtendrán los contenidos desde el punto más cercano a su ubicación geográfica por lo que el rendimiento será mucho más óptimo.

Sus principales características:

  • Gran performance debido al uso de Anycast y el split TCP
  • Monitorización inteligente de los health probes sobre los distintos backend
  • Enrutamiento basado en rutas URL
  • Soporte para múltiples sitios web
  • Afinidad de sesión basada en cookies
  • Gestión de certificados SSL
  • Custom domains
  • Web Application Firewall (WAF) para la seguridad de las aplicaciones
  • Redireccionamiento de tráfico HTTP a HTTPS
  • Redireccionamiento personalizado basado en path
  • Soporte de caja para IPv6 y HTTP/2
  • Caché
  • SLA del 99,99% 😎

Let's go

Vamos a probar el servicio, y para ello lo primero que vamos a hacer es crear una aplicación web en React.

gh repo create rfcm83/DemoAzureFrontDoor
cd .\DemoAzureFrontDoor\
npx create-react-app azure-front-door
cd .\azure-front-door\
npm start

Para ejecutar estos comandos necesitas tener instalado:

Una vez se han completado esos comandos, se abre una sesión de navegador con la url http://localhost:3000.

React App

Ahora hacemos un commit de los cambios en el repo.

cd.. #Volvemos a la raíz del repo
git commit -m 'First commit Demo FrontDoor'
git push --set-upstream origin master

En el Portal de Azure creamos dos Static Web App en dos regiones distintas, en mi caso:

Setting Value EUR Value US
Name Europe US
Region West Europe Central US
Build Presets React React
App Location /azure-front-door /azure-front-door
Output location build build

Sample Static Web App

Cuando ya se han desplegado las dos app, creamos un Front Door desde el Portal en West Europe, para ello, introducimos la siguiente configuración de base:

Add Frontend

Después, agregamos un backend pool que apuntará a Europa y América.

Add Backend Pool

Añadimos el FQDN de Europa.

Add Europe Backend

Seguimos con el de Estados Unidos.

Add US Backend

Dejamos los valores de balanceo por defecto, y añadimos el backend pool. A continuación, necesitamos crear dos reglas de enrutamiento, la primera para que todo el tráfico HTTP se redirija automáticamente a HTTPS, y la otra para que el tráfico HTTPS sea direccionado al backend pool que hemos creado.

Para hacer el redirect de HTTP a HTTPS, necesitamos modificar estos valores:

Redirect HTTP - HTTPS

A continuación, creamos el forwarding de HTTPS hacia el backend.

Forwarding Backend

Una vez añadidas las reglas de enrutamiento, revisamos y creamos el Front Door. Aunque estamos haciendo este proceso en la creación del recurso, luego, desde el portal podremos actualizar y agregar o eliminar reglas o backends. Tras unos minutos, el servicio estará desplegado y configurado, pero es preciso esperar un poco para que esté completamente configurado, todos los cambios sobre los Front Door tardan unos minutos en materializarse.

Front Door Up

Bien, ya tenemos el servicio arriba, si lo testamos entrando por la ruta HTTP redirige automáticamente al HTTPS, pero... necesitamos una url más amigable, para ello vamos a crear un custom domain.

En el Portal de Azure, accedemos al blade del Front Door Designer, y creamos un nuevo frontend, y para asegurarnos que nuestro sitio es seguro utilizaremos un certificado SSL, para ello habilitamos el Custom Domain HTTPS y le indicamos que lo gestione el Front Door.

Nota: Para poder asignar un custom domain es preciso asignar un registro CNAME que apunte al FQDN del Azure Front Door.

Custom Domain

Cuando lo hemos creado, el propio diseñador nos advierte de que no está funcionando, así que necesitamos activarlo en las reglas de enrutamiento. Accedemos a cada regla de enrutamiento y lo añadimos.

Add frontend to routing rule

Una vez se han modificado las dos reglas, pulsamos en Guardar, este proceso tardará algo más de lo habitual porque no sólo va a actualizar la configuración del Front Door, también tiene que generar el certificado digital del custom domain que hemos agregado, el propio portal nos indica que podría llegar a tardar unos 20 minutos. Si se accede a la configuración de este nuevo frontend, se puede ver cómo está avanzando el proceso. Cuando finalice, podremos volver a testar la configuración del Front Door por HTTP y HTTPS, el resultado deberá ser el mismo que antes de agregar nuestro dominio.

Custom Domain running

Probando la configuración global

Decíamos que este servicio balancea el tráfico al backend más próximo para así optimizar el performance de nuestro site. Bien, pues vamos a probar que es así, para ello creamos un nuevo Application Insights, con la configuración de servicio clásico, en nuestro grupo de recursos y creamos un test de disponibilidad desde el blade Availability.

Availability Test

Mantenemos las cinco localizaciones que nos propone, en mi caso son:

  • West US
  • UK West
  • Japan East
  • France Central
  • Australia East

Si recordamos, nuestra app está publicada en West Europe y Central US, por lo que todos estos orígenes están próximos, pero no coincide ninguno con nuestra publicación. Aunque realmente este test está haciendo un ping, ya podemos ver cómo las localizaciones más lejanas tienen de media, peores tiempos de respuesta que las localizaciones más próximas a los datacenter de nuestros backend.

Results Test

Para completar la prueba, agregamos Central US y West Europe al test, y comparamos resultados.

Final Comparison

Finalmente, si analizamos los resultados, los tiempos de las regiones europeas y americanas tienen mejores tiempos de respuesta que las que están en Australia o Asia, tanto en el promedio como en los valores mínimo y máximo, y, por supuesto, Central US y West Europe tienen unos valores medios mejores que el resto de su región.

Buy Me A Coffee