Condé Demo – Construindo uma solução auto-escalável dentro do Windows Azure
· Boa noite a todos !
Esta “Condé Demo” é a mais antiga que já publiquei no Channel9. Ela foi concebida para o evento S+S Day de Dezembro de 2010, apesar dos 6 meses de idade, continua muito atual. Em algumas reuniões com parceiros e start-ups uma das perguntas que surgem é “O Windows Azure suporta auto-escalabilidade ?”, a primeira resposta é não. Então, é neste momento que surge a expressão de interrogação, “Como assim? Não estamos falando de computação elástica?”, bem primeiramente é necessário esclarecer que a capacidade computação elástica refere-se a possibilidade crescer ou encolher o uso de poder de processamento e armazenamento no Azure. Já quando falamos sobre auto-escalabilidade, na realidade é a existência de uma a inteligência em reconher um padrão de comportamento de uma aplicação, e assim baseado em conjunto de thresholds/SLAs/Notificações, esta inteligência deve incrementar ou encolher o consumo de recursos da aplicação.
Bem, pode-se notar que determinar qual comportamento padrão e os quais os thredsholds são medidas estritamente ligadas à aplicação e não a uma plataforma de serviços. Mas nem tudo são problemas, através de um conjunto de recursos do Azure é plenamente possível a construção de aplicação que suporte auto-escalabilidade.
Em novembro de 2009, em um bate-papo com o Arquiteto-Chefe Otavio Pecego, ele lançou o desafio de apresentarmos no S+S Day uma solução que suportaria auto-escalabilidade. O desafio foi aceito e concluído com sucesso.
Teoria do Controle
A inspiração para a construção da aplicação de auto-escalabilidade veio da Teoria de Controle da Mecânica . Para entender esta teoria, vamos a um exemplo comum, “Como manter a velocidade constante de um veículo, independente da carga que ele transporta?”; agora imagine como construir um mecanismo para responder à esta pergunta. Para que este motor possa manter a sua velocidade é necessário que uma inteligência esteja continuamente analisando os fatores externos (condição da estrada, resistência do evento, peso atual do veículo), e uma vez tendo estes fatores externos esta inteligência pode enviar comandos aumentar ou reduzir a aceleração do veículo.
Na imagem abaixo, você pode ver o desenho padrão da Teoria do Controle. Nela estão presentes alguns aspectos importantes, são eles:
o Processo: Entidade que recebe os comandos do Controlador e executa as ações
o Controlador: Entidade que compara o valor desejado (SP) com o valor do processo (PV) e determina com base em um algoritmo qual é o valor de correção que o Processo deve executar para aproximar do valor desejado (SP).
o Feedback: Conjunto de dados que o controlador utilizará para medir o quanto deve incrementar ou reduzir o valor do processo (PV), baseado na relação Valor Desejado (SP) X Valor do Processo (PV).
Patterns
Aplicando a Teoria do Controle dentro de uma solução para cloud computing, podemos ver dois patterns interessantes que podemos ver. O primeiro pattern chama-se “Scale Unit”, podemos defini-lo como a quantidade de recursos que uma aplicação consome para atender uma demanda definida. Um exemplo deste pattern seria definirmos, por exemplo, que uma aplicação para atender 250 usuários simultaneamente ela precisasse de 1 WebRole e 1 WorkerRole.
Já o segundo pattern é o “Heart Beat”, este pattern funciona como uma coleta contínua de dados estatísticos das Roles/Scale Units, e assim baseando em threshold, o mecanismo de Controle envia comandos de incremento ou decremento no número de Scale Units que a aplicação vem consumindo ao longo da sua execução.
E uma vez o “Heart Beat Service” detecte alguma anomalia no desempenho da aplicação, ele envia para a aplicação o comando de incrementar o número de “Scale Units” e assim consegue manter o desempenho esperado.
Arquitetura da Demonstração
Uma vez conhecendo o modelo e os patterns apresentados, chegou o momento de vermos qual é a arquitetura da aplicação apresentada na demonstração. O propósito da aplicação é realizar cálculos de números fatoriais que são submetidos para uma fila do Windows Azure Storage. Uma vez estes números são submetidos para uma fila, um WorkerRole captura estes números, calcula e escreve dentro uma table.
Além disso, uma aplicação de monitoramento (isolada do ambiente Azure) comporta como “Heart Beat”, coletando continuamente o número de itens pendentes na fila. E se o número de itens pendentes ficar acima do threshold, a aplicação de acompanhamento envia uma requisição de incremento do número de WorkerRoles. E vice-versa, e o número de itens ficar abaixo do threshold, ela solicita que reduza o número de WorkRoles.
Código-fonte e documentos
Conteúdo |
Link |
Observações |
Pré-requisitos para a produção |
Código-fonte para a aplicação a ser hospedada no Azure |
Esta solução foi desenvolvida em cima do Visual Studio 2010 Ultimate | Verifique o arquivo Readme.txt para saber onde deve fazer as modificações abaixo Projeto SetupAzureStorage
Projeto SPSDayDemoAutoScaling01
|
|
Código-fonte da aplicação de monitoramento. |
Esta solução foi desenvolvida em cima do Visual Studio 2008 VSTS Em alguns casos, pode ocorrer falha de rede na execução do aplicativo, sugiro aumentar o tempo de atualização do gráfico. | Verifique o arquivo Readme.txt para saber onde deve fazer as modificações abaixo Projeto SPSDayDemoAutoScaling01Health
|
Condé Demo
Abaixo tem o vídeo do Channel 9, se quiser ver mais vídeos entre em https://channel9.msdn.com/niners/luconde.
abs e T+
Condé
versão 1.3
Comments
- Anonymous
October 23, 2010
Parabéns Condé! Muito bom todos seus posts! Muito bem feito e explicado! Esta ajudando muito com meu projeto! Vlws