Les 5 tactiques éprouvées qui ont réduit nos coûts Azure de 30%

En 2017, ShareGate a dépensé 250 000 $ sur Azure. Même avec un MVP Azure dans notre équipe nous aidant à maintenir les coûts aussi bas que possible, notre facture a quand même augmenté de 45 % en moins de 12 mois. Le principal coupable, bien sûr, était l’étalement du cloud.

Nous savions que des économies massives étaient possibles, alors nous avons demandé à nos experts de nous établir une liste de méthodes pratiques et efficaces de contrôle des coûts du cloud pour réduire nos dépenses Azure.

Nous avons compilé nos conclusions dans ce guide afin que vous puissiez vous aussi commencer à identifier dès maintenant les économies potentielles d’Azure dans les environnements de votre organisation.

.

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.

Les VM basées sur le cloud présentent un défi en termes de contrôle des coûts : elles nécessitent généralement des spécifications minimales pour fonctionner et sont souvent inactives avec des pics d’utilisation périodiques, mais elles continuent d’encourir le coût total tant qu’elles sont sous tension.

En septembre 2017, Microsoft a annoncé la famille de machines virtuelles B-Series, également connues sous le nom de machines virtuelles éclatables. Ces machines sont spécifiquement conçues pour les charges de travail qui doivent toujours être disponibles, mais qui sont généralement inactives avec des pics d’utilisation occasionnels. Les VM de la série B offrent un potentiel de réduction des coûts important : entre 15 et 55 % du prix d’une machine équivalente de la série D, selon le système d’exploitation que vous utilisez.

Lecture recommandée : Azure cost-saving tips : dos and don’ts from industry insiders, par Leigh Ryan

So I should convert all my existing VMs to B-Series and save big?

Attention maintenant ! Toutes les charges de travail ne peuvent pas être converties en B-Series aveuglément. Vous devez trouver un équilibre entre le coût et la consommation de CPU. Les séries B se voient attribuer une quantité de base de puissance CPU. Tant que son utilisation est inférieure à la ligne de base, la VM accumule des crédits, qui peuvent ensuite être utilisés pour consommer des CPU dépassant la ligne de base. Toutefois, si votre machine virtuelle devient trop gourmande en CPU, elle sera bridée aux performances de la ligne de base jusqu’à ce que suffisamment de crédits soient disponibles.

Les lignes de base et les limites de crédit varient en fonction de la taille de chaque VM de série B. En outre, chaque fois que la VM est mise hors tension, tous les crédits accumulés sont perdus. À ce titre, les VM de série B sont véritablement conçues pour les charges de travail à faible utilisation ou prévisibles qui doivent être disponibles à tout moment.

Pour vous aider à déterminer si votre machine virtuelle peut être convertie en série B en toute sécurité, vous pouvez exécuter des scripts personnalisés tels que le script Azure-Burst-Check de Dave Hall.

Identifier et agir sur les ressources inactives

Grâce à Azure, il n’a jamais été aussi facile de mettre en place un nouvel environnement et de le faire fonctionner au pied levé dès qu’il s’agit de répondre à un nouveau besoin de votre organisation. 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. Consultez notre abécédaire sur la création d’un plan de gouvernance des coûts du cloud pour avoir un aperçu des éléments fondamentaux à prendre en compte : visibilité, propriété et autorisations, cycle de vie et optimisation – ou, comme nous aimons les appeler, VOLO.

En bref, pour chaque ressource que vous créez, vous voudrez :

• Utiliser des balises et d’autres stratégies pour catégoriser la façon dont l’actif sera utilisé (dev, test, prod, etc.)
• Spécifier un propriétaire unique pour la ressource (généralement la personne qui a demandé la ressource)
• Déterminer une date d’expiration ou de vérification pour la ressource (et s’assurer de suivre le calendrier et d’éliminer rapidement les ressources inutiles)

Une fois que vous avez ces informations, il est beaucoup plus facile de déterminer si une ressource donnée est encore nécessaire ou non et d’agir en conséquence.

Lecture recommandée : Comment démarrer et arrêter vos VM avec Azure Automation, par Antoine Jagueneau

Je n’ai pas de plan de gouvernance des coûts. Que faire maintenant ?

Azure vous donne accès à un ensemble de statistiques d’utilisation qui mesurent le niveau d’activité de vos ressources. Ces valeurs peuvent être examinées depuis le portail Azure, en accédant à l’API Azure et en utilisant un code personnalisé, ou par le biais d’une solution de gestion des coûts dédiée. En examinant ces chiffres d’utilisation, vous pouvez identifier les actifs qui ne sont plus utilisés (ou nettement sous-utilisés) et prendre les mesures appropriées. Gardez également à l’esprit que la gouvernance des coûts du cloud est un processus itératif, il n’est donc jamais trop tard pour commencer à travailler sur un plan.

Trouver la bonne taille de ressource

Un problème courant lors de la création de nouvelles ressources cloud est de déterminer la bonne taille à utiliser. Azure propose un grand nombre d’options pour répondre à différents besoins (plus de RAM, plus de puissance CPU, des disques SSD, des GPU, etc.), mais même au sein d’une même famille de machines, choisir la bonne taille a son importance.

Lecture recommandée : Comment fonctionne la tarification des VM Azure, par Leigh Ryan

Si vous vous trompez, vous paierez plus que nécessaire pendant que votre machine tourne au ralenti, ou vous vous retrouverez avec une machine épinglée à 100 % d’utilisation du CPU (ou pire encore, qui bascule en mémoire virtuelle parce qu’elle n’a plus de RAM physique). Tout cela, bien sûr, peut avoir un impact significatif sur les performances des applications.

Il n’est pas toujours facile de déterminer à l’avance les exigences d’un système donné, et il peut donc être tentant d’aller un peu plus haut que ce dont vous avez besoin, juste pour être sûr. Il est également assez fréquent de l’oublier ensuite et de le laisser surdimensionné, ce qui entraîne des coûts inutiles mois après mois.

Comment pouvez-vous éviter cela ? Nous allons examiner quelques stratégies dans cet article.

La façon la plus simple d’éviter de gaspiller de l’argent sur la consommation inutile de ressources, cependant, est de laisser un outil d’optimisation du cloud dédié surveiller votre locataire et vous avertir chaque fois qu’il y a une opportunité de redimensionner, de réduire la taille ou de réduire autrement une ressource donnée.

Quand réduire la taille

Si vous pensez que cela peut être le cas pour votre environnement, ne paniquez pas ! Il existe quelques moyens simples de déterminer si vous devez réduire la taille d’une VM donnée. La méthode la plus simple consiste à jeter un coup d’œil aux graphiques du pourcentage de CPU et du pourcentage de mémoire pour chaque ressource dans le portail Azure.

Typiquement, les tailles des instances dans Azure doublent avec chaque niveau : une S1 aura 1 cœur de CPU accompagné de 1,75 Go de RAM, tandis qu’une S2 aura 2 cœurs et 3,5 Go de RAM. Le même schéma s’applique également aux tailles des bases de données et aux DTU.

Dans tous les cas, si vous constatez sur une longue période que les deux statistiques d’utilisation sont inférieures à 50 %, vous pouvez en toute confiance réduire la taille de votre instance sans craindre de nuire aux performances.

Pourquoi ne puis-je pas voir l’utilisation de la mémoire pour ma VM?

Malheureusement, vous n’obtiendrez pas les graphiques de pourcentage de mémoire pour les machines virtuelles, classiques ou gérées, dès la sortie de la boîte. Pour accéder à ces informations, vous devrez activer la surveillance au niveau des invités et vérifier les bons compteurs de performance. Celui que vous devez vérifier spécifiquement est MemoryCommitted Bytes. Avec ces informations, vous devriez être en mesure de déterminer si un service peut être réduit en toute sécurité ou non.

Localiser et supprimer les disques inutilisés

Si vous utilisez Azure depuis un certain temps, vous avez probablement créé – et supprimé – un bon nombre de machines virtuelles. Mais votre facture continue d’augmenter, et vous ne savez pas vraiment pourquoi. Les disques de stockage sont probablement en cause, plus précisément les disques des machines virtuelles supprimées qui traînent encore sur votre compte et vous coûtent de l’argent mois après mois. Cette situation est encore plus probable si vous utilisez des machines virtuelles classiques plutôt que la nouvelle variété ARM. La raison en est très simple : Azure ne supprime pas systématiquement vos disques lorsque vous supprimez une machine virtuelle. Cela a pour but de vous protéger contre les pertes de données accidentelles, mais cela signifie également que si vous ne faites pas attention, vous continuerez à payer pour des disques dont vous n’avez plus besoin.

Vous pouvez résoudre ce problème depuis le portail 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. Utilisez la barre de recherche Azure pour trouver le compte de stockage que vous avez noté à l’étape 1, puis ouvrez le volet Propriétés

4. Cliquez sur Blobs, puis sélectionnez la ligne avec le bon conteneur de stockage

5. Cochez la case avec le nom de fichier correct, puis cliquez sur Supprimer dans le menu supérieur

VHD oubliés

Même si vous suivez toutes ces étapes pour identifier les disques non attachés, vous risquez toujours de passer à côté de VHD oubliés qui reposent à l’abandon dans le stockage classique. Généralement, le portail Azure crée un conteneur « vhds » et les place là dans un compte de stockage. Pour les localiser, vérifiez chaque compte de stockage classique pour trouver un conteneur vhds sous Blobs. À l’intérieur du conteneur, regardez la colonne État de location pour chaque fichier. Si elle indique Disponible, cela signifie qu’aucune VM n’utilise actuellement ce VHD et que vous pouvez le supprimer en toute sécurité (mais vous devez toujours vérifier le contenu pour vous en assurer !).

L’exploitation des bases de données de pool élastique

Il est fort probable que vous ayez commencé votre projet de migration vers le cloud en déplaçant vers Azure des charges de travail qui étaient auparavant hébergées sur site ou dans un centre de données privé. Un grand nombre de ces charges de travail utilisaient probablement des bases de données SQL Server, qui avaient tendance à constituer l’épine dorsale de la plupart des projets logiciels avant l’essor du cloud et du mouvement NoSQL. Vous avez également probablement remarqué que la tarification des bases de données SQL dans Azure peut devenir assez élevée, assez rapidement.

Alors qu’auparavant vous pouviez utiliser un seul serveur de base de données pour héberger des dizaines, voire des centaines, de bases de données pour vos différents projets ou clients, le coût de leur fractionnement en bases de données SQL Azure distinctes pourrait être des ordres de grandeur plus élevés que ce à quoi vous vous attendiez. Cela est dû à la façon dont les bases de données fonctionnent dans Azure. Sur site, vous étiez habitué à ce que plusieurs bases de données partagent les ressources limitées d’un seul serveur. Avec Azure SQL, chaque base de données dispose d’une quantité de ressources réservée, qui vous sera facturée même si la base de données est inactive. Ce modèle est idéal si vous avez plusieurs bases de données dont l’utilisation est constante et prévisible. Si vous avez un grand nombre de bases de données avec un modèle d’utilisation en dents de scie, cependant, vous pouvez trouver l’étiquette de prix nettement moins attrayante. Cela vous laisse deux options :

• Utiliser un niveau de base de données plus grand et plus cher pour gérer les pics d’utilisation des bases de données
• Utiliser un niveau inférieur pour économiser des coûts, au détriment des performances pendant les périodes de pointe

Pour partager les ressources entre les bases de données, les premiers adoptants d’Azure ont été contraints de créer et de maintenir leurs propres machines virtuelles avec SQL Server installé et de reproduire essentiellement les conditions dans lesquelles elles étaient exécutées lorsqu’elles étaient sur site ou dans un centre de données privé. Si cette méthode fonctionnait bien, elle ne permettait pas d’accéder à toutes les excellentes fonctionnalités qu’Azure SQL a à offrir, telles que :

• Haute disponibilité intégrée (pas besoin de configurer la réplication)
• Géo-réplication active
• Restauration ponctuelle

Ces fonctionnalités ne sont pas triviales à déployer par soi-même et peuvent être un défi à maintenir.

Mieux : Instances gérées

Azure propose un niveau plus récent de services de base de données SQL appelé instances gérées, qui sont essentiellement des machines virtuelles gérées qui hébergent un serveur SQL. Les instances gérées ne vous fourniront pas toutes les fonctionnalités intégrées aux services Azure SQL à base de données unique, mais vous n’aurez pas non plus besoin de gérer le système d’exploitation ou l’installation de SQL Server. En gros, vous obtenez une machine virtuelle dont la configuration et la maintenance sont largement prises en charge pour vous.

Meilleur : les pools élastiques SQL

Mais il existe une autre option dans Azure pour répondre à ce scénario courant : Les pools élastiques SQL. Au lieu de réserver une certaine quantité de ressources pour une seule base de données, les pools élastiques SQL vous permettent de réserver un certain nombre de ressources et de les partager entre des centaines de bases de données. Ce modèle présente tous les avantages d’Azure SQL et vous permet de gérer correctement les schémas d’utilisation en dents de scie sur plusieurs bases de données. Les pools élastiques se sont avérés incroyablement populaires et constituent une option idéale pour les applications multi-locataires.

Cependant, vous devez être prudent dans votre utilisation des pools élastiques. Si vous avez une ou plusieurs bases de données dont l’utilisation est nettement supérieure à celle des autres bases de données d’un pool, vous pouvez être contraint d’acheter un niveau de pool élastique plus coûteux pour gérer les pics d’utilisation. Dans certains cas, il peut être plus rentable de diviser ces bases de données à forte utilisation en offres de bases de données uniques (en les retirant du pool) et de payer un niveau de pool élastique plus petit pour les bases de données restantes à faible utilisation. Une bonne règle de base est de regarder l’utilisation des DTU de la base de données : si une seule base de données utilise 40 % ou plus des DTU du pool élastique à un moment donné, vous pouvez être en mesure d’économiser des coûts en la séparant du pool, puis en réduisant ledit pool à un niveau moins coûteux.

Comme toujours, le portail Azure est votre référence pour identifier les modèles d’utilisation des bases de données.

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?