Confiabilidade nos Hubs de Notificações do Microsoft Azure

Hubs de Notificação do Azure ajuda você a gerenciar notificações por push em vários sistemas de notificação de plataforma (PNS), como APNs (Serviço de Notificação por Push) da Apple, FCM (Firebase Cloud Messaging) e WNS (Serviço de Notificação por Push) do Windows.

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 Hubs de Notificação resilientes a várias possíveis interrupções e problemas, incluindo falhas transitórias, falhas na zona de disponibilidade, falhas em toda a região e manutenção do serviço. Ele também descreve as opções de backup e restauração e as principais informações sobre o SLA (contrato de nível de serviço) dos Hubs de Notificação.

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

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

Visão geral da arquitetura de confiabilidade

Hubs de Notificação do Azure é organizado em torno de namespaces e hubs de notificação. Um namespace é um limite de gerenciamento que contém um ou mais hubs. Os hubs representam pontos de extremidade para um aplicativo. Os dispositivos se registram nesses pontos de extremidade usando registros ou instalações, que permitem ao serviço enviar notificações push para os dispositivos. Para obter mais informações, consulte Gerenciamento de registro.

Os Hubs de Notificação enviam notificações por push para sistemas de notificação de plataforma (PNS), como APNs (Serviço de Notificação por Push) da Apple e FCM (Firebase Cloud Messaging). A entrega de notificação de ponta a ponta depende da disponibilidade dos Hubs de Notificação e do comportamento de provedores PNS downstream.

Para o planejamento de confiabilidade, é importante distinguir entre os seguintes tipos de dados que os Hubs de Notificação gerenciam:

• Metadados: Configuração de namespace e hub, incluindo informações de conexão e configuração de recuperação de desastre.
• Dados de registro: Registros e instalações de dispositivos que mapeiam usuários e dispositivos para tags e modelos.

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, consulte Recomendações para resolver falhas transitórias.

Os Hubs de Notificação manipulam automaticamente falhas transitórias que ocorrem ao se conectar a um PNS. No entanto, você é responsável por lidar com falhas transitórias quando os serviços ou os dispositivos dos usuários interagem com os Hubs de Notificação. Falhas transitórias podem ocorrer durante operações de registro, operações de envio de notificação e operações de gerenciamento. Siga estas diretrizes:

• Registros e instalações: Seus aplicativos em dispositivos devem tentar novamente as operações de registro e instalação que falharem devido a falhas transitórias. os SDKs fornecidos Microsoft manipulam novas tentativas automaticamente. Se você não puder usar os SDKs fornecidos, implemente a lógica de nova tentativa com backoff exponencial e jitter e, sempre que possível, garanta que as operações de registro sejam idempotentes.

  Criar ou atualizar uma instalação é idempotente, portanto você pode tentar novamente a operação com segurança. Quando possível, use instalações em vez de registros.

• As operações de gerenciamento e envio de notificação: Use um SDK fornecido Microsoft para enviar notificações por push e executar operações de gerenciamento. Esses SDKs tentarão novamente automaticamente quando ocorrerem falhas transitórias.

  Se você não puder usar os SDKs fornecidos, implemente a lógica de novas tentativas com backoff exponencial e jitter e, sempre que possível, torne idempotentes as operações de envio de notificaçõ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.

Em regiões que dão suporte a zonas de disponibilidade, os namespaces dos Hubs de Notificação dão suporte a uma configuração com redundância de zona . Os Hubs de Notificação habilitam automaticamente a redundância de zona para todos os namespaces em algumas regiões. Quando a redundância de zona está habilitada, Microsoft replica os metadados e os dados de registro em todas as zonas de disponibilidade na região.

Requirements

• Suporte à região:

  Os Hubs de Notificação habilitam automaticamente a redundância de zona para todos os namespaces nas regiões a seguir. Você não pode desabilitar a redundância de zona nessas regiões:

  Europa	Médio Oriente	Africa	Pacífico Asiático
  França Central	Catar Central	Norte da África do Sul	Norte da China 3
  Norte da Itália			Coreia Central
  Leste da Noruega
  Polônia Central
  Suécia Central
  Norte da Suíça

  Em outras regiões que dão suporte a Hubs de Notificação e têm zonas de disponibilidade, a redundância de zona é opcional. Você só pode habilitá-lo ao criar um namespace.

• Suporte à camada: Você pode usar zonas de disponibilidade com todas as camadas de Hubs de Notificação.

Custo

A redundância de zona gera uma cobrança adicional além do valor do nível de preço. Para obter mais informações, consulte os preços dos Hubs de Notificação.

Configurar o suporte à zona de disponibilidade

• Crie um namespace com redundância de zona: O processo para criar um novo namespace com redundância de zona depende da região que você usa:

  • Em regiões em que os Hubs de Notificação habilitam automaticamente a redundância de zona, você não precisa configurá-la.

    Importante

    Nessas regiões, os Hubs de Notificação sempre criam namespaces com redundância de zona habilitada, mesmo que uma implantação baseada em código, como um arquivo Bicep ou Azure Resource Manager modelo, especifique que a redundância de zona está desabilitada.

    Se você não quiser um namespace com redundância de zona, crie-o em uma região que dê suporte à redundância de zona opcional.

  • Em regiões em que a redundância de zona é opcional, você só pode habilitá-la quando criar um namespace. Para saber como configurar um novo namespace com redundância de zona, consulte Criar um hub de notificação Azure no portal Azure.

• Tornar um namespace existente com redundância de zona: O Notification Hubs não oferece suporte à migração local de um namespace existente para oferecer suporte a zonas de disponibilidade. Você precisa implantar um novo namespace e mover seus registros para esse namespace. Siga as orientações em Mover recursos entre regiões do Azure, o que também se aplica caso você implante o novo namespace na mesma região.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configurar um namespace dos Hubs de Notificação para redundância de zona e quando todas as zonas estiverem operacionais.

• Operação entre zonas: Os Hubs de Notificação distribuem e servem automaticamente solicitações usando a infraestrutura em qualquer zona da região.

• Replicação de dados entre zonas: Os dados de registro e os metadados são replicados de forma síncrona em todas as zonas da região especificada.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você configura um namespace dos Hubs de Notificação para redundância de zona e há uma interrupção em uma das zonas.

• Detecção e resposta: Microsoft detecta falhas de zona e gerencia o failover dentro da região. Você não precisa iniciar o failover.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: Operações de gerenciamento em voo, registros de dispositivo e novas solicitações para enviar notificações podem falhar durante o failover. Seus aplicativos devem tentar novamente as operações com falha seguindo as diretrizes transitórias de tratamento de falhas.

• Perda de dados esperada: A perda de dados não é esperada durante uma interrupção de zona única porque os Hubs de Notificação replicam de forma síncrona os dados de registro e configuração de namespace e hub entre zonas de disponibilidade.

  Essa replicação não é um backup. No modelo de responsabilidade compartilhada, você é responsável por fazer backup de dados de registro e instalação. Para obter mais informações, consulte Cópia de Segurança e Restauração.

• Tempo de inatividade esperado: Uma breve interrupção de serviço é possível enquanto Microsoft redireciona o tráfego. Siga as diretrizes transitórias de tratamento de falhas para preparar seus aplicativos para essas interrupções.

• Redistribuição: O serviço redireciona automaticamente solicitações para zonas íntegras.

Recuperação de zona

Quando a zona afetada se recupera, você não precisa executar nenhuma ação. Microsoft restaura e reequilibra a infraestrutura dos Hubs de Notificação para usar a zona recuperada.

Testar falhas em zonas

Você não pode acionar diretamente um failover de zona do Notification Hubs. Para testar o comportamento da carga de trabalho, execute testes de resiliência para repetições, idempotência e falhas de dependência em ambientes de não produção. Você também pode usar Azure Chaos Studio para testar os componentes do aplicativo ao redor.

Resiliência a falhas em toda a região

Os Hubs de Notificação fornecem recuperação de desastre de metadados replicando metadados de namespace entre regiões, mas não replicam os dados de registro do dispositivo. Essa funcionalidade requer intervenção manual durante uma interrupção de região e envolve algum tempo de inatividade para o hub de notificação.

Se você precisar reduzir o tempo de inatividade e a intervenção manual durante o failover, considere usar uma solução de várias regiões personalizada.

recuperação de desastre geográfico de metadados gerenciados por Microsoft

Os Hubs de Notificação dão suporte à recuperação de desastre de metadados gerenciados por Microsoft para uma região de Azure secundária. Se sua região primária tiver uma região emparelhada, você poderá selecionar essa região emparelhada. Independentemente do status de emparelhamento da região primária, você também pode escolher uma região secundária em uma lista de regiões de recuperação flexíveis. Os Hubs de Notificação replicam metadados de namespace, como o nome do namespace, as cadeias de conexão e outras informações críticas.

Microsoft é responsável por declarar um desastre e iniciar o failover. Quando isso acontece, Microsoft cria um novo namespace na região secundária. Como ele usa os metadados da região primária, os aplicativos podem se conectar a esse namespace usando o nome do namespace, o cadeia de conexão e os nomes de hub existentes.

Requirements

• Suporte à região: Em regiões Azure emparelhadas, seu namespace pode usar a região emparelhada Azure como a região secundária.

  Se o namespace estiver em uma região não emparelhada, ou se você quiser replicar dados para uma região diferente, poderá selecionar uma das seguintes regiões flexíveis de recuperação como região secundária:

  Américas	Europa	Africa	Pacífico Asiático
  Sul do Brasil	Europa Setentrional	Norte da África do Sul	Leste da Austrália
  Oeste dos EUA 2			Sudeste Asiático

• Suporte à camada: As opções de recuperação de desastre de metadados estão disponíveis em todas as camadas de Hubs de Notificação.

Custo

O Notification Hubs não cobra nada a mais para configurar ou usar a recuperação geográfica de desastres de metadados. No entanto, você paga pela largura de banda entre regiões usada para replicar metadados. Para obter detalhes de preços, consulte preços de largura de banda e preços dos Hubs de Notificação.

Configurar o suporte a várias regiões

• Habilite a recuperação de desastres geográficos dos metadados para um novo namespace: Siga o procedimento em Criar um hub de notificação do Azure no portal do Azure. Selecione a configuração de recuperação de desastre ao criar o namespace.

• Habilitar ou desabilitar a recuperação de desastre geográfico de metadados para um namespace existente: Siga o procedimento em Habilitar a recuperação de desastre para um namespace de Hubs de Notificação do Azure existente.

• Faça backup dos dados de registro do dispositivo: Consulte Exportar e importar registros de Hubs de Notificação do Azure em massa.

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

Esta seção descreve o que esperar quando você configurar um namespace do Notification Hubs para recuperação geográfica de desastres de metadados e quando as regiões primária e secundária estiverem operacionais.

• Operação entre regiões: A região primária atende a todas as solicitações. A região secundária não atende solicitações, a menos que ocorra failover.

• Replicação de dados entre regiões: Metadados, como o nome do namespace, a configuração do hub, as cadeias de conexão e outras informações críticas, são replicados de forma assíncrona entre regiões. Os dados de registro não são replicados. Você é responsável por exportá-lo regularmente para manter um backup.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura um namespace do Notification Hubs para a recuperação de desastre geográfica de metadados e ocorre uma interrupção na região primária.

• Detecção e resposta: Microsoft é responsável por detectar a falha da região e decidir se deve disparar o failover para a região secundária configurada.

• 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 solicitações em voo para o namespace na região primária podem falhar quando a região ficar offline. Os clientes devem repetir as operações após a conclusão do failover.

• Perda de dados esperada: Os metadados são preservados. Os dados de registro não são armazenados automaticamente em backup, mas você pode fazer backup por conta própria. Para obter mais informações, consulte Exportar e importar registros de Hubs de Notificação do Azure em massa. Caso contrário, os dados de registro ficam indisponíveis até que a região primária se recupere.

• Tempo de inatividade esperado: Leva algum tempo para a Microsoft acionar o failover dos metadados e, em seguida, para que o failover seja concluído. Embora o tempo possa variar, geralmente leva várias horas.

  Após a conclusão do failover, você será responsável por restaurar os backups de dados de registro.

• Redistribuição: Após o failover, as solicitações são roteadas para um namespace na região secundária que usa os dados replicados da região primária. Após a conclusão do failover, os clientes se conectam automaticamente ao namespace na região secundária.

Recuperação de região

Se a região primária se recuperar, talvez seja possível retornar ao namespace primário da região primária. O namespace primário manteria os dados de registro antes da interrupção. Esse seria um processo manual e Microsoft se comunicaria com você para explicar como isso funciona.

Depois que a região primária for recuperada, você precisará:

• Valide o estado do namespace e seus dados.
• Determine se é necessário sincronizar as alterações de dados de registro recentes da região secundária para a região primária.

Teste de falhas na região

Você não pode iniciar um failover geográfico. No entanto, você deve testar seus próprios procedimentos de recuperação de desastre. Verifique se os registros têm backup e se você pode restaurá-los para um novo namespace.

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

A recuperação de desastres geográfica de metadados gerenciada pela Microsoft replica apenas metadados. O recurso pode recuperar esses metadados para um namespace secundário, mas você é responsável por importar registros de dispositivo para esse namespace para que seu aplicativo possa continuar operando. Essa abordagem requer intervenção manual durante um desastre e envolve tempo de inatividade.

Se os seus objetivos de recuperação exigirem menos tempo de inatividade ou menos intervenção manual, você poderá implementar uma solução multirregional ativa-ativa personalizada. Implante um segundo namespace dos Hubs de Notificação em outra região Azure com antecedência.

• Failover: Como o segundo namespace é um recurso de trabalho, você pode implementar a lógica para detectar uma falha de região e alternar para esse namespace.

• Sincronização: Para manter um segundo hub de notificação em sincronia com o hub de notificação primário, use uma das seguintes opções:

  • Para instalações: Use um back-end de aplicativo que cria e atualiza instalações simultaneamente em ambos os hubs de notificação. As instalações permitem que você especifique seu próprio identificador de dispositivo exclusivo, que dá suporte a esse cenário de replicação. Para obter mais informações, consulte o exemplo do RedundantHub.

  • Para registros: Use um back-end de aplicativo que exporta regularmente registros do hub de notificação primário como um backup e os importa em massa para o hub de notificação secundário. Para obter mais informações, consulte Exportar e importar registros de Hubs de Notificação do Azure em massa.

  Como alternativa, se você não tiver um back-end, configure seu aplicativo para criar instalações em ambos os hubs quando o aplicativo for iniciado em dispositivos de destino. Os dispositivos criam novos registros em ambos os hubs de notificação. Eventualmente, o hub de notificação secundário tem todos os dispositivos ativos registrados.

• Registros e instalações expirados: O hub de notificação secundário pode ter registros e instalações expirados. Quando uma notificação por push é enviada para um identificador expirado, o Notification Hubs remove automaticamente o registro associado ou o registro de instalação no hub de notificação, com base na resposta recebida do servidor PNS. Você pode limpar registros expirados da solução de backup de sua escolha adicionando lógica personalizada que processa comentários de cada envio e remove registros e instalações expirados.

• Aplicativos não abertos: Há um período durante o qual dispositivos com aplicativos não abertos não recebem notificações.

• Custo: Se você usar seu próprio hub secundário para proteger os dados de registro, esse hub incorre em encargos de serviço normais. Da mesma forma, se você implantar quaisquer outros recursos do Azure em sua região secundária para dar suporte à recuperação, você pagará por eles às taxas normais do serviço.

Backup e restauração

Os Hubs de Notificação não fornecem um único recurso interno de backup e restauração para todos os dados armazenados em seu namespace. Você é responsável por combinar as seguintes abordagens:

• Use a infraestrutura como código (IaC), como Bicep, para definir seu namespace, hub e configuração de política. Armazene essas definições no controle do código-fonte para que você possa reimplantar os recursos quando necessário.
• Faça backup dos dados de registro do dispositivo exportando registros Hubs de Notificação do Azure em massa.

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.

Para Hubs de Notificação, o SLA de disponibilidade se aplica a namespaces que usam as camadas Básica e Standard.

Conteúdo relacionado

• Confiabilidade no Azure