Confiabilidade no Azure App Configuration

O Azure App Configuration armazena e gere centralmente as definições de configuração das aplicações e as feature flags, substituindo ficheiros de configuração incorporados diretamente nas aplicações. Esta abordagem permite atualizações dinâmicas, versionamento dos valores de configuração e acompanhamento histórico das alterações de configuração ao longo do tempo. A disponibilidade e fiabilidade da Configuração de Aplicações são considerações importantes porque o comportamento das aplicações pode depender diretamente do acesso aos dados de configuração em tempo de execução.

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 a arquitetura de fiabilidade do Azure App Configuration e explica como o serviço foi concebido para permanecer disponível durante falhas transitórias, falhas em zonas de disponibilidade e interrupções regionais.

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

Para a maioria das implementações em produção do App Configuration, considere as seguintes recomendações:

• SKU: Use o SKU Standard ou Premium.
• Proteção contra eliminação suave e purga: Ative a proteção contra eliminação suave e purga para proteger contra a eliminação de dados.
• Para cenários críticos para a missão: Use o SKU Premium e configure a réplica incluída para permitir a replicação em várias regiões, melhorando a alta disponibilidade e a resiliência face a interrupções regionais.

Para uma lista de práticas recomendadas e configurações para cargas de trabalho em produção, veja Construir aplicações com alta resiliência.

Visão geral da arquitetura de confiabilidade

Quando implementas a Configuração de Aplicações, implementas uma loja. A sua loja contém vários tipos de definições que a sua aplicação pode usar, incluindo chaves e valores, e sinalizadores de funcionalidades. O serviço inclui também capacidades integradas para organizar, proteger, versionar e implementar de forma segura alterações de configuração em vários ambientes. Para mais informações, veja O que é a Configuração de Aplicações Azure?

A Configuração de Aplicações é um serviço totalmente gerido. A Microsoft é responsável por armazenar e gerir as suas definições, bem como pela manutenção do serviço.

Quando você constrói aplicações cliente que se ligam ao Azure App Configuration, pode opcionalmente usar o Azure App Configuration com o Azure Front Door (pré-visualização) para ativar a cache e a aceleração global de tráfego. Esta configuração introduz outras considerações para a geo-replicação, que são destacadas ao longo deste artigo quando apropriado.

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 o Azure App Configuration, considere as seguintes melhores práticas para minimizar o efeito de falhas transitórias no acesso à configuração, especialmente em caminhos críticos de código.

• Fornecedores de configuração: Utilize os fornecedores de configuração do App Configuration, que têm capacidades integradas de reintento e cache, juntamente com muitas outras funcionalidades de resiliência.
• Azure SDKs: Use os SDKs de Configuração de Aplicações se a sua aplicação precisar de enviar pedidos de escrita. Os SDKs repetem automaticamente nas respostas com códigos de estado HTTP 429 e outros erros transitórios.
• Lógica de Repetição: Inclui lógica de repetição em clientes personalizados se não conseguires usar Fornecedores de Configuração de Aplicações ou SDKs. O retry-after-ms cabeçalho na resposta fornece um tempo de espera sugerido em milissegundos antes de tentar novamente o pedido.
• Definições de Cache: Armazene as definições de cache na memória sempre que possível para reduzir os pedidos diretos à loja.

Para outras orientações sobre configuração de aplicações, consulte o FAQ de Configuração de Aplicações Azure.

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.

A Configuração de Aplicações fornece automaticamente redundância de zonas em regiões que suportam zonas de disponibilidade. Essa redundância fornece alta disponibilidade dentro de uma região sem exigir nenhuma configuração específica.

Quando uma zona de disponibilidade se torna indisponível, a Configuração de Aplicações redireciona automaticamente os seus pedidos para outras zonas de disponibilidade saudáveis para garantir uma alta disponibilidade.

Requerimentos

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

Américas	Europa	Médio Oriente	África	Ásia-Pacífico
Sul do Brasil	Centro de França	Israel Central		Leste da Austrália
Canadá Central	Alemanha Centro-Oeste	Catar Central		Índia Central
E.U.A. Central	Norte de Itália	Norte dos E.A.U.		Norte da China 3
E.U.A. Leste	Europa do Norte			Ásia Leste
E.U.A. Leste 2	Leste da Noruega			Leste do Japão
México Central	Polónia Central			Coreia Central
E.U.A. Centro-Sul	Espanha Central			Sudeste Asiático
US Gov - Virginia	Suécia Central
E.U.A. Oeste 2	Norte da Suíça
E.U.A. Oeste 3	Sul do Reino Unido
	Europa Ocidental

Custo

Não há custo extra pela redundância de zonas para a configuração de aplicações do Azure.

Configurar o suporte à zona de disponibilidade

A Microsoft ativa automaticamente a redundância de zonas para uma loja quando esta está numa região que suporta zonas de disponibilidade.

Se a App Configuration adicionar suporte a zonas de disponibilidade a uma região existente, não precisa de fazer nada para começar a beneficiar do suporte a zonas de disponibilidade. A sua loja beneficiará do suporte de zonas de disponibilidade que se tornou disponível para as lojas de Configuração de Aplicações na região.

Comportamento quando todas as zonas estão íntegras

Quando uma loja está numa região que suporta redundância de zonas e todas as zonas de disponibilidade estão operacionais, pode esperar o seguinte comportamento:

• Operação entre zonas: A Configuração de Aplicações gere automaticamente o encaminhamento do tráfego entre zonas de disponibilidade. Durante as operações normais, distribui os pedidos de forma transparente entre as zonas.

• Replicação de dados entre zonas: Nas regiões que suportam zonas, a Configuração de Aplicações replica os dados de forma síncrona entre as zonas de disponibilidade. Esta replicação garante que as suas definições permanecem consistentes e disponíveis mesmo que uma zona se torne indisponível.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando uma loja está numa região que suporta redundância de zona e uma zona de disponibilidade não está disponível:

• Deteção e resposta: O serviço de Configuração de Aplicações deteta falhas de zona e responde automaticamente a elas. Você não precisa tomar nenhuma medida durante uma falha 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.

• Solicitações ativas: Durante uma falha de zona, a zona afetada pode falhar ao lidar com solicitações em voo, o que exige que os aplicativos cliente as tentem novamente. Os aplicativos cliente devem seguir práticas transitórias de tratamento de falhas para garantir que 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 previsto: Não se espera tempo de inatividade.

• Redistribuição: A Configuração da Aplicação redireciona automaticamente o tráfego da zona afetada para zonas saudáveis, sem necessidade de intervenção do cliente.

Recuperação de zona

Quando uma zona anteriormente indisponível recupera, a Configuração da Aplicação restaura automaticamente as operações normais em todas as zonas de disponibilidade. Não precisas de tomar qualquer ação para recuperar de uma falha de zona.

Teste de falhas de zona

A plataforma Azure App Configuration gere o encaminhamento de tráfego, failover e recuperação de zonas para armazenamentos redundantes de zona. Como este processo é totalmente gerido pela Microsoft, não é necessário validar processos de falha em zonas de disponibilidade.

Resiliência a falhas em toda a região

O Azure App Configuration fornece capacidades nativas de geo-replicação para apoiar a resiliência durante interrupções regionais. A geo-replicação permite replicar dados de configuração entre regiões como uma funcionalidade de serviço gerido.

Georreplicação

A geo-replicação permite que um armazenamento seja replicado em múltiplas regiões Azure. Cada loja pode ter várias réplicas em diferentes regiões. A loja original é também uma réplica. Esta capacidade ajuda a proteger as aplicações contra perturbações regionais.

Requerimentos

• Apoio regional: Podes criar réplicas em qualquer região Azure suportada pelo Azure App Configuration, mesmo que as regiões não sejam regiões emparelhadas com Azure.

• Tier: O armazenamento de configuração deve usar um nível suportado para permitir a geo-replicação. Para mais informações, consulte Ativar geo-replicação.

Considerações

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

• Réplicas redundantes de zona: Qualquer réplica que crie numa região onde a Configuração de Aplicações suporta zonas de disponibilidade é automaticamente redundante por zona.

• Azure Front Door: Para permitir a entrega geo-redundante de configuração com o Azure Front Door, configure réplicas do Configuração de Aplicação como origens dentro de um grupo de origem. A configuração correta da origem permite ao Azure Front Door gerir o roteamento baseado em saúde, balanceamento de carga e failover automático entre regiões. Para mais informações, veja Métodos de encaminhamento de tráfego para a origem.

Custo

Cada região geo-replicada é faturada separadamente de acordo com os preços do respetivo nível e região. Não se aplicam taxas de saída de dados para replicação entre regiões. Para detalhes de preços, consulte Azure App Configuration pricing.

Configurar suporte a várias regiões

Para configurar a replicação para um armazenamento de configuração recém-criado, veja Ativar geo-replicação.

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

Esta secção descreve o que esperar quando configura um repositório de Configuração de Aplicações para georreplicação, e todas as regiões estão operacionais.

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

  O Azure App Configuration não encaminha automaticamente o tráfego entre regiões. Quando utiliza fornecedores de configuração do App Configuration, a sua aplicação pode, opcionalmente, usar a descoberta automática de réplicas. Em alternativa, pode especificar uma lista prioritária de réplicas, e a Configuração da Aplicação seleciona a primeira réplica saudável. Isto permite que a sua aplicação controle qual a réplica que utiliza.

  Observação

  Se usar o Azure Front Door, o comportamento do encaminhamento de tráfego é diferente. Para obter mais informações, consulte Failover e balanceamento de carga.

• Replicação de dados entre zonas: Os dados são replicados de forma assíncrona e acabam por ser consistentes. Podes usar a métrica de latência de replicação no Azure Monitor para monitorizar a latência atual de replicação entre réplicas.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando configura uma loja de Configuração de Aplicações para geo-replicação, e há uma falha numa das regiões de réplica.

• Deteção e resposta: A Microsoft é responsável por detetar falhas de região ou réplicas e iniciar processos de recuperação.

  Quando utiliza fornecedores de configuração de Configuração de Aplicações e realiza a descoberta automática de réplicas ou com uma lista de múltiplas réplicas, a sua aplicação passa automaticamente para outra réplica saudável.

  Se não usar fornecedores de Configuração de Aplicações, é responsável por mudar a sua aplicação para uma réplica saudável.

• 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: Pedidos ativos direcionados a uma réplica na região poderão ser rejeitados. As aplicações cliente devem tentar novamente os pedidos contra uma réplica diferente.

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

• Tempo de inatividade previsto: Quando uma réplica se torna indisponível, permanece offline até que a sua região recupere. Outras réplicas continuam a processar pedidos. As aplicações podem sofrer um breve período de inatividade enquanto detetam a falha e mudam para uma réplica saudável. A duração depende da rapidez com que cada aplicação executa esta deteção e failover.

• Redistribuição: As aplicações devem encaminhar o tráfego para uma réplica saudável quando ocorre uma falha.

  Se usar fornecedores de configuração do App Configuration, os fornecedores tratam automaticamente da seleção de réplicas e do failover.

  Se colocar o serviço Azure Front Door em frente ao seu data store e configurar o grupo de origem com várias réplicas como origens para recuperação de falhas, o Azure Front Door redireciona automaticamente os pedidos para uma réplica em bom estado.

Recuperação da região

Depois de a região recuperar, a Configuração da Aplicação traz a réplica de volta em sincronia com as outras réplicas sem a sua intervenção.

És responsável por reconfigurar a tua aplicação para encaminhar o tráfego de volta para a instância da região recuperada. As aplicações que utilizam fornecedores de Configuração de Aplicações começam automaticamente a usar a réplica novamente.

Teste para falhas regionais

Atualmente, não se pode simular diretamente um failover de réplica na App Configuration. No entanto, como as aplicações controlam a seleção de réplicas, pode testar o comportamento de failover forçando a aplicação a entrar num estado em que ela tem de trocar as réplicas.

Para validar o comportamento de failover réplica da sua aplicação, pode introduzir uma falha controlada de conectividade num ambiente não produtivo e observar como a aplicação responde.

Uma abordagem é usar a sua máquina local ou outro ambiente onde tenha acesso administrativo. Siga estes passos:

1. Ative o registo verbose para o Azure SDK. No .NET, use a classe AzureEventSourceListener para configurar um logger. Para mais informações, consulte Tutorial: Usar configuração dinâmica numa aplicação .NET - Registo e monitorização.

2. Configure manualmente o seu hosts ficheiro para que os pedidos para a sua loja de Configuração de Aplicações sejam encaminhados para um endereço IP que não os possa receber, como 127.0.0.1 (localhost).

   Advertência

   Este passo bloqueia efetivamente o acesso do seu computador à sua loja de Configuração de Aplicações. Segue estes passos apenas num ambiente sem produção.

3. Monitorize os registos para 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'.
   

   Esta mensagem indica que a aplicação conseguiu com sucesso fazer a transferência para outra réplica da sua loja.

4. Depois de completar o teste, desfaça as alterações ao seu hosts ficheiro.

Backup e restauração

O Azure App Configuration permite-lhe exportar dados de configuração de uma loja e utilizá-los como parte de uma estratégia de backup mais ampla.

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

Resiliência à eliminação acidental

A Configuração de Aplicações oferece duas funcionalidades principais de recuperação para evitar eliminações acidentais ou maliciosas:

• Eliminação suave: Quando ativado, a eliminação suave permite-lhe recuperar armazenamentos e definições apagados durante um período de retenção configurável. Pensa na eliminação suave como um contentor de reciclagem para os teus recursos de Configuração de Aplicações.

• Proteção contra purgas: Quando ativada, a proteção contra purgas impede a eliminação permanente da sua loja e das suas definições até que o período de retenção termine. Esta salvaguarda impede que agentes maliciosos destruam permanentemente as suas definições.

Use ambas as funcionalidades para ambientes de produção. Para mais informações, consulte Proteção contra eliminação suave e purga.

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

A Microsoft realiza regularmente atualizações de serviço e outras manutenções. O serviço gere estas atividades automaticamente, garantindo que a manutenção seja 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.

Resiliência a problemas de configuração

Alterações de configuração incorretas ou acidentais podem causar tempo de inatividade na aplicação. Use instantâneos de configuração para implementar alterações na configuração de forma segura. Monitorize o estado da sua aplicação após quaisquer alterações de configuração e volte ao último instantâneo de configuração conhecido se as alterações introduzirem um problema.

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.

Conteúdo relacionado

• Fiabilidade no Azure
• Documentação da Configuração de Aplicativo do Azure