Confiabilidade no Serviço do Azure SignalR

Serviço do Azure SignalR é um serviço totalmente gerenciado que permite a comunicação bidirecional em tempo real em aplicativos Web e móveis. Ele abstrai o mecanismo de transporte subjacente. Quando WebSockets estiverem disponíveis, o serviço os usará. Quando não estão, ele volta para Eventos Enviados pelo Servidor ou long polling. Essa abstração significa que o código do cliente e do servidor pode se comunicar em tempo real sem estar vinculado a um protocolo de transporte específico.

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 os Serviço do Azure SignalR resilientes a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também destaca as principais informações sobre o SLA (contrato de nível de serviço) do Serviço do Azure SignalR.

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

Para cargas de trabalho de produção, recomendamos que você:

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 Serviço do SignalR. 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 Serviço do Azure SignalR.

Serviço do Azure SignalR dá suporte a dois modos service. No modo padrão, os servidores de aplicativos se conectam ao recurso Serviço do Azure SignalR e contêm a lógica do hub. No modo sem servidor, o serviço se integra ao Azure Functions e o Functions atua como manipuladores de mensagens controlados por eventos para que você não gerencie servidores de aplicativos diretamente. Para obter mais informações, confira Modo de serviço no serviço do Azure SignalR.

Um recurso de Serviço do SignalR tem um ponto de extremidade globalmente exclusivo semelhante ao contoso.service.signalr.net. Os clientes estabelecem conexões com esse endpoint. Os servidores de aplicativos se conectam ao mesmo endpoint para enviar mensagens e receber eventos de clientes.

Arquitetura física

Serviço do Azure SignalR gerencia o estado da conexão 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.

Serviço do Azure SignalR usa conexões de longa duração entre clientes, servidores de aplicativos e o serviço. Essas conexões podem ser descartadas devido a falhas transitórias, como instabilidade de rede, reconfigurações de balanceador de carga ou suspensões de abas do navegador. Projete seus aplicativos cliente e servidores de aplicativos para lidar com quedas de conexão e se reconectar automaticamente.

Os SDKs do Serviço do Azure SignalR incluem tratamento de reconexão interna para conexões de servidor ao serviço. A reconexão do lado do cliente depende da biblioteca de clientes que você usa. Os clientes do SignalR do ASP.NET Core oferecem suporte à reconexão com estado, o que permite que um cliente retome sua conexão anterior sem perder o estado se ele se reconectar rapidamente usando a mesma ID de Conexão. Se a reconexão resultar em uma nova ID de conexão, por exemplo, após uma interrupção mais longa, o serviço tratará o cliente como uma nova conexão. Nesse caso, o cliente precisa se juntar novamente a todos os grupos em que esteve anteriormente e restaurar qualquer estado de sessão.

Para obter diretrizes detalhadas sobre como desenhar seu aplicativo para lidar com desconexões e reconexões de clientes, consulte Compreendendo as desconexões e reconexões de clientes no Serviço do Azure SignalR.

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.

Serviço do Azure SignalR dá suporte a implantações com redundância de zona na camada Premium. Quando você cria ou atualiza para um recurso de camada Premium em uma região que dá suporte a zonas de disponibilidade, Serviço do Azure SignalR distribui automaticamente sua capacidade de computação em todas as zonas de disponibilidade na região. Se uma zona de disponibilidade falhar, Serviço do Azure SignalR roteia novas conexões para instâncias nas zonas íntegras restantes.

Requirements

• 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 do Azure SignalR 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 Serviço do Azure SignalR.

• 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 preços do Serviço Azure SignalR.

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 recurso de Serviço do SignalR com redundância de zona. Selecione um SKU de camada Premium ao criar o recurso. Para obter mais informações, consulte os guias de início rápido, como Quickstart: criar uma sala de chat usando Serviço do SignalR.

• 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 Alterar a camada do serviço Azure SignalR.

Comportamento quando todas as zonas estão saudáveis

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

• Operação entre zonas: O Serviço do Azure SignalR gerencia automaticamente a distribuição das conexões e operações entre as 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.

• A replicação de dados de zona cruzada: Serviço do Azure SignalR não persiste os dados do cliente, portanto, não há dados a serem replicados entre zonas. O estado da conexão é efêmero e está associado a cada conexão ativa.

Comportamento durante uma falha de zona

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

• Detecção e resposta: A plataforma Serviço do Azure SignalR é 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 ativas com os nós na zona afetada são desconectadas. 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: Serviço do Azure SignalR não persiste mensagens, portanto, não é esperado que uma falha de zona cause perda de dados no Azure SignalR service. 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.

• 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: Serviço do Azure SignalR 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, Serviço do Azure SignalR 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

O Serviço do Azure SignalR gerencia automaticamente o roteamento de tráfego, o failover e a recuperação de zona 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

Serviço do Azure SignalR é um serviço de região única. Se a região ficar indisponível, seu recurso de Serviço do SignalR também não estará disponí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 de Serviço do SignalR em regiões diferentes.

Geo-replication

A replicação geográfica permite adicionar replicas do recurso Serviço do SignalR em outras regiões Azure. Gerenciador de Tráfego do Azure usa o roteamento baseado em DNS para direcionar cada cliente para a réplica regional íntegra 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.

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

Requirements

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

Considerations

• 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 Serviço do Azure SignalR.

• Configuration changes: O plano de controle primário, na região primária, processa as alterações de configuração no recurso Serviço do SignalR. 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. As taxas de saída entre regiões se aplicam quando as mensagens são transferidas entre réplicas e entregues a clientes ou servidores em outra região. Para obter mais informações, consulte preços do Serviço do Azure SignalR.

Configurar a replicação geográfica

Para adicionar ou remover uma réplica a um recurso de Serviço do SignalR, consulte Geo-replication em Serviço do Azure SignalR.

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 dimensionamento automático, consulte Autoscaling no Serviço do Azure SignalR.

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 Serviço do Azure SignalR para replicação geográfica e todas as réplicas 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. Serviço do SignalR 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.

  Serviço do Azure SignalR 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 Serviço do Azure SignalR para replicação geográfica e há uma interrupção em uma das regiões de réplica.

• Detection and response: Serviço do SignalR é 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, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: As conexões 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: Serviço do Azure SignalR 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 nenhuma alteração na configuração do recurso Serviço do SignalR ou suas réplicas. No entanto, as conexões 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 personalizadas de várias regiões 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 Serviço do SignalR separados 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 tolerância a falhas e diretrizes de testes, consulte Resiliência e recuperação de desastres no Serviço do Azure SignalR.

Backup e restauração

Serviço do Azure SignalR é 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 seus recursos de Serviço do SignalR 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.

Durante a manutenção planejada, Serviço do Azure SignalR usa uma estratégia de desligamento normal para reduzir o impacto sobre os clientes conectados. As conexões são gradualmente desconectadas por uma janela de tempo definida, permitindo que os clientes se reconectem progressivamente em vez de todas de uma vez. Para obter mais informações, consulte Desconexões durante a manutenção do serviço.

Eventos de manutenção são exibidos para seus clientes à medida que a conexão cai. Verifique se os aplicativos cliente implementam a lógica de reconexão para que possam se recuperar de desconexões relacionadas à manutenção sem interrupção visível do usuário.

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

• Relibilidade em Azure
• visão geral Serviço do Azure SignalR
• Geo-replicação no Serviço SignalR do Azure
• Resiliência e recuperação de desastres no Serviço do Azure SignalR
• Compreensão das desconexões e reconexões de clientes no Serviço do Azure SignalR