Editar

Aplicativo Web básico

Serviço de aplicativo do Azure
Cofre de Chave do Azure
Azure Monitor
Banco de Dados SQL do Azure

Essa arquitetura mostra os componentes fundamentais de um aplicativo Web básico. Você pode usar a arquitetura para criar um aplicativo Web e, em seguida, personalizar o aplicativo de acordo com suas necessidades.

Arquitetura

Diagram showing the reference architecture for a basic web application in Azure.

Baixe um Arquivo Visio dessa arquitetura.

Componentes

  • O Serviço de Aplicativo do Azure é uma plataforma totalmente gerenciada para criar e implantar aplicativos de nuvem. Ele permite definir um conjunto de recursos de computação para um aplicativo Web executar, implantar aplicativos Web e configurar slots de implantação.
  • Os slots de implantação permitem preparar uma implantação e, em seguida, trocá-la pela implantação de produção. Dessa forma, evita-se implantar diretamente na produção. Consulte a seção de engenharia e implantação de versão abaixo para obter recomendações específicas.
  • Endereço IP: o aplicativo Serviço de Aplicativo tem um endereço IP público e um nome de domínio. O nome de domínio é um subdomínio de azurewebsites.net, como contoso.azurewebsites.net.
  • O DNS do Azure é um serviço de hospedagem para domínios DNS, fornecendo resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure. Para usar um nome de domínio personalizado (como contoso.com), crie registros DNS que mapeiam o nome de domínio personalizado para o endereço IP. Para obter mais informações, consulte Configurar um nome de domínio personalizado no Serviço de Aplicativo do Azure.
  • O Banco de Dados SQL do Azure é um banco de dados relacional como serviço na nuvem. O Banco de Dados SQL compartilha a sua base de código com o mecanismo do banco de dados do Microsoft SQL Server. Dependendo dos requisitos de aplicativo, você também pode usar o banco de dados do Azure para MySQL ou o banco de dados do Azure para PostgreSQL. Essas alternativas são serviços de banco de dados totalmente gerenciados baseados nos mecanismos de banco de dados MySQL Server e Postgres de código aberto.
  • O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem que permite que os funcionários acessem aplicativos em nuvem desenvolvidos para sua organização.
  • O Azure Monitor é uma solução para coletar, analisar e agir em logs e métricas em seus ambientes.
  • O Cofre de Chaves do Azure dá suporte ao gerenciamento de segredos, gerenciamento de chaves e gerenciamento de certificados. Ele pode armazenar segredos de aplicativos, como cadeias de conexão de banco de dados.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita e fornecida no código. O código é implantado com configurações de produção. Use as recomendações para personalizar sua implantação para atender às suas necessidades.

Plano do Serviço de Aplicativo

O plano do Serviço de Aplicativo tem diferentes níveis de preços. Cada camada de preço oferece suporte a vários tamanhos de instância que diferem pelo número de núcleos e memória. Você pode alterar a camada de preços após a implantação selecionando "Expandir (Plano do Serviço de Aplicativo)" na navegação à esquerda. Aqui estão algumas recomendações do Serviço de Aplicativo:

  • Execute sua carga de trabalho de produção nos níveis de preços Básico, Standard e Premium. Nessas três camadas, o aplicativo é executado em instâncias de máquina virtual dedicadas e alocou recursos que podem ser expandidos.
  • Use as camadas Standard e Premier se precisar de dimensionamento automático e TLS/SSL.
  • Crie um plano diferente do Serviço de Aplicativo para teste e desenvolvimento. Use as camadas Gratuita e Compartilhada (visualização) para teste e desenvolvimento para eficiência de custos. Mas não use as camadas Gratuita e Compartilhada para cargas de trabalho de produção. Os recursos compartilhados não podem ser expandidos.
  • Certifique-se de excluir planos que você não está usando, como testar implantações. Os Planos do Serviço de Aplicativo são cobrados por segundo. Você será cobrado pelas instâncias no plano do Serviço de Aplicativo mesmo se o aplicativo for interrompido. Para obter mais informações sobre planos e cobrança do Serviço de Aplicativo, consulte:

O modelo ARM abaixo é implantado no nível de preços Padrão.

Banco de Dados SQL

  • Use o Banco de Dados SQL do Azure para reduzir a sobrecarga de gerenciamento. O Banco de Dados SQL do Azure cria uma construção lógica que atua como um ponto administrativo central para uma coleção de bancos de dados. Essa construção lógica reduz a sobrecarga de gerenciamento. Cada banco de dados dentro do grupo é implantado com uma camada de serviço específica. Dentro de cada grupo, os bancos de dados não podem compartilhar recursos. Não há custos de computação para o servidor, mas você precisa especificar a camada para cada banco de dados. Portanto, o desempenho pode ser melhor devido aos recursos dedicados, mas o custo pode ser maior.
  • Execute o planejamento de capacidade e escolha uma camada e um nível de desempenho que atendam às suas necessidades. O Banco de Dados SQL dá suporte às camadas de serviço Básico, Standard e Premium, com vários níveis de desempenho em cada camada que são medidos em DTUs (Unidades de Transmissão de Dados).

Region

  • Crie o plano do Serviço de Aplicativo e o Banco de Dados SQL na mesma região para minimizar a latência da rede. Em geral, escolha a região mais próxima aos usuários.
  • O grupo de recursos também tem uma região. Ele especifica onde os metadados de implantação são armazenados. Coloque o grupo de recursos e seus recursos na mesma região para melhorar a disponibilidade durante a implantação.
  • Use a calculadora de preços para estimar os custos.
  • Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Considerações

Essas considerações implementam os pilares da Estrutura de Bem-Arquitetado do Azure. Os pilares são um conjunto de princípios orientadores que melhoram a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Eficiência de desempenho

Um grande benefício do Serviço de Aplicativo do Azure é a capacidade de dimensionar o aplicativo com base na carga. Aqui estão algumas considerações para ter em mente ao planejar dimensionar seu aplicativo.

Dimensionando o aplicativo do Serviço de Aplicativo

Há dois modos de dimensionar um aplicativo do Serviço de Aplicativo:

  • Aumentar a escala significa alterar o tamanho da instância. O tamanho da instância determina a memória, o número de núcleos e o armazenamento em cada instância VM. Você pode aumentar manualmente, alterando o tamanho da instância ou a camada do plano.
  • Expandir significa adicionar instâncias para lidar com o aumento da carga. Cada tipo de preço tem um número máximo de instâncias. Você pode expandir alterando manualmente a contagem de instâncias ou configurando o dimensionamento automático para que o Azure adicione ou remova instâncias automaticamente com base em uma agenda e/ou métricas de desempenho. Cada operação de escala ocorre de maneira rápida, normalmente em questão de segundos.

Para habilitar o dimensionamento automático, crie um perfil de dimensionamento automático que defina o número mínimo e máximo de instâncias. Você pode configurar perfis baseados em agenda para disparar eventos de escala. Por exemplo, você pode criar perfis separados para dias de semana e fins de semana. Um perfil pode conter regras para quando adicionar ou remover instâncias. Por exemplo, adicionar duas instâncias se o uso da CPU estiver acima de 70% por 5 minutos.

Recomendações para dimensionar um aplicativo Web:

  • Limite a escala para cima e para baixo tanto quanto possível. Ele pode disparar uma reinicialização do aplicativo. Em vez disso, expanda-se. Selecione uma camada e um tamanho que atendam aos seus requisitos de desempenho sob carga típica e, em seguida, dimensione as instâncias para lidar com alterações no volume de tráfego.
  • Habilite o dimensionamento automático. Se seu aplicativo tiver uma carga de trabalho previsível e regular, crie perfis para agendar as contagens de instância antecipadamente. Se a carga de trabalho não for previsível, use o dimensionamento automático baseado em regras para reagir às alterações na carga à medida que elas ocorrem. Você pode combinar as duas abordagens.
  • Use o uso da CPU para regras de dimensionamento automático. Geralmente, o uso da CPU é uma boa métrica para as regras de dimensionamento automático. No entanto, você deve fazer um teste de carga do seu aplicativo, identificar gargalos potenciais e basear as regras de dimensionamento automático nesses dados.
  • Defina um período de resfriamento menor para adicionar instâncias e um maior para remover instâncias. As regras de dimensionamento automático incluem um período de resfriamento . O período de resfriamento é o intervalo a aguardar após a conclusão de uma ação de escala antes de iniciar uma nova ação de escala. O período de resfriamento permite que o sistema se estabilize antes de ser escalado novamente. Por exemplo, defina 5 minutos para adicionar uma instância, mas 60 minutos para remover uma instância. É melhor adicionar novas instâncias rapidamente sob carga pesada para lidar com o tráfego extra e, em seguida, reduzir gradualmente.

Dimensionando bancos de dados SQL

Dimensione bancos de dados individuais sem tempo de inatividade do aplicativo se precisar de uma camada de serviço ou nível de desempenho mais alto para o Banco de dados SQL.

Para obter mais informações, confira Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure.

Confiabilidade

No momento em que este artigo foi escrito, o contrato de nível de serviço (SLA) para o Serviço de Aplicativo é de 99,95%. O SLA do Serviço de Aplicativo aplica-se a instâncias únicas e múltiplas. O SLA para Banco de Dados SQL é de 99,99% para as camadas Basic, Standard e Premium.

Backups

O Banco de dados SQL fornece restauração point-in-time e restauração geográfica para restaurar a perda de dados. Esses recursos estão disponíveis em todas as camadas e são habilitados automaticamente. Você não precisa agendar ou gerenciar os backups.

  • Use a restauração point-in-time. Você pode se recuperar de erro humano retornando o banco de dados para um ponto anterior no tempo.
  • Use a restauração geográfica. Você pode se recuperar de uma interrupção de serviço restaurando um banco de dados de um backup com redundância geográfica.
  • Considere o uso de backup e restauração do Serviço de Aplicativo. Backup e restauração é um recurso para seus arquivos de aplicativo. No entanto, os arquivos de backup incluem configurações do aplicativo em texto sem formatação, como cadeias de conexão.
  • Evite usar o recurso de backup do Serviço de Aplicativo para fazer backup de seus bancos de dados SQL. Ele exporta o banco de dados para um arquivo SQL BACPAC, consumindo DTUs. Nesse caso, use a Recuperação Pontual do banco de dados SQL descrita acima. Para obter mais informações, consulte continuidade de negócios na nuvem e recuperação de desastres de banco de dados com o Banco de dados SQL.

Excelência operacional

Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. Separar ambientes facilita o gerenciamento de implantações, a exclusão de implantações de teste e a atribuição de direitos de acesso.

Ao atribuir recursos a grupos de recursos, considere os seguintes recursos:

  • Ciclo de vida. Em geral, coloque recursos com o mesmo ciclo de vida no mesmo grupo de recursos.
  • Acesso. Você pode usar o RBAC (controle de acesso baseado em função) do Azure para aplicar políticas de acesso aos recursos em um grupo.
  • Cobrança. Você pode exibir os custos acumulados para o grupo de recursos.

Para obter mais informações, confira Visão geral do Azure Resource Manager.

Configurações do aplicativo

  • Armazene definições de configuração como configurações do aplicativo. Defina as configurações do aplicativo em seus modelos do Resource Manager ou com o PowerShell. No runtime, as configurações de aplicativo ficam disponíveis para o aplicativo como variáveis de ambiente.
  • Nunca verifique senhas, chaves de acesso ou cadeias de conexão no controle do código-fonte. Em vez disso, passe segredos como parâmetros para um script de implantação que armazena esses valores como configurações do aplicativo.
  • Quando você alterna um slot de implantação, as configurações do aplicativo são alternadas por padrão. Se você precisar de configurações diferentes para produção e preparo, será possível criar configurações de aplicativo que permanecem em um slot e não são trocadas.

Diagnóstico e monitoramento

DevOps

  • Use modelos ARM para implantar recursos do Azure e suas dependências. O modelo ARM que o acompanha implanta um único aplicativo Web. Todos os recursos são isolados na mesma carga de trabalho básica. Esse isolamento facilita a associação de recursos específicos da carga de trabalho a uma equipe. A equipe pode então gerenciar de forma independente todos os aspectos desses recursos. Esse isolamento permite que a equipe de DevOps execute a CI/CD (integração contínua e entrega contínua).
  • Use diferentes modelos ARM e integre-os aos serviços de DevOps do Azure. Essa configuração permite criar ambientes diferentes em minutos. Por exemplo, você pode replicar cenários semelhantes à produção ou ambientes de teste de carga somente quando necessário e economizar no custo.
  • Provisione várias instâncias do aplicativo Web. Você não quer que seu aplicativo Web dependa de uma única instância e potencialmente crie um único ponto de falha. Várias instâncias melhoram a resiliência e a escalabilidade.

Para obter mais informações, confira a seção de DevOps em Azure Well-Architected Framework.

Engenharia e implantação de versões

  • Use modelos do Gerenciador de Recursos do Azure para provisionar recursos do Azure. Os modelos facilitam a automatização das implantações por meio do PowerShell ou da CLI do Azure.
  • Implante o aplicativo (código, binários e arquivos de conteúdo). Existem várias opções, incluindo a implantação de um repositório Git local, usando o Visual Studio ou a implantação contínua usando o controle do código-fonte baseado em nuvem. Consulte Implantar o aplicativo no Serviço de Aplicativo do Azure.

Um aplicativo do Serviço de Aplicativo sempre tem um slot de implantação chamado production. O slot de produção representa o local de produção ao vivo. É recomendável criar um slot de preparo para implantar atualizações. Os benefícios do uso de um slot de preparo incluem:

  • Você pode verificar se a implantação foi bem-sucedida antes de colocá-la em produção.
  • Implantar em um slot de preparo garante que todas as instâncias sejam aquecidas antes de serem alternadas para produção. Muitos aplicativos têm um tempo significativo de aquecimento e de resfriamento.
  • Crie um terceiro slot para manter a última implantação em boas condições. Depois de alternar o preparo e a produção, mova a implantação de produção anterior (que agora está no processo de preparo) para o último slot válido. Dessa forma, se você descobrir um problema mais tarde, será possível reverter rapidamente para a última versão válida.

Swapping slots for production and staging deployments

  • Ao reverter para uma versão anterior, verifique se todas as alterações de esquema do banco de dados são compatíveis com as versões anteriores.
  • Não use os slots da implantação de produção para teste, porque todos os aplicativos no mesmo Plano do Serviço de Aplicativo compartilham as mesmas instâncias de VM. Por exemplo, testes de carga podem prejudicar o site de produção dinâmica. Nesse caso, crie Planos do Serviço de Aplicativo separados para teste e produção. Colocando as implantações de teste em um plano separado, você as isola da versão de produção.

Segurança

Esta seção lista as considerações sobre segurança específicas dos serviços do Azure descritos neste artigo. Esta não é uma lista completa de práticas recomendadas de segurança. Para obter algumas outras considerações de segurança, consulte Proteger um aplicativo no Serviço de Aplicativo do Azure.

Auditoria do Banco de Dados SQL

A auditoria pode ajudar a manter a conformidade regulamentar e obter informações sobre discrepâncias e irregularidades que podem indicar preocupações comerciais ou suspeitas de violações de segurança. Consulte Introdução à auditoria do banco de dados SQL.

Slots de implantação

Cada slot de implantação tem um endereço IP público. Proteja os slots de não produção usando o logon do Microsoft Entra para que apenas os membros de suas equipes de desenvolvimento e DevOps possam alcançar esses pontos de extremidade.

Registrando em log

Os logs nunca devem registrar senhas de usuários ou outras informações que possam ser usadas para confirmação de fraude de identidade. Remova esses detalhes dos dados antes de armazená-los.

SSL

Um aplicativo do Serviço de Aplicativo inclui um ponto de extremidade SSL em um subdomínio sem azurewebsites.net custo extra. O ponto de extremidade SSL inclui um certificado curinga para o domínio *.azurewebsites.net. Ao usar um nome de domínio personalizado, você deverá fornecer um certificado que corresponda ao domínio personalizado. A abordagem mais simples é comprar um certificado diretamente no portal do Azure. Você também pode importar certificados de outras autoridades de certificação. Para obter mais informações, consulte comprar e configurar um certificado SSL para seu Serviço de Aplicativo do Azure.

O HTTPS não está habilitado por padrão na implantação do modelo ARM. Como prática recomendada de segurança, o aplicativo deve impor HTTPS redirecionando as solicitações HTTP. Você pode implementar HTTPS dentro de seu aplicativo ou usar uma regra de reconfiguração de URL conforme descrito em habilitar HTTPS para um aplicativo no Serviço de Aplicativo do Azure.

Autenticação

Recomendamos a autenticação por meio de um provedor de identidade (IDP), como Microsoft Entra ID, Facebook, Google ou Twitter. Use o OAuth 2 ou o OIDC (OpenID Connect) para o fluxo de autenticação. O Microsoft Entra ID fornece funcionalidade para gerenciar usuários e grupos, criar funções de aplicativo, integrar suas identidades locais e consumir serviços de back-end, como o Microsoft 365 e o Skype for Business.

Evite que o aplicativo gerencie logins e credenciais de usuários diretamente. Ele cria uma superfície de ataque potencial. No mínimo, seria necessário ter uma confirmação por email, uma recuperação de senha e uma autenticação multifator, bem como validar o nível de segurança da senha e armazenar hashes de senha com segurança. Os grandes provedores de identidade cuidam de tudo isso para você e estão sempre monitoramento e aprimorando as práticas de segurança.

Considere usar a autenticação do Serviço de Aplicativo para implementar o fluxo de autenticação OAuth ou OIDC. Os benefícios de autenticação do Serviço de Aplicativo incluem:

  • Fácil de configurar.
  • Nenhum código é necessário para cenários de autenticação simples.
  • Dá suporte para autorização delegada usando tokens de acesso OAuth para consumir recursos em nome do usuário.
  • Fornece um cache de token interno.

Algumas limitações da autenticação do Serviço de Aplicativo:

  • Opções de personalização limitadas.
  • A autorização delegada é restrita a um recurso de back-end por sessão de logon.
  • Se você usar mais de um IDP, não haverá nenhum mecanismo interno para a descoberta de território doméstico.
  • Para cenários multilocatários, o aplicativo deve implementar a lógica para validar o emissor do token.

Implantar este cenário

Essa arquitetura inclui um plano do Serviço de Aplicativo do Azure e um aplicativo vazio. Ele usa o Banco de Dados SQL do Azure, o Cofre de Chaves do Azure para armazenar a cadeia de conexão do banco de dados e o Monitor do Azure para log, monitoramento e alerta.

Use o comando a seguir para criar um grupo de recursos para a implantação. Selecione o botão Experimentar para usar um shell incorporado.

az group create --name basic-web-app --location eastus

Execute o comando a seguir para implantar o aplicativo Web e a infraestrutura de suporte. Quando solicitado, digite o nome de usuário e a senha. Esses valores são usados para acessar a instância do Banco de Dados SQL do Azure.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Para obter informações detalhadas e mais opções de implantação, consulte os modelos ARM usados para implantar esta solução.

Modelo do ARM de aplicativo Web básico

Próximas etapas

Dicas para solucionar problemas do aplicativo:

Documentação do produto:

Módulos do Microsoft Learn: