Confiabilidade no Ambiente do Serviço de Aplicativo do Azure

O Ambiente do Serviço de Aplicativo é um recurso do Serviço de Aplicativo do Azure que fornece um ambiente totalmente isolado e dedicado para executar aplicativos do Serviço de Aplicativo com segurança em alta escala. Como um serviço do Azure, o Ambiente do 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 o suporte à confiabilidade no Ambiente do Serviço de Aplicativo, incluindo resiliência a falhas transitórias, falhas na zona de disponibilidade e interrupções em toda a região. Ele também descreve estratégias de backup e resiliência à manutenção do serviço e destaca algumas informações importantes sobre o SLA (Contrato de Nível de Serviço de Ambiente do Serviço de Aplicativo).

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

Recomendamos que você habilite a redundância de zona em seu ambiente e planos do Serviço de Aplicativo, o que exige que seus planos usem no mínimo duas instâncias.

Visão geral da arquitetura de confiabilidade

Quando você implementa um Ambiente de Serviço de Aplicativos, você implanta o ambiente como o contêiner para seus planos de Serviço de Aplicativos e aplicativos web. Durante a configuração, configure as definições principais de rede e o isolamento de hardware opcional. Escolha se deseja suportar redundância de zonas no ambiente, caso a região ofereça zonas de disponibilidade.

Após criar seu ambiente, você pode criar um ou mais planos do App Service.

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.

Para usar um App Service Environment, seus planos devem utilizar o nível de preço Isoladov2. Este nível oferece suporte à redundância de zonas e a aplicativos críticos de missão em grande escala.

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.

Você pode configurar o seu Ambiente de Serviço de Aplicativos como redundante por zona. Você também pode configurar seus planos do App Service para serem redundantes por zona, o que os distribui entre múltiplas zonas de disponibilidade.

No entanto, você pode habilitar ou desabilitar a redundância de zona em cada plano. Isso significa que você pode ter alguns planos no seu ambiente com redundância de zona e outros que não têm.

Quando você cria um plano do Serviço de Aplicativo com redundância de zona em seu ambiente, as instâncias do plano do Serviço de Aplicativo são distribuídas entre as zonas de disponibilidade na região. Para obter mais informações, consulte distribuição de instâncias entre zonas.

Requisitos

Para habilitar a redundância de zonas para o seu Ambiente de Serviço de Aplicativos, você deve atender aos seguintes requisitos:

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

• Tipo de plano: Use tipos de plano v2 isolados.

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

• Unidade de escala: Seu ambiente 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 ambiente usa. Em vez disso, quando você cria um ambiente do Serviço de Aplicativo, o ambiente é atribuído a uma unidade de escala com base no grupo de recursos do ambiente. Para determinar se a unidade de escala do Ambiente do Serviço de Aplicativo oferece suporte à redundância de zona, verifique o suporte à redundância de zona para um Ambiente do Serviço de Aplicativo.

  Se o ambiente estiver em uma unidade de escala que não oferece suporte a zonas de disponibilidade, você não poderá habilitar a redundância de zona no seu ambiente ou nos seus planos. Em vez disso, você precisa criar um novo ambiente em um novo grupo de recursos e reimplantar seus aplicativos para novos planos dentro desse ambiente.

• Requisitos de configuração: Configure o Ambiente do Serviço de Aplicativo e seus planos para dar suporte à redundância de zona. Você pode habilitar a redundância de zonas durante a criação do ambiente ou atualizando um ambiente existente.

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, veja Ver as zonas físicas de um plano do Serviço de Aplicativo.

Considerações

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.

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. Para obter mais informações, consulte Resiliência à manutenção do serviço.

Para planos do App Service que não são redundantes por zona, as instâncias de VM subjacentes não são resilientes a falhas de zonas de disponibilidade. Eles podem experimentar tempo de inatividade durante uma interrupção em qualquer zona nessa região.

Custo

Você pode habilitar a redundância por zona em um Ambiente do App Service ou em seus planos sem custo adicional. No entanto, a redundância de zona para um plano exige que ele tenha duas ou mais instâncias. O preço é calculado com base na SKU do seu plano do Serviço de Aplicativo, na capacidade especificada e em quaisquer instâncias às quais você dimensionar com base nos critérios de escala automática.

Se você habilitar zonas de disponibilidade, mas especificar uma capacidade inferior a duas instâncias, a plataforma aplica um mínimo de duas instâncias. A plataforma cobra por essas duas instâncias.

Configurar o suporte à zona de disponibilidade

Para aprender a criar, habilitar ou desabilitar um novo Ambiente do App Service com redundância por zona e novos planos do App Service com redundância por zona, consulte Configurar Ambientes do App Service e planos do App Service Isolated v2 para redundância por zona.

Planejamento e gerenciamento de capacidade

Para se preparar para uma falha na zona de disponibilidade, considere o superprovisionamento da capacidade do seu 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 se tornar indisponível, seu ambiente, juntamente com seus planos e aplicativos, também se tornarão indisponíveis.

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, implante vários Ambientes do Serviço de Aplicativo em várias regiões. As etapas a seguir ajudam a fortalecer a resiliência:

• Implante seu aplicativo nos Ambientes do Serviço de Aplicativo 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.

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

Backup e restauração

Para fazer backup de seus aplicativos do Serviço de Aplicativo em um arquivo, use 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.

Personalize o ciclo de atualização. Você pode personalizar o ciclo de atualização de um Ambiente do Serviço de Aplicativo. Se você precisar validar o efeito das atualizações na sua carga de trabalho, habilite as atualizações manuais. Essa abordagem permite realizar validação e testes em uma instância fora de produção antes de aplicá-los à sua instância de produção.

Para mais informações sobre preferências de manutenção, consulte Preferências de atualização para manutenção planejada do Ambiente do Serviço de Aplicativo.

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 Serviço de Aplicativo