Windows Azure: arquitetura de custos para o Windows Azure

  • Artigo

Criar aplicativos e soluções para a computação em nuvem e o Windows Azure requer uma maneira totalmente diferente de se considerar os custos operacionais.

Maarten Balliauw

A computação em nuvem e as plataformas como o Windows Azure são referenciadas como “o próximo grande passo” na TI. Isso certamente parece verdade quando consideramos as inúmeras vantagens da computação em nuvem.

A computação e o armazenamento se tornaram uma história sob demanda, que você pode usar a qualquer momento, pagando apenas por aquilo que efetivamente utilizar. Entretanto, isso também apresenta um problema. Se um aplicativo em nuvem for desenvolvido como um aplicativo comum, é provável que a perspectiva de custo desse aplicativo não seja de acordo com o esperado.

Métricas diferentes

Na TI tradicional, uma pessoa poderia comprar um conjunto de hardware (infraestrutura de rede, servidores e assim por diante), instalá-lo, passar pelo processo de configuração e conectá-lo à Internet. Esse é um investimento único, com um funcionário para apertar os botões e girar os parafusos — e é isso.

Com a computação em nuvem, um modelo de custo substitui esse modelo de investimento. Você paga por recursos como potência e armazenamento de servidor com base em seu uso efetivo. Com uma plataforma como o Windows Azure, você pode esperar as seguintes medidas para calcular sua fatura mensal:

  • Número de horas que você reservou uma máquina virtual (VM) — o que significa que você paga por um aplicativo implantado, mesmo se ele não estiver atualmente em execução.
  • Número de CPUs em uma VM.
  • Largura de banda, medida por GB de entrada/saída.
  • Quantidade de armazenamento utilizado, em GB.
  • Número de transações no armazenamento.
  • Tamanho do banco de dados no SQL Azure.
  • Número de conexões no AppFabric da plataforma Windows Azure.

É possível encontrar todos os detalhes de preços no site do Windows Azure em microsoft.com/windowsazure/offers. Como pôde ser visto por essa lista, há muito o que considerar.

Limitando máquinas virtuais

Veja aqui como isso funciona a partir de uma perspectiva prática. Embora limitar a quantidade de VMs em execução seja uma boa maneira de reduzir custos, para Web Roles, é sensato ter pelo menos duas VMs para balanceamento de carga e disponibilidade. Use a API de Diagnósticos do Windows Azure para medir o uso da CPU, a quantidade de solicitações HTTP e o uso da memória nessas instância e redimensione seu aplicativo quando necessário.

Todas as instâncias de todas as funções em execução no Windows Azure mensalmente duplicam a quantidade de horas na fatura. Por exemplo, ter em média três instâncias de função em execução (às vezes, duas, às vezes, quatro) será 25% mais barato do que executar quatro instâncias em tempo integral com praticamente nenhuma carga de trabalho.

Para as Worker Roles, também é sensato ter pelo menos duas instâncias de função para realizar o processamento em segundo plano. Isso ajudará a garantir que, quando uma instância não estiver disponível por conta de atualizações ou uma função começar a ocorrer, o aplicativo ainda estará disponível. Ao usar as ferramentas disponível do Windows Azure, você pode configurar uma Worker Role pronta para uso a fim de realizar apenas uma tarefa.

Se estiver executando um site de compartilhamento de fotos, por exemplo, você vai querer ter uma Worker Role para redimensionar as imagens e outra para enviar notificações por email. O uso da regra de “pelo menos duas instâncias” significa executar quatro instâncias de Worker Role, o que resulta em uma fatura ajustável. O redimensionamento de imagens e o envio de emails não exige realmente essa quantidade de capacidade de CPU e, por isso, ter apenas duas Worker Roles para executar as duas tarefas deve ser suficiente. Isso gera uma economia de 50% na fatura mensalmente pela execução do Windows Azure. Também é bem fácil implementar um mecanismo de threading em uma Worker Role, onde cada thread executa a parte de seu trabalho dedicado.

O Windows Azure oferece quatro tamanhos de VM: pequeno, médio, grande e extragrande. As diferenças entre cada tamanho são o número de CPUs disponíveis, a quantidade de memória e de armazenamento local disponíveis e o desempenho de E/S. É ideal pensar sobre o tamanho apropriado da VM antes de realmente fazer a implantação no Windows Azure. Não é possível alterá-lo depois da execução do aplicativo.

Quando receber seu demonstrativo mensal, você perceberá que todas as horas de computação foram convertidas em horas de instância pequena quando apresentadas em sua fatura. Por exemplo, o período de uma hora de uma instância de computação média representaria duas horas de uma instância de computação pequena na taxa da instância pequena. Se tiver duas instâncias médias em execução, você será cobrado por 720 horas x 2 x 2.

Considere isso ao dimensionar suas VMs. Você pode obter praticamente a mesma potência de computação usando instâncias pequenas. Digamos que você tenha quatro delas cobradas como 720 horas x 4. Esse preço é igual. Você pode reduzir para duas instâncias, quando apropriado, o que resultará em 720 horas x 2. Se não precisar de mais CPUs, mais memória ou mais armazenamento, permaneça com as instâncias pequenas, pois elas podem ser dimensionadas de maneira mais granular do que instâncias maiores.

A cobrança de serviços do Windows Azure começa após a implantação de um aplicativo e ocorre independentemente de as instâncias de função estarem ativas ou não. É possível verificar isso facilmente no portal do Windows Azure. Há uma imagem grande de uma caixa. “Quando a caixa está cinza, está tudo OK. Quando a caixa está azul, uma fatura está pendente.” (Agradecimentos a Brian H. Prince pela observação.)

Se estiver implantando aplicativos no ambiente de preparo ou de produção e desligando-os após o uso, não se esqueça de também cancelar a implantação do aplicativo. Você não vai querer pagar por nenhum aplicativo inativo. Além disso, lembre-se de reduzir, quando apropriado. Isso causa um efeito direto nos custos operacionais mensais.

Ao realizar um dimensionamento, é recomendável ter uma instância de função em execução por pelo menos uma hora, pois você paga pela hora. Acelere vários threads de trabalho em uma Worker Role. Dessa maneira, uma Worker Role poderá executar várias tarefas, em vez de apenas uma. Se não precisar de mais CPUs, memória ou armazenamento, permaneça com as instâncias pequenas. E, novamente, certifique-se de cancelar a implantação de seus aplicativos quando não estiverem em uso.

Largura de banda, armazenamento e transações

A largura de banda e as transações são duas métricas complicadas. Atualmente, não existe nenhuma boa maneira de mensurá-las, exceto pela verificação da fatura mensal. Não existe um monitoramento em tempo real que possa ser consultado e utilizado para adaptar o seu aplicativo. A largura de banda é a métrica mais fácil de mensurar dentre as duas. Quanto menor a quantidade de tráfego na transmissão, menores serão os custos. Simples assim.

As coisas ficam mais complicadas quando você implanta aplicativos em várias regiões do Windows Azure. Digamos que você tenha uma Web Role em execução na região “América do Norte” e uma conta de armazenamento na região “Leste Europeu”. Nessa situação, a largura de banda para a comunicação entre a Web Role e o armazenamento será cobrada.

Se a Web Role e o armazenamento estiverem localizados na mesma região (ambos na “América do Norte”, por exemplo), não haveria nenhuma cobrança de largura de banda para a comunicação entre a Web Role e o armazenamento. Lembre-se de que, ao definir o design de aplicativos distribuídos geograficamente, é melhor manter os serviços vinculados dentro da mesma região do Windows Azure.

Ao usar o Windows Azure Content Delivery Network (CDN), você pode aproveitar outra medida interessante de redução de custos. A CDN é medida da mesma maneira que o armazenamento de blob, ou seja, por GB armazenado por mês. Após iniciar uma solicitação para a CDN, ela obterá o conteúdo original do armazenamento de blob (incluindo o consumo de largura de banda e, portanto, faturado) e irá armazená-lo em cache localmente.

Se você definir os cabeçalhos de expiração de seu cache como muito curtos, isso consumirá mais largura de banda, pois o cache da CDN se atualizará com mais frequência. Quando a expiração do cache for muito longa, o Windows Azure armazenará o conteúdo na CDN por um período maior e cobrará por GB armazenado por mês. Pense sobre isso para cada aplicativo, de forma que você possa determinar o melhor período de expiração do cache.

O Windows Azure Diagnostics Monitor também usa o armazenamento de blob para dados de diagnóstico, como contadores de desempenho, logs de rastreamento, logs de eventos, entre outros. Ele grava esses dados em seu aplicativo, em um intervalo predefinido. A gravação de cada minuto aumentará a contagem da transação no armazenamento, o que levará a custos extras. Defini-lo em um intervalo como a cada 15 minutos resultará em menos transações de armazenamento. Entretanto, a desvantagem disso é que os dados de diagnóstico estão sempre com pelo menos 15 minutos de atraso.

Além disso, o Windows Azure Diagnostics Monitor não limpa seus dados. Se você não fizer isso, existe uma chance de ser cobrado por uma grande quantidade de armazenamento que não contém nada além de dados de diagnóstico antigos e expirados.

As transações são cobradas a cada 10.000. Pode parecer um número alto, mas você pagará por eles, na realidade. Cada operação em uma conta de armazenamento é uma transação. A criação de um contêiner de blob, a listagem do conteúdo de um contêiner de blob, o armazenamento de dados em uma tabela no armazenamento de tabelas, a exibição de mensagens em uma fila — todos esses são transações. Ao executar uma operação, como o armazenamento de blobs, por exemplo, você deve primeiro verificar se o contêiner de blob já existe. Se não existir, você deverá criá-lo e, em seguida, armazenar um blob. Isso contabiliza duas transações; possivelmente, três.

O mesmo é contabilizado para a hospedagem de conteúdo estático no armazenamento de blob. Se o seu site hospeda 40 imagens pequenas em uma página, isso significa 40 transações. Esse número pode aumentar rapidamente com aplicativos de tráfego alto. Simplesmente ao assegurar que um contêiner de blob existe na inicialização de um aplicativo e ignorar essa verificação em todas as operações subsequentes, você poderá reduzir o número de transações em praticamente 50%. Seja esperto quanto a isso e diminua o valor de sua fatura.

Índices podem ser caros

O SQL Azure é um produto interessante. Você pode ter um banco de dados de 1GB, 5GB, 10GB, 20GB, 30GB, 40GB ou 50GB a um preço mensal extremamente baixo. É seguro e suficiente iniciar com um banco de dados do SQL Azure de 5GB. Se estiver usando apenas 2GB dessa capacidade, significa que você não está realmente em um modelo pagamento pelo uso, certo?

Em algumas situações, pode ser mais econômico distribuir os dados entre diferentes bancos de dados do SQL Azure, em vez de ter um único banco de dados grande. Por exemplo, você poderia ter um banco de dados de 5GB e um de 10GB, em vez de um banco de dados de 20GB com 5GB de capacidade não utilizada. Esse tipo de armazenamento estratégico afetará sua fatura se você realizá-lo de maneira inteligente e se ele funcionar com o tipo de seus dados.

Cada objeto consome uma quantidade de armazenamento. Os índices e as tabelas podem consumir muita capacidade de armazenamento do banco de dados. Tabelas grandes podem ocupar 10% de um banco de dados e alguns índices podem consumir 0,5% de um banco de dados.

Se dividir o custo mensal de sua assinatura do SQL Azure pelo tamanho do banco de dados, você terá o custo por unidade de armazenamento. Pense sobre os objetos em seu banco de dados. Se o índice X custar a você 50 centavos por mês e, na verdade, não acrescentar muito no ganho de desempenho, simplesmente descarte-o. 50 centavos não é muito, mas se você eliminar algumas tabelas e alguns índices, esse valor pode ser significativo. Um exemplo interessante sobre isso pode ser encontrado no blog da equipe do SQL Azure, na postagem sobre o custo real dos índices (blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx).

Há uma grande movimentação no desenvolvimento de aplicativos para que não sejam mais utilizados procedimentos armazenados em um banco de dados. Em vez disso, a tendência é usar mapeadores relacionais de objetos e executar vários cálculos sobre os dados na lógica do aplicativo.

Não há nada de errado com ele, mas isso fica interessante quando pensamos sobre o Windows Azure e o SQL Azure. A execução de cálculos de dados no aplicativo pode exigir instâncias extras de Web Role ou Worker Role. Se você mover esses cálculos para o SQL Azure, estará economizando uma instância de função nessa situação. Como o SQL Azure é medido no armazenamento, e não no uso de CPU, você realmente obtém ciclos de CPU livres em seu banco de dados.

Impacto para os desenvolvedores

O desenvolvedor que estiver escrevendo códigos pode ter um impacto direto sobre os custos. Por exemplo, ao compilar um site ASP.NET que será hospedado pelo Windows Azure, você poderá fazer a distribuição entre instâncias de função usando o provedor de estado de sessão com suporte de armazenamento do Windows Azure. Esse provedor armazena os dados da sessão no serviço de tabela do Windows Azure, no qual a quantidade de armazenamento e de largura de banda utilizada e a contagem de transações são mensuradas para cobrança. Considere o trecho de código a seguir que é utilizado para determinar o idioma de um usuário a cada solicitação:

if (Session["culture"].ToString() == "en-US") {
  // .. set to English ...
}
if (Session["culture"].ToString() == "nl-BE") {
  // .. set to Dutch ...
}

Não há nada errado com ele? Tecnicamente, não. Entretanto, é possível otimizá-lo em 50% a partir de uma perspectiva de custo:

string culture = Session["culture"].ToString();
if (culture == "en-US") {
  // .. set to English ...
}
if (culture == "nl-BE") {
  // .. set to Dutch ...
}

Os dois trechos de código fazem exatamente a mesma coisa. O primeiro trecho lê os dados da sessão duas vezes, ao passo que o segundo lê os dados apenas uma vez. Isso significa um ganho de custo de 50% na contagem de largura de banda e transações. O mesmo se aplica às filas. Ler uma mensagem por vez, 20 vezes, será mais caro do que ler 20 mensagens de uma só vez.

Como pôde verificar, a computação em nuvem introduz detalhes de preços e economias diferentes para a hospedagem de aplicativos. Embora a computação em nuvem possa representar um enorme aprimoramento nos custos operacionais em relação a um data center tradicional, você deve ficar atento a determinadas considerações quanto à arquitetura dos aplicativos quando projetados para a nuvem.

Maarten Balliauw

Maarten Balliauwé consultor técnico em tecnologias da Web na RealDolmen, uma das maiores empresas de ICT da Bélgica. Seus interesses são ASP.NET MVC, PHP e Windows Azure. Ele é um Microsoft Most Valuable Professional do ASP.NET e publicou diversos artigos em publicações sobre PHP e .NET, como MSDN Magazine, Belgium e PHP Architect. Balliauw também é um palestrante sempre presente em vários eventos nacionais e internacionais. Visite seu blog em blog.maartenballiauw.be.

 

Conteúdo relacionado