Replicação geográfica no Azure Web PubSub

Os aplicativos de missão crítica geralmente precisam ter um sistema de failover robusto e atender os usuários mais perto de onde eles estão. Antes do lançamento do recurso de replicação geográfica, os desenvolvedores precisavam implantar vários recursos do Web PubSub e escrever código personalizado para orquestrar a comunicação entre recursos. Agora, com a configuração rápida por meio do portal do Azure, você pode habilitar facilmente esse recurso.

Benefícios do uso da replicação geográfica

• Mais resistente à interrupção regional: se ocorrer uma interrupção regional, os clientes serão automaticamente encaminhados para uma réplica íntegra.
• Comunicação entre regiões: os desenvolvedores usam um recurso habilitado para replicação geográfica como de costume, mesmo que nos bastidores haja mais de um recurso. A comunicação entre réplicas é tratada pelo serviço.
• Velocidade de rede aprimorada: clientes geograficamente dispersos se conectarão à réplica mais próxima. Essas réplicas se comunicam por meio do backbone de rede global do Azure, garantindo uma rede rápida e estável.
• Facilidade de gerenciamento. Todas as réplicas compartilham a configuração do recurso Web PubSub principal.

Pré-requisitos

• Um recurso Web PubSub na camada premium.

Caso de uso de exemplo

Contoso, uma empresa de mídia social

A Contoso é uma empresa de mídia social com sua base de clientes espalhada pelos EUA e Canadá. A Contoso fornece um aplicativo móvel e Web a seus usuários para que eles possam se conectar uns com os outros. O aplicativo Contoso é implantado no Centro dos EUA. Como parte da arquitetura da Contoso, o Web PubSub é usado para estabelecer conexões WebSocket persistentes entre aplicativos cliente e o servidor de aplicativos. A Contoso gosta de poder descarregar o gerenciamento de conexões WebSocket para o Web PubSub, mas não gosta de ler relatórios de usuários no Canadá com latência mais alta. Além disso, a equipe de desenvolvimento da Contoso deseja proteger o aplicativo contra interrupções regionais para que os usuários possam acessá-lo sem interrupções.

A Contoso poderia configurar outro recurso Web PubSub no Canada Central, geograficamente mais próximo de seus usuários no Canadá. No entanto, o gerenciamento de vários recursos do Web PubSub traz alguns desafios:

1. Um mecanismo de comunicação entre regiões precisaria ser implementado para que os usuários no Canadá e nos EUA possam interagir uns com os outros.
2. A equipe de desenvolvimento precisaria gerenciar dois recursos separados do Web PubSub, cada um com domínio e cadeia de conexão distintos.
3. Se ocorrer uma interrupção regional, o tráfego precisará ser direcionado para um recurso disponível.

Tudo isso tira os recursos de engenharia do foco na inovação de produtos.

Aproveitando o recurso de replicação geográfica

Com o recurso de replicação geográfica, a Contoso agora pode estabelecer uma réplica no Canada Central, superando efetivamente os desafios mencionados acima. A equipe de desenvolvedores fica feliz em descobrir que não precisa fazer nenhuma alteração no código. É tão fácil quanto clicar em alguns botões no portal do Azure. A equipe de desenvolvedores também está feliz em compartilhar com as partes interessadas que, como a Contoso planeja entrar no mercado europeu, eles simplesmente precisam adicionar outra réplica na Europa.

Como habilitar a replicação geográfica em um recurso Web PubSub

Portal

Para criar uma réplica em uma região do Azure, vá para o recurso Web PubSub e localize a folha Réplicas no portal do Azure e clique em Adicionar para criar uma réplica.

Após a criação, você poderá visualizar/editar sua réplica no portal clicando no nome da réplica.

Bicep

Use o Visual Studio Code ou seu editor favorito para criar um arquivo com o seguinte conteúdo e nomeie-o 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
  }
}

Implantar o arquivo Bicep usando a CLI do Azure

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

CLI

Atualize a extensão webpubsub para a versão mais recente e execute:

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

Preços e unidade de recursos

Cada réplica tem seu própriounit e autoscale settings.

A réplica é um recurso da camada Premium do Serviço Azure Web PubSub. Cada réplica é cobrada separadamente de acordo com sua própria unidade e tráfego de saída. A cota de mensagens gratuitas também é calculada separadamente.

No exemplo anterior, a Contoso adicionou uma réplica no Canada Central. A Contoso pagaria pela réplica no Canada Central de acordo com sua unidade e mensagem no Preço Premium.

Haverá taxas de saída para o tráfego de saída entre regiões. Se uma mensagem for transferida entre réplicas e enviada com êxito para um cliente ou servidor após a transferência, ela será cobrada como uma mensagem de saída.

Excluir uma réplica

Depois de criar uma réplica para um recurso Web PubSub, você poderá excluí-la a qualquer momento, se não for mais necessária.

Para excluir uma réplica no portal do Azure:

1. Navegue até o recurso Web PubSub e selecione a folha Réplicas . Clique na réplica que você deseja excluir.
2. Clique no botão Excluir na folha de visão geral da réplica.

Para excluir uma réplica usando a CLI do Azure:

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

Entenda como funciona o recurso de replicação geográfica

1. O cliente resolve o FQDN (Nome de Domínio Totalmente Qualificado) contoso.webpubsub.azure.com do serviço Web PubSub. Esse FQDN aponta para um Gerenciador de Tráfego, que retorna o Nome Canônico (CNAME) da instância regional do Web PubSub mais próxima.
2. Com esse CNAME, o cliente estabelece uma conexão de websocket com a instância regional (réplica).
3. As duas réplicas sincronizarão dados entre si. As mensagens enviadas para uma réplica seriam transferidas para outras réplicas, se necessário.
4. Caso uma réplica falhe na verificação de integridade conduzida pelo Gerenciador de Tráfego (TM), a TM excluirá o ponto de extremidade da instância com falha de seus resultados de resolução de domínio. Para obter detalhes, consulte abaixo Resiliência e recuperação de desastres

Observação

• No plano de dados, um recurso primário do Azure Web PubSub funciona de forma idêntica às suas réplicas

---

Resiliência e recuperação de desastre

O Serviço Azure Web PubSub utiliza um gerenciador de tráfego para verificações de integridade e resolução de DNS para suas réplicas. Em circunstâncias normais, quando todas as réplicas estiverem funcionando corretamente, os clientes serão direcionados para a réplica mais próxima. Por exemplo:

• Os clientes próximos serão eastus direcionados para a réplica localizada no eastus.
• Da mesma forma, os clientes próximos serão westus direcionados para a réplica no westus.

No caso de uma interrupção regional em Eastus (ilustrada abaixo), o gerente de tráfego detectará a falha na verificação de integridade dessa região. Em seguida, o DNS dessa réplica defeituosa será excluído dos resultados da resolução DNS do gerenciador de tráfego. Após uma duração TTL (Tempo de Vida de DNS), que é definida como 90 segundos, os clientes em eastus serão redirecionados para se conectar com a réplica no westus.

Assim que o problema for eastus resolvido e a região estiver online novamente, a verificação de integridade será bem-sucedida. Os clientes entrarão, então eastus , mais uma vez, direcionados para a réplica em sua região. Essa transição é suave, pois os clientes conectados não serão afetados até que as conexões existentes sejam fechadas.

Esse processo de failover e recuperação é automático e não requer intervenção manual.

Desabilitar ou habilitar o ponto de extremidade da réplica

Ao configurar uma réplica, você tem a opção de habilitar ou desabilitar seu ponto de extremidade. Se estiver desabilitada, a resolução DNS do FQDN primário não incluirá a réplica e, portanto, o tráfego não será direcionado para ela.

Você também pode habilitar a desativação do ponto de extremidade depois que ele for criado. Na folha de réplicas do recurso primário, clique no botão de reticências no lado direito da réplica e escolha Habilitar ponto de extremidade ou Desabilitar ponto de extremidade:

Antes de excluir uma replicação, considere desabilitar seu ponto de extremidade primeiro. Com o tempo, as conexões existentes serão desconectadas. Como nenhuma nova conexão está chegando, a replicação fica ociosa finalmente. Isso garante um processo de exclusão contínuo.

Esse recurso também é útil para solucionar problemas regionais.

Observação

• Devido ao cache DNS, pode levar vários minutos para que a atualização DNS entre em vigor.
• As conexões existentes permanecem inalteradas até que se desconectem.

Impacto no desempenho após habilitar o recurso de replicação geográfica

Depois que as réplicas forem habilitadas, os clientes distribuirão naturalmente com base em suas localizações geográficas. Embora o Web PubSub assuma a responsabilidade de sincronizar dados entre essas réplicas, você ficará satisfeito em saber que a sobrecarga associada à Carga do Servidor é mínima para os casos de uso mais comuns.

Especificamente, se seu aplicativo normalmente transmite para grupos maiores (tamanho >10) ou uma única conexão, o impacto da sincronização no desempenho é quase imperceptível. Se você estiver enviando mensagens para grupos pequenos (tamanho < 10), poderá notar um pouco mais de sobrecarga de sincronização.

Para garantir um gerenciamento de failover eficaz, é recomendável definir o tamanho da unidade de cada réplica para lidar com todo o tráfego. Como alternativa, você pode habilitar o dimensionamento automático para gerenciar isso.

Para obter mais avaliação de desempenho, consulte Desempenho.