Fiabilité dans Azure Web PubSub Service

Azure Web PubSub Service est un service de messagerie en temps réel entièrement managé qui permet la communication bidirectionnelle entre les serveurs et les clients à l’aide du protocole WebSocket. Une seule ressource Web PubSub peut être mise à l’échelle jusqu'à un million de connexions WebSocket simultanées. Le service prend en charge plusieurs modèles de messagerie, notamment la diffusion de serveur à client, la messagerie vers les groupes nommés, le pub/sub entre clients et le streaming de jetons IA.

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 Web PubSub Service résilient à 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 décrit également comment le service gère la maintenance et met en évidence les informations clés sur le contrat de niveau de service (SLA) Azure Web PubSub service.

Recommandations de déploiement de production pour la fiabilité

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

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 Web PubSub. 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 Performance guide pour Azure Web PubSub Service.

Une ressource Web PubSub a un point de terminaison global unique similaire à contoso.webpubsub.azure.com. Les clients établissent des connexions WebSocket à 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.

Pour plus d’informations, consultez les détails internes du service Azure Web PubSub.

Architecture physique

Azure Web PubSub Service gère l’état de connexion webSocket 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.

WebSocket est un protocole de connexion de longue durée. Les événements réseau temporaires, les redémarrages de l’infrastructure principale et les opérations de maintenance de service peuvent supprimer une connexion active. Une reconnexion de base restaure la connexion, mais sans logique supplémentaire, le client perd les messages qui étaient en cours de transmission et mis en file d’attente pendant l'interruption.

Azure Web PubSub Service résout ce problème via sous-protocoles fiables qui se trouvent au-dessus de la connexion WebSocket brute. Les sous-protocoles suivent la séquence de messages et l’état de connexion afin que, lorsqu’une connexion tombe, le client renégocie avec le service et reprend à partir de l’endroit où il s’est arrêté.

En règle générale, il n'y a aucune perte de messages après qu'une connexion se coupe et se rétablit. Toutefois, il existe certaines situations où la perte de messages peut se produire. Par exemple, si le client se déconnecte pendant plus d’une minute, puis se reconnecte avec le même ID de connexion, l’opération de reconnexion affiche un état d’échec pour indiquer que la perte de message peut se produire.

Pour tirer parti des sous-protocole fiables, suivez ces recommandations :

• Si possible, utilisez un SDK client Azure Web PubSub. Le SDK implémente automatiquement le sous-protocole fiable. Aucune configuration supplémentaire n’est requise. Pour plus d’informations, consultez :

  • Kit de développement logiciel (SDK) côté client Web PubSub pour JavaScript
  • bibliothèque cliente de Azure Web PubSub pour .NET
  • bibliothèque cliente Azure Web PubSub pour Python
  • Azure bibliothèque de client WebPubSub pour Java

• Si vous ne pouvez pas utiliser le Kit de développement logiciel (SDK), implémentez l’un des sous-protocoles fiables directement dans votre code client WebSocket. Pour obtenir des instructions complètes sur la spécification et l’implémentation, consultez Créer des clients WebSocket fiables.

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 Web PubSub Service prend en charge les déploiements redondants interzone lorsque vous utilisez le niveau Premium. Lorsque vous créez ou mettez à niveau une ressource Web PubSub de niveau Premium dans une région qui prend en charge les zones de disponibilité, la redondance de zone est automatiquement activée. Le service distribue son infrastructure entre plusieurs zones de disponibilité de la région. En cas d’échec d’une zone, le service achemine le trafic vers l’infrastructure dans une zone saine.

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 Web PubSub 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 Web PubSub.

• 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 Web PubSub tarification des services.

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 Web PubSub redondante interzone. Sélectionnez une référence SKU de niveau Premium lorsque vous créez la ressource. Pour plus d’informations, consultez Créer une ressource Azure Web PubSub.

• 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 Scale an Azure Web PubSub Service instance.

Comportement lorsque toutes les zones sont saines

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

• Opération interzone : Azure Web PubSub 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 Web PubSub Service ne conserve pas les données client. Le service gère les métadonnées de session, telles que l’état de la connexion et les informations de séquence de messages pour les connexions actives. Ces métadonnées sont répliquées de manière synchrone dans les zones de disponibilité.

Comportement lors d’une défaillance de zone

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

• Détection et réponse : La plateforme Azure Web PubSub Service est responsable de la détection d’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 WebSocket actives à l’infrastructure dans 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 Web PubSub 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 service Azure Web PubSub. 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.

  Si les éditeurs utilisent un sdk client Azure Web PubSub ou implémentent les sous-protocoles fiables, leurs messages sont reconnus par le service une fois que le service les reçoit. Lorsqu’un message est reconnu, il est répliqué dans toutes les zones de disponibilité, de sorte que la défaillance de la zone du serveur ne provoque pas la perte du message. Toutefois, si un abonné ne reçoit pas le message avant sa suppression, il peut ne pas recevoir le message.

• 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 Web PubSub 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 Web PubSub 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

Le service Azure Web PubSub gère automatiquement le routage du trafic, le basculement et la récupération de zone pour les ressources Premium de niveau redondantes 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 Web PubSub Service est un service à région unique. Si la région devient indisponible, votre ressource Web PubSub est également indisponible.

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 Web PubSub dans différentes régions.

Geo-replication

La géoréplication vous permet d’ajouter replicas de votre ressource Web PubSub dans d’autres régions Azure. Tous les réplicas partagent un point de terminaison unique (contoso.webpubsub.azure.com). Derrière ce point de terminaison, Azure Traffic Manager utilise le routage DNS pour diriger chaque client vers la réplique régionale la plus proche et saine. 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 Web PubSub est appelée région primaire, et sa réplique est la réplique principale. Le plan de contrôle de la ressource principale gère la configuration de votre ressource Web PubSub.

Exigences

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

Éléments à prendre en compte

• 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 Geo-replication dans Azure Web PubSub.

• Modifications de configuration : Le plan de contrôle principal, dans la région primaire, traite les modifications de configuration apportées à la ressource Web PubSub. 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. Si un message est transféré entre les réplicas, puis remis à un client ou un serveur dans une autre région, il est facturé en tant que message sortant. Pour plus d’informations, consultez Azure Web PubSub tarification des services.

Configurer la géoréplication

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

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 Unités de mise à l’échelle automatique d’un service Azure Web PubSub.

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 Web PubSub Service pour la géoréplication et que toutes les régions sont opérationnelles.

• 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. Le service Web PubSub 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 Web PubSub Service ne conserve pas les messages ; seule la livraison active est synchronisée entre les répliques.

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

Cette section décrit ce à quoi vous pouvez vous attendre lorsque vous configurez le service Azure Web PubSub pour la géoréplication et en cas de panne dans l'une des régions de réplica.

• Détection et réponse : Le service Web PubSub est chargé de détecter une défaillance dans une région et de réacheminer automatiquement le 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 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 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 WebSocket actives au réplica dans la région ayant échoué sont supprimées. Les clients doivent se reconnecter après le basculement du réplica.

• Perte de données attendue : Azure Web PubSub Service ne stocke 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 Web PubSub ou à ses réplicas. Toutefois, les connexions WebSocket continuent de fonctionner dans les réplicas en bon état.

• 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 la géoréplication, vous pouvez déployer et gérer des ressources Web PubSub 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 Web PubSub Service.

Sauvegarde et restauration

Azure Web PubSub 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 Web PubSub à l’aide de l’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.

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

• Qu’est-ce que le service Azure Web PubSub ?
• Géoréplication dans Azure Web PubSub
• Résilience et récupération d’urgence dans Azure Web PubSub Service
• Mettre à l'échelle une instance du service Azure Web PubSub
• Mettre à l'échelle automatiquement les unités d'un service Azure Web PubSub
• Fiabilité dans Azure