Misurate prima di rientrare: dimensionare un'uscita dal cloud sull'uso reale

L'errore più costoso nel lasciare il public cloud è copiare il parco così com'è. Gli ambienti cloud crescono per provisioning, e ciò che è provisionato non è ciò che è usato: dimensioni di istanza scelte in fretta, volumi dimensionati per un picco mai arrivato, servizi che nessuno ricorda di aver avviato. Spostate tutto uno a uno e porterete lo spreco dentro un contratto a canone fisso. Ecco come misurare ciò che gira davvero prima che qualcuno disegni un nuovo progetto.

Il problema: la fattura descrive ciò che affittate, non ciò che usate

Una fattura cloud elenca tipi di istanza, dimensioni di volume e livelli di servizio. Nulla di questo vi dice quanta CPU la vostra applicazione ha consumato nella sua ora più intensa, quanti IOPS il database ha eseguito davvero, o quanta memoria la cache contiene effettivamente. Sono questi i numeri di cui ha bisogno un progetto fisico o private cloud, e il provider cloud li ha registrati quasi tutti per voi da sempre.

Passo uno: inventariate tutto, non solo i server

Partite da un elenco completo delle risorse in ogni region che avete mai usato. I tag aiutano, ma le risorse senza tag sono esattamente quelle che dovete trovare:

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

Poi raggruppate per servizio. I server sono di solito la parte facile. Il lavoro sta in ciò che li circonda: database gestiti, cache, load balancer, zone DNS, code, bucket di oggetti, certificati, funzioni pianificate, e i ruoli IAM e i security group che li legano insieme. Ognuno ha bisogno di un proprietario e di una decisione: spostare, sostituire, mantenere o dismettere.

Passo due: leggete i percentili, non le medie

Per ogni risorsa di calcolo, estraete almeno un mese di utilizzo, e leggete il 95° percentile e il massimo invece della media. La media di una notte tranquilla e di una sera intensa non descrive né l'una né l'altra.

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

La memoria è la lacuna: le metriche dell'hypervisor non vedono dentro il guest. Se l'agente CloudWatch è installato, le sue metriche di memoria stanno nel namespace CWAgent. Se non lo è, raccogliete dall'interno delle istanze per un paio di settimane con sar o con il vostro monitoraggio esistente prima di dimensionare qualunque cosa. Indovinare la memoria è il modo in cui i progetti finiscono o affamati o sprecati.

Fate lo stesso per lo storage: VolumeReadOps e VolumeWriteOps per volume vi danno gli IOPS reali, e VolumeReadBytes e VolumeWriteBytes il throughput. Per i database gestiti, leggete CPUUtilization, FreeableMemory, ReadIOPS e WriteIOPS. Per le cache, la memoria effettivamente usata e il numero di connessioni. Per il traffico, NetworkOut per istanza mostra da dove viene davvero l'egress, il che conta per progettare la rete, non solo per la fattura.

Passo tre: costruite il foglio di dimensionamento

Mettete le misurazioni in un unico foglio, una riga per workload:

Workload	CPU p95	Memoria usata p95	IOPS p95	Quota di egress	Crescita prevista

Poi dimensionate ciascuno sul suo picco misurato con un margine che sapete giustificare, non sull'istanza su cui gira oggi. Due regole che applichiamo a ogni progetto:

• Non date mai a una macchina virtuale più vCPU di quanti core fisici abbia un singolo socket CPU, né più memoria di quanta ne serva un singolo nodo NUMA. Una VM distribuita su più socket paga una penalità di memoria remota a ogni accesso e spesso gira più lentamente di una più piccola. Se un workload ha bisogno di più di un socket, deve scalare in orizzontale o passare al bare metal.
• Dimensionate correttamente, poi fermatevi. I parchi cloud sono abitualmente sovradimensionati perché ridimensionare era rischioso. Su infrastruttura dedicata la dimensione giusta costa meno ed è spesso più veloce.

Passo quattro: mappate ogni managed service su qualcosa di vostro

Per ogni managed service, scrivete cosa lo sostituisce e cosa cambia per l'applicazione:

Managed service	Sostituto di vostra proprietà	Cosa nota l'applicazione
MySQL o MariaDB gestito	Percona XtraDB Cluster o MariaDB replicato, dietro ProxySQL	un nuovo endpoint; nient'altro
Redis gestito	Valkey o Redis con Sentinel	connessione tramite Sentinel
Application load balancer	Coppia HAProxy con indirizzi flottanti	nulla
DNS gestito	il vostro parco PowerDNS	nulla, se lo spostamento è sequenziato
Kubernetes gestito	OpenShift o OKD su bare metal	gli stessi manifest, con le storage class riviste

Alcuni servizi non hanno un equivalente sensato nella vostra nuova casa, o sono economici e comodi dove stanno. L'ibrido è una risposta legittima: teneteli nel cloud e collegate i due mondi in privato. Un piano di rientro che cerca di spostare tutto è spesso quello che si arena.

Passo cinque: progettate per i domini di guasto che vi lasciate alle spalle

Le availability zone hanno fatto un lavoro reale per voi, quindi il nuovo progetto deve fare lo stesso lavoro in modo esplicito. Mappate ogni livello su host separati, array di storage separati e, dove conta, siti separati. I servizi a quorum (database, cache, coordinatori) hanno bisogno di tre membri in tre domini di guasto. Scrivetelo livello per livello; «era multi AZ» non è un progetto.

Passo sei: pianificate lo spostamento del DNS come il percorso critico che è

Il DNS è di solito l'ultima cosa a spostarsi e quella che può rompere tutto in una volta. Se la zona è firmata con DNSSEC, sequenziate il cambio di chiavi e del record DS così che i resolver validanti non vedano mai una catena rotta. Descriviamo lo spostamento completo di un cliente via dal DNS di AWS nella nostra pagina sul DNS gestito.

La vostra checklist

• Un inventario completo in tutte le region, con un proprietario e una decisione per risorsa.
• Almeno un mese di utilizzo p95 e di picco per CPU, memoria, IOPS ed egress.
• Memoria misurata dall'interno dei guest, non indovinata.
• Un foglio di dimensionamento che dimensiona sui picchi misurati, con le VM tenute dentro un singolo socket.
• Ogni managed service mappato su un sostituto, o mantenuto deliberatamente.
• Domini di guasto progettati esplicitamente, e lo spostamento del DNS sequenziato.

Se state valutando un ritorno a un'infrastruttura di proprietà, siamo lieti di cominciare dalle misurazioni.

cta: Parla con un ingegnere

Related

• /what-we-do/data-web/cloud-repatriation/
• /what-we-do/data-web/datacenter-migrations/
• /what-we-do/data-web/high-availability-platforms/