Replicación geográfica en Azure Web PubSub

Las aplicaciones críticas a menudo necesitan tener un sistema de conmutación por error sólido y servir a los usuarios más cerca de dónde están. Antes del lanzamiento de la característica de replicación geográfica, los desarrolladores necesitaban implementar varios recursos de Web PubSub y escribir código personalizado para orquestar la comunicación entre recursos. Ahora, con la configuración rápida a través de Azure Portal, puede habilitar fácilmente esta característica.

Ventajas del uso de la replicación geográfica

• Más resistente a la interrupción regional: si se produce una interrupción regional, los clientes se enrutarán automáticamente a una réplica correcta.
• Comunicación entre regiones: los desarrolladores usan un recurso habilitado para replicación geográfica como de costumbre, aunque en segundo plano haya más de un recurso. El servicio controla la comunicación entre réplicas.
• Velocidad de red mejorada: los clientes dispersos geográficamente se conectarán a la réplica más cercana. Estas réplicas se comunican a través de la red troncal global de Azure, lo que garantiza redes rápidas y estables.
• Administrabilidad. Todas las réplicas comparten la configuración del recurso principal de Web PubSub.

Requisitos previos

• Un recurso de Web PubSub en el nivel Premium.

Ejemplo de caso de uso

Contoso, una empresa de redes sociales

Contoso es una empresa de redes sociales con su base de clientes distribuida en Estados Unidos y Canadá. Contoso proporciona una aplicación móvil y web a sus usuarios para que puedan conectarse entre sí. La aplicación Contoso se implementa en centro de EE. UU. Como parte de la arquitectura de Contoso, Web PubSub se usa para establecer conexiones WebSocket persistentes entre las aplicaciones cliente y el servidor de aplicaciones. Contoso le gusta que pueden descargar la administración de conexiones de WebSocket a Web PubSub, pero no le gusta leer informes de usuarios en Canadá que experimentan una mayor latencia. Además, el equipo de desarrollo de Contoso quiere asegurar la aplicación contra la interrupción regional para que los usuarios puedan acceder a la aplicación sin interrupciones.

Contoso podría configurar otro recurso de Web PubSub en centro de Canadá, que está geográficamente más cerca de sus usuarios en Canadá. Sin embargo, la administración de varios recursos de Web PubSub conlleva algunos desafíos:

1. Un mecanismo de comunicación entre regiones tendría que implementarse para que los usuarios de Canadá y EE. UU. puedan interactuar entre sí.
2. El equipo de desarrollo tendría que administrar dos recursos independientes de Web PubSub, cada uno con un dominio y cadena de conexión distintos.
3. Si se produce una interrupción regional, el tráfico debe dirigirse a un recurso disponible.

Todo lo anterior quita los recursos de ingeniería de centrarse en la innovación del producto.

Aprovechamiento de la característica de replicación geográfica

Con la característica de replicación geográfica, Contoso ahora puede establecer una réplica en centro de Canadá, superando eficazmente los desafíos mencionados anteriormente. El equipo de desarrolladores está encantado de averiguar que no es necesario realizar ningún cambio en el código. Es tan fácil como hacer clic en unos pocos botones en Azure Portal. El equipo de desarrolladores también está encantado de compartir con las partes interesadas que como Contoso planea entrar en el mercado europeo, simplemente necesitan agregar otra réplica en Europa.

Habilitación de la replicación geográfica en un recurso de Web PubSub

Portal

Para crear una réplica en una región de Azure, vaya al recurso Web PubSub y busque la hoja Réplicas en Azure Portal y haga clic en Agregar para crear una réplica.

Después de la creación, podrá ver o editar la réplica en el portal haciendo clic en el nombre de la réplica.

Bicep

Use Visual Studio Code o su editor favorito para crear un archivo con el siguiente contenido y asígnele el nombre main.bicep:

@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
  }
}

Implementación del archivo de Bicep mediante la CLI de Azure

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

CLI

Actualice la extensión webpubsub a la versión más reciente y, a continuación, ejecute:

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

Precios y unidad de recursos

Cada réplica tiene su propiaunit y autoscale settings.

Réplica es una característica del nivel Premium del servicio Azure Web PubSub. Cada réplica se factura por separado según su propia unidad y tráfico saliente. La cuota de mensajes gratis también se calcula por separado.

En el ejemplo anterior, Contoso agregó una réplica en Centro de Canadá. Contoso pagaría la réplica en Centro de Canadá según su unidad y mensaje en Precio Premium.

Habrá tarifas de salida para el tráfico saliente entre regiones. Si un mensaje se transfiere entre réplicas y se envía correctamente a un cliente o servidor después de la transferencia, se facturará como un mensaje saliente.

Eliminación de una réplica

Después de crear una réplica para un recurso de Web PubSub, puede eliminarla en cualquier momento si ya no es necesaria.

Para eliminar una réplica en Azure Portal:

1. Vaya al recurso Web PubSub y seleccione la hoja Réplicas . Haga clic en la réplica que desea eliminar.
2. Haga clic en el botón Eliminar de la hoja de información general de la réplica.

Para eliminar una réplica mediante la CLI de Azure:

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

Comprender cómo funciona la característica de replicación geográfica

1. El cliente resuelve el nombre de dominio completo (FQDN) contoso.webpubsub.azure.com del servicio Web PubSub. Este FQDN apunta a un Administrador de tráfico, que devuelve el nombre canónico (CNAME) de la instancia de Web PubSub regional más cercana.
2. Con este CNAME, el cliente establece una conexión websocket a la instancia regional (réplica).
3. Las dos réplicas sincronizarán los datos entre sí. Si es necesario, los mensajes enviados a una réplica se transferirían a otras réplicas.
4. En caso de que una réplica produzca un error en la comprobación de estado realizada por Traffic Manager (TM), el TM excluirá el punto de conexión de la instancia con error de los resultados de la resolución de dominio. Para obtener más información, consulte a continuación Resistencia y recuperación ante desastres.

Nota:

• En el plano de datos, un recurso de Azure Web PubSub principal funciona de forma idéntica a sus réplicas.

---

Resistencia y recuperación ante desastres

El servicio Azure Web PubSub utiliza un administrador de tráfico para las comprobaciones de estado y la resolución dns hacia sus réplicas. En circunstancias normales, cuando todas las réplicas funcionan correctamente, los clientes se dirigirán a la réplica más cercana. Por ejemplo:

• Los clientes cercanos eastus se dirigirán a la réplica ubicada en eastus.
• Del mismo modo, los clientes cercanos westus se dirigirán a la réplica en westus.

En caso de una interrupción regional en eastus (se muestra a continuación), el administrador de tráfico detectará el error de comprobación de estado de esa región. A continuación, el DNS de esta réplica errónea se excluirá de los resultados de la resolución DNS del administrador de tráfico. Después de una duración de tiempo de vida (TTL) de DNS, que se establece en 90 segundos, los clientes de eastus se redirigirán para conectarse con la réplica en westus.

Una vez resuelto el problema en eastus y la región vuelve a estar en línea, la comprobación de estado se realizará correctamente. A continuación, los clientes en eastus se dirigirán una vez más a la réplica en su región. Esta transición es fluida, ya que los clientes conectados no se verán afectados hasta que se cierren esas conexiones existentes.

Este proceso de conmutación por error y recuperación es automático y no requiere intervención manual.

Deshabilitar o habilitar el punto de conexión de réplica

Al configurar una réplica, tiene la opción de habilitar o deshabilitar su punto de conexión. Si está deshabilitado, la resolución DNS del FQDN principal no incluirá la réplica y, por lo tanto, el tráfico no se dirigirá a ella.

También puede habilitar la deshabilitación del punto de conexión una vez creado. En la hoja réplicas del recurso principal, haga clic en el botón de puntos suspensivos situado en el lado derecho de la réplica y elija Habilitar punto de conexión o Deshabilitar punto de conexión:

Antes de eliminar una replicación, considere la posibilidad de deshabilitar primero su punto de conexión. Con el tiempo, las conexiones existentes se desconectarán. A medida que no llegan nuevas conexiones, la replicación se vuelve inactiva finalmente. Esto garantiza un proceso de eliminación sin problemas.

Esta característica también es útil para solucionar problemas regionales.

Nota:

• Debido a la caché DNS, la actualización de DNS puede tardar varios minutos en surtir efecto.
• Las conexiones existentes no se ven afectadas hasta que se desconectan.

Impacto en el rendimiento después de habilitar la característica de replicación geográfica

Una vez habilitadas las réplicas, los clientes se distribuirán naturalmente en función de sus ubicaciones geográficas. Aunque Web PubSub asume la responsabilidad de sincronizar los datos entre estas réplicas, se complacerá en saber que la sobrecarga asociada en la carga del servidor es mínima para los casos de uso más comunes.

En concreto, si la aplicación suele difundirse a grupos más grandes (tamaño >10) o a una sola conexión, el impacto en el rendimiento de la sincronización apenas es perceptible. Si va a enviar grupos pequeños (tamaño < 10), es posible que observe un poco más sobrecarga de sincronización.

Para garantizar una administración de conmutación por error eficaz, se recomienda establecer el tamaño de unidad de cada réplica para controlar todo el tráfico. Como alternativa, puede habilitar el escalado automático para administrarlo.

Para obtener más evaluación del rendimiento, consulte Rendimiento.