Fiabilité dans Azure Functions

Azure Functions est un service de calcul piloté par les événements qui exécute de petits blocs de code, ou functions, sans provisionnement ou gestion d’infrastructure explicite. 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. Cette fonctionnalité rend Functions bien adaptée au traitement des données, à l’intégration du système et aux 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 Functions résiliente à 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 Functions (SLA).

Recommandations concernant le déploiement de production

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

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous déployez Functions, il est important de vous familiariser avec ces 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 tarifaire 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 gère les aspects des opérations internes de l'application fonction, notamment le stockage du code de la fonction, la journalisation et la gestion de la simultanéité (par exemple, les baux de blobs pour des types de déclencheurs spécifiques).

    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 font partie essentielle de votre architecture de fiabilité Functions. Configurez-les pour répondre aux exigences de résilience de votre application de fonction.

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

  • Fonctions durables : Les fonctions durables sont une fonctionnalité de Functions. Il fournit des fonctions avec état telles que des orchestrations longues et des entités avec état.

    Lorsque vous utilisez des fonctions durables, vous configurez un fournisseur de stockage qui stocke l’état. Évaluez les caractéristiques de fiabilité du magasin d’état que vous choisissez et configurez-le 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 Functions inclut la gestion des erreurs temporaires intégrée pour les déclencheurs et les 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é garantit que les problèmes de connectivité temporaires ou les interruptions de service n’empêchent pas votre fonction de s’exécuter. Pour plus d’informations, consultez la gestion des erreurs et les nouvelles tentatives.

    Cette protection couvre uniquement les erreurs temporaires. La plateforme ne réessaye pas d'échecs persistants, tels qu'une chaîne de connexion mal configurée ou une ressource supprimée.

    La plateforme traite les échecs persistants et les échecs temporaires répétés comme des erreurs. Configurez la journalisation pour capturer des informations sur les erreurs d’exécution de fonction. Pour plus d’informations, consultez Configurer la surveillance pour Functions.

  • Votre code de fonction : Dans votre code de fonction, vous êtes responsable de la gestion des erreurs temporaires lorsque votre fonction appelle des services externes. Implémentez la logique de nouvelle tentative, les délais d’attente et les modèles de rupture de circuit appropriés pour les appels de service externes effectués dans votre code fonctionnel. Concevez vos fonctions pour être idempotentes dans la mesure du possible afin que les nouvelles tentatives ne créent pas d’effets secondaires dupliqués.

  • Clients : Les applications clientes qui se connectent à des fonctions de manière synchrone, comme par le biais 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 les plans Flex Consumption, Premium ou Dedicated (Azure App Service) à la place.

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 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 un plan Functions redondant interzone avec trois instances réparties entre trois zones et un compte ZRS.

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 Azure App Service gère la redondance de zone, consultez Reliability in App Service.

Votre plan est non zonal ou régional lorsque vous n’activez pas la redondance de zone. La plateforme peut placer des instances de plan dans n’importe quelle zone de disponibilité de la région ou dans la même zone. Les instances de plan ne sont pas résilientes aux défaillances de zone 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 : Vous pouvez déployer des plans Premium redondants interzone 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 : La plateforme prend en charge le déploiement de plans Windows et Linux à redondance de zone.

  • Nombre minimal d’instances : La redondance de zone pour les plans Premium nécessite un minimum de deux instances toujours prêtes.

  • Compte de stockage hôte : Vous devez configurer le compte de stockage hôte par défaut de votre application de fonction pour utiliser 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, mettez-le également à jour pour qu’il soit redondant interzone.

Considérations

Comportements non-runtime : 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 les aspects de 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 les applications de plan Flex Consumption comme redondantes interzone, la plateforme répartit automatiquement les instances de plan entre plusieurs zones de la région sélectionnée, avec différentes règles pour les instances toujours prêtes et à la demande :

  • Les instances toujours prêtes sont réparties entre au moins deux zones à l’aide de la répartition circulaire.

    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. 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 résultent de volumes générant des événements lorsque l'application s'évolue au-delà du nombre d'instances toujours prêtes. Les instances à la demande sont réparties dans les zones de disponibilité sur la base du meilleur effort possible. La plateforme hiérarchise un déploiement plus rapide plutôt qu'une répartition uniforme entre les zones. La plateforme tente d'égaliser la distribution au fil du temps.

Lorsque vous configurez des plans d'application de fonctions Elastic Premium comme redondants entre zones, la plateforme répartit automatiquement les instances du plan dans 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 multipliées par le 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 meilleure répartition des zones, que fournissent les Groupes de machines virtuelles identiques Azure sous-jacents. Azure considère un plan Premium balanced lorsque chaque zone a le même nombre de machines virtuelles que les autres zones du plan, plus ou moins une machine virtuelle.

Coûts

Vous n’entraînez aucun coût supplémentaire lorsque vous activez la redondance de zone. La tarification d’un plan redondant interzone est identique à celle d’un plan à zone unique. Toutefois, l’activation de la redondance de zone affecte le nombre minimal d’instances dans votre plan.

Lorsque vous activez les 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.

Si vous activez des zones de disponibilité sur un plan qui a 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 connaître tous les détails concernant la tarification, consultez la tarification des fonctions.

Configurez la prise en charge des zones de disponibilité

  • Créez un nouveau plan de fonctions redondant interzone. Vous pouvez activer la redondance de zone lorsque vous créez un plan. Pour plus d’informations, consultez Créer une application de fonction redondante interzone.

  • Activez la redondance de zone sur un plan existant. Vous pouvez activer ou désactiver les zones de disponibilité pour les plans Elastic Premium existants. Les plans Elastic Premium ont un comportement de capacité spécifique qui diffère des plans Dédiés (App Service) et nécessitent des étapes de configuration supplémentaires. Pour obtenir des instructions détaillées, consultez Activer la redondance de zone sur un plan existant.

  • Créez un plan Functions à redondance de zone. Vous pouvez activer la redondance de zone lorsque vous créez un plan. Pour plus d’informations, consultez Créer une application de fonction redondante par zones.

  • Activez la redondance de zone sur un plan existant. Pour les plans Premium, vous pouvez activer la redondance de zone uniquement pendant la création du plan. Vous ne pouvez pas convertir un plan Premium existant en plan à redondance de zone. Au lieu de cela, migrez 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 redondantes interzone continuent de s’exécuter même lorsque les zones de la région subissent une panne.

Lors d’une panne de zone, Functions détecte les instances perdues et tente automatiquement de localiser ou de créer des instances de remplacement dans les zones saines. La plateforme effectue ce processus de manière optimale et ne garantit pas la réussite. Si votre charge de travail nécessite un nombre spécifique d’instances pour maintenir votre niveau de service attendu, envisagez de surprovisionner le nombre d’instances toujours prêtes. Le surprovisionnement permet à la solution de tolérer la perte de capacité et de continuer à fonctionner sans réduire les performances. Pour plus d’informations, consultez Gérer la capacité en surprovisionnant.

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 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 : Functions est un service de calcul sans état. Il n’existe donc aucune donnée à 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 des fonctions durables, passez en revue votre fournisseur de stockage pour savoir 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 lorsqu’un plan est redondant entre zones, que le compte de stockage hôte utilise ZRS et qu’il existe une panne de zone de disponibilité.

  • Détection et réponse : La plateforme Functions est chargée de détecter un échec dans une zone de disponibilité. Vous n’avez pas besoin de lancer un basculement 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, les demandes en cours qui se connectent à une instance de la zone de disponibilité défectueuse se terminent et doivent être retentées. Assurez-vous que vos applications sont préparées en suivant les instructions 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 Functions est un service sans état.

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

    Pour les fonctions durables, passez en revue votre fournisseur de stockage pour savoir 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 les instructions de gestion des erreurs temporaires.

  • Réacheminement du trafic : Functions détecte les instances perdues de cette zone et tente de trouver de nouvelles instances de remplacement. Une fois que 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 pendant une défaillance 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, Functions restaure automatiquement les instances de la zone de disponibilité, supprime les instances temporaires créées dans les autres zones de disponibilité et redirige le trafic entre vos instances comme normale.

Tester les pannes de zone

La plateforme 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. Azure gère entièrement cette fonctionnalité. Vous n'avez donc pas besoin de valider les processus d'échec de zone de disponibilité.

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

Functions est un service à région unique. Si la région devient indisponible, votre ressource Functions n’est pas disponible.

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

Pour éviter les interruptions de votre service pendant les pannes à l’échelle de la région, vous pouvez déployer de manière redondante les mêmes fonctions sur 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, tenez compte des modèles actifs-actifs et actifs-passifs . Les sections suivantes présentent 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

Dans un modèle actif-actif, les fonctions dans les deux régions exécutent activement et traitent des événements, soit de manière en double, soit en rotation. Utilisez un modèle actif-actif en combinaison avec Azure Front Door pour vos fonctions critiques déclenchées par HTTP, qui peuvent acheminer et répartir de manière circulaire les requêtes HTTP entre les fonctions exécutées 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 la supprime de la rotation et redirige uniquement le trafic vers les autres fonctions qui sont restées saines.

Diagramme qui montre un exemple d'architecture active-active. Azure Front Door achemine des requêtes entre les applications Functions dans différentes régions qui ont chacune leur 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 déclencheurs Azure Service Bus et Azure Event Hubs), utilisez un modèle actif-passif. Dans un modèle actif-passif, les instances de fonction s’exécutent dans la région qui reçoit des événements, tandis que les instances de la région secondaire restent inactives. Ce modèle garantit qu’une seule fonction traite chaque message, ce qui permet de maintenir la cohérence des données. Il permet également de basculer vers la région secondaire lors d’un sinistre tel qu’une panne régionale.

Considérez le basculement de l'application fonctionnelle avec les comportements de basculement des autres services que vous utilisez, tels que :

Prenons un exemple de topologie qui utilise un déclencheur Event Hubs, où votre namespace Event Hubs est configuré pour la géorécupération d'urgence. Dans ce cas, le modèle actif-passif nécessite les composants suivants :

  • Les espaces de noms Event Hubs sont déployés 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. Cette configuration crée également un alias que vous pouvez utiliser pour vous connecter à l’espace de noms Event Hubs et basculer l’alias du serveur principal vers le serveur secondaire sans modifier les informations de connexion.

  • Applications de fonction déployées dans la région primaire et secondaire. L’application dans la région secondaire reste inactive, car elle ne reçoit pas de messages.

  • Les déclencheurs de chaque fonction d'application utilisent la chaîne de connexion directe (nonalias) pour son espace de noms Event Hubs respectif.

  • Les éditeurs de l'espace de noms Event Hubs publient via la chaîne de connexion alias.

Diagramme montrant un exemple d’architecture active-passive. La géorécupération d’urgence Event Hubs s’étend sur plusieurs régions et des applications de fonction distinctes et des bases de données dans chaque région.

Avant le basculement, les éditeurs qui envoient des événements via l'alias partagé dirigent le trafic vers le hub d’événements principal. L’application de fonction principale écoute exclusivement le hub d’événements principal. L’application de fonction secondaire reste passive et inactive.

Lorsque le basculement commence, les éditeurs qui envoient des événements à l’alias partagé sont routés vers le hub d’événements secondaire. L’application de fonction secondaire devient active et se déclenche automatiquement. Le hub d’événements peut piloter l’ensemble du processus de basculement, et chaque application de fonction s’exécute uniquement lorsque son hub d’événements correspondant est actif.

Fonctions durables

Pour la reprise après sinistre multirégion pour les fonctions Azure durables, consultez Disaster recovery and geo-distribution in Azure durable functions.

Résilience à la maintenance du service

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 redémarrer ou rencontrer des interruptions temporaires. Assurez-vous que 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 ajoutent une couche supplémentaire de résilience si une instance ou une zone devient défectueuse pendant une mise à niveau.

  • Instances temporaires supplémentaires : 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. Utilisez cette approche pour valider et tester une instance hors production avant d’appliquer les mises à niveau à 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. Soyez prêt à restaurer une mise à jour en cas de problème. Contrôlez le déploiement des mises à jour pour réduire les interruptions des redémarrages d’applications.

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

Les emplacements de déploiement des functions permettent d'effectuer des déploiements de vos applications fonction sans temps d'arrêt. 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. Les redémarrages d’application provoquent des erreurs temporaires.

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.

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

Contenu connexe

  • Last updated on