Compartilhar via

Aplicativo Web com redundância de zona altamente disponível na linha de base

Serviço de aplicativo do Azure
Gateway de Aplicativo do Azure
Armazenamento do Azure
Banco de Dados SQL do Azure
Link Privado do Azure
Rede Virtual do Azure
Azure Monitor

Essa arquitetura de linha de base baseia-se na arquitetura básica do aplicativo Web e fornece diretrizes detalhadas para criar um aplicativo Web seguro, com redundância de zona e altamente disponível no Azure. Nessa arquitetura, o Gateway de Aplicativos do Azure, juntamente com o Firewall de Aplicativos Web do Azure, expõe um ponto de extremidade público e roteia solicitações para o Serviço de Aplicativos do Azure por meio do Link Privado do Azure. O aplicativo do Serviço de Aplicativo usa a integração de rede virtual e o Link Privado para se comunicar com segurança com soluções de PaaS (plataforma como serviço) do Azure, como o Azure Key Vault e o Banco de Dados SQL do Azure.

Importante

Uma implementação de exemplo demonstra essa implementação do Serviço de Aplicativo de linha de base no Azure. Use-o como base para sua solução de produção.

Arquitetura

Diagrama que mostra uma arquitetura de linha de base do Serviço de Aplicativo com redundância zonal e alta disponibilidade.

Baixe um Arquivo Visio dessa arquitetura.

Componentes

Essa arquitetura compartilha muitos componentes com a arquitetura básica do aplicativo Web. A lista a seguir descreve apenas os componentes que diferem ou estendem a arquitetura básica:

  • O Gateway de Aplicativo é um balanceador de carga HTTP e HTTPS de camada 7 e gerenciador de tráfego da Web. Nessa arquitetura, o Gateway de Aplicativo atua como um único ponto de entrada público. O Application Gateway encerra o TLS (Transport Layer Security) e avalia as regras do Firewall do Aplicativo Web do Azure. Em seguida, ele encaminha solicitações aprovadas privadamente para instâncias do Serviço de Aplicativo em zonas de disponibilidade.

  • O Firewall do Aplicativo Web do Azure é um serviço nativo de nuvem que protege aplicativos Web contra explorações comuns, como injeção de SQL e XSS (script entre sites). Nessa arquitetura, o Firewall de Aplicativo Web do Azure é executado no Gateway de Aplicativo e bloqueia solicitações mal-intencionadas antes de chegarem ao Serviço de Aplicativo. Essa configuração melhora a segurança e ajuda a manter a disponibilidade.

  • O Key Vault é um serviço que armazena e gerencia com segurança segredos, chaves de criptografia e certificados. Nessa arquitetura, ele armazena o certificado TLS (X.509) que o Gateway de Aplicativo usa e contém segredos de aplicativo que o Serviço de Aplicativo acessa privadamente.

  • A Rede Virtual do Azure é um serviço que fornece redes virtuais privadas isoladas e seguras no Azure. Nessa arquitetura, a rede virtual fornece pontos de extremidade privados, integração do Serviço de Aplicativo e sub-redes dedicadas para o Gateway de Aplicativo. Essa configuração isola o tráfego e permite que o Serviço de Aplicativo se comunique com segurança com os serviços dependentes do Azure por meio de pontos de extremidade privados.

  • O Link Privado é um serviço de rede que fornece acesso privado aos serviços do Azure pela rede de backbone da Microsoft para eliminar a exposição à Internet pública. Nessa arquitetura, o Link Privado permite conexões de entrada privadas com o Serviço de Aplicativo e conexões de saída privadas do Serviço de Aplicativo para serviços como Key Vault, Banco de Dados SQL e Armazenamento do Azure.

  • O DNS do Azure é um serviço de hospedagem para domínios do DNS (Sistema de Nomes de Domínio). Ele fornece resolução de nomes usando a infraestrutura do Microsoft Azure. As zonas DNS privadas mapeiam o nome de domínio totalmente qualificado (FQDN) de um serviço para o endereço IP de um endpoint privado. Nessa arquitetura, as zonas DNS privadas mapeiam o domínio padrão do Serviço de Aplicativo e outros domínios de serviço de PaaS para seus endereços de ponto de extremidade privados para que todo o tráfego permaneça na rede privada.

Rede

A segurança de rede é central para a arquitetura de linha de base do Serviço de Aplicativo. Em um alto nível, a arquitetura de rede fornece os seguintes recursos:

  • Um único ponto de entrada seguro para o tráfego de cliente.

  • Filtragem de tráfego por meio do Firewall do Aplicativo Web do Azure

  • Criptografia TLS de ponta a ponta para dados em trânsito

  • Exfiltração de dados minimizada por meio do Link Privado, que mantém o tráfego dentro do Azure

  • Agrupamento lógico e isolamento de recursos de rede por meio da segmentação de rede

Fluxos de rede

Diagrama que mostra os fluxos de rede em uma arquitetura de rede do Serviço de Aplicativo de linha de base.

Fluxo de Entrada

As etapas a seguir descrevem o fluxo de entrada da Internet para a instância do Serviço de Aplicativo:

  1. O usuário emite uma solicitação para o endereço IP público do Gateway de Aplicativo.

  2. O Gateway de Aplicações avalia as regras do Firewall de Aplicações Web, que protegem contra ataques como XSS e injeção de SQL. Se uma regra detectar uma violação, o Gateway de Aplicativo retornará um erro ao solicitante e interromperá o processamento. Senão, o Application Gateway roteia a solicitação para o pool de back-end, que nesse caso é o domínio padrão do App Service.

  3. A zona privatelink.azurewebsites.net DNS privada é vinculada à rede virtual. A zona DNS contém um registro A que mapeia o domínio padrão do Serviço de Aplicativo para o endereço IP privado do ponto de extremidade privado do Serviço de Aplicativo. O DNS do Azure usa esse registro para resolver o domínio padrão para o endereço IP do ponto de extremidade privado.

  4. O Gateway de Aplicativo roteia a solicitação para uma instância do Serviço de Aplicativo por meio do ponto de extremidade privado.

Fluxo de saída

As etapas a seguir descrevem o fluxo de saída do Serviço de Aplicativo para os serviços de PaaS do Azure:

  1. O Serviço de Aplicativo envia uma solicitação para o nome DNS do serviço do Azure necessário, como Key Vault, Armazenamento, Banco de Dados SQL ou qualquer outro serviço do Azure que dê suporte ao Link Privado. O recurso de integração de rede virtual do Serviço de Aplicativo roteia a solicitação pela rede virtual.

  2. Semelhante à etapa 3 no fluxo de entrada, a zona DNS privada vinculada contém um registro A que mapeia o domínio do serviço do Azure para seu endereço IP de ponto de extremidade privado. O DNS do Azure usa esse registro para resolver o domínio para o endereço IP do ponto de extremidade privado do serviço.

  3. A rede virtual roteia a solicitação para o serviço por meio do ponto de extremidade privado.

O tráfego de saída que não vai para os serviços de PaaS do Azure sai por meio de um endereço IP público que vários clientes compartilham. Por exemplo, um aplicativo Web pode chamar uma API pública durante uma solicitação HTTP. Para controlar esse tipo de tráfego de saída, encaminhe-o por meio de um dispositivo de rede como o Firewall do Azure. Para obter mais informações, consulte Controlar o tráfego de saída usando o Firewall do Azure.

Implementação do Gateway de Aplicações

O Gateway de Aplicativo é um balanceador de carga escalonável, regional e de camada 7 que dá suporte ao Firewall de Aplicativo Web do Azure e ao descarregamento de TLS. Ao implementar o Application Gateway para o tráfego de entrada no App Service, considere os seguintes pontos:

Fluxo de App Service para os serviços do Azure

Essa arquitetura usa a integração de rede virtual para rotear o tráfego do Serviço de Aplicativo para pontos de extremidade privados por meio da rede virtual. A arquitetura de linha de base não habilita todo o roteamento de tráfego, o que forçaria todo o tráfego de saída por meio da rede virtual. Em vez disso, ele roteia apenas o tráfego interno destinado a pontos de extremidade privados.

Para serviços do Azure que não exigem acesso público à Internet, permita pontos de extremidade privados e bloqueie pontos de extremidade públicos. Os pontos de extremidade privados melhoram a segurança permitindo que o Serviço de Aplicativo se conecte aos serviços de Link Privado diretamente da rede virtual privada sem endereçamento IP público.

Nesta arquitetura, o Banco de Dados SQL, o Armazenamento e o Key Vault têm pontos de extremidade públicos bloqueados. Seus firewalls de serviço permitem o tráfego somente de outros serviços autorizados do Azure. Configure outros serviços do Azure, como o Azure Cosmos DB e o Azure Managed Redis, com pontos de extremidade privados. Nessa arquitetura, o Azure Monitor não usa um ponto de extremidade privado, mas você pode implementar um usando um Escopo de Link Privado do Azure Monitor (AMPLS).

A arquitetura de linha de base implementa uma zona DNS privada para cada serviço. Cada zona DNS privada contém um registro A que mapeia o FQDN do serviço para o endereço IP do ponto de extremidade privado. As zonas se conectam à rede virtual. Grupos de zonas privadas de DNS criam e atualizam automaticamente registros DNS para pontos de extremidade privados.

Considere os seguintes pontos ao implementar a integração de rede virtual e pontos de extremidade privados:

Segmentação e segurança de redes virtuais

A rede nessa arquitetura tem sub-redes separadas para Gateway de Aplicativo, componentes de integração do Serviço de Aplicativo e pontos de extremidade privados. Um NSG (grupo de segurança de rede) em cada sub-rede permite apenas o tráfego de entrada e saída necessário. A tabela a seguir descreve uma seleção de regras NSG que você pode adicionar a cada sub-rede.

Sub-rede Entrada Saída
GatewaySubnet AppGw.In.Allow.ControlPlane: permitir o acesso do plano de controle de entrada.

AppGw.In.Allow443.Internet: Permitir acesso HTTPS de entrada à Internet.		 AppGw.Out.Allow.PrivateEndpoints: permitir acesso de saída a PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: permitir o acesso de saída ao Azure Monitor.
PrivateEndpointsSubnet Regras padrão: permitir acesso interno na rede virtual. Regras padrão: permitir o acesso de saída à rede virtual.
AppServiceSubnet Regras padrão: Permitir o acesso de entrada da rede virtual. AppPlan.Out.Allow.PrivateEndpoints: permitir o acesso de saída a PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: permitir o acesso de saída ao Azure Monitor.

Considere os seguintes pontos ao implementar a segmentação e a segurança da rede virtual:

  • Habilite a proteção contra DDoS para a rede virtual que contém uma sub-rede de gateway de aplicativo com um endereço IP público.

  • Adicione um NSG a cada sub-rede sempre que possível. Use as regras mais rigorosas que permitem a funcionalidade completa da solução.

  • Use grupos de segurança de aplicativos para agrupar recursos logicamente, o que simplifica a criação de regras NSG em ambientes complexos.

A tabela a seguir mostra um esquema de rede de exemplo.

Tipo Nome Intervalo de endereços
Rede virtual Prefixo de endereço 10.0.0.0/16
Sub-rede GatewaySubnet 10.0.1.0/24
Sub-rede AppServiceSubnet 10.0.0.0/24
Sub-rede PrivateEndpointsSubnet 10.0.2.0/27
Sub-rede AgentsSubnet 10.0.2.32/27

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.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos assumidos com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade confiabilidade.

A arquitetura do Serviço de Aplicativo de linha de base se concentra na redundância zonal para os principais serviços regionais. As zonas de disponibilidade são locais fisicamente separados em uma região que fornecem alta disponibilidade e tolerância a falhas. Quando você implanta duas ou mais instâncias entre zonas de disponibilidade em regiões com suporte, a falha de uma zona não afeta as outras. Essa abordagem ajuda a manter a disponibilidade do serviço.

A arquitetura também garante instâncias suficientes dos serviços do Azure para atender à demanda. As seções a seguir fornecem diretrizes de confiabilidade para cada serviço de chave na arquitetura.

Application Gateway

Implante o Gateway de Aplicativo em uma configuração com redundância de zona com uma contagem mínima de instâncias de escala de três ou mais. Várias instâncias garantem que o serviço permaneça disponível durante falhas sem aguardar o tempo de inicialização de seis a sete minutos necessário para configurar uma nova instância.

Serviço de Aplicativo

  • Implante no mínimo duas instâncias do Serviço de Aplicativo que dão suporte a zonas de disponibilidade. Para maior resiliência, implante pelo menos uma instância para cada zona de disponibilidade em sua região, além de instâncias extras em cada zona para redundância.

  • Implemente pontos de extremidade de verificação de integridade em seus aplicativos e configure o recurso de verificação de integridade do Serviço de Aplicativo para redirecionar solicitações para fora de instâncias não íntegras. Para obter mais informações, consulte Monitorar instâncias do Serviço de Aplicativo usando verificações de integridade e verificações de integridade no ASP.NET Core.

  • Capacidade de superprovisionamento para lidar com falhas em zonas.

Armazenamento de Blobs

  • Utilize armazenamento com redundância de zona (ZRS), que replica dados de forma síncrona em três zonas de disponibilidade na região. Crie contas de armazenamento padrão ZRS (armazenamento com redundância de zona) ou armazenamento padrão GZRS (armazenamento com redundância de zona geográfica) para garantir a replicação de dados entre zonas de disponibilidade.

  • Crie contas de armazenamento separadas para implantações, ativos Web e outros dados para gerenciar e configurar cada conta de forma independente.

Banco de Dados SQL

  • Implante o Banco de Dados SQL na camada Uso Geral, Premium ou Comercialmente Crítico com redundância de zona ativada. Essas camadas dão suporte à redundância de zona.

  • Configurar backups de Banco de Dados SQL para usar ZRS ou GZRS.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança.

A arquitetura do Serviço de Aplicativo de linha de base se concentra nas recomendações de segurança essenciais para seu aplicativo Web. Você deve entender como a criptografia e a identidade funcionam em cada camada para ajudar a proteger sua carga de trabalho.

Serviço de Aplicativo

  • Desative os métodos de autenticação local para implementações de sites com FTP (Protocolo de Transferência de Arquivo) e SCM (Gerenciamento de Controle do Código-Fonte).

  • Desativar a depuração remota.

  • Use a versão mais recente do TLS compatível com todos os clientes.

  • Ative o plano do Microsoft Defender para Serviço de Aplicativo.

  • Use as versões mais recentes das plataformas com suporte, linguagens de programação, protocolos e estruturas.

  • Considere o Ambiente do Serviço de Aplicativo se você precisar de maior isolamento ou acesso seguro à rede.

Criptografia

Os aplicativos Web de produção devem criptografar dados em trânsito usando HTTPS. O HTTPS depende do TLS e usa chaves públicas e privadas para criptografia. Armazene o certificado TLS (X.509) no Key Vault e conceda permissão ao Gateway de Aplicativo para recuperar a chave privada. Para dados inativos, alguns serviços criptografam dados automaticamente e outros permitem personalizar as configurações.

Dados em trânsito

A arquitetura de linha de base criptografa os dados em trânsito do usuário para o aplicativo web no App Service.

Diagrama que mostra um fluxo de criptografia do Serviço de Aplicativo de linha de base.

O fluxo de trabalho a seguir descreve como a criptografia funciona em um alto nível:

  1. O usuário envia uma solicitação HTTPS para o aplicativo web.

  2. A solicitação HTTPS atinge o gateway de aplicativo.

  3. O gateway de aplicativo usa um certificado (X.509) no Cofre de Chaves para criar uma conexão TLS segura com o navegador da Web do usuário. O gateway de aplicativo descriptografa a solicitação HTTPS para que o firewall do aplicativo Web possa inspecioná-la.

  4. O gateway de aplicativo cria uma conexão TLS com o Serviço de Aplicativo para criptografar novamente a solicitação do usuário. O Serviço de Aplicativo fornece suporte nativo para HTTPS, portanto, você não precisa adicionar um certificado ao Serviço de Aplicativo. O gateway de aplicativo envia o tráfego criptografado para o Serviço de Aplicativo. O Serviço de Aplicativo descriptografa o tráfego e o aplicativo Web processa a solicitação.

Considere as seguintes recomendações ao configurar a criptografia de dados em trânsito:

  • Crie ou carregue seu certificado no cofre de chaves. A criptografia HTTPS requer um certificado (X.509). Você precisa de um certificado de uma autoridade de certificação confiável para seu domínio personalizado.

  • Armazene a chave privada para o certificado no Cofre da Chave.

  • Forneça acesso do Gateway de Aplicativo à chave privada do certificado. Para obter mais informações, consulte Conceder permissão usando o RBAC (controle de acesso baseado em função) do Azure e identidades gerenciadas para recursos do Azure. Não use políticas de acesso ao Cofre de Chaves para fornecer acesso. As políticas de acesso permitem que você conceda apenas permissões amplas, não valores específicos.

  • Ative a criptografia de ponta a ponta. O Serviço de Aplicativo é o pool de back-end do gateway de aplicação. ** Ao definir a configuração do pool de back-end, use o protocolo HTTPS na porta de back-end 443.

Dados em repouso

  • Use a criptografia de dados transparente para criptografar dados confidenciais no Banco de Dados SQL. A criptografia transparente de dados criptografa todo o banco de dados, backups e arquivos de log de transações e não requer alterações em seu aplicativo Web.

  • Coloque dados confidenciais em seu próprio banco de dados e ative a criptografia somente para esse banco de dados. Essa abordagem minimiza a latência de criptografia de banco de dados.

  • Entenda o suporte à criptografia interna. O Armazenamento do Azure criptografa automaticamente os dados em repouso por meio da criptografia do lado do servidor (AES (Advanced Encryption Standard) de 256 bits. O Azure Monitor criptografa automaticamente dados em repouso por meio de chaves gerenciadas pela Microsoft.

Governança

O Azure Policy ajuda a impor decisões de arquitetura e segurança para aplicativos Web. Ele pode impedir que recursos não compatíveis sejam implantados (modo de negação) ou sinalizá-los para revisão (modo de auditoria). Essa abordagem ajuda a detectar o descompasso de configuração da arquitetura pretendida, se o descompasso ocorre por meio de implantações de IaC (infraestrutura como código) ou alterações manuais no portal do Azure.

Coloque todos os recursos em sua arquitetura sob a governança do Azure Policy. Use políticas internas ou iniciativas de política sempre que possível para impor topologia de rede, recursos de serviço, segurança e decisões de monitoramento essenciais. Considere as seguintes políticas internas:

  • O Serviço de Aplicativo deve desabilitar o acesso à rede pública.
  • O Serviço de Aplicativo deve usar a integração de rede virtual.
  • O Serviço de Aplicativo deve usar o Link Privado para se conectar aos serviços de PaaS.
  • O Serviço de Aplicativo deve ter métodos de autenticação locais desabilitados para implantações de site de FTP e SCM.
  • O Serviço de Aplicativo deve ter a depuração remota desativada.
  • Os aplicativos do Serviço de Aplicativo devem usar a versão mais recente do TLS.
  • O Serviço do Defender para Aplicativo deve estar habilitado.
  • O Firewall do Aplicativo Web do Azure deve ser habilitado para o Gateway de Aplicativo.

Veja mais políticas internas para serviços importantes, como Gateway de Aplicativo e componentes de rede, Serviço de Aplicativo, Key Vault e componentes de monitoramento. Você pode criar políticas personalizadas ou usar políticas de comunidade, como políticas de zonas de destino do Azure, se as políticas internas não atenderem às suas necessidades. Prefira políticas integradas quando possível.

Gerenciamento de identidade e acesso

A arquitetura de linha de base do Serviço de Aplicativo configura a autenticação e a autorização para identidades de usuário (usuários) e identidades de carga de trabalho (recursos do Azure). Ele implementa o princípio do privilégio mínimo.

Identidades de usuário

  • Use o mecanismo de autenticação integrada para o Serviço de Aplicativo, também chamado EasyAuth. O EasyAuth simplifica a integração do provedor de identidade com seu aplicativo Web. Ele lida com a autenticação fora do seu aplicativo Web, para que você não precise fazer alterações significativas no código.

  • Configure a URL de resposta para o domínio personalizado. Defina a URL de redirecionamento como https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

    Substitua <application-gateway-endpoint> pelo endereço IP público ou pelo nome de domínio personalizado do gateway de aplicativo. Substitua <provider> pelo provedor de autenticação, como aad para a ID do Microsoft Entra.

    Para obter instruções de configuração, consulte as considerações do Azure Front Door ou configure o Gateway de Aplicativo.

Identidades de carga de trabalho

  • Use identidades gerenciadas para identidades de carga de trabalho. As identidades gerenciadas eliminam a necessidade de os desenvolvedores gerenciarem credenciais de autenticação.

  • Use identidades gerenciadas atribuídas ao usuário. As identidades atribuídas pelo sistema podem fazer com que as implantações de IaC falhem com base nas condições de concorrência e na ordem das operações. As identidades gerenciadas atribuídas pelo usuário evitam alguns desses cenários de erro de implantação. Para obter mais informações, confira Identidades gerenciadas.

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

A implantação do aplicativo básico do Serviço de Aplicativo segue as diretrizes de arquitetura do Azure Pipelines. Como a arquitetura de linha de base nega acesso público ao Serviço de Aplicativo e protege a conta de armazenamento de implantação dentro da rede virtual, você não pode implantar de fora da rede virtual. Para resolver essa restrição, a arquitetura usa agentes de implantação auto-hospedados que são executados na rede virtual. As diretrizes de implantação a seguir se concentram na implantação do código do aplicativo, não em alterações de infraestrutura ou de banco de dados.

Diagrama que mostra uma arquitetura de implantação do Serviço de Aplicativo de linha de base.

Fluxo de implantação

  1. O pipeline de lançamento publica uma solicitação de trabalho na fila de trabalho para os agentes auto-hospedados. O trabalho instrui o agente a carregar o artefato de construção do arquivo zip de publicação em uma conta de Armazenamento.

  2. Um agente de implantação autogerenciado sonda a fila, pega a solicitação de tarefa e baixa a tarefa e o artefato de compilação.

  3. O agente de implantação auto-hospedado carrega o arquivo zip para a conta de armazenamento por meio do ponto de extremidade privado da conta de armazenamento.

  4. O pipeline continua e um agente gerenciado pega um trabalho subsequente. O agente gerenciado executa um comando na interface de linha de comando (CLI) para atualizar a configuração do aplicativo WEBSITE_RUN_FROM_PACKAGE para referenciar o novo arquivo ZIP de publicação no slot de preparo.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. O App Service obtém o novo arquivo zip de publicação do armazenamento por meio do endpoint privado da conta de armazenamento. Ele reinicia a instância de preparo com o novo pacote porque WEBSITE_RUN_FROM_PACKAGE foi definido como um nome de arquivo diferente.

  6. O pipeline retoma e executa testes de fumaça ou aguarda aprovação manual. Após testes ou aprovação bem-sucedidos, o pipeline troca os slots de preparo e produção.

Diretrizes de implantação

Aplique as seguintes diretrizes de implantação para a arquitetura de linha de base:

  • Execute sua implantação diretamente de um pacote no Serviço de Aplicativo para evitar conflitos de implantação. Essa abordagem monta o pacote ZIP diretamente como diretório somente leitura wwwroot, em vez de copiar arquivos. Ele elimina conflitos de bloqueio de arquivos entre implantação e runtime e garante que apenas aplicativos totalmente implantados sejam executados.

  • Inclua números de versão em nomes de arquivo zip do pacote implantado. Quando você atualiza a configuração do WEBSITE_RUN_FROM_PACKAGE aplicativo para fazer referência ao pacote de implantação que tem um nome de arquivo diferente, o Serviço de Aplicativo puxa automaticamente o novo pacote e reinicia.

  • Utilize slots de implantação para implementações de código resiliente.

  • Considere a utilização de agentes gerenciados e auto-hospedados.

  • Use IaC para automatizar implantações de infraestrutura.

  • Valide o desempenho e a resiliência da carga de trabalho continuamente usando serviços como o Azure Load Testing e o Azure Chaos Studio.

Configuração

Os aplicativos exigem valores de configuração e segredos. Use as seguintes diretrizes para configuração e gerenciamento de segredos:

  • Nunca armazene segredos como senhas ou chaves de acesso no controle do código-fonte. Armazene segredos no Key Vault.

  • Armazene a configuração do aplicativo na configuração do Serviço de Aplicativo. Se você precisar de suporte para configuração externa ou sinalizador de recurso, use a Configuração de Aplicativos do Azure.

  • Use as referências do Cofre de Chaves na configuração do Serviço de Aplicativo para expor segredos com segurança em seu aplicativo.

  • Configure as configurações de aplicativo específicas do slot se os slots de produção e teste precisarem de valores diferentes. Por padrão, durante a implantação, as configurações do aplicativo são trocadas com o slot.

  • Use variáveis de ambiente locais ou recursos específicos da plataforma para desenvolvimento local. A configuração do Serviço de Aplicativo expõe as configurações do aplicativo como variáveis de ambiente. Ferramentas de desenvolvimento como o Visual Studio permitem que você defina variáveis de ambiente em perfis de inicialização e forneça armazenamento seguro para configurações locais por meio de segredos do usuário.

Monitoramento

O monitoramento coleta e analisa dados de sistemas de TI (tecnologia da informação) para fornecer observabilidade. Nessa arquitetura, o monitoramento controla a integridade e a segurança do aplicativo Web em várias camadas, o que ajuda a manter operações confiáveis.

Monitore três camadas de chave:

  • Código do aplicativo: Acompanhe a telemetria específica do aplicativo e as métricas personalizadas.

  • Infraestrutura (runtime): Monitore o ambiente de runtime do Serviço de Aplicativo.

  • Plataforma (recursos do Azure): Colete métricas e logs de serviços do Azure, como Gateway de Aplicativo, Banco de Dados SQL e Key Vault.

Para obter mais informações, consulte log de atividades do Azure, logs de recursos do Azure e log de aplicativos do Serviço de Aplicativo.

Monitore a plataforma

O monitoramento de plataforma coleta dados dos serviços do Azure em sua arquitetura.

Application Gateway

O Gateway de Aplicações monitora a integridade do pool de back-end por meio de sondas de integridade padrão. Utilize os logs de acesso do Gateway de Aplicações para coletar informações, como registros de data e hora, códigos de resposta HTTP e caminhos de URL. Para obter mais informações, consulte logs de integridade e diagnósticos do backend.

Serviço de Aplicativo

O Serviço de Aplicativo fornece recursos de monitoramento integrados e internos para melhorar a observabilidade. Se seu aplicativo Web já tiver recursos de telemetria e monitoramento, como instrumentação em processo, esses recursos continuarão funcionando no Serviço de Aplicativo.

  • Ative a instrumentação automática para estender a instrumentação sem alterações de código. Esse recurso fornece visibilidade do APM (monitoramento de desempenho do aplicativo). Para obter mais informações, consulte Monitorar o desempenho do Serviço de Aplicativo.

  • Ative o rastreamento distribuído para acompanhar solicitações em vários serviços e dependências. Você pode monitorar sistemas de nuvem distribuída por meio do rastreamento distribuído e de um perfilador de desempenho.

  • Use instrumentação baseada em código para telemetria personalizada. O Application Insights também dá suporte à instrumentação baseada em código para telemetria de aplicativo personalizado. Adicione o SDK do Application Insights ao seu código e use a API do Application Insights.

  • Ative os logs do Serviço de Aplicativo para diagnóstico em nível de plataforma. O Serviço de Aplicativo fornece quatro tipos de log para solução de problemas: logs de aplicativos, logs de servidor Web, mensagens de erro detalhadas e rastreamento de solicitação com falha.

  • Use logs estruturados. Adicione uma biblioteca de log estruturada ao código do aplicativo. Atualize seu código para usar pares chave-valor e ative os logs de aplicativos no App Service para armazená-los no seu Espaço de Trabalho do Log Analytics.

  • Ative o recurso de verificação de integridade do Serviço de Aplicativo para manter a disponibilidade. As verificações de integridade detectam instâncias não íntegras, redirecionam o tráfego para longe delas e as substituem automaticamente. Esse recurso requer duas ou mais instâncias do Serviço de Aplicativo.

Backup de banco de dados

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de design parade Eficiência de Desempenho.

Application Gateway

  • Implemente o dimensionamento automático para o Gateway de Aplicativo para aumentar ou reduzir a escala para atender à demanda.

  • Defina a contagem máxima de instâncias para um número maior do que a necessidade esperada. Você paga apenas pelas unidades de capacidade usadas.

  • Defina uma contagem mínima de instâncias que possa lidar com pequenos picos de tráfego. Você pode usar o uso médio da unidade de computação para calcular sua contagem mínima de instâncias.

  • Siga as diretrizes sobre o dimensionamento da sub-rede do Gateway de Aplicativo.

Serviço de Aplicativo

Banco de Dados SQL

O dimensionamento de banco de dados envolve muitas considerações além do escopo dessa arquitetura. Para obter mais informações sobre como dimensionar o Banco de Dados SQL, consulte os seguintes recursos:

Outras orientações sobre escalabilidade

  • Revise os limites e cotas de assinatura para garantir que os serviços sejam dimensionados de acordo com a demanda.

  • Considere o cache para os seguintes tipos de dados para aumentar o desempenho e a escalabilidade:

    • Dados de transação semiestática
    • Estado da sessão
    • Saída HTML complexa

Próximas etapas