Partilhar via

Fiabilidade no Serviço de Aplicações 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 oferecer 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 na zona de disponibilidade, interrupções de região e manutenção de serviços. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e destaca algumas informações importantes sobre o contrato de nível de serviço (SLA) do Serviço de Aplicativo.

Observação

Se você estiver procurando informações sobre suporte à confiabilidade no Ambiente do Serviço de Aplicativo, consulte Confiabilidade no Ambiente do 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 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, você especifica 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 dimensionar um plano para ser executado em várias instâncias de VM, também chamadas de trabalhadores. Essas instâncias fornecem os recursos de computação que executam o código do aplicativo. Um único plano do Serviço de Aplicativo pode hospedar vários aplicativos. Todos os aplicativos são executados no mesmo conjunto compartilhado de instâncias de VM.

O Serviço de Aplicativo 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 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 alimentação comum e um switch de rede.

  • Distribuição entre zonas de disponibilidade: Se você habilitar a redundância de zona em um plano de Serviço de Aplicativo com suporte, o Azure distribuirá suas instâncias entre as zonas de disponibilidade dentro da região. Essa configuração fornece maior resiliência se ocorrer uma interrupção de zona. Para obter mais informações sobre redundância de zona, consulte Suporte à zona de disponibilidade.

  • Dimensionamento de aplicativos: Quando você configura seu plano do Serviço de Aplicativo para executar várias instâncias de VM, todos os aplicativos do 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 dimensionados 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 Serviço de Aplicativo, incluindo computação, armazenamento, rede e balanceamento de carga. O Azure gerencia unidades de escala para garantir uma distribuição equilibrada da carga de trabalho, executar manutenção de rotina e manter a confiabilidade geral da plataforma.

    Alguns recursos podem ser aplicados apenas a unidades de escala específicas. Por exemplo, algumas unidades de escala do Serviço de Aplicativo podem oferecer suporte à redundância de zona, 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 em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

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

SDKs fornecidos pela Microsoft geralmente lidam com falhas transitórias. Como você hospeda seus próprios aplicativos no Serviço de Aplicativo, 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 do seu plano. Se uma entidade estiver com problemas, o serviço irá substituí-la automaticamente por uma nova entidade funcional. 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 atenuar esses efeitos, implante várias instâncias do seu plano do Serviço de Aplicativo.

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

  • Evite aumentar ou diminuir a escala. Essas operações alteram a CPU, a memória e outros recursos atribuídos a cada instância e podem disparar uma 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 expandir e dimensionar, adicione e remova instâncias dinamicamente para lidar com alterações no volume de tráfego.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Para as camadas Premium v2 a v4, você pode configurar o Serviço de Aplicativo como zona redundante, o que significa que seus recursos são distribuídos em 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. Quando você configura a redundância de zona nos planos do Serviço de Aplicativo, todos os aplicativos que usam o plano se tornam redundantes de zona.

Requisitos

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

Distribuição de instâncias entre zonas

Quando você cria um plano do Serviço de Aplicativo com redundância de 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 se uma zona sofrer uma interrupção.

A distribuição de instâncias numa implantação com redundância de zona segue regras específicas. Estas regras também se aplicam à medida que a aplicação entra e sai:

  • 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 suportadas pelo seu plano: O Azure determina o número de zonas de disponibilidade que seu plano pode usar, que é conhecido como maximumNumberOfZones. Para exibir o número de zonas de disponibilidade que seu plano específico pode usar, consulte Verificar o suporte de redundância de zona para um plano do Serviço de Aplicativo.

  • Distribuição da instância: Quando a redundância de zona está habilitada, o Azure distribui instâncias de plano em várias zonas de disponibilidade automaticamente. A distribuição baseia-se nas seguintes regras:

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

    • Se o número de instâncias não for dividido uniformemente, o Azure distribuirá as instâncias restantes 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 balanceamento de zona de melhor esforço que os conjuntos de escala de máquina virtual subjacente do Azure fornecem. Um plano será balanceado se cada zona tiver o mesmo número de VMs ou diferir por uma instância de todas as outras zonas. Para obter mais informações, consulte Balanceamento de zona.

  • Colocação da 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, consulte Exibir zonas físicas para um plano do Serviço de Aplicativo.

Considerações

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

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

Para planos do Serviço de Aplicativo que não são configurados como redundantes de zona, as instâncias de máquina virtual (VM) subjacentes não são resilientes a falhas de zona de disponibilidade. Eles podem experienciar um período de inatividade durante uma falha em qualquer zona dessa região.

Custo

Quando você usa os planos do App Service Premium v2 a v4, habilitar zonas de disponibilidade não aumenta o custo se você tiver duas ou mais instâncias. As cobranças são baseadas na SKU do plano do Serviço de Aplicativo, na capacidade especificada e em todas as 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 instâncias de duas. A plataforma cobra por essas duas instâncias.

Configurar o suporte à zona de disponibilidade

Planejamento e gerenciamento de capacidade

Para se preparar para falhas na zona de disponibilidade, considere sobreprovisionar a capacidade do seu plano do Serviço de Aplicativo. Esta abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem um desempenho degradado. Para obter mais informações, consulte Gerenciar a capacidade usando o provisionamento excessivo.

Comportamento quando todas as zonas estão íntegras

A lista a seguir descreve o que esperar quando os planos do Serviço de Aplicativo são configurados para redundância de 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 Serviço de Aplicativo em todas as zonas de disponibilidade.

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

Comportamento durante uma falha de zona

Uma interrupção da zona de disponibilidade pode afetar alguns aspetos do Serviço de Aplicativo, mesmo que o aplicativo continue a servir tráfego. Esses comportamentos incluem o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação do aplicativo.

A lista a seguir descreve o que esperar quando os planos do Serviço de Aplicativo são configurados para redundância de zona e uma ou mais zonas de disponibilidade não estão disponíveis:

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

  • Solicitações ativas: Todas as solicitações em andamento que se conectam a uma instância do plano do Serviço de Aplicativo na zona de disponibilidade defeituosa são encerradas. Repita essas solicitações.

  • Reencaminhamento do tráfego: O Serviço de Aplicativo deteta as instâncias perdidas dessa zona e tenta encontrar novas instâncias de substituição. Depois que o Serviço de Aplicativo encontra substitutos, ele distribui o tráfego entre as novas instâncias conforme necessário.

    Se o dimensionamento automático estiver configurado e determinar que mais instâncias são necessárias, ele solicitará instâncias do Serviço de Aplicativo. O comportamento de dimensionamento automático opera independentemente 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, consulte Dimensionar um aplicativo no Serviço de Aplicativo e Visão geral do dimensionamento automático.

    Importante

    O Azure não garante que as solicitações para mais instâncias sejam bem-sucedidas em um cenário de zone-down. A plataforma tenta preencher instâncias perdidas com base no melhor esforço. Se você precisar de capacidade garantida durante uma falha de zona de disponibilidade, crie e configure seus planos do Serviço de Aplicativo para contabilizar a perda de zona ao provisionar excessivamente a capacidade.

  • Comportamentos sem tempo de execução: Os aplicativos em um plano do Serviço de Aplicativo com redundância de zona continuam a ser executados e a servir o tráfego mesmo que uma zona de disponibilidade sofra uma interrupção. No entanto, comportamentos não de execução podem ser afetados durante uma interrupção numa zona de disponibilidade. Esses comportamentos incluem o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração do aplicativo e a publicação do 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.

Teste de falhas de zona

A plataforma do Serviço de Aplicativo gerencia o roteamento de tráfego, failover e failback para planos do Serviço de Aplicativo com redundância de zona. Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na 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, 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 uma única região afetar seu aplicativo, você pode implantar planos em várias regiões. As seguintes medidas ajudam a reforçar a resiliência:

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

Considere os seguintes recursos relacionados:

Backup e restauração

Ao usar a camada Básica ou superior, você pode fazer backup de 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 o estado no disco. A maioria das soluções não deve depender exclusivamente de backups. Em vez disso, use os outros recursos deste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não oferecem.

Importante

A partir de 31 de março de 2028, os backups personalizados do Serviço de Aplicativo do Azure não darão mais suporte ao backup de bancos de dados vinculados. Consulte Descontinuação de backups de banco de dados vinculados para obter mais informações.

Em vez disso, use as ferramentas nativas de backup e restauração do banco de dados vinculado. Para obter mais informações, consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo.

Resiliência à manutenção de serviços

O Serviço de Aplicativo executa atualizações regulares de serviço e outras tarefas de manutenção. Para manter a 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.

Habilite a redundância de zona. 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. Os domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e são mapeadas para zonas de disponibilidade. Implantar várias instâncias em seu plano do Serviço de Aplicativo e habilitar a redundância de zona para seu plano adiciona uma camada extra de resiliência se uma instância ou zona não estiver íntegra durante uma atualização.

Para obter mais informações, consulte 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 contrato de nível de serviço (SLA) para serviços do 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 Acordos de Nível de Serviço (SLAs) para serviços online.

Quando se implementa um plano de Serviço de Aplicações com redundância de zona, a percentagem de tempo de atividade definida no SLA aumenta.

Conteúdos relacionados

  • Last updated on