Mise à l’échelle automatique dans Azure App Service
Remarque
La mise à l’échelle automatique est disponible pour tous les types d’applications : Windows et Linux (déployer en tant que code et conteneur). La mise à l’échelle automatique n’est pas prise en charge pour le trafic d’emplacement de déploiement.
La mise à l’échelle automatique est une nouvelle option de montée en charge qui gère automatiquement les décisions de mise à l’échelle pour vos applications web et vos plans App Service. Elle est différente de la mise à l’échelle automatique Azure préexistante qui vous permet de définir des règles de mise à l’échelle en fonction des planifications et des ressources. Grâce à la mise à l’échelle automatique, vous pouvez ajuster les paramètres de mise à l’échelle pour améliorer le niveau de performance de votre application et éviter les problèmes de démarrage à froid. La plateforme préchauffe des instances pour agir en tant que tampon lors d’une montée en puissance et assurer ainsi des transitions de performances fluides. Vous êtes facturé par seconde pour chaque instance, y compris les instances préchauffées.
Une comparaison des options de scale-out et de scale-in est disponible sur App Service :
| Manuel | Autoscale | Mise à l’échelle automatique | |
|---|---|---|---|
| Niveaux tarifaires disponibles | Basic et Up | Standard et Up | Niveaux tarifaires Premium V2 (P1V2, P2V2, P3V2) et Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3, P5MV3) |
| Mise à l’échelle basée sur des règles | Non | Oui | Non, la plateforme gère le scale-out et le scale-in en fonction du trafic HTTP. |
| Mise à l’échelle basée sur la planification | Non | Oui | Non |
| Instances toujours prêtes | Non, votre application web s’exécute sur le nombre d’instances mises à l’échelle manuellement. | Non, votre application web s’exécute sur d’autres instances disponibles pendant l’opération de scale-out, en fonction du seuil défini pour les règles de mise à l’échelle automatique. | Oui (minimum 1) |
| Instances préchauffées | Non | Non | Oui (par défaut 1) |
| Maximum par application | Non | Non | Oui |
Comment fonctionne la mise à l’échelle automatique
Vous activez la mise à l’échelle automatique pour un plan App Service et configurez une plage d’instances pour chacune des applications web. Lorsque votre application web commence à recevoir du trafic HTTP, App Service surveille la charge et ajoute des instances. Les ressources peuvent être partagées lorsque plusieurs applications web au sein d’un plan App Service sont nécessaires pour effectuer un scale-out simultané.
Voici quelques scénarios dans lesquels vous devez effectuer une montée en charge automatiquement :
- Vous ne souhaitez pas configurer des règles de mise à l’échelle auto basées sur les métriques de ressources.
- Vous souhaitez que vos applications web du même plan App Service soient mises à l’échelle différemment et indépendamment les unes des autres.
- Votre application web est connectée à une base de données ou à un système hérité, qui peut ne pas être mis à l’échelle aussi rapidement. La mise à l’échelle automatique vous permet de définir le nombre maximal d’instances que votre plan App Service peut mettre à l’échelle. Ce paramètre permet à l’application web de ne pas surcharger le back-end.
Activer la mise à l’échelle automatique
La rafale maximale est le nombre le plus élevé d’instances que votre plan App Service peut atteindre en fonction des requêtes HTTP entrantes. Pour les plans Premium v2 et v3, vous pouvez définir une rafale maximale de 30 instances. La rafale maximale doit être égale ou supérieure au nombre de collaborateurs spécifié pour le plan App Service.
Pour activer la mise à l’échelle automatique, accédez au menu gauche de l’application web et sélectionnez Scale-out (plan App Service). Sélectionnez Automatique, mettez à jour la valeur de Rafale maximale, puis sélectionnez le bouton Enregistrer.
Définir le nombre minimal d’instances d’applications web
Instances toujours prêtes est un paramètre au niveau de l’application permettant de spécifier le nombre minimal d’instances. Si la charge dépasse ce que les instances toujours prêtes peuvent gérer, des instances supplémentaires sont ajoutées (sans excéder la rafale maximale spécifiée pour le plan App Service).
Pour définir le nombre minimal d’instances d’application web, accédez au menu gauche de l’application web et sélectionnez Scale-out (plan App Service). Mettez à jour la valeur des Instances toujours prêtes, puis sélectionnez le bouton Enregistrer.
Définir le nombre maximal d’instances d’applications web
La limite de mise à l’échelle maximale définit le nombre maximal d’instances qu’une application web peut mettre à l’échelle. La limite de mise à l’échelle maximale est utile lorsqu’un composant en aval, comme une base de données, a un débit limité. La valeur maximale par application peut être comprise entre 1 et la rafale maximale.
Pour définir le nombre maximal d’instances d’application web, accédez au menu gauche de l’application web, puis sélectionnez Scale-out (plan App Service). Sélectionnez Appliquer la limite de scale-out, mettez à jour la Limite de mise à l’échelle maximale, puis sélectionnez le bouton Enregistrer.
Mettre à jour les instances préchauffées
Le paramètre d’instances préchauffées fournit des instances chauffées en tant que mémoire tampon pendant les événements d’activation et de mise à l’échelle HTTP. Les instances préchauffées continuent d’être mises en mémoire tampon tant que la limite maximale de scale-out n’est pas atteinte. Le nombre d’instances préchauffées par défaut est de 1, et dans la plupart des scénarios, cette valeur reste à 1.
Vous ne pouvez pas modifier le paramètre d’instances préchauffées dans le portail. Vous devez plutôt utiliser Azure CLI.
Désactiver la mise à l’échelle automatique
Pour désactiver la mise à l’échelle automatique, accédez au menu gauche de l’application web et sélectionnez Scale-out (plan App Service). Sélectionnez Manuel, puis sélectionnez le bouton Enregistrer.
La mise à l’échelle automatique prend-elle en charge les applications de fonction Azure ?
Attention
La mise à l’échelle automatique est désactivée lorsque les applications web App Service et les applications Azure Functions se trouvent dans le même plan App Service.
Non, vous pouvez uniquement avoir des applications web Azure App Service dans le plan App Service où vous souhaitez activer la mise à l’échelle automatique. Pour Functions, il est plutôt recommandé d’utiliser le plan Azure Functions Premium.
Comment fonctionne la mise à l’échelle automatique en arrière-plan ?
Les applications définies pour la mise à l’échelle automatique sont surveillées en continu, avec des évaluations d’intégrité des Workers avec des intervalles de quelques secondes au plus. Si le système détecte une charge accrue sur l’application, les vérifications d’intégrité deviennent plus fréquentes. En cas de détérioration de la santé des Workers et de ralentissement des requêtes, des instances supplémentaires sont demandées. La vitesse à laquelle les instances sont ajoutées varie en fonction du modèle de charge et du temps de démarrage de l’application individuelle. Les applications avec de brefs temps de démarrage et des rafales intermittentes de charge peuvent voir une machine virtuelle ajoutée à des intervalles de quelques secondes à une minute.
Une fois la charge réduite, la plateforme lance un examen du scale-in potentiel. Ce processus commence généralement entre 5 et 10 minutes après l’arrêt de l’augmentation de charge. Pendant le scale-in, les instances sont supprimées à des intervalles d’au moins quelques secondes à une minute.
De plus, si plusieurs applications web sont déployées dans le même plan App Service, la plateforme s’efforce d’allouer des ressources entre les instances disponibles en fonction de la charge de chaque application web individuelle.
Comment suis-je facturé pour les instances préchauffées ?
Pour comprendre comment vous êtes facturé pour les instances préchauffées, prenons cet exemple de scénario : supposons que votre application web dispose de cinq instances qui sont toujours prêtes, ainsi que d’une instance préchauffée définie comme instance par défaut.
Lorsque votre application web est inactive et ne reçoit aucune requête HTTP, elle s’exécute avec les cinq instances toujours prêtes. À ce stade, vous n’êtes pas facturé pour une instance préchauffée, car les instances toujours prêtes ne sont pas utilisées et aucune instance préchauffée n’est allouée.
Toutefois, dès que votre application web commence à recevoir des requêtes HTTP et que les cinq instances toujours prêtes deviennent actives, une instance préchauffée est allouée et sa facturation commence.
Si le taux de requêtes HTTP continue d’augmenter et qu’App Service décide d’effectuer une mise à l’échelle au-delà des cinq instances initiales, il commencera à utiliser l’instance préchauffée. Cela signifie que, lorsqu’il existe six instances actives, une septième instance est immédiatement approvisionnée pour remplir la mémoire tampon préchauffée.
Cette séquence de mise à l’échelle et de préchauffage se poursuit tant que le nombre maximal d’instances pour l’application n’est pas atteint. Il est important de noter qu’aucune instance n’est préchauffée ou activée au-delà du nombre maximal d’instances.
Pourquoi AppServiceHTTPLogs a des entrées de journal similaires à « /admin/host/ping » avec un état 404 ?
La mise à l’échelle automatique d’App Service vérifie régulièrement le point de terminaison /admin/host/ping ainsi que d’autres mécanismes de contrôle d’intégrité inhérents à la plateforme. Ces vérifications sont des fonctionnalités spécifiquement implémentées. Parfois, en raison de configurations de plateforme existantes, des erreurs 404 peuvent être retournées par ces pings. Toutefois, il est important de noter que ces erreurs 404 ne doivent pas affecter la disponibilité ou les performances de mise à l’échelle de votre application.
Si votre application web retourne un état 5xx, les pings de ces points de terminaison peuvent causer des redémarrages intermittents, bien que cette situation demeure peu courante. Nous implémentons actuellement des améliorations pour résoudre ces redémarrages intermittents. Jusqu’à ce stade, assurez-vous que votre application web ne retourne pas d’état 5xx sur ce point de terminaison. N’oubliez pas que ces points de terminaison de ping ne peuvent pas être personnalisés.
Comment suivre le nombre d’instances soumises à un scale-out pendant l’événement de mise à l’échelle automatique ?
La métrique AutomaticScalingInstanceCount signalera le nombre de machines virtuelles sur lesquelles l’application s’exécute, y compris l’instance préchauffée si elle est déployée. Cette métrique peut également être utilisée pour suivre le nombre maximal d’instances que votre application web a soumises à un scale-out pendant un événement de mise à l’échelle automatique. Cette métrique est disponible uniquement pour les applications dont la mise à l’échelle automatique est activée.
Comment l’affinité ARR affecte-t-elle la mise à l’échelle automatique ?
Azure App Service utilise des cookies ARR (Application Request Routing) appelés cookies d’affinité ARR. Les cookies d’affinité ARR limitent la mise à l’échelle, car ils envoient des requêtes uniquement aux serveurs associés au cookie, au lieu d’une instance disponible. Pour les applications qui stockent l’état, il est préférable d’effectuer un scale-up (augmenter les ressources sur une seule instance). Pour les applications sans état, le scale-out (ajout d’instances supplémentaires) offre plus de flexibilité et d’extensibilité. Les cookies d’affinité ARR sont activés par défaut sur App Service. En fonction des besoins de votre application, vous pouvez choisir de désactiver les cookies d’affinité ARR lors de l’utilisation de la mise à l’échelle automatique.
Pour désactiver les cookies d’affinité ARR : sélectionnez votre application App Service puis, sous Paramètres, sélectionnez Configuration. Sélectionnez ensuite l’onglet Paramètres généraux. Sous Affinité ARR, sélectionnez Désactivé, puis sélectionnez le bouton Enregistrer.
Plus de ressources
Commentaires
Bientôt disponible : pendant toute l’année 2024, nous allons éliminer progressivement Problèmes GitHub comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, voir : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour