Considérations relatives à la planification de la capacité
La planification de la capacité de base commence par des calculs simples, mais certains facteurs peuvent compliquer le processus. En plus des valeurs d’utilisation actuelles et prédites simples, vous devez également prendre en compte les éléments suivants :
- Limites et quotas du service
- Limitations de coût
- Inefficacités du code et de la configuration
- Dépendances
Dans cette unité, vous observez l’impact que peuvent avoir ces considérations sur la planification de capacité et voyez comment traiter chacune d’elles.
Limites et quotas du service
Beaucoup ont tendance à voir le cloud computing comme une ressource illimitée. En comparaison avec les modèles traditionnels de serveur/centre de données, la capacité du cloud semble infinie. Il est vrai que le cloud offre un tout nouveau niveau d’échelle. Toutefois, comme tout le reste, il présente certaines limites. La planification de capacité implique de savoir où se situent ces limites de service.
Quand vous observez votre système et son architecture, vous devez comprendre les limites des services cloud que vous utilisez. Par exemple, par défaut, vous pouvez avoir un maximum de 200 machines virtuelles par groupe de machines virtuelles à haute disponibilité dans Azure. Cette limite peut sembler plus que suffisante si vous venez de commencer. Toutefois, une fois cette limite atteinte, vous ne pouvez pas provisionner d’autres machines virtuelles, ce qui peut éventuellement aboutir à une panne.
De même, par défaut, vous pouvez avoir 250 comptes de stockage par abonnement, par région. Il s’agit de deux exemples de limites non strictes qui peuvent être augmentées. Toutefois, certains services ont des limites maximales, que vous pouvez examiner en cliquant sur le lien suivant.
Abonnement Azure et limites, quotas et contraintes de service
Ces limites et quotas doivent être pris en compte et monitorés. Examinons les différentes façons de procéder.
Dans le portail Azure
Vous pouvez voir les quotas de service et votre situation par rapport à ces limites dans la section Utilisation et quotas, sous Abonnements -> Paramètres dans le volet de navigation. Vous pouvez filtrer sur une catégorie de service comme réseau/calcul, et sur une région Azure. Cela vous indique votre situation par rapport aux limites.
Via le code
Vous pouvez utiliser le point de terminaison Usage - List pour tous les services Azure afin d’obtenir les informations d’utilisation des ressources actuelles, ainsi que les limites des ressources de calcul prévues dans l’abonnement, comme indiqué dans cet exemple tronqué.
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{
"currentValue": 124,
"/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
"limit": 1000,
"name": {
"localizedValue": "Virtual Networks",
"value": "VirtualNetworks"
},
"unit": "Count"
}
Vous pouvez voir que le nombre actuel de réseaux virtuels Azure en cours d’utilisation est de 124 pour une limite de 1000. L’augmentation d’une limite nécessite une demande de support. Vous devez donc savoir à l’avance quand vous vous approcherez du seuil.
Limitations de coût
La mise à l’échelle n’est pas un simple ajout de ressources en cas de problème. Il est important que votre organisation comprenne le coût de votre environnement cloud et que l’ajout de ressources entraîne généralement la hausse de ce coût. Soyez conscient de ce coût et collaborez avec vos équipes financières pour vérifier que vous êtes d’accord sur les dépenses cloud actuelles et prévues.
Vous devez prévoir le coût à la fois lors de la conception initiale des systèmes et lors des examens réguliers de vos systèmes déjà en cours d’exécution. Azure propose des outils qui peuvent vous aider à :
- Planifier le coût d’un environnement avec la calculatrice Azure.
- Passer en revue les dépenses mensuelles actuelles et prévues dans le portail Azure.
- Configurer des budgets dans Microsoft Cost Management. Cet outil vous permet d’examiner vos coûts dans différentes étendues, notamment le groupe d’administration, le groupe de ressources et l’abonnement.
Inefficacités du code et de la configuration
Parfois, augmenter le nombre de ressources peut résoudre un problème, mais représente des frais. Parfois, la mise à l’échelle n’est pas la solution ou n’est pas la solution complète. Dans certains cas, ce qui semble être un besoin de mise à l’échelle est en fait un problème causé par une mauvaise configuration ou programmation.
Vous pouvez économiser de l’argent et du temps en recherchant les bogues avant d’effectuer un scale-out des ressources. Voici quelques exemples de cette approche :
- Si vous avez une base de données mal conçue avec des partitions à chaud (en utilisant, par exemple, une seule partition sur une immense base de données noSQL), elle reste lente quelle que soit l’ampleur de la mise à l’échelle.
- Si vous avez des requêtes de base de données inefficaces, rendez-les plus performantes avant d’ajouter des ressources à la base de données. Parfois, le simple ajout de l’index approprié à une base de données basée sur les requêtes courantes peut entraîner une baisse de vos coûts d’un facteur 100.
- Si vos délais d’attente ne sont pas bien définis, vos connexions à la base de données peuvent être saturées en raison de nouvelles tentatives liées à ces délais d’attente incohérents entre le serveur et la base de données. Dans ce cas, vous devez corriger les paramètres avant de mettre à l’échelle la base de données.
- Si le code du développeur est inefficace, pouvez-vous écrire du code plus efficace pour résoudre le problème ? Le code ne libère peut-être pas la mémoire quand il le peut et vous utilisez des machines virtuelles avec plus de mémoire que nécessaire. Des correctifs comme cela peuvent permettre de réaliser des économies substantielles.
Dépendances
Les modifications nécessaires pour résoudre certains des problèmes décrits dans ce module ont souvent des liens de dépendance sur les développeurs de votre application. Certaines solutions et bonnes pratiques recommandées ici nécessitent que vous collaboriez avec ces développeurs pour que ça marche.
Vous ne pouvez peut-être pas implémenter toutes ces recommandations par vous-même. Toutefois, si vous comprenez le système cloud et ses fonctionnalités et caractéristiques, vous pouvez inciter le changement pour améliorer vos systèmes, leur scalabilité et leur fiabilité.