Todo el mundo sabe que una de las ventajas de la nube es precisamente la alta disponibilidad y escalabilidad que ésta ofrece. Sin embargo, tanto o más importante que la plataforma es el diseño y arquitectura de nuestra aplicación. Esto es algo que se debe analizar caso y caso y cada escenario es distinto pero si que es cierto que hay una serie de puntos que siempre debemos tener en cuenta cuando nos enfrentemos a uno o varios de estos requisitos:

  • Número elevado de usuarios
  • Gran número de peticiones concurrentes
  • Requisitos altos de ancho de banda
  • Requerimientos elevados de almacenamiento

Veamos puntos a tener en cuenta para que nuestra aplicación sea muy escalable:

Aplicación Web

  • Todas las técnicas y buenas prácticas que debemos seguir en una aplicación web ASP.NET, aplican también en un escenario con Windows Azure.
  • La monitorización es crítica. Si no monitorizo mi aplicación (CPU, RAM, etc.) difícilmente voy a poder optimizar el rendimiento de la misma. Más información sobre monitorización en Azure en este video y en este artículo. Es importante resaltar también que hay herramientas de terceros como Azure Diagnostics Manager que seguramente nos harán la vida mucho más fácil.
  • Gestión de sesiones: Si la aplicación utiliza sesiones ASP.NET, lo más recomendable es utilizar el Proveedor de Sesiones de Windows Azure Caching.   
    

Patrones Asíncronos

  • Worker-QueueModelLos patrones asíncronos aplican a aplicaciones altamente escalables tanto on-premise como en la nube.
  • Las Colas del Windows Azure Storage son muy útiles para comunicación asíncrona entre instancias de roles en Windows Azure típicamente para desacoplar el front-end (Web Roles) con el backend (Worker Roles).
    • Una cola tiene un rendimiento máximo de 500-600 mensajes por segundo.
    • Cuantas más instancias e hilos de ejecución simultáneos, mayor rendimiento de lectura o escritura (mensajes leídos o insertados/segundo) hasta llegar a un valor máximo en el que ya no se aprecian incrementos significativos.
    • Al llegar al límite de rendimiento, podré crear más colas para aumentar la escalabilidad del sistema.

Caché

  • AppFabricCacheSi queremos una aplicación escalable, el uso de cachés se hace prácticamente indispensable ya que hará disminuir la carga de nuestros servidores. Como regla general, a mayor uso de caché, mayor escalabilidad.
  • Algunos tipos de caché que habrá que gestionar:
    • Caché de Página de ASP.NET: Permite almacenar en caché una página completa o una parte de ella.
    • Caché de datos estáticos: En la mayoría de las aplicaciones tengo contenido estático que por su naturaleza es siempre el primer candidato a ser distribuido desde un caché. Imágenes, HTML estático, videos, documentos, etc. entran dentro de esta categoría. Puedo almacenar estos contenidos en BLOBS de Windows Azure Storage y posteriormente habilitar el Content Delivery Network (CDN) de Windows Azure. El CDN está formado por una red de más de 22 puntos de distribución alrededor del planeta de forma que nos aseguramos que cada usuario, independientemente de su ubicación geográfica puede acceder al contenido de la CDN con la menor latencia y el mayor ancho de banda disponible.
    • Caché de datos de aplicación: En Windows Azure, por su propia naturaleza tenemos que pensar siempre en mecanismos de caché distribuidos. Algunas opciones:
      • Windows Azure Caching: Es sin duda la opción más recomendable. Nos proporciona un caché distribuido en memoria que puedo utilizar en mi aplicación con un API muy sencillo. Se proporciona como servicio por lo que no tengo que instalarlo ni configurarlo.
      • Memcached: Otra alternativa posible de un gestor de caché distribuido en memoria que es utilizado por alguno de los principales websites de más tráfico en Internet. Podemos encontrar algunos ejemplos sobre cómo hacerlo en este post de Marteen Balliauw, en esta web de CodePlex, en el blog de David Aiken y en esta página. También se trata el tema en el Capítulo 3 del libro gratuito “Windows Azure Platform – Articles from the Trenches”.
      • Existen más motores de caché distribuidos en memoria como Shared Cache y otros. Si alguien los ha probado en Windows Azure se agradecerá un comentario.

Escalabilidad automática

  • Si nuestra aplicación tiene que responder ante picos impredecibles de demanda, es absolutamente necesario el disponer de un mecanismo de escalado automático de instancias de forma que a mayor demanda, el sistema sea capaz de provisionar de forma automática un mayor número de instancias para atender esa demanda. En este sentido tenemos varias opciones:

SQL Azure

  • Lectura y escritura de datos: Cuantos más instancias e hilos de ejecución simultáneos, mayor rendimiento de lectura o escritura (registros leídos o insertados/segundo) hasta llegar a un valor máximo en el que ya no se aprecian incrementos significativos.
  • Atención a los límites de concurrencia: En diversas pruebas realizadas, se observan picos de rendimiento al atacar SQL Azure desde 30 clientes simultáneos (cliente=instancia x hilo de ejecución).
  • Para datos en los que se requiera la máxima velocidad de lectura, el uso de Tablas de Windows Azure Storage puede ser una opción a considerar
  • Bases de datos de gran tamaño: Deberemos aplicar técnicas de particionado de datos o sharding como se describen este whitepaper de TechNet. Es importante resaltar que SQL Azure dispone de un particionado automático llamado SQL Azure Federation del que podemos leer más en este post. La técnica del sharding, además de evitarnos llegar al límite de capacidad de cada base de datos en SQL Azure (actualmente 150 GB) permite también aumentar el rendimiento del acceso a datos ya que puedo paralelizar consultas simultáneamente a varias bases de datos.

 

Otras consideraciones

  • Recuerda compilar el código en modo “Release” antes de subirlo a producción.
  • No habilites nunca IntelliTrace en producción, nunca.
  • Haz tests de carga de tu aplicación. Observa los resultados.
  • Haz más tests de carga de tu aplicación. Vuelve a observar los resultados obtenidos.
  • ¿Mencioné ya que es importante realizar tests de carga?
  • Hay muchas formas de realizar tests de carga. Algunas de ellas:

 

Recursos adicionales   

Casos de éxito

    ACTUALIZACIÓN (11-03-2011): Añadidos algunos recursos adicionales.

    ACTUALIZACIÓN (16-08-2011): Añadidos artículos de pruebas de carga con Visual Studio y con WCAT. Añadido también enlace a “CloudNinja”.

    ACTUALIZACIÓN (14-09-2011): Añadido el Windows Azure Autoscaling Block de P&P.

    ACTUALIZACIÓN (17-04-2012): Añadido SQL Azure Federation y la versión final de WASABi

    Como siempre, espero vuestros comentarios y experiencias sobre este tema.