Amplificando nuestra web con un proxy inverso en Windows Azure

Me lo explicó primero mi compañero Hugo, que trabaja como ingeniero en Lisboa, y luego al comentarlo, los amigos de Plain Concepts me confirman que ellos ya lo tienen instalado y funcionando en algunos clientes, y que funciona de cine. No es probablemente tan funcional o tan eficiente como uno por hardware, pero tiene algunas ventajas que están muy bien.

El concepto es muy fácil aunque tiene algunas limitaciones (ver el último párrafo). Unos servidores en Windows Azure que hacen de “amplificador” de nuestra página web: se “aprenden” un sitio y lo entregan desde los propios servidores de Windows Azure, de acuerdo con unas reglas que podemos definir como queramos, y sin cargar en muchos casos nuestros propios servidores. No requiere mucho desarrollo, se hace usando este componente de Windows llamado ARR.

Comentarios:

• Le da a cualquier página web una escalabilidad casi infinita. Podemos tener una pequeña página web en un pequeño servidor, y usar el proxy inverso en Azure (el “amplificador”) para soportar el tráfico de cientos de miles de usuarios a la vez.

• La elasticidad es máxima: podemos utilizar muchos servidores (incluso cientos) durante un día solamente o incluso durante un par de horas nada más. El resto del tiempo nuestro “amplificador” puede estar en un par de servidores pequeños nada más (menos de 150€ al mes). El paso de un estado a otro se puede hacer en menos de media hora, o incluso podemos ir aumentando o disminuyendo gradualmente el número de servidores en función del tráfico real que tengamos de manera automática, usando este componente llamado Wasabi.

• La enorme elasticidad nos permite optimizar al máximo el coste cuando hay poco tráfico… y crecer todo lo que queramos cuando el tráfico sea intenso.

• Se habilitan soluciones híbridas: a veces no queremos sacar los sitios web de nuestra organización, por la información contenida en las bases de datos o por lo que sea. El modelo que comentamos habilita una solución híbrida muy sencilla, en el que mantengamos unos servidores pequeños en nuestras oficinas para poner en marcha y actualizar el site como lo necesitemos, y usemos el “amplificador” fuera de nuestra organización para manejar volúmenes importantes de tráfico.

• Hay muchos casos en los que podemos ahorrar en ancho de banda. Mucha gente tiene un balanceador por hardware delante de los frontales para gestionar el tráfico… pero ese tráfico tiene que llegar hasta sus máquinas, por lo que nos obliga en picos enormes a contratar anchos de banda importantes. Mediante la solución que proponemos el tráfico llega hasta el “amplificador” y se responde desde ahí en muchas de las sesiones, por lo que reduce mucho la tensión sobre nuestras líneas contratadas y nuestro balanceador.

• Podemos hacer esto con cualquier página en cualquier tecnología (da igual que esté hecha con php, con java o con cualquier otra cosa). También funciona con vídeo o audio, incluso en directo, si es Silverlight Smooth Streaming o se puede convertir. De hecho, estamos hablando de hacer transcodificación en tiempo real en algún proyecto. Ojito, que mete un importante retardo en la señal.

• La principal limitación: para que funcione, las páginas tienen que ser estáticas. Es decir, tenemos que ser capaces de entregar la misma página, exactamente igual, a diferentes usuarios. Eso es necesario porque los servidores que hay en Azure con esta técnica no calculan realmente: leen una página, la almacenan localmente, y se la sirven a los usuarios que las piden. No quita que la duración de una página puede ser de un día, una hora o un minuto. Podemos definir una regla por la que la el amplificador vuelva a leer la página original en intervalos muy cortos. Eso sí, la página tiene que ser igual para todos los usuarios que vienen a la vez.

  No vale tanto páginas más o menos personalizadas, ecommerce y muchos sitios dinámicos. Pero hay muchos sitios en los que hay contenido estático mezclado con dinámico, y en muchos casos podemos liberar a la infraestructura del cliente de la parte estática y dejar los servidores que haya para que atiendan sólo la parte dinámica.

Comments

• Anonymous
  March 21, 2012
  Muy bueno Juanjo, !!!!