Partilhar via


Fiabilidade no Serviço de Aplicações do Azure

Este artigo descreve o suporte à confiabilidade no Serviço de Aplicativo do Azure, abrangendo resiliência intrarregional 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, portanto, o 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 baseado em HTTP para hospedar aplicativos Web, APIs REST e back-ends móveis. O Serviço de Aplicativo do Azure adiciona o poder do Microsoft Azure ao seu aplicativo, com recursos de segurança, balanceamento de carga, dimensionamento automático e gerenciamento automatizado. Para explorar como o Serviço de Aplicativo do Azure pode reforçar a confiabilidade e a resiliência da carga de trabalho do seu aplicativo, consulte 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 trabalhadores 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 distribui automaticamente as instâncias entre as zonas de disponibilidade.

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

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

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

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

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

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

  • 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 não estiver íntegra, o serviço poderá substituí-la automaticamente 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 seu plano do Serviço de Aplicativo.

  • Use slots de implantação. Os slots de implantação do Serviço de Aplicativo do Azure permitem implantações sem tempo de inatividade 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 reinicialização do aplicativo, o que causa uma falha transitória.

  • Evite aumentar ou diminuir a escala. 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 a expansão para cima e para baixo pode desencadear uma reinicialização do aplicativo.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de 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, consulte O que são zonas de disponibilidade?.

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

A distribuição de instâncias com uma implantação redundante de zona é determinada dentro das seguintes regras, mesmo quando o aplicativo é dimensionado para dentro e para fora:

  • A contagem mínima de instâncias do plano do Serviço de Aplicativo é três.
  • Se você 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.
  • Qualquer contagem de instâncias além de 3*N está espalhada pelas 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 escala de máquina virtual do Azure subjacentes. Um plano do Serviço de Aplicativo será "equilibrado" se cada zona tiver 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 são configurados como redundantes de zona, as instâncias de VM não são resilientes a falhas de zona de disponibilidade. Eles podem enfrentar tempo de inatividade durante uma interrupção em qualquer zona dessa região.

Regiões suportadas

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

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

Requisitos

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

  • As zonas de disponibilidade só são suportadas na pegada mais recente do Serviço de Aplicativo. Mesmo que esteja a utilizar uma das regiões suportadas, receberá um erro se as zonas de disponibilidade não forem suportadas para o seu grupo de recursos. Para garantir que suas cargas de trabalho cheguem a um carimbo que ofereça suporte a zonas de disponibilidade, talvez seja necessário criar um novo grupo de recursos, um plano do Serviço de Aplicativo e um Serviço de Aplicativo.

  • Você deve implantar um mínimo de três instâncias do seu plano.

Considerações

Os aplicativos implantados em um plano do Serviço de Aplicativo com redundância de zona continuam a ser executados e a atender tráfego mesmo que várias zonas da região sofram uma interrupção. No entanto, é possível que comportamentos sem tempo de execução, incluindo o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação de aplicativos, ainda possam ser afetados durante uma interrupção da zona de disponibilidade. A redundância de zona para planos do Serviço de Aplicativo garante apenas o tempo de atividade contínuo para aplicativos implantados.

Custo

Quando você estiver usando os planos do Serviço de Aplicativo Premium v2 ou Premium v3, não há custo adicional associado à ativaçã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 na SKU do seu plano do Serviço de Aplicativo, na capacidade especificada e em todas as instâncias para as quais você dimensionar com base em seus critérios de dimensionamento automático. Se você habilitar zonas de disponibilidade, mas especificar uma capacidade inferior a três, a plataforma imporá uma contagem mínima de instâncias de três e cobrará por essas três instâncias.

O Ambiente do Serviço de Aplicativo v3 tem um modelo de preços específico para redundância de zona. Para obter informações sobre preços para o 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 Zona redundante ao implantar o plano.

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

A redundância de zona só pode ser configurada ao criar um novo plano do Serviço de Aplicativo. Se você tiver um plano existente do Serviço de Aplicativo que não seja redundante de zona, precisará substituí-lo por um novo plano com redundância de zona. Não é possível converter um plano existente do Serviço de Aplicativo para usar zonas de disponibilidade. Da mesma forma, não é possível desativar a redundância de zona em um plano existente do Serviço de Aplicativo.

Planejamento e gerenciamento de capacidade

Para se preparar para falhas na zona de disponibilidade, você deve provisionar excessivamente a capacidade de serviço para garantir que a solução possa tolerar 1/3 de perda de capacidade e continuar a funcionar sem desempenho degradado durante interrupções em toda a zona. Como a plataforma distribui VMs por três zonas e você precisa levar em conta pelo menos a falha de uma zona, multiplique a contagem de instâncias de pico de carga de trabalho por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se sua carga de trabalho de pico típica requer quatro instâncias, você deve 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 disponíveis do plano do Serviço de Aplicativo em todas as zonas de disponibilidade.

Experiência de zone-down

Deteção e resposta: a plataforma do Serviço de Aplicativo é responsável por detetar 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 defeituosa são encerradas e precisam ser repetidas.

Reencaminhamento de tráfego: quando uma zona não está disponível, o Serviço de Aplicação do Azure deteta as instâncias perdidas dessa zona. Ele tenta encontrar automaticamente novas instâncias de substituição. Em seguida, ele distribui o tráfego pelas novas instâncias conforme necessário.

Se você tiver configurado o dimensionamento automático e 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.

Nota

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 de instâncias adicionais em um cenário de zone-down sejam bem-sucedidas. O preenchimento de instâncias perdidas ocorre com base no melhor esforço. Se precisar de capacidade garantida quando uma zona de disponibilidade for perdida, crie e configure seus planos do Serviço de Aplicativo para contabilizar a perda de uma zona. Você pode fazer isso provisionando demais a capacidade do seu plano do Serviço de Aplicativo.

Reativação pós-falha

Quando a zona de disponibilidade se recupera, 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, failover e failback para planos do Serviço de Aplicativo com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou validar processos de falha da zona de disponibilidade.

Suporte multi-região

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

Soluções alternativas multi-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. Para fazer isso, você deve:

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

Por exemplo, arquiteturas que ilustram essa abordagem, consulte:

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

Para obter um exemplo de abordagem que ilustra essa arquitetura, consulte Implantação corporativa de alta disponibilidade usando o Ambiente do Serviço de Aplicativo.

Cópias de Segurança

Ao usar a camada Básica ou superior, você pode fazer backup do aplicativo do Serviço de Aplicativo em um arquivo usando os recursos de backup e restauração do Serviço de Aplicativo. Esse recurso é útil se for difícil reimplantar seu código ou se você armazenar o estado no disco. No entanto, para a maioria das soluções, você não deve confiar em 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.

Contrato de nível de serviço (SLA)

O contrato de nível de serviço (SLA) para o Serviço de Aplicativo do Azure descreve a disponibilidade esperada do serviço. Descreve igualmente as condições que devem ser satisfeitas para atingir essa expectativa de disponibilidade. Para entender essas condições, é importante que você revise os Contratos de Nível de Serviço (SLA) dos Serviços Online.

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