Partager via

Mise à l’échelle automatique

La mise à l’échelle automatique désigne le processus d’allocation dynamique de ressources destiné à répondre aux besoins en matière de performances. À mesure que le volume de travail augmente, une application peut nécessiter des ressources supplémentaires afin de garantir les niveaux de performances souhaités et de respecter les contrats de niveau de service (SLA). Étant donné que la demande diminue et que les ressources supplémentaires ne sont plus nécessaires, elles peuvent être désallouées pour réduire les coûts.

La mise à l’échelle automatique tire parti de l’élasticité des environnements hébergés dans le cloud tout en allégeant les contraintes de gestion. Elle réduit la nécessité de recourir à un opérateur dédié à la supervision continue des performances d’un système, ainsi qu’à l’ajout et au retrait des ressources.

La mise à l’échelle d’une application peut s’effectuer de deux manières :

  • La mise à l’échelle verticale, également appelée mise à l’échelle vers le haut et vers le bas, signifie changer la capacité d’une ressource. Par exemple, vous pouvez déplacer une application vers une plus grande taille de machine virtuelle. La mise à l’échelle verticale nécessite souvent que le système soit temporairement indisponible pendant son redéploiement. Par conséquent, il est moins courant d’automatiser la mise à l’échelle verticale.

  • La mise à l’échelle horizontale, également appelée amplification et réduction, signifie l’ajout ou la suppression d’instances d’une ressource. Pendant que de nouvelles ressources sont approvisionnées, l’application continue à s’exécuter sans interruption. Une fois le processus de provisionnement terminé, la solution est déployée sur ces ressources supplémentaires. Si la demande baisse, les ressources supplémentaires peuvent être arrêtées proprement, puis libérées.

De nombreux systèmes cloud, notamment Microsoft Azure, prennent en charge la mise à l’échelle horizontale automatique. Le reste de cet article se concentre sur la mise à l’échelle horizontale.

Remarque

La mise à l’échelle automatique s’applique principalement aux ressources de calcul. Bien qu’il soit possible de mettre à l’échelle horizontalement une base de données ou une file d’attente de messages, ce processus implique généralement le partitionnement des données, ce qui n’est généralement pas automatisé.

Composants de mise à l’échelle automatique

Une stratégie de mise à l’échelle automatique implique généralement les composants suivants :

  • Systèmes d’instrumentation et de surveillance au niveau de l’application, du service et de l’infrastructure. Ces systèmes capturent les métriques clés, telles que les temps de réponse, les longueurs de file d’attente, l’utilisation du processeur et l’utilisation de la mémoire.

  • La logique de prise de décision évalue ces métriques d’utilisation dynamique par rapport aux seuils ou planifications prédéfinis et détermine s’il faut effectuer une mise à l’échelle.

  • Les composants et mécanismes effectuent l’action de mise à l’échelle. Dans l’idéal, ces composants et mécanismes doivent être découplés du code de charge de travail lui-même et gérés en tant que processus externe. Le code inactif ou submergé ne devrait pas être responsable de sa propre mise à l'échelle.

  • Fonctionnalités de test, de surveillance et de réglage de la stratégie de mise à l’échelle automatique pour s’assurer qu’elle fonctionne comme prévu.

Azure fournit des mécanismes de mise à l’échelle automatique intégrés qui traitent des scénarios courants. Si un service ou une technologie particulier n’a pas de fonctionnalité de mise à l’échelle automatique intégrée ou si vous avez des exigences de mise à l’échelle automatique spécifiques au-delà de ses fonctionnalités, envisagez une implémentation personnalisée. Une implémentation personnalisée collecte les métriques opérationnelles et système, analyse les métriques et met à l’échelle les ressources en conséquence.

Configurer la mise à l’échelle automatique pour une solution Azure

Azure fournit une mise à l’échelle automatique intégrée pour la plupart des options de calcul.

Ces options de calcul utilisent toutes la fonctionnalité de mise à l’échelle automatique Azure Monitor pour fournir un ensemble commun de fonctionnalités de mise à l’échelle automatique.

  • Azure Functions diffère des options de calcul précédentes, car vous n’avez pas besoin de configurer de règles de mise à l’échelle automatique. Au lieu de cela, Azure Functions alloue automatiquement la puissance de calcul lorsque votre code s’exécute. Azure Functions effectue un scale-out si nécessaire pour gérer la charge. Pour plus d’informations, consultez Choisir le plan d’hébergement approprié pour Azure Functions.

Une solution de mise à l’échelle automatique personnalisée peut parfois être utile. Par exemple, vous pouvez utiliser diagnostics Azure et les métriques basées sur des applications, ainsi que du code personnalisé pour surveiller et exporter les métriques d’application. Vous pouvez ensuite définir des règles personnalisées en fonction de ces métriques et utiliser les API REST Azure Resource Manager pour déclencher la mise à l’échelle automatique. Toutefois, une solution personnalisée n’est pas simple à implémenter et doit être considérée uniquement si aucune des approches précédentes ne peut répondre à vos besoins.

Utilisez les fonctionnalités intégrées de mise à l’échelle automatique de la plateforme si elles répondent à vos besoins. Si ce n’est pas le cas, déterminez soigneusement si vous avez besoin de fonctionnalités de mise à l’échelle plus complexes. Par exemple, d’autres exigences peuvent inclure une granularité plus précise du contrôle, différentes façons de détecter les événements déclencheurs pour la mise à l’échelle, la mise à l’échelle entre les abonnements et la mise à l’échelle d’autres types de ressources.

Utiliser la fonctionnalité de mise à l’échelle automatique Azure Monitor

La fonctionnalité de mise à l'échelle automatique Azure Monitor fournit un ensemble commun de fonctionnalités de mise à l’échelle automatique pour les ensembles d'échelles de machines virtuelles, App Service et Azure Cloud Services. 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.

Prenons les exemples suivants :

  • Effectuez un scale-out à 10 instances les jours de la semaine et effectuez un scale-in à quatre instances le samedi et le dimanche.

  • Effectuez un scale-out d’une instance si l'utilisation moyenne du CPU est supérieure à 70%, et effectuez un scale-in d'une instance si le CPU tombe en dessous de 50%.

  • Effectuez un scale-out d’une instance si le nombre de messages d’une file d’attente excède un certain seuil.

Augmentez les ressources lorsque la charge augmente pour garantir la disponibilité. En cas de faible utilisation, effectuez un scale-down afin de pouvoir optimiser les coûts. Utilisez toujours une combinaison de règles de scale-out et de scale-in. Sinon, la mise à l’échelle automatique n’a lieu que dans une direction jusqu’à atteindre le seuil (nombre maximal ou minimal d’instances) défini dans le profil.

Sélectionnez un nombre d’instances par défaut sécurisé pour votre charge de travail. La ressource est mise à l’échelle en fonction de cette valeur si le nombre maximal ou minimal d’instances n’est pas défini.

Pour obtenir la liste des métriques intégrées, consultez les métriques courantes de mise à l’échelle automatique Azure Monitor. Vous pouvez également implémenter des métriques personnalisées à l’aide d’Application Insights.

Vous pouvez configurer la mise à l’échelle automatique à l’aide de PowerShell, d’Azure CLI, d’un modèle Azure Resource Manager ou du portail Azure. Pour un contrôle plus détaillé, utilisez l’API REST Resource Manager. Azure Monitoring Management Library et Microsoft Insights Library (en préversion) sont des kits SDK qui permettent de collecter des métriques à partir de différentes ressources et d’effectuer une mise à l’échelle automatique en utilisant les API REST. Pour les ressources où la prise en charge de Resource Manager n’est pas disponible ou si vous utilisez Azure Cloud Services, l’API REST Gestion des services peut être utilisée pour la mise à l’échelle automatique. Dans tous les autres cas, utilisez Resource Manager.

Tenez compte des points suivants lors de l’utilisation de la mise à l’échelle automatique :

  • Déterminez si vous pouvez prédire la charge sur l’application suffisamment précisément pour utiliser la mise à l’échelle automatique planifiée, l’ajout et la suppression d’instances pour répondre aux pics prévus de la demande. Si ce n’est pas le cas, utilisez la mise à l’échelle automatique réactive en fonction des métriques d’exécution pour gérer les changements imprévisibles de la demande. En règle générale, vous pouvez combiner ces approches.

    Par exemple, créez une stratégie qui ajoute des ressources en fonction d’une planification des heures où vous savez que l’application est la plus sollicitée. Des ressources supplémentaires permettent de s’assurer que la capacité est disponible si nécessaire, sans délai de démarrage de nouvelles instances. Pour chaque règle planifiée, définissez des métriques qui permettent la mise à l’échelle automatique réactive pendant cette période pour garantir que l’application peut gérer des pics soutenus mais imprévisibles dans la demande.

  • Il est souvent difficile de comprendre la relation entre les métriques et les besoins en capacité, en particulier lorsqu’une application est déployée initialement. Configurez une petite capacité supplémentaire au début, puis surveillez et ajustez les règles de mise à l’échelle automatique pour rapprocher la capacité de la charge réelle.

  • Configurez les règles de mise à l’échelle automatique, puis surveillez les performances de votre application au fil du temps. Utilisez les résultats de cette surveillance pour ajuster la façon dont le système s'adapte si nécessaire. Toutefois, gardez à l’esprit que la mise à l’échelle automatique n’est pas un processus instantané. Il faut du temps pour réagir à une métrique telle que l’utilisation moyenne du processeur dépassant ou tombant en dessous d’un seuil spécifié.

  • Les règles de mise à l’échelle automatique qui utilisent un mécanisme de détection basé sur un attribut de déclencheur mesuré utilisent une valeur agrégée au fil du temps, plutôt que des valeurs instantanées, pour déclencher une action de mise à l’échelle automatique. Les attributs de déclencheur incluent l’utilisation du processeur ou la longueur de file d’attente. Par défaut, l’agrégat est une moyenne des valeurs. Cette approche empêche le système de réagir trop rapidement ou de provoquer une oscillation rapide. Il permet également de consacrer du temps aux nouvelles instances qui sont automatiquement démarrées pour entrer en mode opérationnel. D’autres actions de mise à l’échelle automatique ne peuvent pas se produire pendant le démarrage des nouvelles instances. Pour les services cloud Azure et les machines virtuelles Azure, la période par défaut de l’agrégation est de 45 minutes. Ainsi, cela peut prendre un certain temps pour que la métrique active la mise à l’échelle automatique en réponse aux pics de demande. Vous pouvez modifier la période d’agrégation à l’aide du Kit de développement logiciel (SDK), mais les périodes de moins de 25 minutes peuvent entraîner des résultats imprévisibles. Pour la fonctionnalité Web Apps d’App Service, la période moyenne est plus courte, ce qui permet aux nouvelles instances d’être disponibles en environ cinq minutes après une modification de la mesure du déclencheur moyen.

  • Évitez le bagottement qui alterne continuellement les actions de scale-in et de scale-out. Supposons qu’il existe deux instances. La limite supérieure est de 80% processeur et la limite inférieure est de 60%. Lorsque la charge est à 85%, une autre instance est ajoutée. Après un certain temps, la charge diminue à 60%. Avant le scale-in du service de mise à l’échelle automatique, il calcule la distribution de la charge totale (de trois instances) lorsqu’une instance est supprimée, en la prenant à 90%. Il faudrait effectuer un scale-out immédiatement. Par conséquent, il saute l'étape de mise à l'échelle et vous pourriez ne jamais voir les résultats escomptés de mise à l'échelle.

    La situation de bagottement peut être contrôlée en optant pour une marge adéquate entre les seuils de scale-out et scale-in.

  • La mise à l’échelle manuelle est réinitialisée en fonction du nombre maximal et minimal d’instances utilisées pour la mise à l’échelle automatique. Si vous mettez manuellement à jour le nombre d’instances sur une valeur supérieure ou inférieure à la valeur maximale, le moteur de mise à l’échelle automatique revient automatiquement à la valeur minimale (si elle est inférieure) ou à la valeur maximale (si elle est supérieure). Par exemple, vous définissez la plage entre trois et six. Si vous avez une instance en cours d’exécution, le moteur de mise à l’échelle automatique s’adapte à trois instances lors de sa prochaine exécution. De même, si vous définissez manuellement la mise à l’échelle sur huit instances, lors de la prochaine exécution, la mise à l’échelle automatique revient à six instances sur sa prochaine exécution. La mise à l’échelle manuelle est temporaire, sauf si vous réinitialisez également les règles de mise à l’échelle automatique.

  • Le moteur de mise à l’échelle automatique traite un seul profil à la fois. Si une condition n’est pas remplie, elle recherche le profil suivant. Conservez les métriques clés hors du profil par défaut, car ce profil est vérifié en dernier. Dans un profil, vous pouvez avoir plusieurs règles. Pour le scale-out, la mise à l’échelle automatique s’exécute si une règle est respectée. Lors de la réduction d'échelle, l'autoscaling exige que toutes les règles soient respectées.

    Pour plus d’informations sur la mise à l’échelle d’Azure Monitor, consultez les meilleures pratiques pour la mise à l’échelle automatique.

  • Si vous configurez la mise à l’échelle automatique à l’aide du Kit de développement logiciel (SDK) plutôt que du portail, vous pouvez spécifier une planification plus détaillée pendant laquelle les règles sont actives. Vous pouvez également créer vos propres métriques et les utiliser avec ou sans aucune des règles existantes dans vos règles de mise à l’échelle automatique. Par exemple, vous pouvez utiliser d’autres compteurs, tels que le nombre de requêtes par seconde ou la disponibilité moyenne de la mémoire. Vous pouvez également utiliser des compteurs personnalisés pour mesurer des processus métier spécifiques.

  • Lorsque vous mettez automatiquement à l’échelle Service Fabric, les types de nœuds de votre cluster sont constitués de groupes de machines virtuelles identiques au serveur principal. Vous devez donc configurer des règles de mise à l’échelle automatique pour chaque type de nœud. Prenez en compte le nombre de nœuds dont vous devez disposer avant de configurer la mise à l’échelle automatique. Votre niveau de fiabilité pilote le nombre minimal de nœuds dont vous devez disposer pour le type de nœud principal. Pour plus d’informations, consultez Mettre à l’échelle un cluster Service Fabric en augmentant ou réduisant à l’aide de règles de mise à l’échelle automatique.

  • Vous pouvez utiliser le portail pour lier des ressources telles que des instances azure SQL Database et des files d’attente à une instance de service cloud. Cette méthode vous permet d’accéder plus facilement aux options de configuration manuelle et automatique distinctes pour chacune des ressources liées. Pour plus d’informations, consultez Gérer les services cloud Azure.

  • Lorsque vous configurez plusieurs stratégies et règles, elles peuvent entrer en conflit les unes avec les autres. La mise à l’échelle automatique utilise les règles de résolution de conflits suivantes pour s'assurer qu’il existe toujours un nombre suffisant d’instances en cours d’exécution.

    • Les opérations de scale-out priment toujours sur les opérations de scale-in.

    • Quand des opérations de scale-out sont en conflit, la règle à l’origine de l’augmentation la plus élevée du nombre d’instances prime.

    • Lorsque les opérations de mise à l’échelle sont en conflit, la règle qui initie la plus petite diminution du nombre d’instances est prioritaire.

  • Dans un App Service Environment, vous pouvez utiliser toutes les mesures front-end ou de pool Worker pour définir des règles de mise à l’échelle automatique. Pour plus d’informations, consultez vue d’ensemble de l’environnement App Service.

Considérations relatives à la conception d’application

La mise à l’échelle automatique ne constitue pas une solution instantanée. L’ajout de ressources à un système ou l’exécution de plusieurs instances d’un processus ne garantit pas que les performances du système s’améliorent. Lors de l’élaboration d’une stratégie de mise à l’échelle automatique, tenez compte des points suivants :

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

  • Si la solution implémente une tâche longue, créez-la pour qu’elle prenne en charge à la fois le scale-out et le scale-in. Sans conception appropriée, 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 est arrêté 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. Pour obtenir un exemple, consultez le modèle Canaux et filtres.

  • 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. Enregistrez ces informations d’état dans un stockage durable auquel toute instance du processus qui exécute la tâche peut accéder. Par conséquent, si le processus est arrêté, le travail qu’il effectuait peut être repris à partir du dernier point de contrôle à l’aide d’une autre instance. Il existe des bibliothèques qui fournissent cette fonctionnalité, telles que NServiceBus et MassTransit. Elles conservent en toute transparence l’état où 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 davantage d’instances de calcul d’interface utilisateur sans augmenter le nombre d’instances de calcul en arrière-plan ou l’inverse. Vous pouvez offrir 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 les ressources pour les packages de service de base. Cette approche vous aide à respecter les SLA.

Autres critères de mise à l’échelle

  • Tenez compte de la longueur de la file d’attente sur laquelle l’interface utilisateur et les instances de calcul en arrière-plan communiquent. Utilisez-le comme critère pour votre stratégie de mise à l’échelle automatique. Ces critères peuvent indiquer un déséquilibre ou une différence entre la charge actuelle et la capacité de traitement de la tâche en arrière-plan. Il existe un attribut légèrement plus complexe mais meilleur pour baser les décisions de mise à l'échelle. Utilisez l’heure entre l’envoi d’un message et la fin de son traitement, appelée heure critique. Si cette valeur de temps critique est inférieure à un seuil opérationnel significatif, il est inutile d'augmenter la capacité, même si 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 ce point de terminaison traite de l’intégration avec un service web partenaire pour l’envoi d’e-mails. Les parties prenantes de l’entreprise peuvent ne pas considérer ce scénario comme suffisamment urgent pour justifier le coût du scale-out.

    • 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, le scale-out est logique.

    • Pour utiliser un moment 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 de messages pendant la transmission et le traitement. Une de ces bibliothèques 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, assurez-vous de bien comprendre la relation entre les résultats de ces types de compteurs et les besoins réels en capacité de calcul. Par exemple, les compteurs incluent le nombre de commandes passées toutes les heures ou le runtime moyen d’une transaction complexe. 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, envisagez de limiter le nombre maximal d’instances qui peuvent être ajoutées automatiquement. Cette approche évite également les coûts associés à l’exécution de plusieurs milliers d’instances. La plupart des mécanismes de mise à l’échelle automatique vous permettent de spécifier le nombre minimal et maximal d’instances d’une règle. En outre, envisagez de dégrader correctement les fonctionnalités que le système fournit si vous déployez le nombre maximal d’instances 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 de charge de travail. Il faut du temps pour configurer 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 requêtes lorsque le volume varie rapidement, envisagez d’utiliser une stratégie de mise à l’échelle automatique agressive qui démarre des instances supplémentaires plus rapidement. Assurez-vous que le coût n’est pas un facteur de contribution majeur. 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.

  • 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. Ces détails incluent ce qui a déclenché l’événement, quelles ressources ont été ajoutées ou supprimées, et quand elle s’est produite. Si vous créez un mécanisme de mise à l’échelle automatique personnalisé, assurez-vous qu’il incorpore cette fonctionnalité. Analysez les informations pour mesurer l’efficacité de la stratégie de mise à l’échelle automatique et paramétrez-la si nécessaire. Vous pouvez régler les deux à court terme, à mesure que les modèles d’utilisation deviennent plus évidents et à long terme, à mesure que l’entreprise s’étend 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 des ressources supplémentaires 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 réduite.

Les modèles et conseils suivants peuvent également être pertinents pour votre scénario lors de l’implémentation de la mise à l’échelle automatique :

  • Le modèle de limitation décrit comment une application peut continuer à fonctionner et à répondre aux contrats SLA lorsqu’une augmentation de la demande place une charge extrême sur les ressources. Vous pouvez utiliser une limitation de mise à l’échelle automatique pour éviter de surcharger un système pendant son scale-out.

  • Le modèle Consommateurs concurrents décrit comment implémenter un pool d’instances de service qui peuvent gérer les messages de n’importe quelle instance d’application. La mise à l’échelle automatique peut être utilisée pour démarrer et arrêter les instances de service pour correspondre à la charge de travail attendue. Cette approche permet à un système de traiter plusieurs messages simultanément pour optimiser le débit, améliorer la scalabilité et la disponibilité, et équilibrer la charge de travail.

  • La surveillance et les diagnostics, y compris l’instrumentation et les métriques, sont essentielles pour collecter les informations qui peuvent conduire le processus de mise à l’échelle automatique.