Géoréplication dans Azure Web PubSub

Les applications stratégiques doivent souvent disposer d’un système de basculement robuste et servir les utilisateurs plus près de leur emplacement. Avant la publication de la fonctionnalité de géoréplication, les développeurs devaient déployer plusieurs ressources Web PubSub et écrire du code personnalisé pour orchestrer la communication entre les ressources. Maintenant, avec une configuration rapide via le portail Azure, vous pouvez facilement activer cette fonctionnalité.

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

• Plus résilient face aux pannes régionales : en cas de panne régionale, les clients seront automatiquement redirigés vers un réplica sain.
• Communication interrégion : les développeurs utilisent une ressource activée pour la géoréplication comme n’importe quelle autre ressource, même si en arrière-plan il existe plusieurs ressources. La communication entre les répliques est gérée par le service.
• Débit réseau amélioré : les clients géographiquement dispersés se connecteront à la réplique la plus proche. Ces réplicas communiquent via le réseau global Azure, garantissant ainsi une mise en réseau rapide et stable.
• Gestion facile. Tous les réplicas partagent la configuration de la ressource Web PubSub principale.

Prérequis

• Une ressource Web PubSub dans le niveau Premium.

Exemple de cas d’usage

Contoso, une société de réseaux sociaux

Contoso est une société de réseaux sociaux dont la base de clients est répartie aux États-Unis et au Canada. Contoso fournit une application mobile et web à ses utilisateurs afin qu’ils puissent se connecter les uns avec les autres. L’application Contoso est déployée dans la région USA Centre. Dans le cadre de l’architecture de Contoso, Web PubSub est utilisé pour établir des connexions WebSocket persistantes entre les applications clientes et le serveur d’applications. Contoso apprécie de pouvoir décharger la gestion des connexions WebSocket à Web PubSub, mais n’apprécie pas que les utilisateurs au Canada signalent une latence plus élevée. En outre, l’équipe de développement de Contoso souhaite assurer l’application contre les pannes régionales, afin que les utilisateurs puissent y accéder sans interruption.

Contoso pourrait configurer une autre ressource Web PubSub dans la région Canada Centre, qui est géographiquement plus proche de ses utilisateurs au Canada. Toutefois, la gestion de plusieurs ressources Web PubSub présente quelques défis :

1. Un mécanisme de communication interrégion devrait être mis en œuvre afin que les utilisateurs du Canada et des États-Unis puissent interagir.
2. L’équipe de développement devrait gérer deux instances distinctes de Web PubSub, chacune avec une chaîne de connexion et un domaine distincts.
3. Si une panne régionale a lieu, le trafic doit être dirigé vers une ressource disponible.

Toutes les contraintes ci-dessus font que les ressources d’ingénierie ne peuvent pas se concentrer sur l’innovation des produits.

Exploiter la fonctionnalité de géoréplication

Avec la fonctionnalité de géoréplication, Contoso peut maintenant établir un réplica dans la région Canada Centre, et ainsi surmonter efficacement les défis mentionnés ci-dessus. L’équipe de développement est heureuse d’apprendre qu’elle n’a pas besoin d’apporter de modifications de code. Seuls quelques clics de boutons dans le portail Azure sont nécessaires. L’équipe de développement est également heureuse d’informer les parties prenantes que, comme Contoso prévoit d’entrer sur le marché européen, il lui suffit simplement d’ajouter une autre réplique en Europe.

Comment activer la géoréplication dans une ressource Web PubSub

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

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

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

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

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

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

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

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

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

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

az webpubsub replica create --sku Premium_P1 -l eastus --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Tarifs et unité de ressources

Chaque réplica a son propre unit et autoscale settings.

Réplica est une fonctionnalité du niveau Premium du service Azure Web PubSub. Chaque réplica est facturé séparément selon sa propre unité et son propre trafic sortant. Le quota de messages gratuits est également calculé séparément.

Dans l’exemple précédent, Contoso a ajouté une réplique dans le Centre du Canada. Contoso paierait le réplica situé dans la région Canada Centre selon les tarifs Premium applicables aux unités et aux messages.

Des frais de sortie de données s’appliqueront au trafic sortant interrégional. 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 une réplique

Une fois que vous avez créé un réplica pour une ressource Web PubSub, 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 ressource Web PubSub, puis sélectionnez le volet Répliques. Cliquez sur la réplique que vous souhaitez supprimer.
2. Cliquez sur le bouton Supprimer dans le volet Vue d’ensemble du réplica.

Pour supprimer un réplica à l’aide d’Azure CLI :

 az webpubsub replica delete --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Comprendre le fonctionnement de la fonctionnalité de géoréplication

1. Le client résout le nom de domaine complet (FQDN) contoso.webpubsub.azure.com du service Web PubSub. Ce FQDN pointe vers un Traffic Manager, qui renvoie le nom canonique (CNAME) de l’instance Web PubSub régionale la plus proche.
2. Avec ce CNAME, le client établit une connexion WebSocket à 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 ses résultats de résolution de domaine. Pour plus d’informations, consultez Résilience et reprise d’activité après sinistre ci-dessous.

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

Azure Web PubSub Service utilise un Traffic Manager pour les contrôles d’intégrité et la résolution DNS vers ses réplicas. Dans des conditions 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 seront dirigés vers la réplique située dans eastus.
• De même, les clients proches de westus seront dirigés vers la réplique dans westus.

En cas de panne régionale dans la région eastus (illustrée ci-dessous), Traffic Manager détectera l’échec de la vérification de l’état d’intégrité pour cette région. Ensuite, le DNS de ce réplica défectueux sera exclu des résultats de résolution DNS du gestionnaire de trafic. Après expiration de la durée de vie (TTL) DNS, définie sur 90 secondes, les clients de eastus seront redirigés pour se connecter à la réplique 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éussira. Les clients dans eastus seront alors de nouveau dirigés vers la réplica de 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.

Désactiver ou activer le point de terminaison de la réplique

Lors de la configuration d’une réplique, vous pouvez activer ou désactiver son point de terminaison. S’il est désactivé, la résolution DNS du FQDN principal n’inclura pas la réplique et, par conséquent, le trafic ne sera pas dirigé vers celle-ci.

Vous pouvez également activer ou désactiver le point de terminaison après sa création. Dans le panneau des réplicas de la ressource principale, cliquez sur le bouton de points de suspension situé à droite du réplica, puis 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.

Impact sur les performances après l’activation de la fonctionnalité de géoréplication

Une fois les réplicas activés, les clients seront naturellement répartis en fonction de leur emplacement géographique. Bien que Web PubSub 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), vous remarquerez peut-être un peu plus de surcharge de synchronisation.

Afin de garantir une gestion efficace du basculement, il est recommandé de configurer la taille d’unité de chaque réplica de manière à pouvoir gérer l’ensemble du 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.

Configurations héritées et non héritées

Les répliques héritent de la plupart des configurations de la ressource principale ; toutefois, certains paramètres doivent être configurés directement sur les répliques. Voici la liste de ces configurations :

1. SKU : Chaque réplique a son propre nom de SKU et la taille de son unité. Les règles de mise à l’échelle automatique des répliques doivent être configurées séparément selon leurs métriques respectives.
2. Points de terminaison privés partagés : bien que les points de terminaison privés partagés soient automatiquement répliqués vers les réplicas, des approbations distinctes sont requises sur les ressources de liaison privée cibles. Pour ajouter ou supprimer des points de terminaison privés partagés, gérez-les sur la ressource principale. Ne pas activer le réplica tant que son point de terminaison privé partagé n’a pas été approuvé.
3. Paramètres de la destination de journalisation. Si cela n’est pas configuré sur les réplicas, seuls les journaux de la ressource principale seront transférés.
4. Alertes.

Toutes les autres configurations sont héritées de la ressource principale. Par exemple, les clés d’accès, l’identité, le pare-feu d’applications, les domaines personnalisés, les points de terminaison privés et le contrôle d’accès.