Meça antes de repatriar: dimensionar uma saída da cloud a partir do uso real

O erro mais caro ao sair da public cloud é copiar a infraestrutura tal como está. Os ambientes cloud crescem por provisionamento, e provisionado não é usado: tamanhos de instâncias escolhidos à pressa, volumes dimensionados para um pico que nunca chegou, serviços que ninguém se lembra de ter iniciado. Mova isso um para um e transporta o desperdício para um contrato fixo. Aqui fica como medir o que realmente corre antes de alguém desenhar algo novo.

O problema: a fatura descreve o que aluga, não o que usa

Uma fatura de cloud lista tipos de instâncias, tamanhos de volumes e escalões de serviço. Nada disso lhe diz quanta CPU a sua aplicação consumiu na sua hora mais ocupada, quantos IOPS a base de dados realizou de facto, ou quanta memória a cache realmente ocupa. Esses são os números de que um desenho físico ou de private cloud precisa, e o fornecedor de cloud esteve a registá-los por si este tempo todo.

Primeiro passo: inventarie tudo, não apenas os servidores

Comece com uma lista completa de recursos em todas as regiões que alguma vez usou. As tags ajudam, mas os recursos sem tags são exatamente os que precisa de encontrar:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --query 'ResourceTagMappingList[].ResourceARN' --output text
done | tr '\t' '\n' | sort > inventory.txt

Depois agrupe por serviço. Os servidores são habitualmente a parte fácil. O trabalho está no que os rodeia: bases de dados geridas, caches, load balancers, zonas DNS, filas, object buckets, certificados, functions agendadas, e os papéis IAM e os security groups que os ligam entre si. Cada um precisa de um responsável e de uma decisão: mover, substituir, manter ou retirar.

Segundo passo: leia percentis, não médias

Para cada recurso de computação, extraia pelo menos um mês de utilização, e leia o percentil 95 e o máximo em vez da média. A média de uma noite calma e de um fim de tarde ocupado não descreve nenhum dos dois.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<instance-id> \
  --start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' --output text \
  | tr '\t' '\n' | sort -n | tail -1

A memória é a lacuna: as métricas do hypervisor não veem dentro do guest. Se o CloudWatch agent estiver instalado, as suas métricas de memória estão no namespace CWAgent. Se não, recolha a partir de dentro das instâncias durante umas duas semanas com sar ou com a sua monitorização existente antes de dimensionar o que quer que seja. Adivinhar a memória é a forma como os desenhos acabam ou famintos ou perdulários.

Faça o mesmo para o storage: VolumeReadOps e VolumeWriteOps por volume dão-lhe os IOPS reais, e VolumeReadBytes e VolumeWriteBytes o throughput. Para bases de dados geridas, leia CPUUtilization, FreeableMemory, ReadIOPS e WriteIOPS. Para caches, a memória realmente usada e o número de ligações. Para o tráfego, NetworkOut por instância mostra de onde vem realmente o egress, o que importa para desenhar a rede, não apenas para a fatura.

Terceiro passo: construa a folha de dimensionamento

Coloque as medições numa única folha, uma linha por carga de trabalho:

Carga de trabalho	CPU p95	Memória usada p95	IOPS p95	Quota de egress	Crescimento esperado

Depois dimensione cada uma para o seu pico medido com uma margem que consiga justificar, não para a instância em que corre hoje. Duas regras que aplicamos a todos os desenhos:

• Nunca dê a uma máquina virtual mais vCPU do que os núcleos físicos de um socket de CPU, nem mais memória do que a que um nó NUMA serve. Uma VM espalhada por dois sockets paga uma penalização de memória remota em cada acesso e corre frequentemente mais devagar do que uma mais pequena. Se uma carga de trabalho precisa de mais do que um socket, precisa de escalar horizontalmente ou de passar para bare metal.
• Dimensione corretamente, e depois pare. As infraestruturas cloud estão sistematicamente sobredimensionadas porque redimensionar era arriscado. Em infraestrutura dedicada o tamanho certo é mais barato e frequentemente mais rápido.

Quarto passo: mapeie cada serviço gerido para algo que lhe pertence

Para cada serviço gerido, escreva o que o substitui e o que muda para a aplicação:

Serviço gerido	Substituto que lhe pertence	O que a aplicação nota
MySQL ou MariaDB gerido	Percona XtraDB Cluster ou MariaDB replicado, atrás de ProxySQL	um novo endpoint, nada mais
Redis gerido	Valkey ou Redis com Sentinel	ligar através do Sentinel
Application load balancer	Par HAProxy com endereços flutuantes	nada
DNS gerido	a sua própria infraestrutura PowerDNS	nada, se a mudança for sequenciada
Kubernetes gerido	OpenShift ou OKD em bare metal	os mesmos manifests, com as storage classes revistas

Alguns serviços não têm um equivalente sensato na sua nova casa, ou são baratos e convenientes onde estão. O híbrido é uma resposta legítima: mantenha-os na cloud e ligue os dois de forma privada. Um plano de repatriação que tenta mover tudo é muitas vezes aquele que fica parado.

Quinto passo: desenhe para os failure domains que deixa para trás

As availability zones fizeram trabalho real por si, por isso o novo desenho tem de fazer o mesmo trabalho explicitamente. Mapeie cada camada para hosts separados, arrays de storage separados e, onde importa, sites separados. Os serviços com quórum (bases de dados, caches, coordenadores) precisam de três membros em três failure domains. Escreva-o camada a camada. «Era multi AZ» não é um desenho.

Sexto passo: planeie a mudança de DNS como o caminho crítico que é

O DNS é habitualmente a última coisa a mudar e aquela que pode partir tudo de uma vez. Se a zona está assinada com DNSSEC, sequencie a alteração da chave e do registo DS para que os resolvers com validação nunca vejam uma cadeia quebrada. Descrevemos a mudança completa de um cliente para fora do DNS da AWS na nossa página de managed DNS.

A sua checklist

• Um inventário completo em todas as regiões, com um responsável e uma decisão por recurso.
• Pelo menos um mês de utilização p95 e de pico para CPU, memória, IOPS e egress.
• Memória medida a partir de dentro dos guests, não adivinhada.
• Uma folha de dimensionamento que dimensiona para picos medidos, com as VM mantidas dentro de um socket.
• Cada serviço gerido mapeado para um substituto, ou mantido deliberadamente.
• Failure domains desenhados explicitamente, e a mudança de DNS sequenciada.

Se está a ponderar um regresso a infraestrutura que lhe pertence, teremos todo o gosto em começar pela medição.

CTA

Fale com um engenheiro

Related

Relacionados: Repatriação da cloud e saída de colocation · Migrações de datacenter geridas, ensaiadas · Construção de plataformas de alta disponibilidade