Confiabilidade no Azure App Configuration

Azure App Configuration armazena e gere centralmente as definições de configuração da aplicação e as feature flags, substituindo os ficheiros de configuração embutidos diretamente nas aplicações. Com esta abordagem, pode atualizar dinamicamente os valores de configuração, acompanhar o histórico de versões e manter um registo 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 se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft disponibiliza uma variedade de capacidades para apoiar a resiliência e a 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 da Configuração de Aplicações e como o serviço é 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 ajudar a evitar 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 replicar em várias regiões. Esta abordagem melhora a elevada disponibilidade e resiliência face a interrupções regionais.

Para uma lista de práticas e configurações recomendadas para cargas de trabalho em produção, consulte Construa 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?

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

Quando constrói aplicações cliente que se ligam à App Configuration, pode opcionalmente usar App Configuration com Azure Front Door (pré-visualização) para ativar cache e aceleração global do 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.

Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Ao utilizar a Configuração de Aplicações, 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: Use os fornecedores de Configuração de Aplicações, que têm capacidades integradas de retentativa e cache, bem como outras funcionalidades de resiliência.

  • SDKs do Azure: Use os SDKs de Configuração da Aplicação 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 a 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 do cliente 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 as Perguntas Frequentes sobre Configuração de Aplicações.

Resiliência a falhas na zona de disponibilidade

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.

Diagrama que mostra uma loja de Configuração de Aplicações redundante por zonas que abrange três zonas na região.

O diagrama mostra as zonas de disponibilidade 1, 2 e 3. A App Configuration Store abrange as três zonas da região.

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 tornam-se 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 por redundância de zonas para Configuração da Aplicação.

Configurar o suporte à zona de disponibilidade

Microsoft configura automaticamente a redundância de zonas para uma loja quando esta está em uma 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 tomar qualquer ação para beneficiar do suporte a zonas de disponibilidade. A sua loja beneficia do suporte para zonas de disponibilidade que fica disponível para as lojas de Configuração de Aplicações na região.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando tem uma loja de Configuração de Aplicações redundante em zonas, e todas as zonas estão operacionais.

  • 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 tem uma loja de Configuração de Aplicações com redundância por zonas e ocorre uma falha numa das zonas.

  • 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, pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health alerts para o notificar de 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 App Configuration gere o encaminhamento de tráfego, failover e recuperação de zonas para lojas redundantes de zona. A Microsoft gere totalmente este processo, por isso não precisa de validar processos de falha em zonas de disponibilidade.

Resiliência a falhas em toda a região

A App Configuration fornece capacidades nativas de geo-replicação para suportar a resiliência durante interrupções regionais. A geo-replicação permite que os dados de configuração se replicem entre regiões como uma funcionalidade de serviço gerido.

Georreplicação

Com a geo-replicação, pode replicar uma loja 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. Esta capacidade ajuda a proteger as aplicações contra perturbações regionais.

Requerimentos

  • Region support: Pode criar réplicas em qualquer região do Azure que o App Configuration suporte, mesmo que as regiões não sejam regiões emparelhadas do 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 de configuração geo-redundante com Azure Front Door, configure réplicas de Configuração de Aplicações como origens dentro de um grupo de origem. Origens corretamente configuradas são necessárias para que o Azure Front Door realize encaminhamento 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 Preços de Configuração de Aplicações.

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 é individualmente endereçável e tem o seu próprio nome de Sistema de Nomes de Domínio (DNS). Todas as réplicas podem aceitar tanto operações de leitura como de escrita.

    A Configuração de Aplicações 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. Esta abordagem 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 do tráfego é diferente. Para obter mais informações, consulte Failover e balanceamento de carga.

  • Replicação de dados entre zonas: Os dados replicam-se de forma assíncrona e acabam por ser consistentes. Pode 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: Microsoft é responsável por detetar falhas de região ou réplica e iniciar processos de recuperação.

    Quando utiliza fornecedores de configuração de aplicação com descoberta automática de réplicas ou uma lista de múltiplas réplicas, a sua aplicação deteta automaticamente falhas e faz failover para uma 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 o notifica automaticamente a si quando uma região está inoperante. No entanto, pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

  • Pedidos ativos: Pedidos ativos contra uma réplica na região podem falhar. 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 Azure Front Door na frente do seu armazenamento de dados e configurar o grupo de origem com múltiplas réplicas como fontes para failover, 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 sincroniza a réplica 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 usam fornecedores de Configuração de Aplicações começam automaticamente a usar a réplica novamente.

Teste para falhas regionais

Não podes simular diretamente um failover de réplica no 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. Ativa o registo detalhado para o SDK do Azure. Em .NET, use a classe AzureEventSourceListener para configurar um logger. Para obter mais informações, consulte Registo de logs 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. Monitore os logs para uma mensagem semelhante à seguinte mensagem:

    [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

Pode usar o App Configuration para exportar dados de configuração de uma loja e usá-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 ativas a eliminação suave, podes recuperar armazenamentos e definições eliminados durante um período de retenção configurável. Funções de eliminação suave como um contentor de reciclagem para os recursos de Configuração da Aplicação.

  • Proteção contra purgas: Quando ativas a proteção contra purga, o serviço impede a eliminação permanente da tua 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, o que torna a manutenção simples e transparente para si. Não se espera tempo de inatividade durante os eventos de manutenção, a menos que Azure Service Health forneça um aviso de manutenção planeada.

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 a saúde 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 acordo de nível de serviço (SLA) para serviços Azure descreve a disponibilidade esperada de cada serviço e as condições que a sua solução deve cumprir para atingir essa expectativa de disponibilidade. Para mais informações, consulte SLAs para serviços online.