Dimensionnement adapté et mise à l’échelle automatique

Le redimensionnement adapté consiste à faire correspondre les SKU de VM ou de service Azure aux besoins réels en ressources de votre charge de travail, sans surprovisionner (ce qui gaspille de l'argent) ni sous-provisionner (ce qui risque de dégrader les performances). Lorsqu'elles migrent depuis un environnement local, la plupart des organisations commencent par surprovisionner de 30 à 50 % par prudence. Une analyse régulière du dimensionnement, généralement mensuelle, peut permettre de récupérer une part importante de ces dépenses excessives sans nuire aux performances de l'application.

Utilisez les métriques Azure Monitor et VM Insights pour collecter pendant au moins 30 jours les données relatives au CPU, à la mémoire, aux IOPS des disques et au débit réseau. Examinez l'utilisation de pointe (P95 ou P99), et non la moyenne, afin de garantir que la VM correctement dimensionnée peut gérer les pics de trafic. Par défaut, la recommandation de redimensionnement d'Azure Advisor s'appuie sur les 7 derniers jours, mais vous pouvez étendre cette période à 30 ou 60 jours dans la configuration d'Advisor pour obtenir des données plus représentatives.

Les VM Azure sont organisées en familles de SKU optimisées pour différentes charges de travail : D-series (usage général), E-series (optimisées pour la mémoire), F-series (optimisées pour le calcul), N-series (GPU) et L-series (optimisées pour le stockage). Si l'utilisation du CPU d'une VM est faible mais que celle de la mémoire est élevée, passer d'une série D à une série E avec le même nombre de vCPU fournit davantage de RAM pour un coût similaire. Le redimensionnement d'une VM dans Azure nécessite généralement un bref redémarrage de quelques minutes.

La mise à l'échelle automatique planifiée est le bon choix lorsque les habitudes de charge sont prévisibles. Une application de vente au détail qui connaît un trafic élevé pendant les heures ouvrées et presque aucun trafic pendant la nuit peut être configurée avec une planification de scale-out à 07:00 et de scale-in à 22:00. Virtual Machine Scale Sets (VMSS) et App Service prennent tous deux en charge les règles de mise à l'échelle automatique planifiée. Cette approche est plus simple et permet de mieux prévoir les coûts qu'une mise à l'échelle automatique fondée sur des métriques lorsque les modèles de charge sont connus.

La mise à l'échelle automatique fondée sur les métriques ajoute ou supprime dynamiquement des instances en fonction de métriques en temps réel telles que le pourcentage de CPU, la longueur de la file d'attente des requêtes HTTP ou des métriques personnalisées publiées via Azure Monitor. Vous définissez des règles de scale-out (pour ajouter des instances) et des règles de scale-in (pour supprimer des instances), avec des périodes de refroidissement afin d'éviter les changements rapides et répétés. La bonne pratique consiste à définir un seuil de scale-out inférieur au seuil de scale-in — par exemple, effectuer un scale-out au-delà de 70 % de CPU et un scale-in en dessous de 30 % — avec une période de refroidissement de 5 minutes.

Azure Spot VM vous permet d’utiliser la capacité Azure inutilisée avec des remises pouvant atteindre 90 % par rapport aux tarifs du paiement à l’utilisation. En contrepartie, Azure peut évincer les VM Spot avec un préavis de 30 secondes lorsqu’il a besoin de récupérer cette capacité. Les instances Spot sont donc idéales pour les charges de travail par lots interruptibles, comme le rendu, le calcul scientifique et les pipelines de traitement des données. VMSS prend en charge le mélange de VM régulières (pour une capacité de base) et de VM Spot (pour les pics de capacité) dans le même groupe identique, à l’aide d’une stratégie de mélange des priorités.

La mise à l’échelle automatique de Azure App Service fonctionne au niveau de l’App Service Plan : elle ajoute ou supprime des instances de travail selon les règles que vous configurez. Les déclencheurs disponibles incluent la longueur de la file d’attente HTTP, le pourcentage d’utilisation du CPU et le pourcentage d’utilisation de la mémoire. Le niveau Standard et les niveaux supérieurs prennent en charge la mise à l’échelle manuelle et automatique ; le niveau Basic prend uniquement en charge la mise à l’échelle manuelle. Pour les charges de travail sans serveur, envisagez d’utiliser les fonctions Azure avec le Consumption Plan, qui redimensionnent la capacité jusqu’à zéro et facturent uniquement chaque exécution, ce qui élimine entièrement le coût des instances inactives.

Voici quelques pièges courants de la mise à l’échelle automatique : affinité de session : si votre application stocke l’état de session dans la mémoire d’une VM, la réduction de la capacité entraîne la perte des sessions ; utilisez plutôt Redis Cache ou des sessions stockées dans une Database. Temps de démarrage longs : si les VM ou les conteneurs mettent 10 minutes à démarrer, la mise à l’échelle automatique basée sur les métriques ne peut pas réagir assez rapidement ; préchauffez la capacité en l’augmentant selon un calendrier avant les pics prévus. Réduction de capacité trop agressive : mettre fin à des instances pendant le traitement de requêtes en cours provoque des erreurs ; configurez la vidange des connexions et une période de refroidissement suffisamment longue.

Le dimensionnement adapté s’applique également aux services PaaS. Azure SQL Database utilisant le modèle DTU peut être réduit si le pourcentage de DTU reste constamment inférieur à 50 %. Le modèle vCore permet de faire évoluer indépendamment le CPU et le Storage. Azure Cache for Redis peut passer du niveau Premium au niveau Standard si la persistance et la réplication géographique ne sont pas nécessaires. Les pools de nœuds d’Azure Kubernetes Service peuvent utiliser la mise à l’échelle automatique du cluster pour augmenter ou réduire le nombre de nœuds selon l’état d’attente des pods et leur état d’inactivité.

Le dimensionnement adapté n’est pas une activité ponctuelle. Les charges de travail évoluent au fil du temps : les habitudes de trafic changent, des fonctionnalités sont ajoutées et les bases d’utilisateurs grandissent ou diminuent. Intégrez une revue mensuelle du dimensionnement adapté à votre processus FinOps : récupérez les recommandations du Conseiller, examinez les 10 VM les moins utilisées et les services PaaS surprovisionnés, puis créez des tâches pour les équipes responsables. Suivez les économies réalisées par rapport aux recommandations produites afin de démontrer le ROI FinOps à la direction.

La stratégie de coût optimale consiste à adapter d’abord le dimensionnement, puis à réserver. Acheter une Reserved VM Instance pour une VM surprovisionnée vous engage sur le mauvais SKU. Adaptez d’abord la VM à sa taille correcte, observez sa nouvelle utilisation pendant 30 jours pour en confirmer la stabilité, puis achetez une réservation pour ce SKU correctement dimensionné. Cette approche en deux étapes maximise la remise tout en évitant de payer une capacité réservée inutilisée.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le dimensionnement adapté associe les SKU de VM aux exigences réelles des charges de travail à l’aide de métriques de performance, que la mise à l’échelle automatique planifiée et basée sur les métriques ajuste dynamiquement la capacité pour répondre à la demande, et que les VM Spot offrent des remises pouvant atteindre 90 % pour les charges de travail par lots interruptibles. Nous allons maintenant étudier les Azure Savings Plans et les Reservations pour les charges de travail faisant l’objet d’un engagement.