Meilleures pratiques pour la mise à l’échelle automatique

Article
10/15/2024

La mise à l’échelle automatique Azure Monitor s’applique uniquement à Azure Virtual Machine Scale Sets, à Azure Cloud Services, à la fonctionnalité Web Apps d’Azure App Service et à Azure API Management.

Concepts de la mise à l’échelle automatique

Une ressource ne peut avoir qu’un paramètre de mise à l’échelle automatique.
Un paramètre de mise à l’échelle automatique peut comporter un ou plusieurs profils, et chaque profil peut avoir une ou plusieurs règles de mise à l’échelle automatique.
Un paramètre de mise à l’échelle automatique met à l’échelle les instances horizontalement, c’est-à-dire vers l’extérieur en augmentant la taille des instances et vers l’intérieur en diminuant la taille des instances.
Un paramètre de mise à l’échelle automatique a une valeur d’instances maximum, minimum et par défaut.
Une tâche de mise à l’échelle automatique lit la mesure associée à mettre à l’échelle, en vérification qu’elle a dépassé le seuil configuré pour l’augmentation ou la diminution de taille d’instance. Vous pouvez afficher une liste des mesures pour la mise à l’échelle automatique dans la rubrique Mesures courantes de mise à l’échelle automatique Azure Monitor.
Tous les seuils sont calculés au niveau de l’instance. Par exemple, « effectuer un scale-out d’une instance lorsque l’UC moyenne > 80 % quand le nombre d’instances est égal à 2 ». Cela signifie effectuer un scale-out lorsque l’UC moyenne sur toutes les instances est supérieure à 80 %.
Tous les échecs de mise à l’échelle automatique sont enregistrés dans le journal d’activité. Vous pouvez ensuite configurer une alerte de journal d’activité pour être informé par e-mail, SMS ou webhooks de chaque échec de mise à l’échelle automatique.
De même, toutes les opérations de mise à l’échelle réussies sont consignées dans le journal d’activité. Vous pouvez aussi configurer une alerte de journal d’activité pour être informé par e-mail, SMS ou webhooks de chaque action de mise à l’échelle automatique réussie. Vous pouvez également configurer des notifications par e-mail ou webhook pour être averti en cas d’action de mise à l’échelle réussie via l’onglet Notifications du paramètre 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 à jour manuellement le nombre d’instances avec une valeur inférieure au minimum ou supérieure au maximum, le moteur de mise à l’échelle s’ajuste automatiquement à la valeur minimale (si elle est inférieure) ou à la valeur maximale (le cas ci-dessus). 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.

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 uniquement une partie de la combinaison, la mise à l’échelle automatique n’effectue l’action que dans une direction (scale-out ou scale-in) jusqu’à ce qu’elle atteigne le nombre d’instances minimum ou maximum 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, nous ne vous recommandons pas la combinaison de règles suivante, car il n’existe aucune règle de scale-in 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, vous pouvez avoir une situation dans laquelle l’utilisation de la mémoire est supérieure à 90 %, mais l’utilisation du processeur est inférieure à 45 %. Ce scénario peut entraîner un bagotement pour autant que les deux conditions soient remplies.

Sélection de la statistique appropriée pour votre mesure de diagnostic

Pour les mesures de diagnostics, vous pouvez choisir entre Moyen, Minimum, Maximum et Total comme mesure de mise à l’échelle. La statistique la plus courante est Moyen.

Considérations relatives aux valeurs de seuil de la mise à l’échelle pour les mesures spéciales

Pour les mesures spéciales, telles que les mesures de longueur de file d’attente Azure Service Bus ou Stockage Azure, le seuil correspond au nombre moyen de messages disponibles en fonction du nombre actuel d’instances. Choisissez soigneusement la valeur de seuil pour ce métrique.

Examinons un exemple qui vous permettra de mieux comprendre ce comportement :

Augmenter les instances de 1 lorsque le nombre de messages de file d’attente de stockage >= 50
Diminuer les instances de 1 lorsque le nombre de messages de file d’attente de stockage <= 10

Examinez la séquence suivante :

Il existe deux instances de file d’attente de stockage.
Les messages continuent d’arriver et lorsque vous examinez la file d’attente de stockage, le nombre total est de 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 de stockage doit être égal à 100.
Ensuite, supposons que le nombre total de messages atteigne 100.
Une troisième instance de file d'attente de stockage est ajoutée en raison d’une action de scale-out. La prochaine action de montée en charge ne se produira que lorsque le nombre total de messages dans la file d’attente atteindra 150, car 150/3 = 50.
Maintenant, le nombre de messages dans la file d’attente diminue. Avec trois instances, la première action de diminution de la taille des instances se produit lorsque le nombre total de messages dans toutes les files d’attente atteint 30, car 30/3 donne 10 messages par instance, ce qui correspond au seuil de diminution de la taille des instances.

Considérations relatives à la mise à l’échelle lorsque plusieurs règles sont configurées dans un profil

Il existe des cas où vous devrez définir plusieurs règles dans un profil. Les règles de mise à l’échelle automatique suivantes sont utilisées par le moteur de mise à l’échelle automatique quand plusieurs règles sont définies :

Pour l’augmentation de la taille des instances, 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 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 le processeur > 75 %, faire un scale-out de 1
Si la mémoire > 75 %, faire un scale-out de 1

Ensuite, l’action suivante se produit :

Si le processeur est de 76 % et la mémoire est de 50 %, une augmentation de la taille des instances se produit.
Si le processeur est de 50 % et la mémoire est de 76 %, une augmentation de la taille des instances se produit.

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

Sélectionnez toujours un nombre d’instances par défaut sans échec

Le nombre d’instances par défaut est important, car la mise à l’échelle automatique utilise ce nombre pour mettre à l’échelle vos services quand les métriques ne sont pas disponibles. Par conséquent, sélectionnez un nombre d’instances par défaut qui est sécurisé pour vos charges de travail.

Configuration des notifications de mise à l’échelle automatique

Les événements de mise à l’échelle automatique sont enregistrés dans le journal d’activité dans les cas suivants :

La mise à l’échelle automatique déclenche une opération de mise à l’échelle.
Le service de mise à l’échelle automatique termine une opération de mise à l’échelle avec succès.
Le service de mise à l’échelle automatique ne parvient pas à terminer une opération de mise à l’échelle avec succès
Les métriques ne sont pas disponibles pour permettre au service de mise à l’échelle automatique de 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.
La mise à l’échelle automatique détecte un bagottement et abandonne la tentative de mise à l’échelle. Vous voyez un type de journal Flapping dans cette situation. Si vous voyez ce type de journal, déterminez si vos seuils sont trop rapprochés.
La mise à l’échelle automatique détecte un bagottement mais reste en mesure d’effectuer correctement la mise à l’échelle. Vous voyez un type de journal FlappingOccurred dans cette situation. Si vous voyez ce type de journal, le moteur de mise à l’échelle automatique a tenté une mise à l’échelle (par exemple, de 4 instances à 2), mais a déterminé que ce changement entraînerait un bagotement. À la place, le moteur de mise à l’échelle automatique a essayé une mise à l’échelle avec un nombre d’instances différent (par exemple, pour utiliser trois instances au lieu de deux). Comme cette action n’a pas provoqué de bagotement, il a effectué la mise à l’échelle avec ce nombre d’instances.

Vous pouvez également utiliser une alerte de journal d’activité pour surveiller l’intégrité du moteur de mise à l’échelle automatique. 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 de l’activation des alertes de journal d’activité, vous pouvez configurer des notifications par e-mail ou webhook pour être averti en cas d’action de mise à l’échelle via l’onglet Notifications du paramètre de mise à l’échelle automatique.

Envoyer des données en toute sécurité à l’aide du protocole TLS 1.2

Pour garantir la sécurité des données en transit vers Azure Monitor, nous vous encourageons vivement à configurer l’agent de façon à utiliser au moins le protocole TLS (Transport Layer Security) 1.2. Les versions antérieures de TLS/SSL (Secure Sockets Layer) se sont avérées vulnérables. Bien qu’elles fonctionnent toujours pour permettre la compatibilité descendante, nous ne les recommandons pas. L’industrie évolue et abandonne rapidement la prise en charge de ces protocoles plus anciens.

Le PCI Security Standards Council a défini l’échéance au 30 juin 2018 pour désactiver les versions antérieures de TLS/SSL et effectuer une mise à niveau vers des protocoles plus sécurisés. Une fois qu’Azure aura arrêté la prise en charge des versions héritées, si vos agents ne peuvent pas communiquer via au moins le protocole TLS 1.2, vous ne serez plus en mesure d’envoyer des données aux journaux Azure Monitor.

Nous vous recommandons de ne pas définir explicitement votre agent pour qu’il utilise uniquement TLS 1.2, sauf si cela est nécessaire. Il est préférable d’autoriser l’agent à détecter, négocier et tirer parti des normes de sécurité futures. Dans le cas contraire, vous risquez de manquer la sécurité accrue des normes plus récentes et peut-être de rencontrer des problèmes si TLS 1.2 est déprécié en faveur de ces dernières normes.

Partager via