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

• Résilience accrue aux pannes régionales : si une panne régionale se produit, les clients sont automatiquement acheminé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éplicas est gérée par le service.
• 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.
• 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 de faire savoir aux parties prenantes que Contoso, qui prévoit d’entrer sur le marché européen, n’aura qu’à ajouter un autre réplica 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 ses propres unit et autoscale settings.

Le réplica est une fonctionnalité du niveau Premium du service Azure Web PubSub. 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 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 panneau Réplicas. Cliquez sur le réplica à supprimer.
2. Cliquez sur le bouton Supprimer dans le panneau 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 nom de domaine complet pointe vers Traffic Manager, qui retourne 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

Le service Azure Web PubSub 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.

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.

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

Une fois les réplicas activés, les clients procèdent naturellement à une distribution en fonction de leurs localisations géographiques. 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.

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.

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

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

1. Référence SKU : chaque réplica a son propre nom de référence SKU et sa taille d’unité. Les règles de mise à l’échelle automatique pour les réplicas doivent être configurées séparément en fonction de leurs mesures individuelles.
2. Points de terminaison privés partagés : alors que les points de terminaison privés partagés sont automatiquement répliqués sur des réplicas, des approbations distinctes sont requises sur les ressources de liaison privée cible. 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 destination des journaux. S’il n’est pas configuré sur les réplicas, seuls les journaux de la ressource principale sont 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.