Rightsizing des instances et des options de stockage

Le rightsizing permet de reprendre le contrôle des dépenses en éliminant les gaspillages évidents au niveau des instances et du stockage utilisé.

De Nombreux outils peuvent aider à cela :

• AWS Trusted Advisor
• Azure Advisor
• Google Cloud ...
• CloudHealth
• Turbonomic
• Apptio
• Cloud Checkr
• Lota.Cloud
• Teevity
• ...

Il est bien sûr possible de faire ce travail soi-même en analysant l’utilisation de chaque instance et en déduisant les meilleures choix d’instances mais les combinaisons sont très nombreuses et il peut y avoir des facteurs de « bottlenecks » difficiles à détecter à l’œil. On pense toujours à la CPU et la mémoire mais quid des IOPS ? Un outil  peut clairement aider.

Et il ne s’agit pas de regarder uniquement les VMs mais de se poser aussi la question sur le stockage : Quelle est la bonne classe à utiliser, quelles options, pour que le service soit rendu au meilleur prix et sans gaspillage inutile.

Une fois la liste des recommandations faite, il faut les analyser et valider les changements : Un outil peut aussi se tromper ou pour être plus précis ne sera peut-être pas en mesure d’anticiper une hausse d’activité que vous avez prévu.

Enfin il faut planifier et exécuter les changements validés via votre gouvernance habituelle. Voici à quoi peut ressembler en très haut niveau le processus :

Cas d'AWS

AWS EC2 a différentes familles d'instances.

• A usage général : A1, T2, T3, M4, M5
• Optimisées pour le calcul : C4, C5
• Optimisées pour la mémoire : R5, R4, X1
• Optimisées pour le calcul accéléré : P2, P3, G4, G3, F1
• Optimisées pour le stockage : D2, I3, H1

Au sein de chaque famille, il existe différentes tailles (micro, small, medium, large, xlarge, 2xlarge, 4xlarge...) dont la taille double à chaque fois.

On peut par exemple avoir sélectionner une instance de type c4.2xlarge pour couvrir un besoin estimé à 8GHz de CPU et 11GB de Mémoire. Puis se rendre compte que le maximum utilisé est de 1.5 GHz de CPU et 7.5GB de mémoire. Une instance M1.large couvrirait ce besoin pour moitié moins cher. Mais il ne faut pas s'arrêter là car les instances M1 sont de première génération et il existe de nouveaux types avec des performance améliorées pour une prix inférieur. Dans notre cas une instance M4.large serait un meilleur choix.

Mais on peut aller encore plus loin en cherchant des instances "burstable", qui n'ont pas des performances fixes comme les M4. Une t2.large par exemple est limitée en temps normal à 60% de 2 CPU mais peut "monter" jusqu'à 2 au besoin en utilisant des "crédits". On peut donc réduire encore les coûts si ce type d'instance répond au besoin (76% moins cher que le c4.2xlarge initial).