Compartilhar via


Confiabilidade no Serviço de Aplicativo do Azure

Este artigo descreve o suporte à confiabilidade no Serviço de Aplicativo do Azure. Ele abrange a resiliência intra-regional com zonas de disponibilidade e informações sobre implantações em várias regiões.

A resiliência é uma responsabilidade compartilhada entre você e a Microsoft. Este artigo também aborda maneiras de criar uma solução resiliente que atenda às suas necessidades.

O Serviço de Aplicativo do Azure é um serviço com base em HTTP para hospedagem de aplicativos Web, APIs REST e back-ends móveis. O Serviço de Aplicativo do Azure agrega o poder do Microsoft Azure ao seu aplicativo, com funcionalidades de segurança, balanceamento de carga, dimensionamento automático e gerenciamento automatizado. Para ver como o Serviço de Aplicativo do Azure pode reforçar a confiabilidade e a resiliência da carga de trabalho do seu aplicativo, confira Por que usar o Serviço de Aplicativo?

Ao implantar o Serviço de Aplicativo do Azure, você pode criar várias instâncias de um plano do Serviço de Aplicativo, que representa os trabalhos de computação que executam o código do aplicativo. Para obter mais informações, confira Plano do Serviço de Aplicativo do Azure. Embora a plataforma faça um esforço para implantar as instâncias em diferentes domínios de falha, ela não espalha automaticamente as instâncias entre zonas de disponibilidade.

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

Para implantações de produção, você deve:

  • Use planos do Serviço de Aplicativo Premium v3.
  • Habilite a redundância de zona, o que exige que seu plano do Serviço de Aplicativo use no mínimo três instâncias.

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. Elas se corrigem após um curto período de tempo. É importante que seu aplicativos tratem falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure ao se comunicar com as APIs, bancos de dados e outros componentes hospedados na nuvem. Para saber mais sobre como lidar com falhas transitórias, confira Recomendações para lidar com falhas transitórias.

Os SDKs fornecidos pela Microsoft geralmente lidam com falhas transitórias. Como você hospeda os seus próprios aplicativos no Serviço de Aplicativo do Azure, considere como evitar causar falhas transitórias, certificando-se de:

  • Implante várias instâncias do seu plano. O Serviço de Aplicativo do Azure executa atualizações automatizadas e outras formas de manutenção em instâncias do seu plano. Se uma instância ficar não íntegra, o serviço poderá substituir automaticamente essa instância por uma nova instância íntegra. Durante o processo de substituição, pode haver um curto período em que a instância anterior esteja indisponível e uma nova instância ainda não esteja pronta para atender ao tráfego. Você pode atenuar o impacto desse comportamento implantando várias instâncias do plano do Serviço de Aplicativo.

  • Usar slots de implantação. Os slots de implantação do Serviço de Aplicativo do Azure permitem implantações de tempo de inatividade zero de seus aplicativos. Use slots de implantação para minimizar o impacto de alterações de implantações e configurações para os seus usuários. O uso de slots de implantação também reduz a probabilidade do aplicativo ser reiniciado. A reinicialização causa uma falha transitória.

  • Evite expandir ou reduzir verticalmente. Em vez disso, selecione uma camada e um tamanho de instância que atendam aos seus requisitos de desempenho sob carga típica. Dimensione apenas instâncias para lidar com alterações no volume de tráfego. O dimensionamento para cima e para baixo pode disparar uma reinicialização do aplicativo.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos de datacenters fisicamente separados em cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.

Para obter mais informações sobre zonas de disponibilidade no Azure, confira O que são as zonas de disponibilidade?

O Serviço de Aplicativo do Azure pode ser configurado como com redundância de zona, o que significa que seus recursos estão espalhados por várias zonas de disponibilidade. A disseminação em várias zonas ajuda suas cargas de trabalho de produção a obter resiliência e confiabilidade. O suporte à zona de disponibilidade é uma propriedade do Plano do Serviço de Aplicativo.

A propagação de instância com uma implantação com redundância de zona é determinada usando as regras a seguir. Essas regras se aplicam mesmo à medida que o aplicativo é reduzido ou escalado horizontalmente:

  • A contagem mínima de instâncias do plano do Serviço de Aplicativo é três.
  • As instâncias serão espalharão uniformemente se você especificar uma capacidade maior que três e o número de instâncias for divisível por três.
  • As contagens de instâncias além de 3*N são distribuídas entre a única ou as duas zonas restantes.

Quando a plataforma do serviço de aplicativo aloca instâncias para um plano do serviço de aplicativo com redundância de zona, ela usa o melhor balanceamento de zona de esforço oferecido pelos Conjuntos de Dimensionamento de Máquinas Virtuais do Microsoft Azure subjacentes. Um Plano do Serviço de Aplicativo será equilibrado se cada zona tiver o mesmo número de máquinas virtuais ou uma a mais ou a menos, em todas as outras zonas. Para obter mais informações, confira Balanceamento de zona.

Para Planos do Serviço de Aplicativo que não estejam configurados como com redundância de zona, as instâncias de máquina virtual não são resilientes a falhas de zona de disponibilidade. Eles podem experimentar tempo de inatividade durante uma interrupção em qualquer zona nessa região.

Regiões com suporte

Planos do Serviço de Aplicativo com redundância de zona podem ser implantados em qualquer região que dê suporte a zonas de disponibilidade.

Para ver quais regiões dão suporte a zonas de disponibilidade para Ambiente do Serviço de Aplicativo v3, consulte Regiões.

Requisitos

  • Você precisa usar os tipos de plano Premium v2 ou Premium v3.

  • As zonas de disponibilidade só têm suporte no volume mais recente do Serviço de Aplicativo. Mesmo que você esteja usando uma das regiões com suporte, se não houver suporte para zonas de disponibilidade para o grupo de recursos, ocorrerá um erro. Para garantir que as suas cargas de trabalho cheguem em uma unidade de escala que dê suporte a zonas de disponibilidade, talvez seja necessário criar um novo grupo de recursos, Plano do Serviço de Aplicativo e Serviço de Aplicativo.

  • Você precisa implantar no mínimo três instâncias do seu plano.

Considerações

Aplicativos implantados em um plano do Serviço de Aplicativo com redundância de zona continuarão a executar e veicular tráfego mesmo que várias zonas na região sofram uma interrupção. Comportamentos que não são de runtime ainda podem ser afetados durante uma interrupção da zona de disponibilidade. Esses comportamentos incluem dimensionamento do Plano do Serviço de Aplicativo, criação de aplicativo, configuração de aplicativo e publicação de aplicativo. A redundância de zona para os planos do serviço de aplicativo garante apenas o tempo de atividade contínuo para aplicativos implantados.

Custo

Ao usar planos Premium v2 ou v3 do Serviço de Aplicativo, não há custo adicional associado à habilitação de zonas de disponibilidade, desde que você tenha três ou mais instâncias em seu Plano do Serviço de Aplicativo. Você é cobrado com base no SKU do Plano do Serviço de Aplicativo, na capacidade especificada e em todas as instâncias para as quais você dimensiona com base nos critérios de dimensionamento automático.

Se você habilitar zonas de disponibilidade, mas especificar uma capacidade menor que três, a plataforma imporá uma contagem mínima de três instâncias. A plataforma cobra por essas três instâncias.

O Ambiente do Serviço de Aplicativo v3 tem um modelo de preço específico para redundância de zona. Para obter informações sobre preços do Ambiente do Serviço de Aplicativo v3, consulte Preços.

Configurar o suporte à zona de disponibilidade

Para implantar um novo plano do Serviço de Aplicativo do Azure com redundância de zona, selecione a opção Com redundância de zona ao implantar o plano.

Para implantar um novo Ambiente do Serviço de Aplicativo do Azure com redundância de zona, confira Criar um Ambiente do Serviço de Aplicativo.

A redundância de zona só pode ser configurada quando você cria um novo Plano do Serviço de Aplicativo. Se você tiver um Plano do Serviço de Aplicativo existente que não possua redundância de zona, substitua-o por um novo plano com redundância de zona. Você não pode converter um plano do Serviço de Aplicativo existente para usar zonas de disponibilidade. Da mesma forma, você não pode desabilitar a redundância de zona em um plano do Serviço de Aplicativo existente.

Planejamento e gerenciamento de capacidade

Para se preparar para falha na zona de disponibilidade, você deve provisionar a capacidade de serviço em excesso. Essa abordagem garante que a solução possa tolerar perda de capacidade em 1/3 e continuar funcionando sem desempenho degradado durante interrupções em toda a zona. Como a plataforma espalha máquinas virtuais em três zonas e você precisa considerar a falha de pelo menos uma zona, multiplique a contagem de instâncias de carga de trabalho de pico por um fator de zones/(zones-1), ou 3/2. Por exemplo, se a carga de trabalho de pico comum exigir quatro instâncias, você deverá provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.

Roteamento de tráfego entre zonas

Durante as operações normais, o tráfego é roteado entre todas as instâncias do plano do Serviço de Aplicativo disponíveis em todas as zonas de disponibilidade.

Experiência de zona inoperante

Detecção e resposta. A plataforma do Serviço de Aplicativo é responsável por detectar uma falha em uma zona de disponibilidade e responder a ela. Você não precisa fazer nada para iniciar um failover de zona.

Solicitações ativas. Quando uma zona de disponibilidade não está disponível, todas as solicitações em andamento conectadas a uma instância do Plano do Serviço de Aplicativo na zona de disponibilidade com falha são encerradas. Eles precisam ser repetidos.

Redirecionamento de tráfego. Quando uma zona não está disponível, o Serviço de Aplicativo do Azure detecta as instâncias perdidas dessa zona. Ele tenta localizar automaticamente novas instâncias substitutas. Em seguida, ele espalha o tráfego entre as novas instâncias conforme necessário.

Se você tiver o dimensionamento automático configurado e se ele decidir que mais instâncias são necessárias, o dimensionamento automático também emitirá uma solicitação ao Serviço de Aplicativo para adicionar mais instâncias. Para obter mais informações, confira Escalar verticalmente um aplicativo no Serviço de Aplicativo do Azure.

Observação

O comportamento de dimensionamento automático é independente do comportamento da plataforma do Serviço de Aplicativo. Sua especificação de contagem de instâncias de dimensionamento automático não precisa ser um múltiplo de três.

Importante

Não há garantia de que as solicitações para mais instâncias em um cenário de zona inoperante tenham sucesso. O preenchimento posterior de instâncias perdidas ocorre com base no melhor esforço. Se você precisar de capacidade garantida quando uma zona de disponibilidade for perdida, você deverá criar e configurar seus planos do Serviço de Aplicativo para considerar a perda de uma zona. Você pode fazer isso superprovisionando a capacidade do plano do Serviço de Aplicativo.

Failback

Quando a zona de disponibilidade é recuperada, o Serviço de Aplicativo do Azure cria automaticamente instâncias na zona de disponibilidade recuperada, remove todas as instâncias temporárias criadas nas outras zonas de disponibilidade e roteia o tráfego entre suas instâncias normalmente.

Teste de falhas de zona

A plataforma do Serviço de Aplicativo do Azure gerencia o roteamento de tráfego, o failover e o failback para planos do Serviço de Aplicativo com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar nem validar processos de falha da zona de disponibilidade.

Suporte para várias regiões

O Serviço de Aplicativo do Azure é um serviço de região única. Se a região ficar indisponível, o seu aplicativo também ficará indisponível.

Soluções alternativas de várias regiões

Para garantir que o seu aplicativo se torne menos suscetível a uma falha de região única, você precisa implantá-lo em várias regiões:

  • Implante seu aplicativo nas instâncias em cada região.
  • Configure políticas de failover e balanceamento de carga.
  • Replique seus dados entre as regiões para que você possa recuperar o último estado do aplicativo.

Para obter uma abordagem de exemplo que ilustra essa arquitetura, confira Implantação empresarial de alta disponibilidade usando o Ambiente do Serviço de Aplicativo.

Backups

Ao usar a camada Básica ou superior, você pode fazer backup do aplicativo do Serviço de Aplicativo em um arquivo usando as funcionalidades de backup e restauração do Serviço de Aplicativo. Para obter mais informações, confira Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo do Azure.

Esse recurso será útil se for difícil reimplantar seu código ou se você armazenar o estado em disco. Para a maioria das soluções, você não deve contar com backups do Serviço de Aplicativo. Use os outros métodos descritos neste artigo para dar suporte aos seus requisitos de resiliência.

SLA (Contrato de Nível de Serviço)

O SLA (Contrato de Nível de Serviço) para o Serviço de Aplicativo do Azure descreve a disponibilidade esperada do serviço. Ele também descreve as condições que precisam ser atendidas para atingir essa expectativa de disponibilidade. Para entender essas condições, examine os Contratos de Nível de Serviço (SLA) de Serviços Online.

Quando você implanta um plano do Serviço de Aplicativo com redundância de zona, o percentual de tempo de atividade definido no SLA aumenta.