Fiabilité dans Azure Notification Hubs

Azure Notification Hubs vous aide à gérer les notifications Push sur plusieurs systèmes de notification de plateforme (PNS), tels que le service de notification Push Apple (APN), Firebase Cloud Messaging (FCM) et Windows Service de notification Push (WNS).

Lorsque vous utilisez Azure, la fiabilité 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 explique comment rendre Notification Hubs résilient à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité, les défaillances à l’échelle de la région et la maintenance du service. Il décrit également les options de sauvegarde et de restauration et les informations clés sur le contrat de niveau de service Notification Hubs (SLA).

Recommandations concernant le déploiement de production

Pour les charges de travail de production, suivez ces recommandations :

Vue d’ensemble de l’architecture de fiabilité

Azure Notification Hubs est organisé autour des espaces de noms et des hubs de notification. Un espace de noms est une limite de gestion qui contient un ou plusieurs hubs. Les hubs représentent des points de terminaison pour une application. Les appareils s’inscrivent auprès de ces points de terminaison à l’aide d’inscriptions ou d’installations, ce qui permet au service d’envoyer des notifications Push aux appareils. Pour plus d’informations, consultez Gestion des inscriptions.

Notification Hubs envoie des notifications Push à des systèmes de notification de plateforme (PNS), tels qu’Apple Push Notification Service (APNs) et Firebase Cloud Messaging (FCM). La remise de notification de bout en bout dépend de la disponibilité des hubs de notification et du comportement des fournisseurs PNS en aval.

Pour la planification de la fiabilité, il est important de faire la distinction entre les types de données suivants que Notification Hubs gère :

• Métadonnées : Configuration de l’espace de noms et du hub, y compris les informations de connexion et la configuration de la récupération d’urgence.
• Données d’enregistrement : Enregistrements et installations d’appareils qui associent les utilisateurs et les appareils à des balises et à des modèles.

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, voir Recommandations concernant le traitement des pannes transitoires.

Notification Hubs gère automatiquement les erreurs temporaires qui se produisent lors de la connexion à un PNS. Toutefois, vous êtes responsable de la gestion des défaillances temporaires lorsque les appareils de vos services ou utilisateurs interagissent avec Notification Hubs. Des défaillances temporaires peuvent se produire pendant les opérations d’inscription, les opérations d’envoi de notification et les opérations de gestion. Suivez ces instructions :

• Inscriptions et installations : Vos applications sur les appareils doivent réessayer les opérations d’inscription et d’installation qui échouent en raison d’erreurs temporaires. les kits sdk Microsoft fournis gèrent automatiquement les nouvelles tentatives. Si vous ne pouvez pas utiliser les SDK fournis, implémentez un mécanisme de nouvelle tentative avec temporisation exponentielle et gigue, et rendez les opérations d’enregistrement idempotentes lorsque cela est possible.

  La création ou la mise à jour d’une installation est idempotente. Vous pouvez donc réessayer l’opération en toute sécurité. Si possible, utilisez des installations plutôt que des enregistrements.

• Notifications envoyées et opérations de gestion : Utilisez un kit SDK fourni par Microsoft pour envoyer des notifications Push et effectuer des opérations de gestion. Ces kits SDK réessayent automatiquement lorsque des erreurs temporaires se produisent.

  Si vous ne pouvez pas utiliser les SDK fournis, implémentez un mécanisme de nouvelle tentative avec une temporisation exponentielle et une gigue, et rendez les opérations d’envoi de notifications idempotentes dans la mesure du possible.

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.

Dans les régions qui prennent en charge les zones de disponibilité, les espaces de noms Notification Hubs prennent en charge une configuration redondante interzone. Notification Hubs active automatiquement la redondance de zone pour tous les espaces de noms dans certaines régions. Lorsque la redondance de zone est activée, Microsoft réplique à la fois les métadonnées et les données d’inscription dans toutes les zones de disponibilité de la région.

Requirements

• Prise en charge de la région :

  Notification Hubs active automatiquement la redondance de zone pour tous les espaces de noms dans les régions suivantes. Vous ne pouvez pas désactiver la redondance de zone dans ces régions :

  Europe	Moyen-Orient	Africa	Asie-Pacifique
  France Centrale	Qatar Central	Afrique du Sud Nord	Chine Nord 3
  Italy North			Korea Central
  Norvège Est
  Pologne Centre
  Suède Centre
  Suisse Nord

  Dans d’autres régions qui prennent en charge Notification Hubs et qui ont des zones de disponibilité, la redondance de zone est facultative. Vous ne pouvez l’activer que lorsque vous créez un espace de noms.

• Niveaux pris en charge : Vous pouvez utiliser des zones de disponibilité avec tous les niveaux de Notification Hubs.

Cost

La redondance de zone entraîne des frais supplémentaires en plus du prix du palier tarifaire. Pour plus d’informations, consultez la tarification de Notification Hubs.

Configurez la prise en charge des zones de disponibilité

• Créez un espace de noms redondant interzone : Le processus de création d’un espace de noms redondant interzone dépend de la région que vous utilisez :

  • Dans les régions où Notification Hubs active automatiquement la redondance de zone, vous n’avez pas besoin de la configurer.

    Important

    Dans ces régions, Notification Hubs crée toujours des espaces de noms avec redondance de zone activée, même si un déploiement basé sur le code, tel qu’un fichier Bicep ou un modèle Azure Resource Manager, spécifie que la redondance de zone est désactivée.

    Si vous ne souhaitez pas d’espace de noms redondant interzone, créez-le dans une région qui prend en charge la redondance de zone facultative.

  • Dans les régions où la redondance de zone est facultative, vous pouvez l’activer uniquement lorsque vous créez un espace de noms. Pour savoir comment configurer un nouvel espace de noms avec redondance de zone, consultez Créer un hub de notification Azure dans le portail Azure.

• Rendez une zone d’espace de noms existante redondante : Notification Hubs ne prend pas en charge la migration sur place d’un espace de noms existant vers la prise en charge de la zone de disponibilité. Vous devez déployer un nouvel espace de noms et déplacer vos inscriptions vers cet espace de noms. Suivez les instructions de Déplacer des ressources entre Azure régions, qui s’applique également si vous déployez le nouvel espace de noms dans la même région.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qui doit être attendu lorsque vous configurez un espace de noms Notification Hubs pour la redondance de zone et que toutes les zones sont opérationnelles.

• Opération interzone : Notification Hubs distribue et traite automatiquement les requêtes à l’aide de l’infrastructure dans n’importe quelle zone de la région.

• Réplication des données interzones : Les données d’inscription et les métadonnées sont répliquées de manière synchrone sur toutes les zones de la région spécifiée.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque vous configurez un espace de noms Notification Hubs pour la redondance de zone et qu’il existe une panne dans l’une des zones.

• Détection et réponse : Microsoft détecte les défaillances de zone et gère le basculement au sein de la région. Vous n’avez pas besoin de lancer le basculement.

• 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 : Les opérations de gestion en cours de vol, les inscriptions d’appareils et les nouvelles demandes d’envoi de notifications peuvent échouer pendant le basculement. Vos applications doivent réessayer les opérations ayant échoué en suivant les instructions de gestion des erreurs temporaires.

• Perte de données attendue : La perte de données n’est pas attendue lors d’une panne à zone unique, car Notification Hubs réplique de manière synchrone les données d’espace de noms et de hub et de configuration et d’inscription entre les zones de disponibilité.

  Cette réplication n’est pas une sauvegarde. Sous le modèle de responsabilité partagée, vous êtes responsable de la sauvegarde des données d’inscription et d’installation. Pour plus d’informations, consultez Sauvegarde et restauration.

• Temps d’arrêt attendu : Une brève interruption de service est possible lorsque Microsoft redirige le trafic. Suivez les instructions de gestion des erreurs temporaires pour préparer vos applications à ces interruptions.

• Redistribution : Le service redirige automatiquement les requêtes vers des zones saines.

Récupération de la zone

Lorsque la zone affectée récupère, vous n’avez pas besoin d’effectuer d’action. Microsoft restaure et rééquilibrée l’infrastructure Notification Hubs pour utiliser la zone récupérée.

Tester les pannes de zone

Vous ne pouvez pas déclencher directement un basculement vers une autre zone pour Notification Hubs. Pour tester le comportement de votre charge de travail, exécutez des tests de résilience portant sur les tentatives de nouvelle exécution, l’idempotence et les défaillances des dépendances dans des environnements de non-production. Vous pouvez également utiliser Azure Chaos Studio pour tester les composants d’application environnants.

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

Notification Hubs fournit une récupération d’urgence des métadonnées en répliquant les métadonnées d’espace de noms entre les régions, mais elle ne réplique pas les données d’inscription d’appareil. Cette fonctionnalité nécessite une intervention manuelle lors d’une panne de région et implique un temps d’arrêt pour votre hub de notification.

Si vous devez réduire les temps d’arrêt et l’intervention manuelle pendant le basculement, envisagez d’utiliser une solution multirégion personnalisée.

métadonnées gérées par Microsoft pour la géoreprise d’activité après sinistre

Notification Hubs prend en charge la récupération d’urgence des métadonnées gérées par Microsoft vers une région de Azure secondaire. Si votre région primaire a une région jumelée, vous pouvez sélectionner cette région jumelée. Quel que soit l’état de jumelage de votre région primaire, vous pouvez également choisir une région secondaire dans une liste de régions de récupération flexibles. Notification Hubs réplique ensuite les métadonnées d’espace de noms, telles que le nom de l’espace de noms, les chaînes de connexion et d’autres informations critiques.

Microsoft est responsable de la déclaration d’un sinistre et du lancement du basculement. Lorsque cela se produit, Microsoft crée un nouvel espace de noms dans la région secondaire. Comme il utilise les métadonnées de la région primaire, les applications peuvent se connecter à cet espace de noms à l’aide du nom d’espace de noms existant, de la chaîne de connexion et des noms de hub existants.

Requirements

• Prise en charge de la région : Dans les régions Azure jumelées, votre espace de noms peut utiliser la Azure région jumelée comme région secondaire.

  Si votre espace de noms se trouve dans une région non souhaitée ou si vous souhaitez répliquer des données dans une autre région, vous pouvez sélectionner l’une des régions de récupération flexibles suivantes comme région secondaire :

  Americas	Europe	Africa	Asie-Pacifique
  Brazil South	Europe Nord	Afrique du Sud Nord	Australia East
  Ouest des États-Unis 2			Asie du Sud-Est

• Niveaux pris en charge : Les options de reprise d’activité après sinistre des métadonnées sont disponibles dans tous les niveaux de Notification Hubs.

Cost

Notification Hubs ne facture pas de frais supplémentaires pour configurer ou utiliser la géo-récupération d’urgence des métadonnées. Toutefois, vous payez pour la bande passante interrégion utilisée pour répliquer les métadonnées. Pour plus d’informations sur la tarification, consultez tarification de la bande passante et tarification de Notification Hubs.

Configurer la prise en charge de la multirégion

• Activez la géorécupération d’urgence des métadonnées pour un nouvel espace de noms : Suivez la procédure de création d’un hub de notification Azure dans le portail Azure. Sélectionnez la configuration de récupération d’urgence lorsque vous créez l’espace de noms.

• Activez ou désactivez la géo-récupération d’urgence des métadonnées pour un espace de noms existant : Suivez la procédure d’activation de la récupération d’urgence pour un espace de noms Azure Notification Hubs existant.

• Sauvegardez vos données d’inscription d’appareil : Consultez Exporter et importer des inscriptions Azure Notification Hubs en bloc.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez un espace de noms Notification Hubs pour la géorécupération d’urgence des métadonnées, et que vos régions primaires et secondaires sont opérationnelles.

• Opération interrégion : La région primaire répond à toutes les demandes. La région secondaire ne répond pas aux requêtes, sauf en cas de basculement.

• Réplication des données interrégions : Les métadonnées, telles que le nom de l’espace de noms, la configuration du hub, les chaînes de connexion et d’autres informations critiques, sont répliquées de manière asynchrone entre les régions. Les données d’inscription ne sont pas répliquées. Vous êtes responsable de l’exporter régulièrement afin de maintenir une sauvegarde.

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

Cette section décrit à quoi s’attendre lorsque vous configurez un espace de noms Notification Hubs pour la géo-récupération d’urgence des métadonnées et qu’une panne survient dans la région primaire.

• Détection et réponse : Microsoft est responsable de la détection de l’échec de la région et de décider s’il faut déclencher le basculement vers la région secondaire configurée.

• 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 demandes en cours d’accès à l’espace de noms dans la région primaire peuvent échouer lorsque la région est hors connexion. Les clients doivent réessayer une fois le basculement terminé.

• Perte de données attendue : Les métadonnées sont conservées. Les données d’inscription ne sont pas sauvegardées automatiquement, mais vous pouvez les sauvegarder vous-même. Pour plus d’informations, consultez Exporter et importer des inscriptions Azure Notification Hubs en bloc. Si ce n’est pas le cas, les données d’inscription ne sont pas disponibles tant que la région primaire n’est pas récupérée.

• Temps d’arrêt prévu : Il faut un certain temps pour que Microsoft déclenche le basculement des métadonnées, puis pour que le basculement se termine. Bien que le temps puisse varier, il faut généralement plusieurs heures.

  Une fois le basculement terminé, il vous incombe de restaurer toute sauvegarde des données d’inscription.

• Redistribution : Après le basculement, les requêtes sont acheminées vers un espace de noms dans la région secondaire qui utilise les données répliquées de la région primaire. Une fois le basculement terminé, les clients se connectent automatiquement à l’espace de noms dans la région secondaire.

Récupération de région

Si la région primaire récupère, il peut être possible de restaurer l’espace de noms principal dans la région primaire. L’espace de noms principal conserverait les données d’inscription avant la panne. Ce serait un processus manuel et Microsoft communiqueriez avec vous pour expliquer comment cela fonctionne.

Une fois la région primaire récupérée, vous devez :

• Validez l’état de votre espace de noms et de ses données.
• Déterminez s’il faut synchroniser les modifications récentes des données d’inscription de la région secondaire vers la région primaire.

Tester les défaillances régionales

Vous ne pouvez pas initier un basculement géographique. Toutefois, vous devez tester vos propres procédures de récupération d’urgence. Vérifiez que les inscriptions sont sauvegardées et que vous pouvez les restaurer dans un nouvel espace de noms.

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

La reprise d’activité géographique des métadonnées gérée par Microsoft réplique uniquement les métadonnées. La fonctionnalité peut récupérer ces métadonnées dans un espace de noms secondaire, mais vous êtes responsable de l’importation d’inscriptions d’appareils dans cet espace de noms afin que votre application puisse continuer à fonctionner. Cette approche nécessite une intervention manuelle lors d’un sinistre et implique un temps d’arrêt.

Si vos objectifs de récupération nécessitent moins de temps d’arrêt ou d’intervention manuelle, vous pouvez implémenter une solution multirégion active active personnalisée. Déployez un deuxième espace de noms Notification Hubs vers une autre région Azure à l’avance.

• Basculement : Étant donné que le deuxième espace de noms est une ressource active, vous pouvez mettre en place une logique pour détecter une défaillance dans une région et basculer vers cet espace de noms.

• Synchronisation : Pour conserver un deuxième hub de notification synchronisé avec le hub de notification principal, utilisez l’une des options suivantes :

  • Pour les installations : Utilisez un back-end d’application qui crée et met à jour simultanément des installations dans les deux hubs de notification. Les installations vous permettent de spécifier votre propre identificateur d’appareil unique, qui prend en charge ce scénario de réplication. Pour plus d’informations, consultez l’exemple RedondantHub.

  • Pour les inscriptions : Utilisez un back-end d’application qui exporte régulièrement les inscriptions à partir du hub de notification principal en tant que sauvegarde et les importe en bloc dans le hub de notification secondaire. Pour plus d’informations, consultez Exporter et importer des inscriptions Azure Notification Hubs en bloc.

  Sinon, si vous n’avez pas de back-end, configurez votre application pour créer des installations dans les deux hubs lorsque l’application démarre sur les appareils cibles. Les appareils créent de nouvelles inscriptions dans les deux hubs de notification. Finalement, le hub de notification secondaire a tous les appareils actifs inscrits.

• Inscriptions et installations expirées : Le hub de notification secondaire a peut-être expiré des inscriptions et des installations. Lorsqu’un push est effectué vers un handle expiré, Notification Hubs nettoie automatiquement l’enregistrement d’inscription ou d’installation associé sur le hub de notification, en fonction de la réponse reçue du serveur PNS. Vous pouvez nettoyer les enregistrements expirés de la solution de sauvegarde de votre choix en ajoutant une logique personnalisée qui traite les commentaires de chaque envoi et supprime les inscriptions et installations expirées.

• Applications non ouvertes : Il y a une période pendant laquelle les appareils avec des applications non ouvertes ne reçoivent pas de notifications.

• Coût : Si vous utilisez votre propre hub secondaire pour protéger les données d’inscription, ce hub entraîne des frais de service normaux. De même, si vous déployez d’autres ressources Azure dans votre région secondaire pour prendre en charge votre récupération, vous payez ceux-ci à des tarifs de service normaux.

Sauvegarde et restauration

Notification Hubs ne fournit pas de fonctionnalité de sauvegarde et de restauration intégrée unique pour toutes les données stockées dans votre espace de noms. Vous êtes responsable de la combinaison des approches suivantes :

• Utilisez l’infrastructure en tant que code (IaC), comme Bicep, pour définir votre espace de noms, votre hub et votre configuration de stratégie. Stockez ces définitions dans le contrôle de code source afin de pouvoir redéployer les ressources si nécessaire.
• Sauvegardez vos données d’inscription de votre appareil en exportant en masse les inscriptions Azure Notification Hubs.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure 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 prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.

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.

Pour Notification Hubs, le contrat de niveau de service (SLA) de disponibilité s’applique aux espaces de noms qui utilisent les niveaux Basic et Standard.

Contenu connexe

• Fiabilité dans Azure