As 5 tácticas comprovadas que reduziram os custos do nosso Azure em 30%

Em 2017, o ShareGate gastou $250.000 no Azure. Mesmo com um MVP Azure na nossa equipa ajudando-nos a manter os custos o mais baixos possível, a nossa conta ainda aumentou 45% em menos de 12 meses. O principal culpado, é claro, foi a expansão da nuvem.

Sabíamos que era possível economizar muito, então pedimos aos nossos especialistas que nos elaborassem uma lista de métodos práticos e eficazes de controle de custos da nuvem para reduzir nossos gastos com o Azure.

Compilamos nossas descobertas neste guia para que você também possa começar a identificar imediatamente as economias potenciais do Azure nos ambientes da sua organização.

Consider B-Series virtual machines

While platform-as-a-service (PaaS) offerings have been gaining significant ground over the past few years, virtual machines—be it for legacy reasons or due to specific software requirements—still represent a large portion of cloud usage.

As VMs baseadas em nuvem representam um desafio em termos de controle de custos: elas normalmente exigem especificações mínimas para serem executadas e geralmente estão ociosas com picos de uso periódicos, mas continuam incorrendo no custo total enquanto estiverem ligadas.

Em setembro de 2017, a Microsoft anunciou a família de máquinas virtuais da série B, também conhecidas como máquinas virtuais com capacidade de explosão. Estas máquinas são projetadas especificamente para cargas de trabalho que sempre precisam estar disponíveis, mas são tipicamente ociosas, com picos ocasionais de uso. As VMs da Série B oferecem um potencial significativo de redução de custos: entre 15 e 55% de desconto no preço de uma máquina equivalente da Série D, dependendo do sistema operacional que você estiver usando.

Leitura recomendada: Dicas de economia de custos Azure: dos e não dos iniciantes da indústria, por Leigh Ryan

Então eu devo converter todas as minhas VMs existentes para a Série B e economizar grandes?

Cuidado agora! Nem todas as cargas de trabalho podem ser convertidas às cegas para a Série B. Você precisa encontrar um equilíbrio entre o custo e o consumo da CPU. A Série B é alocada uma quantidade de base de energia da CPU. Desde que seu uso esteja abaixo da linha de base, a VM acumula créditos, que podem então ser usados para consumir a CPU excedendo a linha de base. Se sua máquina virtual se tornar muito intensiva em CPU, no entanto, ela será acelerada até o desempenho da linha de base até que créditos suficientes estejam disponíveis.

Baselines e limites de crédito variam de acordo com o tamanho de cada VM da Série B. Além disso, sempre que a VM é desligada, todos os créditos acumulados são perdidos. Como tal, as VMs da Série B são verdadeiramente concebidas para cargas de trabalho de baixa utilização ou previsíveis que são necessárias para estarem sempre disponíveis.

Para o ajudar a determinar se a sua máquina virtual pode ser convertida em segurança para uma Série B, pode executar scripts personalizados como o script Azure-Burst-Check do Dave Hall.

Identificar e agir em recursos ociosos

Bem obrigado ao Azure, nunca foi tão fácil colocar um novo ambiente em funcionamento a qualquer momento, sempre que é hora de atender a uma nova necessidade para a sua organização. Fast-forward a few years, however, and you’ll start noticing a buildup of resources in your Azure subscription that are likely racking up a hefty bill. It isn’t always easy to tell which workloads are still being used and which ones can safely be decommissioned.

The best solution would be to go back in time and implement a basic cloud asset governance plan. Confira nossa cartilha sobre a criação de um plano de governança de custos da nuvem para uma visão geral dos elementos centrais a serem considerados: visibilidade, propriedade e permissões, ciclo de vida e otimização – ou, como gostamos de chamá-los, VOLO.

Em poucas palavras, para cada recurso que você criar, você vai querer:

• Usar tags e outras estratégias para categorizar como o recurso será usado (dev, test, prod, etc.).)
• Especifique um único proprietário para o recurso (normalmente a pessoa que solicitou o recurso)
• Determine uma data de expiração ou check-up para o recurso (e certifique-se de seguir o cronograma e eliminar recursos desnecessários prontamente)

Após ter esta informação, é muito mais fácil determinar se um determinado recurso ainda é necessário e agir de acordo.

Leitura recomendada: Como iniciar e parar suas VMs com Azure Automation, por Antoine Jagueneau

Eu não tenho um plano de governança de custos. Agora o que?

Azure dá-lhe acesso a um conjunto de estatísticas de utilização que medem a quantidade de actividade que os seus recursos estão a ver. Estes valores podem ser examinados a partir do Portal Azure, acedendo à API Azure e utilizando código personalizado, ou através de uma solução dedicada de gestão de custos. Ao examinar estes números de utilização, pode identificar quais os activos que já não estão a ser utilizados (ou que estão significativamente subutilizados) e tomar as medidas adequadas. Além disso, tenha em mente que a governança de custos da nuvem é um processo iterativo, portanto nunca é tarde demais para começar a trabalhar em um plano.

Encontrar o tamanho correto do recurso

Uma questão comum ao criar novos recursos da nuvem é descobrir o tamanho correto para usar. Azure oferece um grande número de opções para acomodar diferentes requisitos (mais RAM, mais potência de CPU, drives SSD, GPUs, etc.), mas mesmo dentro da mesma família de máquinas, escolher o tamanho certo importa.

Leitura recomendada: Como funciona o preço do Azure VM?, por Leigh Ryan

Enconhe errado, e ou você paga mais do que precisa enquanto sua máquina está ociosa, ou você acaba com uma máquina que está a 100% de CPU (ou pior ainda, trocando para memória virtual porque está sem memória física de RAM). Tudo isso, é claro, pode impactar significativamente o desempenho do aplicativo.

Nem sempre é fácil descobrir os requisitos de um determinado sistema antes do tempo, então pode ser tentador ir um pouco mais alto do que você precisa apenas para estar no lado seguro. É também bastante comum esquecê-lo e deixá-lo sobredimensionado, levando a custos desnecessários mês após mês.

Como você pode evitar isso? Vamos analisar algumas estratégias neste artigo.

A maneira mais fácil de evitar o desperdício de dinheiro no consumo desnecessário de recursos, no entanto, é deixar que uma ferramenta dedicada de otimização em nuvem monitore seu inquilino e o notifique sempre que houver uma oportunidade de redimensionar, diminuir a escala ou de outra forma cortar um determinado recurso.

Quando diminuir a escala

Se você acredita que este pode ser o caso do seu ambiente, não entre em pânico! Existem algumas maneiras fáceis de determinar se você deve reduzir o tamanho de um determinado VM. O método mais fácil é dar uma olhada nos gráficos Percentagem da CPU e Percentagem da Memória para cada recurso no Portal Azure.

Tipicamente, os tamanhos das instâncias em Azure duplicam com cada camada: um S1 terá 1 núcleo de CPU junto com 1,75 GB de RAM, enquanto um S2 terá 2 núcleos e 3,5 GB de RAM. O mesmo padrão também se aplica a tamanhos de banco de dados e DTUs.

Em todos os casos, se você ver durante um longo período de tempo que ambas as estatísticas de uso estão abaixo de 50%, você pode, confiantemente, reduzir a sua instância sem se preocupar em atrapalhar o desempenho.

Por que não consigo ver o uso de memória para o meu VM?

Felizmente, você não estará obtendo os gráficos de porcentagem de memória para máquinas virtuais, clássicas ou gerenciadas, fora da caixa. Para acessar esta informação, você precisará habilitar o monitoramento de nível de guest-level e verificar os Contadores de Desempenho corretos. O que você deve verificar especificamente é o MemoryCommitted Bytes. Com estas informações, você deve ser capaz de determinar se um serviço pode ser reduzido com segurança ou não.

Localizar e excluir discos não utilizados

Se você está usando o Azure há algum tempo, você provavelmente criou – e excluiu – um número razoável de máquinas virtuais. Mas a sua conta continua a subir e você não tem bem a certeza do motivo. Um provável culpado é os discos de armazenamento; especificamente, os discos para máquinas virtuais apagadas que ainda permanecem na sua conta e custam dinheiro mês após mês. Isto é ainda mais provável se você estiver usando máquinas virtuais clássicas ao invés da nova variedade ARM. A razão para isso é bastante simples: O Azure não apaga sistematicamente os seus discos quando apaga uma máquina virtual. Isto é para o proteger da perda acidental de dados, mas também significa que se não tiver cuidado, continuará a pagar pelos discos que já não precisa.

P>Pode resolver este problema a partir do portal Azure. The procedure will be a bit different depending on whether you’re dealing with managed disks or classic disks.

Managed disks

For managed disks, go to the Azure portal, search for Disks in the search bar, and select “Disks”.

This will display all your managed disks. If the Owner column is empty, it means that the disk is not currently attached to anything and you can probably delete it.

To delete the disk, select the row, go to Overview and click Delete in the top bar.

Classic disks

For classic disks, go to the Azure portal, click in the Search bar up top and search for Disks. Select “Disks (classic)”.

You’ll see all of your disks and a column indicating which VM each disk is currently attached to. If you see a disk that isn’t attached to a VM, you can probably delete it safely.

Deleting classic disks is a bit of a process, as the underlying file (the VHD), which is stored in a storage account, will still be there until you manually remove it. Here are the steps:

1. Click on the classic disk and take note of its Storage account and Media link information

2. Click Delete and confirm

3. Use a barra de pesquisa do Azure para encontrar a conta de Armazenamento que você notou no passo 1, depois abra o painel de propriedades

4. Clique em Blobs, depois selecione a linha com o recipiente de armazenamento certo

5. Marque a caixa com o nome correto do arquivo, então clique em Excluir no menu superior

Esquecidos VHDs

Even se você seguir todos estes passos para identificar discos soltos, ainda pode perder os VHDs esquecidos que ficam abandonados no armazenamento clássico. Tipicamente, o Portal Azure cria um contentor “vhds” e coloca-os lá numa conta de armazenamento. Para localizá-los, verifique em cada conta de armazenamento clássica um contentor vhds em Blobs. Dentro do contentor, veja a coluna Estado de Aluguer para cada ficheiro. Se diz Disponível, significa que nenhuma VM está atualmente usando esse VHD, e pode ser seguro para você excluí-lo (mas você deve sempre verificar o conteúdo para ter certeza!).

Leverage elastic pool databases

Chances are you started your cloud migration project by moving workloads that were previously hosted on-prem or in a private data center over to Azure. Um grande número dessas cargas de trabalho provavelmente utilizava bancos de dados SQL Server, que tendiam a ser a espinha dorsal da maioria dos projetos de software antes da ascensão da nuvem e do movimento NoSQL. Você provavelmente também notou que o preço dos bancos de dados SQL no Azure pode ficar bastante alto, muito rapidamente.

Embora anteriormente você tenha usado um único servidor de banco de dados para hospedar dezenas, se não centenas, de bancos de dados para seus vários projetos ou clientes, o custo de dividi-los em bancos de dados SQL separados do Azure pode ser ordens de magnitude maior do que você esperava. Isto é devido à forma como as bases de dados funcionam no Azure. On-prem, você estava acostumado a múltiplos bancos de dados compartilhando os recursos limitados de um único servidor. Com o Azure SQL, cada base de dados tem uma quantidade reservada de recursos, que ainda lhe será cobrada mesmo que a base de dados esteja ociosa. O modelo é ótimo se você tiver vários bancos de dados com utilização consistente e previsível. Se você tiver um grande número de bases de dados com um padrão de utilização pontual, no entanto, você pode achar a etiqueta de preço significativamente menos atraente. Isto deixa-o com duas opções:

• Utilizar um nível maior e mais caro de base de dados para lidar com o pico de utilização da base de dados
• Utilizar um nível mais baixo para poupar custos, à custa do desempenho durante os picos de utilização

Para partilhar recursos entre bases de dados, os primeiros utilizadores do Azure foram forçados a criar e manter as suas próprias máquinas virtuais com o SQL Server instalado e essencialmente replicar as condições sob as quais foram executadas enquanto estavam on-prem ou num datacenter privado. Embora este método tenha funcionado bem, não permitiu o acesso a todas as grandes funcionalidades que o Azure SQL tem para oferecer, tais como:

• Built-in high availability (sem necessidade de configurar replicação)
• Active geo-replication
• Point-in-time restore

Estas funcionalidades não são triviais para implementar por si só e podem ser um desafio para manter.

Bem mais: Instâncias gerenciadas

Azure oferece um novo nível de serviços de banco de dados SQL chamado Managed instances, que são essencialmente máquinas virtuais gerenciadas que hospedam um SQL Server. As instâncias geridas não lhe fornecerão todas as funcionalidades que estão integradas nos serviços de base de dados única do Azure SQL, mas também não necessitará de gerir o sistema operativo ou a instalação do SQL Server. Basicamente, você está obtendo uma máquina virtual cuja configuração e manutenção é amplamente gerenciada para você.

Best: SQL elastic pools

Mas existe outra opção no Azure para lidar com este cenário comum: Piscinas elásticas SQL. Ao invés de reservar uma certa quantidade de recursos para um único banco de dados, os pools elásticos SQL permitem reservar uma série de recursos e compartilhá-los em centenas de bancos de dados. Este modelo tem todos os benefícios do Azure SQL e permite lidar adequadamente com padrões de utilização pontiagudos em múltiplas bases de dados. Os pools elásticos provaram ser incrivelmente populares e são uma opção ideal para aplicações multi-tenantadas.

No entanto, você deve ser cauteloso no uso de pools elásticos. Se você tem um ou mais bancos de dados com um uso significativamente maior que os outros bancos de dados em um pool, você pode ser forçado a comprar um nível de elástico mais caro para lidar com os picos de uso. Em alguns casos, pode ser realmente mais econômico dividir esses bancos de dados de alta utilização em um único banco de dados (retirando-os do pool) e pagar por um nível menor de pool elástico para os demais bancos de dados de menor utilização. Uma boa regra geral é observar a utilização de DTUs de banco de dados: se um único banco de dados estiver utilizando 40% ou mais das DTUs do pool elástico em um determinado momento, você pode ser capaz de economizar custos dividindo-o do pool e, em seguida, reduzindo esse pool para um nível mais barato.

Como sempre, o portal Azure é o seu go-to para identificar padrões de uso do banco de dados.

Time to take action and start saving on Azure

By acting on the five areas outlined in this guide, our team managed to shrink our Azure spend by 30%.

Can you do better?