Géoréplication dans Azure SignalR

Les entreprises recherchant une présence locale ou nécessitant un système de basculement robuste choisissent souvent de déployer des services dans plusieurs régions Azure. Avec l’intégration de la géoréplication dans Azure SignalR, la gestion des scénarios multirégions est devenue beaucoup plus facile.

Avantages offerts par l’utilisation de la géoréplication

• Résilience accrue aux pannes régionales : si une panne régionale se produit, le système DNS Azure SignalR est résolu en réplicas sains dans d’autres régions.
• Communication interrégion. Différents réplicas peuvent communiquer entre eux comme s’il s’agissait de la même instance.
• Amélioration de la vitesse du réseau : les clients dispersés géographiquement se connectent au réplica le plus proche. Ces réplicas communiquent via le réseau global Azure, garantissant ainsi une mise en réseau rapide et stable.
• Configurations partagées. Tous les réplicas conservent la configuration de la ressource Azure SignalR Service principale.

Prérequis

• Une instance d’Azure SignalR Service de niveau Premium.

Exemple de cas d’usage

Contoso est une société de réseaux sociaux dont la base de clients est répartie aux États-Unis et au Canada. Pour servir ces clients et leur permettre de communiquer les uns avec les autres, Contoso exécute ses services dans la région USA Centre. Azure SignalR Service est utilisé pour gérer les connexions utilisateur et faciliter la communication entre eux. Les utilisateurs finaux de Contoso sont principalement des utilisateurs de téléphone. En raison des distances géographiques importantes, les utilisateurs finaux au Canada peuvent observer une latence élevée et une mauvaise qualité du réseau.

Avant l’avènement de la fonctionnalité de géoréplication, Contoso pouvait configurer une autre instance d’Azure SignalR Service dans la région Canada Centre pour servir ses utilisateurs canadiens. Grâce à la configuration d’une instance d’Azure SignalR Service plus proche géographiquement, les utilisateurs finaux disposaient alors d’une meilleure qualité réseau et d’une latence inférieure.

Toutefois, la gestion de plusieurs instances d’Azure SignalR Service présentait quelques défis :

1. Un mécanisme de communication interrégion était nécessaire pour permettre la conversation entre les utilisateurs du Canada et des États-Unis.
2. L’équipe de développement devait gérer deux instances d’Azure SignalR Service distinctes, chacune avec une chaîne de connexion et un domaine distincts.
3. Si une panne régionale se produisait, le trafic devait être basculé vers une autre région.

Exploitation de la géoréplication

Avec la nouvelle fonctionnalité de géoréplication, Contoso peut maintenant établir un réplica dans la région Canada Centre, et ainsi surmonter efficacement les obstacles mentionnés ci-dessus.

Créer un réplica SignalR

Portail

Pour créer un réplica, accédez au panneau Réplicas SignalR dans le portail Azure, puis cliquez sur Ajouter pour créer un réplica. Il sera activé automatiquement lors de la création.

Après la création, vous pouvez afficher/modifier votre réplica dans le portail en cliquant sur le nom du réplica.

Bicep

Utilisez Visual Studio Code ou votre éditeur favori pour créer un fichier avec le contenu suivant, puis nommez-le main.bicep :

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Déployer le fichier Bicep à l’aide d’Azure CLI

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Tarifs et unité de ressources

Chaque réplica a ses propresunit et autoscale settings.

Le réplica est une fonctionnalité du niveau Premium d’Azure SignalR Service. Chaque réplica est facturé séparément en fonction de sa propre unité et de son propre trafic sortant. Le quota de messages gratuits est également calculé séparément.

Dans l’exemple précédent, Contoso a ajouté un réplica dans Canada Centre. Contoso paierait le réplica dans Canada Centre conformément à son unité et à son quota de messages au tarif Premium.

Il y aura des frais de sortie pour le trafic sortant interrégion. Si un message est transféré entre réplicas et envoyé avec succès à un client ou un serveur après le transfert, il est facturé en tant que message sortant.

Supprimer un réplica

Une fois que vous avez créé un réplica pour votre instance d’Azure SignalR Service, vous pouvez le supprimer à tout moment s’il n’est plus nécessaire.

Pour supprimer un réplica dans le portail Azure :

1. Accédez à votre instance d’Azure SignalR Service et sélectionnez le panneau Réplicas. Cliquez sur le réplica à supprimer.
2. Cliquez sur le bouton Supprimer dans le panneau Vue d’ensemble du réplica.

Comprendre le fonctionnement du réplica SignalR

Le diagramme ci-dessous fournit une brève illustration de la fonctionnalité des réplicas SignalR :

1. Le client négocie avec le serveur d’applications et reçoit une redirection vers le service Azure SignalR. Il résout ensuite le nom de domaine complet (FQDN) du service SignalR, contoso.service.signalr.net. Ce nom de domaine complet pointe vers Traffic Manager, qui retourne le nom canonique (CNAME) de l’instance SignalR régionale la plus proche.
2. Avec ce CNAME, le client établit une connexion à l’instance régionale (réplica).
3. Les deux réplicas synchronisent leurs données l’un avec l’autre. Les messages envoyés à un réplica sont transférés vers d’autres réplicas si nécessaire.
4. Dans le cas où un réplica échoue au contrôle d’intégrité effectué par Traffic Manager (TM), celui-ci exclut le point de terminaison de l’instance ayant échoué de son processus de résolution de domaine. Pour plus d’informations, consultez Résilience et reprise d’activité après sinistre ci-dessous.

Remarque

• Dans le plan de données, une ressource Azure SignalR principale fonctionne de façon identique à ses réplicas.

Résilience et récupération d’urgence

Azure SignalR Service utilise un gestionnaire de trafic pour les contrôles d’intégrité et la résolution DNS vers ses réplicas. Dans des circonstances normales, lorsque tous les réplicas fonctionnent correctement, les clients sont dirigés vers le réplica le plus proche. Exemple :

• Les clients proches de eastus sont dirigés vers le réplica situé dans eastus.
• De même, les clients proches de westus sont dirigés vers le réplica dans westus.

En cas de panne régionale dans eastus (illustrée ci-dessous), le gestionnaire de trafic détecte l’échec du contrôle d’intégrité pour cette région. Le système DNS de ce réplica défectueux est alors exclu des résultats de la résolution DNS du gestionnaire de trafic. Après une durée de vie (TTL) DNS définie sur 90 secondes, les clients dans eastus sont redirigés afin de se connecter au réplica dans westus.

Une fois le problème dans eastus résolu et la région de nouveau en ligne, le contrôle d’intégrité réussit. Les clients dans eastus seront de nouveau dirigés vers le réplica dans leur région. Cette transition est fluide, car les clients connectés ne seront pas affectés tant que ces connexions existantes ne seront pas fermées.

Ce processus de basculement et de récupération est automatique, et ne nécessite aucune intervention manuelle.

Pour les connexions de serveur, le basculement et la récupération fonctionnent de la même façon que pour les connexions clientes.

Remarque

• Ce mécanisme de basculement est destiné à Azure SignalR Service. Les pannes régionales du serveur d’applications dépassent la portée de ce document.

Désactiver ou activer le point de terminaison de réplica

Lors de la configuration d’un réplica, vous avez la possibilité d’activer ou de désactiver son point de terminaison. S’il est désactivé, la résolution DNS du nom de domaine complet principal n’inclut pas le réplica. Par conséquent, le trafic n’est pas dirigé vers celui-ci.

Vous pouvez également activer ou désactiver le point de terminaison après sa création. Dans le panneau de réplicas de la ressource principale, cliquez sur le bouton de sélection situé à droite du réplica et choisissez Activer le point de terminaison ou Désactiver le point de terminaison :

Avant de supprimer une réplication, réfléchissez s’il ne serait pas préférable de désactiver d’abord son point de terminaison. Au fil du temps, les connexions existantes se déconnecteront. Aucune nouvelle connexion ne se présentant, la réplication finira par devenir inactive. Cela garantit la fluidité du processus de suppression.

Cette fonctionnalité est également utile pour résoudre les problèmes régionaux.

Remarque

• En raison du cache DNS, l’entrée en vigueur de la mise à jour DNS peut prendre plusieurs minutes.
• Les connexions existantes ne sont pas affectées tant qu’elles ne sont pas interrompues.

Impact sur les performances après l’ajout de réplicas

Une fois les réplicas activés, les clients procèdent naturellement à une distribution en fonction de leurs localisations géographiques. Bien que SignalR assume la responsabilité de la synchronisation des données entre ces réplicas, vous serez heureux d’apprendre que la surcharge associée sur la charge du serveur est minimale pour les cas d’usage les plus courants.

Plus précisément, si votre application diffuse généralement à des groupes de grande taille (> 10) ou une connexion unique, l’impact sur les performances de la synchronisation est à peine perceptible. Si vous envoyez des messages à de petits groupes (taille < 10) ou à des utilisateurs individuels, vous remarquerez peut-être un peu plus de surcharge de synchronisation.

Pour garantir une gestion efficace du basculement, il est recommandé de définir la taille d’unité de chaque réplica pour gérer tout le trafic. En guise d’alternative, vous pouvez activer la mise à l’échelle automatique pour gérer cela.

Pour plus d’informations sur l’évaluation des performances, consultez Performances.