Mise à l’échelle automatique

  • Article

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). Lorsque la demande diminue et que les ressources supplémentaires ne sont plus requises, il est possible de libérer ces dernières pour minimiser 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 montée ou descente en puissance, consiste à modifier la capacité d’une ressource. Par exemple, vous pouvez déplacer une application vers une machine virtuelle de taille supérieure. La mise à l’échelle verticale implique fréquemment l’inaccessibilité momentanée du système lors de son redéploiement. Il est donc plus inhabituel d’automatiser la mise à l’échelle verticale.

  • La mise à l’échelle horizontale, également appelée augmentation ou diminution de la taille des instances, consiste à ajouter ou supprimer des instances d’une ressource. Pendant que de nouvelles ressources sont approvisionnées, l’application continue à s’exécuter sans interruption. Une fois le processus d’approvisionnement terminé, la solution est déployée sur ces ressources supplémentaires. Si la demande diminue, les ressources supplémentaires peuvent être correctement arrêtées et libérées.

De nombreux systèmes basés sur le 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.

Notes

La mise à l’échelle automatique s’applique principalement aux ressources de calcul. Bien qu’il soit possible de procéder à la mise à l’échelle horizontale d’une base de données ou d’une file d’attente de messages, cette opération implique habituellement un partitionnement des données, lequel n’est généralement pas automatisé.

Composants de mise à l’échelle automatique

Une stratégie de mise à l’échelle automatique implique les éléments suivants :

  • Systèmes de surveillance et d’instrumentation au niveau de l’application, des services et de l’infrastructure. Ces systèmes capturent des mesures clés, telles que le temps de réponse, les longueurs des files d’attente, l’utilisation du processeur et l’utilisation de la mémoire.
  • Logique de prise de décision qui évalue ces métriques par rapport aux planifications ou aux seuils prédéfinis et détermine si une mise à l’échelle est ou non nécessaire.
  • Composants procédant à la mise à l’échelle du système.
  • le test, la surveillance et le réglage de la stratégie de mise à l’échelle automatique, afin de garantir son bon fonctionnement.

Azure intègre des mécanismes de mise à l’échelle automatique qui sont adaptés aux scénarios courants. Si un service ou une technologie spécifiques n’intègrent pas de fonctionnalités de mise à l’échelle automatique, ou que certaines de vos exigences de mise à l’échelle dépassent leurs capacités, vous pouvez envisager une implémentation personnalisée. Une implémentation personnalisée peut collecter des métriques opérationnelles et système, analyser ces métriques, puis mettre à l’échelle les ressources en conséquence.

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

Azure intègre une mise à l’échelle automatique pour la plupart des options de calcul.

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

  • La solution Azure Functions diffère des options de calcul précédentes, car elle ne nécessite pas la configuration de règles de mise à l’échelle automatique. À la place, Azure Functions alloue automatiquement une puissance de calcul lorsque votre code s’exécute, et augmente la taille des instances selon les besoins pour gérer la charge. Pour plus d’informations, consultez l’article Choisir le plan d’hébergement approprié pour Azure Functions.

Enfin, une solution de mise à l’échelle automatique personnalisée peut parfois se révéler utile. Par exemple, vous pouvez utiliser les diagnostics et les métriques Azure basées sur l’application, ainsi qu’un code personnalisé pour superviser et exporter les métriques d’application. Vous pouvez ensuite définir des règles personnalisées reposant sur ces métriques, et utiliser les API REST Resource Manager pour déclencher la mise à l’échelle automatique. Toutefois, une solution personnalisée n’est pas simple à implémenter et doit être envisagée uniquement si aucune des approches précédentes ne peut répondre à vos exigences.

Utilisez les fonctionnalités de mise à l’échelle automatique intégrées de la plateforme, si elles répondent à vos exigences. Sinon, étudiez soigneusement l’opportunité de recourir à des fonctionnalités de mise à l’échelle plus complexes. Une granularité de contrôle supérieure, différents moyens de détection des événements déclencheurs de la mise à l’échelle automatique, la mise à l’échelle entre les abonnements et la mise à l’échelle d’autres types de ressources constituent quelques exemples d’exigences supplémentaires.

Utiliser la mise à l’échelle Azure Monitor

La mise à l’échelle Azure Monitor offre un ensemble commun de fonctionnalités de mise à l’échelle automatique pour les groupes de machines virtuelles identiques, Azure App Service et Azure Cloud Service. La mise à l’échelle peut être planifiée ou basée sur une métrique collectée au moment de l’exécution, telle que l’utilisation de l’UC ou de la mémoire.

Exemples :

  • Effectuez un scale-out jusqu’à 10 instances pendant les jours ouvrés et effectuez un scale-in jusqu’à 4 pour les samedis et dimanches.
  • Ajoutez une instance supplémentaire si l’utilisation moyenne de l’UC dépasse 70 %, et retirez une instance si l’utilisation de l’UC tombe en deçà de 50 %.
  • Effectuez un scale-out d’une instance si le nombre de messages d’une file d’attente excède un certain seuil.

Effectuez un scale-up de la ressource lorsque la charge augmente pour garantir la disponibilité. De même, lors des moments de faible utilisation, effectuez un scale-down afin d’optimiser le coût. Utilisez toujours une combinaison de règles de scale-out et de scale-in. Dans le cas contraire, la mise à l’échelle automatique n’intervient que dans une seule direction jusqu’à ce qu’elle atteigne le seuil (nombre maximal ou minimal d’instances) défini dans le profil.

Sélectionnez un nombre d’instances par défaut qui est sécurisé pour votre charge de travail. Elle 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 Métriques courantes pour la mise à l’échelle automatique d’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, de l’interface de ligne de commande Azure, d’un modèle Azure Resource Manager ou du portail Azure. Pour bénéficier d’un contrôle plus précis, utilisez l’API REST Azure Resource Manager. Les bibliothèques Azure Monitoring Service Management Library et Microsoft Insights Library (en version préliminaire) sont des Kits de développement logiciel qui permettent de recueillir des mesures à partir de différentes ressources et d’effectuer une mise à l’échelle automatique avec les API REST. Pour les ressources où la prise en charge d’Azure Resource Manager n’est pas disponible, ou si vous utilisez Azure Cloud Services, vous pouvez utiliser l’API REST Azure Service Management pour la mise à l’échelle automatique. Dans tous les autres cas, utilisez Azure Resource Manager.

Lorsque vous utilisez la mise à l’échelle automatique Azure, tenez compte des points suivants :

  • Évaluez si vous pouvez anticiper la charge sur l’application de manière suffisamment précise pour utiliser la mise à l’échelle automatique planifiée en ajoutant et retirant des instances afin de répondre aux pics de demande anticipés. Si ce n’est pas possible, utilisez la mise à l’échelle automatique réactive basée sur les métriques collectées au moment de l’exécution afin de gérer les changements de demande imprévus. En règle générale, vous pouvez combiner ces approches. Par exemple, élaborez une stratégie qui ajoute des ressources en fonction d’un calendrier répertoriant les périodes de pic d’activité de l’application. Cela permet de garantir la disponibilité de la capacité au moment voulu, sans le délai associé au démarrage des nouvelles instances. Pour chaque règle planifiée, définissez des métriques qui prennent en charge la mise à l’échelle automatique réactive durant cette période afin de garantir que l’application peut gérer les pics de demande soutenus mais imprévus.

  • Il est souvent difficile d’appréhender la relation entre les mesures et les exigences de capacité, en particulier lors du déploiement initial d’une application. Approvisionnez dès le début une capacité légèrement supplémentaire, puis surveillez et adaptez les règles de mise à l’échelle automatique afin de faire correspondre la capacité avec 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 définir le mode de mise à l’échelle du système, si nécessaire. Toutefois, gardez à l’esprit que la mise à l’échelle n’est pas un processus instantané. La réaction à une mesure telle que le dépassement du seuil d’utilisation moyenne du processeur prend du temps.

  • Les règles de mise à l’échelle automatique qui utilisent un mécanisme de détection basé sur un attribut de déclenchement mesuré (par exemple utilisation du processeur ou longueur de file d’attente) utilisent une valeur agrégée au fil du temps, et non des valeurs instantanées, pour déclencher une action de mise à l’échelle automatique. Par défaut, cette valeur agrégée correspond à une moyenne de valeurs. Cette configuration empêche toute réaction prématurée du système, et prévient toute oscillation rapide. Elle laisse également le temps aux nouvelles instances démarrées automatiquement d’adopter le mode d’exécution, empêchant l’application des actions supplémentaires de mise à l’échelle automatique durant le démarrage des nouvelles instances. Pour Azure Cloud Services et Azure Virtual Machines, la période par défaut associée à l’agrégation est de 45 minutes. Dès lors, il vous faudra éventuellement attendre ce délai pour constater le déclenchement, par la mesure, de 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 SDK, mais les périodes de moins de 25 minutes peuvent donner des résultats imprévisibles. Pour Web Apps, la période moyenne est beaucoup plus courte. Les nouvelles instances sont disponibles environ cinq minutes après une modification de la mesure de déclenchement.

  • Évitez les situations de bagottement qui alternent continuellement les actions de scale-in et de scale-out. Supposons qu’il existe deux instances et que la limite supérieure soit de 80 % UC et la limite inférieure de 60 %. Lorsque la charge est à 85 %, une autre instance est ajoutée. Après un certain temps, la charge descend à 60 %. Avant d’effectuer le scale-in, le service de mise à l’échelle automatique calcule la distribution de la charge totale (de trois instances) lorsqu’une instance est supprimée, en la faisant passer à 90 %. Il lui faut donc effectuer immédiatement un scale-out. Dès lors, il ignore le scale-in et vous risquez de ne jamais voir les résultats de mise à l’échelle attendus.

    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 selon le nombre maximal et minimal d’instances utilisé pour la mise à l’échelle automatique. Si vous mettez à jour manuellement le nombre d’instances avec une valeur inférieure ou supérieure à la valeur maximale, le moteur de mise à l’échelle s’ajuste 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 3 et 6. Si vous avez une seule instance en cours d’exécution, le moteur de mise à l’échelle automatique effectue la mise à l’échelle sur trois instances lors de sa prochaine exécution. De même, si vous définissez manuellement la mise à l’échelle sur huit instances, la mise à l’échelle sera redéfinie sur six instances lors de la prochaine exécution. La mise à l’échelle manuelle est temporaire, sauf si vous réinitialisez aussi les règles de mise à l’échelle.

  • Le moteur de mise à l’échelle automatique ne traite qu’un seul profil à la fois. Si une condition n’est pas remplie, le profil suivant est vérifié. Conservez les mesures clés en dehors du profil par défaut, car ce profil est vérifié en dernier. Un profil peut contenir plusieurs règles. Pour le scale-out, la mise à l’échelle automatique s’exécute si une règle est respectée. Pour le scale-in, la mise à l’échelle automatique nécessite que toutes les règles soient respectées.

Pour plus d’informations sur la mise à l’échelle d’Azure Monitor, consultez 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 par l’intermédiaire du portail, vous pouvez spécifier une planification plus détaillée de la période d’activité des règles. Vous pouvez également créer vos propres mesures et les utiliser avec ou sans les éléments existants dans vos règles de mise à l’échelle automatique. Par exemple, vous pouvez opter pour l’utilisation de compteurs alternatifs, comme le nombre de requêtes par seconde ou la disponibilité moyenne de la mémoire, ou de compteurs personnalisés pour mesurer des processus d’entreprise spécifiques.

  • Lors de la mise à l’échelle automatique de Service Fabric, les types de nœuds de votre cluster sont constitués de groupes de machines virtuelles identiques sur le serveur principal ; vous devez donc configurer des règles de mise à l’échelle automatique pour chaque type de nœud. Tenez compte du nombre de nœuds dont vous devez disposer avant de configurer la mise à l’échelle automatique. Le nombre de nœuds minimal dont vous devez disposer pour le type de nœud principal est déterminé par le niveau de fiabilité que vous avez choisi. Pour plus d'informations, consultez Effectuer un scale-in ou un scale-out d'un cluster Service Fabric à l'aide de règles de mise à l'échelle automatique.

  • Vous pouvez utiliser le portail pour lier des ressources telles que des files d’attente et des instances SQL Database à une instance de service cloud. Cela vous permet d’accéder plus facilement aux options de configuration de mise à l’échelle automatiques et manuelles de chacune des ressources liées. Pour plus d’informations, consultez Procédure : lier une ressource à un service cloud.

  • Quand 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’un nombre suffisant d’instances est toujours en cours d’exécution :

    • Les opérations de scale-out priment toujours sur les opérations de scale-in.
    • Lorsque 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 des opérations de scale-in sont en conflit, la règle à l’origine de la diminution la plus faible du nombre d’instances prime.

  • Dans un environnement App Service, vous pouvez utiliser toutes les métriques de pool de Workers ou de serveur frontal pour définir des règles de mise à l’échelle automatique. Pour plus d’informations, consultez l’article Mise à l’échelle automatique et environnement App Service.

Considérations relatives à la conception d’applications

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 formuler des hypothèses relatives à l’affinité des instances ; ne concevez pas de solutions qui nécessitent l’exécution permanente du code dans une instance spécifique de processus. Lors de la mise à l’échelle horizontale d’un service cloud ou d’un site web, ne partez pas du principe que l’ensemble des requêtes d’une même source seront dirigées 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 des instances supplémentaires d’un service à mesure que la taille 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 la prudence requise, une tâche de ce type pourrait empêcher la fermeture appropriée d’une instance de processus lors d’une mise à l’échelle horizontale du système, ou l’instance pourrait perdre des données en cas d’arrêt forcé du processus. Dans l’idéal, refactorisez une tâche longue et divisez le traitement exécuté en bloc plus petits, discrets. L’article Modèle de canaux et de filtres fournit un exemple de la procédure à suivre.

  • Sinon, vous pouvez implémenter un mécanisme de point de contrôle qui enregistre les informations d’état de la tâche à des intervalles réguliers et enregistre cet état dans un espace de stockage durable accessible par l’ensemble des instances du processus exécutant la tâche. Ainsi, si le processus est arrêté, la tâche qu’il exécutait peut être poursuivie à partir du dernier point de contrôle à l’aide d’une instance différente. 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.

  • Quand les tâches d’arrière-plan s’exécutent sur des instances de calcul séparées, telles que les rôles de travail d’une application hébergée par des services cloud, vous devrez peut-être appliquer des stratégies distinctes de mise à l’échelle à différentes parties de l’application. Par exemple, vous devrez peut-être déployer des instances de calcul supplémentaires d’interface utilisateur sans augmenter le nombre d’instances de calcul d’arrière-plan, ou inversement. Si vous proposez différents niveaux de services (comme des packages de services de base ou de niveau Premium), il vous faudra éventuellement faire monter en puissance les ressources de calcul associées aux packages de services Premium de manière plus importante que celles dédiées aux packages de services de base afin de répondre aux exigences des contrats de niveau de service.

  • 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. Cette valeur est un indicateur possible de déséquilibre ou d’écart entre la charge actuelle et la capacité de traitement de la tâche en arrière-plan. Il existe un meilleur attribut un peu plus complexe sur lequel baser les décisions de mise à l’échelle. Utilisez le délai entre le moment où un message est envoyé et le moment où son traitement se termine, appelé délai critique. Si cette valeur de délai critique est inférieure à un seuil métier significatif, il est inutile d’effectuer une mise à l’échelle, 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 délai critique du message le plus ancien est de 500 ms, et ce point de terminaison gère l’intégration avec un service web tiers pour l’envoi d’e-mails. Il est probable que les parties prenantes de l’entreprise considèrent qu’il s’agit d’un délai qui ne justifie pas les dépenses supplémentaires liées à la mise à l’échelle.
    • En revanche, il peut y avoir 500 messages dans une file d’attente, avec le même délai 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 délai critique dans les décisions de mise à l’échelle automatique, il est utile d’ajouter automatiquement les informations pertinentes aux en-têtes des messages, pendant qu’ils sont envoyés et traités. NServiceBus est une bibliothèque de ce type qui fournit cette fonctionnalité.

  • Si vous basez votre stratégie de mise à l’échelle automatique sur des compteurs de processus d’entreprise, tels que le nombre de commandes transmises par heure ou la durée d’exécution moyenne d’une transaction complexe, veillez à comprendre parfaitement la relation entre les résultats issus de ces types de compteurs et les exigences réelles en matière de capacité de calcul. Il peut être nécessaire de mettre à l’échelle plusieurs composants ou unités de calcul afin de vous adapter aux modifications transmises par les compteurs d’entreprise.

  • Pour empêcher un système de procéder à une montée en puissance excessive et éviter les coûts associés à l’exécution de plusieurs milliers d’instances, envisagez de limiter le nombre d’instances pouvant être automatiquement ajoutées. La plupart des mécanismes de mise à l’échelle automatique prennent en charge la définition des nombres minimal et maximal d’instances associées à une règle. De plus, vous pouvez dégrader de manière appropriée la fonctionnalité fournie par le système si le nombre maximal d’instances a été déployé et que le système est toujours surchargé.

  • N’oubliez pas que la mise à l’échelle automatique n’est pas forcément le mécanisme le mieux adapté à la gestion d’un pic imprévu de charge de travail. L’approvisionnement et le démarrage des nouvelles instances d’un service et l’ajout des ressources à un système étant des opérations qui demandent du temps, il se peut que le pic de demandes soit passé quand les nouveaux éléments 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 que la capacité disponible traite l’ensemble des requêtes lors des fluctuations brutales du volume et que la contrainte financière n’est pas un obstacle majeur, vous pouvez appliquer une stratégie poussée de mise à l’échelle automatique qui démarre plus rapidement les instances supplémentaires. 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 et consigner les détails de chacun des événements de mise à l’échelle automatique (éléments déclencheurs, ressources ajoutées ou retirées, et à quel moment). 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 alerter un opérateur susceptible de démarrer manuellement des ressources supplémentaires si nécessaire. Si cette situation se présente, l’opérateur est également chargé de retirer ces ressources une fois que la charge est revenue à la normale.

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

  • Modèle de limitation. Ce modèle décrit comment une application peut continuer à fonctionner et à satisfaire aux contrats de niveau de service quand une augmentation de la demande place une charge conséquente sur les ressources. Vous pouvez associer un modèle de limitation à la mise à l’échelle automatique afin d’éviter de surcharger un système soumis à une opération d’évolutivité horizontale.

  • Modèle des consommateurs concurrents. Ce modèle explique comment implémenter un pool d’instances de services pouvant traiter les messages d’une instance d’application. La mise à l’échelle automatique sert éventuellement à démarrer et arrêter les instances de services afin de satisfaire les charges de travail anticipées. Grâce à cette approche, un système peut traiter simultanément plusieurs messages afin d’optimiser le débit, améliorer l’évolutivité et la disponibilité, et équilibrer la charge de travail.

  • Surveillance et diagnostics. L’instrumentation et la télémétrie sont essentielles pour collecter les informations pouvant être utilisées dans le cadre du processus de mise à l’échelle automatique.