0Pricing
Azure Fundamentals · Leçon

Mise à l’échelle automatique et domaines personnalisés

Configurez des règles d’augmentation de capacité fondées sur les métriques du CPU et des files d’attente HTTP, associez un domaine personnalisé à votre application web et liez un certificat géré App Service gratuit.

Mise à l’échelle automatique et domaines personnalisés est une leçon Azure Fundamentals gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Azure Fundamentals, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Azure Fundamentals comprend 4 leçons au total.

Pourquoi la mise à l’échelle automatique est importante

La mise à l’échelle automatique ajuste automatiquement le nombre d’instances App Service exécutant votre application en fonction de la demande en temps réel. Sans mise à l’échelle automatique, vous devez prévoir la charge maximale et payer une capacité inactive pendant les heures creuses. Avec la mise à l’échelle automatique, Azure ajoute des instances lorsque la charge augmente et en supprime lorsqu’elle diminue, optimisant ainsi les performances et les coûts. La mise à l’échelle automatique nécessite le niveau Standard ou supérieur.

Mise à l’échelle horizontale ou verticale

Azure propose deux dimensions de mise à l’échelle. La mise à l’échelle horizontale ajoute plusieurs instances identiques de votre application pour répartir la charge — c’est principalement ce que fait la mise à l’échelle automatique. La mise à l’échelle verticale passe à une machine virtuelle plus grande, avec davantage de CPU et de RAM, en modifiant le SKU du plan App Service. La mise à l’échelle horizontale est préférable pour la résilience, car plusieurs instances peuvent survivre à des défaillances individuelles ; la mise à l’échelle verticale est limitée par le matériel.

# Scale out to 5 instances manually
az appservice plan update \
  --name MyAppServicePlan \
  --resource-group MyRG \
  --number-of-workers 5

# Scale up: change the SKU tier
az appservice plan update \
  --name MyAppServicePlan \
  --resource-group MyRG \
  --sku P2V3

Règles et profils de mise à l’échelle automatique

La mise à l’échelle automatique dans Azure se configure au moyen de paramètres de mise à l’échelle automatique associés à un plan App Service. Un paramètre de mise à l’échelle automatique contient un ou plusieurs profils (régulier, à date fixe ou récurrent), chacun contenant des règles. Une règle d’augmentation d’échelle se déclenche lorsqu’une métrique dépasse un seuil (par exemple, CPU > 70 %) ; une règle de réduction d’échelle se déclenche lorsqu’elle passe sous un seuil inférieur (par exemple, CPU < 30 %). Définissez toujours des règles d’augmentation et de réduction d’échelle afin d’éviter une croissance incontrôlée ou des coûts excessifs.

# Create an autoscale setting with CPU-based rules
az monitor autoscale create \
  --name MyAutoscale \
  --resource-group MyRG \
  --resource MyAppServicePlan \
  --resource-type Microsoft.Web/serverfarms \
  --min-count 2 \
  --max-count 10 \
  --count 2

# Add scale-out rule: CPU > 70% for 5 minutes
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale out 2 \
  --condition 'CpuPercentage > 70 avg 5m'

Mise à l’échelle automatique planifiée

La mise à l’échelle automatique planifiée (profils récurrents) vous permet d’augmenter préventivement la capacité pour des schémas de trafic prévisibles. Par exemple, vous pouvez passer à 10 instances chaque jour ouvré à 08:00, puis revenir à 2 à 18:00. La combinaison de profils fondés sur un calendrier et de profils fondés sur les métriques offre le meilleur des deux approches : une capacité préparée pour les pics connus et une réaction élastique aux hausses inattendues.

# Add a recurrence profile for weekday peak hours
az monitor autoscale profile create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --name 'WeekdayPeak' \
  --min-count 5 \
  --max-count 15 \
  --count 5 \
  --recurrence week mon tue wed thu fri \
  --start 08:00 \
  --end 18:00 \
  --timezone 'UTC'

Périodes de refroidissement

Une période de refroidissement est un délai après une action de mise à l’échelle pendant lequel aucune autre mise à l’échelle n’a lieu. Elle empêche les oscillations — des augmentations ou réductions d’échelle répétées et rapides déclenchées par des pics temporaires des métriques. La période de refroidissement par défaut est de 5 minutes pour l’augmentation comme pour la réduction d’échelle. Définissez une période plus longue pour la réduction d’échelle (par exemple, 10 à 15 minutes) afin de laisser aux instances le temps de terminer les connexions actives avant leur suppression.

# Scale-in rule with 10-minute cooldown
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale in 1 \
  --condition 'CpuPercentage < 30 avg 10m' \
  --cooldown 10

Configurer un domaine personnalisé

Les applications App Service reçoivent un nom d’hôte azurewebsites.net par défaut. Pour utiliser votre propre domaine (par exemple, www.contoso.com), ajoutez un domaine personnalisé dans les paramètres d’App Service et créez les enregistrements DNS correspondants auprès de votre bureau d’enregistrement de domaine. Vous devez prouver que vous en êtes propriétaire en créant un CNAME ou un enregistrement TXT (appelé enregistrement de vérification) dans votre zone DNS, puis créer l’enregistrement CNAME ou A de routage proprement dit.

# DNS records at your registrar:
# CNAME  www           MyUniqueWebApp.azurewebsites.net
# TXT    asuid.www     <verification_id from Azure portal>

# After DNS propagation, add the custom domain in Azure
az webapp config hostname add \
  --webapp-name MyUniqueWebApp \
  --resource-group MyRG \
  --hostname www.contoso.com

Certificats TLS pour les domaines personnalisés

Une fois le domaine personnalisé associé, vous avez besoin d’un certificat TLS pour activer HTTPS. App Service propose trois options : certificat géré par App Service (gratuit, renouvelé automatiquement et limité aux domaines standard), certificat App Service (acheté via Azure et stocké dans Key Vault) ou importation d’un certificat tiers (votre propre certificat provenant de Let’s Encrypt ou d’une autorité de certification). Le mode HTTPS uniquement redirige automatiquement tout le trafic HTTP vers HTTPS.

# Create a free App Service Managed Certificate
az webapp config ssl create \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --hostname www.contoso.com

# Bind the certificate to enforce HTTPS
az webapp config ssl bind \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --certificate-thumbprint <THUMBPRINT> \
  --ssl-type SNI

# Enforce HTTPS only
az webapp update \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --https-only true

Métriques de file d’attente HTTP pour la mise à l’échelle automatique

Bien que le CPU soit une métrique courante pour la mise à l’échelle automatique, la longueur de la file d’attente HTTP constitue souvent un meilleur signal pour les applications web. Lorsque la file est longue, de nouvelles requêtes sont en attente, car les instances sont entièrement occupées. La mise à l’échelle fondée sur HttpQueueLength détecte la surcharge plus rapidement que le CPU, qui peut varier sans nécessairement indiquer une latence perceptible par l’utilisateur. Utilisez les deux métriques ensemble pour obtenir un comportement de mise à l’échelle automatique robuste.

# Scale out when HTTP queue length exceeds 100
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale out 2 \
  --condition 'HttpQueueLength > 100 avg 1m' \
  --cooldown 5

# Scale in when queue drops below 10
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale in 1 \
  --condition 'HttpQueueLength < 10 avg 10m' \
  --cooldown 10

Notifications de mise à l’échelle automatique

Configurez des notifications de mise à l’échelle automatique pour recevoir des alertes par e-mail ou webhook lors des événements de mise à l’échelle. Cela aide les équipes à comprendre les schémas de trafic et à vérifier que la mise à l’échelle automatique se comporte comme prévu. Les notifications se configurent dans la section dédiée aux notifications du paramètre de mise à l’échelle automatique et peuvent cibler plusieurs adresses e-mail ainsi que des points de terminaison webhook (pour l’intégration avec Slack, PagerDuty ou des outils personnalisés).

# Add email notification to autoscale setting
az monitor autoscale update \
  --name MyAutoscale \
  --resource-group MyRG \
  --add-condition '{"email": {"sendToSubscriptionAdministrator": true, "customEmails": ["ops@contoso.com"]}, "webhooks": []}'

Domaines apex et Traffic Manager

La mise en correspondance d’un domaine apex (par exemple, contoso.com sans www) avec App Service nécessite un enregistrement A pointant vers l’adresse IP d’App Service, ainsi qu’un enregistrement TXT de vérification. Comme les adresses IP d’App Service peuvent changer, Microsoft recommande d’utiliser Azure Traffic Manager ou Azure Front Door comme intermédiaire : l’équivalent CNAME du domaine apex (enregistrement ALIAS/ANAME) pointe vers le profil Traffic Manager, qui achemine le trafic vers App Service.

# Get the App Service inbound IP (for A record)
az webapp show \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --query 'inboundIpAddress' -o tsv

# DNS at registrar (apex domain with A record approach)
# A      contoso.com     <inboundIpAddress>
# TXT    asuid           <verification_id>

Tester le comportement de la mise à l’échelle automatique

Après avoir configuré la mise à l’échelle automatique, vérifiez son bon fonctionnement en générant une charge artificielle. Utilisez des outils tels que Apache JMeter, k6 ou Azure Load Testing pour simuler des utilisateurs simultanés. Surveillez la métrique du nombre d’instances du plan App Service dans Azure Monitor afin de confirmer que le nombre d’instances augmente lorsque la charge augmente et diminue lorsqu’elle baisse. Documentez le nombre de RPS (requêtes par seconde) observé par instance afin de valider vos seuils de mise à l’échelle.

# Run a quick load test with curl (basic)
for i in {1..100}; do curl -o /dev/null -s https://www.contoso.com/health & done
wait

# Monitor current instance count
az monitor metrics list \
  --resource '/subscriptions/.../providers/Microsoft.Web/serverfarms/MyAppServicePlan' \
  --metric 'InstanceCount' \
  --interval PT1M

Vérification rapide

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que les règles de mise à l’échelle automatique des plans App Service ajoutent ou suppriment des instances en fonction de déclencheurs liés au processeur, à la file d’attente HTTP ou à une planification, que les domaines personnalisés nécessitent des enregistrements DNS CNAME/A ainsi qu’un enregistrement TXT de vérification dans votre zone DNS, et que les certificats TLS (y compris les certificats gérés gratuits) activent HTTPS sur les domaines personnalisés. Nous allons maintenant découvrir l’authentification et la mise en réseau d’App Service.

Questions Fréquemment Posées

La leçon « Mise à l’échelle automatique et domaines personnalisés » est-elle gratuite ?

Oui — le texte complet de « Mise à l’échelle automatique et domaines personnalisés » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Azure Fundamentals, passe à CoddyKit PRO. Le cours Azure Fundamentals comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mise à l’échelle automatique et domaines personnalisés » ?

Configurez des règles d’augmentation de capacité fondées sur les métriques du CPU et des files d’attente HTTP, associez un domaine personnalisé à votre application web et liez un certificat géré App… Tu pratiques Azure Fundamentals avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Azure Fundamentals ?

Aucune expérience préalable n'est requise. Azure Fundamentals sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Mise à l’échelle automatique et domaines personnalisés » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Azure Fundamentals ?

Oui. Chaque leçon Azure Fundamentals inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Création d’un plan App Service et d’une application web
  2. Emplacements de déploiement et permutation
  3. Mise à l’échelle automatique et domaines personnalisés
  4. Authentification et mise en réseau App Service
← Retour à Azure Fundamentals