Confiabilidade na Configuração de Aplicativos do Azure

A Configuração de Aplicativos do Azure armazena e gerencia centralmente as configurações de configuração do aplicativo e os sinalizadores de recursos, substituindo os arquivos de configuração inseridos diretamente nos aplicativos. Essa abordagem permite atualizações dinâmicas, controle de versão de valores de configuração e acompanhamento histórico de alterações de configuração ao longo do tempo. A disponibilidade e a confiabilidade da Configuração de Aplicativos são considerações importantes porque o comportamento do aplicativo pode depender diretamente do acesso aos dados de configuração no runtime.

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 a arquitetura de confiabilidade da Configuração de Aplicativos do Azure e explica como o serviço foi projetado para permanecer disponível durante falhas transitórias, falhas de zona de disponibilidade e interrupções de região.

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

Para a maioria das implantações de produção da Configuração de Aplicativos, considere as seguintes recomendações:

• SKU: Use o SKU Standard ou Premium.
• Exclusão branda e proteção contra purga: Habilite a exclusão branda e a proteção contra purga para proteger contra a exclusão de dados.
• Para cenários críticos de missão: Use o SKU Premium e configure a réplica incluída para habilitar a replicação em várias regiões para melhorar a alta disponibilidade e resiliência a interrupções de região.

Para obter uma lista de práticas recomendadas e configuração para cargas de trabalho de produção, consulte Compilar aplicativos com alta resiliência.

Visão geral da arquitetura de confiabilidade

Ao implantar a Configuração de Aplicativos, você implanta um repositório. Seu repositório contém vários tipos de configurações que seu aplicativo pode usar, incluindo chaves e valores, e sinalizadores de recursos. O serviço também inclui recursos internos para organizar, proteger, fazer controle de versão e implementar com segurança as alterações de configuração entre ambientes. Para obter mais informações, consulte o que é a Configuração de Aplicativos do Azure?

A Configuração de Aplicativos é um serviço totalmente gerenciado. A Microsoft é responsável por armazenar e gerenciar suas configurações, além de executar a manutenção no serviço.

Ao criar aplicativos cliente que se conectam à Configuração de Aplicativos do Azure, você pode usar opcionalmente a Configuração de Aplicativos com o Azure Front Door (versão prévia) para habilitar o cache e a aceleração de tráfego global. Essa configuração apresenta outras considerações para replicação geográfica, que são realçadas ao longo deste artigo, quando apropriado.

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 Configuração de Aplicativos do Azure, considere as práticas recomendadas a seguir para minimizar o efeito de falhas transitórias no acesso à configuração, especialmente em caminhos de código críticos.

• Provedores de configuração: Use os provedores de configuração do App Configuration, que têm recursos de tentativa e cache integrados, além de muitos outros recursos de resiliência.
• SDKs do Azure: Use os SDKs de Configuração de Aplicativo se o aplicativo precisar enviar solicitações de gravação. Os SDKs tentam automaticamente novamente em respostas com o código de status HTTP 429 e outros erros transitórios.
• Lógica de repetição: Inclua lógica de repetição em clientes personalizados se você não puder usar Provedores de Configuração de Aplicativos ou SDKs. O retry-after-ms cabeçalho na resposta fornece um tempo de espera sugerido em milissegundos antes de repetir a solicitação.
• Cache: Configure o cache na memória sempre que possível para reduzir solicitações diretas à sua loja.

Para obter outras diretrizes de configuração de aplicativo, consulte as perguntas frequentes sobre a Configuração de Aplicativos 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.

A Configuração de Aplicativos fornece redundância de zona automaticamente em regiões que dão suporte a zonas de disponibilidade. Essa redundância fornece alta disponibilidade em uma região sem exigir nenhuma configuração específica.

Quando uma zona de disponibilidade fica indisponível, a Configuração de Aplicativos redireciona automaticamente suas solicitações para outras zonas de disponibilidade íntegras para garantir a alta disponibilidade.

Requirements

Suporte à região: As lojas implantadas nas seguintes regiões são automaticamente redundantes por zona:

Américas	Europa	Médio Oriente	África	Pacífico Asiático
Sul do Brasil	França Central	Israel Central		Leste da Austrália
Canadá Central	Centro-oeste da Alemanha	Catar Central		Índia Central
EUA Central	Norte da Itália	Norte dos EAU		Norte da China 3
Leste dos EUA	Europa Setentrional			Ásia Oriental
Leste dos EUA 2	Leste da Noruega			Leste do Japão
México Central	Polônia Central			Coreia Central
Centro-Sul dos EUA	Espanha Central			Sudeste Asiático
US Gov - Virgínia	Suécia Central
Oeste dos EUA 2	Norte da Suíça
Oeste dos EUA 3	Sul do Reino Unido
	Oeste da Europa

Custo

Não há custo adicional para redundância de zona para a Configuração de Aplicativos do Azure.

Configurar o suporte à zona de disponibilidade

A Microsoft habilita automaticamente a redundância de zona para um repositório quando está em uma região que dá suporte a zonas de disponibilidade.

Se a Configuração de Aplicativo adicionar suporte à zona de disponibilidade a uma região existente, você não precisará fazer nada para começar a se beneficiar do suporte à zona de disponibilidade. Sua loja se beneficiará do suporte à zona de disponibilidade que se tornou disponível para repositórios de Configuração de Aplicativos na região.

Comportamento quando todas as zonas estão saudáveis

Quando um repositório está em uma região que dá suporte à redundância de zona e todas as zonas de disponibilidade estão operacionais, você pode esperar o seguinte comportamento:

• Operação entre zonas: A Configuração de Aplicativos gerencia automaticamente o roteamento de tráfego entre zonas de disponibilidade. Durante operações normais, ele distribui de forma transparente as solicitações entre zonas.

• Replicação de dados entre zonas: Em regiões que dão suporte a zonas, a Configuração de Aplicativo replica dados de forma síncrona entre zonas de disponibilidade. Essa replicação garante que suas configurações permaneçam consistentes e disponíveis mesmo se uma zona ficar indisponível.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um repositório está em uma região que dá suporte à redundância de zona e uma zona de disponibilidade não está disponível:

• Detecção e resposta: O serviço de Configuração de Aplicativo detecta falhas de zona e responde automaticamente a elas. Você não precisa tomar qualquer ação durante uma falha de zona.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. 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 de problemas.

• Solicitações ativas: Durante uma falha de zona, a zona afetada pode falhar ao lidar com solicitações em andamento, o que exige que os aplicativos cliente as repitam. Os aplicativos cliente devem seguir práticas transitórias de tratamento de falhas para garantir que eles possam repetir solicitações se ocorrer uma falha de zona.

• Perda de dados esperada: Nenhuma perda de dados é esperada durante uma falha de zona devido à replicação síncrona entre zonas.

• Tempo de inatividade esperado: Nenhum tempo de inatividade é esperado.

• Redistribuição: A Configuração de Aplicativos redireciona automaticamente o tráfego da zona afetada para zonas íntegras sem exigir nenhuma intervenção do cliente.

Recuperação de zona

Quando uma zona que estava indisponível anteriormente se recupera, a Configuração de Aplicativos restaura automaticamente as operações normais em todas as zonas de disponibilidade. Você não precisa realizar nenhuma ação para se recuperar de uma falha em uma zona.

Testar falhas em zonas

A plataforma de Configuração de Aplicativos do Azure gerencia o roteamento de tráfego, o failover e a recuperação de zona para repositórios com redundância de zona. Como esse processo é totalmente gerenciado pela Microsoft, você não precisa validar os processos de falha da zona de disponibilidade.

Resiliência a falhas em toda a região

A Configuração de Aplicativos do Azure fornece recursos nativos de replicação geográfica para dar suporte à resiliência durante interrupções de região. A replicação geográfica permite que os dados de configuração sejam replicados entre regiões como um recurso de serviço gerenciado.

Geo-replication

A replicação geográfica permite que um repositório seja replicado em várias regiões do Azure. Cada loja pode ter várias réplicas em diferentes regiões. A loja original também é uma réplica. Essa funcionalidade ajuda a proteger os aplicativos contra interrupções em toda a região.

Requirements

• Suporte à região: Você pode criar réplicas em qualquer região do Azure com suporte pela Configuração de Aplicativos do Azure, mesmo que as regiões não sejam regiões emparelhadas do Azure.

• Camada: O repositório de configuração deve usar uma camada com suporte para habilitar a replicação geográfica. Para obter mais informações, consulte Habilitar replicação geográfica.

Considerações

Ao habilitar a replicação geográfica, considere os seguintes fatores:

• Réplicas com redundância de zona: Qualquer réplica criada em uma região na qual a Configuração de Aplicativos dá suporte a zonas de disponibilidade é automaticamente redundante por zona.

• Azure Front Door: Para habilitar a entrega de configuração com redundância geográfica com o Azure Front Door, configure as réplicas da Configuração de Aplicativos como origens em um grupo de origem. A configuração de origem correta permite que o Azure Front Door gerencie roteamento baseado em integridade, balanceamento de carga e failover automático entre regiões. Para obter mais informações, consulte Os métodos de roteamento de tráfego para a origem.

Custo

Cada região replicada geograficamente é cobrada separadamente de acordo com os preços da respectiva camada e região. Nenhum encargo de saída de dados se aplica à replicação entre regiões. Para obter detalhes sobre preços, consulte os preços da Configuração de Aplicativos do Azure.

Configurar o suporte a várias regiões

Para configurar a replicação para um repositório de configuração recém-criado, consulte Habilitar replicação geográfica.

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

Esta seção descreve o que esperar quando você configura um repositório de Configuração de Aplicativos para replicação geográfica e todas as regiões estão operacionais.

• Operação entre zonas: Cada réplica é endereçável individualmente e tem seu próprio nome DNS. Todas as réplicas podem aceitar operações de leitura e gravação.

  A Configuração de Aplicativos do Azure não roteia automaticamente o tráfego entre regiões. Quando você usa provedores de configuração de Configuração de Aplicativo, o aplicativo pode, opcionalmente, usar a descoberta automática de réplica. Como alternativa, você pode especificar uma lista priorizada de réplicas e o App Configuration seleciona a primeira réplica saudável. Isso permite que seu aplicativo controle qual réplica ele usa.

  Observação

  Se você usar o Azure Front Door, o comportamento de roteamento de tráfego será diferente. Para obter mais informações, consulte Tolerância a falhas e balanceamento de carga.

• Replicação de dados entre zonas: Os dados são replicados de forma assíncrona e, eventualmente, são consistentes. Você pode usar a métrica de latência de replicação no Azure Monitor para monitorar a latência de replicação atual entre réplicas.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura um repositório de Configuração de Aplicativos para replicação geográfica e há uma interrupção em uma das regiões de réplica.

• Detecção e resposta: A Microsoft é responsável por detectar falhas de região ou réplica e iniciar processos de recuperação.

  Quando você usa provedores de configuração de Configuração de Aplicativo e executa a descoberta automática de réplicas ou com uma lista de várias réplicas, seu aplicativo faz failover automaticamente para outra réplica íntegra.

  Se você não usar provedores de Configuração de Aplicativos, será responsável por alternar seu aplicativo para uma réplica íntegra.

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

• Solicitações ativas: Solicitações ativas em uma réplica na região podem ser descartadas. Os aplicativos cliente devem repetir as solicitações em relação a uma réplica diferente.

• Perda de dados esperada: Se uma réplica falhar, as alterações recentes feitas nessa réplica ainda poderão não ser replicadas para outras réplicas. Essas alterações podem permanecer indisponíveis até que a réplica se recupere. Para estimar a possível perda de dados, monitore a métrica de latência de replicação no Azure Monitor.

• Tempo de inatividade esperado: Quando uma réplica fica indisponível, ela fica offline até que sua região se recupere. Outras réplicas continuam a processar solicitações. Os aplicativos podem experimentar um breve tempo de inatividade enquanto detectam a falha e alternam para uma réplica íntegra. A duração depende da rapidez com que cada aplicativo executa essa detecção e failover.

• Redistribuição: Os aplicativos devem rotear o tráfego para uma réplica íntegra quando ocorre uma falha.

  Se você utilizar provedores de configuração do App Configuration, eles gerenciarão automaticamente a seleção e o failover das réplicas.

  Se você colocar o Azure Front Door na frente do data store e configurar o grupo de destino com várias réplicas como destinos para failover, o Azure Front Door redirecionará automaticamente as solicitações para uma réplica saudável.

Recuperação de região

Depois que a região se recuperar, a Configuração de Aplicativos colocará a réplica novamente em sincronia com as outras réplicas sem a intervenção.

Você é responsável por reconfigurar seu aplicativo para rotear o tráfego de volta para a instância de região recuperada. Os aplicativos que usam provedores de Configuração de Aplicativos começam automaticamente a usar a réplica novamente.

Teste de falhas na região

Você não pode simular diretamente um failover de réplica na Configuração de Aplicativos hoje. No entanto, como os aplicativos controlam a seleção de réplicas, você pode testar o comportamento de failover forçando o aplicativo a entrar em um estado no qual ele precise alternar entre as réplicas.

Para validar o comportamento de failover das réplicas do aplicativo, você pode introduzir uma falha de conectividade controlada em um ambiente de não produção e observar como o aplicativo responde.

Uma abordagem é usar o computador local ou outro ambiente em que você tenha acesso administrativo. Siga estas etapas:

1. Habilite o log detalhado para o SDK do Azure. No .NET, use a AzureEventSourceListener classe para configurar um logger. Para obter mais informações, consulte Tutorial: Usar a configuração dinâmica em um aplicativo .NET – Registro em log e monitoramento.

2. Configure manualmente seu hosts arquivo para que as solicitações para o repositório de Configuração de Aplicativos sejam roteados para um endereço IP que não possa recebê-los, como 127.0.0.1 (localhost).

   Aviso

   Esta etapa bloqueia efetivamente o acesso do computador ao repositório de Configuração de Aplicativos. Siga apenas estas etapas em um ambiente de não produção.

3. Monitore os logs para obter uma mensagem semelhante a esta:

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   Essa mensagem indica que o aplicativo fez failover com êxito para usar outra réplica do repositório.

4. Depois de concluir o teste, desfaça as alterações no hosts arquivo.

Backup e restauração

A Configuração de Aplicativos do Azure permite exportar dados de configuração de um repositório e usá-los como parte de uma estratégia de backup mais ampla.

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

Resiliência à exclusão acidental

A Configuração de Aplicativos fornece dois principais recursos de recuperação para evitar exclusão acidental ou mal-intencionada:

• Exclusão reversível: Quando habilitada, a exclusão reversível permite que você recupere repositórios e configurações excluídos durante um período de retenção configurável. Pense na exclusão temporária como uma lixeira para os recursos de Configuração do Aplicativo.

• Proteção contra limpeza: Quando habilitada, a proteção contra limpeza impede a exclusão permanente de sua loja e suas configurações até que decorra o período de retenção. Essa proteção impede que atores mal-intencionados destruam permanentemente suas configurações.

Use ambos os recursos para ambientes de produção. Para obter mais informações, consulte Exclusão temporária e proteção contra purga.

Resiliência à manutenção do serviço

A Microsoft executa regularmente atualizações de serviço e outras manutenções. O serviço lida com 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.

Resiliência a problemas de configuração

Alterações de configuração incorretas ou acidentais podem causar tempo de inatividade do aplicativo. Use instantâneos de configuração para distribuir com segurança as alterações na configuração. Monitore a integridade do aplicativo após as alterações de configuração e reverta para o último instantâneo de configuração conhecido se as alterações introduzirem um problema.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Conteúdo relacionado

• Confiabilidade no Azure
• Documentação da Configuração de Aplicativos do Azure