Compartilhar via

Confiabilidade na Grade de Eventos do Azure

A Grade de Eventos do Azure é um serviço de mensagens totalmente gerenciado que permite a comunicação baseada em eventos entre serviços e aplicativos. Normalmente, ele é usado para criar arquiteturas orientadas a eventos e integrar serviços do Azure a aplicativos personalizados.

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 a Grade de Eventos do Azure resiliente a várias possíveis interrupções e problemas, incluindo falhas transitórias, falhas na zona de disponibilidade e falhas em toda a região. Ele também destaca as principais informações sobre o SLA (contrato de nível de serviço) da Grade de Eventos do Azure.

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

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, segurança, custo, operações e desempenho. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável da Grade de Eventos do Azure, consulte as diretrizes do Azure Well-Architected Framework para a Grade de Eventos do Azure.

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

A Grade de Eventos do Azure roteia eventos de editores de eventos para consumidores de eventos. Ele é usado tanto por aplicativos de clientes quanto pelos serviços do Azure para emitir e consumir eventos, como notificações quando os recursos são criados, atualizados ou excluídos.

A Grade de Eventos dá suporte a vários tipos de recursos e modelos de implantação:

A Grade de Eventos dá suporte a várias camadas, incluindo a camada básica e a camada padrão. Essas camadas fornecem diferentes funcionalidades e diferem na forma como os recursos são implantados e gerenciados. Para obter mais informações, consulte Escolher a camada de Grade de Eventos correta para sua solução.

Arquitetura física

A Grade de Eventos do Azure é um serviço totalmente gerenciado. A Microsoft gerencia a infraestrutura subjacente, incluindo recursos de computação e armazenamento. Em regiões com suporte, a Grade de Eventos distribui automaticamente recursos entre zonas de disponibilidade para fornecer redundância de zona interna.

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.

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

  • Editores de eventos: Quando um aplicativo cliente publica eventos na Grade de Eventos, ele é responsável por lidar com falhas transitórias. Os aplicativos devem implementar a lógica de repetição ao publicar eventos. Para obter mais informações, consulte Solucionar problemas transitórios de conexão.

    Recomendamos que você use os SDKs do plano de dados da Grade de Eventos, que fornecem automaticamente tratamento transitório de falhas.

  • Consumidores de eventos: A Grade de Eventos fornece eventos para destinos configurados. Para essas conexões de saída, você configura políticas de tentativa em assinaturas de eventos. Essas políticas definem com que frequência e por quanto tempo a Grade de Eventos tenta a entrega novamente quando ocorrem falhas, incluindo falhas transitórias. Para obter mais informações , consulte a entrega por push de mensagens e tente novamente com tópicos de namespace

  • Idempotency: É uma boa prática projetar sua arquitetura de evento para idempotency, o que significa que os eventos podem ser recebidos e processados com segurança várias vezes. Por exemplo, se uma falha transitória ou outro problema ocorrer quando seu aplicativo estiver processando um evento, uma abordagem idempotente significa que seu aplicativo pode reprocessar a mensagem e se recuperar.

    Você é responsável por criar sua arquitetura de eventos e aplicativo para dar suporte à idempotency. Para obter informações gerais, consulte Idempotency.

  • Mensagens mortas: A Grade de Eventos dá suporte a mensagens mortas para eventos não entregues, o que ajuda a persistir dados durante falhas mais duradouras em consumidores de eventos. Para obter mais informações, consulte letras mortas para assinaturas de eventos para tópicos de namespaces na Grade de Eventos do Azure.

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.

Os recursos da Grade de Eventos do Azure são redundantes em zonas em regiões que dão suporte a zonas de disponibilidade. A redundância de zona significa que, mesmo quando uma zona de disponibilidade tem um problema, os recursos da Grade de Eventos continuam funcionando usando a infraestrutura em outras zonas. Os dados do evento são replicados automaticamente em três zonas de disponibilidade para resiliência dentro da região, e o Event Grid se autorecupera durante uma interrupção em toda a zona. Você não precisa habilitar ou configurar essa funcionalidade.

Requisitos

Suporte à região: A redundância de zona está disponível em todas as regiões do Azure que dão suporte a zonas de disponibilidade.

Custo

Não há custo adicional para redundância de zona. Você não pode habilitar ou desabilitar esse recurso; ele é incluído por padrão em regiões com suporte.

Configurar o suporte à zona de disponibilidade

Nenhuma configuração é necessária. Todos os recursos da Grade de Eventos em regiões com suporte são automaticamente redundantes por zona.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando um recurso do Event Grid possui redundância de zona e todas as zonas estão operacionais.

  • Operação entre zonas: A Grade de Eventos utiliza um modelo ativo-ativo em todas as zonas de disponibilidade. As conexões de cliente são automaticamente balanceadas por carga entre zonas e o serviço roteia as operações para a infraestrutura de mensagens disponível, independentemente da zona.

  • Replicação de dados entre zonas: A Grade de Eventos replica automaticamente metadados e dados de evento entre zonas de disponibilidade para manter a resiliência.

Comportamento durante uma falha de zona

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

  • Detecção e resposta: A Grade de Eventos detecta automaticamente falhas de zona e inicia o failover para zonas íntegras. Você não precisa fazer nada para iniciar um failover de zona.
  • Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Azure Service Health 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: Durante uma falha de zona, a Grade de Eventos pode remover solicitações ativas. Se seus clientes lidarem com falhas transitórias adequadamente, como tentar novamente após um curto período de tempo, eles normalmente evitam um impacto significativo.

  • Perda de dados esperada: O modelo de redundância de zona da Grade de Eventos foi projetado para habilitar a resiliência a falhas de zona com impacto mínimo. No entanto, durante uma falha de zona, há alguma possibilidade de perda de dados.

    Se você precisar garantir que seu aplicativo não perca dados mesmo durante uma falha de zona, você deverá:

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

  • Redirecionamento de tráfego: A Grade de Eventos detecta a perda da zona e redireciona automaticamente novas solicitações para a infraestrutura em uma das zonas de disponibilidade íntegras.

Recuperação de zona

Quando a zona afetada se recupera, a Grade de Eventos a reintegra automaticamente ao serviço sem a necessidade de ação do cliente. Em seguida, a zona recuperada aceita novas conexões e processa mensagens junto com as outras zonas. Os dados replicados para zonas sobreviventes durante a interrupção permanecem intactos e a replicação normal é retomada em todas as zonas. Você não precisa tomar medidas para recuperação ou reintegração de zona.

Testar falhas em zonas

A Grade de Eventos gerencia o roteamento de tráfego, o failover e a recuperação de zona para falhas de zona, portanto, você não precisa validar os processos de falha em zona de disponibilidade ou fornecer mais informações adicionais.

Resiliência a falhas em toda a região

Os recursos da Grade de Eventos são implantados em uma única região. Se houver uma falha em toda a região, os recursos da Grade de Eventos não estarão disponíveis.

Em regiões emparelhadas do Azure, a Grade de Eventos fornece recuperação de desastre geográfico limitada para os metadados dos recursos da Grade de Eventos. Você também pode projetar e criar sua própria solução de várias regiões, que pode dar suporte ao seu planejamento de recuperação de desastre. A tabela a seguir mostra como diferentes tipos de recursos da Grade de Eventos dão suporte a cada modelo:

Recurso da Grade de Eventos Dá suporte à recuperação de desastre geográfico Dá suporte à solução personalizada
Tópicos personalizados Suportado Suportado
Tópicos do sistema Habilitado automaticamente Sem suporte
Domínios Suportado Suportado
Namespaces Sem suporte Suportado
Namespaces de parceiro Sem suporte Suportado

Recuperação de desastre geográfico

A recuperação de desastres geográficos replica os metadados do Event Grid para a região emparelhada da sua região primária em recursos com suporte. Os dados do evento não são replicados.

A recuperação de desastre geográfico foi projetada como um fallback gerenciado pela Microsoft para interrupções regionais severas e não se destina a fornecer tempos de recuperação rápidos ou previsíveis. O failover iniciado pela Microsoft é um recurso raramente usado pela Microsoft para realizar o failover de recursos da Grade de Eventos da região afetada para a região geográfica emparelhada correspondente. A Microsoft se reserva o direito de determinar quando essa opção será exercida. Esse mecanismo não envolve o consentimento do cliente antes que o tráfego seja direcionado para failover.

Importante

A Microsoft dispara o failover gerenciado pela Microsoft. É provável que ocorra após um atraso significativo e seja feito empreendendo o máximo esforço. O failover de recursos da Grade de Eventos pode ocorrer em um momento diferente do tempo de failover de outros serviços do Azure.

Se você precisar ser resiliente a interrupções de região, considere usar uma das soluções personalizadas de várias regiões para resiliência.

Opcionalmente, você pode desabilitar a recuperação de desastre geográfico e usar sua própria solução personalizada de várias regiões que atenda aos seus requisitos de seleção de região, tempo de failover e muito mais. Quando você desabilitar a recuperação de desastre geográfico, nenhum dado de evento é replicado para outra região pela Microsoft.

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

Requisitos

  • Suporte à região: A recuperação de desastre geográfico está disponível apenas em regiões do Azure que têm uma região emparelhada.

  • Tipos de recurso: Tópicos e domínios personalizados dão suporte à recuperação de desastre geográfico. Tópicos do sistema são habilitados automaticamente para recuperação de desastres geográficos. Não há suporte para outros tipos de recursos, como namespaces e namespaces de parceiros.

Custo

Não há custo adicional para recuperação de desastre geográfico.

Configurar o suporte a várias regiões

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

  • Para habilitar a recuperação de desastre geográfico: Atualize a configuração de seu tópico ou domínio e selecione Entre geografias (padrão).

  • Para desabilitar a recuperação de desastres geográficos: Atualize a configuração do seu tópico ou domínio e selecione Regional.

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

Esta seção descreve o que esperar quando um recurso da Grade de Eventos é configurado para recuperação de desastre geográfico e todas as regiões estão operacionais.

  • Operação entre regiões: Todo o tráfego é roteado para a região primária.

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

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando um recurso da Grade de Eventos é configurado para recuperação de desastre geográfico e há uma interrupção na região primária.

  • Detecção e resposta: A Microsoft detecta falhas na região e determina se e quando iniciar o failover.
  • Notificação: A Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto, você pode usar Azure Service Health 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 ativas para a região primária são encerradas. Os aplicativos cliente devem repetir essas solicitações após a conclusão do failover.

  • Perda de dados esperada:

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

    • Dados do evento: Os dados de evento na região primária não estão disponíveis e poderão ser perdidos se a região não puder ser verificada.

      Depois que ocorre um failover, novos dados são processados da região emparelhada. Os eventos não processados são despachados da região primária assim que a falha é mitigada. Se a recuperação da região primária exigir um tempo maior do que o valor de vida útil definido em eventos, os dados na região primária poderão ser descartados. Para atenuar essa perda de dados, recomendamos que você configure um destino de mensagens mortas para uma assinatura de evento.

      Se a região afetada for perdida e não puder ser recuperada, haverá alguma perda de dados. No cenário ideal, o consumidor está acompanhando a taxa de publicação e apenas alguns segundos de dados são perdidos. O pior cenário seria quando o consumidor não estiver processando eventos ativamente e com um tempo máximo de vida útil de 24 horas, a perda de dados pode ser de até 24 horas.

      Observação

      A Grade de Eventos não pode garantir a retenção de dados durante uma interrupção de região. Se você precisar de retenção garantida, precisará projetar seu aplicativo para armazenar eventos de maneira durável em outro armazenamento de dados.

  • Tempo de inatividade esperado: 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. Você deve esperar que o tempo de inatividade seja pelo menos uma hora, e talvez mais.

    Depois que o failover é iniciado, em até cinco minutos, a Grade de Eventos começa a aceitar tráfego para tópicos e assinaturas, incluindo para operações de criação, atualização e exclusão.

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

Recuperação de região

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

Teste de falhas na região

A Grade de Eventos do Azure gerencia o roteamento de tráfego, o failover e a recuperação em caso de desastres geográficos. Você não precisa iniciar nada. Como esse recurso é totalmente gerenciado, você não precisa validar processos de falha de região.

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

Talvez você queira desabilitar ou não contar com o failover iniciado pela Microsoft por qualquer um destes motivos:

  • Você precisa que os dados do evento sejam replicados entre regiões e não apenas metadados.
  • Você precisa garantir um tempo de failover garantido ou uma abordagem específica. O failover iniciado pela Microsoft é feito do melhor modo possível.
  • Sua região não é emparelhada com outra região do Azure.
  • O par de sua região não atende aos requisitos de residência de dados da sua organização.

Para níveis mais altos de controle e previsibilidade, você pode implementar arquiteturas personalizadas de várias regiões. Essa abordagem envolve a implantação de recursos separados da Grade de Eventos em várias regiões e o gerenciamento de failover no nível do aplicativo. Ao usar esse modelo, você é responsável por implantar, configurar e manter os recursos em sincronia entre regiões.

Considere os seguintes fatores ao projetar uma solução de várias regiões:

  • Replicação: Você deve implementar um processo personalizado para replicar os recursos da Grade de Eventos e sua configuração entre regiões primárias e secundárias. Lembre-se de replicar identidades de cliente, certificados de CA, grupos de clientes, espaços de tópicos e associações de permissão, quando aplicável. Você pode decidir se deseja implementar a replicação manual ou automatizada.

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

    • As soluções ativas-ativas podem ser obtidas replicando os metadados e equilibrando a carga entre os namespaces.
    • Soluções ativas-passivas podem ser obtidas replicando os metadados para manter o namespace secundário pronto para que, quando o namespace primário não estiver disponível, o tráfego possa ser direcionado para o namespace secundário.

  • Monitoramento de integridade: Você pode usar APIs de saúde integradas fornecidas pela Grade de Eventos para monitorar a integridade dos tópicos.

    Seus aplicativos cliente devem detectar falhas de uma região e rotear eventos para outra região apropriada.

    Como alternativa, você pode implementar um serviço de concierge que direciona os clientes para os pontos de extremidade primários ou secundários para seus tópicos ou namespaces executando verificações de integridade nesses pontos de extremidade. O serviço de concierge pode ser um aplicativo Web que é replicado geograficamente e mantido acessível usando técnicas de redirecionamento de DNS ou serviços como o Gerenciador de Tráfego do Azure.

Para obter mais informações sobre uma abordagem, incluindo o código de exemplo, consulte a implementação de failover do lado do cliente na Grade de Eventos do Azure.

Backup e restauração

A Grade de Eventos é principalmente um serviço de roteamento de eventos e não tem recursos nativos de backup ou restauração.

Se você precisar implementar recursos de backup ou se tiver necessidades de retenção de longo prazo, recomendamos que você execute o arquivamento em seu aplicativo. Para fazer isso, você deve criar lógica para rotear ou copiar seus eventos para um repositório durável, como o Armazenamento de Blobs do Azure, em paralelo com o caminho de entrega primário. Se os sistemas a jusante não estiverem disponíveis, seu aplicativo poderá usar o arquivamento para reproduzir os eventos.

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 Azure Service Health.

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.

O SLA de disponibilidade da Grade de Eventos aborda a publicação de eventos.

Conteúdo relacionado

  • Last updated on