Implantação empresarial de alta disponibilidade que usa o Ambiente do Serviço de Aplicativo

Microsoft Entra ID

Gateway de Aplicativo do Azure

Firewall do Azure

Rede Virtual do Azure

Serviço de aplicativo do Azure

Observação

Ambiente do Serviço de Aplicativo versão 3 é o principal componente dessa arquitetura. As versões 1 e 2 foram desativadas em 31 de agosto de 2024.

As zonas de disponibilidade são coleções fisicamente separadas de datacenters em uma região específica. Você pode implantar recursos entre zonas para garantir que interrupções limitadas a uma zona não afetem a disponibilidade de seus aplicativos. Essa arquitetura descreve como melhorar a resiliência de uma implantação do Ambiente do Serviço de Aplicativo implantando-a em uma arquitetura com redundância de zona. Essas zonas não estão relacionadas à proximidade. Eles podem ser mapeadas para diferentes locais físicos para assinaturas diferentes. A arquitetura pressupõe apenas uma implantação de assinatura.

Os serviços do Azure que oferecem suporte a Zonas de Disponibilidade podem ser zonais, com redundância de zona ou ambos. Você pode implantar serviços zonais em uma zona específica e implantar automaticamente serviços com redundância de zona entre zonas. Para obter mais informações, consulte o suporte à zona de disponibilidade. O Ambiente do Serviço de Aplicativo dá suporte a implantações com redundância de zona.

Quando você configura um Ambiente do Serviço de Aplicativo para redundância de zona, a plataforma implanta automaticamente instâncias do plano do Serviço de Aplicativo do Azure no número máximo de zonas disponíveis na região selecionada. Pelo menos duas zonas devem estar disponíveis na região para habilitar a redundância de zona. Como resultado, a contagem mínima de instâncias do plano do Serviço de Aplicativo é sempre duas. A plataforma determina o número de zonas disponíveis para um Ambiente do Serviço de Aplicativo.

Architecture

O diagrama apresenta um layout estruturado de uma arquitetura de rede do Microsoft Azure, delimitada por uma borda azul pontilhada rotulada como rede virtual. Um ícone que representa a Internet reside fora da rede virtual. Ele se conecta ao Gateway de Aplicativo, que reside em sua própria sub-rede. Esse gateway aponta para a sub-rede central que contém um balanceador de carga interno do Ambiente do Serviço de Aplicativo com redundância de zona. Nessa sub-rede, três componentes empilhados são rotulados como aplicativo Web, API privada e função. O ambiente do aplicativo Web aponta para três sub-redes. Uma sub-rede contém Azure Redis Gerenciado. Outra sub-rede contém um firewall com uma seta que aponta para fora, rotulado como tráfego de saída. A terceira sub-rede apresenta vários pontos de extremidade privados conectados a ícones que representam Redis Gerenciados do Azure, Barramento de Serviço do Azure, Azure Cosmos DB, Banco de Dados SQL do Azure e Azure Key Vault, que residem fora da rede virtual. Zonas DNS (Sistema de Nomes de Domínio Privado) fora da sub-rede conectam-se aos pontos de extremidade privados. Uma VM (máquina virtual) de jump box reside em sua própria sub-rede, conectada por meio de linhas tracejadas à sub-rede central e a um ícone rotulado GitHub Actions, que está posicionado na parte inferior do diagrama fora da rede virtual. Na extrema direita, um ícone rotulado como ID do Microsoft Entra está sozinho.

Baixe um arquivo do Visio dessa arquitetura.

Há uma implantação de referência para essa arquitetura disponível no GitHub.

Os recursos nas sub-redes do Ambiente do Serviço de Aplicativo nesta implementação de referência correspondem aos recursos na arquitetura de implantação padrão do Ambiente do Serviço de Aplicativo. Essa implementação de referência usa as capacidades de redundância de zona do App Service Environment v3 e do Azure Managed Redis para fornecer maior disponibilidade. O escopo dessa arquitetura de referência é limitado a uma única região.

Components

• O Ambiente do Serviço de Aplicativo v3 é uma opção de hospedagem isolada e de alto desempenho que dá suporte à redundância de zona. Em regiões que dão suporte à redundância de zona, você pode configurar a redundância de zona a qualquer momento durante o ciclo de vida de um Ambiente do Serviço de Aplicativo. Cada plano do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo com redundância de zona deve incluir pelo menos duas instâncias para garantir a implantação em duas ou mais zonas. Você pode combinar planos com redundância de zona e não com redundância de zona no mesmo Ambiente do Serviço de Aplicativo. Para configurar um plano que tenha apenas uma instância, primeiro desabilite a redundância de zona para esse plano. A redundância de zona não incorre em encargos extras. Você paga apenas pelas instâncias isoladas v2 em uso. Para obter mais informações, consulte o preço e a confiabilidade do Ambiente do Serviço de Aplicativono Ambiente do Serviço de Aplicativo. Nessa arquitetura, o Ambiente do Serviço de Aplicativo v3 fornece uma plataforma de hospedagem isolada e de alto desempenho para aplicativos Web, APIs e funções.

• A Rede Virtual do Azure é uma rede baseada em IP de camada 3 que abrange todas as zonas de disponibilidade em uma única região. As sub-redes na rede virtual também se estendem entre zonas de disponibilidade. Para obter mais informações, consulte os requisitos de rede para o Ambiente e a Confiabilidade do Serviço de Aplicativo na Rede Virtual. Nessa arquitetura, a Rede Virtual fornece rede segura e isolada para todos os recursos.

• O Gateway de Aplicativo do Azure v2 é um balanceador de carga de tráfego web nativo para a nuvem que dá suporte à redundância de zona. Nessa arquitetura, ela abrange várias zonas de disponibilidade em cada região. Como resultado, um único gateway de aplicativo fornece alta disponibilidade, conforme mostrado na arquitetura de referência. A arquitetura de referência usa a SKU do Firewall do Aplicativo Web do Gateway de Aplicativo, que fornece maior proteção contra ameaças e vulnerabilidades comuns. Essa proteção se baseia em uma implementação do CRS (Conjunto de Regras Principais) do OWASP (Open Web Application Security Project). Para obter mais informações, consulte Confiabilidade no Gateway de Aplicativo v2. O Gateway de Aplicativo v2 serve como um balanceador de carga de tráfego da Web com redundância de zona.

• O Firewall do Azure é um serviço de segurança de rede gerenciado nativo de nuvem que inclui suporte interno para alta disponibilidade. Ele pode usar várias zonas sem configuração extra. Nessa arquitetura, o Firewall do Azure fornece segurança de rede gerenciada e de alta disponibilidade para controlar e monitorar o tráfego de saída para recursos na rede virtual.

  Você também pode configurar uma zona de disponibilidade específica ao implantar o firewall. Para obter mais informações, consulte o suporte à zona de disponibilidade do Firewall do Azure. A arquitetura de referência não usa essa configuração.

• A ID do Microsoft Entra é um serviço global altamente disponível e altamente redundante que abrange zonas e regiões de disponibilidade. Para obter mais informações, consulte Avançar na disponibilidade da ID do Microsoft Entra. Nessa arquitetura, a ID do Microsoft Entra fornece serviços de gerenciamento de identidade e acesso altamente disponíveis e redundantes para autenticação e autorização em todos os componentes.

• O GitHub Actions é uma plataforma de automação que dá suporte a recursos de CI/CD (integração contínua e implantação contínua). Nessa arquitetura, o GitHub Actions cria aplicativos fora da rede virtual e os implanta em planos do Serviço de Aplicativo hospedados em um Ambiente do Serviço de Aplicativo.

O Ambiente do Serviço de Aplicativo reside na rede virtual, portanto, uma VM (máquina virtual) serve uma caixa de salto na rede virtual para facilitar a implantação. Para segurança aprimorada e conectividade RDP (Protocolo de Área de Trabalho Remota) e SSH (Secure Shell), considere usar o Azure Bastion como jump box.

• O Redis Gerenciado do Azure é um serviço com redundância de zona. Um cache com redundância de zona é executado em VMs implantadas em várias Zonas de Disponibilidade. Nessa arquitetura, o Redis Gerenciado do Azure fornece maior resiliência e disponibilidade.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Caixas de salto

Essa implementação de referência usa o mesmo pipeline de CI/CD no nível de produção que a implantação padrão, com apenas uma VM de jumpbox. Mas você pode usar uma caixa de salto para cada uma das três zonas. Essa arquitetura usa apenas uma caixa de salto porque a caixa de salto não afeta a disponibilidade do aplicativo. O jump box dá suporte à implantação e teste.

Ambiente do Serviço de Aplicativo

Você pode implantar o Ambiente do Serviço de Aplicativo em zonas de disponibilidade para fornecer resiliência e confiabilidade para cargas de trabalho críticas para os negócios. Essa configuração também é conhecida como redundância de zona.

Quando você implementa a redundância de zona, a plataforma implanta automaticamente as instâncias do plano do Serviço de Aplicativo em duas ou mais zonas na região selecionada. Como resultado, a contagem mínima de instâncias do plano do Serviço de Aplicativo é sempre duas.

• Você pode configurar zonas de disponibilidade ao criar o Ambiente do Serviço de Aplicativo ou em qualquer ponto do ciclo de vida do ambiente.

• Todos os planos do Serviço de Aplicativo criados nesse Ambiente do Serviço de Aplicativo exigem um mínimo de duas instâncias para habilitar a redundância de zona. Se o ambiente for com redundância de zona, você poderá habilitar e desabilitar seletivamente a redundância de zona para os planos individuais do Serviço de Aplicativo. Para dimensionar em um plano do Serviço de Aplicativo para uma única instância, desabilite a redundância de zona para esse plano e, em seguida, prossiga com a operação de dimensionamento.

• Somente um subconjunto de regiões dá suporte a zonas de disponibilidade.

Para obter mais informações, consulte Confiabilidade no Serviço de Aplicativo.

Resiliency

Os aplicativos executados no Ambiente do Serviço de Aplicativo formam o pool de back-end do Gateway de Aplicativo. Quando uma solicitação para o aplicativo vem da Internet pública, o gateway encaminha a solicitação para o aplicativo executado no Ambiente do Serviço de Aplicativo. Essa arquitetura de referência implementa verificações de integridade no principal front-end web conhecido como votingApp. Essa investigação de integridade verifica o status de integridade da API Web e do cache Redis. O código em Startup.cs implementa essa investigação.

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Se algum componente, incluindo o front-end da Web, a API ou o cache, falhar na investigação de integridade, o Gateway de Aplicativo roteia a solicitação para o outro aplicativo no pool de back-end. Essa configuração garante que a solicitação sempre roteia para o aplicativo em uma sub-rede do Ambiente do Serviço de Aplicativo completamente disponível.

A implementação de referência padrão também usa a investigação de integridade. Nessa implementação, o gateway retornará um erro se a investigação de integridade falhar. Mas a implementação altamente disponível melhora a resiliência do aplicativo e a qualidade da experiência do usuário.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

As considerações de custo para a arquitetura de alta disponibilidade são semelhantes à implantação padrão.

As seguintes diferenças podem afetar o custo:

• O suporte à zona de disponibilidade não incorre em encargos extras. Você paga apenas pelas instâncias que usa. Para saber mais, veja Preços do Ambiente do Serviço de Aplicativo.

• O Redis Gerenciado do Azure tornar-se-á redundante por zona em regiões que tenham várias zonas de disponibilidade, quando a alta disponibilidade estiver habilitada. Um cache com redundância de zona opera em nós implantados em várias zonas de disponibilidade em uma região para fornecer maior resiliência e disponibilidade.

A compensação por um sistema altamente disponível, resiliente e altamente seguro inclui um custo maior para alguns serviços do Azure. Para avaliar seus requisitos e estimar custos, use a calculadora de preços do Azure.

Implantar este cenário

Para implantar a implementação de referência para essa arquitetura, consulte o leiame do GitHub. Use o script para a implantação de alta disponibilidade.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

• Deep Bhattacharya | Arquiteto de Soluções em Nuvem
• Suhas Rao | Arquiteto de Soluções em Nuvem

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas

Para modificar essa arquitetura, você pode dimensionar horizontalmente seus aplicativos na mesma região ou em várias regiões, com base na capacidade de carga de pico esperada. Replicar seus aplicativos em várias regiões pode ajudar a atenuar os riscos de falhas mais amplas do datacenter geográfico, como falhas causadas por terremotos ou outros desastres naturais.

• Para obter mais informações sobre o dimensionamento horizontal, consulte a escala distribuída geograficamente com o Ambiente do Serviço de Aplicativo.
• Para uma solução de roteamento global e altamente disponível, considere usar o Azure Front Door.

Observação

Ambiente do Serviço de Aplicativo versão 3 é o principal componente dessa arquitetura. As versões 1 e 2 foram desativadas em 31 de agosto de 2024.

As zonas de disponibilidade são coleções fisicamente separadas de datacenters em uma região específica. Você pode implantar recursos entre zonas para garantir que interrupções limitadas a uma zona não afetem a disponibilidade de seus aplicativos. Essa arquitetura descreve como melhorar a resiliência de uma implantação do Ambiente do Serviço de Aplicativo implantando-a em uma arquitetura com redundância de zona. Essas zonas não estão relacionadas à proximidade. Eles podem ser mapeadas para diferentes locais físicos para assinaturas diferentes. A arquitetura pressupõe apenas uma implantação de assinatura.

Os serviços do Azure que oferecem suporte a Zonas de Disponibilidade podem ser zonais, com redundância de zona ou ambos. Você pode implantar serviços zonais em uma zona específica e implantar automaticamente serviços com redundância de zona entre zonas. Para obter mais informações, consulte o suporte à zona de disponibilidade. O Ambiente do Serviço de Aplicativo dá suporte a implantações com redundância de zona.

Quando você configura um Ambiente do Serviço de Aplicativo para redundância de zona, a plataforma implanta automaticamente instâncias do plano do Serviço de Aplicativo do Azure no número máximo de zonas disponíveis na região selecionada. Pelo menos duas zonas devem estar disponíveis na região para habilitar a redundância de zona. Como resultado, a contagem mínima de instâncias do plano do Serviço de Aplicativo é sempre duas. A plataforma determina o número de zonas disponíveis para um Ambiente do Serviço de Aplicativo.

Architecture

O diagrama apresenta um layout estruturado de uma arquitetura de rede do Microsoft Azure, delimitada por uma borda azul pontilhada rotulada como rede virtual. Um ícone que representa a Internet reside fora da rede virtual. Ele se conecta ao Gateway de Aplicativo, que reside em sua própria sub-rede. Esse gateway aponta para a sub-rede central que contém um balanceador de carga interno do Ambiente do Serviço de Aplicativo com redundância de zona. Nessa sub-rede, três componentes empilhados são rotulados como aplicativo Web, API privada e função. O ambiente do aplicativo Web aponta para três sub-redes. Uma sub-rede contém Azure Redis Gerenciado. Outra sub-rede contém um firewall com uma seta que aponta para fora, rotulado como tráfego de saída. A terceira sub-rede apresenta vários pontos de extremidade privados conectados a ícones que representam Redis Gerenciados do Azure, Barramento de Serviço do Azure, Azure Cosmos DB, Banco de Dados SQL do Azure e Azure Key Vault, que residem fora da rede virtual. Zonas DNS (Sistema de Nomes de Domínio Privado) fora da sub-rede conectam-se aos pontos de extremidade privados. Uma VM (máquina virtual) de jump box reside em sua própria sub-rede, conectada por meio de linhas tracejadas à sub-rede central e a um ícone rotulado GitHub Actions, que está posicionado na parte inferior do diagrama fora da rede virtual. Na extrema direita, um ícone rotulado como ID do Microsoft Entra está sozinho.

Baixe um arquivo do Visio dessa arquitetura.

Há uma implantação de referência para essa arquitetura disponível no GitHub.

Os recursos nas sub-redes do Ambiente do Serviço de Aplicativo nesta implementação de referência correspondem aos recursos na arquitetura de implantação padrão do Ambiente do Serviço de Aplicativo. Essa implementação de referência usa as capacidades de redundância de zona do App Service Environment v3 e do Azure Managed Redis para fornecer maior disponibilidade. O escopo dessa arquitetura de referência é limitado a uma única região.

Components

• O Ambiente do Serviço de Aplicativo v3 é uma opção de hospedagem isolada e de alto desempenho que dá suporte à redundância de zona. Em regiões que dão suporte à redundância de zona, você pode configurar a redundância de zona a qualquer momento durante o ciclo de vida de um Ambiente do Serviço de Aplicativo. Cada plano do Serviço de Aplicativo em um Ambiente do Serviço de Aplicativo com redundância de zona deve incluir pelo menos duas instâncias para garantir a implantação em duas ou mais zonas. Você pode combinar planos com redundância de zona e não com redundância de zona no mesmo Ambiente do Serviço de Aplicativo. Para configurar um plano que tenha apenas uma instância, primeiro desabilite a redundância de zona para esse plano. A redundância de zona não incorre em encargos extras. Você paga apenas pelas instâncias isoladas v2 em uso. Para obter mais informações, consulte o preço e a confiabilidade do Ambiente do Serviço de Aplicativono Ambiente do Serviço de Aplicativo. Nessa arquitetura, o Ambiente do Serviço de Aplicativo v3 fornece uma plataforma de hospedagem isolada e de alto desempenho para aplicativos Web, APIs e funções.

• A Rede Virtual do Azure é uma rede baseada em IP de camada 3 que abrange todas as zonas de disponibilidade em uma única região. As sub-redes na rede virtual também se estendem entre zonas de disponibilidade. Para obter mais informações, consulte os requisitos de rede para o Ambiente e a Confiabilidade do Serviço de Aplicativo na Rede Virtual. Nessa arquitetura, a Rede Virtual fornece rede segura e isolada para todos os recursos.

• O Gateway de Aplicativo do Azure v2 é um balanceador de carga de tráfego web nativo para a nuvem que dá suporte à redundância de zona. Nessa arquitetura, ela abrange várias zonas de disponibilidade em cada região. Como resultado, um único gateway de aplicativo fornece alta disponibilidade, conforme mostrado na arquitetura de referência. A arquitetura de referência usa a SKU do Firewall do Aplicativo Web do Gateway de Aplicativo, que fornece maior proteção contra ameaças e vulnerabilidades comuns. Essa proteção se baseia em uma implementação do CRS (Conjunto de Regras Principais) do OWASP (Open Web Application Security Project). Para obter mais informações, consulte Confiabilidade no Gateway de Aplicativo v2. O Gateway de Aplicativo v2 serve como um balanceador de carga de tráfego da Web com redundância de zona.

• O Firewall do Azure é um serviço de segurança de rede gerenciado nativo de nuvem que inclui suporte interno para alta disponibilidade. Ele pode usar várias zonas sem configuração extra. Nessa arquitetura, o Firewall do Azure fornece segurança de rede gerenciada e de alta disponibilidade para controlar e monitorar o tráfego de saída para recursos na rede virtual.

  Você também pode configurar uma zona de disponibilidade específica ao implantar o firewall. Para obter mais informações, consulte o suporte à zona de disponibilidade do Firewall do Azure. A arquitetura de referência não usa essa configuração.

• A ID do Microsoft Entra é um serviço global altamente disponível e altamente redundante que abrange zonas e regiões de disponibilidade. Para obter mais informações, consulte Avançar na disponibilidade da ID do Microsoft Entra. Nessa arquitetura, a ID do Microsoft Entra fornece serviços de gerenciamento de identidade e acesso altamente disponíveis e redundantes para autenticação e autorização em todos os componentes.

• O GitHub Actions é uma plataforma de automação que dá suporte a recursos de CI/CD (integração contínua e implantação contínua). Nessa arquitetura, o GitHub Actions cria aplicativos fora da rede virtual e os implanta em planos do Serviço de Aplicativo hospedados em um Ambiente do Serviço de Aplicativo.

O Ambiente do Serviço de Aplicativo reside na rede virtual, portanto, uma VM (máquina virtual) serve uma caixa de salto na rede virtual para facilitar a implantação. Para segurança aprimorada e conectividade RDP (Protocolo de Área de Trabalho Remota) e SSH (Secure Shell), considere usar o Azure Bastion como jump box.

• O Redis Gerenciado do Azure é um serviço com redundância de zona. Um cache com redundância de zona é executado em VMs implantadas em várias Zonas de Disponibilidade. Nessa arquitetura, o Redis Gerenciado do Azure fornece maior resiliência e disponibilidade.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Caixas de salto

Essa implementação de referência usa o mesmo pipeline de CI/CD no nível de produção que a implantação padrão, com apenas uma VM de jumpbox. Mas você pode usar uma caixa de salto para cada uma das três zonas. Essa arquitetura usa apenas uma caixa de salto porque a caixa de salto não afeta a disponibilidade do aplicativo. O jump box dá suporte à implantação e teste.

Ambiente do Serviço de Aplicativo

Você pode implantar o Ambiente do Serviço de Aplicativo em zonas de disponibilidade para fornecer resiliência e confiabilidade para cargas de trabalho críticas para os negócios. Essa configuração também é conhecida como redundância de zona.

Quando você implementa a redundância de zona, a plataforma implanta automaticamente as instâncias do plano do Serviço de Aplicativo em duas ou mais zonas na região selecionada. Como resultado, a contagem mínima de instâncias do plano do Serviço de Aplicativo é sempre duas.

• Você pode configurar zonas de disponibilidade ao criar o Ambiente do Serviço de Aplicativo ou em qualquer ponto do ciclo de vida do ambiente.

• Todos os planos do Serviço de Aplicativo criados nesse Ambiente do Serviço de Aplicativo exigem um mínimo de duas instâncias para habilitar a redundância de zona. Se o ambiente for com redundância de zona, você poderá habilitar e desabilitar seletivamente a redundância de zona para os planos individuais do Serviço de Aplicativo. Para dimensionar em um plano do Serviço de Aplicativo para uma única instância, desabilite a redundância de zona para esse plano e, em seguida, prossiga com a operação de dimensionamento.

• Somente um subconjunto de regiões dá suporte a zonas de disponibilidade.

Para obter mais informações, consulte Confiabilidade no Serviço de Aplicativo.

Resiliency

Os aplicativos executados no Ambiente do Serviço de Aplicativo formam o pool de back-end do Gateway de Aplicativo. Quando uma solicitação para o aplicativo vem da Internet pública, o gateway encaminha a solicitação para o aplicativo executado no Ambiente do Serviço de Aplicativo. Essa arquitetura de referência implementa verificações de integridade no principal front-end web conhecido como votingApp. Essa investigação de integridade verifica o status de integridade da API Web e do cache Redis. O código em Startup.cs implementa essa investigação.

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Se algum componente, incluindo o front-end da Web, a API ou o cache, falhar na investigação de integridade, o Gateway de Aplicativo roteia a solicitação para o outro aplicativo no pool de back-end. Essa configuração garante que a solicitação sempre roteia para o aplicativo em uma sub-rede do Ambiente do Serviço de Aplicativo completamente disponível.

A implementação de referência padrão também usa a investigação de integridade. Nessa implementação, o gateway retornará um erro se a investigação de integridade falhar. Mas a implementação altamente disponível melhora a resiliência do aplicativo e a qualidade da experiência do usuário.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

As considerações de custo para a arquitetura de alta disponibilidade são semelhantes à implantação padrão.

As seguintes diferenças podem afetar o custo:

• O suporte à zona de disponibilidade não incorre em encargos extras. Você paga apenas pelas instâncias que usa. Para saber mais, veja Preços do Ambiente do Serviço de Aplicativo.

• O Redis Gerenciado do Azure tornar-se-á redundante por zona em regiões que tenham várias zonas de disponibilidade, quando a alta disponibilidade estiver habilitada. Um cache com redundância de zona opera em nós implantados em várias zonas de disponibilidade em uma região para fornecer maior resiliência e disponibilidade.

A compensação por um sistema altamente disponível, resiliente e altamente seguro inclui um custo maior para alguns serviços do Azure. Para avaliar seus requisitos e estimar custos, use a calculadora de preços do Azure.

Implantar este cenário

Para implantar a implementação de referência para essa arquitetura, consulte o leiame do GitHub. Use o script para a implantação de alta disponibilidade.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

• Deep Bhattacharya | Arquiteto de Soluções em Nuvem
• Suhas Rao | Arquiteto de Soluções em Nuvem

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas

Para modificar essa arquitetura, você pode dimensionar horizontalmente seus aplicativos na mesma região ou em várias regiões, com base na capacidade de carga de pico esperada. Replicar seus aplicativos em várias regiões pode ajudar a atenuar os riscos de falhas mais amplas do datacenter geográfico, como falhas causadas por terremotos ou outros desastres naturais.

• Para obter mais informações sobre o dimensionamento horizontal, consulte a escala distribuída geograficamente com o Ambiente do Serviço de Aplicativo.
• Para uma solução de roteamento global e altamente disponível, considere usar o Azure Front Door.