Fiabilité dans Azure App Service

2025-06-22

Cet article décrit la prise en charge de la fiabilité dans Azure App Service, couvrant la résilience intrarégion via des zones de disponibilité et des déploiements multirégions.

La fiabilité est une responsabilité partagée entre vous et Microsoft. Vous pouvez utiliser ce guide pour déterminer quelles options de fiabilité répondent à vos objectifs métier et objectifs de temps d’activité spécifiques.

App Service est un service HTTP pour l’hébergement d’applications web, d’API REST et de back-ends mobiles. App Service s’intègre à Microsoft Azure pour assurer la sécurité, l’équilibrage de charge, la mise à l’échelle automatique et la gestion automatisée pour les applications. Pour découvrir comment App Service peut renforcer la fiabilité et la résilience de votre charge de travail d’application, consultez la vue d’ensemble d’App Service.

Lorsque vous déployez App Service, vous pouvez provisionner plusieurs instances dans un plan App Service. Ce plan représente les workers de calcul qui exécutent votre code d’application. La plateforme s’efforce de déployer les instances sur différents domaines d’erreur, mais elle ne distribue pas automatiquement les instances entre les zones de disponibilité.

Recommandations concernant le déploiement de production

Utilisez des plans App Service Premium v3/v4.
Activez la redondance de zone. Pour afficher les conditions requises pour activer la redondance de zone, accédez aux exigences de prise en charge de la zone de disponibilité.

Activez la redondance de zone, ce qui nécessite que votre plan App Service utilise au moins deux instances.

Erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications gèrent les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.

Les Kits de développement logiciel (SDK) fournis par Microsoft gèrent généralement les fautes temporaires. Étant donné que vous hébergez vos propres applications sur App Service, pensez à éviter d’entraîner des erreurs temporaires :

Déployez plusieurs instances dans votre plan. App Service effectue des mises à jour automatisées et d’autres formes de maintenance sur les instances de votre plan. Si une instance devient non saine, le service peut remplacer automatiquement cette instance par une nouvelle instance saine. Pendant le processus de remplacement, il peut y avoir une courte période lorsque l’instance précédente n’est pas disponible et qu’une nouvelle instance n’est pas prête à servir le trafic. Vous pouvez atténuer ces effets en déployant plusieurs instances de votre plan App Service.
Utilisez des emplacements de déploiement. Les emplacements de déploiement App Service permettent de déployer des déploiements sans temps d’arrêt de vos applications. Utilisez des emplacements de déploiement pour réduire l’effet des déploiements et des modifications de configuration pour vos utilisateurs. Les emplacements de déploiement réduisent également la probabilité que votre application redémarre. Le redémarrage de l’application provoque une erreur temporaire.
Évitez d’effectuer un scale-up ou un scale-down. Le scale-up et le scale-down nécessitent la modification du processeur, de la mémoire et d’autres ressources allouées à chaque instance. Les opérations de scale-up et de scale-down peuvent déclencher un redémarrage d’une application. Au lieu d’effectuer un scale-up ou un scale-down, sélectionnez un niveau et une taille d’instance qui répondent à vos besoins en matière de performances en fonction de la charge standard. Vous pouvez effectuer un scale-out et un scale-in en ajoutant et supprimant dynamiquement des instances pour gérer les modifications apportées au volume de trafic.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

App Service peut être configuré comme redondant interzone, ce qui signifie que vos ressources sont distribuées entre plusieurs zones de disponibilité. La distribution entre plusieurs zones permet à vos charges de travail de production d’atteindre la résilience et la fiabilité. Lorsque vous configurez la redondance par zone sur les plans App Service, toutes les applications qui utilisent le même plan deviennent redondantes par zone.

La distribution d’instances dans un déploiement redondant interzone suit des règles spécifiques. Ces règles restent applicables à mesure que l’application est mise à l’échelle et augmente. Pour plus d’informations, consultez Considérations.

Soutien régional

Les plans App Service redondants interzone peuvent être déployés dans n’importe quelle région qui prend en charge les zones de disponibilité.

Pour savoir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.

Spécifications

Vous devez utiliser les types de plans Premium v2-4. Pour afficher plus d’informations, veillez à sélectionner le niveau approprié en haut de cette page.

Vous devez utiliser les types de plan Premium v2-4 ou Isolé v2 et avoir au moins deux instances du plan.
Les zones de disponibilité sont prises en charge uniquement sur les unités d’échelle App Service plus récentes. Même si vous utilisez l’une des régions prises en charge, si les zones de disponibilité ne sont pas prises en charge pour l’unité d’échelle que vous utilisez, vous recevez une erreur lorsque vous créez un plan App Service redondant interzone.

L’unité d’échelle à laquelle vous êtes affecté est basée sur le groupe de ressources sur lequel vous déployez un plan App Service. Pour vous assurer que vos charges de travail atterrissent sur une unité d’échelle qui prend en charge les zones de disponibilité, vous devrez peut-être créer un groupe de ressources et créer un plan App Service et une application App Service au sein du nouveau groupe de ressources.

Pour voir si votre plan App Service se trouve sur un tampon qui prend en charge les zones de disponibilité, vérifiez la propriété maximumNumberOfZones du plan App Service. Si la valeur est supérieure à une, votre tampon prend en charge les zones et vous pouvez activer la redondance de zone sur le plan. Si la valeur est égale à une, votre unité d’échelle ne prend pas en charge les zones de disponibilité et vous devez déployer un nouveau plan pour activer la redondance des zones.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
Vous devez déployer au moins deux instances dans votre plan.

Considérations

Pendant une panne de zone de disponibilité, certains aspects d’Azure App Service peuvent être affectés, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Lorsque vous activez la redondance de zone sur votre plan App Service, vous améliorez également votre résilience aux mises à jour déployées par la plateforme App Service. Pour en savoir plus, consultez Fiabilité pendant la maintenance du service.

Instances minimales : Votre plan App Service doit avoir au moins deux instances pour la redondance de zone.
Zones de disponibilité maximale prises en charge par votre plan : Azure détermine le nombre de zones de disponibilité que votre plan peut utiliser. Pour afficher le nombre de zones de disponibilité que votre plan peut utiliser, consultez la propriété maximumNumberOfZones sur le plan App Service. Il s’agit d’une propriété en lecture seule. Si cette valeur est égale à 1, votre plan App Service ne prend pas en charge la redondance de zone. Si la valeur maximaleNumberOfZones est supérieure à 1, votre plan App Service peut être configuré pour la redondance de zone.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
Distribution d’instances : Lorsque la redondance de zone est activée, les instances de plan sont distribuées automatiquement sur plusieurs zones de disponibilité. La distribution est basée sur les règles suivantes :
- Les instances distribuent uniformément si vous spécifiez une capacité (nombre d’instances) supérieure à maximumNumberOfZones et que le nombre d’instances est divisible par maximumNumberOfZones.
- Toutes les instances restantes sont réparties entre les zones restantes.
- Lorsque la plateforme App Service alloue des instances à un plan App Service redondant interzone, elle utilise le meilleur équilibrage de zone possible qu’offre les groupes de machines virtuelles identiques Azure. Un plan App Service est équilibré si chaque zone a le même nombre de machines virtuelles ou diffère de plus ou moins une machine virtuelle par rapport à toutes les autres zones. Pour découvrir plus d’informations, consultez Équilibrage de zone.
Positionnement de zone physique : Vous pouvez afficher la zone de disponibilité physique utilisée pour chacune de vos instances de plan App Service. Utilisez l’API REST, qui retourne la physicalZone valeur de chaque instance.
```
az rest --method get --url https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/instances?api-version=2024-04-01
```

Pour les plans App Service qui ne sont pas configurés comme redondants interzone, les instances de machine virtuelle sous-jacentes ne sont pas résilientes aux échecs de zone de disponibilité. Elles peuvent rencontrer des temps d’arrêt pendant une panne dans n’importe quelle zone de cette région.

Coût

Lorsque vous utilisez des plans App Service Premium v2-v4, il n’existe aucun coût supplémentaire associé à l’activation des zones de disponibilité tant que vous avez deux instances ou plus dans votre plan App Service. Vous êtes facturé en fonction de la référence SKU de votre plan App Service, de la capacité que vous spécifiez et de toutes les instances que vous mettez à l’échelle en fonction de vos critères de mise à l’échelle automatique.

Si vous activez les zones de disponibilité, mais spécifiez une capacité inférieure à deux, la plateforme applique un nombre minimal d’instances de deux. La plateforme vous facture pour ces deux instances.

Lorsque vous utilisez le plan App Service Isolé v2, il n’existe aucun coût supplémentaire associé à l’activation des zones de disponibilité tant que vous avez deux instances ou plus dans votre plan App Service. Vous êtes facturé en fonction de la référence SKU de votre plan App Service, de la capacité que vous spécifiez et de toutes les instances auxquelles vous effectuez une mise à l’échelle en fonction de vos critères de mise à l’échelle automatique.

Configurer la prise en charge des zones de disponibilité

Pour déployer un nouveau plan App Service redondant interzone, vous devez utiliser les types de plan Premium v2-4. Pour afficher plus d’informations, veillez à sélectionner le niveau approprié en haut de cette page.

Créez un plan App Service avec redondance de zone. Pour déployer un nouveau plan App Service redondant interzone, sélectionnez l’option redondante interzone lorsque vous déployez le plan dans le portail Azure ou définissez la propriété zoneRedundant du plan true App Service sur la commande Azure CLI, la commande Azure PowerShell, le fichier Bicep ou le modèle Azure Resource Manager :
- Azure CLI
- Biceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --zone-redundant --number-of-workers 2 --sku P1V3
```
Remarque

Si vous utilisez Azure CLI pour modifier la zone-redundant propriété, vous devez spécifier la propriété, qui est le --number-of-workers nombre d’instances, et utiliser une capacité supérieure ou égale à 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Migrez un plan App Service existant vers la redondance de zone. Si vous disposez d’un plan App Service existant qui prend en charge la redondance de zone (le nombre maximal de zones disponibles est supérieur à 1), vous pouvez activer la redondance de zone en définissant la propriété zoneRedundant du true plan App Service sur azure CLI, votre fichier Bicep ou votre modèle Resource Manager :
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Remarque

Si vous utilisez Azure CLI pour modifier la zoneRedundant propriété, vous devez spécifier la propriété, qui est le sku.capacity nombre d’instances, et utiliser une capacité supérieure ou égale à 2.

Si vous êtes sur un plan ou un tampon qui ne prend pas en charge les zones de disponibilité, vous devez créer un plan App Service dans un nouveau groupe de ressources afin que vous atterrissiez sur l’empreinte App Service qui prend en charge les zones.

Remarque

La modification de l’état de redondance de zone d’un plan App Service est presque instantanée. Vous ne rencontrez pas de temps d’arrêt ou de problèmes de performances pendant le processus.
Désactivez la redondance de zone. Pour désactiver la redondance de zone, définissez la propriété du plan zoneRedundant App Service sur false ou utilisez Azure CLI :
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Remarque

Si vous utilisez Azure CLI pour désactiver la zoneRedundant propriété, vous devez spécifier la sku.capacity propriété, sinon la valeur par défaut est 1.

Créez un plan App Service avec redondance de zone.
1. Si vous n’avez pas d’environnement App Service redondant interzone préexistant, déployez un nouvel environnement App Service redondant interzone. Pour plus d’informations sur la création d’un environnement App Service, consultez Créer un environnement App Service.
2. Pour créer le plan App Service dans le portail Azure, sélectionnez Redondant interzone. Pour créer le plan à l’aide de la commande Azure CLI, de la commande Azure PowerShell, du fichier Bicep ou du modèle Resource Manager, définissez la propriété zoneRedundantdu plan true App Service sur , comme dans l’exemple de code suivant :
- Azure CLI
- Biceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --app-service-environment MyAse --zone-redundant --number-of-workers 2 --sku I1V2
```
Remarque

Si vous utilisez Azure CLI pour modifier la zoneRedundant propriété, vous devez spécifier la propriété, qui est le number-of-workers nombre d’instances, et utiliser une capacité supérieure ou égale à 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Migrer un plan App Service existant vers la redondance de zone Si vous disposez d’un environnement App Service existant ou d’un plan App Service isolé v2 qui prend en charge la redondance de zone, vous pouvez activer la redondance de zone à tout moment. Pour activer la redondance de zone pour l’environnement App Service, définissez la zoneRedundant propriété true sur ou utilisez Azure CLI :
- Azure CLI
- Biceps
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=true
```
```
resource asev3 'Microsoft.Web/hostingEnvironments@2020-12-01' = {
    name: aseName
    location: location
    kind: 'ASEV3'
    dependsOn: [
        virtualnetwork
    ] 
    properties: {
        ...
        zoneRedundant: true
    }
}
```
Remarque

Lorsque vous modifiez l’état de redondance de zone de l’environnement App Service, vous lancez une mise à niveau qui prend 12 à 24 heures. Pendant le processus de mise à niveau, vous ne rencontrez aucun temps d’arrêt ni aucun problème de performances.

Pour les plans App Service isolés v2, si l’environnement App Service est redondant interzone, les plans App Service peuvent être redondants interzone. Chaque plan App Service a son propre paramètre de redondance de zone indépendante, ce qui signifie que vous pouvez avoir une combinaison de plans redondants interzone et non redondants interzone dans un environnement App Service. Pour activer la redondance de zone sur un plan App Service isolé v2, définissez la propriété zoneRedundant du plan App Service sur true ou utilisez Azure CLI.
- Azure CLI
- Biceps
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Remarque

Si vous utilisez Azure CLI pour modifier la zoneRedundant propriété, vous devez spécifier la propriété, qui est le sku.capacity nombre d’instances, et utiliser une capacité supérieure ou égale à 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Désactivez la redondance de zone. Pour désactiver la redondance de zone, vous pouvez définir le plan App Service ou la propriété App Service Environment zoneRedundant sur false ou utiliser Azure CLI :
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=false

az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Remarque

Si vous utilisez Azure CLI pour désactiver la zoneRedundant propriété, vous devez spécifier la sku.capacity propriété, sinon la valeur par défaut est 1.

Planification de capacité et gestion

Pour vous préparer à une défaillance de zone de disponibilité, envisagez de surprovisionner la capacité de votre plan App Service. Le surapprovisionnement permet à la solution de tolérer un certain degré de perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

Opérations normales

La section suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles :

Routage du trafic entre les zones : Pendant les opérations normales, le trafic est acheminé entre toutes vos instances de plan App Service disponibles dans toutes les zones de disponibilité.
Réplication des données entre les zones : Pendant les opérations normales, tout état stocké dans le système de fichiers de votre application est stocké dans un stockage redondant interzone et répliqué de manière synchrone entre les zones de disponibilité.

Expérience en cas de défaillance de zone

La section suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles :

Détection et réponse : La plateforme App Service détecte automatiquement les défaillances dans une zone de disponibilité et lance une réponse. Aucune intervention manuelle n’est nécessaire pour lancer un basculement de zone.
Demandes actives : Lorsqu’une zone de disponibilité n’est pas disponible, toutes les requêtes en cours connectées à une instance de plan App Service dans la zone de disponibilité défectueuse sont arrêtées. Elles doivent faire l’objet d’une nouvelle tentative.
Réacheminement du trafic : Lorsqu’une zone n’est pas disponible, App Service détecte les instances perdues de cette zone et tente automatiquement de trouver de nouvelles instances de remplacement. Une fois les remplacements trouvés, il distribue ensuite le trafic entre les nouvelles instances en fonction des besoins.

Si la mise à l’échelle automatique est configurée et détermine que d’autres instances sont nécessaires, il émet une demande à App Service pour ajouter ces instances. Le comportement de mise à l’échelle automatique fonctionne indépendamment du comportement de la plateforme App Service, ce qui signifie que la spécification du nombre d’instances n’a pas besoin d’être un multiple de deux. Pour plus d’informations, consultez Mise à l’échelle d’une application dans App Service et vue d’ensemble de la mise à l’échelle automatique.

Important

Il n’est pas garanti que les requêtes d’instances supplémentaires réussissent dans un scénario de zone en panne. Le remplissage des instances perdues se produit sur une base optimale. Si vous avez besoin d’une capacité garantie lorsqu’une zone de disponibilité est perdue, vous devez créer et configurer vos plans App Service pour tenir compte de la perte d’une zone. Pour ce faire , vous pouvez surprovisionner la capacité de votre plan App Service.
Comportements non-runtime : Les applications déployées dans un plan App Service redondant interzone continuent à s’exécuter et à traiter le trafic même si une zone de disponibilité subit une panne. Toutefois, il est possible que les comportements hors runtime soient toujours affectés pendant une panne de zone de disponibilité. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Restauration automatique

Lorsque la zone de disponibilité récupère, App Service crée automatiquement des instances dans la zone de disponibilité récupérée, supprime toutes les instances temporaires créées dans les autres zones de disponibilité et route le trafic entre vos instances comme d’habitude.

Test des défaillances de zone

La plateforme App Service gère le routage du trafic, le basculement et la restauration automatique pour les plans App Service redondants interzone. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

Prise en charge de plusieurs régions

App Service est un service à région unique. Si la région devient indisponible, votre application n’est pas disponible.

Autres approches multirégions

Pour réduire le risque d’une défaillance à une seule région affectant votre application, déployez-la dans plusieurs régions. Les étapes suivantes aident à renforcer la résilience :

Déployez votre application sur les instances de chaque région.
Configurez les stratégies d’équilibrage de charge et de basculement.
Répliquez vos données entre les régions afin de pouvoir récupérer votre dernier état d’application.

Les ressources suivantes sont liées à cette approche :

Pour obtenir un exemple d’approche illustrant cette architecture, consultez le déploiement d’entreprise haute disponibilité à l’aide d’App Service Environment.

Sauvegardes

Lorsque vous utilisez le niveau Essentiel ou un niveau supérieur, vous pouvez sauvegarder votre application App Service dans un fichier à l’aide des fonctionnalités de sauvegarde et restauration App Service.

Cette fonctionnalité est utile s’il est difficile de redéployer votre code ou si vous stockez l’état sur le disque. Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans App Service.

Fiabilité pendant la maintenance du service

Azure App Service effectue des mises à niveau de service régulières, ainsi que d’autres formes de maintenance. Pour vous assurer que votre capacité attendue est disponible pendant une mise à niveau, la plateforme ajoute automatiquement des instances supplémentaires du plan App Service pendant le processus de mise à niveau.

Activer la redondance de zone. Lorsque vous activez la redondance de zone sur votre plan App Service, vous améliorez également votre résilience aux mises à jour déployées par la plateforme App Service. Les domaines de mise à jour se composent de collections de machines virtuelles qui sont mises hors connexion au moment d’une mise à jour. Les domaines de mise à jour sont liés aux zones de disponibilité. Le déploiement de plusieurs instances dans votre plan App Service et l’activation de la redondance de zone pour votre plan ajoute une couche supplémentaire de résilience pendant les mises à niveau si une instance ou une zone devient défectueuse.

Pour plus d’informations, consultez Maintenance planifiée de routine pour Azure App Service.

Personnalisez le cycle de mise à niveau. Vous devez personnaliser le cycle de mise à niveau d’un environnement App Service. Si vous devez valider l’effet des mises à niveau sur votre charge de travail, envisagez d’activer les mises à niveau manuelles afin de pouvoir effectuer la validation et le test sur une instance hors production avant le déploiement de la modification sur votre instance de production.

Pour en savoir plus sur les préférences de maintenance, consultez La préférence de mise à niveau pour la maintenance planifiée d’App Service Environment.

Contrat de niveau de service (SLA)

Le contrat de niveau de service (SLA) pour App Service décrit la disponibilité attendue du service et les conditions qui doivent être remplies pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Lorsque vous déployez un plan App Service redondant entre zones, le pourcentage de temps d’activité défini dans le SLA augmente.

Fiabilité dans Azure