Confiabilidade no Ambiente do Serviço de Aplicativo do Azure

Ambiente do Serviço de Aplicativo é um recurso 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 de Azure, Ambiente do Serviço de Aplicativo fornece uma variedade de recursos para dar suporte aos seus requisitos de confiabilidade.

Quando você utiliza o Azure, confiabilidade é uma responsabilidade compartilhada. 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 em Ambiente do Serviço de Aplicativo, incluindo resiliência a falhas transitórias, falhas de 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) 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

Ao implementar um Ambiente do Serviço de Aplicativo, você implanta o ambiente como o contêiner para seus planos do Serviço de Aplicativo 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 Ambiente do Serviço de Aplicativo, seus planos devem usar a camada de preço Isolada v2. 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 plano de Serviço de Aplicativo entre domínios de falha na 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ê habilitar a redundância de zona em um plano do Serviço de Aplicativo com suporte, o Azure distribui suas instâncias pelas zonas de disponibilidade na 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. 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 Azure quando se comunicam com 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 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 Availability são grupos fisicamente separados de datacenters em uma região Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Você pode configurar seu Ambiente do Serviço de Aplicativo como zone redundante. Em seguida, você pode configurar os planos do Serviço de Aplicativo no ambiente para serem redundantes por zona, o que distribui as instâncias desse plano em várias zonas de disponibilidade. Você pode optar por habilitar ou desabilitar a redundância de zona em cada plano, o que significa que você pode ter alguns planos em seu ambiente com redundância de zona e outros que não são.

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.

Se o seu Ambiente do Serviço de Aplicativo e os planos não estiverem configurados como redundantes de zona, eles serão considerados nonzonal e as instâncias subjacentes de VM (máquina virtual) não serão resilientes a falhas em zonas de disponibilidade. Eles podem experimentar tempo de inatividade durante uma interrupção em qualquer zona nessa região.

Requirements

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

• Suporte de regiões: Para ver quais regiões suportam 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 no seu plano para que o plano seja redundante em zonas.

  Planos não zonais podem ser implantados em seu ambiente com uma única instância.

• 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 dá suporte à redundância de zona, Marque 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 seu 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 Serviço de Aplicativo com redundância de zona, Azure distribui as instâncias do plano entre 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.

• Máximo de zonas de disponibilidade suportadas pelo seu plano: O Azure determina o número de zonas de disponibilidade que seu plano pode usar, o que é referido como 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.

  Observação

  O número de zonas de disponibilidade disponíveis para seu plano (maximumNumberOfZones) varia de acordo com a unidade de escala e a região. Uma implantação com redundância de zona sempre usa pelo menos duas zonas de disponibilidade e pode usar mais dependendo da unidade de escala. Independentemente do número de zonas, uma implantação com redundância de zona fornece resiliência a uma única falha de zona e oferece o mesmo SLA.

• Instance distribution: Quando a redundância de zona está habilitada, Azure distribui automaticamente instâncias de plano entre várias zonas de disponibilidade. A distribuição é baseada nas seguintes regras:

  • Se o número de instâncias exceder maximumNumberOfZones e se dividir uniformemente, Azure distribuirá as instâncias uniformemente entre zonas.

  • Se o número de instâncias não for dividido uniformemente, Azure distribuirá 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 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

• Comportamentos sem execução: Uma interrupção da zona de disponibilidade pode afetar alguns aspectos do Serviço de Aplicativo, embora 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.

• Atualizações da plataforma: Ao habilitar a redundância de zona em seu plano do Serviço de Aplicativo, 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.

Custo

Você pode ativar a redundância de zona em um Ambiente do Serviço de Aplicativo ou seus planos sem custos adicionais. 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 saber como criar, habilitar ou desabilitar um novo Ambiente do Serviço de Aplicativo com redundância de zona e novos planos do Serviço de Aplicativo com redundância de zona, consulte Configurar ambientes do Serviço de Aplicativo e planos isolados do Serviço de Aplicativo v2 para redundância de 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.

• Notification: Microsoft não notifica automaticamente quando uma zona está inoperante. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre 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

  Azure não garante que as solicitações para mais instâncias tenham êxito em um cenário de zona para baixo. 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 corporativa de alta disponibilidade usando 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 para 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 obter 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 SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs dos 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. O mesmo SLA se aplica independentemente do número de zonas disponíveis na unidade de escala subjacente.

Conteúdo relacionado

• Relibilidade em Azure
• Confiabilidade no Serviço de Aplicativo