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

  • Article

S’applique à cette recommandation de liste de vérification de fiabilité 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.

Guide associé :Partitionnement des données

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

Définitions

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

Notes

Les opérations de mise à l’échelle peuvent être statiques (mise à l’échelle quotidienne planifiée régulièrement pour prendre en charge les modèles de charge normaux), automatiques (processus automatisé en réponse aux conditions remplies) ou manuelles (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ée supplémentaire et peut entraîner des temps d’arrêt en fonction des ressources mises à l’échelle.

Stratégies de conception

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 l’utilisateur et les flux système pour chaque charge de travail qui conduit à une opération de mise à l’échelle. Voici des exemples des différents modèles de charge :

  • Statique : chaque nuit à 23 h EST, le nombre d’utilisateurs actifs est inférieur à 100 et l’utilisation du processeur pour les serveurs d’applications diminue de 90 % sur tous les nœuds.

  • Dynamique, régulière et prévisible : chaque lundi matin, 1 000 employés dans plusieurs régions se connectent au système ERP.

  • Dynamique, irrégulière et prévisible : un lancement de produit a lieu 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.

  • Dynamique, irrégulière et imprévisible : un événement à grande échelle provoque un pic de demande pour un produit. Par exemple, les entreprises qui fabriquent et vendent des déshumidificateurs 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 des pièces dans leur maison.

Une fois que vous avez identifié ces types de modèles de charge, vous pouvez :

  • Identifiez la façon dont la modification de charge associée à chaque modèle affecte votre infrastructure.

  • Créez l’automatisation pour traiter la mise à l’échelle de manière fiable.

Pour les exemples précédents, vos stratégies de mise à l’échelle peuvent être les suivantes :

  • Statique : vous disposez d’une mise à l’échelle planifiée de vos nœuds de calcul au nombre minimal (2) entre 23 h et 6 h HNE.

  • Dynamique, régulière et prévisible : vous disposez d’un scale-out planifié de vos nœuds de calcul à la capacité quotidienne normale avant que la première région ne commence à fonctionner.

  • Dynamique, irrégulière et prévisible : vous définissez une mise à l’échelle planifiée unique de vos instances de calcul et de base de données le matin d’un lancement de produit, puis vous effectuez un scale-down après une semaine.

  • Dynamique, irrégulière et imprévisible : vous avez défini des seuils de mise à l’échelle automatique pour prendre en compte les pics de trafic non planifiés.

Lors de la conception de votre automatisation de mise à l’échelle, veillez à tenir compte des problèmes suivants :

  • Que tous les composants de votre charge de travail doivent être candidats pour l’implémentation de la mise à l’échelle. Dans la plupart des cas, les services globaux tels que Microsoft Entra l’ID sont mis à l’échelle automatiquement et en toute transparence pour vous et vos clients. Veillez à comprendre les fonctionnalités de mise à l’échelle de vos contrôleurs d’entrée et de sortie réseau et de votre solution d’équilibrage de charge.

  • Composants qui ne peuvent pas faire l’objet d’un scale-out. Par exemple, les bases de données relationnelles volumineuses qui n’ont pas de partitionnement activé et ne peuvent pas être refactorisée sans impact significatif. Documentez les limites de 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.

  • Temps nécessaire pour effectuer l’opération de mise à l’échelle afin de planifier correctement l’opération pour qu’elle se produise avant que la charge supplémentaire n’atteigne votre infrastructure. Par exemple, si un composant comme Gestion des API met à l’échelle 45 minutes, l’ajustement du seuil de mise à l’échelle à 65 % au lieu de 90 % peut vous aider à effectuer une mise à l’échelle plus tôt et à vous préparer à l’augmentation prévue de la charge.

  • 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 amont.

  • Tous les éléments d’application avec état qui peuvent être interrompus par une opération de mise à l’échelle et toute affinité de session (ou adhérence de session) implémentée. L’adhérence peut limiter votre capacité de mise à l’échelle et introduit des points de défaillance uniques.

  • 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, il n’est pas utile d’ajouter d’autres serveurs web. Identifiez et résolvez d’abord 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.

Suivre le modèle de conception d’empreinte de déploiement vous aide à gérer l’ensemble de votre infrastructure. La base de votre conception de mise à l’échelle sur des empreintes en tant qu’unités d’échelle est également bénéfique. Et il vous aide à contrôler étroitement vos opérations de mise à l’échelle sur plusieurs charges de travail et sous-ensembles de charges de travail. 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 les miroir sur les empreintes si nécessaire.

Compromis : La montée en puissance a des implications sur les coûts. Par conséquent, optimisez votre stratégie pour effectuer un scale-down dès que possible afin de maîtriser les coûts. Assurez-vous que l’automatisation que vous utilisez pour effectuer un scale-up a également des déclencheurs pour effectuer un scale-down.

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 les instances horizontalement. Certains services ont des fonctionnalités intégrées limitées ou inexistantes pour la mise à l’échelle automatique. Veillez donc à documenter ces cas et à définir des processus pour gérer la mise à l’échelle.

De nombreux services Azure proposent des API que vous pouvez utiliser pour concevoir des opérations de mise à l’échelle automatique personnalisées à l’aide de Azure Automation, comme les exemples de code dans mise à l’échelle automatique de votre Azure IoT Hub. 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 d’Azure Monitor fournit un ensemble commun de fonctionnalités de mise à l’échelle automatique pour Azure Virtual Machine Scale Sets, 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

Considérations relatives à la mise à l’échelle automatique

La mise à l’échelle automatique ne constitue pas une solution instantanée. Le simple ajout de ressources à un système ou l’exécution d’un nombre plus important d’instances de processus ne vous garantit pas l’amélioration des performances du système. Lors de l’élaboration d’une stratégie de mise à l’échelle automatique, tenez compte des points suivants :

Le système peut être mis à l’échelle horizontalement. Évitez de faire des suppositions sur instance affinité. Ne concevez pas de solutions qui nécessitent que le code s’exécute toujours dans un instance spécifique d’un processus. Lors de la mise à l’échelle horizontale d’un service cloud ou d’un site web, ne partez pas du principe qu’une série de requêtes provenant de la même source est toujours acheminée vers le même instance. Pour la même raison, concevez les services sans état, afin d’éviter que l’ensemble des requêtes d’une application soient dirigées vers la même instance d’un service. Quand vous concevez un service qui lit les messages d’une file d’attente avant de les traiter, n’anticipez pas l’identité de l’instance du service qui traite un message spécifique. La mise à l’échelle automatique peut démarrer plus d’instances d’un service à mesure que la longueur de la file d’attente augmente. L’article Modèle des consommateurs concurrents explique comment gérer ce scénario.

Si la solution implémente une longue tâche, configurez-la pour qu’elle prenne en charge à la fois l’augmentation et la réduction. Sans précaution, une telle tâche pourrait empêcher une instance d’un processus d’être arrêtée proprement lorsque le système est mis à l’échelle. Ou bien, il peut perdre des données si le processus s’arrête de force. Dans l’idéal, refactorisez une tâche longue et divisez le traitement exécuté en bloc plus petits, discrets. Le modèle Canaux et filtres fournit un exemple de la façon dont vous pouvez obtenir cette solution.

Vous pouvez également implémenter un mécanisme de point de contrôle qui enregistre des informations d’état sur la tâche à intervalles réguliers. Vous pouvez ensuite enregistrer cet état dans un stockage durable accessible à n’importe quel instance du processus exécutant la tâche. Ainsi, si le processus est arrêté, le travail qu’il effectuait peut être repris à partir du dernier point de contrôle par un autre instance. Il existe des bibliothèques qui fournissent cette fonctionnalité, telles que NServiceBus et MassTransit. Ils persistent de manière transparente, où les intervalles sont alignés sur le traitement des messages provenant des files d’attente dans Azure Service Bus.

Lorsque des tâches en arrière-plan s’exécutent sur des instances de calcul distinctes, telles que dans des rôles de travail d’une application hébergée par des services cloud, vous devrez peut-être mettre à l’échelle différentes parties de l’application à l’aide de différentes stratégies de mise à l’échelle. Par exemple, vous devrez peut-être déployer des instances de calcul d’interface utilisateur supplémentaires sans augmenter le nombre d’instances de calcul en arrière-plan, ou inversement. Si vous proposez différents niveaux de service, tels que des packages de service de base et premium, vous devrez peut-être effectuer un scale-out des ressources de calcul pour les packages de service Premium de manière plus agressive que pour les packages de service de base afin de respecter les contrats de niveau de service (SLA).

Prenez en compte la longueur de la file d’attente sur laquelle communiquent les instances de calcul en arrière-plan et d’interface utilisateur. Utilisez-la comme critère pour votre stratégie de mise à l’échelle automatique. Ce problème est un indicateur possible d’un déséquilibre ou d’une différence entre la charge actuelle et la capacité de traitement de la tâche en arrière-plan. Un attribut légèrement plus complexe mais meilleur sur lequel baser les décisions de mise à l’échelle consiste à utiliser le temps entre le moment où un message a été envoyé et le moment où son traitement a été terminé. Cet intervalle est appelé heure critique. Si cette valeur de temps critique est inférieure à un seuil métier significatif, il n’est pas nécessaire de mettre à l’échelle, même si la longueur de la file d’attente est longue.

Par exemple, il peut y avoir 50 000 messages dans une file d’attente. Toutefois, l’heure critique du message le plus ancien est de 500 ms, et le point de terminaison traite de l’intégration avec un service web tiers pour l’envoi d’e-mails. Les parties prenantes de l’entreprise considéreraient probablement qu’il s’agit d’une période de temps qui ne justifierait pas l’utilisation d’argent supplémentaire pour la mise à l’échelle.

En revanche, il peut y avoir 500 messages dans une file d’attente, avec le même temps critique de 500 ms, mais le point de terminaison fait partie du chemin critique dans un jeu en ligne en temps réel où les parties prenantes de l’entreprise ont défini un temps de réponse de 100 ms ou moins. Dans ce cas, l’opération de scale-out serait logique.

Pour utiliser le temps critique dans les décisions de mise à l’échelle automatique, il est utile qu’une bibliothèque ajoute automatiquement les informations pertinentes aux en-têtes des messages pendant leur envoi et leur traitement. NServiceBus est une bibliothèque qui fournit cette fonctionnalité.

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 la durée d’exécution moyenne d’une transaction complexe, veillez à bien comprendre la relation entre les résultats de ces types de compteurs et les besoins réels en capacité de calcul. 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.

Pour empêcher un système d’effectuer un scale-out excessif et éviter les coûts associés à l’exécution de plusieurs milliers d’instances, envisagez de limiter le nombre maximal d’instances ajoutées automatiquement. La plupart des mécanismes de mise à l’échelle automatique vous permettent de spécifier le nombre minimal et maximal d’instances pour une règle. En outre, envisagez de dégrader normalement les fonctionnalités que le système fournit si le nombre maximal d’instances ont été déployées et que le système est toujours surchargé.

Gardez à l’esprit que la mise à l’échelle automatique n’est peut-être pas le mécanisme le plus approprié pour gérer une rafale soudaine dans une charge de travail. L’approvisionnement et le démarrage de nouvelles instances d’un service ou l’ajout de ressources à un système prennent du temps, 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 Modèle de limitation.

À l’inverse, si vous avez besoin de la capacité de traiter toutes les demandes lorsque le volume fluctue rapidement et que le coût n’est pas un facteur important, envisagez d’utiliser une stratégie de mise à l’échelle automatique agressive qui démarre plus rapidement plus d’instances. Vous pouvez également utiliser une stratégie planifiée qui démarre un nombre suffisant d’instances pour satisfaire de manière anticipée la charge maximale.

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é, les ressources qui ont été ajoutées ou supprimées, et quand). Si vous créez un mécanisme personnalisé de mise à l’échelle automatique, veillez à intégrer cette fonctionnalité. Analysez les informations pour aider à mesurer l’efficacité de la stratégie de mise à l’échelle automatique et ajustez-la si nécessaire. Vous pouvez effectuer un réglage à la fois à court terme, à mesure que les modèles d’utilisation deviennent plus évidents, et à long terme, à mesure que l’entreprise se développe ou que les exigences de l’application évoluent. Si une application atteint la limite supérieure définie pour la mise à l’échelle automatique, le mécanisme peut également alerter un opérateur qui peut démarrer manuellement d’autres ressources si nécessaire. Dans ces circonstances, l’opérateur peut également être responsable de la suppression manuelle de ces ressources une fois la charge de travail allégée.

Exemple

Reportez-vous aux conseils 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é