Mesurez avant de rapatrier : dimensionner une sortie du cloud à partir de l'usage réel

L'erreur la plus coûteuse en quittant le cloud public est de copier le parc tel qu'il est. Les environnements cloud grandissent par provisionnement, et provisionné ne veut pas dire utilisé : des tailles d'instances choisies dans l'urgence, des volumes dimensionnés pour un pic qui n'est jamais venu, des services que personne ne se souvient d'avoir lancés. Déplacez cela un pour un et vous emportez le gaspillage dans un contrat fixe. Voici comment mesurer ce qui tourne vraiment avant que quiconque dessine une nouvelle architecture.

Le problème : la facture décrit ce que vous louez, pas ce que vous utilisez

Une facture cloud liste des types d'instances, des tailles de volumes et des niveaux de service. Rien de tout cela ne vous dit combien de CPU votre application a consommé à son heure la plus chargée, combien d'IOPS la base de données a réellement effectués, ni combien de mémoire le cache occupe vraiment. Ce sont les chiffres dont une architecture physique ou de private cloud a besoin, et le fournisseur cloud les enregistrait pour vous depuis le début.

Première étape : inventorier tout, pas seulement les serveurs

Commencez par une liste complète des ressources dans chaque région que vous avez jamais utilisée. Les tags aident, mais les ressources sans tag sont précisément celles qu'il faut trouver :

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

Puis regroupez par service. Les serveurs sont en général la partie facile. Le travail est dans ce qui les entoure : bases de données managées, caches, load balancers, zones DNS, files d'attente, buckets d'objets, certificats, fonctions planifiées, et les rôles IAM et security groups qui les relient. Chacun a besoin d'un propriétaire et d'une décision : déplacer, remplacer, conserver ou retirer.

Deuxième étape : lire des percentiles, pas des moyennes

Pour chaque ressource de calcul, extrayez au moins un mois d'utilisation, et lisez le 95e percentile et le maximum plutôt que la moyenne. La moyenne d'une nuit calme et d'une soirée chargée ne décrit ni l'une ni l'autre.

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 mémoire est le trou : les métriques de l'hyperviseur ne voient pas à l'intérieur de l'invité. Si l'agent CloudWatch est installé, ses métriques mémoire sont dans le namespace CWAgent. Sinon, collectez depuis l'intérieur des instances pendant une ou deux semaines avec sar ou votre supervision existante avant de dimensionner quoi que ce soit. Deviner la mémoire est la façon dont les architectures finissent soit affamées, soit gaspilleuses.

Faites de même pour le stockage : VolumeReadOps et VolumeWriteOps par volume vous donnent les IOPS réels, et VolumeReadBytes et VolumeWriteBytes le débit. Pour les bases de données managées, lisez CPUUtilization, FreeableMemory, ReadIOPS et WriteIOPS. Pour les caches, la mémoire réellement utilisée et le nombre de connexions. Pour le trafic, NetworkOut par instance montre d'où vient vraiment l'egress, ce qui compte pour concevoir le réseau, pas seulement pour la facture.

Troisième étape : construire la feuille de dimensionnement

Mettez les mesures dans une feuille, une ligne par charge de travail :

Charge de travail	CPU p95	Mémoire utilisée p95	IOPS p95	Part d'egress	Croissance attendue

Puis dimensionnez chacune à son pic mesuré avec une marge que vous pouvez justifier, pas à l'instance sur laquelle elle tourne aujourd'hui. Deux règles que nous appliquons à chaque architecture :

• Ne donnez jamais à une machine virtuelle plus de vCPU qu'un socket CPU n'a de cœurs physiques, ni plus de mémoire qu'un nœud NUMA n'en sert. Une VM étalée sur deux sockets paie une pénalité de mémoire distante à chaque accès et tourne souvent plus lentement qu'une plus petite. Si une charge de travail a besoin de plus d'un socket, elle doit monter en charge horizontalement ou passer sur du bare metal.
• La bonne taille, puis on s'arrête. Les parcs cloud sont systématiquement surdimensionnés parce que redimensionner était risqué. Sur une infrastructure dédiée, la bonne taille est moins chère et souvent plus rapide.

Quatrième étape : associer chaque service managé à quelque chose qui vous appartient

Pour chaque service managé, notez ce qui le remplace et ce qui change pour l'application :

Service managé	Remplacement qui vous appartient	Ce que l'application remarque
MySQL ou MariaDB managé	Percona XtraDB Cluster ou MariaDB répliqué, derrière ProxySQL	un nouveau endpoint, rien d'autre
Redis managé	Valkey ou Redis avec Sentinel	se connecter via Sentinel
Application load balancer	Paire HAProxy avec adresses flottantes	rien
Managed DNS	votre propre parc PowerDNS	rien, si le déplacement est séquencé
Kubernetes managé	OpenShift ou OKD sur bare metal	les mêmes manifests, avec les storage classes revues

Certains services n'ont pas d'équivalent raisonnable dans votre nouveau foyer, ou sont bon marché et pratiques là où ils sont. L'hybride est une réponse légitime : gardez-les dans le cloud et reliez les deux en privé. Un plan de rapatriement qui essaie de tout déplacer est souvent celui qui s'enlise.

Cinquième étape : concevoir pour les domaines de panne que vous laissez derrière vous

Les zones de disponibilité faisaient un vrai travail pour vous, donc la nouvelle architecture doit faire le même travail explicitement. Associez chaque tier à des hôtes distincts, des baies de stockage distinctes et, là où cela compte, des sites distincts. Les services à quorum (bases de données, caches, coordinateurs) ont besoin de trois membres dans trois domaines de panne. Écrivez-le tier par tier. « C'était multi AZ » n'est pas une architecture.

Sixième étape : planifier le déplacement du DNS comme le chemin critique qu'il est

Le DNS est en général la dernière chose à déplacer et celle qui peut tout casser d'un coup. Si la zone est signée avec DNSSEC, séquencez le changement de clé et d'enregistrement DS pour que les résolveurs validants ne voient jamais de chaîne rompue. Nous décrivons le déplacement complet d'un client hors du DNS d'AWS sur notre page managed DNS.

Votre checklist

• Un inventaire complet sur toutes les régions, avec un propriétaire et une décision par ressource.
• Au moins un mois d'utilisation p95 et de pic pour le CPU, la mémoire, les IOPS et l'egress.
• La mémoire mesurée depuis l'intérieur des invités, pas devinée.
• Une feuille de dimensionnement qui dimensionne aux pics mesurés, avec les VM gardées dans un seul socket.
• Chaque service managé associé à un remplacement, ou délibérément conservé.
• Les domaines de panne conçus explicitement, et le déplacement du DNS séquencé.

Si vous pesez un retour vers une infrastructure qui vous appartient, nous serons heureux de commencer par la mesure.

CTA

Parler à un ingénieur

Related

Articles liés : Rapatriement cloud (cloud repatriation) et sorties de colocation · Migrations de datacenter infogérées, répétées · Constructions de plateformes haute disponibilité