Considérations relatives à la planification de la capacité

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 exemple, par défaut, vous pouvez avoir un maximum de 200 machines virtuelles par groupe à haute disponibilité de machine virtuelle dans Azure. Cette limite peut sembler plus que suffisamment de machines virtuelles si vous commencez simplement. Toutefois, lorsque vous atteignez cette limite, vous ne pouvez pas provisionner de machines virtuelles supplémentaires, ce qui peut entraîner une panne.

De même, par défaut, vous pouvez avoir 250 comptes de stockage par abonnement, par région. 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.

Abonnement Azure et limites, quotas et contraintes du service

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 le réseau/ le calcul et la région Azure. Il vous montre où vous êtes contre les limites.

Via le code

Vous pouvez utiliser le Usage - List point de terminaison 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é.

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 utilisés est de 124 par rapport à une limite de 1 000. L’augmentation d’une limite nécessite une demande de support. Vérifiez donc que vous connaissez à l’avance quand vous risquez de vous rapprocher du seuil.

Limitations des coûts

La mise à l’échelle ne consiste pas seulement à lever 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 propose 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.
• Configurer 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 chaudes, telles que l’utilisation d’une seule partition sur une base de données noSQL énorme, il est lent, quelle que soit la quantité de mise à l’échelle.
• 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é.