Confiabilidade no serviço Azure Web PubSub

Azure Web PubSub Service é um serviço de mensagens totalmente gerenciado em tempo real que permite a comunicação bidirecional entre servidores e clientes usando o protocolo WebSocket. Um único recurso do Web PubSub pode ser dimensionado para um milhão de conexões WebSocket simultâneas. O serviço dá suporte a vários padrões de mensagens, incluindo difusão de servidor para cliente, mensagens para grupos nomeados, pub/sub de cliente para cliente e streaming de token de inteligência artificial.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o serviço de Azure Web PubSub resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, falhas de zona de disponibilidade e falhas em toda a região. Ele também descreve como o serviço lida com a manutenção e realça as principais informações sobre o SLA (contrato de nível de serviço) do Azure Web PubSub Service.

Recomendações de implantação de produção para confiabilidade

Para cargas de trabalho de produção, siga estas recomendações:

  • Use o nível Premium. A camada premium é resiliente a falhas de zona de disponibilidade em regiões com suporte e permite configurar a replicação geográfica.
  • Use o SDK do cliente Azure Web PubSub ao criar aplicativos cliente ou siga as diretrizes transitórias de tratamento de falhas reconectando-se com segurança. Falhas de zona, falhas de região e erros transitórios descartam todas as conexões ativas.
  • Habilite a replicação geográfica para proteger contra falhas em toda a região. Dimensione cada réplica com unidades suficientes para lidar com a carga total de tráfego esperada durante um evento de failover.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O recurso que você cria é um recurso do Web PubSub. Você configura um recurso com várias unidades, que representa a capacidade do recurso, incluindo o número máximo de conexões simultâneas. Para obter mais informações, consulte Performance guide for Azure Web PubSub Service.

Um recurso do Web PubSub tem um ponto de extremidade globalmente exclusivo semelhante a contoso.webpubsub.azure.com. Os clientes estabelecem conexões WebSocket com esse endpoint. Os servidores de aplicativos se conectam ao mesmo endpoint para enviar mensagens e receber eventos de clientes.

Para obter mais informações, consulte os internos do serviço Azure Web PubSub.

Arquitetura física

Azure Web PubSub Service gerencia o estado da conexão WebSocket e o roteamento de mensagens em um conjunto de recursos de computação. Microsoft gerencia a infraestrutura subjacente. Você não vê ou interage diretamente com VMs individuais que o serviço usa ou outros componentes de infraestrutura.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

WebSocket é um protocolo de conexão de longa duração. Eventos de rede transitórios, reinicializações de infraestrutura de back-end e operações de manutenção de serviço podem descartar uma conexão ativa. Uma reconexão básica restaura a conexão, mas sem lógica adicional o cliente perde mensagens que estavam em trânsito ou enfileiradas durante a interrupção.

Azure Web PubSub Service resolve esse problema por meio de subprotocols confiáveis que ficam sobre a conexão WebSocket bruta. Os subprotocolos acompanham a sequência de mensagens e o estado de conexão para que, quando uma conexão cair, o cliente renegocie com o serviço e retome do ponto em que parou.

Normalmente, não há perda de mensagens depois que um conectão é removido e reconectado. No entanto, há algumas situações em que a perda de mensagens pode ocorrer. Por exemplo, se o cliente se desconectar por mais de um minuto e se reconectar com a mesma ID de conexão, a operação de reconexão mostrará um status de falha para indicar que a perda de mensagem pode acontecer.

Para aproveitar os subprotocols confiáveis, siga estas recomendações:

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Azure Web PubSub Service dá suporte a implantações com redundância de zona quando você usa a camada Premium. Quando você cria ou atualiza um recurso do Web PubSub de camada Premium em uma região que dá suporte a zonas de disponibilidade, a redundância de zona é habilitada automaticamente. O serviço distribui sua infraestrutura em várias zonas de disponibilidade na região. Se uma zona falhar, o serviço roteia o tráfego para a infraestrutura em uma zona saudável.

Diagrama que mostra um serviço de Azure Web PubSub com redundância de zona, espalhado por várias zonas de disponibilidade.

Requisitos

  • Suporte à região: Há suporte para redundância de zona na maioria das regiões em que ambas as condições se aplicam:

    • Serviço Azure Web PubSub está disponível. Para obter uma lista de regiões em que o serviço está disponível, consulte a Disponibilidade do Produto por Região.
    • A região oferece suporte a zonas de disponibilidade. Para obter uma lista de regiões com zonas de disponibilidade, consulte Azure lista de regiões.

    No entanto, o Oeste do Japão atualmente não dá suporte à redundância de zona para Azure Web PubSub.

  • Camada: A redundância de zona está disponível na camada Premium.

Custo

A redundância de zona não acrescenta custo, e você paga a taxa padrão da camada Premium. Para obter mais informações, consulte Azure Web PubSub preços do serviço.

Configurar o suporte à zona de disponibilidade

A redundância de zona não requer nenhuma configuração além de selecionar a camada Premium. Ele é habilitado automaticamente em ambos os casos:

  • Crie um novo recurso do Web PubSub com redundância de zona. Selecione um SKU de camada Premium ao criar o recurso. Para obter mais informações, consulte Criar um recurso Azure Web PubSub.

  • Atualize um recurso existente para a camada Premium. A redundância de zona é habilitada automaticamente quando você atualiza um recurso existente para um SKU de camada Premium. A atualização do Standard para o Premium não causa tempo de inatividade do serviço. Para obter mais informações, consulte Escala uma instância do Serviço Azure Web PubSub.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configura um recurso de Azure Web PubSub para redundância de zona e todas as zonas de disponibilidade estão operacionais.

  • Cross-zone operation: O Azure Web PubSub Service gerencia automaticamente a distribuição de conexões e operações entre zonas de disponibilidade. A infraestrutura em várias zonas processa o tráfego em um modelo ativo-ativo. Você não precisa configurar nada para aproveitar esse comportamento. O serviço roteia mensagens entre instâncias entre zonas automaticamente, de modo que uma mensagem enviada por um cliente em uma zona é entregue aos clientes conectados em qualquer outra zona.

  • Replicação de dados entre zonas: Azure Web PubSub Service não persiste dados do cliente. O serviço mantém metadados de sessão, como informações de estado de conexão e sequência de mensagens para conexões ativas. Esses metadados são replicados de forma síncrona entre zonas de disponibilidade.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você configura um recurso de Azure Web PubSub para redundância de zona e há uma interrupção em uma das zonas de disponibilidade.

  • Detection and response: A plataforma Azure Web PubSub Service é responsável por detectar uma falha em uma zona de disponibilidade. Você não precisa executar nenhuma ação para iniciar um failover de zona.
  • Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Durante uma falha de zona, as conexões WebSocket ativas com a infraestrutura na zona afetada são descartadas. Se seus clientes lidarem com falhas transitórias adequadamente, como reconectar após um curto período de tempo, eles normalmente evitam um impacto significativo.

  • Expected data loss: O Azure Web PubSub Service não persiste mensagens; portanto, não se espera que uma falha de zona cause perda de dados no serviço Azure Web PubSub. No entanto, quaisquer conexões ativas são interrompidas durante um evento de queda da zona, e, portanto, qualquer dado que está sendo transmitido no momento pode ser perdido.

    Se os editores usarem um SDK do cliente Azure Web PubSub ou implementarem os subprotocols confiáveis, suas mensagens serão confirmadas pelo serviço após o serviço recebê-las. Quando uma mensagem é reconhecida, ela é replicada em todas as zonas de disponibilidade, portanto, a falha na zona do editor não faz com que a mensagem seja perdida. No entanto, se um assinante não receber a mensagem antes de ser descartada, ele poderá não receber a mensagem.

  • Tempo de inatividade esperado: A reconexão de conexões ativas descartadas normalmente leva alguns segundos. Os clientes que implementam a lógica de reconexão passam por interrupção mínima.

  • Redistribution: Azure Web PubSub Service detecta a perda da zona e redistribui automaticamente o tráfego entre as zonas íntegras. Você não precisa realizar nenhuma ação.

Recuperação de zona

Quando uma zona de disponibilidade é recuperada, Azure Web PubSub Serviço a reintegra automaticamente na topologia de serviço ativa. Você não precisa tomar nenhuma medida para a recuperação da zona.

Após a recuperação de uma zona, novas conexões poderão ser direcionadas para a infraestrutura na zona recuperada. Conexões existentes não serão movidas ou rebalanceadas para a zona recuperada, mas serão gradualmente rebalanceadas à medida que forem suspensas e reconectadas ao longo do tempo. O desequilíbrio de conexão entre zonas não tem nenhum impacto na carga de trabalho.

Testar falhas em zonas

Azure Web PubSub Service gerencia o roteamento de tráfego, o failover e a recuperação de zona automaticamente para recursos da camada Premium com redundância de zona. Você não precisa iniciar nada. Como a redundância de zona é totalmente gerenciada, você não precisa validar os processos de falha da zona de disponibilidade.

Resiliência a falhas em toda a região

Azure Web PubSub Service é um serviço de região única. Se a região ficar indisponível, o recurso Web PubSub também ficará indisponível.

Para proteger seu aplicativo contra uma falha em toda a região, você pode usar a replicação geográfica, que está disponível na camada Premium. Como alternativa, você pode criar uma solução de várias regiões personalizada implantando vários recursos do Web PubSub em regiões diferentes.

Geo-replication

A replicação geográfica permite adicionar replicas do recurso Web PubSub em outras regiões Azure. Todas as réplicas compartilham um único ponto de extremidade (contoso.webpubsub.azure.com). Por trás desse ponto de extremidade, Gerenciador de Tráfego do Azure usa o roteamento baseado em DNS para direcionar cada cliente para a réplica regional saudável mais próxima. Se uma região falhar, o Gerenciador de Tráfego detectará a falha por meio de verificações de integridade e interromperá o direcionamento de clientes para essa réplica. Novas conexões de cliente são roteadas automaticamente para a réplica saudável mais próxima disponível.

Diagrama que mostra Azure Web PubSub configurado para replicação geográfica em duas regiões.

A região em que você criou o recurso Web PubSub é chamada de região primária e sua réplica é a réplica primária. O plano de controle do recurso primário gerencia a configuração do recurso do Web PubSub.

Requisitos

  • Region support: Você pode adicionar réplicas em qualquer região em que Azure Web PubSub Service esteja disponível.
  • Camada: Você deve usar a camada Premium para habilitar a replicação geográfica.
  • Limite de réplica: Cada recurso primário do Web PubSub dá suporte a até oito réplicas.

Considerações

  • Herança de configuração: As réplicas herdam a maioria das configurações do recurso primário. Determinadas configurações devem ser configuradas separadamente em cada réplica. Para obter a lista completa de configurações que não são herdadas, consulte Geo-replication em Azure Web PubSub.

  • Alterações de configuração: O plano de controle primário, na região primária, processa quaisquer alterações de configuração no recurso Do Web PubSub. Se o plano de controle primário não estiver disponível, você não poderá atualizar a configuração de recursos, embora as réplicas existentes continuem a processar o tráfego de dados sem interrupção.

Custo

Cada réplica é cobrada separadamente com base na sua própria contagem de unidades e no volume de mensagens de saída. Se uma mensagem for transferida entre réplicas e entregue a um cliente ou servidor em outra região, ela será cobrada como uma mensagem de saída. Para obter mais informações, consulte Azure Web PubSub preços do serviço.

Configurar a replicação geográfica

Para adicionar ou remover uma réplica a um recurso do Web PubSub, consulte Geo-replication em Azure Web PubSub.

Planejamento e gerenciamento de capacidade

Cada réplica manipula o tráfego de forma independente. Durante um failover regional, os clientes da região com falha se reconectam à réplica íntegra mais próxima. Para garantir que as réplicas sobreviventes tenham capacidade suficiente para absorver essa carga extra, configure cada réplica com unidades que possam lidar com o tráfego total esperado da carga de trabalho, não apenas a parte que ela normalmente atende.

Como alternativa, habilite o dimensionamento automático em cada réplica para que as unidades possam ser dimensionadas automaticamente em resposta a uma carga mais alta. O dimensionamento automático continua funcionando quando uma réplica secundária não está disponível, mas o dimensionamento automático não funciona se o plano de controle primário não estiver disponível. Para obter mais informações sobre o dimensionamento automático, consulte Escalizar automaticamente unidades de um serviço Azure Web PubSub.

Para obter diretrizes gerais sobre sobreprovisionamento como estratégia, consulte Gerenciar capacidade por excesso de provisionamento.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando você configura Azure Web PubSub Service para replicação geográfica e todas as regiões estão operacionais.

  • Operação entre regiões: Gerenciador de Tráfego do Azure roteia cada cliente para a réplica regional saudável mais próxima. Clientes em diferentes áreas geográficas podem se conectar a réplicas diferentes. O Serviço Web PubSub sincroniza mensagens entre réplicas para que os clientes conectados a qualquer réplica possam se comunicar entre si.

  • Replicação de dados entre regiões: Quando uma mensagem é enviada para uma réplica, o serviço transfere essa mensagem de forma síncrona para outras réplicas para que os clientes conectados em outro lugar possam recebê-la. A sobrecarga de sincronização é mínima para a maioria dos padrões comuns de mensagens, como difusão para grandes grupos ou mensagens de uma única conexão. Mensagens para grupos pequenos (menos de 10 membros) podem produzir uma sobrecarga de sincronização ligeiramente maior.

    Azure Web PubSub Serviço não persiste mensagens; somente a entrega ativa é sincronizada entre réplicas.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura o Serviço Azure Web PubSub para replicação geográfica e há uma interrupção em uma das regiões de réplica.

  • Detecção e resposta: O Serviço Web PubSub é responsável por detectar uma falha em uma região e redirecionar automaticamente o tráfego de entrada para uma réplica em uma das outras regiões configuradas.

  • Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:

  • Solicitações ativas: As conexões WebSocket ativas com a réplica na região com falha são descartadas. Os clientes devem se reconectar após o failover da réplica.

  • Expected data loss: Azure Web PubSub Service não persiste mensagens. As mensagens que estavam em trânsito para clientes na região com falha no momento da falha podem ser perdidas. Nenhuma perda de dados persistente é esperada porque o serviço não armazena dados do cliente.

  • Tempo de inatividade esperado: Gerenciador de Tráfego do Azure executa verificações de integridade em cada réplica. Quando uma interrupção em uma região faz com que uma réplica falhe em seu check de integridade, o Gerenciador de Tráfego remove o endpoint dessa réplica dos resultados de resolução DNS. Depois de remover o ponto de extremidade, o TTL DNS de 90 segundos deve decorrer antes que os clientes vejam os registros DNS com as atualizações. No total, a transição normalmente leva alguns minutos. Clientes bem projetados que implementam a lógica de reconexão podem retomar a operação normal após se reconectar à réplica saudável.

    Se o plano de controle primário não estiver disponível, você não poderá fazer alterações na configuração do recurso do Web PubSub ou em suas réplicas. No entanto, as conexões WebSocket continuam funcionando em réplicas íntegras.

  • Redistribuição: Gerenciador de Tráfego do Azure direciona a solicitação de entrada para réplicas saudáveis. No entanto, se um cliente tentar se reconectar antes de o Gerenciador de Tráfego do Azure ter detectado o failover da réplica e as entradas de DNS atualizadas terem se propagado até o cliente, a tentativa de reconexão de um cliente poderá continuar a atingir a região indisponível e pode falhar.

    Depois que a atualização DNS se propaga, os clientes que se reconectam são automaticamente direcionados para a réplica saudável mais próxima.

Recuperação de região

Quando a região com falha é recuperada, a verificação de integridade do Gerenciador de Tráfego detecta a réplica restaurada e reinclui seu endpoint no processo de resolução do DNS. Os clientes atualmente conectados a outras réplicas não são afetados e permanecem conectados até que se desconectem. Novas conexões são redirecionadas para a réplica da região recuperada quando ela é a réplica saudável mais próxima.

Teste de falhas na região

Para simular uma falha em região e testar o comportamento de reconexão do aplicativo cliente, você pode desabilitar o endpoint de uma réplica. Essa ação faz com que o Gerenciador de Tráfego pare o roteamento do tráfego para essa réplica, o que permite observar como os clientes se comportam quando a réplica à qual se conectam fica indisponível. Para obter etapas detalhadas, consulte Desabilitar ou habilitar o ponto de extremidade da réplica.

Soluções de várias regiões personalizadas para resiliência

Se você precisar de resiliência entre regiões, mas não estiver usando replicação geográfica, poderá implantar e gerenciar recursos separados do Web PubSub em várias regiões e implementar sua própria lógica de failover no servidor de aplicativos. Essa abordagem é mais complexa do que a replicação geográfica e não dá suporte a failover sem interrupção para conectividade cliente a cliente. Para obter uma visão geral detalhada da arquitetura, padrões de failover e diretrizes de teste, consulte Recuperação de desastres e resiliência no Serviço Azure Web PubSub.

Backup e restauração

Azure Web PubSub Service é um serviço de mensagens sem estado. Ele não persiste as mensagens do cliente e não tem nenhuma funcionalidade de backup ou restauração.

Para proteger sua configuração de recursos, defina os recursos do Web PubSub usando a infraestrutura como código (como modelos de Bicep ou ARM) e armazene essas definições no controle do código-fonte. Se você precisar recriar um recurso, reimplante-o da configuração armazenada.

Resiliência à manutenção do serviço

A Microsoft aplica regularmente as atualizações de serviço e executa outras manutenções. A plataforma Azure manipula essas atividades automaticamente, garantindo que a manutenção seja perfeita e transparente para você. Não se espera tempo de inatividade durante eventos de manutenção, a menos que você tenha sido avisado por meio de manutenção planejada do Integridade do Serviço do Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Conteúdo relacionado

  • Last updated on