Fiabilité dans Azure SignalR Service

Azure SignalR Service est un service entièrement géré qui permet une communication bidirectionnelle en temps réel dans les applications web et mobiles. Il extrait le mécanisme de transport sous-jacent. Lorsque webSockets sont disponibles, le service les utilise. Quand ce n’est pas le cas, il revient aux événements envoyés par le serveur ou à une interrogation longue. Cette abstraction signifie que votre code client et serveur peut communiquer en temps réel sans être lié à un protocole de transport spécifique.

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 Azure SignalR Service résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance des services. Il met également en évidence les informations clés relatives au contrat de niveau de service (SLA) Azure SignalR Service.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

La ressource que vous créez est une ressource SignalR Service. Vous configurez une ressource avec un certain nombre d’unités, qui représente la capacité de la ressource, y compris le nombre maximal de connexions simultanées. Pour plus d’informations, consultez le guide Performance pour Azure SignalR Service.

Azure SignalR Service prend en charge deux modes de service . En mode par défaut, vos serveurs d’applications se connectent à la ressource Azure SignalR Service et contiennent votre logique hub. En mode serverless, le service s'intègre à Azure Functions et Functions joue le rôle de gestionnaires de messages pilotés par les événements afin de ne pas gérer directement les serveurs d'applications. Pour plus d’informations, consultez Mode de service dans Azure SignalR Service.

Une ressource SignalR Service a un point de terminaison global unique similaire à contoso.service.signalr.net. Les clients établissent des connexions à ce point de terminaison. Les serveurs d’applications se connectent au même point de terminaison pour envoyer des messages et recevoir des événements des clients.

Architecture physique

Azure SignalR Service gère l’état de connexion et le routage des messages sur un ensemble de ressources de calcul. Microsoft gère l’infrastructure sous-jacente. Vous ne voyez pas ou n’interagissez pas directement avec des machines virtuelles individuelles que le service utilise ou d’autres composants d’infrastructure.

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.

Azure SignalR Service utilise des connexions de longue durée entre les clients, les serveurs d’applications et le service. Ces connexions peuvent être supprimées en raison d’erreurs temporaires telles que l’instabilité du réseau, les reconfigurations de l’équilibreur de charge ou les suspensions d’onglets du navigateur. Concevez vos applications clientes et serveurs d’applications pour gérer les suppressions de connexion et reconnecter automatiquement.

Les kits de développement logiciel (SDK) Azure SignalR Service incluent la gestion intégrée de la reconnexion pour les connexions de serveur au service. La reconnexion côté client dépend de la bibliothèque cliente que vous utilisez. Les clients SignalR ASP.NET Core prennent en charge la reconnexion avec conservation d'état, ce qui permet au client de reprendre sa connexion précédente sans perdre l'état s'il se reconnecte rapidement à l'aide du même ID de connexion. Si la reconnexion entraîne un nouvel ID de connexion, par exemple, après une panne plus longue, le service traite le client comme une nouvelle connexion. Dans ce cas, le client doit rejoindre tous les groupes qu’il était précédemment dans et restaurer n’importe quel état de session.

Pour obtenir des instructions détaillées sur la conception de votre application pour gérer les déconnexions et les reconnexions des clients, consultez Comprendre les déconnexions et les reconnexions des clients dans le service Azure SignalR.

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.

Azure SignalR Service prend en charge les déploiements redondants interzone dans le niveau Premium. Lorsque vous créez ou mettez à niveau vers une ressource de niveau Premium dans une région qui prend en charge les zones de disponibilité, Azure SignalR Service distribue automatiquement sa capacité de calcul sur toutes les zones de disponibilité de la région. En cas d’échec d’une zone de disponibilité, Azure SignalR Service achemine de nouvelles connexions vers des instances dans les zones saines restantes.

Exigences

• Prise en charge de la région : La redondance de zone est prise en charge dans la plupart des régions où ces deux conditions s’appliquent :

  • Azure SignalR Service est disponible. Pour obtenir la liste des régions où le service est disponible, consultez Disponibilité des produits par région.
  • La région prend en charge les zones de disponibilité. Pour obtenir la liste des régions avec des zones de disponibilité, consultez Azure liste des régions.

  Toutefois, le Japon Ouest ne prend actuellement pas en charge la redondance de zone pour Azure SignalR Service.

• Niveau: La redondance de zone est disponible sur le niveau Premium.

Coûts

La redondance de zone n’ajoute pas de coût et vous payez le taux de niveau Premium standard. Pour plus d’informations, consultez Azure SignalR Service tarification.

Configurez la prise en charge des zones de disponibilité

La redondance de zone ne nécessite aucune configuration au-delà de la sélection du niveau Premium. Elle est automatiquement activée dans les deux cas suivants :

• Créez une ressource SignalR Service redondante interzone. Sélectionnez une référence SKU de niveau Premium lorsque vous créez la ressource. Pour plus d’informations, consultez les guides de démarrage rapide, tels que Quickstart : Create a chat room by using SignalR Service.

• Mettez à niveau une ressource existante vers le niveau Premium. La redondance de zone est automatiquement activée lorsque vous mettez à niveau une ressource existante vers une référence SKU de niveau Premium. La mise à niveau de Standard vers Premium n’entraîne pas de temps d’arrêt du service. Pour plus d’informations, consultez Changez votre niveau Azure SignalR Service.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez une ressource Azure SignalR Service pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Opération interzone : Azure SignalR Service gère automatiquement la façon dont les connexions et les opérations sont distribuées entre les zones de disponibilité. L’infrastructure dans plusieurs zones traite le trafic dans un modèle actif-actif. Vous n’avez pas besoin de configurer quoi que ce soit pour tirer parti de ce comportement. Le service achemine automatiquement les messages entre les instances entre les zones. Par conséquent, un message envoyé par un client dans une zone est remis aux clients connectés dans n’importe quelle autre zone.

• Réplication des données interzones : Azure SignalR Service ne conserve pas les données client. Il n'existe donc aucune donnée à répliquer entre les zones. L’état de connexion est éphémère et est associé à chaque connexion active.

Comportement lors d’une défaillance de zone

Cette section décrit ce que vous devez attendre lorsque vous configurez une ressource Azure SignalR Service pour la redondance de zone et qu'il existe une panne dans l'une des zones de disponibilité.

• Detection et response : La plateforme Azure SignalR Service est chargée de détecter une défaillance dans une zone de disponibilité. Vous n’avez pas besoin d’agir pour 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 : Lors d’une défaillance de zone, les connexions actives aux nœuds de la zone affectée sont supprimées. Si vos clients gèrent les erreurs temporaires de manière appropriée, par exemple en se reconnectant après une courte période de temps, ils évitent généralement un impact significatif.

• Expected data loss : Azure SignalR Service ne conserve pas les messages. Par conséquent, une défaillance de zone n'est pas censée entraîner une perte de données dans le Azure SignalR service. Toutefois, toutes les connexions actives sont supprimées lors d’un événement de zone vers le bas, de sorte que toutes les données qui sont transmises activement peuvent être perdues.

• Temps d’arrêt attendu : La reconnexion des connexions actives supprimées prend généralement quelques secondes. Les clients qui implémentent une logique de reconnexion subissent des perturbations minimales.

• Redistribution : Azure SignalR Service détecte la perte de la zone et redistribue automatiquement le trafic entre les zones saines. Vous n’avez pas besoin d’agir.

Récupération de la zone

Lorsqu’une zone de disponibilité se rétablit, Azure SignalR Service la réintègre automatiquement dans la topologie de service active. Vous n’avez pas besoin d’effectuer d’action pour la récupération de la zone.

Une fois qu’une zone a récupéré, de nouvelles connexions peuvent être dirigées vers l’infrastructure dans la zone récupérée. Les connexions existantes ne seront pas déplacées ni rééquilibrées dans la zone récupérée, mais elles seront rééquilibrées progressivement à mesure que les connexions existantes se déconnectent et se reconnectent au fil du temps. Le déséquilibre de connexion entre les zones n’a aucun impact sur votre charge de travail.

Tester les pannes de zone

Azure SignalR Service gère automatiquement le routage du trafic, le basculement et la récupération de zone pour les ressources de niveau Premium redondant interzone. Vous n’avez pas besoin de lancer quoi que ce soit. Étant donné que la redondance de zone est entièrement gérée, vous n’avez pas besoin de valider les processus de défaillance des zones de disponibilité.

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

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

Pour protéger votre application contre une défaillance à l’échelle de la région, vous pouvez utiliser la géoréplication, qui est disponible dans le niveau Premium. Vous pouvez également créer une solution multirégion personnalisée en déployant plusieurs ressources SignalR Service dans différentes régions.

Geo-replication

La géoréplication vous permet d’ajouter replicas de votre ressource de SignalR Service dans d’autres régions Azure. Azure Traffic Manager utilise le routage DNS pour diriger chaque client vers le réplica régional le plus proche et sain. En cas d’échec d’une région, Traffic Manager détecte l’échec par le biais de contrôles d’intégrité et arrête de diriger les clients vers cette réplique. Les nouvelles connexions clientes sont automatiquement routées vers le réplica sain le plus proche.

La région dans laquelle vous avez créé la ressource Azure SignalR Service est appelée région primaire, et sa réplique est la réplique primaire. Le plan de contrôle de la ressource primaire gère la configuration de votre ressource Azure SignalR Service.

Exigences

• Region support : Vous pouvez ajouter des réplicas dans n’importe quelle région où Azure SignalR Service est disponible.
• Niveau: Vous devez utiliser le niveau Premium pour activer la géoréplication.
• Replica limit : Chaque ressource de SignalR Service principale prend en charge jusqu’à huit réplicas.

Considérations

• Héritage de configuration : Les réplicas héritent de la plupart des paramètres de configuration de la ressource principale. Certains paramètres doivent être configurés séparément sur chaque réplique. Pour obtenir la liste complète des paramètres qui ne sont pas hérités, consultez Géoréplication dans Azure SignalR Service.

• Modifications de configuration : Le plan de contrôle principal, dans la région primaire, traite les modifications de configuration apportées à la ressource SignalR Service. Si le plan de contrôle principal n’est pas disponible, vous ne pourrez pas mettre à jour la configuration des ressources, bien que les réplicas existants continuent de traiter le trafic de données sans interruption.

Coûts

Chaque réplica est facturé séparément en fonction de son propre nombre d’unités et du volume de messages sortants. Les frais de sortie interrégion s’appliquent lorsque les messages sont transférés entre les réplicas et remis aux clients ou aux serveurs d’une autre région. Pour plus d’informations, consultez Azure SignalR Service tarification.

Configurer la géoréplication

Pour ajouter ou supprimer un réplica d'une ressource Azure SignalR, consultez Geo-replication dans Azure SignalR Service.

Planification de capacité et gestion

Chaque réplique gère le trafic indépendamment. Pendant un basculement régional, les clients de la région en panne se reconnectent à la réplique en bon état la plus proche. Pour vous assurer que les réplicas survivants disposent d’une capacité suffisante pour absorber cette charge supplémentaire, configurez chaque réplica avec des unités capables de gérer le trafic attendu complet de la charge de travail, plutôt que seulement la portion qu'il dessert normalement.

Vous pouvez également activer la mise à l’échelle automatique sur chaque réplica afin que les unités puissent effectuer un scale-out automatiquement en réponse à une charge plus élevée. La mise à l’échelle automatique continue de fonctionner lorsque une réplique secondaire n’est pas disponible, mais elle ne fonctionne pas si le plan de contrôle principal est indisponible. Pour plus d’informations sur la mise à l’échelle automatique, consultez Autoscaling dans Azure SignalR Service.

Pour obtenir des conseils généraux sur le surprovisionnement en tant que stratégie, consultez Gérer la capacité en surprovisionnant.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsque vous configurez Azure SignalR Service pour la géoréplication et que tous les réplicas sont opérationnels.

• Opération inter-régions : Azure Traffic Manager redirige chaque client vers la réplique régionale la plus proche et en bon état. Les clients dans différentes zones géographiques peuvent se connecter à différentes répliques. SignalR Service synchronise les messages entre les réplicas afin que les clients connectés à n’importe quel réplica puissent communiquer entre eux.

• Réplication des données interrégions : Lorsqu’un message est envoyé à un réplica, le service transfère de façon synchrone ce message à d’autres réplicas afin que les clients connectés ailleurs puissent le recevoir. La surcharge de synchronisation est minimale pour les modèles de messagerie les plus courants, tels que la diffusion vers de grands groupes ou la messagerie d’une connexion unique. La messagerie à de petits groupes (moins de 10 membres) peut entraîner une surcharge de synchronisation légèrement plus élevée.

  Azure SignalR Service ne conserve pas les messages ; la distribution active est synchronisée entre les réplicas.

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

Cette section décrit ce que vous devez attendre lorsque vous configurez Azure SignalR Service pour la géoréplication et qu'il existe une panne dans l'une des régions de réplica.

• Détection et réponse : SignalR Service est responsable de la détection d’une défaillance dans une région et du réacheminement automatique du trafic entrant vers un réplica dans l’une des autres régions que vous configurez.

• 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 connexions actives au réplica dans la région défaillante sont interrompues. Les clients doivent se reconnecter après le basculement du réplica.

• Perte de données attendue : Azure SignalR Service ne conserve pas les messages. Les messages qui étaient en transit vers les clients dans la région ayant échoué au moment de l’échec peuvent être perdus. Aucune perte de données persistante n’est attendue, car le service ne stocke pas les données client.

• Expected downtime : Azure Traffic Manager effectue des contrôles d’intégrité sur chaque réplique. Lorsqu’une panne de région provoque l’échec d’une vérification d’intégrité d’un réplica, Traffic Manager supprime le point de terminaison de ce réplica de ses résultats de résolution DNS. Après avoir supprimé le point de terminaison, la durée de vie DNS de 90 secondes doit s’écouler avant que les clients voient les enregistrements DNS mis à jour. Au total, la transition prend généralement quelques minutes. Les clients bien conçus qui implémentent la logique de reconnexion peuvent reprendre leur fonctionnement normalement après la reconnexion à la réplique en bon état.

  Si le plan de contrôle principal n'est pas disponible, vous ne pouvez apporter aucune modification à la configuration de votre ressource SignalR Service ou de ses réplicas. Toutefois, les connexions continuent de fonctionner dans des répliques saines.

• Redistribution : Azure Traffic Manager dirige la requête entrante vers des réplicas sains. Toutefois, si un client tente de se reconnecter avant qu'Azure Traffic Manager n'ait détecté le basculement du réplica et que les entrées DNS mises à jour aient été propagées au client, la tentative de reconnexion d'un client risque de continuer à cibler la région indisponible et d'échouer.

  Une fois la mise à jour DNS propagée, les clients se reconnectant sont automatiquement routés vers le réplica sain le plus proche.

Récupération de région

Lorsque la région ayant échoué récupère, le contrôle d’intégrité de Traffic Manager détecte le réplica restauré et inclut à nouveau son point de connexion dans la résolution DNS. Les clients actuellement connectés à d'autres réplicas ne sont pas affectés et restent connectés tant qu'ils ne se déconnectent pas. De nouvelles connexions sont routées vers le réplica de la région récupérée lorsqu’il s’agit du réplica sain le plus proche.

Tester les défaillances régionales

Pour simuler un basculement de région et tester le comportement de reconnexion de votre application cliente, vous pouvez désactiver le point de terminaison d’un réplica. Cette action entraîne l’arrêt du routage du trafic vers ce réplica, ce qui vous permet d’observer le comportement de vos clients lorsque le réplica auquel ils se connectent devient indisponible. Pour obtenir des instructions détaillées, consultez Désactiver ou activer le point de terminaison du réplica.

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

Si vous avez besoin d'une résilience interrégion, mais que vous n'utilisez pas de géoréplication, vous pouvez déployer et gérer des ressources SignalR Service distinctes dans plusieurs régions et implémenter votre propre logique de basculement dans votre serveur d'applications. Cette approche est plus complexe que la géoréplication et ne prend pas en charge le basculement sans temps d’arrêt pour la connectivité client à client. Pour obtenir une vue d’ensemble détaillée de l’architecture, des modèles de basculement et des conseils de test, consultez Resiliency et récupération d’urgence dans Azure SignalR Service.

Sauvegarde et restauration

Azure SignalR Service est un service de messagerie sans état. Il ne conserve pas les messages clients et n’a aucune fonctionnalité de sauvegarde ou de restauration.

Pour protéger votre configuration des ressources, définissez vos ressources SignalR Service à l’aide d’une infrastructure en tant que code (par exemple, des modèles Bicep ou ARM) et stockez ces définitions dans le contrôle de code source. Si vous devez recréer une ressource, redéployez-la à partir de la configuration stockée.

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.

Pendant la maintenance planifiée, Azure SignalR Service utilise une stratégie d’arrêt appropriée pour réduire l’impact sur les clients connectés. Les connexions sont progressivement déconnectées sur une fenêtre de temps définie, ce qui permet aux clients de se reconnecter progressivement plutôt qu’à la fois. Pour plus d’informations, consultez Déconnexions pendant la maintenance du service.

Les événements de maintenance sont exposés à vos clients au fur et à mesure que la connexion tombe. Assurez-vous que vos applications clientes implémentent une logique de reconnexion afin qu’elles puissent récupérer à partir de déconnexions liées à la maintenance sans interruption visible par l’utilisateur.

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.

Contenu connexe

• Fiabilité dans Azure
• vue d’ensemble Azure SignalR Service
• Geo-replication dans Azure SignalR Service
• Résilience et récupération après sinistre dans Azure SignalR Service
• Compréhension des déconnexions et reconnexions des clients dans Azure SignalR Service