Fiabilidade no Azure Event Grid

O Azure Event Grid é um serviço de mensagens totalmente gerido que permite a comunicação baseada em eventos entre serviços e aplicações. É frequentemente usado para construir arquiteturas orientadas a eventos e integrar serviços Azure com aplicações personalizadas.

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 o Azure Event Grid resiliente a várias potenciais interrupções e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. Também destaca informações chave sobre o acordo de nível de serviço (SLA) Azure Event Grid.

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

O Azure Well-Architected Framework fornece recomendações sobre fiabilidade, segurança, custo, operações e desempenho. Para compreender como estas áreas se influenciam mutuamente e contribuem para uma solução fiável do Azure Event Grid, consulte as orientações do Azure Well-Architected Framework para o Azure Event Grid.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

O Azure Event Grid encaminha eventos dos editores de eventos para os consumidores de eventos. É usado tanto por aplicações clientes como por serviços Azure para emitir e consumir eventos, como notificações quando recursos são criados, atualizados ou eliminados.

O Event Grid suporta múltiplos tipos de recursos e modelos de implementação:

• Os tópicos são as principais entidades que recebem e armazenam eventos.

  Os tópicos do sistema são criados automaticamente pelos serviços Azure para emitir eventos para tipos específicos de recursos Azure. Os tópicos personalizados são criados e geridos por si.

  Os tópicos podem suportar tanto a entrega por push como por pull.

• Os domínios de eventos agrupam múltiplos tópicos personalizados sob um único endpoint, simplificando a publicação de eventos. Para obter mais informações, consulte Compreender domínios de evento para gerenciar tópicos de grade de eventos.

• Os namespaces são usados com o tier padrão e fornecem um contentor para múltiplos recursos da Grade de Eventos. Para mais informações, consulte conceitos de namespace Azure Event Grid.

A Grelha de Eventos suporta múltiplos níveis, incluindo o nível básico e o nível padrão. Estes níveis oferecem capacidades diferentes e diferem na forma como os recursos são distribuídos e geridos. Para mais informações, consulte Escolha o nível certo da Grade de Eventos para a sua solução.

Arquitetura física

O Azure Event Grid é um serviço totalmente gerido. A Microsoft gere a infraestrutura subjacente, incluindo os recursos de computação e armazenamento. Nas regiões suportadas, a Grelha de Eventos distribui automaticamente os recursos entre as zonas de disponibilidade para proporcionar redundância de zona incorporada.

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.

Ao utilizar a Grade de Eventos, considere as seguintes práticas para garantir que a sua solução é resiliente a falhas transitórias:

• Editores de eventos: Quando uma aplicação cliente publica eventos no Event Grid, é responsável por tratar falhas transitórias. As aplicações devem implementar lógica de retentativas ao publicar eventos. Para mais informações, consulte Solucionar problemas de ligação transitória.

  Recomendamos que utilize os SDKs do plano de dados da Grade de Eventos, que fornecem automaticamente o tratamento de falhas transitórias.

• Consumidores do evento: A Grade de Eventos entrega eventos para destinos configurados. Para estas ligações de saída, configuram-se políticas de reintento nas subscrições de eventos. Estas políticas definem com que frequência e durante quanto tempo o Event Grid retenta a entrega quando ocorrem falhas, incluindo falhas transitórias. Para mais informações, veja Entrega de mensagens push e tentativa com tópicos de namespace

• Idempotência: É uma boa prática desenhar a sua arquitetura de eventos para idempotência, o que significa que os eventos podem ser recebidos e processados em segurança várias vezes. Por exemplo, se ocorrer uma falha transitória ou outro problema quando a sua aplicação está a processar um evento, então uma abordagem idempotente significa que a sua aplicação pode reprocessar a mensagem e recuperar.

  És responsável por desenhar a tua arquitetura e aplicação de eventing para suportar idempotência. Para informações gerais, veja Idempotência.

• Dead-lettering: O Event Grid suporta dead-lettering para eventos que não foram entregues, o que ajuda a persistir dados durante falhas prolongadas nos consumidores de eventos. Para mais informações, consulte Dead lettering para subscrições de eventos em tópicos de namespaces no Azure Event Grid.

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.

Os recursos do Azure Event Grid são redundantes em zonas que suportam zonas de disponibilidade. Redundância de zona significa que, mesmo quando uma zona de disponibilidade tem um problema, os seus recursos da Grade de Eventos continuam a funcionar usando infraestruturas noutras zonas. Os dados de eventos são replicados automaticamente em três zonas de disponibilidade para resiliência intra-regional, e o Event Grid recupera-se automaticamente durante uma interrupção abrangendo toda a zona. Não precisas de ativar ou configurar esta funcionalidade.

Requisitos

Apoio regional: A redundância de zonas está disponível em todas as regiões Azure que suportam zonas de disponibilidade.

Custo

Não há custos adicionais para redundância de zonas. Não podes ativar nem desativar esta funcionalidade; Está incluído por defeito nas regiões suportadas.

Configurar o suporte à zona de disponibilidade

Nenhuma configuração é necessária. Todos os recursos da Grelha de Eventos nas regiões suportadas são automaticamente redundantes por zona.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que pode ser esperado quando um recurso do Event Grid é redundante por zona e todas as zonas estão operacionais.

• Operação entre zonas: O Event Grid opera num modelo ativo-ativo em várias zonas de disponibilidade. As ligações dos clientes são automaticamente balanceadas de carga entre zonas, e o serviço encaminha as operações para a infraestrutura de mensagens disponível independentemente da zona.

• Replicação de dados entre zonas: O Event Grid replica automaticamente metadados e dados de eventos entre zonas de disponibilidade para manter a resiliência.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um recurso da Grade de Eventos é redundante em zona e há uma falha numa das zonas.

• Deteção e resposta: O Event Grid deteta automaticamente falhas de zona e inicia o failover para zonas saudáveis. Você não precisa fazer nada para iniciar um failover de zona.

• 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: Durante uma falha de zona, a Grelha de Eventos pode deixar de ter pedidos ativos. Se os seus clientes lidarem adequadamente com falhas transitórias , por exemplo, tentando novamente após um curto período de tempo, normalmente evitam um impacto significativo.

• Perda de dados esperada: O modelo de redundância de zonas da Grelha de Eventos foi concebido para permitir resiliência a falhas de zona com impacto mínimo. No entanto, durante uma falha de zona, existe alguma possibilidade de perda de dados.

  Se precisar de garantir que a sua aplicação não perde dados mesmo durante uma falha de zona, deve:

  • Desenhe os seus organizadores de eventos e consumidores para seguirem as recomendações de gestão de falhas transitórias, incluindo tentativas e idempotência.
  • Planeie a durabilidade do evento na origem ou numa loja de eventos duradoura.

• Tempo de inatividade esperado: Uma falha de zona pode causar alguns segundos de tempo de inatividade. Se os seus clientes lidarem adequadamente com falhas transitórias , por exemplo, tentando novamente após um curto período de tempo, normalmente evitam um impacto significativo.

• Redirecionamento de tráfego: O Event Grid deteta a perda da zona e redireciona automaticamente novos pedidos para a infraestrutura numa das zonas de disponibilidade saudáveis.

Recuperação de zona

Quando a zona afetada recupera, a Grade de Eventos reintegra-a automaticamente no serviço sem exigir ação do cliente. A zona recuperada aceita então novas ligações e processa mensagens juntamente com as outras zonas. Os dados que foram replicados para as zonas sobreviventes durante a interrupção mantêm-se intactos, e a replicação normal recomeça em todas as zonas. Não precisas de tomar medidas para a recuperação ou reintegração da zona.

Teste de falhas de zona

O Event Grid gere o encaminhamento do tráfego, a alternância e a recuperação de zonas em caso de falhas de zona, por isso não precisa validar processos relativos a falhas de zonas de disponibilidade nem fornecer informações adicionais.

Resiliência a falhas em toda a região

Os recursos da Grade de Eventos são implementados numa única região. Se houver uma falha regional, os seus recursos da Grade de Eventos ficam indisponíveis.

Em regiões Azure emparelhadas, o Event Grid fornece uma recuperação geográfica limitada de desastres para os metadados dos seus recursos do Event Grid. Também pode conceber e construir a sua própria solução multi-região, que pode apoiar o seu planeamento de recuperação de desastres. A tabela seguinte mostra como diferentes tipos de recursos da Grelha de Eventos suportam cada modelo:

Recuperação após desastre geográfica

A recuperação geo-desastre replica os metadados da Event Grid para a região emparelhada da sua região principal para recursos suportados. Os dados do evento não são replicados.

A recuperação de desastres geográficos foi concebida como um mecanismo de falha automática gerido pela Microsoft para falhas regionais graves e não pretende proporcionar tempos de recuperação rápidos ou previsíveis. O failover iniciado pela Microsoft é exercido pela Microsoft em situações raras para executar o failover de recursos do Event Grid de uma região afetada para a região geograficamente emparelhada correspondente. A Microsoft reserva-se o direito de determinar quando esta opção será exercida. Este mecanismo não envolve o consentimento do cliente antes de o tráfego ser ignorado.

Pode, opcionalmente, desativar a recuperação em caso de desastre geográfico e usar a sua própria solução multi-região personalizada que atenda aos seus requisitos para seleção de região, tempo de failover e mais. Quando desativa a recuperação de desastres geográficos, nenhum dado de eventos é replicado para outra região pela Microsoft.

Esta funcionalidade não está disponível em regiões sem uma região emparelhada.

Requisitos

• Apoio regional: A recuperação de desastres geo está disponível apenas nas regiões do Azure que têm uma região emparelhada.

• Tipos de recursos: Tópicos e domínios personalizados suportam a recuperação de desastres geográficos. Os tópicos do sistema são ativados automaticamente para recuperação de desastre geográfico. Outros tipos de recursos, como namespaces e namespaces de parceiros, não são suportados.

Custo

Não há custos adicionais para a recuperação de desastres geográficos.

Configurar suporte a várias regiões

Nas regiões suportadas, os tópicos do sistema são automaticamente configurados para recuperação de desastres geográficos. Para outros tipos de recursos da Grelha de Eventos:

• Para permitir a recuperação em desastres geográficos: Atualize a configuração do seu tópico ou domínio e selecione Cross-Geo (predefinido).

• Para desativar a recuperação do geo-diaster: Atualize a configuração do seu tema ou domínio e selecione Regional.

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

Esta secção descreve o que esperar quando um recurso do Event Grid é configurado para recuperação de desastres geográficos e todas as regiões estão operacionais.

• Operação entre regiões: Todo o tráfego é encaminhado para a região principal.

• Replicação de dados entre regiões: Os metadados são replicados síncronicamente para a região emparelhada. Os dados do evento não são replicados.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando um recurso da Event Grid está configurado para recuperação de desastre geográfico e ocorre uma interrupção na região principal.

• Deteção e resposta: A Microsoft deteta falhas de região e determina se e quando deve iniciar o failover.

• Notificação: A Microsoft não notifica automaticamente quando uma região está fora de serviço. 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: Os pedidos ativos para a região principal são terminados. As aplicações cliente devem tentar novamente estes pedidos após a conclusão do failover.

• Perda de dados esperada:

  • Metadados: O Event Grid preserva os metadados durante o failover. Como todas as alterações de metadados são replicadas de forma síncrona, não se espera perda de metadados.

  • Dados do evento: Os dados de eventos na região primária não estão disponíveis e podem ser perdidos se a região não for recuperável.

    Após ocorrer um failover, novos dados são processados da região emparelhada. Os eventos não processados são enviados da região principal assim que a interrupção é mitigada. Se a recuperação da região primária exigir mais tempo do que o valor de tempo de vida estabelecido nos eventos, os dados na região primária podem ser perdidos. Para mitigar esta perda de dados, recomendamos que configure um destino de carta morta para uma subscrição de evento.

    Se a região afetada for perdida e irrecuperável, haverá alguma perda de dados. No melhor cenário, o consumidor está a acompanhar a taxa de publicação de dados e perdem-se apenas alguns segundos de dados. O pior cenário seria quando o consumidor não está a processar eventos ativamente e, com um tempo máximo de vida de 24 horas, a perda de dados pode chegar até 24 horas.

    Observação

    O Event Grid não pode garantir a retenção de dados durante uma interrupção regional. Se precisas de retenção garantida, tens de desenhar a tua aplicação para armazenar eventos de forma durável noutra loja de dados.

• Tempo de inatividade previsto: A quantidade de tempo de inatividade depende da gravidade da interrupção e do tempo necessário para a Microsoft avaliar e iniciar o failover. Deves esperar que o tempo de inatividade seja pelo menos uma hora, ou talvez mais.

  Após a iniciação do failover, dentro de cinco minutos, o Event Grid começa a aceitar tráfego para tópicos e assinaturas, incluindo para operações de criação, atualização e eliminação.

• Redistribuição: Após a conclusão do failover, o tráfego é automaticamente encaminhado para a região secundária.

Recuperação da região

A Microsoft gere a recuperação por região e o processo de recuperação depende do cenário específico de interrupção. Em geral, o failover é normalmente tratado como uma operação unidirecional.

Teste para falhas regionais

O Azure Event Grid gere o encaminhamento de tráfego, failover e recuperação para recuperação de desastres geográficos. Você não precisa iniciar nada. Como esta funcionalidade é totalmente gerida, não é necessário validar processos de falha de região.

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

Pode querer desativar, ou não depender, do failover iniciado pela Microsoft por qualquer uma destas razões:

• É necessário que os dados de eventos sejam replicados entre regiões, e não apenas metadados.
• Precisa garantir um tempo específico ou uma abordagem específica para o failover. O failover iniciado pela Microsoft é feito com base no melhor esforço possível.
• A tua região não está emparelhada com outra região Azure.
• O par da sua região não cumpre os requisitos de residência de dados da sua organização.

Para níveis mais elevados de controlo e previsibilidade, pode implementar arquiteturas personalizadas multi-região. Esta abordagem envolve a implementação de recursos separados da Grade de Eventos em múltiplas regiões e a gestão do failover ao nível da aplicação. Quando utiliza este modelo, é responsável por implementar, configurar e manter os recursos sincronizados entre regiões.

Considere os seguintes fatores ao desenhar uma solução multi-região:

• Replicação: Deves implementar um processo personalizado para replicar os teus recursos da Grade de Eventos e a sua configuração entre as regiões primária e secundária. Lembre-se de replicar as identidades dos clientes, certificados da CA, grupos de clientes, espaços de tópicos e atribuições de permissões, quando aplicável. Pode decidir se implementa replicação manual ou automatizada.

• Abordagens de failover: Pode escolher se deseja criar uma solução ativa-ativa ou ativa-passiva:

  • Soluções ativo-ativo podem ser alcançadas replicando os metadados e equilibrando a carga entre os namespaces.
  • Soluções ativo-passivas podem ser alcançadas replicando os metadados para manter o espaço secundário pronto, de modo que, quando o espaço principal não estiver disponível, o tráfego possa ser direcionado para o espaço secundário.

• Monitorização da saúde: Pode usar APIs de saúde integradas fornecidas pelo Event Grid para monitorizar a saúde dos tópicos.

  As suas aplicações cliente devem detetar falhas numa região e encaminhar eventos para outra região apropriada.

  Em alternativa, pode implementar um serviço de concierge que encaminhe os clientes para os endpoints primários ou secundários dos seus tópicos ou namespaces, realizando verificações de saúde nesses endpoints. O serviço concierge pode ser uma aplicação web que é replicada geograficamente e mantida acessível usando técnicas de redirecionamento DNS ou serviços como o Azure Traffic Manager.

Para mais informações sobre uma abordagem, incluindo código de exemplo, consulte Implementação de failover do lado do cliente no Azure Event Grid.

Backup e restauração

O Event Grid é principalmente um serviço de encaminhamento de eventos e não tem funcionalidades nativas de backup ou restauro.

Se precisar de implementar capacidades de backup, ou se tiver necessidades de retenção a longo prazo, recomendamos que realize o arquivamento na sua aplicação. Para isso, deve construir lógica para encaminhar ou copiar os seus eventos para um armazenamento duradourável, como o Azure Blob Storage, em paralelo com o caminho principal de entrega. Se os sistemas a jusante não estiverem disponíveis, a sua aplicação pode usar o arquivo para reproduzir os eventos.

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

O SLA de disponibilidade do Grid de Eventos cobre a publicação de eventos.

Conteúdo relacionado

• Fiabilidade no Azure
• Orientações do Azure Well-Architected Framework para o Azure Event Grid
• Documentação da Grade de Eventos do Azure