Compartilhar via

Confiabilidade no Serviço de Aplicativo do Azure

  • Artigo

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

A resiliência é uma responsabilidade compartilhada entre você e a Microsoft, e este artigo também aborda maneiras de você construir 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. 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.

Embora os SDKs fornecidos pela Microsoft geralmente manipulem falhas transitórias, pois você hospeda seus aplicativos no Serviço de Aplicativo do Azure, você precisa considerar como evitar causar falhas transitórias, certificando-se de que você:

  • 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 de tempo em que a instância anterior não está disponível e uma nova instância ainda não está 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 implantações e alterações de configuração em seus usuários. O uso de slots de implantação também reduz a probabilidade de o aplicativo ser reiniciado, o que 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. Considere que escalar e reduzir verticalmente pode disparar uma reinicialização do aplicativo.

Suporte à zona 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 a zonas de disponibilidade é uma propriedade do Plano do Serviço de Aplicativo.

A distribuição de instâncias com uma implantação com redundância de zona é determinada com base nas seguintes regras, mesmo quando o aplicativo é reduzido ou escalado horizontalmente:

  • A contagem mínima de instâncias do plano do Serviço de Aplicativo é três.
  • Se especificar uma capacidade maior que três e o número de instâncias for divisível por três, as instâncias serão distribuídas uniformemente.
  • 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 é "balanceado", se cada zona tem o mesmo número de VMs ou +/- uma VM em todas as outras zonas usadas pelo plano do Serviço de Aplicativo.

Para planos do Serviço de Aplicativo que não estão configurados como com redundância de zona, as instâncias de VM 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.

Requisitos

  • As zonas de disponibilidade só têm suporte no volume mais recente do Serviço de Aplicativo. Mesmo se você estiver usando uma das regiões com suporte, receberá um erro se as zonas de disponibilidade não tiverem suporte para o grupo de recursos. Para garantir que suas cargas de trabalho cheguem em um carimbo que dê suporte a zonas de disponibilidade, talvez seja necessário criar um novo grupo de recursos, um plano do Serviço de Aplicativo e o Serviço de Aplicativo.
  • Você precisa implantar no mínimo três instâncias do seu plano.

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.

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. Entretanto, é possível que comportamentos que não são de runtime, incluindo o dimensionamento do plano de serviço de aplicativo e a criação, configuração e publicação de aplicativos, ainda sejam afetados durante uma interrupção de zona de disponibilidade. 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

Quando você está usando planos Premium v2 ou Premium v3 do Serviço de Aplicativo, não há nenhum 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ê será cobrado com base no SKU do plano do Serviço de Aplicativo, na capacidade especificada e nas instâncias dimensionadas de acordo com os critérios de dimensionamento automático. Se você habilitar as zonas de disponibilidade, mas especificar uma capacidade menor que três, a plataforma impõe uma contagem de instâncias mínima de três e 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 usar a redundância de zona, alterne para um tipo de plano do Serviço de Aplicativo com suporte.

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 especificada ao criar um plano do Serviço de Aplicativo. Se você tiver um plano do Serviço de Aplicativo existente que não seja com redundância de zona, precisará substituí-lo 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 a falha da zona de disponibilidade, você deve superprovisionar a capacidade de serviço para garantir que a solução possa tolerar perda de 1/3 de capacidade e continuar funcionando sem desempenho degradado durante interrupções em toda a zona. Como a plataforma difunde as VMs em três zonas e você precisa considerar pelo menos a falha de uma zona, multiplique a contagem de instâncias de carga de trabalho de pico por um fator de zonas/(zonas-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. 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 e precisam ser repetidas.

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.

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á garantias de que as solicitações de instâncias adicionais em um cenário de zona inativa serão bem-sucedidas. 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 seu aplicativo se torne menos suscetível a uma falha de região única, você precisará implantar seu aplicativo em várias regiões. Você deve:

  • 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 exemplos de arquiteturas que ilustram essa abordagem, confira:

Para acompanhar um tutorial que cria um aplicativo de várias regiões, confira Tutorial: Criar um aplicativo de várias regiões altamente disponível no Serviço de Aplicativo do Azure.

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. Esse recurso será útil se for difícil reimplantar seu código ou se você armazenar o estado em disco. No entanto, para a maioria das soluções, você não deve contar com backups do Serviço de Aplicativo e, em vez disso, deve usar 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, é importante que você examine os SLA (Contratos de Nível de Serviço) para 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.

Conteúdo relacionado