Recommandations pour la conception d’une stratégie de mise à l’échelle fiable

2025-06-21

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :06	Implémentez une stratégie de mise à l’échelle rapide et fiable au niveau de l’application, des données et de l’infrastructure. Basez la stratégie de mise à l’échelle sur des modèles d’utilisation réels ou prédits et réduisez l’intervention manuelle.

Ce guide décrit les recommandations relatives à la conception d’une stratégie de mise à l’échelle fiable.

Définitions

Terme	Définition
Mise à l’échelle verticale	Approche de mise à l’échelle qui ajoute la capacité de calcul aux ressources existantes.
Mise à l’échelle horizontale	Approche de mise à l’échelle qui ajoute des instances d’un type donné de ressource.
Mise à l’échelle automatique	Approche de mise à l’échelle qui ajoute ou supprime automatiquement des ressources lorsqu’un ensemble de conditions est rempli.

Remarque

Les opérations de mise à l’échelle peuvent être statiques (mise à l’échelle quotidienne planifiée régulièrement pour prendre en charge des modèles de charge normaux), automatique (processus automatisé en réponse aux conditions remplies) ou manuel (un opérateur effectue une opération de mise à l’échelle ponctuelle en réaction à un changement de charge imprévu). La mise à l’échelle verticale et horizontale peut être effectuée via l’une de ces méthodes. Toutefois, la mise à l’échelle verticale automatique nécessite un développement d’automatisation personnalisé supplémentaire et peut entraîner un temps d’arrêt en fonction des ressources mises à l’échelle.

Le système doit être conçu pour être évolutif horizontalement. Évitez de faire des hypothèses sur l’affinité d’instance. Ne concevez pas de solutions qui nécessitent que le code s’exécute toujours dans une instance spécifique d’un processus. Lors de la mise à l’échelle horizontale d’un service cloud ou d’un site web, ne supposez pas qu’une série de requêtes provenant de la même source est toujours acheminée vers la même instance. Pour la même raison, il faut concevoir des services sans état pour éviter que l'ensemble de requêtes d'une application doive être toujours acheminé vers la même instance d'un service. Lors de la conception d’un service qui lit les messages à partir d’une file d’attente et les traite, ne faites aucune hypothèse sur l’instance du service qui gère un message spécifique. La mise à l’échelle automatique peut démarrer davantage d’instances d’un service à mesure que la longueur de la file d’attente augmente. Le modèle Consommateurs concurrents décrit comment gérer ce scénario.

Pour utiliser le temps critique dans les décisions de mise à l’échelle automatique, il est utile de disposer d’une bibliothèque pour ajouter automatiquement les informations pertinentes aux en-têtes de messages lorsqu’ils sont envoyés et traités. Une bibliothèque qui fournit cette fonctionnalité est NServiceBus.

Stratégies de conception clés

Conception en fonction des modèles de charge

Pour concevoir une stratégie de mise à l’échelle fiable pour vos charges de travail, concentrez-vous sur l’identification des modèles de charge pour les flux utilisateur et système pour chaque charge de travail qui conduit à une opération de mise à l’échelle. Voici des exemples de différents modèles de charge et de leurs stratégies de mise à l’échelle correspondantes :

Statique: Chaque nuit par 11 PM EST, le nombre d’utilisateurs actifs de votre application tombe en dessous de 100 et l’utilisation du processeur pour les serveurs d’applications diminue de 90% sur tous les nœuds. Pour gérer cela, vous pouvez planifier le scale-down de vos nœuds de calcul jusqu’au nombre minimal (2) entre 11 pm et 6 AM EST.
Dynamique, régulière et prévisible : Chaque lundi matin, 1000 employés dans plusieurs régions se connectent au système ERP. Pour gérer cela, vous pouvez planifier le scale-out de vos nœuds de calcul sur la capacité quotidienne normale avant que la première région commence à fonctionner.
Dynamique, irrégulier et prévisible : Un lancement de produit se produit le premier jour du mois et il existe des données historiques des lancements précédents sur la façon dont le trafic augmente dans ces situations. Pour résoudre ce problème, vous pouvez définir un scale-up planifié unique de vos instances de calcul et de base de données le matin d’un lancement de produit et effectuer un scale-down après une semaine.
Dynamique, irrégulier et imprévisible : Un événement à grande échelle provoque un pic de demande d’un produit. Par exemple, les entreprises qui fabriquent et vendent des déhumidifieurs peuvent subir une augmentation soudaine de la circulation après un ouragan ou un autre événement d’inondation lorsque les personnes dans les zones touchées doivent sécher les pièces dans leurs maisons. Pour gérer ce problème, vous pouvez définir des seuils de mise à l’échelle automatique pour tenir compte des pics de trafic non planifiés.

Adapter les stratégies de mise à l’échelle pour adapter des composants ou des flux individuels

Il n’existe aucune stratégie de mise à l’échelle adaptée à toutes les tailles. Différents services cloud ont différents degrés de prise en charge de la mise à l’échelle et différentes approches de mise à l’échelle. Pour cette raison, il est important de comprendre comment la mise à l’échelle est prise en charge et implémentée dans tous vos composants de charge de travail pour concevoir votre stratégie de mise à l’échelle globale. Vous pouvez appliquer des stratégies de mise à l’échelle au niveau du composant individuel ou au niveau du flux, en fonction de votre conception architecturale. Lorsque vous déterminez la façon dont vous allez implémenter la mise à l’échelle sur votre charge de travail, tenez compte des facteurs suivants :

Ces composants qui ne peuvent pas être mis à l’échelle. Par exemple, les bases de données relationnelles volumineuses qui n’ont pas de partitionnement sont activées et ne peuvent pas être refactornées sans impact significatif. Documentez les limites des ressources publiées par votre fournisseur de cloud et surveillez ces ressources de près. Incluez ces ressources spécifiques dans votre planification future de la migration vers des services évolutifs.
Relation des composants du flux en termes d’ordre des opérations d’échelle. Veillez à ne pas surcharger par inadvertance un composant en aval en mettant d’abord à l’échelle un composant en amont.
Tous les éléments d’application avec état susceptibles d’être interrompus par une opération de mise à l’échelle et toute affinité de session (ou collance de session) implémentée. L’adhérence peut limiter votre capacité de mise à l’échelle et introduire des points de défaillance uniques. Concevez votre charge de travail sans état dans la mesure pratique.
Goulots d’étranglement potentiels. Le scale-out ne résout pas tous les problèmes de performances. Par exemple, si votre base de données principale est le goulot d’étranglement, ajouter des serveurs web ne sert à rien. Identifiez et résolvez les goulots d’étranglement dans le système avant d’ajouter d’autres instances. Les parties avec état du système sont les causes les plus courantes des goulots d’étranglement.
Gestion des tâches longues. Concevez une tâche longue pour prendre en charge le scale-out et la mise à l’échelle. Sans précaution, une telle tâche peut empêcher l’arrêt propre d’une instance d’un processus lorsque le système est mis à l’échelle. Ou peut-être perdre des données si le processus se termine de force. Dans l’idéal, refactorisez une tâche longue et décomposez le traitement qu’il effectue en blocs plus petits et discrets. Le modèle Canaux et filtres fournit un exemple de la façon dont vous pouvez obtenir cette solution.

Choisir la bonne technologie

La mise à l’échelle de vos choix technologiques bien informés vous aidera à vous assurer que votre charge de travail peut répondre à vos objectifs de fiabilité à mesure que votre charge de travail évolue. Recherchez les capacités de mise à l’échelle offertes pour différentes ressources qui offrent des fonctionnalités similaires et choisissez la meilleure combinaison pour vos plans de croissance futurs. Par exemple, vous pouvez avoir plusieurs options pour les magasins de données qui peuvent héberger le type particulier de bases de données que vous utiliserez. Toutefois, un choix peut avoir une meilleure fonctionnalité de mise à l’échelle prête à l’emploi que d’autres, ce qui pourrait le rendre meilleur choix pour votre charge de travail.

Tirez parti des services qui sont automatiquement mis à l’échelle. Quand c’est pratique, utilisez des services SaaS qui sont mis à l’échelle automatiquement sans configuration ni entrée. Les services globaux tels que Microsoft Entra ID offrent cette fonctionnalité. Les solutions serverless offrent également une mise à l’échelle automatique et peuvent être de bons choix pour de nombreux cas d’usage.
Tirez parti des services qui offrent une mise à l’échelle prête à l’emploi. De nombreux services PaaS offrent des fonctionnalités de mise à l’échelle intégrées et faciles à utiliser que vous pouvez configurer pour répondre à vos exigences de fiabilité. Par exemple, vous pouvez configurer la mise à l’échelle du débit pour Cosmos DB pour répondre à vos besoins particuliers.

Automatiser la mise à l’échelle

Automatisez les opérations de mise à l’échelle de vos composants de charge de travail dans une mesure pratique. Lorsque vous utilisez des ressources qui ont des fonctionnalités de mise à l’échelle automatique configurables, générez la logique de configuration dans votre code de déploiement IaC (Infrastructure-as-code). Lorsque vous utilisez des ressources qui n’offrent pas de mise à l’échelle automatique prête à l’emploi, générez l’automatisation pour effectuer des opérations de mise à l’échelle à l’aide d’outils d’automatisation natifs et incluez le code d’automatisation dans votre code IaC.

Si vous basez votre stratégie de mise à l’échelle automatique sur des compteurs qui mesurent les processus métier, tels que le nombre de commandes passées par heure ou le temps d’exécution moyen d’une transaction complexe, assurez-vous de bien comprendre la relation entre les résultats de ces types de compteurs et les besoins de capacité de calcul réels. Il peut être nécessaire de mettre à l’échelle plusieurs composants ou unités de calcul en réponse aux modifications apportées aux compteurs de processus métier.

N’oubliez pas que la mise à l’échelle automatique n’est peut-être pas le mécanisme le plus approprié pour gérer une rafale soudaine d’une charge de travail. Il faut du temps pour provisionner et démarrer de nouvelles instances d’un service ou ajouter des ressources à un système, et la demande maximale peut passer au moment où ces ressources supplémentaires sont disponibles. Dans ce scénario, il peut être préférable de limiter le service. Pour plus d’informations, consultez le modèle de limitation.

À l’inverse, si vous avez besoin de la capacité de traiter toutes les demandes lorsque le volume varie rapidement, et que le coût n’est pas un facteur de contribution majeur, envisagez d’utiliser une stratégie de mise à l’échelle automatique agressive qui démarre plus rapidement des instances. Vous pouvez également utiliser une stratégie planifiée qui démarre un nombre suffisant d’instances pour répondre à la charge maximale avant que cette charge ne soit attendue.

Choisir les unités d’échelle appropriées

Basez votre stratégie de mise à l’échelle sur des unités d’échelle, qui sont le regroupement logique de composants à mettre à l’échelle ensemble et les incréments d’échelle à utiliser (comme passer d’une référence SKU de machine virtuelle à une autre). Les options à prendre en compte sont les suivantes :

Mise à l’échelle des ressources individuellement : vous devrez peut-être mettre à l’échelle uniquement des machines virtuelles ou des bases de données individuelles.
Mise à l’échelle d’un composant complet en même temps : Par exemple, vous pouvez avoir une API de microservice composée d’une application App Service, d’une base de données et de files d’attente qui doivent être mises à l’échelle simultanément.
Mise à l’échelle de la solution complète : pour les charges de travail complexes ou stratégiques, la mise à l’échelle de la solution entière en tant que tampon de déploiement peut simplifier votre stratégie de mise à l’échelle. Au lieu de gérer les planifications de mise à l’échelle et les seuils de mise à l’échelle automatique de nombreuses ressources distinctes, vous pouvez appliquer un ensemble limité de définitions de mise à l’échelle à un tampon de déploiement, puis mettre en miroir celui-ci selon les besoins.

Important

Définissez une limite maximale sur le nombre d’unités d’échelle qui peuvent être automatiquement allouées pour éviter les coûts excédentaires.

Optimiser le temps d’initialisation de l’unité d’échelle

Lorsque vous concevez votre stratégie de mise à l’échelle, gardez à l’esprit que différents services sont mis à l’échelle de temps à différentes échelles de temps. Certains services sont mis à l’échelle quasi instantanément et d’autres qui sont beaucoup plus lents. Par exemple, les instances gestion des API peuvent prendre jusqu’à 45 minutes pour terminer leurs opérations de mise à l’échelle. Pour tenir compte de l’échelle de temps de l’opération de mise à l’échelle, prévoyez correctement d’effectuer l’opération de mise à l’échelle avant que la charge accrue attendue atteigne votre charge de travail. Voici d’autres recommandations à prendre en compte :

Pré-initialisez les nœuds qui seront déployés pour réduire le temps nécessaire à l’initialisation.
Prévoyez un délai de mémoire tampon autour des modifications de configuration avant d’apporter d’autres modifications ou d’utiliser le système de manière rare. Par exemple, vous pouvez libérer une instance principale App Gateway via une modification de règle. Vous devez attendre que les connexions soient vidées de cette instance avant de pouvoir être supprimées en toute sécurité.
Surprovisionner des ressources pour gérer une charge accrue pendant la mise à l’échelle. Vous pouvez vous assurer que les machines virtuelles s’exécutent normalement à 75% capacité d’utilisation pour s’assurer qu’elles peuvent gérer une charge accrue pendant la mise à l’échelle horizontale.
Ajustez vos seuils de mise à l’échelle à l’aide de la surveillance. Utilisez votre supervision de capacité pour vous assurer que vos seuils de mise à l’échelle pour déclencher des opérations de mise à l’échelle.

Mettre à l’échelle les magasins de données à l’aide du partitionnement et du partitionnement

Optimisez la fiabilité de votre patrimoine de données en l’incluant dans votre stratégie de mise à l’échelle. Le partitionnement de données répartit une base de données sur des ressources de stockage logiques ou physiques, en supprimant des points de défaillance uniques. Choisissez la meilleure stratégie de partitionnement pour votre cas d’usage.

Partitionnement horizontal (partitionnement) : les partitions (partitions) sont placées dans des magasins de données distincts, mais toutes les partitions ont le même schéma. Chaque partition contient un sous-ensemble de la base de données. Il s’agit d’une bonne approche pour optimiser la fiabilité, car elle facilite l’équilibrage de charge et réduit le fardeau des opérations lors du traitement des problèmes. Les partitions peuvent être répliquées pour une fiabilité plus élevée.
Partitionnement vertical : chaque partition contient un sous-ensemble des champs des éléments du magasin de données. Les champs sont divisés en fonction de leur modèle d’utilisation.
Partitionnement fonctionnel : les données sont agrégées en fonction de la façon dont chaque contexte limité du système utilise les données.

Envisagez de combiner ces stratégies lorsque vous concevez un schéma de partitionnement. Par exemple, vous pouvez diviser les données en partitions, puis utiliser le partitionnement vertical pour subdiviser davantage les données de chaque partition.

Optimisez votre stratégie de partition pour l’extensibilité. Analysez les modèles d’accès aux données pour déterminer quelles opérations nécessitent le plus de ressources de traitement et équilibrez vos partitions pour vous assurer que chacun dispose de suffisamment de ressources pour gérer les exigences d’extensibilité.

Pour obtenir des instructions détaillées sur le partitionnement et le partitionnement, consultez le guide de conception

Surveiller vos opérations de mise à l’échelle

Le mécanisme de mise à l’échelle automatique doit surveiller le processus de mise à l’échelle automatique et consigner les détails de chaque événement de mise à l’échelle automatique (ce qui l’a déclenché, quelles ressources ont été ajoutées ou supprimées, et quand). Si vous créez un mécanisme de mise à l’échelle automatique personnalisé, assurez-vous qu’il incorpore cette fonctionnalité. Analysez de manière proactive les informations pour mesurer l’efficacité de la stratégie de mise à l’échelle automatique et paramétrez-la si nécessaire.

Facilitation Azure

Une fonctionnalité de mise à l’échelle automatique est disponible dans de nombreux services Azure. Il vous permet de configurer facilement des conditions pour mettre à l’échelle automatiquement des instances horizontalement. Certains services ont des fonctionnalités intégrées limitées ou non pour être mis à l’échelle automatiquement. Veillez donc à documenter ces cas et à définir des processus pour gérer la mise à l’échelle.

De nombreux services Azure offrent des API que vous pouvez utiliser pour concevoir des opérations de mise à l’échelle automatique personnalisées à l’aide d’Azure Automation, telles que les exemples de code dans la mise à l’échelle automatique de votre Hub Azure IoT. Vous pouvez utiliser des outils tels que KEDA pour la mise à l’échelle automatique pilotée par les événements, qui est disponible dans Azure Kubernetes Service et Azure Container Apps.

La mise à l’échelle automatique Azure Monitor fournit un ensemble commun de fonctionnalités de mise à l’échelle automatique pour les groupes de machines virtuelles identiques Azure, Azure App Service, Azure Spring Apps et bien plus encore. La mise à l’échelle peut être effectuée selon une planification ou en fonction d’une métrique d’exécution, telle que l’utilisation du processeur ou de la mémoire. Consultez le guide Azure Monitor pour connaître les meilleures pratiques.

Compromis

Compromis : le scale-up a des implications sur les coûts, donc optimisez votre stratégie pour réduire le scale-down dès que possible pour aider à maintenir les coûts sous contrôle. Assurez-vous que l’automatisation que vous utilisez pour effectuer un scale-up a également des déclencheurs pour effectuer un scale-down.

Exemple :

Reportez-vous aux instructions de mise à l’échelle de l’architecture de référence AKS.

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

liste de contrôle de fiabilité