Confiabilidade no Serviço de Aplicativo do Azure

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 integra-se ao Microsoft Azure para fornecer segurança, balanceamento de carga, dimensionamento automático e gerenciamento automatizado para aplicativos. Como um serviço do Azure, o Serviço de Aplicativo fornece uma variedade de recursos para dar suporte aos seus requisitos de confiabilidade.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar 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 como tornar o Serviço de Aplicativo resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções na região e manutenção do serviço. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (Contrato de Nível de Serviço de Aplicativo).

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

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, desempenho, segurança, custo e operações. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável do Serviço de Aplicativo, consulte as práticas recomendadas de arquitetura para o Serviço de Aplicativo (Aplicativos Web) no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Ao criar um aplicativo Web do Serviço de Aplicativo, especifique o plano do Serviço de Aplicativo que executa o aplicativo.

Um plano do Serviço de Aplicativo define um conjunto de recursos de computação que executam seus aplicativos Web. Todos os aplicativos web devem ser executados dentro de um plano. Você pode escalar um plano para ser executado em múltiplas instâncias de VM, também chamadas de trabalhadores. Essas instâncias fornecem os recursos de computação que executam o código do seu aplicativo. Um único plano do App Service pode hospedar múltiplos aplicativos. Todos os aplicativos são executados no mesmo conjunto compartilhado de instâncias de VM.

O App Service fornece os seguintes recursos de redundância:

• Distribuição entre domínios de falha: No nível da plataforma, o Azure distribui automaticamente as instâncias de VM do seu plano do App Service entre domínios de falha dentro da região do Azure. Essa distribuição minimiza o risco de falhas de hardware localizadas agrupando VMs que compartilham uma fonte de energia e um alternador de rede comuns.

• Distribuição entre zonas de disponibilidade: Se você ativar a redundância de zonas em um plano do App Service compatível, o Azure distribuirá suas instâncias entre zonas de disponibilidade dentro da região. Essa configuração oferece maior resiliência caso ocorra uma falha em uma zona. Para mais informações sobre redundância de zonas, veja Suporte a zonas de disponibilidade.

• Dimensionamento de aplicativos: Ao configurar seu plano do App Service para executar múltiplas instâncias de VM, todos os aplicativos no plano são executados em todas as instâncias por padrão. Se você configurar seu plano para dimensionamento automático, todos os aplicativos serão escalados juntos com base nas configurações de dimensionamento automático. No entanto, você pode personalizar quantas instâncias de plano executam um aplicativo específico usando o dimensionamento por aplicativo.

• Unidades de escala: Internamente, o Serviço de Aplicativo é executado em uma infraestrutura de plataforma chamada unidades de escala, também conhecidas como selos ou webspaces. Uma unidade de escala inclui todos os componentes necessários para hospedar e executar o App Service, incluindo computação, armazenamento, rede e balanceamento de carga. O Azure gerencia unidades de escala para garantir a distribuição de carga de trabalho equilibrada, executar a manutenção de rotina e manter a confiabilidade geral da plataforma.

  Algumas funcionalidades podem ser aplicadas apenas a unidades de escala específicas. Por exemplo, algumas unidades de escala do App Service podem oferecer suporte à redundância de zonas, enquanto outras unidades de escala na mesma região não.

Resiliência a 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. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Os SDKs fornecidos pela Microsoft geralmente lidam com falhas transitórias. Como você hospeda suas próprias aplicações no App Service, tome medidas para reduzir a chance de falhas transitórias:

• Implante várias instâncias em seu plano. O Serviço de Aplicativo executa atualizações automatizadas e outras formas de manutenção em instâncias em 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 não está disponível e uma nova instância não está pronta para atender ao tráfego. Para mitigar esses efeitos, implante múltiplas instâncias do seu plano do App Service.

• Usar slots de implantação. Os slots de implantação do Serviço de Aplicativo permitem implantações sem tempo de inatividade dos seus aplicativos. Use slots de implantação para minimizar o efeito de implantações e alterações de configuração para seus usuários. Os slots de implantação também reduzem a probabilidade de seu aplicativo ser reiniciado. Reiniciar o aplicativo causa uma falha transitória.

• Evite escalar verticalmente ou reduzir verticalmente. Essas operações alteram a CPU, a memória e outros recursos atribuídos a cada instância, podendo acionar a reinicialização do aplicativo. Em vez disso, selecione uma camada e um tamanho de instância que atendam aos seus requisitos de desempenho sob carga típica. Para escalar horizontalmente, adicione e remova instâncias dinamicamente para lidar com mudanças no volume de tráfego.

Resiliência a falhas de zona de disponibilidade

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

Para as camadas Premium v2 a v4, você pode configurar o Serviço de Aplicativo com redundância de zona, o que significa que os seus recursos são distribuídos entre várias zonas de disponibilidade. A distribuição em várias zonas ajuda suas cargas de trabalho de produção a obter resiliência e confiabilidade. Quando você configura a redundância de zona em planos do Serviço de Aplicativo, todos os aplicativos que usam o plano obtêm redundância de zona.

Requisitos

Para habilitar a redundância de zona, você deve atender aos seguintes requisitos:

• Suporte à região: Para planos do Serviço de Aplicativo Premium v2 e v3 , há suporte para redundância de zona em qualquer região que dê suporte a zonas de disponibilidade.

• Tipo de plano: Use tipos de plano Premium v2 até v4.

  Importante

  Para habilitar a redundância de zona para planos do Serviço de Aplicativo Premium v4 , você deve confirmar se sua região desejada dá suporte a planos v4 e se ela dá suporte a zonas de disponibilidade.

• Número mínimo de instâncias: Implante no mínimo duas instâncias em seu plano.

• Unidade de escala: Seu aplicativo deve ser implantado em uma unidade de escala que dê suporte a zonas de disponibilidade. Você não controla diretamente a unidade de escala que seu plano usa. Em vez disso, quando você cria um plano do Serviço de Aplicativo, o plano é atribuído a uma unidade de escala com base no grupo de recursos do plano. Para determinar se a unidade de escala do plano do Serviço de Aplicativo dá suporte à redundância de zona, confira Verificar se há suporte à redundância de zona para um plano do Serviço de Aplicativo.

  Se o plano do Serviço de Aplicativo estiver em uma unidade de escala que não ofereça suporte à redundância de zona, você não poderá habilitar a redundância de zona em seu plano. Em vez disso, você precisa reimplantar seus aplicativos para um novo plano em uma unidade de escala diferente.

Distribuição de instâncias entre zonas

Quando você cria um plano do App Service redundante por zona, o Azure distribui as instâncias do plano entre as zonas de disponibilidade na região. Essa distribuição garante que seus aplicativos permaneçam disponíveis mesmo que uma zona sofra uma falha.

A distribuição de instâncias em uma implantação com redundância de zona segue regras específicas. Essas regras também se aplicam à medida que o aplicativo escala horizontalmente para dentro e para fora:

• Instâncias mínimas: Seu plano do Serviço de Aplicativo deve ter no mínimo duas instâncias para redundância de zona.

• Zonas de disponibilidade máxima compatíveis com seu plano: O Azure determina o número de zonas de disponibilidade que seu plano pode usar, que é chamado de maximumNumberOfZones. Para visualizar o número de zonas de disponibilidade que seu plano específico pode usar, veja Verificar suporte à redundância de zonas para um plano do Serviço de Aplicativo.

• Distribuição de instâncias: Quando a redundância de zonas está ativada, o Azure distribui automaticamente as instâncias do plano entre múltiplas zonas de disponibilidade. A distribuição é baseada nas seguintes regras:

  • Se o número de instâncias exceder maximumNumberOfZones e se dividir igualmente, o Azure distribui as instâncias de forma equilibrada entre as zonas.

  • Se o número de instâncias não se dividir igualmente, o Azure distribui as instâncias restantes entre as 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 balanceamento de zona de melhor esforço que os conjuntos de dimensionamento de máquinas virtuais do Microsoft Azure subjacentes fornecem. Um plano está balanceado se cada zona tiver o mesmo número de VMs ou diferir por uma instância em relação a todas as outras zonas. Para obter mais informações, consulte Balanceamento de zona.

• Posicionamento de zona física: Você pode exibir a zona de disponibilidade física usada para cada uma das instâncias do plano do Serviço de Aplicativo. Para obter mais informações, confira Exibir as zonas físicas de um plano do Serviço de Aplicativo.

Considerações

Para planos Premium v2 a v4, uma interrupção de zona de disponibilidade pode afetar alguns aspectos do Serviço de Aplicativo do Azure, mesmo que o aplicativo continue a atender ao tráfego. Esses comportamentos incluem dimensionamento do Plano do Serviço de Aplicativo, criação de aplicativo, configuração de aplicativo e publicação de aplicativo.

Ao habilitar a redundância de zona no plano do Serviço de Aplicativo Premium v2 a v4, você também melhora a resiliência durante as atualizações da plataforma. Para obter mais informações, consulte Resiliência à manutenção do serviço.

Para planos do Serviço de Aplicativo que não são configurados como com redundância de zona, as instâncias de máquina virtual (VM) subjacentes 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.

Custo

Ao usar os planos do Serviço de Aplicativo Premium v2 a v4, habilitar zonas de disponibilidade não adicionará custo se você tiver duas ou mais instâncias. Os encargos são baseados no SKU do plano do Serviço de Aplicativo, na capacidade especificada e nas 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 inferior a duas, a plataforma imporá uma contagem mínima de duas instâncias. A plataforma cobra por essas duas instâncias.

Configurar o suporte à zona de disponibilidade

• Crie um novo plano do Serviço de Aplicativo com redundância de zona. Para obter mais informações, confira Criar um novo plano do Serviço de Aplicativo que inclua redundância de zona.

• Habilitar ou desabilitar a redundância de zona em um plano do Serviço de Aplicativo existente. Para obter mais informações, confira Definir redundância de zona para um plano do Serviço de Aplicativo existente.

Planejamento e gerenciamento de capacidade

Para se preparar para uma falha na zona de disponibilidade, considere o superprovisionamento da capacidade do plano de Serviço de Aplicativo. Essa abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem desempenho degradado. Para mais informações, consulte Gerenciar capacidade usando superprovisionamento.

Comportamento quando todas as zonas estão saudáveis

A lista a seguir descreve o que esperar quando os planos do App Service estão configurados para redundância por zona e todas as zonas de disponibilidade estão operacionais:

• 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 App Service em todas as zonas de disponibilidade.

• Replicação de dados entre zonas: Durante operações normais, qualquer estado armazenado no sistema de arquivos do aplicativo é armazenado no armazenamento com redundância de zona e replicado de forma síncrona entre zonas de disponibilidade.

Comportamento durante uma falha de zona

Uma falha em uma zona de disponibilidade pode afetar alguns aspectos do App Service, mesmo que o aplicativo continue a atender ao tráfego. 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 lista a seguir descreve o que esperar quando os planos do App Service estão configurados para redundância por zona e uma ou mais zonas de disponibilidade estão indisponíveis:

• Detecção e resposta: A plataforma do Serviço de Aplicativo detecta automaticamente falhas em uma zona de disponibilidade e inicia uma resposta. Não é necessária intervenção manual para iniciar um failover de zona.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também 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 de problemas.

• Solicitações ativas: Quaisquer solicitações em andamento que se conectem a uma instância do plano do App Service na zona de disponibilidade com falha são encerradas. Tente novamente essas solicitações.

• Redirecionamento de tráfego: O App Service detecta as instâncias perdidas daquela zona e tenta localizar novas instâncias de substituição. Depois que o App Service encontra substituições, ele distribui o tráfego entre as novas instâncias conforme necessário.

  Se a escalabilidade automática estiver configurada e determinar que mais instâncias são necessárias, ela solicitará instâncias ao Serviço de Aplicativo. O comportamento da escalabilidade automática opera de forma independente do comportamento da plataforma do Serviço de Aplicativo. Portanto, sua especificação de contagem de instâncias não precisa ser um múltiplo de dois. Para obter mais informações, confira Escalar verticalmente um aplicativo no Serviço de Aplicativo e Visão geral da escala automática.

  Importante

  O Azure não garante que as solicitações por mais instâncias sejam bem-sucedidas em um cenário de queda de zona. A plataforma tenta repor as instâncias perdidas com base no melhor esforço possível. Se você precisar de capacidade garantida durante uma falha de zona de disponibilidade, crie e configure seus planos do Serviço de Aplicativo para considerar a perda de zona por meio do superprovisionamento da capacidade.

• Comportamentos não relacionados à execução: As aplicações em um plano do Serviço de Aplicativo com redundância por zona continuam em funcionamento e atendendo ao tráfego mesmo que uma zona de disponibilidade sofra uma interrupção. No entanto, 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.

Recuperação de zona

Quando a zona de disponibilidade se recupera, o Serviço de Aplicativo 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 como de costume.

Testar falhas em zonas

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

Resiliência a falhas em toda a região

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

Soluções personalizadas de várias regiões para resiliência

Para reduzir o risco de uma falha de região única que afete seu aplicativo, você pode implantar planos em várias regiões. As etapas a seguir ajudam a fortalecer a resiliência:

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

Considere os seguintes recursos relacionados:

• Arquitetura de referência: aplicativo Web de várias regiões altamente disponível
• Abordagens a serem consideradas
• Tutorial: Criar um aplicativo de várias regiões altamente disponível no Serviço de Aplicativo

Backup e restauração

Ao usar a camada Básica ou superior, você pode fazer backup dos seus aplicativos do Serviço de Aplicativo em um arquivo usando os recursos de backup e restauração do Serviço de Aplicativo.

Esses recursos ajudam quando é difícil reimplantar o código ou quando você armazena estado em disco. A maioria das soluções não deve depender exclusivamente de backups. Em vez disso, use os outros recursos deste guia para atender aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem.

Resiliência à manutenção do serviço

O Serviço de Aplicativo realiza atualizações regulares de serviço e outras tarefas de manutenção. Para manter sua capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extras do plano do Serviço de Aplicativo durante o processo de atualização.

Habilitar a redundância de zona. Ao ativar a redundância de zonas no seu plano do App Service, você também melhora a resiliência durante as atualizações da plataforma. Domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e que são mapeados para zonas de disponibilidade. Implantar várias instâncias no seu plano do Serviço de Aplicativo e habilitar a redundância por zona para o seu plano adiciona uma camada extra de resiliência caso uma instância ou zona se torne instável durante uma atualização.

Para obter mais informações, confira Manutenção planejada de rotina para o Serviço de Aplicativo e Manutenção de rotina para o Serviço de Aplicativo, reinicializações e tempo de inatividade.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs 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

• Confiabilidade no Azure
• Confiabilidade no Ambiente do Serviço de Aplicativo