Cache na nuvem

  • Artigo

Apresentando o Serviço de Cache do Windows Azure AppFabric

Karandeep Anand

Em um mundo no qual a velocidade e o dimensionamento são as principais métricas de sucesso de qualquer solução, eles não podem ser deixados para depois nem adaptados para uma arquitetura de aplicativo — a velocidade e o dimensionamento devem ser os princípios de design centrais quando você ainda estiver em seu quadro criando a arquitetura de seu aplicativo.

O Serviço de Cache do Windows Azure AppFabric fornece os blocos de construção necessários para simplificar esses desafios sem ter de aprender como implantar e gerenciar outra camada na arquitetura de seu aplicativo. Em resumo, o Serviço de Cache é a memória elástica de que seu aplicativo necessita para aumentar o desempenho e a produtividade diminuindo a pressão da camada de dados e do estado distribuído, de forma que seu aplicativo consiga dimensionar a camada do computador com facilidade.

O Serviço de Cache foi lançado como um CTP (Community Technology Preview) na Microsoft Professional Developers Conference em 2010 e foi atualizado em fevereiro de 2011.

O Serviço de Cache é uma parte importante da plataforma Windows Azure e baseia-se nas ofertas de PaaS (Platform as a Service) que já compõem a plataforma. O Serviço de Cache baseia-se na mesma base de código que o Cache do Windows Server AppFabric e, consequentemente, ele possui uma experiência de desenvolvedor simétrica à do cache local.

O Serviço de Cache oferece aos desenvolvedores os seguintes recursos:

  • Provedores ASP.NET pré-criados de estado de sessão e de cache de saída de página, o que permite a aceleração de aplicativos Web sem ter de modificar o código do aplicativo.
  • Cache de qualquer objeto gerenciado — sem limite de tamanho de objeto e sem custos de serialização para o cache local.
  • Fácil integração com aplicativos existentes.
  • Modelo de desenvolvimento consistente no Windows Azure AppFabric e no Windows Server AppFabric.
  • Acesso protegido e autorização fornecidos pelo serviço Controle de Acesso.

Embora seja possível configurar outras tecnologias de cache, como memcached, por conta própria como instâncias na nuvem, você acabaria instalando, configurando e gerenciando os clusters e as instâncias de cache sozinho. Isso padroniza um dos principais objetivos da nuvem e, em particular, do PaaS: evitar o gerenciamento desses detalhes. O Serviço de Cache do Windows Server AppFabric tira essa carga de você e, ao mesmo tempo, acelera o desempenho de aplicativos Web ASP.NET em execução no Windows Azure com pouco ou nenhum código ou alterações na configuração. Vou lhe mostrar como isso é feito no restante deste artigo.

Nos bastidores

Agora que você sabe como o cache pode ser uma escolha de design estratégica para seu aplicativo, vamos nos aprofundar na aparência do Serviço de Cache. Vamos usar como exemplo um típico site de compras na Web, digamos um site de comércio eletrônico que vende o Xbox e jogos para PC, e vamos usar isso para compreender as várias partes do Serviço de Cache.

Em um nível alto, existem três peças no quebra-cabeça:

  • Cliente de cache
  • Serviço de cache
  • Conexão entre o cliente e o serviço

O cliente de cache é o proxy que reside em seu aplicativo — neste caso, o site de compras. É a parte de código que sabe como conversar com o serviço de cache, em uma linguagem que ambos compreendem. Você deve incluir esse assembly de cliente em seu aplicativo e implantá-lo no aplicativo Web com a configuração apropriada para se capaz de descobrir e conversar com o Serviço de Cache. (Abordarei esse processo mais adiante neste artigo.)

Como existem alguns padrões de aplicativos comuns, como o estado de sessão ASP.NET, no qual o cache pode ser usado imediatamente, há duas maneiras de utilizar o cliente.

Para uma programação explícita em relação a APIs do cache, inclua o assembly de cliente do cache em seu aplicativo a partir do SDK e comece a fazer chamadas GET/PUT para armazenar e recuperar dados do cache. Essa é uma boa maneira de armazenar seu catálogo de jogos ou outros dados de referência para seu site de jogos.

Em cenários de nível superior que utilizam o cache, você deve incluir o provedor de estado de sessão ASP.NET do Serviço de Cache e interagir com as APIs de estado de sessão, em vez de interagir com as APIs de cache. O provedor de estado de sessão faz o trabalho pesado de chamar as APIs de cache apropriadas para manter o estado de sessão na camada de cache. Essa é uma boa maneira de você armazenar informações como preferências do usuário, carrinho de compras, histórico de navegação de jogos, entre outras, no estado de sessão sem escrever nenhuma linha de código de cache.

Você realmente pode manter qualquer objeto no cache: texto, dados, blobs, objetos CLR e outros. E também não existem restrições quanto ao tamanho do objeto. Portanto, independentemente de estar armazenando objetos explícitos no cache ou armazenando o estado da sessão, o tamanho do objeto não é uma consideração a ser escolhida se você pode usar o Serviço de Cache em seu aplicativo.

Algo a ser observado sobre o Serviço de Cache é que ele é um cache explícito no qual é possível gravar e do qual você tem total controle. Ele não é uma camada de cache transparente sobre seu banco de dados ou armazenamento. Isso possui o benefício de fornecer controle total sobre quais dados são armazenados e gerenciados no cache, mas também significa que você tem de programar no cache como um armazenamento de dados separado usando as APIs do cache.

Esse padrão geralmente é referenciado como cache-aside, no qual você primeiro carrega os dados no cache; em seguida, verifica se eles estão disponíveis para serem recuperados lá e, apenas quando não estiverem disponíveis, você os lê explicitamente da camada de dados. Por isso, como desenvolvedor, você deve aprender o modelo de programação de cache, as APIs e as dicas e os truques comuns para tornar eficiente a utilização do cache.

Outro ponto a ser observado sobre o cliente do cache é a capacidade de armazenar em cache um subconjunto dos dados que residem nos servidores de cache distribuídos, diretamente no cliente — o servidor Web executando o site de jogos de nosso exemplo. Esse recurso é popularmente conhecido como cache local e é habilitado com uma definição de configuração simples que permite que você especifique a quantidade de objetos que deseja armazenar, bem como as configurações de tempo limite para invalidar o cache.

A segunda peça importante do quebra-cabeça é o próprio Serviço de Cache. Imagine o Serviço de Cache como a Microsoft executando um grande conjunto de clusters de cache para você, altamente otimizado quanto ao desempenho, ao tempo de ativação, à resiliência e ao dimensionamento e exposto apenas como um serviço de rede simples com um ponto de extremidade para você chamar. O Serviço de Cache é um serviço de multilocatário altamente disponível sem sobrecarga de gerenciamento para seus usuários.

Como usuário, você obtém um ponto de extremidade seguro do WCF (Windows Communication Foundation) com o qual conversar, além da quantidade de memória utilizável de que necessita para seu aplicativo e as APIs para o cliente de cache chamar a fim de armazenar e recuperar dados. O importante aqui é a memória utilizável. Se você solicitar 1 GB de memória cache, você obterá 1 GB de memória utilizável para armazenar seus objetos, de maneira diferente da quantidade de memória disponível em uma instância do Windows Azure que você comprar. O Serviço de Cache faz o trabalho de pooling na memória a partir do cluster distribuído das máquinas que está executando e gerenciando a fim de fornecer a quantidade de memória utilizável de que você necessita. Como resultado, ele também fornece automaticamente flexibilidade para realizar o dimensionamento com base nas necessidades de seu cache com uma simples alteração na configuração. Dessa maneira, imagine o Serviço de Cache como um pool virtual de memória particionada e compartilhada que você pode consumir de maneira flexível.

O outro ponto de design dos bastidores a ser compreendido é que o Serviço de Cache particiona automaticamente seu cache de forma que você não perca dados no caso de inatividade de uma máquina, mesmo se você não tiver comprado a opção de alta disponibilidade (ou HA, high availability) mais cara para seu cache. A opção de HA não está disponível atualmente no Cache do Windows Azure AppFabric e será disponibilizada apenas para o Cache do Windows Server AppFabric hoje. Esse esquema de particionamento aumenta o desempenho e diminui a probabilidade de perda de dados automaticamente para você, sem que tenha de aprender sobre o serviço back-end.

A terceira e última peça do quebra-cabeça é a conexão entre seu cliente de cache e o Serviço de Cache. A comunicação entre o cliente de cache e o serviço ocorre por meio do WCF, e o modelo de programação do WCF é extraído do desenvolvedor enquanto o cliente de cache converte as chamadas GET/PUT em um protocolo do WCF que o serviço compreende. O que você precisa saber sobre esse canal de comunicação é que ele é seguro, o que é essencial, especialmente no mundo da nuvem. O seu cache é protegido por meio de um token (obtido quando você cria o cache nomeado) do serviço Controle de Acesso. O Serviço de Cache utiliza esse token para restringir o acesso aos seus dados armazenados em cache por seu cliente.

Diretrizes de arquitetura

Nós gastamos muito tempo com clientes que possuem níveis variados de complexidade de aplicativos. Geralmente, antes de começarmos a apresentar as opções de design e a arquitetura, nós desenhamos o diagrama simples mostrado na Figura 1. Na maioria dos casos, esse diagrama apresenta as contrapartidas entre os três elementos mais básicos envolvidos no armazenamento e na manipulação de dados. (Tivemos algumas discussões com alguns gurus do armazenamento sobre o fato de que eles podem saturar a rede antes de conseguirem maximizar a taxa de transferência do disco e, por isso, qualificamos a afirmação como na “maioria” dos casos.)

image: Memory, Network and Disk Usage in Data Manipulation Scenarios

Figura 1 Utilização de memória, rede e disco em cenários de manipulação de dados

O princípio básico é que a memória de sua máquina local fornece o acesso a dados mais rápido com a menor latência, mas está limitado à quantidade de memória utilizável da máquina. No instante em que precisar de mais memória do que sua máquina local pode lhe fornecer ou precisar externalizar os dados da camada de seu computador (para o estado compartilhado ou para mais durabilidade), o preço mínimo que você pagará será pelo salto de rede. O mais lento nesse espectro é o armazenamento de dados em um disco (unidades de estado sólido ajudam um pouco, mas ainda são bastante caras).

O disco é o maior e mais barato armazenamento, ao passo que a memória é a mais cara e, por isso, a mais restrita em termos de capacidade. O Serviço de Cache equilibra os vários elementos fornecendo o serviço como um serviço de rede a fim de acessar uma grande parte de memória distribuída e compartilhada em várias camadas de computação. Simultaneamente, ele fornece uma otimização no recurso de cache local a fim de habilitar um subconjunto dos dados para residirem adicionalmente na máquina local e, ao mesmo tempo, remove a complexidade de manter a consistência entre o cache local e a camada de cache no serviço.

Com esse histórico, vejamos algumas considerações de arquitetura de alto nível para usar o cache em seu aplicativo.

Quais dados você deve armazenar no cache? A resposta varia significativamente de acordo com o design geral de seu aplicativo. Quando falamos de dados de cenários de cache, geralmente, nós os dividimos em tipos de dados e padrões de acesso, conforme mostrado na Figura 2 (consulte msdn.microsoft.com/library/ee790832 para obter uma explicação mais detalhada desses padrões de acesso a dados).

Figura 2 Dados em cenários de cache

Tipo de dados Padrão de acesso
Referência Leitura compartilhada
Atividade Gravação exclusiva
Recurso Compartilhado, leitura e gravação simultâneas, acessado por um grande número de transações

Ao usar esse modelo para pensar sobre seus dados, você pode planejar a capacidade e os padrões de acesso — para gerenciar a consistência, a remoção, as atualizações, e assim por diante — e pode restringir os dados utilizados com mais frequência ou os dados suscetíveis ao tempo utilizados ou gerados por seu aplicativo.

Como exemplo, os dados de referência devem ser imediatamente particionados em acessados com bastante frequência versus acessados com pouca frequência a fim de dividir entre cache e armazenamento. Os dados do recurso é um exemplo clássico no qual você deseja inserir o máximo possível no cache para obter o máximo de benefícios de dimensionamento e desempenho. Além da camada de cache, até mesmo o uso do cache local no cliente anda de mãos dadas com o tipo de dados. Os dados de referência são excelentes candidatos a serem mantidos no cache local ou colocalizados com o cliente. Ao mesmo tempo, na maioria dos casos, os dados do recurso podem se tornar bastante prolixos para o cache local devido às frequentes atualizações e, por isso, são mais indicados para a camada de cache.

Como segundo recurso mais caro e, normalmente, o obstáculo das implementações mais ineficientes, os padrões de tráfego de rede para acessar dados do cache são um ponto a que você deve dar especial atenção. Se tiver um grande número de objetos pequenos e não fizer a otimização em relação à frequência e à quantidade de dados buscados, seu aplicativo poderá facilmente chegar aos limites da rede. O uso de marcas para serem buscadas como dados ou o uso do cache local para manter uma grande quantidade de objetos pequenos acessados com frequência é uma excelente contrapartida.

Como a opção de habilitar a HA para um cache nomeado ainda não está disponível no Serviço de Cache, esse é outro fator a ser considerado no design de seu aplicativo. Alguns desenvolvedores e arquitetos preferem usar o cache apenas como um cache transitório. Entretanto, outros deram um salto de confiança para passar exclusivamente para o armazenamento de um subconjunto de seus dados (normalmente, dados de atividade) apenas no cache por meio da habilitação do recurso de HA. A HA tem um custo adicional, mas ela fornece um modelo de design que trata o cache como o único armazenamento de dados, eliminando a necessidade de gerenciar vários armazenamentos de dados.

No entanto, o cache não é um banco de dados! Não podemos enfatizar tanto esse ponto. O assunto HA geralmente faz parecer que o cache pode substituir sua camada de dados. Isso está longe de ser verdade — um banco de dados SQL é otimizado para um conjunto de padrões diferente daquele para o qual a camada do cache foi projetada. Na maioria dos casos, ambos são necessários e podem ser emparelhados a fim de fornecer os melhores padrões de acesso e desempenho e, ao mesmo tempo, manter os custos baixos.

Que tal usar o cache para agregação de dados? Esse é um cenário potente, mas geralmente esquecido. Na nuvem, os aplicativos frequentemente lidam com dados de várias fontes, e esses dados precisam ser agregados e também normalizados. O cache oferece uma alternativa eficiente e de alto desempenho para armazenar e gerenciar esses dados agregados com uma normalização de taxa de transferência alta (na memória, em oposição à leitura de disco e a gravação nele), e o uso de pares chave-valor na estrutura de dados normalizados do cache é uma excelente maneira de pensar como armazenar e atender a esses dados agregados.

Um problema comum que os desenvolvedores de aplicativos e os arquitetos têm de enfrentar é a falta de garantia de que um cliente sempre será roteado para o mesmo servidor que atendeu à solicitação anterior. Quando essas sessões não puderem ser adesivas, você terá de decidir o que será armazenado no estado da sessão e como devolver solicitações entre servidores a fim de solucionar a falta de sessões adesivas. O cache fornece uma alternativa atraente para armazenar qualquer estado compartilhado em vários nós de computação. (Esses nós deveriam ser servidores Web neste exemplo, mas os mesmos problemas são aplicáveis a qualquer cenário de camada de computação compartilhada.) O estado compartilhado é automaticamente mantido de forma consistente pela camada de cache para o acesso por todos os clientes e, ao mesmo tempo, não existe sobrecarga ou latência de ter de gravá-lo em um disco (banco de dados ou arquivos).

A contrapartida a ser considerada aqui é que, se você precisar de acesso com latência ultrabaixa para o estado compartilhado (estado de sessão em um site de jogos online que monitora as pontuações em tempo real, por exemplo), talvez uma camada de cache externo não seja a melhor opção. Para a maioria dos outros cenários, usar a camada de cache é uma maneira rápida e potente de lidar com esse padrão de design, que elimina automaticamente o envelhecimento de seus dados.

Certifique-se de gastar tempo suficiente no planejamento da capacidade de seu cache. A quantidade de objetos, o tamanho de cada objeto, a frequência de acesso de cada objeto e o padrão de acesso desses objetos são todos críticos na determinação da quantidade de cache de que você necessita para seu aplicativo e, também, para que camadas otimizar (cache local, rede, camada de cache, uso de regiões e marcas, entre outros). Lembre-se de que você pode iniciar com uma simples alteração de configuração no arquivo web.config para começar a usar o cache sem escrever nenhuma linha de código, além de que você pode gastar anos desenvolvendo uma solução que utilize o cache da maneira mais eficiente.

Configurando o Cache do AppFabric

Para começar a usar o Serviço de Cache do Windows Azure AppFabric, visite portal.appfabriclabs.com. Esse é o portal de CTP que você pode usar para se familiarizar com o Serviço de Cache. Não há nenhum custo associado a ele, mas também não existem contratos de nível de serviço para o serviço.

No portal, selecione a opção Cache e, em seguida, crie um novo cache clicando em New Namespace. A caixa de diálogo para configurar o namespace do serviço de cache está exibida na Figura 3.

image: Configuring a New Cache Service Namespace

Figura 3 Configurando um novo namespace de serviço de cache

As duas únicas opções que devem ser especificadas são um namespace de serviço exclusivo e o tamanho do cache, que pode ser 128 MB ou 256 MB no CTP. Ao clicar em OK, o serviço provisionará o cache para você em segundo plano. Isso geralmente leva de 10 a 15 segundos. Quando a ação for concluída, você terá um cache totalmente funcional e distribuído disponível para seus aplicativos.

Agora que já foi criado, você pode verificar as propriedades de seu cache, mostradas na Figura 4. Observe que algumas informações específicas da conta foram ofuscadas.

image: Cache Service Properties

Figura 4 Propriedades do serviço de cache

Você pode ver que nós criamos um cache usando o namespace CachingDemo. Existem algumas partes de informações importantes que você talvez queira coletar, pois iremos utilizá-las posteriormente em nosso código: a URL do serviço e o token de autenticação. A URL do serviço é o ponto de extremidade TCP ao qual seu aplicativo se conectará ao interagir com o Serviço de Cache. O token de autenticação é um token criptografado que você transmitirá para o Controle de Acesso a fim de autenticar seu serviço.

Cache em seu aplicativo

Agora, antes de começar a codificação, baixe o SDK do Windows Azure AppFabric. É possível encontrá-lo em go.microsoft.com/fwlink/?LinkID=184288 ou clicando no link no portal.

Certifique-se de que o Cache do Windows Server AppFabric não esteja instalado em sua máquina. Embora a API seja simétrica, os assemblies atuais não são compatíveis. O Cache do Windows Server AppFabric registra seus assemblies de cache no Cache de Assembly Global (ou GAC, Global Assembly Cache) e, por isso, seu aplicativo carregará os assemblies incorretos. Isso será resolvido no momento em que serviço passar para a produção, mas, por enquanto, isso causará um pouco de atrito.

Para começar, vamos criar um aplicativo de console simples usando C#. Após ser criado, certifique-se de atualizar o projeto para que seja destinado a todo o Microsoft .NET Framework, em vez de apenas ao Client Profile. Você também deverá adicionar os assemblies de cache que, normalmente, podem ser encontrados em C:\Arquivos de Programas\SDK do Windows Azure AppFabric\V2.0\Assemblies\Cache. Por enquanto, adicione os dois assemblies a seguir:

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

Uma mudança entre o CTP de outubro e a atualização de fevereiro é que, agora, você deve usar o System.Security.SecureString para o token de autenticação. A finalidade de SecureString é evitar que você tenha de inserir sua senha ou seu token na memória do aplicativo, mantendo-os mais seguros. Entretanto, para fazer isso funcionar em um aplicativo de console simples, você deve criar o seguinte método:

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

Embora anule a finalidade de SecureString forçando você a carregar o token na memória, ele é apenas utilizado nesse cenário simples.

Agora, a próxima etapa é escrever o código que nos configurará para interagir com o Serviço de Cache. A API utiliza um padrão de fábrica e, por isso, teremos de definir a fábrica, algumas configurações e, em seguida, carregar nosso cache padrão, conforme mostrado na Figura 5.

Figura 5 Carregando o cache padrão

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;
}

É possível verificar que definimos um novo DataCacheServerEndpoint com base em uma URL de serviço (que nós forneceremos) que aponta para a porta 22233. Em seguida, criamos DataCacheFactoryConfiguration, transmitimos nosso token de autenticação (que é uma SecureString) e o definimos para as propriedades de segurança — isso permitirá que nós façamos a autenticação no serviço. Nesse momento, é apenas uma questão de construir o DataCacheFactory, obtendo o DataCache com base no cache padrão e retornando o cache padrão.

Embora não seja obrigatório encapsular essa lógica em seu próprio método, isso a torna muito mais conveniente posteriormente.

Nesse ponto, é bastante simples reunir tudo isso no método Main de nosso aplicativo (verifique a Figura 6).

Figura 6 Método Main do aplicativo de console

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);
}

Nós fornecemos o token de autenticação e a URL de serviço para nosso aplicativo e, em seguida, os transmitimos para o método configureDataCache, que define a variável DataCache como o cache padrão. A partir daqui, podemos coletar algumas entradas do console, colocá-las no cache e, em seguida, chamar Get na chave, que retornará o valor. Esse é um teste de cache simples, porém válido.

Incluir os tokens e a URL de serviço no código não é o ideal. Felizmente, o portal fornece o XML que você pode inserir em seu arquivo app.config (ou web.config) e as APIs gerenciarão tudo para você.

No portal, selecione seu cache e, em seguida, clique no botão View Client Configuration. Isso abrirá uma caixa de diálogo com o XML de configuração. Copie o trecho de código XML e cole-o em seu arquivo de configuração. O resultado será semelhante ao exibido na Figura 7.

Figura 7 Configuração 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>

Agora, podemos refatorar nosso código, nos livrar dos métodos createSecureString e configureDataCache e obter isto:

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);
}

É possível verificar que tudo o que temos a fazer é criar uma nova instância de DataCacheFactory, e todas as definições da configuração no arquivo app.config serão lidas por padrão.

Como já foi visto, você pode usar as APIs diretamente ou gerenciar DataCacheFactory em sua configuração. Apesar de termos executado apenas as operações PUT e GET em dados simples, nós podemos armazenar facilmente dados recuperados do SQL Azure, do Windows Azure ou de outro provedor de dados. Para obter uma visão mais complexa sobre como usar o cache de dados de referência armazenados no SQL Azure, consulte Laboratório prático do Serviço de Cache no Curso de treinamento da Plataforma Windows Azure (msdn.microsoft.com/gg457894).

Armazenando dados de sessão

Agora, vejamos como usar o Serviço de Cache para armazenar os dados de sessão de nosso aplicativo Web ASP.NET. Essa é uma técnica avançada, pois ela permite separar o estado de sessão da memória em processo de cada um de nossos clientes Web, facilitando o dimensionamento de nossos aplicativos além de uma instância no Windows Azure.

Isso é importante para os serviços que não oferecem suporte a sessões adesivas, como o Windows Azure. Não existem maneiras de garantir que um usuário visitará uma mesma instância com cada solicitação adicional — na verdade, o balanceador de carga do Windows Azure utiliza explicitamente uma abordagem de rodízio para balancear as cargas e, por isso, é provável que seu usuário visite uma nova instância. Ao usar o Serviço de Cache para estado de sessão, não importa a instância que seu usuário visita, pois todas as instâncias são apoiadas pelo mesmo provedor de estado de sessão.

Para começar, crie um novo projeto do Windows Azure e adicione uma Web Role do ASP.NET. Na Web Role, adicione todos os assemblies fornecidos pelo SDK do Windows Azure AppFabric, incluindo:

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

Em seguida, atualize seu arquivo web.config para que as primeiras coisas a seguirem o elemento <configuration> sejam os elementos <configSections> e <dataCacheClient> — você receberá erros se eles não forem os primeiros elementos.

Agora, a chave para utilizar o Serviço de Cache de estado de sessão é o assembly Microsoft.Web.DistributedCache. Ela contém o provedor de estado de sessão personalizado que utiliza o Serviço de Cache. Volte ao portal LABS, onde você obteve o XML para seus arquivos de configuração, e localize o elemento <sessionState> — você pode colocá-la diretamente no elemento <system.web> de seu arquivo web.config e ela imediatamente informará a seu aplicativo para começar a aproveitar o Serviço de Cache de estado de sessão:

<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 isso está funcionando, abra o arquivo Global.asax.cs e adicione o seguinte código ao 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++;
  }
}

Isso adicionará 10 itens aleatórios no contexto de sua sessão. Em seguida, abra a página Default.aspx.cs e atualize o 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/>");
  }
}

Isso escreverá todos os valores que foram adicionados no contexto da sessão. Por fim, abra o arquivo ServiceConfiguration.cscfg e aumente a contagem de instâncias de 1 para 2:

<Instances count="2" />

Agora, ao pressionar F5, você obterá duas instâncias de seu aplicativo em execução no Compute Emulator. Observe que, independentemente da quantidade de vezes que você atualizar a página, você sempre terá os mesmos 10 valores em seu estado de sessão — isso ocorre porque é uma sessão compartilhada, e o início da sessão é executado apenas uma vez. Por outro lado, se não utilizar o Serviço de Cache como seu provedor de estado de sessão e optar por manter a opção em processo padrão, você terá valores diferentes em cada uma das instâncias.

O que vem a seguir?

O Serviço de Cache do Windows Azure AppFabric está previsto para entrar em produção como um serviço comercial no primeiro semestre de 2011. No primeiro lançamento comercial, alguns dos recursos que já são disponibilizados no Windows Server AppFabric ainda não estarão disponíveis. Algumas dessas exclusões são intencionais, pois elas talvez não se apliquem ao mundo na nuvem. Entretanto, recursos como as notificações também são relevantes no Windows Azure, além de serem essenciais para completar o cenário de cache local, e, por isso, fazem parte do mapa de curto prazo da Microsoft. De maneira semelhante, a opção de ativar a HA para um determinado cache nomeado como um recurso premium também está no topo da lista de prioridade.

A crescente popularidade do Cache do Windows Server AppFabric resultou em diversas solicitações de recursos novos, expandindo a aplicabilidade do cache para um conjunto de cenários ainda mais amplo. Alguns dos recursos que estão sendo discutidos incluem a capacidade de executar consultas avançadas no cache e uma maneira mais fácil de recuperar dados em massa a partir de um cache nomeado.

Além disso, o sucesso dos cenários do provedor de estado de sessão de cache com ASP.NET resultou em solicitações relacionadas à capacidade de associar ao cache consultas de gravação temporária e de leitura, de forma que o cache possa se tornar a principal maneira de manipular dados e, ao mesmo tempo, permitindo que as consultas associadas atualizem a camada de dados no back-end.

Vamos avaliar a possibilidade de inclusão desses e de outros recursos em versões futuras do Cache do Windows Azure AppFabric. Enquanto isso, nós o incentivamos a experimentar a atual implementação do Serviço de Cache e nos informar a sua opinião.

Karandeep Anand é Gerente de programas chefe do grupo de produtos do AppFabric na Microsoft. Sua equipe é responsável pela criação da plataforma de aplicativos e de serviços da próxima geração para a Plataforma Windows Azure e o Windows Server. Você pode entrar em contato com ele pelo email Karandeep.Anand@microsoft.com.

Wade Wegner é instrutor técnico na Microsoft, responsável por influenciar e orientar a estratégia técnica da Microsoft para a plataforma Windows Azure. Você pode entrar em contato com ele pelo blog, em wadewegner.com, ou no Twitter, em twitter.com/WadeWegner.