Meilleures pratiques pour la mise à l’échelle automatique

Azure Monitor mise à l’échelle automatique prend en charge de nombreux types de ressources, notamment Groupes de machines virtuelles identiques Azure, la fonctionnalité de Web Apps de Azure App Service, de Gestion des API Azure et Azure Data Explorer clusters. Pour obtenir la liste actuelle, consultez Services pris en charge pour la mise à l’échelle automatique.

Concepts de la mise à l’échelle automatique

Avant d’appliquer ces meilleures pratiques, passez en revue les blocs de construction de mise à l’échelle automatique de base. Une ressource a un paramètre de mise à l’échelle automatique unique, composé de profils et de règles et définit les nombres d’instances minimum, maximal et par défaut. Les seuils sont calculés au niveau de l’instance, et chaque action de mise à l’échelle est écrite dans le journal d’activité. Pour obtenir le modèle complet, consultez Comprendre les paramètres de mise à l’échelle automatique. Pour connaître les métriques que vous pouvez mettre à l’échelle, consultez Azure Monitor métriques courantes de mise à l’échelle automatique.

Meilleures pratiques relatives à la mise à l’échelle automatique

Utilisez les meilleures pratiques suivantes lorsque vous utilisez la mise à l’échelle automatique.

Vérifiez que les valeurs minimales et maximales sont différentes et séparées par une marge suffisante.

Si le paramètre a une valeur minimum = 2, une valeur maximum = 2 et que le nombre d’instances actuel est égal à 2, aucune action de mise à l’échelle ne peut se produire. Conservez une marge suffisante entre les nombres d’instances minimum et maximum, qui sont inclusifs. La mise à l’échelle agit toujours entre ces limites.

La mise à l’échelle manuelle est réinitialisée par les valeurs minimum et maximum de mise à l’échelle

Si vous mettez manuellement à jour le nombre d’instances vers une valeur en dehors de la plage minimale et maximale, le moteur de mise à l’échelle automatique revient automatiquement à la valeur minimale ou maximale. 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 s'ajuste pour atteindre trois instances lors de sa prochaine exécution. De même, si vous définissez manuellement la mise à l’échelle sur huit instances, le moteur de mise à l’échelle automatique revient à six instances lors de sa prochaine exécution. La mise à l’échelle manuelle est temporaire, sauf si vous réinitialisez aussi les règles de mise à l’échelle.

Utilisez toujours une combinaison de règle d’augmentation et de diminution de la taille des instances qui exécute une augmentation et une diminution

Si vous utilisez une seule partie de la combinaison, la mise à l’échelle automatique prend uniquement des mesures dans une seule direction (scale-out ou in) jusqu’à ce qu’elle atteigne le nombre maximal ou minimal d’instances, comme défini dans le profil. Cette situation n’est pas optimale. Dans l’idéal, vous allez souhaiter que votre ressource puisse effectuer un scale-out lors des périodes de forte utilisation pour assurer la disponibilité. De même, lors des périodes de faible utilisation, vous souhaitez que votre ressource effectuer un scale-in pour vous permettre une réduction des coûts.

Lorsque vous utilisez une règle de scale-in et de scale-out, utilisez idéalement la même métrique pour contrôler les deux. Sinon, il est possible que les conditions de scale-in et de scale-out puissent être remplies en même temps, ce qui entraîne un certain niveau de bagotement. Par exemple, n’utilisez pas la combinaison de règles suivante, car il n’existe aucune règle de mise à l’échelle pour l’utilisation de la mémoire :

  • Si UC > 90 %, effectuer un scale-out de 1
  • Si mémoire > 90 %, effectuer un scale-out de 1
  • Si UC < 45 %, effectuer un scale-in de 1

Dans cet exemple, l’utilisation de la mémoire peut être supérieure à 90% alors que l’utilisation du processeur est inférieure à 45%. Ce scénario peut entraîner des oscillations tant que les deux conditions sont remplies.

Choisissez la statistique et l’agrégation de temps appropriées pour votre métrique de diagnostics

Pour une métrique de diagnostic, qui est une métrique que la ressource émet via Azure Monitor, configurez statistic et timeAggregation pour différentes étapes d’évaluation. La propriété ARM statistic combine les valeurs de métriques de plusieurs instances de ressources dans chaque exemple. La timeAggregation propriété combine ensuite ces exemples sur la fenêtre de temps de la règle.

Propriété ARM Valeurs autorisées Quand utiliser
statistic Average, , MinMax, , SumCount Choisissez comment combiner des valeurs entre des instances pour chaque exemple. Average est le choix le plus courant.
timeAggregation Average, , Minimum, TotalMaximum, , CountLast Choisissez comment combiner des échantillons au fil de la fenêtre de temps avant de comparer le résultat au seuil.

Par exemple, avec une valeur de 1 minute timeGrain, statistic définie Averagesur et timeAggregation définie sur , la mise à Maximuml’échelle automatique commence par mettre à l’échelle automatiquement la métrique entre les instances pour chaque minute. Il compare ensuite la moyenne de 1 minute la plus élevée dans la fenêtre de temps avec le seuil de règle.

Considérations relatives à la mise à l’échelle des valeurs de seuil pour les métriques de longueur de file d’attente

Pour les métriques de longueur d’attente (stockage Azure file d’attente ou Azure Service Bus file d’attente), le seuil correspond au nombre moyen de messages disponibles par nombre actuel d’instances. Choisissez soigneusement la valeur de seuil pour ce métrique.

Pour illustrer le comportement, considérez l’exemple suivant :

  • Augmenter les instances de 1 nombre lorsque stockage Azure nombre >de messages de file d’attente = 50
  • Réduire les instances de 1 nombre lorsque le nombre <de messages de file d’attente = 10

Examinez la séquence suivante :

  1. Il existe deux instances.
  2. Les messages continuent d’arriver et lorsque vous passez en revue la file d’attente, le nombre total lit 50. Vous pourriez supposer que la mise à l’échelle automatique devrait démarrer une action de montée en charge. Toutefois, notez que le nombre de messages par instance est de 50/2 = 25 messages. Ainsi, le scale-out ne se produit pas. Pour que la première action de scale-out se produise, le nombre total de messages dans la file d’attente doit être de 100.
  3. Ensuite, supposons que le nombre total de messages atteigne 100.
  4. Une troisième instance est ajoutée en raison d’une action de scale-out. La prochaine opération d'extension ne se produira que lorsque le nombre total de messages dans la file d’attente atteindra 150, car 150/3 = 50.
  5. Maintenant, le nombre de messages dans la file d’attente diminue. Avec trois instances, la première action de mise à l’échelle se produit lorsque le nombre total de messages additionner jusqu’à 30, car 30/3 = 10 messages par instance, c’est-à-dire le seuil de mise à l’échelle.

Considérations relatives à plusieurs règles configurées dans un profil

Vous devrez peut-être définir plusieurs règles dans un profil. Le moteur de mise à l’échelle automatique applique la logique suivante lorsque plusieurs règles sont définies :

Direction Pathologie
Scale-out La mise à l’échelle automatique s’exécute si une règle est remplie.
Scale-in La mise à l’échelle automatique nécessite que toutes les règles soient remplies.

Pour illustrer cela, supposons que vous disposez de quatre règles de mise à l’échelle automatique :

  • Si UC < 30 %, effectuer un scale-in de 1
  • Si Mémoire < 50 %, effectuer un scale-in de 1
  • Si UC > 75 %, effectuer un scale-out de 1
  • Si Mémoire > 75 % effectuer un scale-out de 1

Ensuite, l’action suivante se produit :

  • Si le CPU est à 76 % et la mémoire à 50 %, l’autoscaling effectue un scale-out.
  • Si le CPU est à 50 % et que la mémoire est à 76 %, l’autoscaling effectue un scale-out.

En revanche, si l’UC est de 25 % et la mémoire est de 51 %, la mise à l’échelle automatique n’effectue pas de scale-in. Pour effectuer un scale-in, l’UC doit être de 29 % et la mémoire de 49 %.

Pour obtenir un autre exemple de travail, consultez l’évaluation de la mise à l’échelle automatique.

Sélectionnez toujours un nombre d'instances par défaut sûr et fiable

Le nombre d’instances par défaut est important en raison de la façon dont la mise à l’échelle automatique l’utilise lorsqu’il existe un problème de lecture de la métrique de ressource. Si la capacité actuelle est inférieure à la valeur par défaut, la mise à l’échelle automatique augmente la capacité jusqu’à la valeur par défaut afin de garantir la disponibilité de la ressource. Si la capacité actuelle est déjà supérieure à la capacité par défaut, la mise à l’échelle automatique ne réduit pas la capacité. Sélectionnez un nombre d’instances par défaut sécurisé pour vos charges de travail. Pour plus d’informations, consultez schéma de paramètre de mise à l’échelle automatique.

Configuration des notifications de mise à l’échelle automatique

La mise à l’échelle automatique écrit dans le journal d’activité dans les cas suivants :

  • La mise à l’échelle automatique émet une opération de mise à l’échelle.
  • Le moteur de mise à l’échelle automatique termine correctement une action de mise à l’échelle.
  • Le moteur de mise à l’échelle automatique ne parvient pas à effectuer une action de mise à l’échelle.
  • Les métriques ne sont pas disponibles pour le moteur de mise à l’échelle automatique pour prendre une décision de mise à l’échelle.
  • Les mesures sont de nouveau disponibles (récupération) pour prendre une décision de mise à l’échelle.
  • Le moteur de mise à l’échelle automatique détecte le flapping et abandonne ou ajuste la tentative d’échelle.

Lorsque le moteur de mise à l’échelle automatique détecte le flapping, il enregistre l’un des types de journaux suivants dans le journal d’activité :

Type de log Sens Action
Flapping Le moteur de mise à l’échelle automatique a détecté le flapping et a abandonné la tentative de mise à l’échelle. Déterminez si vos seuils sont trop étroits.
FlappingOccurred Le moteur de mise à l’échelle automatique a détecté le flapping mais a toujours été mis à l’échelle avec succès. Il a été mis à l’échelle vers un nombre d’instances différent (par exemple, trois instances au lieu de deux) qui ne provoque plus le flapping. Aucune action requise. Passez en revue les seuils si le nombre ajusté n’est pas ce que vous attendez.

Pour surveiller l’intégrité du moteur de mise à l’échelle automatique, utilisez une alerte de journal d’activité. Un exemple indique comment créer une alerte de journal d’activité pour surveiller toutes les opérations du moteur de mise à l’échelle automatique dans votre abonnement. Un autre exemple indique comment créer une alerte de journal d’activité pour surveiller tous les échecs d’opérations de mise à l’échelle automatique dans votre abonnement.

En plus des alertes de journal d’activité, configurez les notifications par e-mail ou webhook pour recevoir une notification pour les actions de mise à l’échelle sous l’onglet Notifications du paramètre de mise à l’échelle automatique.

Étapes suivantes

  • Dernière mise à jour :