Memoria caché de la nube

Introducción al servicio de almacenamiento en caché de Windows Azure AppFabric

Karandeep Anand

En un mundo en el que la velocidad y el escalamiento son las métricas de éxito clave de cualquier solución, no pueden considerarse de menor importancia ni ajustar a una arquitectura de aplicación. La velocidad y el escalamiento deben ser los principios de diseño centrales cuando todavía se está en el diseño de la aplicación.

El servicio de almacenamiento en caché de Windows Azure AppFabric proporciona los bloques de creación necesarios para simplificar estos desafíos sin que sea necesario saber implementar y administrar otro nivel en la arquitectura de la aplicación. En pocas palabras, el servicio de almacenamiento en caché es la memoria elástica que la aplicación necesita para aumentar su rendimiento y productividad gracias a la descarga de la presión del nivel de datos y el estado distribuido, a fin de que la aplicación pueda escalar fácilmente de manera horizontal el nivel de cálculo.

El servicio de almacenamiento en caché se lanzó como CTP (Community Technology Preview) en el congreso Microsoft Professional Developers Conference del año 2010 y se actualizó el mes de febrero de 2011.

El servicio de almacenamiento en caché es parte importante de la plataforma Windows Azure y se basa en las ofertas de Plataforma como servicio (PaaS) que ya forman parte de la plataforma. El servicio de almacenamiento en caché se basa en la misma base de código que el almacenamiento en caché de Windows Server AppFabric y, como consecuencia, tiene una experiencia del desarrollador simétrica respecto de la memoria caché local.

El servicio de almacenamiento en caché ofrece las siguientes capacidades a los desarrolladores:

• proveedores ASP.NET generados previamente para almacenamiento en caché de salida de página y estado de sesión, lo que permite la aceleración de aplicaciones web sin tener que modificar el código de la aplicación;
• almacena en caché cualquier objeto administrado, sin límites de tamaño de objeto ni costos de serialización para el almacenamiento en caché local;
• se integra fácilmente en las aplicaciones existentes;
• un modelo de desarrollo coherente entre Windows Azure AppFabric y Windows Server AppFabric;
• autorización y acceso seguros proporcionado por el servicio de control de acceso.

A pesar de que puede configurar otras tecnologías de almacenamiento en caché (como memcached) como instancias en la nube, terminaría usted mismo instalando, configurando y administrando las instancias y los clústeres de caché. Esto define de manera predeterminada uno de los principales objetivos de la nube y de PaaS en especial: evitar tener que administrar estos detalles. El servicio de almacenamiento en caché de Windows Server AppFabric le quita esta carga, a la vez que también acelera el rendimiento de las aplicaciones web de ASP.NET que se ejecutan en Windows Azure con muy pocos cambios, o ninguno, en el código y la configuración. En el resto de este artículo le mostraremos cómo hacer esto.

Aspectos técnicos

Ahora que comprende cómo el almacenamiento en caché puede ser una opción de diseño estratégica para la aplicación, hagamos un análisis un poco más profundo respecto de cómo se ve realmente el servicio de almacenamiento en caché. Tomemos un ejemplo de un sitio web de compras típico, como un sitio de e-commerce que vende juegos para Xbox y de PC, y lo usaremos para comprender los diversos componentes del servicio de almacenamiento en caché.

En un nivel alto, existen tres piezas clave en este rompecabezas:

• cliente de caché;
• servicio de almacenamiento en caché;
• conexión entre el cliente y el servicio.

El cliente de caché es el proxy que reside dentro de la aplicación; en este caso, el sitio web de compras. Es la parte del código que sabe cómo comunicarse con el servicio de almacenamiento en caché en un lenguaje que ambos conocen bien. Necesita incluir este ensamblado de cliente en la aplicación e implementarlo con su aplicación web con la configuración adecuada para poder detectar y comunicarse con el servicio de almacenamiento en caché. (Más adelante en este artículo abarcaremos este proceso).

Como existen algunos patrones de aplicaciones comunes, como el estado de sesión ASP.NET, donde el almacenamiento en caché se puede usar de manera estándar, hay dos maneras de usar el cliente.

Para la programación explícita contra las API de caché, incluya el ensamblado de cliente de caché en la aplicación desde el SDK y podrá comenzar a realizar llamadas GET/PUT para almacenar y recuperar datos desde la memoria caché. Esta es una buena manera de almacenar el catálogo de juegos u otros datos de referencia para el sitio web de juegos.

Para escenarios de nivel superior que, a su vez, usan la memoria caché, debe incluir el proveedor de estado de sesión de ASP.NET para el servicio de almacenamiento en caché e interactuar con las API de estado de sesión en lugar de interactuar con las API de almacenamiento en caché. El proveedor de estado de sesión se encarga del trabajo pesado de llamar a las API de almacenamiento en caché adecuadas para mantener el estado de sesión en el nivel de la memoria caché. Esta es una buena manera de almacenar información como las preferencias de usuario, el carro de la compra, el historial de exploración de los juegos, etc., en el estado de sesión sin escribir siquiera una línea de código de caché.

Puede mantener prácticamente cualquier objeto en la memoria caché: texto, datos, blobs, objetos CLR, etc. Tampoco hay restricciones para el tamaño del objeto. Por lo tanto, ya sea que esté almacenando en caché objetos explícitos o estados de sesión, el tamaño del objeto no es una consideración para elegir si puede usar o no el servicio de almacenamiento en caché en su aplicación.

Un aspecto que se tener en cuenta acerca del servicio de almacenamiento en caché es que es una memoria caché explícita en la que escribe y que tiene el control completo sobre ella. No es un nivel de caché transparente sobre la base de datos o el almacenamiento. Tiene el beneficio de proporcionar un control completo sobre los datos que se almacenan y administran en la memoria caché, pero también significa que debe programar contra la memoria caché como un almacén de datos independiente mediante el uso de las API de caché.

Este patrón normalmente se conoce como “cache-aside”, en el que primero carga los datos en la memoria caché y luego comprueba si existen ahí para recuperarlos y, solo cuando no están disponibles, lee explícitamente los datos desde el nivel de datos. De esta manera, como desarrollador, debe aprender el modelo de programación de caché, las API y sugerencias y trucos comunes que hacen que el uso de la memoria caché sea eficiente.

Otro aspecto que se debe saber sobre el cliente de caché es la capacidad de almacenar en caché un subconjunto de datos que residen en los servidores de caché distribuida, directamente en el cliente, es decir, el servidor web que ejecuta el sitio web de juegos en nuestro ejemplo. Esta característica normalmente se conoce como la memoria caché local y está habilitada con una configuración simple que le permite especificar el número de objetos que desea administrar y los ajustes de tiempo de espera para invalidar la memoria caché.

La segunda pieza clave del rompecabezas es el servicio de almacenamiento en caché mismo. Considere el servicio de almacenamiento en caché como que Microsoft ejecuta un conjunto de clústeres de caché de gran tamaño para usted, optimizado intensamente para obtener rendimiento, tiempo de actividad, resistencia y escalamiento horizontal y expuesto solo como un simple servicio de red con un extremo para que usted realice llamadas. El servicio de almacenamiento en caché es un servicio multiempresa altamente disponible sin sobrecarga de administración para sus usuarios.

Como usuario, recibe un extremo seguro de Windows Communication Foundation (WCF) con el que comunicarse y la cantidad de memoria utilizable que necesita para la aplicación y las API del cliente de caché al que llamar para almacenar y recuperar datos. La clave aquí es la memoria utilizable. Si pide una memoria caché de 1 GB, obtiene 1 GB de memoria utilizable para almacenar los objetos, a diferencia de la cantidad de memoria disponible en una instancia de Windows Azure que compra. El servicio de almacenamiento en caché hace el trabajo de agrupar la memoria desde el clúster distribuido de máquinas que ejecuta y administra a fin de proporcionar la cantidad de memoria utilizable que necesita. Como resultado, también proporciona automáticamente la flexibilidad de escalar verticalmente hacia arriba o hacia abajo según sus necesidades de caché mediante un cambio simple en la configuración. En ese sentido, considere el servicio de almacenamiento en caché como un grupo virtual de memoria particionada y compartida que puede usar de manera flexible.

El otro punto de diseño bajo la superficie que se debe comprender es que el servicio de almacenamiento en caché particiona automáticamente la memoria caché para que no pierda datos frente a la eventualidad de que un equipo deje de funcionar, incluso si no ha adquirido la opción de alta disponibilidad (HA) más cara para la memoria caché. (La opción HA no está disponible actualmente en almacenamiento en caché de Windows Azure AppFabric, y solo se encuentra disponible en almacenamiento en caché de Windows Server AppFabric). Este esquema de partición aumenta el rendimiento y disminuye automáticamente la probabilidad de pérdida de datos sin tener que saber lo que ocurre con el servicio back-end.

La tercera y última pieza del rompecabezas es la conexión entre el cliente de caché y el servicio de almacenamiento en caché. La comunicación entre el cliente de caché y el servicio usa WCF y el modelo de programación de WCF se extrae del desarrollador mientras el cliente de caché traduce las llamadas GET/PUT a un protocolo WCF que comprende el servicio. Lo que debe saber sobre este canal de comunicación es que es seguro, lo que es muy importante, en especial en el mundo de la nube. La memoria caché se protege con un token de servicio de control de acceso (el que obtiene cuando se crea la memoria caché denominada). El servicio de almacenamiento en caché usa este token para restringir el acceso a los datos en caché por parte del cliente.

Pautas de arquitectura

Hemos pasado mucho tiempo con clientes que tienen distintos grados de complejidad en las aplicaciones. Normalmente, antes de comenzar a diagramar la arquitectura y las opciones de diseño, dibujaremos el diagrama simple que aparece en la figura 1. En la mayoría de los casos, este diagrama captura las desventajas entre los tres elementos más básicos que participan en el almacenamiento y la manipulación de datos. (Hemos tenido algunos expertos en almacenamiento que han discutido con nosotros respecto a que ellos pueden saturar la red antes de poder obtener el máximo rendimiento del disco, de ahí que calificamos la afirmación sobre “la mayoría” de los casos).

Figura 1 Uso de memoria, red y disco en escenarios de manipulación de datos

El principio básico es que la memoria en la máquina local proporciona el acceso a datos más rápido sin la más mínima latencia, pero se limita a la cantidad de memoria utilizable en la máquina. Apenas necesite más memoria de la que puede ofrecer su máquina local o necesite externalizar los datos desde su nivel de cálculo (ya sea para estado compartido o para obtener más durabilidad), el precio mínimo que paga es por el salto de la red. Lo más lento en este espectro es almacenar datos en un disco (las unidades de estado sólido ayudan un poco, pero todavía son muy caras).

El disco es el almacén más barato y mayor tamaño, mientras que la memoria es el más caro y, por consiguiente, el más restringido en términos de capacidad. El servicio de almacenamiento en caché equilibra los diversos elementos al prestar el servicio como un servicio de red para obtener acceso a un buen fragmento de memoria distribuida y compartida en varios niveles de cálculo. Al mismo tiempo, proporciona una optimización con la característica de caché local para permitir que un subconjunto de los datos resida adicionalmente en la máquina virtual mientras se elimina la complejidad de mantener la coherencia entre la memoria caché local y el nivel de caché en el servicio.

Con estos antecedentes, echemos un vistazo a algunas consideraciones de arquitectura de nivel superior para el uso de caché en la aplicación.

¿Qué datos debiera poner en la memoria caché? La respuesta varía considerablemente con el diseño general de la aplicación. Cuando hablamos de datos para escenarios de almacenamiento en caché, normalmente desglosamos los tipos de datos y los patrones de acceso que aparecen en la figura 2 (consulte msdn.microsoft.com/library/ee790832 para obtener una explicación más profunda de estos patrones de acceso a datos).

Figura 2 Datos en escenarios de almacenamiento en caché

Tipo de datos	Patrón de acceso
Referencia	Lectura compartida
Actividad	Escritura exclusiva
Recurso	Recurso compartido, en el que se lee y escribe simultáneamente, y al que obtienen acceso un gran número de transacciones

Mediante el uso de este modelo para pensar en sus datos, puede prepararse para los patrones de acceso y capacidad (para administrar la coherencia, expulsión, actualizaciones, etc.) y restringir los datos a los datos usados con mayor frecuencia o a los limitados por el tiempo que la aplicación usa o genera.

Como ejemplo, los datos de referencia deben ser particionados fácilmente en datos frecuentemente accedidos frente a accedidos con menor frecuencia para dividirlos entre memoria caché y almacenamiento. Los datos de recurso son un ejemplo clásico en el que desea acomodar el máximo posible en la memoria caché para obtener el máximo de beneficios de escalamiento y rendimiento. Además del nivel de caché, incluso el uso de la memoria caché local en el cliente va de la mano con el tipo de datos. Los datos de referencia son grandes candidatos para mantenerlos en la memoria caché local o en ubicaciones compartidas con el cliente; mientras que, en la mayoría de los casos, los datos de recurso pueden convertirse en muy complejos para la memoria caché local debido a actualizaciones frecuentes y, por consiguiente, se adaptan mejor en el nivel de caché.

Como el segundo recurso más caro y normalmente el cuello de botella para la mayoría de las implementaciones ineficientes, los patrones de tráfico de red para obtener acceso a datos de caché son algo a lo que se debe poner especial atención. Si tiene una gran cantidad de objetos pequeños y no optimiza la frecuencia y cantidad de los objetos que captura, fácilmente puede hacer que su aplicación esté enlazada a la red. El uso de etiquetas para capturar dichos datos o el uso de la memoria caché para mantener una gran cantidad de pequeños objetos de acceso frecuente es una gran desventaja.

Mientras que la opción de habilitar HA para una caché denominada no esté disponible todavía en el servicio de almacenamiento en caché, existe otro factor que hay que tomar en consideración en el diseño de la aplicación. Algunos desarrolladores y arquitectos eligen usar la memoria caché solo como una caché transitoria. Sin embargo, otros han realizado un acto de fe respecto de decidir exclusivamente almacenar un subconjunto de sus datos (normalmente datos de actividad) solo en la memoria caché mediante la habilitación de la característica de HA. HA tiene costos generales, pero proporciona un modelo de diseño que considera la memoria caché como el único almacén de datos, con lo que se elimina la necesidad de administrar varios almacenes de datos.

Sin embargo, la memoria caché no es una base de datos. No podemos enfatizar esta afirmación lo suficiente. El tema de HA normalmente hace parecer que la memoria caché puede reemplazar el nivel de datos. Esto no es así: una base de datos SQL está optimizada para un conjunto de patrones distinto del para el cual está diseñado el nivel de caché. En la mayoría de los casos, ambos resultan necesarios y se pueden emparejar para ofrecer los mejores patrones de acceso y rendimiento, a la vez que los costos se mantienen bajos.

¿Qué ocurre con el uso de la memoria caché para la agregación de datos? Este es un escenario poderoso, pero que normalmente se pasa por alto. En la nube, las aplicaciones a menudo tratan con datos provenientes de diversos orígenes y los datos no solo deben ser agregados, sino que también normalizados. La memoria caché ofrece una alternativa eficiente y de alto rendimiento para almacenar y administrar estos datos agregados con normalización de alto rendimiento (en memoria, en oposición a leer desde un disco y escribir en uno) y la estructura de datos normalizados de la memoria caché que usa pares de valor clave es una excelente manera de pensar cómo almacenar y atender estos datos agregados.

Un problema común al que se deben enfrentar los desarrolladores y arquitectos de aplicaciones es la falta de garantías respecto de que un cliente se enrutará siempre al mismo servidor que atendió la solicitud anterior. Cuando estas sesiones no puedan ser permanentes, necesitará decidir qué almacenar en estado de sesión y cómo devolver respuestas entre servidores para solucionar la falta de sesiones permanentes. La memoria caché ofrece una atractiva alternativa al almacenamiento de cualquier estado compartido entre varios nodos de cálculo. (En este ejemplo, estos nodos serían servidores web, pero los mismos problemas se aplican a cualquier escenario de nivel de cómputo compartido). El nivel de caché mantiene automática y coherentemente el estado compartido para el acceso de parte de todos los clientes y, al mismo tiempo, no hay sobrecarga o latencia en tener que escribirlo en un disco (ya sea base de datos o archivos).

La desventaja que aquí se debe considerar es que si necesita un acceso de latencia ultra lento al estado compartido (por ejemplo, un estado de sesión en un sitio web de juegos en línea que hace seguimiento de las puntuaciones en tiempo real), puede que un nivel de caché externo no sea la mejor opción. Para la mayoría de los demás escenarios, usar el nivel de caché es una manera rápida y eficaz de tratar con este patrón de diseño, que elimina automáticamente la obsolencia de los datos.

Pero asegúrese de pasar el tiempo suficiente planeando la capacidad de su caché. El número de objetos, el tamaño de cada objeto, la frecuencia de acceso de cada objeto y el patrón para obtener acceso a estos objetos son elementos esenciales no solo para determinar cuánta memoria caché necesita para la aplicación, sino que también qué niveles se deben optimizar (caché local, red, nivel de caché, uso de regiones y etiquetas, etc.). Recuerde que puede comenzar con un simple modificador de configuración en el archivo web.config para comenzar a usar el almacenamiento en caché sin tener que escribir siquiera una línea de código, y puede pasar años diseñando una solución que use el almacenamiento en caché de la manera más eficiente.

Configuración de almacenamiento en caché de AppFabric

Para comenzar a usar el servicio de almacenamiento en caché de Windows Azure AppFabric, vaya a portal.appfabriclabs.com. Este es el portal de CTP que puede usar para familiarizarse con el servicio de almacenamiento en caché. No tiene ningún costo, pero no hay ningún contrato de nivel de servicio para el servicio.

En el portal, seleccione la opción Cache (Memoria caché) y cree una nueva memoria caché mediante un clic en New Namespace (Nuevo espacio de nombres). La figura 3 muestra el cuadro de diálogo para configurar el espacio de nombres de servicio de la memoria caché.

Figura 3 Configuración de un nuevo espacio de nombres de servicio de la memoria caché

Las dos únicas opciones que debe especificar son un espacio de nombres de servicio único y el tamaño de la memoria caché (para el que puede elegir entre 128 MB y 256 MB en el CTP). Cuando elija OK (Aceptar), el servicio le proveerá la memoria caché en segundo plano. Normalmente, esto demora entre 10 y 15 segundos. Cuando termine, tendrá una memoria caché completamente funcional y distribuida disponible para sus aplicaciones.

Ahora que está creada, puede echar un vistazo a las propiedades de la memoria caché, las que aparecen en la figura 4. (Observe que ocultamos cierta información específica de la cuenta).

Figura 4 Propiedades del servicio de caché

Puede ver que hemos creado una memoria caché mediante el uso del espacio de nombres de CachingDemo. Debiera capturar ciertas partes de información importante, puesto que las usaremos posteriormente en nuestro código: la dirección URL del servicio y el token de autenticación. La dirección URL del servicio es el extremo de TCP al que se conectará la aplicación cuando interactúe con el servicio de almacenamiento en caché. El token de autenticación es un token cifrado que transmitirá al control de acceso para autenticar el servicio.

Almacenamiento en caché en la aplicación

Ahora, antes de comenzar a codificar, descargue el SDK de Windows Azure AppFabric. Puede encontrarlo en go.microsoft.com/fwlink/?LinkID=184288 o puede hacer clic en el vínculo que aparece en el portal.

Asegúrese de que la memoria caché de Windows Server AppFabric todavía no esté instalada en la máquina. A pesar de que la API es simétrica, los ensamblados actuales no son compatibles. La memoria caché de Windows Server AppFabric registra sus ensamblados de almacenamiento en caché en la memoria caché global de ensamblados (GAC), por lo que la aplicación cargará los ensamblados erróneos. Esto se resolverá en el momento en que el servicio pase a producción pero, por ahora, provoca un poco de dificultades.

Para comenzar, creemos una aplicación de consola simple con C#. Una vez que se cree, asegúrese de actualizar el proyecto para que apunte a Microsoft .NET Framework completo en lugar de hacerlo al perfil de cliente. También deberá agregar los ensamblados de almacenamiento en caché, los que normalmente se encuentran en C:\Archivos de programa\Windows Azure AppFabric SDK\V2.0\Assemblies\Cache. De momento, agregue los dos siguientes ensamblados:

• Microsoft.ApplicationServer.Caching.Client
• Microsoft.ApplicationServer.Caching.Core

Algo que cambió entre el CTP de octubre y la actualización de febrero es que ahora debe usar System.Security.SecureString para el token de autenticación. El propósito de SecureString es evitar que ponga la contraseña o el token en la memoria dentro de la aplicación para que así se mantenga más seguro. Sin embargo, para hacer que esto funcione en una aplicación de consola simple, tendrá que crear el siguiente método:

static private SecureString Secure(string token) {
  SecureString secureString = new SecureString();
  foreach (char c in token) {
    secureString.AppendChar(c);
  }
  secureString.MakeReadOnly();
  return secureString;
}

A pesar de que esto frustra el propósito de SecureString al obligarle a cargar el token en la memoria, solo se usa en este escenario simple.

Lo siguiente que se debe hacer es escribir el código que nos permitirá interactuar con el servicio de almacenamiento en caché. La API usa un patrón de fábrica, por lo que tendremos que definir la fábrica, definir ciertos ajustes y luego cargar nuestra memoria caché predeterminada, tal como se muestra en la figura 5.

Figura 5 Carga de la memoria caché predeterminada

private static DataCache configureDataCache(
  SecureString authorizationToken, string serviceUrl) {

  // Declare an array for the cache host 
  List<DataCacheServerEndpoint> server = 
    new List<DataCacheServerEndpoint>();
  server.Add(new DataCacheServerEndpoint(serviceUrl, 22233));

  // Set up the DataCacheFactory configuration
  DataCacheFactoryConfiguration conf = 
    new DataCacheFactoryConfiguration();
  conf.SecurityProperties = 
    new DataCacheSecurity(authorizationToken);
  conf.Servers = server;

  // Create the DataCacheFactory based on config settings 
  DataCacheFactory dataCacheFactory = 
    new DataCacheFactory(conf);

  // Get the default cache client 
  DataCache dataCache = dataCacheFactory.GetDefaultCache();

  // Return the default cache
  return dataCache;
}

Puede ver que hemos definido un nuevo DataCacheServerEndpoint basado en una dirección URL de servicio (que proporcionaremos) que apunta al puerto 22233. A continuación, creamos la DataCacheFactoryConfiguration, introducimos nuestro token de autenticación (que es una SecureString) y lo definiremos en las propiedades de seguridad; esto nos permitirá autenticarnos al servicio. En este punto, es simplemente materia de construir la DataCacheFactory, obtener la DataCache en base a la memoria caché predeterminada y devolver la memoria caché predeterminada.

A pesar de que no es necesario encapsular esta lógica en su propio método, más adelante resulta mucho más conveniente.

En este punto, es muy simple introducir todo esto en el método Main de nuestra aplicación (consulte la figura 6).

Figura 6 Método Main (Principal) de aplicación de consola

static void Main(string[] args) {
  // Hardcode your token and service url
  SecureString authorizationToken = 
    createSecureString("YOURTOKEN");
  string serviceUrl = "YOURCACHE.cache.appfabriclabs.com";

  // Create and return the data cache
  DataCache dataCache = 
    configureDataCache(authorizationToken, serviceUrl);

  // Enter a value to store in the cache
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();

  // Put your value in the cache
  dataCache.Put("key", value);

  // Get your value out of the cache
  string response = (string)dataCache.Get("key");

  // Write the value
  Console.WriteLine("Your value: " + response);
}

Proporcionamos el token de autenticación y la dirección URL de servicio a nuestra aplicación, luego los transmitimos al método configureDataCache, el que define la variable DataCache en la memoria caché predeterminada. Aquí podemos capturar algunas entradas desde la consola y ponerlas en la memoria caché y luego llamar a Get en la clave, lo que devuelve el valor. Es una prueba simple pero válida de la memoria caché.

Incluir los tokens y la dirección URL de servicio en el código no es ideal. Afortunadamente, el portal proporciona un XML que se puede insertar dentro del archivo app.config (o web.config) y las API serán las que administren todos los elementos.

En el portal, seleccione la memoria caché y luego haga clic en el botón View Client Configuration (Ver configuración de cliente). Con esto se abre un cuadro de diálogo que proporciona el XML de configuración. Copie el fragmento de código XML y péguelo en el archivo de configuración. El resultado será semejante al de la figura 7.

Figura 7 Configuración de cliente

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section 
      name="dataCacheClient" 
      type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core" 
      allowLocation="true" 
      allowDefinition="Everywhere"/>
  </configSections>
  <dataCacheClient deployment="Simple">
    <hosts>
      <host 
        name="YOURCACHE.cache.appfabriclabs.com" 
        cachePort="22233" />
    </hosts>
    <securityProperties mode="Message">
      <messageSecurity
          authorizationInfo="YOURTOKEN">
      </messageSecurity>
    </securityProperties>
  </dataCacheClient>
</configuration>

Ahora podemos refactorizar considerablemente nuestro código, deshacernos de los métodos createSecureString y configureDataCache y quedarnos con lo siguiente:

static void Main(string[] args) {
  DataCacheFactory dataCacheFactory = 
    new DataCacheFactory();
  DataCache dataCache = dataCacheFactory.GetDefaultCache();
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();
  dataCache.Put("key", value);
  string response = (string)dataCache.Get("key");
  Console.WriteLine("Your value: " + response);
}

Puede ver que todo lo que tenemos que hacer es crear una instancia nueva de DataCacheFactory, y todos los ajustes de configuración en el archivo app.config se leen de manera predeterminada.

Como ve, puede usar las API directamente o administrar DataCacheFactory en la configuración. A pesar de que solo hemos realizado operaciones PUT y GET sobre datos simples, pudimos fácilmente almacenar datos recuperados desde SQL Azure, Windows Azure u otros proveedores de datos. Para obtener una vista más compleja del uso de la memoria caché para los datos de referencia almacenados en SQL Azure, consulte los Laboratorios prácticos del servicio de almacenamiento en caché en el curso de aprendizaje de la plataforma Windows Azure Platform.

Almacenamiento de datos de sesión

A continuación, echemos un vistazo a la manera de usar el servicio de almacenamiento en caché para almacenar los datos de sesión para nuestra aplicación web de ASP.NET. Esta es una técnica eficaz, puesto que nos permite separar el estado de sesión desde la memoria en proceso de cada uno de nuestros clientes web, lo que facilita escalar nuestras aplicaciones más allá de una instancia en Windows Azure.

Esto es importante para los servicios que no admiten sesiones permanentes, como Windows Azure. No hay manera de garantizar que un usuario alcanzará la misma instancia con cada solicitud adicional; de hecho, el equilibrador de carga de Windows Azure usa explícitamente un enfoque round-robin para el equilibrio de carga, por lo que es probable que el usuario alcance una instancia nueva. Mediante el uso del servicio de almacenamiento en caché para estado de sesión, no es importante qué instancia alcance el usuario, porque todas ellas son respaldadas por el mismo proveedor de estados de sesión.

Para comenzar, cree un nuevo proyecto de Windows Azure y agregue un rol web de ASP.NET. En el rol web, agregue todos los ensamblados que proporcione el SDK de Windows Azure AppFabric, entre los que se incluyen:

• Microsoft.ApplicationService.Caching.Client
• Microsoft.ApplicationService.Caching.Core
• Microsoft.Web.DistributedCache
• Microsoft.WindowsFabric.Common
• Microsoft.WindowsFabric.Data.Common

A continuación, actualice el archivo web.config para que lo primero que siga al elemento <configuration> sean los elementos <configSections> y <dataCacheClient> (recibirá errores si estos no son los primeros elementos).

Ahora, la clave para usar el servicio de almacenamiento en caché para estado de sesión es el ensamblado Microsoft.Web.DistributedCache. Este ensamblado contiene el proveedor de estado de sesión personalizado que usa el servicio de almacenamiento en caché. Vuelva al portal LABS donde capturó el XML para los archivos de configuración y busque el elemento <sessionState>; puede colocarlo directamente en el elemento <system.web> del archivo web.config y le indicará inmediatamente a su aplicación que comience a usar el servicio de almacenamiento en caché para estado de sesión:

<system.web>
  <sessionState mode="Custom" 
    customProvider="AppFabricCacheSessionStoreProvider">
    <providers>
      <add name="AppFabricCacheSessionStoreProvider"
        type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
        cacheName="default"
        useBlobMode="false" />
    </providers>
  </sessionState>
  ...
</system.web>

Para validar que esto esté funcionando, abra el archivo Global.asax.cs y agregue el siguiente código al método Session_Start:

void Session_Start(object sender, EventArgs e) {
  int i = 0;
  while (i < 10) {
    Session.Add(Guid.NewGuid().ToString(), DateTime.Now.ToString());
    i++;
  }
}

Esto agregará 10 elementos aleatorios al contexto de sesión. A continuación, abra la página Default.aspx.cs y actualice el método Page_Load:

protected void Page_Load(object sender, EventArgs e) {
  foreach (var key in Session.Contents) {
    Response.Write("key: " + key + ", guid: " + 
      Session[key.ToString()].ToString()  + "<br/>");
  }
}

Esto escribirá todos los valores que se agregaron al contexto de sesión. Finalmente, abra el archivo ServiceConfiguration.cscfg y aumente el número de instancias de 1 a 2:

<Instances count="2" />

Ahora, cuando presione F5, tendrá dos instancias de la aplicación que se ejecutarán en el emulador de cómputo. Observe que, independientemente de cuántas veces actualice la página, siempre tendrá los mismos 10 valores en el estado de sesión; esto ocurre porque es una sesión compartida y el inicio de sesión solo se ejecuta una vez. A la inversa, si no usa el servicio de almacenamiento en caché como proveedor de estado de sesión, sino que elige mantener la opción en proceso predeterminada, tendrá distintos valores en cada una de las instancias.

Siguientes pasos

Se espera que el servicio de almacenamiento en caché de Windows Azure AppFabric vaya a producción como servicio comercial durante el primer semestre de 2011. En la primera versión comercial, todavía no estarán disponibles algunas características que sí lo están en Windows Server AppFabric. Algunas de estas exclusiones se realizan a propósito, debido a que podrían no aplicarse en el mundo de la nube. Sin embargo, características como las notificaciones son importantes en Windows Azure además de ser críticas para completar el escenario de caché local y, por lo tanto, forman parte del mapa de ruta a corto plazo de Microsoft. De manera similar, la opción de habilitar HA para una caché denominada determinada como una capacidad premium también está en un lugar importante en la lista de prioridades.

La creciente popularidad del almacenamiento en caché de Windows Server AppFabric ha generado varias solicitudes de características nuevas que abren la aplicabilidad de almacenar en caché un conjunto de escenarios incluso más amplio. Algunas de las capacidades que se analizan incluyen la capacidad de realizar consultas enriquecidas en la memoria caché y la habilitación de una manera más fácil de recuperar datos masivos desde una caché denominada.

Además, el éxito de los escenarios de proveedor de estado de sesión de almacenamiento en caché con ASP.NET ha generado solicitudes para la capacidad de asociar consultas subyacentes de escritura y a través de lectura con la memoria caché, para que esta pueda convertirse en la manera principal de manipular datos, mientras que se permite que las consultas asociadas actualicen el nivel de datos en el back-end.

Evaluaremos la posible inclusión de estas y otras características en futuras versiones del almacenamiento en caché de Windows Azure AppFabric. Mientras tanto, le invitamos a experimentar con la implementación actual del servicio de almacenamiento en caché y a informarnos cómo funciona para usted.

Karandeep Anand es administrador de programa principal para el grupo de productos de AppFabric en Microsoft. Su equipo es responsable de crear los servicios y plataformas de aplicación de nueva generación para Windows Server y la plataforma Windows Azure. Puede ponerse en contacto con él en Karandeep.Anand@microsoft.com.

Wade Wegner es técnico experto de Microsoft, responsable de influir y conducir la estrategia técnica de Microsoft para la plataforma Windows Azure. Puede ponerse en contacto con él a través de su blog en wadewegner.com o por Twitter en twitter.com/WadeWegner.