O poder da computação em nuvem vem de sua elasticidade e capacidade de se adaptar às mudanças de carga. A maioria dos serviços do Azure pode ser ampliada ou reduzida manualmente: pela interação humana no portal ou pela execução de um comando ou script.
Alguns serviços no Azure também oferecem suporte ao escalonamento automático, ou seja, eles podem alterar a alocação de recursos dinamicamente, com base em regras predefinidas e métricas operacionais atuais.
O Azure App Services é um exemplo desse serviço: ele oferece suporte ao dimensionamento com base em uma métrica predefinida .
Temos dois modelos de Autoscale:
Vertical scalling – significa aumentar/diminuir o tamanho do computador (ou seja, CPU ou memória). Geralmente, isso significa alterar o nível de preços. Geralmente, o dimensionamento vertical requer que o sistema fique temporariamente indisponível enquanto é reimplantado. Portanto, não é comum automatizar o dimensionamento vertical.
Horizontal scaling – significa adicionar/remover o número de instâncias, cada instância tendo o mesmo poder de computação. Isso também pode aumentar o custo, mas a faixa de preços é a mesma. O aplicativo continua em execução sem interrupções conforme os novos recursos são provisionados.
O termo autoscaling significa adicionar ou remover instâncias com base em certas condições predefinidas.
O Azure Monitor coleta métricas e logs de quase todos os tipos de recursos. Esses dados podem ser usados para configurar autoscaling, com base na demanda ou com base na programação.
- O escalonamento automático com base na demanda significa aumentar ou diminuir as instâncias, dependendo da carga atual.
- O escalonamento automático baseado em cronograma significa aumentar ou diminuir as instâncias com base em algum cronograma
Também temos a opção de manually scale out/in, mas, novamente, isso ainda seria ineficiente, pois alguém da equipe de operações ainda precisa ficar de olho continuamente quando o escalonamento horizontal ou interno é necessário.
Criar o Azure App Service
Já escrevi um artigo aqui no site mostrando como criar um App service utilizando o portal, acesse o link abaixo para conferir.
Nesse artigo vamos criar um App Service utilizando o PowerShell.
01 – Faça login no portal do Azure.
02 – No portal do Azure abra o Azure Cloud Shell e clique em Open new session.
03 – Execute o script abaixo para criar o App Service Plan e o App Service no East US.
# Variáveis
$Location =”East US”
$AppName = “AppService-dev-01”
$RGname = “RG-App_Service”
$tier = “Standard”
$Planname = “AppService-dev-01”
# Criar um grupo de recursos
New-AzResourceGroup -Name $RGname -Location $Location
# Criar App Service Plan
New-AzAppservicePlan -Name $Planname -ResourceGroupName $RGname -Location $Location -Tier $tier
# Criar App Service
New-AzWebApp -Name $AppName -ResourceGroupName $RGname -Location $Location -AppServicePlan $Planname
Como podemos observar na imagem abaixo o App Service está sendo provisionado.
04 – Como podemos observar os recursos foram provisionados com sucesso.
05 – No portal do Azure pesquise por App Services.
06 – Observe que temos nosso App service AppService01teste e o App service Plan AppService01testeplan.
Configurar Auto Scaling Rule
Ao criar o App Service, é necessário criar um App Service Plan. Este App Service Plan define a quantidade de recursos computacionais do servidor (por exemplo, quantidade de memória e quantos núcleos de CPU, etc.).
Scale up
Nessa opção partimos para analogia de um ônibus com capacidade de 50 usuários, caso precise transportar mais passageiros o dono do ônibus precisa comprar um ônibus com maior capacidade, comparando o exemplo do ônibus com com o Scale up a ideia é basicamente a mesma, caso o App service precise de mais poder computacional temos que aumentar o tamanho do plano para um plano com maior capacidade computacional, nessa opção temos o downtime da aplicação quando alterações o tamanho do plano.
Essa opção é a menos utilizada nos cenários scalling, lembrando que quando mudamos para um plano maior teremos reajustes nos valores que serão cobrados pelo plano.
07 – Na tela App Services selecione o App Service que criamos AppService01teste.
08 – Após selecionar o App Service em Settings clique em Scale up (App Service plan).
Scale out
Autoscale é um recurso integrado que ajuda os aplicativos a ter o melhor desempenho quando a demanda muda. Você pode optar por dimensionar seu recurso manualmente para uma contagem de instância específica ou por meio de uma política de escala automática personalizada que é escalonada com base em limites de métrica (s) ou programar a contagem de instâncias que é escalonada durante as janelas de tempo designadas. A escala automática permite que seu recurso tenha um bom desempenho e seja econômico, adicionando e removendo instâncias com base na demanda.
Voltando para analogia do ônibus, como precisamos transportar mais passageiros poderíamos adquirir um ônibus com a mesma capacidade que o ônibus inicial, sendo assim teríamos a capacidade dobrada porque teríamos dois ônibus, quando o segundo ônibus não fosse necessário poderíamos deixa-lo na garagem e apenas o primeiro ônibus transporia os passageiros, trazendo esse exemplo para o App Service aqui teremos instancias idênticas do App Service Plan dividindo a carga do App Service, com base em métricas sempre que um recurso atingir a capacidade definida da regra cresça uma instancia ou diminua um instancia, pagando assim apenas pelo tempo de atividade dessas instancias.
09 – Após selecionar o App service em Settings clique em Scale out (App Service Plan).
10 – Após selecionar a opção Scale out (App Service Plan) clique em Custom autoscale.
11 – Após selecionar a opção Custom autoscale em Autoscale settings name selecione um nome, em Resource group selecione um grupo de recursos.
12 – Para a opção Default em Scale mode selecione Scale based on a metric, podemos configurar regras para o “Scale In” ou “Scale Out” selecionando a opção “Add a rule”.
- Scale In – Adiciona instancias ao App Service Plan.
- Scale Out – Reduz as instancias adicionadas ao App Service Plan.
13 – Na tela Scale rule em Metrics source podemos escolher entre Current resource, Application gateways, Storage queue (Classic, Storage queue, Service bus queue, other resource, selecione Current resource (AppService01testeplan), para a opção Time aggregation selecione Average, em Metric Name é onde selecionamos qual métrica vamos utilizar para o Scale in e Scale out das instancias, temos algumas opções como CPU Percentagem, Date In, Date out, Disk Queue Length, Memory Percentagem, TCP Closing, TCP Established, etc. Vamos utilizar o “Memory Percentagem” que irá realizar a métrica do “Scale In” e “Scale out” com base no uso de porcentagem de Memoria. Outra configuração importante para o Scale rule é o Operator, aqui podemos definir a porcentagem de Memoria para o Scale In e Scale out, em Operator selecione Greater than, em Metric threshold to trigger scale action é nessa opção que definimos a porcentagem de memoria para o Scale In, para a opção Duration é o tempo que o recurso pode atingir de consumo para criar um nova instancia, para a opção Action em Operation é nessa opção que definimos a ações da métrica, se vamos aumentar o diminuir uma instancia, clique em Increase count by, para a opção Instancia count podemos definir quantas instancias desejamos que ele faça o “Scale IN” e o “Scale Out”, vamos criar apenas uma instancia, em seguida clique em Add.
Nessa regra estamos adicionando mais uma instancia ao App Service Plan caso ele atinja 70% de uso da memoria durante 5 minutos.
14 – Como podemos observar a regra de Increase foi criada, clique em + Add a rule para adicionar a regra de Decrease.
15 – Em Metric name selecione Memory Percentage, em Operator selecione Granter than, em Metric threshold to trigger scale acition selecione 40, para a opção Durantion vamos deixar selecionado 10, lembrando que esse tempo deve maior que o tempo utilizado na regra anterior (Increase coubt by), em Action selecione Drease count by e para a opção Instance count vamos selecionar 1, em seguida clique em Add.
Nessa regra estamos reduzindo uma instancia do App Service Plan caso ele atinja 40% de uso do processado durante 10 minutos.
16 – Como podemos observar as regra de Increase (aumentar) e Decrease (diminuir) foram criadas.
17 – Em Instance limites podemos definir a quantidade de instancias desejada, em minimum vamos definir uma 1 instancia, em Maximum vou definir 2 instancias e para a opção Default vou selecionar 1 instancias, em seguida clique em Save.
Nessa configuração estamos dizendo que o valor mínimo para a regra é 1 instancia e o valor máximo são 2 instancias.
Teste de Stress App Service
O teste que vamos realizar faz varias requisições para aplicação no App Service, quando o App Service Plan atingir 70% de uso do processador durante 10 minutos 1 instancia será provisionada.
O Script abaixo executa um teste de stress no App Service.
# Verifica os Apps services criados no Azure
Get-AzWebApp
# Grupo de Recursos onde está o App Service
$rgname = ‘RG-teste’
# Adicionar o App Service a variável $webapp
$webapp = Get-AzWebApp -ResourceGroupName $rgname
# Teste de stress na aplicação (loop infinito para aumentar a carga da aplicação)
while ($true) { Invoke-WebRequest -Uri $webapp.DefaultHostName }
18 – No vídeo abaixo mostro o teste de stress segundo executado.
Vamos deixar esse teste ser executado durante 10 minutos para que 1 instancia do App servie plan seja criada.
OBSERVAÇÃO: Pressione control + C para parar a execução do teste.
19 – Para verificar se a instancia foi criada selecionado o App Service em Monitoring clique em Process explorer.
20 – Após executar o teste de stress de memoria durante 5 minutos podemos observar que mais 1 instancia foi provisionada para o App Service Plan.
21 – Vamos parar o teste de stress de memoria pressionando control + C.
22 – Após pararmos o teste de stress podemos observar que a instancia que tinha sido adicionado foi deletada.
Comente suas sugestões e observações!
Forte abraço, obrigado e até o próximo post.
Carreira desenvolvida na área de tecnologia da informação, com ampla experiência em Cloud
Computing e Cloud Security.
Forte atuação em projetos de Cloud Security no Microsoft Azure e com tecnologias de
segurança do Microsoft 365.
Tenho Experiência em Microsoft Azure, Microsoft 365, AWS e Windows Server.
Sou Microsoft MVP na categoria Microsoft Azure, AWS Communit Builder Security & Identity e
MCT.