Fiabilité dans Azure App Configuration

Azure App Configuration stocke et gère de manière centralisée les paramètres de configuration et les indicateurs de fonctionnalité des applications, qui remplacent les fichiers de configuration incorporés directement dans les applications. Avec cette approche, vous pouvez mettre à jour dynamiquement les valeurs de configuration, suivre l’historique des versions et conserver un enregistrement 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, reliability est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de 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’App Configuration et la façon dont 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 et de la configuration recommandées pour les charges de travail de production, consultez Générer des applications qui ont 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 Qu’est-ce que App Configuration ?

App Configuration est un service entièrement managé. Microsoft est responsable de l’exécution de la maintenance sur le service et du stockage et de la gestion de vos paramètres.

Lorsque vous développez des applications clientes qui se connectent à App Configuration, vous avez la possibilité d'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 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 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 des fournisseurs App Configuration, qui ont des fonctionnalités intégrées de nouvelle tentative et de mise en cache et d’autres fonctionnalités de résilience.

• 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 des fournisseurs App Configuration ou des kits sdk. L’en-tête retry-after-ms de la réponse fournit un temps d’attente suggéré en millisecondes avant que le client retente 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 FAQ App Configuration.

Résilience aux échecs de zone de disponibilité

Zones d’indisponibilité 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 App Configuration.

Configurez la prise en charge des zones de disponibilité

Microsoft configure automatiquement la redondance de zone pour un magasin lorsqu'il se trouve dans a 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 pas besoin d’effectuer d’action pour 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 devient disponible pour les magasins App Configuration dans la région.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque vous disposez d’un magasin App Configuration redondant interzone et que toutes les zones sont opérationnelles.

• 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 qu’il faut attendre lorsque vous disposez d’un magasin App Configuration redondant interzone et qu’il existe une panne dans l’une des zones.

• 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 d’intégrité 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 est récupérée, 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 App Configuration gère le routage du trafic, le basculement et la restauration de zone pour les stockages redondants interzone. Microsoft gère entièrement ce processus. 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

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 aux données de configuration de répliquer entre les régions en tant que fonctionnalité de service managé.

Géoréplication

Avec la géoréplication, vous pouvez répliquer un magasin 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

• Region support : Vous pouvez créer des réplicas dans n'importe quelle région Azure prise en charge par App Configuration, même si les régions ne sont pas Azure régions jumelées.

• 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épliques redondantes de zone : Toute réplique que vous créez dans une région où App Configuration prend en charge les zones de disponibilité est automatiquement redondante de zone.

• Azure Front Door : Pour activer la livraison de configuration géoredondante avec Azure Front Door, configurez les réplicas d'App Configuration en tant qu'origines au sein d’un groupe d’origines. Les origines correctement configurées sont requises pour Azure Front Door afin de permettre un routage basé sur l'état de santé, la répartition de charge, et le basculement automatique à travers 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’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 (Domain Name System). Tous les réplicas peuvent accepter les opérations de lecture et d’écriture.

  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. Cette approche 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 replication 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 responsable 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 avec la découverte automatique de réplicas ou une liste de plusieurs réplicas, votre application détecte automatiquement les défaillances et bascule vers un réplica sain.

  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 d’intégrité Service Health pour vous avertir des problèmes.

• Demandes actives : Les requêtes actives sur une instance de réplica dans la région peuvent échouer. 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 replication dans Azure Monitor.

• Temps d’arrêt attendu : Lorsqu’une réplique devient indisponible, elle reste hors connexion jusqu’à ce que sa région se rétablisse. 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 magasin de données et configurez le groupe d’origines avec plusieurs répliques comme origines de 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 restaurée, App Configuration synchronise le réplicat avec les autres réplicats 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 de configuration d'application recommencent automatiquement à utiliser le réplica.

Tester les défaillances régionales

Vous ne pouvez pas simuler un basculement de réplica directement dans la configuration de l'application. 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 hors production et observer la façon dont l’application répond.

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 l'Kit de développement logiciel (SDK) Azure. Dans .NET, utilisez la classe AzureEventSourceListener pour configurer un enregistreur d’événements. Pour plus d’informations, consultez 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 détecter un message similaire à l'exemple suivant :

   [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

Vous pouvez utiliser App Configuration pour exporter des données de configuration à partir d’un magasin et 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 vous activez la suppression réversible, vous pouvez récupérer les magasins et paramètres supprimés pendant une période de rétention configurable. Fonctions de suppression réversible comme une corbeille pour vos ressources App Configuration.

• Protection contre le vidage : Lorsque vous activez la protection contre le vidage, le service 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 rend la maintenance simple et transparente pour vous. Aucun temps d’arrêt n’est attendu pendant les événements de maintenance, sauf si Azure Service Health fournit un avis de maintenance planifié.

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 après 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 Azure services 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 ALS pour les services en ligne.

Contenu connexe

• Reliability in Azure
• Documentation de App Configuration