Partager via

Fiabilité dans Azure Functions

Azure Functions est un service de calcul basé sur les événements qui vous permet d’exécuter de petits blocs de code (fonctions) sans avoir à provisionner ou gérer explicitement l’infrastructure. Les fonctions peuvent répondre à des événements tels que des requêtes HTTP, des minuteurs, des messages de file d’attente et des modifications dans d’autres services Azure, ce qui permet de traiter les données, d’intégrer des systèmes et d’exécuter des tâches en arrière-plan.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Functions résilient à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité et les défaillances à l’échelle de la région. Il met également en évidence des informations clés sur le contrat de niveau de service Azure Functions (SLA).

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, les performances, la sécurité, le coût et les opérations. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution Azure Functions fiable, consultez les meilleures pratiques d’architecture pour Azure Functions.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous déployez Azure Functions, il est important d’être familiarisé avec plusieurs concepts :

  • Plans d’hébergement : Les plans représentent l’environnement d’hébergement de vos applications de fonction. Le plan détermine les ressources de calcul disponibles, le modèle de tarification et le comportement de mise à l’échelle.

  • Comptes de stockage : Lorsque vous créez une application de fonction, vous devez spécifier un compte de stockage hôte. Le compte de stockage est utilisé pour gérer les aspects des opérations internes de l'application de fonctions, notamment le stockage du code des fonctions, la journalisation et la gestion de la concurrence (par exemple, les locations de blobs pour certains types de déclencheurs).

    Vous pouvez également utiliser un compte de stockage pour le déploiement. Ce compte de stockage peut être identique à votre compte de stockage hôte ou à un autre compte de stockage.

    Important

    Les comptes de stockage sont des parties critiques de votre architecture de fiabilité Azure Functions, et vous devez les configurer pour répondre aux exigences de résilience de votre application de fonction.

  • Déclencheurs et liaisons : celles-ci permettent à votre fonction de répondre aux événements, de recevoir et d’écrire des données à partir d’autres services.

  • Fonctions durables : Les fonctions durables sont des fonctions avec état, notamment des orchestrations de longue durée et des entités avec état.

    Lorsque vous utilisez Durable Functions, vous configurez un fournisseur de stockage qui stocke l’état. Vous devez évaluer les caractéristiques de fiabilité du magasin d’état que vous choisissez et la configurer pour répondre à vos exigences de résilience.

Résilience aux 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 puissent gérer 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, consultez Recommandations pour la gestion des erreurs temporaires.

Tenez compte des recommandations suivantes pour gérer les erreurs temporaires dans vos applications de fonction :

  • Déclencheurs et liaisons : La plateforme Azure Functions inclut la gestion des erreurs temporaires intégrée pour de nombreux déclencheurs et liaisons. Lorsqu’une erreur temporaire se produit lorsqu’un déclencheur pris en charge se déclenche ou qu’une liaison prise en charge lit ou écrit des données, la plateforme peut réessayer automatiquement l’opération. Ce comportement de nouvelle tentative intégré permet de s’assurer que les problèmes de connectivité temporaires ou les blips de service n’empêchent pas l’exécution de votre fonction. Pour plus d’informations, consultez gestion des erreurs et nouvelles tentatives d’Azure Functions.

    Toutefois, cette protection couvre uniquement les erreurs temporaires. Les échecs persistants, tels qu’une chaîne de connexion mal configurée ou une ressource supprimée, ne sont pas retentés.

    Les échecs persistants et les échecs temporaires répétés sont traités comme des erreurs et vous pouvez configurer la journalisation pour capturer des informations sur les erreurs d’exécution de fonction. Pour plus d’informations, consultez How to configure monitoring for Azure Functions.

  • Votre code de fonction : Dans le corps de votre fonction, vous êtes responsable de la gestion des erreurs temporaires lorsque vous effectuez des appels à des services externes. Vous devez implémenter des modèles de logique de nouvelle tentative, de délai d’attente et de disjoncteur appropriés pour tous les appels de service externes effectués dans votre code de fonction. Concevez vos fonctions pour qu'elles soient idempotentes dans la mesure du possible, afin que les réessais ne provoquent pas de doublons d'effets secondaires.

  • Clients : Toutes les applications clientes qui se connectent à des fonctions de manière synchrone, telles que l’utilisation d’une connexion HTTP, doivent être résilientes aux erreurs temporaires.

Résilience aux échecs de zone de disponibilité

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

Les plans de consommation ne prennent pas en charge les zones de disponibilité. Si la redondance de zone est requise pour votre charge de travail, envisagez d’utiliser le plan Flex Consumption, le plan Premium ou le plan Dédié (App Service).

Les plans Flex Consumption prennent en charge les déploiements redondants interzone.

Les plans Premium prennent en charge les déploiements redondants interzone.

Lorsque la redondance de zone est activée, la plateforme répartit automatiquement vos instances de plan dans toutes les zones de disponibilité de la région sélectionnée. Si une zone de disponibilité dans la région a un problème, vos fonctions continuent à s’exécuter à l’aide d’instances dans des zones saines.

Vous devez également activer le stockage redondant interzone (ZRS) sur le compte de stockage hôte, ce qui garantit qu’il est également résilient aux pannes de zone.

Diagramme montrant le plan Azure Functions redondant interzone avec trois instances réparties entre trois zones et un compte de stockage redondant interzone.

Le plan Dédié (App Service) prend en charge les déploiements redondants interzone. Lorsque la redondance de zone est activée, la plateforme répartit automatiquement vos instances dans toutes les zones de disponibilité de la région sélectionnée. Vous configurez la redondance de zone sur le plan. Pour plus d’informations sur la façon dont App Service gère la redondance de zone, consultez Fiabilité dans Azure App Service.

Si vous n’activez pas la redondance de zone, votre plan est non zonal ou régional, ce qui signifie que les instances de plan peuvent être placées dans n'importe quelle zone de disponibilité de la région ou dans la même zone, et qu’elles ne résistent pas aux défaillances des zones de disponibilité. Votre plan peut rencontrer des temps d’arrêt pendant une panne dans n’importe quelle zone de la région.

Exigences

  • Prise en charge de la région : Les plans Flex Consumption à redondance de zone peuvent être déployés dans un ensemble spécifique de régions. Vous pouvez récupérer la liste actuelle des régions prises en charge à l’aide d’Azure CLI. Pour plus d’informations, consultez Afficher les régions qui prennent en charge les zones de disponibilité.

  • Prise en charge de la région : Les plans Premium à redondance inter-zone peuvent être déployés dans les régions suivantes :

    Americas Europe Moyen-Orient Africa Asie-Pacifique
    Brazil South France Centrale Israel Central Afrique du Sud Nord Australia East
    Canada Central Allemagne Centre-Ouest Qatar Central Inde centrale
    Central US Italie Nord Émirats arabes unis Nord Chine Nord 3
    East US Europe Nord Asie de l’Est
    Est des États-Unis 2 Norvège Est Japon Est
    États-Unis - partie centrale méridionale Suède Centre Asie du Sud-Est
    Ouest des États-Unis 2 Suisse Nord
    Ouest des États-Unis 3 UK South
    Europe Ouest

  • Systèmes d’exploitation : Les plans Windows et Linux sont pris en charge.

  • Nombre minimal d’instances : Un minimum de deux instances toujours prêtes est nécessaire lorsque la redondance de zone est activée pour les plans Premium.

  • Compte de stockage hôte : Vous devez configurer le compte de stockage hôte par défaut de votre application de fonction pour utiliser le stockage redondant interzone (ZRS). Si vous utilisez un compte de stockage hôte qui n’est pas configuré pour ZRS, votre application peut se comporter de manière inattendue lors d’une panne de zone.
  • Compte de stockage de conteneur de déploiement : Si vous utilisez un compte de stockage distinct pour le conteneur de déploiement de l’application, vous devez également le mettre à jour pour qu’il soit redondant interzone.

Considérations

La redondance de zone garantit uniquement une durée de fonctionnement continue pour les applications déployées. Une panne de zone de disponibilité peut affecter certains aspects d’Azure Functions, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle du plan, la création d’applications, la configuration de l’application et la publication d’applications.

Distribution d’instances entre zones

Lorsque vous configurez des applications du plan Flex Consumption en tant qu'interzonal redondant, la plateforme répartit automatiquement les instances du plan entre plusieurs zones de la région sélectionnée, avec différentes règles pour les instances toujours prêtes par rapport à celles à la demande.

  • Les instances toujours prêtes sont distribuées entre au moins deux zones de manière alternée.

    Pour garantir la résilience de zone, la plateforme gère automatiquement au moins deux instances toujours prêtes pour chaque fonction ou groupe de mise à l’échelle par fonction, quelle que soit la configuration toujours prête pour l’application. Toutes les instances créées par la plateforme sont gérées par la plateforme, facturées en tant qu’instances toujours prêtes et ne modifient pas les paramètres de configuration toujours prêts.

  • Les instances à la demande sont créées à la suite de volumes sources d’événements au fur et à mesure que l’application est mise à l’échelle au-delà du nombre d’instances toujours prêtes. Les instances à la demande sont distribuées entre les zones de disponibilité de manière optimale. Un déploiement plus rapide est privilégié par rapport à une répartition uniforme entre les zones. La plateforme tente d'égaliser la distribution au fil du temps.

Lorsque vous configurez les plans d’applications fonctionnelles Elastic Premium comme redondants entre zones, la plateforme répartit automatiquement les instances du plan entre plusieurs zones de la région sélectionnée. La répartition des instances suit ces règles, même lorsque l'application s'adapte à la montée et à la descente en charge :

  • Le nombre minimal d’instances d’application de fonction est de deux.
  • Lorsque vous spécifiez une capacité supérieure au nombre de zones, les instances sont réparties uniformément lorsque la capacité est un multiple du nombre de zones.
  • Pour une valeur de capacité supérieure au nombre de zones * nombre d’instances, des instances supplémentaires sont réparties entre les zones restantes.

Lorsque Functions alloue des instances à un plan Premium redondant interzone, il utilise l’équilibrage de zone à meilleur effort, que proposent les groupes de machines virtuelles identiques Azure sous-jacents. Un plan Premium est considéré comme équilibré lorsque chaque zone a le même nombre de machines virtuelles dans toutes les autres zones utilisées par le plan Premium, plus ou moins une machine virtuelle.

Coûts

Il n’existe aucun coût supplémentaire associé à l’activation de la redondance de zone. La tarification d’un plan redondant interzone est identique à celle d’un plan à zone unique.

Toutefois, lorsque vous activez des zones de disponibilité dans une application avec une configuration d’instance toujours prête de moins de deux instances pour chaque fonction ou groupe de mise à l’échelle par fonction, la plateforme crée automatiquement deux instances du type toujours prêt pour chaque fonction ou groupe de mise à l’échelle par fonction. Ces nouvelles instances sont également facturées en tant qu’instances toujours prêtes.

Toutefois, si vous activez des zones de disponibilité sur un plan avec moins de deux instances, la plateforme applique un nombre minimal d’instances de deux pour ce plan et vous êtes facturé pour les deux instances.

Pour plus d’informations sur la tarification, consultez la tarification d’Azure Functions.

Configurez la prise en charge des zones de disponibilité

  • Créez un nouveau plan Azure Functions à redondance de zone. Vous pouvez activer la redondance de zone lorsque vous créez un plan. Pour obtenir des instructions détaillées, consultez Créer une application de fonction redondante interzone.

  • Activez la redondance de zone sur un plan existant : Pour les plans Premium, vous ne pouvez activer la redondance de zone que lors de la création du plan. Vous ne pouvez pas convertir un plan Premium existant en plan à redondance de zone. Vous devez plutôt migrer votre application en créant un déploiement côte à côte sur une nouvelle application de plan Premium. Pour plus d’informations, consultez Activer la redondance de zone sur un plan existant.

Planification de capacité et gestion

Les applications de fonction à redondance entre zones continuent de s'exécuter même lorsque certaines zones sont en panne.

Lors d’une panne de zone, Azure Functions détecte les instances perdues et tente automatiquement de localiser ou de créer des instances de remplacement dans les zones saines. Ce processus est effectué au mieux et n’est pas garanti. Si votre charge de travail doit avoir un certain nombre d’instances pour maintenir votre niveau de service attendu, envisagez de surprovisionner le nombre d’instances toujours prêtes. Cette approche permet à la solution de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité à l’aide du surapprovisionnement.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un plan est redondant interzone, que le compte de stockage hôte utilise ZRS et que toutes les zones de disponibilité sont opérationnelles.

  • Opération interzone : Lorsque vous configurez la redondance de zone sur Azure Functions, les requêtes sont réparties automatiquement entre les instances de chaque zone de disponibilité. Une demande peut aller à n’importe quelle instance dans n’importe quelle zone de disponibilité.

  • Réplication des données interzones : Azure Functions est un service de calcul sans état. Il n’existe donc aucune donnée client à répliquer entre les zones. La plateforme réplique automatiquement la configuration entre les zones.

    Si votre compte de stockage hôte utilise ZRS, Stockage Azure réplique de façon synchrone ses données dans plusieurs zones de disponibilité.

    Pour Durable Functions, passez en revue votre fournisseur de stockage pour comprendre comment il réplique les données entre les zones.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s'attendre lorsque un plan a une redondance de zone, que le compte de stockage hôte utilise ZRS et qu'il y a une panne de zone de disponibilité.

  • Détection et réponse : La plateforme Azure Functions est chargée de détecter une défaillance dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Lorsqu’une zone de disponibilité n’est pas disponible, toutes les requêtes en cours connectées à une instance de la zone de disponibilité défectueuse sont arrêtées et doivent être retentées. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

  • Perte de données attendue : Les échecs de zone ne sont pas censés entraîner une perte de données, car Azure Functions est un service sans état.

    Si votre compte de stockage hôte utilise ZRS, Stockage Azure assure qu'il n'y a pas de perte de données due à une défaillance de zone.

    Pour Durable Functions, passez en revue votre fournisseur de stockage pour comprendre si la perte de données est possible lors d’une défaillance de zone.

  • Temps d’arrêt attendu : Pendant les pannes de zone, les connexions peuvent rencontrer de brèves interruptions qui durent généralement quelques secondes au fur et à mesure que le trafic est redistribué. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

  • Réacheminement du trafic : Azure Functions détecte les instances perdues de cette zone et tente de trouver de nouvelles instances de remplacement. Une fois qu’Azure Functions trouve des remplacements, il distribue le trafic entre les nouvelles instances en fonction des besoins.

    Important

    Azure ne garantit pas que les demandes de plus d’instances réussissent dans un scénario de zone descendante. La plateforme tente de restaurer les instances perdues dans la mesure du possible. Si vous avez besoin d’une capacité garantie lors d’un échec de zone de disponibilité, créez et configurez vos plans pour tenir compte de la perte de zone en surprovisionnant la capacité.

  • Comportements non-runtime : Les applications d’un plan d’application de fonction redondant interzone continuent à s’exécuter et à traiter le trafic même si une zone de disponibilité rencontre 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 des applications de fonction, la création d’applications, la configuration de l’application et la publication d’applications.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Azure Functions restaure automatiquement les instances dans la zone de disponibilité, supprime toutes les instances temporaires créées dans les autres zones de disponibilité et redirige le trafic entre vos instances normalement.

Tester les pannes de zone

La plateforme Azure Functions gère le routage du trafic, le basculement et la récupération de zone pour les ressources redondantes interzone. Vous n’avez pas besoin de lancer quoi que ce soit. Étant donné que cette fonctionnalité est entièrement gérée, vous n’avez pas besoin de valider les processus d’échec de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Azure Functions est un service à région unique. Si la région devient indisponible, votre ressource Azure Functions est également indisponible.

Solutions multirégions personnalisées pour la résilience

Pour éviter la perte d’exécution pendant les pannes, vous pouvez déployer les mêmes fonctions de manière redondante pour des applications de fonction dans plusieurs régions.

Vous êtes responsable des opérations suivantes :

  • Déploiement d’applications de fonction dans plusieurs régions
  • Gestion de la distribution du trafic entre les régions
  • Implémentation de mécanismes de basculement
  • Garantir la cohérence des données entre les régions (le cas échéant)
  • Surveillance et gestion des déploiements interrégions

Lorsque vous exécutez le même code de fonction dans plusieurs régions, il existe deux modèles couramment utilisés que vous pouvez prendre en compte : actif-actif et actif-passif. Les sections suivantes fournissent une brève présentation de ces modèles, mais ne fournissent pas d’instructions détaillées ou des étapes de configuration.

Modèle actif-actif pour les fonctions de déclencheur HTTP

Avec un modèle actif-actif, les fonctions des deux régions s’exécutent activement et traitent les événements, soit de manière dupliquée, soit en rotation. Vous devez utiliser un modèle actif-actif en combinaison avec Azure Front Door pour vos fonctions critiques déclenchées par HTTP, qui peuvent acheminer des requêtes HTTP de manière répartie en tournoi entre les fonctions s’exécutant dans plusieurs régions. Azure Front Door peut également vérifier régulièrement l’intégrité de chaque point de terminaison. Si une fonction d’une région cesse de répondre aux contrôles d’intégrité, Azure Front Door l’enlève de la rotation et ne transfère le trafic qu'aux autres fonctions en bon état.

Diagramme montrant un exemple d’architecture active-active, avec le routage Azure Front Door entre les applications Azure Functions dans différentes régions, chacune avec sa propre base de données.

Modèle actif-passif pour les fonctions de déclencheur non HTTP

Pour les fonctions déclenchées par des événements et non HTTP (telles que les fonctions déclenchées par Service Bus et Event Hubs), utilisez un modèle actif-passif. Avec un modèle actif-passif, les fonctions s’exécutent activement dans la région qui reçoit des événements, tandis que les mêmes fonctions d’une deuxième région restent inactives. Le modèle actif-passif permet à une fonction unique de traiter chaque message, ce qui est essentiel pour maintenir la cohérence des données, tout en offrant un mécanisme pour basculer vers la région secondaire en cas d'interruption, telle qu'une panne régionale.

Le basculement de l'application de fonction doit être pris en compte avec les comportements de basculement d'autres services, tels que:

Prenons un exemple de topologie à l’aide d’un déclencheur Azure Event Hubs, où votre espace de noms Event Hubs est configuré pour la récupération géographique d’urgence. Dans ce cas, le modèle actif-passif nécessite les composants suivants :

  • Azure Event Hubs est déployé dans une région primaire et une région secondaire.
  • La récupération géographique de sinistres est activée pour appairer les hubs d’événements principaux et secondaires. Cela crée également un alias que vous pouvez utiliser pour vous connecter à l’espace de noms Event Hubs et passer du serveur principal au secondaire sans modifier les informations de connexion.
  • Les applications de fonctions sont déployées dans la région principale et la région secondaire (de basculement), l'application de la région secondaire est essentiellement inactive en raison du fait que les messages ne sont pas envoyés.
  • L’application de fonction se déclenche sur la chaîne de connexion directe (nonalias) pour son espace de noms Event Hubs respectif.
  • Les éditeurs doivent publier dans l'espace de noms Event Hubs en utilisant la chaîne de connexion d’alias.

Diagramme montrant un exemple d’architecture active-passive, avec la géo-récupération d’urgence Event Hubs couvrant plusieurs régions et des applications de fonction et des bases de données distinctes dans chaque région.

Avant le basculement, les serveurs de publication effectuant des envois vers l’alias partagé sont routés vers l’Event Hub primaire. L’application de fonction primaire écoute exclusivement le hub d’événements primaire. L’application de fonction secondaire est passive et inactive.

Dès que le basculement est déclenché, les serveurs de publication qui effectuent des envois vers l’alias partagé sont routés vers l’Event Hub secondaire. L’application de fonction secondaire devient alors active et se déclenche automatiquement. Il est possible de réaliser en intégralité un basculement efficace vers une région secondaire à partir du hub d’événements, les fonctions devenant actives uniquement quand le hub d’événements correspondant est actif.

Fonctions durables

Pour la récupération d’urgence multirégion pour Durable Functions, consultez la récupération d’urgence et la géo-distribution dans Azure Durable Functions.

Résilience à la maintenance du service

Azure Functions effectue des mises à niveau de service régulières et d’autres tâches de maintenance.

  • Résilience des erreurs temporaires : Pendant la maintenance du service, les instances qui exécutent votre application de fonction peuvent être redémarrées ou rencontrer des interruptions temporaires. Vérifiez que toutes les applications clientes qui interagissent avec votre application de fonction sont résilientes aux erreurs temporaires.
  • Activez la redondance de zone : Lorsque vous activez la redondance de zone sur votre plan, vous améliorez également la résilience pendant les mises à jour de la plateforme. Le déploiement de plusieurs instances dans votre plan et l’activation de la redondance de zone pour votre plan ajoute une couche supplémentaire de résilience si une instance ou une zone devient défectueuse pendant une mise à niveau.

Pour maintenir votre capacité attendue pendant une mise à niveau, la plateforme ajoute automatiquement des instances supplémentaires du plan pendant le processus de mise à niveau.

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

  • Environnement App Service : Si vous hébergez votre application de fonction dans un environnement App Service, vous pouvez personnaliser le cycle de mise à niveau. Si vous devez valider l’effet des mises à niveau sur votre charge de travail, activez les mises à niveau manuelles. Cette approche vous permet d’effectuer la validation et le test sur une instance hors production avant de les appliquer à votre instance de production.

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

Résilience aux déploiements d’applications

Les déploiements d’applications présentent le risque de problèmes dans un environnement de production. Vous devez être prêt à restaurer une mise à jour si elle provoque des problèmes. Vous devez également contrôler la façon dont les mises à jour sont déployées pour réduire les interruptions des redémarrages de l’application.

Les plans Flex Consumption prennent en charge les stratégies de mise à jour de site, qui fournissent plusieurs façons de déployer vos mises à jour d’application, y compris les mises à jour propagées pour les déploiements sans temps d’arrêt.

Les emplacements de déploiement Azure Functions permettent de déployer des déploiements sans temps d’arrêt de vos applications de fonction. 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.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Azure Functions fournit des contrats SLA de disponibilité distincts pour le plan Consommation et pour d’autres types de plans.

Contenu connexe

  • Last updated on