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

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

Guide connexe : Partitionnement des données

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

Définitions

Stratégies de conception

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 des différents modèles de charge :

• Statique : chaque nuit par 11 PM 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 : tous les lundis matins, 1000 employés de plusieurs régions se connectent au système ERP.

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

• Dynamique, irrégulier et imprévisible : un événement à grande échelle provoque un pic de demande de produit. Par exemple, les entreprises qui fabriquent et vendent des déshumidifieurs peuvent subir une augmentation soudaine de la circulation après un ouragan ou un autre événement d’inondation lorsque des personnes dans des zones touchées doivent sécher 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.

• Générez l’automatisation pour répondre à 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 échelle planifiée de vos nœuds de calcul au nombre minimal (2) entre 11 pm et 6 AM EST.

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

• Dynamique, irrégulier et prévisible : vous définissez un scale-up planifié unique de vos instances de calcul et de base de données le matin d’un lancement de produit, et vous effectuez un scale-down après une semaine.

• Dynamique, irrégulier et imprévisible : vous avez des seuils de mise à l’échelle automatique définis pour tenir compte des pics de trafic non planifiés.

Automatiser les stratégies de mise à l’échelle

Lorsque vous concevez votre automatisation de mise à l’échelle, veillez à prendre en compte ces problèmes :

• Que tous les composants de votre charge de travail doivent être candidats à l’implémentation de la mise à l’échelle. Dans la plupart des cas, les services globaux tels que Microsoft Entra ID sont mis à l’échelle automatiquement et de manière transparente 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.

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

• Le temps nécessaire pour effectuer l’opération de mise à l’échelle afin que vous planifiez correctement l’opération avant que la charge supplémentaire atteigne votre infrastructure. Par exemple, si un composant comme Gestion des API prend 45 minutes pour être mis à l’échelle, 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 à 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 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.

• 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 back-end est le goulot d’étranglement, elle n’aide pas à ajouter d’autres serveurs web. 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.

Le modèle de conception des tampons de déploiement suit votre gestion globale de l’infrastructure. La base de votre conception de mise à l’échelle sur des tampons en tant qu’unités d’échelle est également bénéfique. 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 mettre en miroir celui-ci selon les besoins.

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.

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

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 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, 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 davantage 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 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 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 les informations d’état sur la tâche à intervalles réguliers. Vous pouvez ensuite enregistrer cet état dans un stockage durable accessible par n’importe quelle instance du processus exécutant la tâche. De cette façon, si le processus est arrêté, le travail qu’il effectuait peut être repris à partir du dernier point de contrôle par une autre instance. Il existe des bibliothèques qui fournissent cette fonctionnalité, telles que NServiceBus et MassTransit. Ils conservent en toute transparence l’état dans lequel les intervalles sont alignés sur le traitement des messages à partir de files d’attente dans Azure Service Bus.

Lorsque des tâches en arrière-plan s’exécutent sur des instances de calcul distinctes, comme dans les 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 vice versa. Si vous proposez différents niveaux de service, tels que les 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 répondre aux 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 lorsque son traitement a été terminé. Cet intervalle est appelé temps critique. Si cette valeur de temps critique est inférieure à un seuil métier significatif, il est inutile 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. Mais le temps 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èrent probablement qu’il s’agit d’une période de temps qui ne justifierait pas les dépenses supplémentaires 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 métier ont défini une durée 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 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.

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.

Pour empêcher un système de tenter de monter en puissance excessivement et d’é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 minimum et maximum d'instances pour une règle. En outre, envisagez de dégrader correctement 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é.

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 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 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é, quelles ressources 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 davantage de 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 facilitée.

Exemple

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

Liens connexes

• Mise à l’échelle de l’efficacité des performances
• Meilleures pratiques en matière de mise à l'échelle automatique

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.