Aplicação Web básica

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Esta arquitetura mostra os componentes fundamentais de uma aplicação Web básica. 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.

Transfira um ficheiro do Visio desta arquitetura.

Componentes

  • O Serviço de Aplicações do Azure é uma plataforma completamente gerida para criar e implementar aplicações na nuvem. Ele permite definir um conjunto de recursos de computação para um aplicativo Web ser executado, 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 implementar diretamente na produção. Consulte a seção de engenharia de liberação e implantação abaixo para obter recomendações específicas.
  • Endereço IP: o aplicativo do 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, tal como contoso.azurewebsites.net.
  • O DNS do Azure é um serviço de alojamento dos domínios DNS que fornece resolução de nomes através da infraestrutura do Microsoft Azure. Ao alojar os seus domínios no Azure, pode gerir os recursos DNS com as mesmas credenciais, APIs, ferramentas e faturação dos 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, veja Configurar um nome de domínio personalizado no Serviço de Aplicações do Azure.
  • O Banco de Dados SQL do Azure é um banco de dados relacional como serviço na nuvem. A Base de Dados SQL partilha a base de código com o motor de bases de dados do Microsoft SQL Server. Dependendo dos requisitos do seu 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 com base nos mecanismos de banco de dados de código aberto MySQL Server e Postgres.
  • 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 Azure Key Vault 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 diferir 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 Aplicações

O plano do Serviço de Aplicativo tem diferentes níveis de preço. Cada camada de preço suporta 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 "Scale-up (App Service Plan)" 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 Basic, 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 Gratuito e Compartilhado (visualização) para testes e desenvolvimento com eficiência de custos. Mas não use as camadas Gratuito e Compartilhado 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 que o aplicativo seja 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ço Padrão.

Base 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 por causa dos recursos dedicados, mas o custo pode ser maior.
  • Realize o planeamento de capacidade e escolha o escalão e o nível de desempenho que satisfaz os seus requisitos. A Base de Dados SQL suporta os escalões de serviço Basic, Standard e Premium, com vários níveis de desempenho em cada escalão medidos em Unidades de Transação da Base de Dados (DTUs).

País/Região

  • 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. Por norma, escolha a região mais próxima dos seus utilizadores.
  • 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 custos.
  • Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.

Considerações

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

Eficiência de desempenho

Uma vantagem principal do Serviço de Aplicações do Azure é a capacidade de dimensionar a aplicação com base na carga. Seguem-se algumas considerações a lembrar quando planear dimensionar a aplicação.

Dimensionar a aplicação do Serviço de Aplicações

Existem duas formas de dimensionar uma aplicação do Serviço de Aplicações:

  • 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 de VM. Pode aumentar verticalmente de forma manual ao alterar o tamanho da instância ou o escalão do plano.
  • Dimensionar significa adicionar instâncias para lidar com o aumento da carga. Cada escalão 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 acontece rapidamente, normalmente em 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 acionar eventos de escala. Por exemplo, você pode criar perfis separados para dias úteis 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 uma aplicação Web:

  • Limite o escalonamento para cima e para baixo tanto quanto possível. Ele pode acionar uma reinicialização do aplicativo. Em vez disso, diminua a escala. 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.
  • Ative o dimensionamento automático. Se a sua aplicação tiver uma carga de trabalho normal e previsível, crie perfis para agendar as contagens de instâncias 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. Pode combinar as duas abordagens.
  • Use o uso da CPU para regras de dimensionamento automático. A utilização da CPU é, geralmente, uma boa métrica para as regras de dimensionamento automático. No entanto, deve realizar um teste de carga da sua aplicação, identificar potenciais estrangulamentos e basear as suas regras de dimensionamento automático nesses dados.
  • Defina um período de reflexão mais curto para adicionar instâncias e um período de reflexão mais longo para remover instâncias. As regras de dimensionamento automático incluem um período de reflexão . O período de reflexão é o intervalo de espera após a conclusão de uma ação de escala antes de iniciar uma nova ação de escala. O período de arrefecimento permite que o sistema estabilize antes de dimensionar 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.

Dimensionamento de bancos de dados SQL

Aumente a escala de 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, veja Dimensionar recursos de base de dados individual na Base de Dados do SQL do Azure.

Fiabilidade

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 Aplicações aplica-se a uma ou várias instâncias. O SLA do Banco de dados SQL é de 99,99% para as camadas Basic, Standard e Premium.

Cópias de Segurança

O Banco de dados SQL fornece restauração point-in-time e restauração geográfica para restaurar a perda de dados. Estas funcionalidades estão disponíveis em todos os escalões e são ativadas automaticamente. Não precisa de agendar nem gerir as cópias de segurança.

Excelência operacional

Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. A separação de 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 os 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.
  • Faturação. Pode ver os custos agregados ao grupo de recursos.

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

Configurações do aplicativo

  • Armazene as definições de configuração como definições da aplicação. Defina as configurações do aplicativo em seus modelos do Gerenciador de Recursos ou usando o PowerShell. No tempo de execução, as definições da aplicação estão disponíveis para a aplicação como variáveis do ambiente.
  • Nunca selecione palavras-passe, chaves de acesso ou cadeias de ligação no controlo de origem. Em vez disso, passe segredos como parâmetros para um script de implantação que armazena esses valores como configurações do aplicativo.
  • Quando troca um bloco de implementação, as definições da aplicação regressam aos valores predefinidos. Se você precisar de configurações de produção e preparo diferentes, poderá criar configurações de aplicativo que se mantenham em um slot e não sejam trocadas.

Diagnóstico e monitorização

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 dos recursos específicos da carga de trabalho a uma equipe. A equipe pode então gerenciar de forma independente todos os aspetos desses recursos. Esse isolamento permite que a equipe de DevOps realize integração contínua e entrega contínua (CI/CD).
  • Use diferentes modelos ARM e integre-os aos serviços de DevOps do Azure. Esta configuração permite-lhe criar diferentes ambientes em minutos. Por exemplo, você pode replicar cenários semelhantes aos de produção ou ambientes de teste de carga somente quando necessário e economizar custos.
  • 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, consulte a seção DevOps no Azure Well-Architected Framework.

Engenharia de lançamento e implantação

  • Use modelos do Azure Resource Manager para provisionar recursos do Azure. Os modelos facilitam a automatização de implantações por meio do PowerShell ou da CLI do Azure.
  • Implante o aplicativo (código, binários e arquivos de conteúdo). Tem várias opções, incluindo a implementação a partir de um repositório Git local, com o Visual Studio, ou a implementação contínua a partir do controlo de origem baseado na nuvem. Veja Implementar a aplicação no Serviço de Aplicações 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. Recomendamos que crie um bloco de teste para a implementação das atualizações. Benefícios da utilização de um bloco de teste:

  • Você pode verificar se a implantação foi bem-sucedida antes de trocá-la para a produção.
  • A implementação de um bloco de teste assegura que todas as instâncias são preparadas antes de serem colocadas em produção. Muitas aplicações têm um tempo significativo de aquecimento e arranque a frio.
  • Crie um terceiro slot para armazenar a última implantação em boas condições. Depois de trocar de teste para produção, mova a implementação de produção anterior (que está agora no modo de teste) para o último bloco bom conhecido. Desta forma, se detetar um problema posteriormente, poderá rapidamente reverter para a última boa versão conhecida.

Swapping slots for production and staging deployments

  • Se reverter para uma versão anterior, verifique se as alterações do esquema da base de dados são compatíveis com versões anteriores.
  • Não utilize os blocos na implementação de produção para fins de teste, uma vez que todas as aplicações no mesmo plano do Serviço de Aplicações partilham as mesmas instâncias de VM. Por exemplo, os testes de carga podem degradar o local de produção ao vivo. Em vez disso, crie planos do Serviço de Aplicações separados para a produção e o teste. Ao colocar implantações de teste em um plano separado, você as isola da versão de produção.

Segurança

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

Auditoria da Base de Dados SQL

A auditoria pode ajudá-lo a manter a conformidade regulatória e a obter informações relativas a discrepâncias e irregularidades que possam traduzir preocupações comerciais ou suspeitas de violações de segurança. Veja Introdução à auditoria da Base de Dados SQL.

Blocos de implementação

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

Registo

Os registos nunca devem gravar palavras-passe dos utilizadores ou outras informações que possam ser utilizadas para o roubo de identidade. Elimine esses detalhes dos dados antes de os armazenar.

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 final SSL inclui um certificado de caráter universal para o domínio *.azurewebsites.net. Se utilizar um nome de domínio personalizado, terá de fornecer um certificado correspondente ao domínio personalizado. A abordagem mais simples consiste em comprar um certificado diretamente no Portal do Azure. 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.

HTTPS não está habilitado por padrão na implantação do modelo ARM. Como melhor prática de segurança, a aplicação deve impor HTTPS ao redirecionar os pedidos de HTTP. Você pode implementar HTTPS em 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. Utilize o OAuth 2 ou o OpenID Connect (OIDC) 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. Cria uma superfície de ataque potencial. No mínimo, você precisaria ter uma confirmação de e-mail, recuperação de senha e autenticação multifator, validar a força da senha e armazenar hashes de senha com segurança. Os grandes provedores de identidade lidam com todas essas coisas para você e estão constantemente monitorando e melhorando suas 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. Benefícios da autenticação do Serviço de Aplicações:

  • Fácil de configurar.
  • Não é necessário nenhum código para cenários de autenticação simples.
  • Suporta a autorização delegada com tokens de acesso de OAuth para consumir recursos em nome do utilizador.
  • Fornece uma cache de tokens incorporada.

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

  • Opções de personalização limitadas.
  • A autorização delegada está restrita a um recurso de back-end por início de sessão.
  • Se você usar mais de um IDP, não haverá nenhum mecanismo interno para a descoberta do território doméstico.
  • Para cenários de vários inquilinos, a aplicação tem de implementar a lógica para validar o emissor de tokens.

Implementar 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 da Chave do Azure para armazenar a cadeia de conexão do banco de dados e o Azure Monitor para registro, 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 seguinte comando para implantar o aplicativo Web e a infraestrutura de suporte. Quando solicitado, digite um nome de usuário e 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.

Próximos passos

Sugestões de resolução de problemas da aplicação:

Documentação do produto:

Módulos do Microsoft Learn: