AWS CloudFront: balanceando las visitas entre varios servidores

2017-05-29 - Categorías: Amazon Web Services
Cloudfront logo

Hoy traigo un pequeño HOWTO de cómo balancear las visitas de un sitio web entre varios servidores, eligiendo exactamente qué visitas van a qué servidores. Se trata unas pocas directrices para configurar CloudFront y así redirigir las peticiones web.

Con esto puedes controlar qué subdirectorios, o que zonas de tu aplicación web se gestionan desde qué servidores. Balancear en función de la carga se puede hacer con un ELB (Elastic Load Balancer), pero estas configuraciones a nivel de CloudFront balancean las peticiones de forma permanente. Por ejemplo:

  • https://www.tudominio.com/blog/ –>> Que lleve a un servidor en concreto, alojado en AWS o en cualquier otro proveedor de servicios.
  • https://www.tudominio.com/imagenes/ –>> Que lleve a un almacén de imágenes, es decir, un servidor web que simplemente aloje imágenes o un almacén en S3 o EFS.
  • https://www.tudominio.com/otroSubdirectorio/ –>> Que lleve a cualquier otro servidor.
  • https://www.tudominio.com/ –>> El resto de peticiones que se dirigan a otros servidores, o un balanceador de carga que a su vez divida la visitas entre cierta cantidad de servidores, arrancando y parando a demanda.

Para el caso de ejemplo que traigo, tenemos todas las visitas en un Magento mientras que un subdirectorio en un WordPress en otro servidor. También tenemos algunos ficheros sueltos en un almacén de objetos S3 (Simple Storage Service).

Un poco de teoría

Todo comienza poniendo CloudFront delante de los servidores, será el punto de contacto con el exterior. CloudFront son una serie de Proxys gestionados automáticamente por AWS. Estos proxys pueden configurarse para ser una red de distribución de contenidos de alta disponibilidad (CDN, Content Delivery Network). En pocas configuraciones puedes dejarle a CloudFront que cachee los contenidos liberando de carga a los servidores. Esto, en algunos casos incluso te ahorra dinero si está bien configurado. Ya que libera de mucha carga de trabajo a los servidores que hay detrás.

Amazon Web Services se encarga de mantenerlos, replicarlos, y que su configuración funcione transparentemente sin mantenimiento por nuestra parte. Es económico comparado con otros servicios de la competencia, y muy robusto.

Así tenemos 2 cosas principales que configurar en CloudFront:

  • Los orígenes de datos: será de donde se servirán los datos, es decir, donde se atenderán las peticiones. Estos pueden ser de 3 tipos a su vez:
    • Almacenes de ficheros estáticos de S3.
    • Balanceadores de carga, llamados Elastic Load Balancers.
    • O servidores normales y corrientes, que a su vez pueden estar dentro de AWS o se pueden redirigir incluso a un servidor privado dentro de una LAN de una empresa.
  • Los comportamientos, llamados en inglés behaviors: que son las rutas que mediante URLs vamos a definir a qué origines de datos tienen que ir las visitas.

Para comprenderlo, de todas las cosas que podemos configurar, tenemos que configurar los orígenes de datos. Y mediante los comportamientos, establecer qué URLs se sirven desde qué origenes de datos. ¿Simple verdad?

Cómo se configura

Simplemente con esto, con pocos clics y sabiendo qué es lo que estamos haciendo, no tenemos más que redirigir las visitas. Por ejemplo, aquí un CloudFront que tiene 3 orígenes de datos configurados:

CloudFront 3 orígenes de datos

Una vez dados de alta los orígenes de datos, sólo queda redirigir todas las visitas a un servidor (Magento en este caso). Mientras que las visitas que lleguen bajo el directorio /blog/ vayan al otro servidor. Esto lo hacemos con los behaviors:

CloudFront balanceando visitantes a distintos servidores

Si te fijas los comportamientos se aplican en orden de precedencia. Es decir, que si una visita entra con un ‘path pattern’ ya se redirige al origen de datos configurado y no se continúa comprobando. Fíjate en la imagen de arriba en los comportamientos 2, 3 y 4. Estos son los que están redirigiendo a otro servidor. He creado 3 comportamientos para que poder configurarlos. En el 2 y 3 le he puesto que CloudFront vaya cacheando en el CDN las imágenes JPG y PNG respectivamente. Y en el 4 lo que hace es que simplemente redirige sin cachear al CDN la petición.

Balanceando y cacheando imágenes

Por si es útil, dejo aquí una configuración destinada a cachear las imágenes en el CDN del CloudFront.

CloudFront balanceando imagenes cacheando con CDN


Los puntos clave de este behavior es establecer el origen en el servidor que va a recibir estas visitas, y las cabeceras de la petición. Debemos redirigir las cabeceras de la petición para que el servidor de destino entienda lo que tiene que servir. Haciendo esto se nos permite cachear al CDN los contenidos servidos, ya sean imágenes, archivos .zip, páginas web, etcétera. Podemos cachear al CDN lo que queramos.

Veo más interesante configurar el cacheo en el servidor origen de datos, así el CDN cogerá la configuración de cacheado que le configures automáticamente. Es decir, si le configuras en el servidor que la cabecera Cache Control sea:

Cache-Control: "max-age=86400"

Entonces CloudFront recibirá esta cabecera del servidor origen de datos, y cacheará estas imágenes con un tiempo de expiración de 86400 segundos (un día).

Balanceando visitas sin cachear

Todavía más simple es redirigir sin cachear. Una configuración de ejemplo que te puede servir es esta:

CloudFront balanceando sin cachear


Para redirigir todo simplemente hay que elegir el servidor origen de datos, y haciendo un Fordward Headers All ya tenemos la redirección. Esto funcionará como un proxy normal y corriente sin cachear nada a nivel de CloudFront.

Recuerda que los comportamientos se aplican uno detrás de otro. Es decir, que si el pattern corresponde a la petición en curso, se aplicará dicha configuración y no seguirá buscando hacia abajo a ver si aplicar otra configuración.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

 

© 2024 JnjSite.com - MIT license

Sitio hecho con WordPress, diseño y programación del tema por Jnj.