Fiabilité dans Azure App Configuration

Azure App Configuration stocke et gère de manière centralisée les paramètres de configuration des applications et les indicateurs de fonctionnalité, en remplaçant les fichiers de configuration incorporés directement dans les applications. Cette approche permet des mises à jour dynamiques, le contrôle de version des valeurs de configuration et le suivi historique des modifications de configuration au fil du temps. La disponibilité et la fiabilité d’App Configuration sont des considérations importantes, car le comportement de l’application peut dépendre directement de l’accès aux données de configuration au moment de l’exécution.

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 décrit l’architecture de fiabilité d’Azure App Configuration et explique comment le service est conçu pour rester disponible pendant les pannes temporaires, les défaillances de zone de disponibilité et les pannes de région.

Recommandations de déploiement de production pour la fiabilité

Pour la plupart des déploiements de production d’App Configuration, tenez compte des recommandations suivantes :

Pour obtenir la liste des pratiques recommandées et de la configuration des charges de travail de production, consultez Création d’applications avec une résilience élevée.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous déployez App Configuration, vous déployez un magasin. Votre magasin contient différents types de paramètres que votre application peut utiliser, notamment les clés et les valeurs et les indicateurs de fonctionnalité. Le service inclut également des fonctionnalités intégrées permettant d’organiser, de sécuriser, de gérer les versions et de déployer en toute sécurité les modifications de configuration dans les environnements. Pour plus d’informations, consultez Présentation d’Azure App Configuration ?

App Configuration est un service entièrement managé. Microsoft est responsable du stockage et de la gestion de vos paramètres, ainsi que de la maintenance sur le service.

Lorsque vous créez des applications clientes qui se connectent à Azure App Configuration, vous pouvez éventuellement utiliser App Configuration avec Azure Front Door (préversion) pour activer la mise en cache et l’accélération du trafic global. Cette configuration présente d’autres considérations relatives à la géoréplication, qui sont mises en surbrillance tout au long de cet article, le cas échéant.

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.

Lorsque vous utilisez Azure App Configuration, tenez compte des meilleures pratiques suivantes pour réduire l’effet des erreurs temporaires sur l’accès à la configuration, en particulier dans les chemins de code critiques.

• Fournisseurs de configuration : Utilisez les fournisseurs de configuration App Configuration, qui ont des fonctionnalités intégrées de nouvelle tentative et de mise en cache, ainsi que de nombreuses autres fonctionnalités de résilience.
• Kits de développement logiciel (SDK) Azure : Utilisez les kits SDK App Configuration si votre application doit envoyer des demandes d’écriture. Les SDK réessayent automatiquement en cas de réponses avec le code d’état HTTP 429 et d’autres erreurs temporaires.
• Logique de nouvelle tentative : Incluez la logique de nouvelle tentative dans les clients personnalisés si vous ne pouvez pas utiliser les fournisseurs App Configuration ou les SDK. L’en-tête retry-after-ms de la réponse fournit un temps d’attente suggéré en millisecondes avant de réessayer la requête.
• Cache: Paramètres de cache en mémoire lorsque cela est possible pour réduire les demandes directes vers votre magasin.

Pour obtenir d’autres conseils de configuration d’application, consultez le FORUM aux questions sur Azure App Configuration.

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.

App Configuration fournit automatiquement une redondance de zone dans les régions qui prennent en charge les zones de disponibilité. Cette redondance offre une haute disponibilité au sein d’une région sans nécessiter de configuration spécifique.

Lorsqu’une zone de disponibilité devient indisponible, App Configuration redirige automatiquement vos demandes vers d’autres zones de disponibilité saines pour garantir la haute disponibilité.

Spécifications

Prise en charge de la région : Les magasins déployés dans les régions suivantes sont automatiquement redondants interzone :

Coûts

Il n’existe aucun coût supplémentaire pour la redondance de zone pour Azure App Configuration.

Configurez la prise en charge des zones de disponibilité

Microsoft active automatiquement la redondance de zone pour un magasin lorsqu’il se trouve dans une région qui prend en charge les zones de disponibilité.

Si App Configuration ajoute la prise en charge des zones de disponibilité à une région existante, vous n’avez rien à faire pour commencer à bénéficier de la prise en charge de la zone de disponibilité. Votre magasin bénéficie de la prise en charge de la zone de disponibilité qui est devenue disponible pour les magasins App Configuration dans la région.

Comportement lorsque toutes les zones sont saines

Lorsqu’un magasin se trouve dans une région qui prend en charge la redondance de zone et que toutes les zones de disponibilité sont opérationnelles, vous pouvez vous attendre au comportement suivant :

• Opération interzone : App Configuration gère automatiquement le routage du trafic entre les zones de disponibilité. Pendant les opérations normales, il distribue en toute transparence les requêtes entre les zones.

• Réplication des données interzones : Dans les régions qui prennent en charge les zones, App Configuration réplique de façon synchrone les données entre les zones de disponibilité. Cette réplication garantit que vos paramètres restent cohérents et disponibles même si une zone devient indisponible.

Comportement lors d’une défaillance de zone

Cette section décrit ce qui doit être attendu lorsqu’un magasin se trouve dans une région qui prend en charge la redondance de zone et qu’une zone de disponibilité n’est pas disponible :

• Détection et réponse : Le service App Configuration détecte les défaillances de zone et y répond automatiquement. Vous n’avez rien à faire pendant une défaillance de zone.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez 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 : Lors d’une défaillance de zone, la zone affectée peut ne pas gérer les demandes en cours d’exécution, ce qui nécessite que les applications clientes les réessayent. Les applications clientes doivent suivre les pratiques de gestion des erreurs temporaires pour s’assurer qu’elles peuvent réessayer les demandes si une défaillance de zone se produit.

• Perte de données attendue : Aucune perte de données n’est attendue lors d’une défaillance de zone en raison de la réplication synchrone entre les zones.

• Temps d’arrêt attendu : Aucun temps d’arrêt n’est attendu.

• Redistribution: App Configuration redirige automatiquement le trafic de la zone affectée vers des zones saines sans nécessiter d’intervention du client.

Récupération de la zone

Lorsqu’une zone précédemment indisponible récupère, App Configuration restaure automatiquement les opérations normales dans toutes les zones de disponibilité. Vous n’avez pas besoin d’effectuer d’action pour récupérer d'une défaillance de zone.

Tester les pannes de zone

La plateforme Azure App Configuration gère le routage du trafic, le basculement et la récupération de zone pour les magasins redondants interzone. Étant donné que ce processus est entièrement géré par Microsoft, 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 App Configuration fournit des fonctionnalités de géoréplication natives pour prendre en charge la résilience pendant les pannes de région. La géoréplication permet la réplication des données de configuration entre les régions en tant que fonctionnalité de service managé.

Géoréplication

La géoréplication permet à un magasin d’être répliqué dans plusieurs régions Azure. Chaque magasin peut avoir plusieurs réplicas dans différentes régions. Le magasin d’origine est également un réplica. Cette fonctionnalité permet de protéger les applications contre les interruptions à l’échelle de la région.

Spécifications

• Prise en charge de la région : Vous pouvez créer des réplicas dans n’importe quelle région Azure prise en charge par Azure App Configuration, même si les régions ne sont pas associées à Azure.

• Niveau: Le magasin de configuration doit utiliser un niveau pris en charge pour activer la géoréplication. Pour plus d’informations, consultez Activer la géoréplication.

Considérations

Lorsque vous activez la géoréplication, tenez compte des facteurs suivants :

• Réplicas redondants interzone : Tout réplica que vous créez dans une région dans laquelle App Configuration prend en charge les zones de disponibilité est automatiquement redondant interzone.

• Azure Front Door : Pour activer la livraison de configurations géoredondante avec Azure Front Door, configurez les réplicas App Configuration en tant qu’origines dans un groupe d’origines. La configuration d’origine correcte permet à Azure Front Door de gérer le routage basé sur l’intégrité, l’équilibrage de charge et le basculement automatique entre les régions. Pour plus d’informations, consultez Les méthodes de routage du trafic vers l’origine.

Coûts

Chaque région géorépliquée est facturée séparément en fonction de la tarification du niveau et de la région respectifs. Aucun frais de sortie de données ne s’applique à la réplication interrégion. Pour plus d’informations sur la tarification, consultez la tarification d’Azure App Configuration.

Configurer la prise en charge multirégion

Pour configurer la réplication pour un magasin de configuration nouvellement créé, consultez Activer la géoréplication.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsque vous configurez un magasin App Configuration pour la géoréplication et que toutes les régions sont opérationnelles.

• Opération interzone : Chaque réplica est adressable individuellement et possède son propre nom DNS. Tous les réplicas peuvent accepter les opérations de lecture et d’écriture.

  Azure App Configuration ne route pas automatiquement le trafic entre les régions. Lorsque vous utilisez les fournisseurs App Configuration, votre application peut éventuellement utiliser la découverte automatique des répliques. Vous pouvez également spécifier une liste hiérarchisée de réplicas, et App Configuration sélectionne le premier réplica sain. Cela permet à votre application de contrôler le réplica qu’elle utilise.

  Note

  Si vous utilisez Azure Front Door, le comportement de routage du trafic est différent. Pour plus d’informations, consultez Basculement et équilibrage de charge.

• Réplication des données interzones : Les données sont répliquées de manière asynchrone et sont finalement cohérentes. Vous pouvez utiliser la métrique de latence de réplication dans Azure Monitor pour surveiller la latence de réplication actuelle entre les réplicas.

Comportement lors d’une défaillance de région

Cette section décrit à quoi s'attendre lorsque vous configurez un magasin App-Configuration pour la géoréplication, et qu'il y a une panne dans l'une des régions de réplication.

• Détection et réponse : Microsoft est chargé de détecter les défaillances de région ou de réplica et de lancer des processus de récupération.

  Lorsque vous utilisez des fournisseurs de configuration App Configuration et procédez à une découverte automatique de répliques ou que vous avez une liste de plusieurs répliques, votre application bascule automatiquement vers une autre réplique saine.

  Si vous n’utilisez pas de fournisseurs de configuration d'application, vous êtes responsable du basculement de votre application vers une réplique saine.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Les requêtes actives sur un réplica dans la région peuvent être supprimées. Les applications clientes doivent effectuer à nouveau les requêtes sur une autre réplique.

• Perte de données attendue : Si un réplica échoue, les modifications récentes apportées à ce réplica peuvent ne pas encore être répliquées vers d’autres réplicas. Ces modifications peuvent rester indisponibles tant que le réplica n’est pas restauré. Pour estimer la perte de données potentielle, surveillez la métrique de latence de réplication dans Azure Monitor.

• Temps d’arrêt attendu : Lorsqu’un réplica devient indisponible, il reste hors connexion jusqu’à ce que sa région soit rétablie. D’autres réplicas continuent de gérer les demandes. Les applications peuvent rencontrer une courte interruption le temps qu'elles détectent un échec et basculent vers une réplique saine. La durée dépend de la rapidité avec laquelle chaque application effectue cette détection et ce basculement.

• Redistribution: Les applications doivent acheminer le trafic vers un réplica sain lorsqu’une défaillance se produit.

  Si vous utilisez les fournisseurs de configuration d'App Configuration, ces derniers gèrent automatiquement le choix et le basculement des réplicas.

  Si vous placez Azure Front Door devant votre stockage de données et configurez le groupe d’origines avec plusieurs répliques comme origines pour le basculement, Azure Front Door réachemine automatiquement les requêtes vers une réplique saine.

Récupération de région

Une fois la région récupérée, App Configuration rétablit la synchronisation du réplica avec les autres réplicas sans votre intervention.

Vous êtes responsable de la reconfiguration de votre application pour router le trafic vers l’instance de région récupérée. Les applications qui utilisent des fournisseurs App Configuration recommencent automatiquement à utiliser le réplica.

Tester les défaillances régionales

Vous ne pouvez pas simuler directement un basculement de réplica dans App Configuration aujourd’hui. Toutefois, étant donné que les applications contrôlent la sélection des réplicas, vous pouvez tester le comportement en cas de basculement en contraignant l'application à passer à un état où elle doit changer de réplica.

Pour valider le comportement de basculement du réplica de votre application, vous pouvez introduire une panne de connectivité contrôlée dans un environnement de non-production et observer comment l'application réagit.

Une approche consiste à utiliser votre ordinateur local ou un autre environnement dans lequel vous disposez d’un accès administratif. Suivez ces étapes :

1. Activez la journalisation détaillée pour le Kit de développement logiciel (SDK) Azure. Dans .NET, utilisez la AzureEventSourceListener classe pour configurer un enregistreur d’événements. Pour plus d’informations, consultez Tutoriel : Utiliser la configuration dynamique dans une application .NET - Journalisation et surveillance.

2. Configurez manuellement votre hosts fichier afin que les demandes adressées à votre magasin App Configuration soient acheminées vers une adresse IP qui ne peut pas les recevoir, par exemple 127.0.0.1 (localhost).

   Avertissement

   Cette étape bloque efficacement l’accès de votre ordinateur à votre magasin App Configuration. Suivez uniquement ces étapes dans un environnement hors production.

3. Surveillez les journaux pour un message similaire à celui-ci :

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   Ce message indique que l’application a correctement basculé pour utiliser un autre réplica de votre magasin.

4. Une fois le test terminé, annulez les modifications apportées à votre hosts fichier.

Sauvegarde et restauration

Azure App Configuration vous permet d’exporter des données de configuration à partir d’un magasin et de les utiliser dans le cadre d’une stratégie de sauvegarde plus large.

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 Que sont la redondance, la réplication et la sauvegarde ?.

Résilience à la suppression accidentelle

App Configuration fournit deux fonctionnalités de récupération clés pour empêcher la suppression accidentelle ou malveillante :

• Suppression réversible : Lorsque cette option est activée, la suppression réversible vous permet de récupérer les magasins et paramètres supprimés pendant une période de rétention configurable. Pensez à la suppression temporaire comme à une corbeille pour vos ressources App Configuration.

• Protection contre le vidage : Lorsqu’elle est activée, la protection contre le vidage empêche la suppression définitive de votre magasin et de ses paramètres jusqu’à ce que la période de rétention se soit écoulée. Cette protection empêche les acteurs malveillants de détruire définitivement vos paramètres.

Utilisez les deux fonctionnalités pour les environnements de production. Pour plus d’informations, consultez Suppression douce et protection contre la purge.

Résilience à la maintenance du service

Microsoft effectue régulièrement des mises à jour de service et d’autres maintenances. Le service gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d’arrêt n’est attendu pendant les événements de maintenance, sauf si vous avez été informé par le biais de la maintenance planifiée d’Azure Service Health.

Résilience aux problèmes de configuration

Des modifications de configuration incorrectes ou accidentelles peuvent entraîner un temps d’arrêt de l’application. Utilisez des instantanés de configuration pour déployer en toute sécurité les modifications apportées à la configuration. Surveillez l’intégrité de votre application en suivant les modifications de configuration et revenez à la dernière capture instantanée de configuration connue si les modifications introduisent un problème.

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 contrats SLA pour les services en ligne.

Contenu connexe

• Fiabilité dans Azure
• Documentation de Azure App Configuration