Considérations relatives à la planification de la capacité
- 5 minutes
La planification de la capacité de base commence par certains calculs simples, mais il existe des facteurs qui peuvent compliquer le processus. En plus des nombres d’utilisation actuels et prédits simples, vous devez également prendre en compte les considérations suivantes :
- Limites et quotas du service
- Limitations des coûts
- Inefficacités du code et de la configuration
- Dépendances
Dans cette unité, vous allez examiner la façon dont ces considérations peuvent affecter votre planification de la capacité et comment les traiter.
Limites et quotas du service
Il existe une tendance à voir le cloud computing comme une ressource illimitée. Par rapport aux modèles de serveur/centre de données traditionnels, la capacité du cloud semble infinie. Le cloud offre un tout nouveau niveau de mise à l’échelle. Cependant, comme tout le reste, il a certaines limites. La planification de la capacité implique de comprendre quand vous allez atteindre ces limites de service.
Lorsque vous examinez votre système et son architecture, vous devez comprendre les limites des services cloud que vous utilisez. Par défaut, par exemple, vous pouvez avoir un maximum de 1 000 machines virtuelles par ensemble de disponibilité de machines virtuelles dans Azure. Cette limite peut sembler plus que suffisante de machines virtuelles si vous débutez tout juste. Toutefois, lorsque vous atteignez cette limite, vous ne pouvez pas provisionner de machines virtuelles supplémentaires, ce qui peut entraîner une panne.
Note
Pour les nouvelles déploiements, envisagez d'utiliser des zones de disponibilité ou Flexibles Virtual Machine Scale Sets au lieu des ensembles de disponibilité. Zones de disponibilité offrir une résilience plus élevée en distribuant des machines virtuelles entre des centres de données physiquement distincts au sein d’une région.
De même, par défaut, vous pouvez avoir 250 comptes de stockage par abonnement, par région (cette limite peut être augmentée via une demande de support). Ces limites sont des exemples de limites souples qui peuvent être augmentées. Toutefois, certains services ont des limites maximales, que vous pouvez trouver dans le lien suivant.
Les limites d’abonnement et de service Azure, les quotas et les contraintes
Ces limites et quotas sont quelque chose à connaître et à surveiller. Examinons les façons de le faire.
portail Azure
Vous pouvez voir les quotas de service et où vous êtes en relation avec ces limites dans la section Utilisation + quotas sous Abonnements -> Paramètres dans le volet de navigation. Vous pouvez filtrer sur la catégorie de service telle que réseau/calcul et Azure région. Il vous montre où vous en êtes par rapport aux limites.
Via le code
Vous pouvez utiliser le point de terminaison Usage - List pour n’importe quel service Azure pour obtenir les informations d’utilisation des ressources actuelles et les limites des ressources de calcul sous l’abonnement, comme illustré dans cet exemple tronqué. Consultez la référence de l’API REST Azure pour connaître la dernière version de l’API stable.
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2024-07-01
{
"currentValue": 12,
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/westeurope/usages/virtualMachines",
"limit": 25000,
"name": {
"localizedValue": "Virtual Machines",
"value": "virtualMachines"
},
"unit": "Count"
}
Vous pouvez voir que le nombre actuel de machines virtuelles utilisées est de 12 par rapport à une limite de 25 000. Certaines limites peuvent être augmentées par le biais d’une demande de support, de sorte que vous sachiez à l’avance quand vous risquez de vous rapprocher d’un seuil.
Limitations des coûts
La mise à l’échelle ne consiste pas seulement à affecter plus de ressources au problème. Il est important que votre organisation comprenne le coût de votre environnement cloud et que l’ajout de ressources supplémentaires est généralement plus coûteux. Tenez compte de ce coût et collaborez avec vos équipes financières pour vous assurer que vous êtes en accord avec les dépenses cloud actuelles et projetées.
Vous devez prévoir les coûts lors de la conception initiale des systèmes et lors de l’exécution de révisions régulières de vos systèmes déjà en cours d’exécution. Azure offre des outils qui peuvent vous aider :
- Planifiez le coût d’un environnement à l’aide de la calculatrice Azure.
- Passez en revue les dépenses mensuelles actuelles et prévues dans le portail Azure.
- Configurez des budgets dans Microsoft Cost Management. Cet outil peut vous permettre 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, diriger davantage de ressources peut résoudre un problème, mais cela coûte de l’argent. Parfois, la mise à l’échelle n’est pas la solution ou n’est pas la solution complète. Dans certains cas, il peut être que ce qui semble être un besoin de mise à l’échelle est en fait un problème causé par un codage ou une configuration incorrects.
Vous pouvez potentiellement économiser de l’argent et du temps en recherchant d’abord 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 surchargées, comme l'utilisation d'une seule partition sur une base de données NoSQL énorme, elle est lente, peu importe à quel point vous la développez.
- Si vous avez des requêtes de base de données inefficaces, rendez-les plus performantes avant de lever plus de ressources sur la base de données. Parfois, l’ajout de l’index approprié à une base de données basée sur des requêtes courantes peut réduire vos coûts 100x.
- Si vos délais d’expiration sont définis de manière incorrecte, vos connexions de base de données peuvent être saturées en raison de nouvelles tentatives provenant de 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 ? Peut-être que le code ne libère pas de mémoire quand il pourrait, donc vous avez utilisé des machines virtuelles de mémoire plus volumineuses quand cela n’est pas nécessaire. Les correctifs comme ceux-ci peuvent offrir des économies significatives.
Dépendances
Les modifications nécessaires pour résoudre certains des problèmes décrits dans ce module ont souvent des dépendances vis-à-vis des développeurs de votre application. Certaines des solutions et meilleures pratiques recommandées ici nécessitent une collaboration entre vous et ces développeurs pour qu’il se produise.
Vous ne pourrez peut-être pas implémenter toutes ces recommandations entièrement par vous-même. Toutefois, si vous comprenez le système cloud et ses fonctionnalités et ses caractéristiques, vous pouvez devenir un moteur pour le changement dans l’amélioration de vos systèmes et leur scalabilité et leur fiabilité.