Confiabilidade nos Hubs de Notificação do Azure

O Hubs de Notificação do Microsoft Azure ajuda-o a gerir notificações push em múltiplos sistemas de notificação de plataforma (PNS), como o Apple Push Notification Service (APNs), o Firebase Cloud Messaging (FCM) e o Windows Push Notification Service (WNS).

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 Centros de Notificação resilientes a vários potenciais cortes e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade, falhas regionais e manutenção de serviços. Descreve também as opções de backup e restauro e informações essenciais sobre o acordo de nível de serviço (SLA) dos Notification Hubs.

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

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

Visão geral da arquitetura de confiabilidade

O Hubs de Notificação do Microsoft Azure está organizado em torno de namespaces e notifications hubs. Um namespace é uma fronteira de gestão que contém um ou mais hubs. Os hubs representam os pontos finais de uma aplicação. Os dispositivos registam-se nesses endpoints através de registos ou instalações, o que permite ao serviço enviar notificações push para os dispositivos. Para mais informações, consulte Gestão de Registos.

O Notification Hubs envia notificações push para sistemas de notificação da plataforma (PNS), como o Apple Push Notification Service (APNs) e o Firebase Cloud Messaging (FCM). A entrega de notificações de ponta a ponta depende da disponibilidade dos Centros de Notificação e do comportamento dos fornecedores PNS a jusante.

Para o planeamento da fiabilidade, é importante distinguir entre os seguintes tipos de dados que o Notification Hubs gere:

• Metadados: Configuração do namespace e do hub, incluindo informação de ligação e configuração de recuperação de desastres.
• Dados de registo: Registos e instalações de dispositivos que associam utilizadores e dispositivos a etiquetas e modelos.

Resiliência a falhas transitórias

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

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

Os Centros de Notificação tratam automaticamente das falhas transitórias que ocorrem ao ligar a um PNS. No entanto, és responsável por tratar falhas transitórias quando os teus serviços ou dispositivos dos utilizadores interagem com os Centros de Notificações. Falhas transitórias podem ocorrer durante operações de registo, operações de envio de notificações e operações de gestão. Siga estas orientações:

• Registos e instalações: As suas aplicações nos dispositivos devem tentar novamente operações de registo e instalação que falham devido a falhas transitórias. Os SDKs fornecidos pela Microsoft tratam automaticamente as novas tentativas. Se não conseguires usar os SDKs fornecidos, implementa lógica de repetição com backoff exponencial e jitter, e garante que as operações de registo sejam idempotentes sempre que possível.

  Criar ou atualizar uma instalação é idempotente, por isso pode tentar novamente a operação em segurança. Sempre que possível, utilize instalações em vez de registos.

• Envio de notificações e operações de gestão: Use um SDK fornecido pela Microsoft para enviar notificações push e realizar operações de gestão. Estes SDKs repetem automaticamente a tentativa em caso de falhas transitórias.

  Se não conseguir usar os SDKs fornecidos, implemente lógica de nova tentativa com um backoff exponencial e jitter, e garanta que as operações de envio de notificações sejam idempotentes sempre que possível.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Em regiões que suportam zonas de disponibilidade, os espaços de nomes do Notification Hubs suportam uma configuração com redundância entre zonas. Os Hubs de Notificações ativam automaticamente a redundância de zonas para todos os namespaces em algumas regiões. Quando a redundância de zonas está ativada, a Microsoft replica tanto os metadados como os dados de registo em todas as zonas de disponibilidade da região.

Requisitos

• Apoio regional:

  Os Centros de Notificações ativam automaticamente a redundância de zonas para todos os namespaces nas regiões seguintes. Não podes desativar a redundância de zonas nestas regiões:

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

  Noutras regiões que suportam Centros de Notificação e têm zonas de disponibilidade, a redundância de zonas é opcional. Só pode ativar quando criar um namespace.

• Suporte por níveis: Pode usar zonas de disponibilidade com todos os níveis de Centros de Notificações.

Custo

A redundância por zona implica um custo adicional para além do preço do escalão. Para mais informações, consulte os preços dos Centros de Notificação.

Configurar o suporte à zona de disponibilidade

• Crie um novo espaço de nomes com redundância entre zonas: O processo para criar um novo espaço de nomes com redundância entre zonas depende da região que está a utilizar:

  • Em regiões onde os Centros de Notificações ativam automaticamente a redundância de zonas, não é necessário configurá-la.

    Importante

    Nestas regiões, os Centros de Notificação criam sempre namespaces com a redundância de zonas ativada, mesmo que uma implementação baseada em código, como um ficheiro Bicep ou um modelo do Azure Resource Manager, especifique que a redundância de zona está desativada.

    Se não quiseres um namespace redundante de zonas, cria-o numa região que suporte redundância de zonas opcional.

  • Em regiões onde a redundância de zonas é opcional, só pode ativar quando cria um namespace. Para saber como configurar um novo namespace com redundância de zonas, consulte Criar um hub de notificações do Azure no portal Azure.

• Tornar uma zona de namespace existente redundante: O Notification Hubs não suporta a migração no local de um namespace existente para o suporte de zonas de disponibilidade. Precisa de implementar um novo namespace e mover os seus registos para esse namespace. Segue as orientações em Mover recursos entre regiões do Azure, que também se aplicam se implementares o novo namespace na mesma região.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que pode esperar ao configurar um espaço de nomes do Notification Hubs para redundância entre zonas e quando todas as zonas estão operacionais.

• Operação entre zonas: O Notification Hubs distribui e serve automaticamente pedidos utilizando infraestruturas em qualquer zona da região.

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

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando configuras um namespace nos Centros de Notificações para redundância de zonas, e há uma falha numa das zonas.

• Deteção e resposta: A Microsoft deteta falhas de zona e gere o failover dentro da região. Não precisas de iniciar o failover.

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

• Pedidos ativos: Operações de gestão em voo, registos de dispositivos e novos pedidos para enviar notificações podem falhar durante o failover. As suas aplicações devem tentar novamente operações falhadas seguindo as orientações de tratamento de falhas transitórias.

• Perda de dados esperada: A perda de dados não é esperada durante uma interrupção de zona única porque os Centros de Notificação replicam sincronizadamente os dados de configuração e registo do namespace e do hub entre zonas de disponibilidade.

  Esta replicação não é uma cópia de segurança. No modelo de responsabilidade partilhada, és responsável por fazer backup dos dados de registo e instalação. Para mais informações, consulte Cópia de segurança e restauração.

• Tempo de inatividade previsto: É possível uma breve interrupção do serviço enquanto a Microsoft redireciona o tráfego. Siga as orientações para o tratamento de falhas transitórias para preparar as suas candidaturas para estas interrupções.

• Redistribuição: O serviço redireciona automaticamente os pedidos para zonas saudáveis.

Recuperação de zona

Quando a zona afetada recupera, não precisas de tomar qualquer medida. A Microsoft restaura e reequilibra a infraestrutura dos Notifications Hubs para utilizar a zona recuperada.

Teste de falhas de zona

Não é possível desencadear diretamente um failover de zona do Notification Hubs. Para testar o comportamento da sua carga de trabalho, execute testes de resiliência para novas tentativas, idempotência e falhas nas dependências em ambientes de não produção. Também pode usar o Azure Chaos Studio para testar componentes de aplicação envolventes.

Resiliência a falhas em toda a região

O Notification Hubs fornece recuperação de desastres de metadados replicando metadados do namespace entre regiões, mas não replica dados de registo de dispositivos. Esta funcionalidade requer intervenção manual durante uma interrupção regional e implica algum tempo de inatividade para o seu centro de notificações.

Se precisar de reduzir o tempo de inatividade e a intervenção manual durante o failover, considere usar uma solução multirregional personalizada.

Recuperação após desastre geográfico de metadados gerida pela Microsoft

O Notification Hubs suporta a recuperação de desastres de metadados gerida pela Microsoft para uma região secundária do Azure. Se a sua região principal tiver uma região emparelhada, pode selecionar essa região emparelhada. Independentemente do estado de emparelhamento da sua região principal, também pode escolher uma região secundária a partir de uma lista de regiões de recuperação flexíveis. O Notification Hubs replica então metadados do namespace, como o nome do namespace, strings de ligação e outras informações críticas.

A Microsoft é responsável por declarar um desastre e iniciar o failover. Quando isso acontece, a Microsoft cria um novo namespace na região secundária. Como utiliza os metadados da região principal, as aplicações podem ligar-se a esse espaço de nomes usando o nome do espaço de nomes, a cadeia de ligação e os nomes do hub existentes.

Requisitos

• Apoio regional: Em regiões Azure emparelhadas, o seu namespace pode usar a região pareada Azure como região secundária.

  Se o seu namespace estiver numa região não emparelhada, ou se quiser replicar dados para outra região, pode selecionar uma das seguintes regiões flexíveis de recuperação como região secundária:

  Américas	Europa	Africa	Ásia-Pacífico
  Sul do Brasil	Europa do Norte	Norte da África do Sul	Leste da Austrália
  E.U.A. Oeste 2			Sudeste Asiático

• Suporte por níveis: As opções de recuperação de desastres de metadados estão disponíveis em todos os níveis dos Centros de Notificação.

Custo

O Notification Hubs não cobra um valor adicional para configurar ou utilizar a recuperação após desastre geográfico dos metadados. No entanto, paga pela largura de banda interregional usada para replicar os metadados. Para detalhes de preços, consulte Preços da largura de banda e preços dos Centros de Notificação.

Configurar suporte multirregional

• Ative a recuperação após desastre geográfico dos metadados para um novo espaço de nomes: Siga o procedimento em Criar um hub de notificações do Azure no portal do Azure. Selecione a configuração de recuperação de desastres ao criar o namespace.

• Ative ou desative a recuperação após desastre geográfico dos metadados para um espaço de nomes existente: Siga o procedimento descrito em Ativar a recuperação após desastre para um espaço de nomes existente do Hubs de Notificação do Microsoft Azure.

• Faça backup dos dados de registo do seu dispositivo: Veja Exportar e importar registos do Hubs de Notificação do Microsoft Azure em massa.

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

Esta secção descreve o que pode esperar quando configura um espaço de nomes do Notification Hubs para recuperação após desastre geográfico dos metadados e quando as regiões primária e secundária estão ambas operacionais.

• Operação entre regiões: A região principal serve todos os pedidos. A região secundária não serve pedidos a menos que ocorra failover.

• Replicação de dados entre regiões: Metadados, como o nome do namespace, configuração do hub, cadeias de ligação e outras informações críticas, são replicados de forma assíncrona entre regiões. Os dados de registo não são replicados. És responsável por exportar isso regularmente para manter uma cópia de segurança.

Comportamento durante uma interrupção regional

Esta secção descreve o que deve esperar quando configura um namespace do Notification Hubs para recuperação após desastre geográfico de metadados e ocorre uma indisponibilidade na região primária.

• Deteção e resposta: A Microsoft é responsável por detetar a falha da região e decidir se aciona o failover para a região secundária configurada.

• Notification: A Microsoft não o notifica automaticamente quando uma região está inoperante. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.

• Pedidos ativos: Pedidos em voo para o namespace na região principal podem falhar quando a região fica offline. Os clientes devem tentar novamente as operações após a conclusão do failover.

• Perda de dados esperada: Os metadados são preservados. Os dados de registo não são automaticamente guardados, mas podes fazer backup por ti próprio. Para mais informações, consulte Exportar e importar registos do Hubs de Notificação do Microsoft Azure em massa. Se não o fizer, os dados de registo não estão disponíveis até que a região principal recupere.

• Período de indisponibilidade previsto: A Microsoft demora algum tempo a acionar o failover dos metadados e para que este seja concluído. Embora o tempo possa variar, geralmente demora várias horas.

  Após a conclusão do failover, és responsável por restaurar quaisquer backups dos dados de registo.

• Redistribuição: Após o failover, os pedidos são encaminhados para um namespace na região secundária que utiliza os dados replicados da região primária. Após a conclusão do failover, os clientes ligam-se automaticamente ao namespace na região secundária.

Recuperação da região

Se a região primária recuperar, poderá ser possível voltar ao espaço de nomes primário na região primária. O espaço de nomes primário manteria os dados de registo anteriores à interrupção. Este seria um processo manual e a Microsoft comunicaria consigo para explicar como funciona.

Depois de a região primária recuperar, precisa de:

• Valida o estado do teu namespace e dos seus dados.
• Determine se deve sincronizar as alterações recentes dos dados de registo da região secundária para a região primária.

Teste para falhas regionais

Não podes iniciar um geo-failover. No entanto, deve testar os seus próprios procedimentos de recuperação de desastres. Verifica se os registos estão guardados e que podes restaurá-los num novo namespace.

Soluções multirregional personalizadas para resiliência

A recuperação após desastre geográfico dos metadados geridos pela Microsoft replica apenas metadados. A funcionalidade pode recuperar esses metadados para um namespace secundário, mas és responsável por importar os registos dos dispositivos para esse namespace para que a tua aplicação possa continuar a funcionar. Esta 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 intervenção manual, pode implementar uma solução multirregional ativa-ativa personalizada. Implemente um segundo namespace Notification Hubs para outra região do Azure com antecedência.

• Failover: Como o segundo namespace é um recurso funcional, podes implementar lógica para detetar uma falha de região e mudar para esse namespace.

• Sincronização: Para manter um segundo centro de notificações sincronizado com o centro principal de notificações, use uma das seguintes opções:

  • Para instalações: Use um backend de aplicação que crie e atualize simultaneamente as instalações em ambos os hubs de notificações. As instalações permitem-lhe especificar o seu próprio identificador único de dispositivo, que suporta este cenário de replicação. Para mais informações, consulte o exemplo do RedundantHub.

  • Para registos: Use um backend de aplicação que exporte regularmente registos do centro principal de notificações como backup e os importe em massa para o centro secundário de notificações. Para mais informações, consulte Exportar e importar registos do Hubs de Notificação do Microsoft Azure em massa.

  Alternativamente, se não tiveres backend, configura a tua aplicação para criar instalações em ambos os hubs quando a app inicia nos dispositivos-alvo. Os dispositivos criam novos registos em ambos os centros de notificação. Eventualmente, o centro de notificações secundário tem todos os dispositivos ativos registados.

• Registos e instalações expirados: O centro de notificações secundário pode ter registos e instalações expiradas. Quando um push é feito para um handle expirado, os Notification Hubs limpam automaticamente o registo de registo ou instalação associado no notification hub, com base na resposta recebida do servidor PNS. Pode limpar registos expirados da solução de backup à sua escolha, adicionando lógica personalizada que processa o feedback de cada envio e remove registos e instalações expiradas.

• Aplicações por abrir: Há um período em que dispositivos com aplicações por abrir não recebem notificações.

• Custo: Se usar o seu próprio hub secundário para proteger os dados de registo, esse hub terá custos normais de serviço. Da mesma forma, se implementares outros recursos do Azure na tua região secundária para apoiar a tua recuperação, pagas por esses aos preços normais de serviço.

Backup e restauração

O Notification Hubs não oferece uma única funcionalidade de backup e restauro incorporada para todos os dados armazenados no seu namespace. És responsável por combinar as seguintes abordagens:

• Use infraestrutura como código (IaC), como o Bicep, para definir o seu namespace, hub e configuração de políticas. Guarde essas definições no controlo de versões para que possa redistribuir os recursos quando necessário.
• Faça backup dos seus dados de registo de dispositivos exportando em massa os registos do Hubs de Notificação do Microsoft Azure.

Resiliência à manutenção de serviços

A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não é esperado qualquer tempo de indisponibilidade durante os eventos de manutenção, a menos que tenha sido informado através da manutenção planeada do Azure Service Health.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do 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 mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.

Para Hubs de Notificação, o SLA de disponibilidade aplica-se a namespaces que utilizam os níveis Básico e Standard.

Conteúdo relacionado

• Fiabilidade no Azure