Perspetiva do Azure Well-Architected Framework no Serviço de Aplicativo do Azure (Aplicativos Web)
O Serviço de Aplicativo do Azure é uma solução de computação de plataforma como serviço (PaaS) que você pode usar para hospedar sua carga de trabalho na plataforma Azure. É um serviço totalmente gerenciado que abstrai a computação subjacente e descarrega a responsabilidade de criar, implantar e dimensionar para a plataforma. Um serviço de aplicação é sempre executado num plano do Serviço de Aplicações. O plano de serviço escolhido determina a região na qual a carga de trabalho é executada, as configurações de computação e o sistema operacional. Vários modelos de cobrança estão disponíveis para o Serviço de Aplicativo.
Este artigo pressupõe que, como arquiteto, você revisou a árvore de decisão de computação e escolheu o Serviço de Aplicativo como a computação para sua carga de trabalho. As diretrizes neste artigo fornecem recomendações de arquitetura mapeadas para os princípios dos pilares do Azure Well-Architected Framework.
Importante
Como usar este guia
Cada seção tem uma lista de verificação de projeto que apresenta áreas arquitetônicas de preocupação, juntamente com estratégias de projeto localizadas para o escopo da tecnologia.
Também estão incluídas recomendações sobre as capacidades tecnológicas que podem ajudar a materializar essas estratégias. As recomendações não representam uma lista exaustiva de todas as configurações disponíveis para o recurso Aplicativos Web do Serviço de Aplicativo do Azure e suas dependências. Em vez disso, eles listam as principais recomendações mapeadas para as perspetivas de design. Use as recomendações para criar sua prova de conceito ou otimizar seus ambientes existentes.
Arquitetura básica que demonstra as principais recomendações: arquitetura de linha de base do Serviço de Aplicativo.
Âmbito da tecnologia
Esta análise concentra-se nas decisões inter-relacionadas para os seguintes recursos do Azure:
- Planos do Serviço de Aplicações
- Aplicações Web
Outras ofertas do Azure estão associadas ao Serviço de Aplicativo, como o Azure Functions, os Aplicativos Lógicos do Azure e o Ambiente do Serviço de Aplicativo. Essas ofertas estão fora do escopo deste artigo. O Ambiente do Serviço de Aplicativo é referenciado ocasionalmente para ajudar a esclarecer recursos ou opções das principais ofertas do Serviço de Aplicativo.
Fiabilidade
O objetivo do pilar Confiabilidade é fornecer funcionalidade contínua, construindo resiliência suficiente e a capacidade de se recuperar rapidamente de falhas.
Os princípios de projeto de confiabilidade fornecem uma estratégia de projeto de alto nível aplicada a componentes individuais, fluxos do sistema e o sistema como um todo.
Lista de verificação de estruturação
Inicie sua estratégia de design com base na lista de verificação de revisão de projeto para Confiabilidade. Determine sua relevância para seus requisitos de negócios, tendo em mente as camadas e os recursos do Serviço de Aplicativo e suas dependências. Alargar a estratégia de modo a incluir mais abordagens, conforme necessário.
Priorizar fluxos de usuários: nem todos os fluxos são igualmente críticos. Atribua prioridades a cada fluxo para orientar suas decisões de projeto. O design de fluxo de usuário pode influenciar quais camadas de serviço e o número de instâncias que você escolhe para um plano e configuração do Serviço de Aplicativo.
Por exemplo, seu aplicativo pode incluir camadas front-end e back-end que se comunicam por meio de um agente de mensagens. Você pode optar por segmentar as camadas em vários aplicativos Web para permitir dimensionamento, gerenciamento do ciclo de vida e manutenção independentes. Colocar um aplicativo grande em um único plano pode levar a problemas de memória ou CPU e afetar a confiabilidade.
Você pode precisar de mais instâncias no front-end para obter o desempenho ideal no lado da interface do usuário. No entanto, o back-end pode não exigir o mesmo número de instâncias.
Antecipar possíveis falhas: Planeje estratégias de mitigação para possíveis falhas. A tabela a seguir mostra exemplos de análise de modo de falha.
Falha Mitigação Falha de componentes subjacentes ou abstratos do Serviço de Aplicativo Ter redundância de componentes em instâncias e dependências. Monitore a integridade das instâncias, o desempenho da rede e o desempenho do armazenamento. Falha de dependências externas Use padrões de design, como o padrão Retry e o padrão Circuit Breaker. Monitore as dependências externas e defina tempos limite apropriados. Falha devido ao tráfego sendo roteado para instâncias não íntegras Monitore a integridade da instância. Considere a capacidade de resposta e evite enviar solicitações para instâncias não íntegras. Para obter mais informações, consulte Análise do modo de falha para aplicativos do Azure.
Construir redundância: crie redundância no aplicativo e na infraestrutura de suporte. Espalhe instâncias entre zonas de disponibilidade para melhorar a tolerância a falhas. O tráfego é encaminhado para outras zonas se uma zona falhar. Implante seu aplicativo em várias regiões para garantir que seu aplicativo permaneça disponível, mesmo que uma região inteira sofra uma interrupção.
Crie níveis semelhantes de redundância em serviços dependentes. Por exemplo, as instâncias de aplicativo se associam ao armazenamento de blobs. Considere configurar a conta de armazenamento associada com armazenamento com redundância de zona (ZRS) se um aplicativo usar uma implantação com redundância de zona.
Ter redundância em componentes de rede. Por exemplo, use endereços IP com redundância de zona e balanceadores de carga.
Tenha uma estratégia de dimensionamento confiável: uma carga inesperada em um aplicativo pode torná-lo não confiável. Considere a abordagem de dimensionamento correta com base nas características da sua carga de trabalho. Às vezes, você pode aumentar a escala para lidar com a carga. No entanto, se a carga continuar a aumentar, expanda para novas instâncias. Prefira o dimensionamento automático em vez de abordagens manuais. Sempre mantenha um buffer de capacidade extra durante as operações de dimensionamento para evitar a degradação do desempenho.
A camada de plano do Serviço de Aplicativo escolhida afeta o dimensionamento em termos do número de instâncias e das unidades de computação.
Garanta a inicialização adequada do aplicativo para que novas instâncias se aqueçam rapidamente e possam receber solicitações.
Esforce-se por aplicativos sem monitoração de estado sempre que possível. O dimensionamento confiável do estado com novas instâncias pode aumentar a complexidade. Considere um armazenamento de dados externo que você pode dimensionar independentemente se precisar armazenar o estado do aplicativo. Armazenar o estado da sessão na memória pode resultar na perda do estado da sessão quando há um problema com o aplicativo ou o Serviço de Aplicativo. Também limita a possibilidade de distribuir a carga por outras instâncias.
Teste regularmente suas regras de dimensionamento automático. Simule cenários de carregamento para verificar se seu aplicativo é dimensionado conforme o esperado. Você deve registrar eventos de dimensionamento para que possa solucionar problemas que possam surgir e otimizar sua estratégia de dimensionamento ao longo do tempo.
O Serviço de Aplicativo tem uma limitação no número de instâncias dentro de um plano, o que pode afetar a confiabilidade do dimensionamento. Uma estratégia é usar carimbos de implantação idênticos, cada instância de plano do Serviço de Aplicativo em execução com seu próprio ponto de extremidade. É essencial que você coloque todos os carimbos com um balanceador de carga externo para distribuir o tráfego entre eles. Use o Gateway de Aplicativo do Azure para implantações de zona única e o Azure Front Door para implantações multirregionais. Essa abordagem é ideal para aplicações de missão crítica onde a confiabilidade é crucial. Para obter mais informações, consulte Linha de base crítica com o Serviço de Aplicativo.
Um plano do Serviço de Aplicativo distribui o tráfego entre instâncias e monitora sua integridade. Observe que o balanceador de carga externo pode não detetar imediatamente se uma instância falhar.
Planeje sua capacidade de recuperação: a redundância é crucial para a continuidade dos negócios. Faça failover para outra instância se uma instância estiver inacessível. Explore os recursos de recuperação automática no Serviço de Aplicativo, como o reparo automático de instâncias.
Implemente padrões de projeto para lidar com a degradação normal para falhas transitórias, como problemas de conectividade de rede, e eventos de grande escala, como interrupções regionais. Considere os seguintes padrões de design:
O padrão Bulkhead segmenta seu aplicativo em grupos isolados para evitar que uma falha afete todo o sistema.
O padrão de Nivelamento de Carga Baseado em Fila fila itens de trabalho que servem como um buffer para suavizar picos de tráfego.
O padrão Retry lida com falhas transitórias devido a falhas de rede, conexões de banco de dados interrompidas ou serviços ocupados.
O padrão de disjuntor impede que um aplicativo tente repetidamente executar uma operação que provavelmente falhará.
Você pode usar WebJobs para executar tarefas em segundo plano em seu aplicativo Web. Para executar essas tarefas de forma confiável, certifique-se de que o aplicativo que hospeda seu trabalho seja executado continuamente em uma programação ou com base em gatilhos controlados por eventos.
Para obter mais informações, consulte Padrões de confiabilidade.
Realizar testes de confiabilidade: realize testes de carga para avaliar a confiabilidade e o desempenho do seu aplicativo sob carga. Os planos de teste devem incluir cenários que validem suas operações de recuperação automatizadas.
Use a injeção de falhas para introduzir falhas intencionalmente e validar seus mecanismos de autorrecuperação e autopreservação. Explore a biblioteca de falhas fornecida pelo Azure Chaos Studio.
O Serviço de Aplicativo impõe limites de recursos aos aplicativos hospedados. O plano do Serviço de Aplicativo determina esses limites. Certifique-se de que seus testes confirmam que o aplicativo é executado dentro desses limites de recursos. Para obter mais informações, veja Subscrição do Azure e limites, quotas e restrições do serviço.
Use testes de integridade para identificar trabalhadores que não respondem: o Serviço de Aplicativo tem recursos internos que executam periodicamente ping em um caminho específico do seu aplicativo Web. As instâncias que não respondem são removidas do balanceador de carga e substituídas por uma nova instância.
Recomendações
| Recomendação | Benefício |
|---|---|
| (Plano do Serviço de Aplicativo) Escolha a camada Premium de um plano do Serviço de Aplicativo para cargas de trabalho de produção. Defina o número máximo e mínimo de trabalhadores de acordo com seu planejamento de capacidade. Para obter mais informações, consulte Visão geral do plano do Serviço de Aplicativo. |
Um plano premium do Serviço de Aplicativo oferece recursos avançados de dimensionamento e garante redundância se ocorrerem falhas. |
| (Plano do Serviço de Aplicativo) Habilite a redundância de zona. Considere o provisionamento de mais de três instâncias para melhorar a tolerância a falhas. Verifique o suporte regional para redundância de zona porque nem todas as regiões oferecem esse recurso. |
Seu aplicativo pode resistir a falhas em uma única zona quando várias instâncias estão espalhadas entre zonas. O tráfego muda automaticamente para instâncias íntegras em outras zonas e mantém a confiabilidade do aplicativo se uma zona não estiver disponível. |
| (Serviço de Aplicativo) Considere desativar o recurso de afinidade de roteamento de solicitação de aplicativo (ARR). A afinidade ARR cria sessões adesivas que redirecionam os usuários para o nó que lidou com suas solicitações anteriores. | As solicitações de entrada são distribuídas uniformemente em todos os nós disponíveis quando você desabilita a afinidade ARR. Solicitações distribuídas uniformemente impedem que o tráfego sobrecarregue qualquer nó único. As solicitações podem ser redirecionadas diretamente para outros nós íntegros se um nó não estiver disponível. Evite afinidade de sessão para garantir que sua instância do Serviço de Aplicativo permaneça sem monitoração de estado. Um Serviço de Aplicativo sem monitoração de estado reduz a complexidade e garante um comportamento consistente entre nós. Remova sessões adesivas para que o Serviço de Aplicativo possa adicionar ou remover instâncias para dimensionar horizontalmente. |
| (Serviço de Aplicativo) Defina regras de recuperação automática com base na contagem de solicitações, solicitações lentas, limites de memória e outros indicadores que fazem parte da sua linha de base de desempenho. Considere essa configuração como parte de sua estratégia de dimensionamento. | As regras de recuperação automática ajudam seu aplicativo a se recuperar automaticamente de problemas inesperados. As regras configuradas acionam ações de recuperação quando os limites são violados. A recuperação automática permite a manutenção proativa automática. |
| (Serviço de Aplicativo) Habilite o recurso de verificação de integridade e forneça um caminho que responda às solicitações de verificação de integridade. | As verificações de integridade podem detetar problemas precocemente. Em seguida, o sistema pode tomar automaticamente ações corretivas quando uma solicitação de verificação de integridade falhar. O balanceador de carga roteia o tráfego de instâncias não íntegras, o que direciona os usuários para nós íntegros. |
Segurança
O objetivo do pilar Segurança é fornecer garantias de confidencialidade, integridade e disponibilidade para a carga de trabalho.
Os princípios de design de segurança fornecem uma estratégia de design de alto nível para atingir esses objetivos, aplicando abordagens ao design técnico em torno da hospedagem no Serviço de Aplicativo.
Lista de verificação de estruturação
Inicie sua estratégia de design com base na lista de verificação de revisão de design para Segurança e identifique vulnerabilidades e controles para melhorar a postura de segurança. Alargar a estratégia de modo a incluir mais abordagens, conforme necessário.
Revise as linhas de base de segurança: para aprimorar a postura de segurança do seu aplicativo hospedado em um plano do Serviço de Aplicativo, revise a linha de base de segurança do Serviço de Aplicativo.
Use o tempo de execução e as bibliotecas mais recentes: teste completamente as compilações do aplicativo antes de fazer atualizações para detetar problemas antecipadamente e garantir uma transição suave para a nova versão. O Serviço de Aplicativo oferece suporte à política de suporte de tempo de execução de linguagem para atualizar pilhas existentes e desativar pilhas de fim de suporte.
Crie segmentação por meio de limites de isolamento para conter violação: aplique a segmentação de identidade. Por exemplo, implemente o controle de acesso baseado em função (RBAC) para atribuir permissões específicas com base em funções. Siga o princípio do menor privilégio para limitar os direitos de acesso apenas ao necessário. Criar também segmentação ao nível da rede. Injete aplicativos do Serviço de Aplicativo em uma rede virtual do Azure para isolamento e defina NSGs (grupos de segurança de rede) para filtrar o tráfego.
Os planos do Serviço de Aplicativo oferecem a camada Ambiente do Serviço de Aplicativo que fornece um alto grau de isolamento. Com o Ambiente do Serviço de Aplicativo, você obtém computação e rede dedicadas.
Aplicar controles de acesso em identidades: restrinja o acesso interno ao aplicativo Web e o acesso externo do aplicativo Web a outros recursos. Essa configuração aplica controles de acesso em identidades e ajuda a manter a postura geral de segurança da carga de trabalho.
Use o Microsoft Entra ID para todas as necessidades de autenticação e autorização. Use funções internas, como um Colaborador do Plano Web, um Colaborador do Site e um Colaborador, Leitor e Proprietário genéricos.
Controle o tráfego de rede de e para o aplicativo: não exponha os pontos de extremidade do aplicativo para a Internet pública. Em vez disso, adicione um ponto de extremidade privado no aplicativo Web colocado em uma sub-rede dedicada. Fronte seu aplicativo com um proxy reverso que se comunica com esse ponto de extremidade privado. Considere usar o Application Gateway ou o Azure Front Door para essa finalidade.
Implante um firewall de aplicativo Web (WAF) para proteção contra vulnerabilidades comuns. O Application Gateway e o Azure Front Door têm recursos WAF integrados.
Configure as regras de proxy reverso e as configurações de rede adequadamente para alcançar o nível desejado de segurança e controle. Por exemplo, adicione regras NSG na sub-rede de ponto de extremidade privada para aceitar apenas o tráfego do proxy reverso.
O tráfego de saída do aplicativo para outros serviços PaaS deve ser sobre pontos de extremidade privados. Considere colocar um componente de firewall para restringir o tráfego de saída para a Internet pública. Ambas as abordagens impedem a exfiltração de dados.
Para obter uma visão abrangente, consulte Recursos de rede do Serviço de Aplicativo.
Criptografar dados: proteja os dados em trânsito com TLS (Transport Layer Security) de ponta a ponta. Use suas chaves gerenciadas pelo cliente para criptografia total dos dados em repouso. Para obter mais informações, consulte Criptografia em repouso usando chaves gerenciadas pelo cliente.
Não use protocolos herdados como TLS 1.0 e 1.1. O Serviço de Aplicativo habilita a versão 1.2 por padrão. Para obter mais informações, consulte Visão geral do TLS do Serviço de Aplicativo.
Todas as instâncias do seu Serviço de Aplicativo têm um nome de domínio padrão. Use um domínio personalizado e proteja esse domínio com certificados.
Reduza a superfície de ataque: remova as configurações padrão de que não precisa. Por exemplo, desative a depuração remota, a autenticação local para sites do Gerenciador de Controle do Código-Fonte (SCM) e a autenticação básica. Desative protocolos não seguros como HTTP e FTP (File Transfer Protocol). Impor configurações por meio de políticas do Azure. Para obter mais informações, consulte Políticas do Azure.
Implementar políticas restritivas de compartilhamento de recursos entre origens (CORS): use políticas restritivas de CORS em seu aplicativo Web para aceitar apenas solicitações de domínios, cabeçalhos e outros critérios permitidos. Imponha políticas CORS com definições de política internas do Azure.
Proteja segredos de aplicativos: você precisa lidar com informações confidenciais, como chaves de API ou tokens de autenticação. Em vez de codificar esses segredos diretamente no código do aplicativo ou nos arquivos de configuração, você pode usar as referências do Cofre da Chave do Azure nas configurações do aplicativo. Quando o aplicativo é iniciado, o Serviço de Aplicativo recupera automaticamente os valores secretos do Cofre de Chaves usando a identidade gerenciada do aplicativo.
Habilite logs de recursos para seu aplicativo: habilite logs de recursos para seu aplicativo para criar trilhas de atividade abrangentes que fornecem dados valiosos durante investigações que seguem incidentes de segurança.
Considere o registro em log como parte de seu processo de modelagem de ameaças ao avaliar ameaças.
Recomendações
| Recomendação | Benefício |
|---|---|
| (Serviço de Aplicativo) Atribua identidades gerenciadas ao aplicativo Web. Para manter os limites de isolamento, não compartilhe ou reutilize identidades entre aplicativos. Certifique-se de se conectar com segurança ao seu registro de contêiner se usar contêineres para sua implantação. |
O aplicativo recupera segredos do Cofre da Chave para autenticar a comunicação externa do aplicativo. O Azure gerencia a identidade e não exige que você provisione ou alterne nenhum segredo. Você tem identidades distintas para granularidade de controle. Identidades distintas facilitam a revogação se uma identidade for comprometida. |
| (Serviço de Aplicativo) Configure domínios personalizados para aplicativos. Desative HTTP e aceite apenas solicitações HTTPS. |
Os domínios personalizados permitem a comunicação segura através de HTTPS usando o protocolo TLS (Transport Layer Security), que garante a proteção de dados confidenciais e cria a confiança do usuário. |
| (Serviço de Aplicativo) avalie se a autenticação interna do Serviço de Aplicativo é o mecanismo certo para autenticar os usuários que acessam seu aplicativo. A autenticação interna do Serviço de Aplicativo integra-se ao Microsoft Entra ID. Esse recurso lida com a validação de token e o gerenciamento de identidade do usuário em vários provedores de login e suporta o OpenID Connect. Com esse recurso, você não tem autorização em um nível granular e não tem um mecanismo para testar a autenticação. | Ao usar esse recurso, você não precisa usar bibliotecas de autenticação no código do aplicativo, o que reduz a complexidade. O usuário já está autenticado quando uma solicitação chega ao aplicativo. |
| (Serviço de Aplicativo) Configure o aplicativo para integração de rede virtual. Use pontos de extremidade privados para aplicativos do Serviço de Aplicativo. Bloqueie todo o tráfego público. Encaminhe a imagem do contêiner através da integração de rede virtual. Todo o tráfego de saída do aplicativo passa pela rede virtual. |
Obtenha os benefícios de segurança de usar uma rede virtual do Azure. Por exemplo, o aplicativo pode acessar recursos com segurança dentro da rede. Adicione um ponto de extremidade privado para ajudar a proteger seu aplicativo. Os terminais privados limitam a exposição direta à rede pública e permitem o acesso controlado através do proxy reverso. |
| (Serviço de Aplicativo) Para implementar o endurecimento: - Desative a autenticação básica que usa um nome de usuário e senha em favor da autenticação baseada em ID do Microsoft Entra. - Desative a depuração remota para que as portas de entrada não sejam abertas. - Permitir que as políticas CORS restrinjam as solicitações recebidas. - Desative protocolos, como FTP. |
Não recomendamos a autenticação básica como um método de implantação seguro. O Microsoft Entra ID emprega a autenticação baseada em token OAuth 2.0, que oferece inúmeras vantagens e aprimoramentos que abordam as limitações associadas à autenticação básica. As políticas restringem o acesso aos recursos do aplicativo, permitem apenas solicitações de domínios específicos e protegem solicitações entre regiões. |
| (Serviço de Aplicativo) Use sempre as referências do Cofre da Chave como configurações do aplicativo. |
Os segredos são mantidos separados da configuração do seu aplicativo. As configurações do aplicativo são criptografadas em repouso. O Serviço de Aplicativo também gerencia rotações secretas. |
| (Plano do Serviço de Aplicativo) Habilite o Microsoft Defender for Cloud for App Service. | Obtenha proteção em tempo real para recursos executados em um plano do Serviço de Aplicativo. Proteja-se contra ameaças e melhore a sua postura geral de segurança. |
| (Plano do Serviço de Aplicativo) Habilite o log de diagnóstico e adicione instrumentação ao seu aplicativo. Os logs são enviados para contas de Armazenamento do Azure, Hubs de Eventos do Azure e Análise de Log. Para obter mais informações sobre tipos de log de auditoria, consulte Tipos de log suportados. | O registro em log captura padrões de acesso. Ele registra eventos relevantes que fornecem informações valiosas sobre como os usuários interagem com um aplicativo ou plataforma. Essas informações são cruciais para fins de responsabilidade, conformidade e segurança. |
Otimização de Custos
A Otimização de Custos concentra-se na deteção de padrões de gastos, priorizando investimentos em áreas críticas e otimizando em outras para atender ao orçamento da organização e, ao mesmo tempo, atender aos requisitos de negócios.
Os princípios de design de Otimização de Custos fornecem uma estratégia de design de alto nível para alcançar esses objetivos e fazer compensações conforme necessário no design técnico relacionado aos seus aplicativos Web e ao ambiente em que eles são executados.
Lista de verificação de estruturação
Inicie sua estratégia de design com base na lista de verificação de revisão de projeto para otimização de custos para investimentos e ajuste o projeto para que a carga de trabalho esteja alinhada com o orçamento alocado para a carga de trabalho. Seu design deve usar os recursos certos do Azure, monitorar investimentos e encontrar oportunidades para otimizar ao longo do tempo.
Estimar o custo inicial: como parte do exercício de modelagem de custos, use a calculadora de preços do Azure para avaliar os custos aproximados associados a várias camadas com base no número de instâncias que você planeja executar. Cada camada do Serviço de Aplicativo oferece diferentes opções de computação.
Monitore continuamente o modelo de custos para acompanhar os gastos.
Avalie as opções com desconto: os níveis mais altos incluem instâncias de computação dedicadas. Você pode aplicar um desconto de reserva se sua carga de trabalho tiver um padrão de uso previsível e consistente. Certifique-se de analisar os dados de uso para determinar o tipo de reserva que se adequa à sua carga de trabalho. Para obter mais informações, consulte Economizar custos com instâncias reservadas do Serviço de Aplicativo.
Entenda os medidores de uso: o Azure cobra uma taxa por hora, proporcional à segunda, com base na camada de preços do seu plano do Serviço de Aplicativo. As cobranças se aplicam a cada instância dimensionada em seu plano, com base no tempo que você aloca a instância da VM. Preste atenção aos recursos de computação subutilizados que podem aumentar seus custos como resultado de uma alocação excessiva devido à seleção de SKU subótima ou à configuração de expansão mal configurada.
Recursos extras do Serviço de Aplicativo, como registro de domínio personalizado e certificados personalizados, podem adicionar custos. Outros recursos, como redes virtuais para isolar sua solução ou cofres de chaves para proteger segredos de carga de trabalho, que se integram aos recursos do Serviço de Aplicativo também podem adicionar custos. Para obter mais informações, consulte Modelo de cobrança dos Serviços de Aplicativo.
Considere as compensações entre densidade e isolamento: você pode usar os planos do Serviço de Aplicativo para hospedar vários aplicativos na mesma computação, o que economiza custos com ambientes compartilhados. Para obter mais informações, consulte Compensações.
Avalie o efeito de sua estratégia de dimensionamento no custo: você deve projetar, testar e configurar corretamente para dimensionamento e dimensionamento quando implementar o dimensionamento automático. Estabeleça limites máximos e mínimos precisos para o dimensionamento automático.
Inicialize proativamente o aplicativo para um dimensionamento confiável. Por exemplo, não espere até que a CPU atinja 95% de uso. Em vez disso, acione o dimensionamento em cerca de 65% para permitir tempo suficiente para que novas instâncias sejam alocadas e inicializadas durante o processo de dimensionamento. No entanto, esta estratégia pode conduzir a uma capacidade não utilizada.
Recomendamos que você combine e equilibre mecanismos de expansão e expansão. Por exemplo, um aplicativo pode ser dimensionado por algum tempo e, em seguida, dimensionado conforme necessário. Explore níveis elevados que oferecem grande capacidade e uso eficiente de recursos. Com base em padrões de uso, níveis Premium mais altos geralmente são mais econômicos porque são mais capazes.
Otimize os custos do ambiente: considere o nível Básico ou Gratuito para executar ambientes de pré-produção. Esses níveis são de baixo desempenho e baixo custo. Se você usar a camada Básica ou Gratuita, use a governança para impor a camada, restringir o número de instâncias e CPUs, restringir o dimensionamento e limitar a retenção de logs.
Implementar padrões de design: essa estratégia reduz o volume de solicitações geradas pela sua carga de trabalho. Considere o uso de padrões como o padrão Backends for Frontends e o padrão Gateway Aggregation, que podem minimizar o número de solicitações e reduzir custos.
Verifique regularmente os custos relacionados aos dados: longos períodos de retenção de dados ou níveis de armazenamento caros podem levar a altos custos de armazenamento. Mais despesas podem se acumular devido ao uso de largura de banda e retenção prolongada de dados de registro.
Considere a implementação de cache para minimizar os custos de transferência de dados. Comece com o cache local na memória e, em seguida, explore as opções de cache distribuído para reduzir o número de solicitações para o banco de dados back-end. Considere os custos de tráfego de largura de banda associados à comunicação entre regiões se o banco de dados estiver localizado em uma região diferente.
Otimize os custos de implantação: aproveite os slots de implantação para otimizar os custos. O slot é executado no mesmo ambiente de computação que a instância de produção. Use-os estrategicamente para cenários como implantações azul-verde que alternam entre slots. Essa abordagem minimiza o tempo de inatividade e garante transições suaves.
Use slots de implantação com cuidado. Você pode introduzir problemas, como exceções ou vazamentos de memória, que podem afetar as instâncias existentes e as novas. Certifique-se de que testa cuidadosamente as alterações. Para obter orientação operacional, consulte Excelência operacional.
Recomendações
| Recomendação | Benefício |
|---|---|
| (Plano do Serviço de Aplicativo) Escolha camadas Gratuitas ou Básicas para ambientes mais baixos. Recomendamos essas camadas para uso experimental. Remova as camadas quando não precisar mais delas. | Os níveis Gratuito e Básico são econômicos em comparação com os níveis mais altos. Eles fornecem uma solução econômica para ambientes que não são de produção que não precisam dos recursos completos e do desempenho dos planos premium. |
| (Plano do Serviço de Aplicativo) Aproveite os descontos e explore os preços preferidos para: - Ambientes mais baixos com planos de desenvolvimento/teste. - Reservas do Azure e planos de poupança do Azure para computação dedicada que você provisiona na camada Premium V3 e no Ambiente do Serviço de Aplicativo. Use instâncias reservadas para cargas de trabalho estáveis com padrões de uso previsíveis. |
Os planos de desenvolvimento/teste fornecem taxas reduzidas para os serviços do Azure, o que os torna econômicos para ambientes que não são de produção. Use instâncias reservadas para pagar antecipadamente por recursos de computação e obter descontos significativos. |
| (Serviço de Aplicativo) Monitore os custos incorridos pelos recursos do Serviço de Aplicativo. Execute a ferramenta de análise de custos no portal do Azure. Crie orçamentos e alertas para notificar as partes interessadas. |
Você pode identificar picos de custos, ineficiências ou despesas inesperadas logo no início. Essa abordagem proativa ajuda você a fornecer controles orçamentários para evitar gastos excessivos. |
| (Plano do Serviço de Aplicativo) Escale quando a demanda diminuir. Para dimensionar, defina regras de escala para reduzir o número de instâncias no Azure Monitor. | Evite o desperdício e reduza despesas desnecessárias. |
Excelência Operacional
A Excelência Operacional concentra-se principalmente em procedimentos para práticas de desenvolvimento, observabilidade e gerenciamento de releases.
Os princípios de design de Excelência Operacional fornecem uma estratégia de design de alto nível para alcançar essas metas em relação aos requisitos operacionais da carga de trabalho.
Lista de verificação de estruturação
Inicie sua estratégia de design com base na lista de verificação de revisão de design para Excelência Operacional para definir processos de observabilidade, teste e implantação relacionados a Aplicativos Web.
Gerenciar versões: use slots de implantação para gerenciar versões de forma eficaz. Você pode implantar seu aplicativo em um slot, executar testes e validar sua funcionalidade. Após a verificação, você pode mover perfeitamente o aplicativo para a produção. Esse processo não incorre em custos extras porque o slot é executado no mesmo ambiente de máquina virtual (VM) que a instância de produção.
Execute testes automatizados: antes de promover uma versão do seu aplicativo Web, teste completamente seu desempenho, funcionalidade e integração com outros componentes. Use o Teste de Carga do Azure, que se integra ao Apache JMeter, uma ferramenta popular para testes de desempenho. Explore ferramentas automatizadas para outros tipos de teste, como o Phantom para testes funcionais.
Implantar unidades imutáveis: implemente o padrão de Carimbos de Implantação para compartimentar o Serviço de Aplicativo em um carimbo imutável. O Serviço de Aplicativo suporta o uso de contêineres, que são inerentemente imutáveis. Considere contêineres personalizados para seu aplicativo Web do Serviço de Aplicativo.
Cada carimbo representa uma unidade independente que você pode expandir ou dimensionar rapidamente. As unidades baseadas neste selo são temporárias e apátridas. O design sem estado simplifica as operações e a manutenção. Essa abordagem é ideal para aplicações de missão crítica. Para obter um exemplo, consulte Linha de base crítica com o Serviço de Aplicativo.
Use uma infraestrutura como tecnologia de código (IaC), como o Bicep, para eliminar unidades com repetibilidade e consistência.
Mantenha os ambientes de produção seguros: crie planos separados do Serviço de Aplicativo para executar ambientes de produção e pré-produção. Não faça alterações diretamente no ambiente de produção para garantir estabilidade e confiabilidade. Instâncias separadas permitem flexibilidade no desenvolvimento e nos testes antes de promover alterações na produção.
Use ambientes baixos para explorar novos recursos e configurações de forma isolada. Mantenha os ambientes de desenvolvimento e teste efêmeros.
Gerenciar certificados: para domínios personalizados, você precisa gerenciar certificados TLS.
Ter processos para adquirir, renovar e validar certificados. Descarregue esses processos para o Serviço de Aplicativo, se possível. Se utilizar o seu próprio certificado, tem de gerir a sua renovação. Escolha a abordagem que melhor se alinha com os seus requisitos de segurança.
| Recomendação | Benefício |
|---|---|
| (Serviço de Aplicativo) Monitore a integridade de suas instâncias e ative as sondas de integridade da instância. Configure um caminho específico para lidar com solicitações de teste de integridade. |
Você pode detetar problemas prontamente e tomar as ações necessárias para manter a disponibilidade e o desempenho. |
| (Serviço de Aplicativo) Habilite os logs de diagnóstico para o aplicativo e a instância. O registro frequente pode diminuir o desempenho do sistema, aumentar os custos de armazenamento e introduzir riscos se você tiver acesso não seguro aos logs. Siga estas práticas recomendadas: - Registre o nível certo de informações. - Definir políticas de retenção. - Manter uma pista de auditoria de acessos autorizados e tentativas não autorizadas. - Tratar logs como dados e aplicar controles de proteção de dados. |
Os logs de diagnóstico fornecem informações valiosas sobre o comportamento do seu aplicativo. Monitore padrões de tráfego e identifique anomalias. |
| (Serviço de Aplicativo) Aproveite os certificados gerenciados pelo Serviço de Aplicativo para descarregar o gerenciamento de certificação para o Azure. | O Serviço de Aplicativo lida automaticamente com processos como aquisição de certificados, verificação de certificados, renovação de certificados e importação de certificados do Cofre de Chaves. Como alternativa, carregue seu certificado no Cofre da Chave e autorize o provedor de recursos do Serviço de Aplicativo a acessá-lo. |
| (Plano do Serviço de Aplicativo) Valide as alterações do aplicativo no slot de preparo antes de trocá-lo pelo slot de produção. | Evite tempo de inatividade e erros. Reverta rapidamente para o último estado válido conhecido se detetar um problema após uma troca. |
Eficiência de Desempenho
A Eficiência de Desempenho consiste em manter a experiência do usuário mesmo quando há um aumento na carga por meio do gerenciamento de capacidade. A estratégia inclui dimensionar recursos, identificar e otimizar potenciais gargalos e otimizar para obter o máximo desempenho.
Os princípios de design de Eficiência de Desempenho fornecem uma estratégia de projeto de alto nível para atingir essas metas de capacidade em relação ao uso esperado.
Lista de verificação de estruturação
Inicie sua estratégia de design com base na lista de verificação de revisão de design para Eficiência de Desempenho para definir uma linha de base com base em indicadores-chave de desempenho para Aplicativos Web.
Identificar e monitorar indicadores de desempenho: defina metas para os indicadores-chave do aplicativo, como o volume de solicitações recebidas, o tempo que o aplicativo leva para responder a solicitações, solicitações pendentes e erros em respostas HTTP. Considere indicadores-chave como parte da linha de base de desempenho para a carga de trabalho.
Capture métricas do Serviço de Aplicativo que formam a base dos indicadores de desempenho. Colete logs para obter informações sobre o uso de recursos e atividades. Use ferramentas de monitoramento de desempenho de aplicativos (APM), como o Application Insights, para coletar e analisar dados de desempenho do aplicativo. Para obter mais informações, consulte Referência de dados de monitoramento do Serviço de Aplicativo.
Inclua instrumentação em nível de código, rastreamento de transações e perfil de desempenho.
Avaliar a capacidade: simule vários cenários de usuário para determinar a capacidade ideal necessária para lidar com o tráfego esperado. Use o teste de carga para entender como seu aplicativo se comporta sob diferentes níveis de carga.
Selecione a camada correta: use computação dedicada para cargas de trabalho de produção. As camadas Premium oferecem SKUs maiores com maior capacidade de memória e CPU, mais instâncias e mais recursos, como redundância de zona. Para obter mais informações, consulte Nível de preços Premium V3.
Otimize sua estratégia de dimensionamento: quando possível, use o dimensionamento automático em vez de ajustar manualmente o número de instâncias à medida que a carga do aplicativo muda. Com o dimensionamento automático, o Serviço de Aplicativo ajusta a capacidade do servidor com base em regras ou gatilhos predefinidos. Certifique-se de fazer testes de desempenho adequados e definir as regras certas para os gatilhos certos.
Se você priorizar a simplicidade durante a configuração inicial, use uma opção de dimensionamento automático que não exija que você defina regras e você só precisa definir limites.
Ter recursos suficientes prontamente disponíveis para garantir o desempenho ideal. Aloque recursos adequadamente para manter as metas de desempenho, como tempo de resposta ou taxa de transferência. Considerar a sobrealocação de recursos quando necessário.
Ao definir regras de dimensionamento automático, leve em conta o tempo que leva para o aplicativo ser inicializado. Considere essa sobrecarga ao tomar todas as decisões de dimensionamento.
Usar cache: recuperar informações de um recurso que não muda com frequência e é caro de acessar afeta o desempenho. Consultas complexas, incluindo junções e várias pesquisas, contribuem para o tempo de execução. Execute o cache para minimizar o tempo de processamento e a latência. Armazene em cache os resultados da consulta para evitar viagens de ida e volta repetidas para o banco de dados ou back-end e reduzir o tempo de processamento para solicitações subsequentes.
Para obter mais informações sobre como usar o cache local e distribuído na carga de trabalho, consulte Caching.
Revise os antipadrões de desempenho: para garantir que o aplicativo Web seja executado e dimensionado de acordo com seus requisitos de negócios, evite os antipadrões típicos. Aqui estão alguns antipadrões que o Serviço de Aplicativo corrige.
Anti-padrão Description Front End ocupado As tarefas com muitos recursos podem aumentar os tempos de resposta para os pedidos de utilizador e causar uma latência elevada.
Mova os processos que consomem recursos significativos para um back-end separado. Use um agente de mensagens para enfileirar tarefas que consomem muitos recursos e que o back-end seleciona para processar de forma assíncrona.Sem Colocação em Cache Atenda solicitações de um cache intermediário na frente do banco de dados back-end para reduzir a latência. Vizinho barulhento Os sistemas multilocatários compartilham recursos entre locatários. A atividade de um inquilino pode ter um efeito negativo na utilização do sistema por outro inquilino. O Ambiente do Serviço de Aplicativo fornece um ambiente totalmente isolado e dedicado para executar aplicativos do Serviço de Aplicativo.
Recomendações
| Recomendação | Benefício |
|---|---|
| Habilite a configuração Sempre Ativado quando os aplicativos compartilharem um único plano do Serviço de Aplicativo. Os aplicativos do Serviço de Aplicativo são descarregados automaticamente quando ociosos para economizar recursos. A próxima solicitação aciona um início a frio, o que pode causar tempos limite de solicitação. | O aplicativo nunca é descarregado com o Always On habilitado. |
| Considere o uso de HTTP/2 para aplicativos para melhorar a eficiência do protocolo. | Escolha HTTP/2 sobre HTTP/1.1 porque HTTP/2 multiplexa totalmente conexões, reutiliza conexões para reduzir a sobrecarga e compacta cabeçalhos para minimizar a transferência de dados. |
Vantagens e desvantagens
Você pode ter que fazer compensações de design se usar as abordagens nas listas de verificação de pilares. Aqui estão alguns exemplos de vantagens e desvantagens.
Densidade e isolamento
Maior densidade: coloque vários aplicativos dentro do mesmo plano do Serviço de Aplicativo para minimizar os recursos. Todos os aplicativos compartilham recursos como CPU e memória, o que pode economizar dinheiro e reduzir a complexidade operacional. Essa abordagem também otimiza o uso de recursos. Os aplicativos podem usar recursos ociosos de outro aplicativo se os padrões de carregamento mudarem ao longo do tempo.
Considere também as desvantagens. Por exemplo, picos de uso ou instabilidade de um aplicativo podem afetar o desempenho de outros aplicativos. Os incidentes em um aplicativo também podem permear outros aplicativos dentro do ambiente compartilhado, o que pode afetar a segurança.
Maior isolamento: O isolamento ajuda a evitar interferências. Essa estratégia se aplica à segurança, ao desempenho e até mesmo à segregação de ambientes de desenvolvimento, teste e produção.
O Ambiente do Serviço de Aplicativo oferece um melhor controle sobre a segurança e a proteção de dados porque cada aplicativo pode ter suas próprias configurações de segurança. Seu ambiente pode conter violações porque o isolamento limita o raio de explosão. A contenção de recursos é minimizada do ponto de vista do desempenho. O isolamento permite o dimensionamento independente com base na demanda específica e no planejamento de capacidade individual.
Como desvantagem, esta abordagem é mais dispendiosa e exige rigor operacional.
Estratégia de dimensionamento confiável
Uma estratégia de dimensionamento bem definida garante que seu aplicativo possa lidar com várias cargas sem comprometer o desempenho. No entanto, há compensações no custo. As operações de dimensionamento levam tempo. Quando novos recursos são alocados, o aplicativo deve ser inicializado corretamente antes de poder processar efetivamente as solicitações. Você pode provisionar recursos em excesso (instâncias pré-aquecidas) para fornecer uma rede de segurança. Sem essa capacidade extra, durante a fase de inicialização, pode haver um atraso no atendimento de solicitações, o que afeta a experiência do usuário. As operações de dimensionamento automático podem ser acionadas com antecedência suficiente para permitir a inicialização adequada de recursos no momento em que os clientes usam os recursos.
Como desvantagem, os recursos sobreprovisionados custam mais. Você é cobrado por segundo para cada instância, incluindo instâncias pré-aquecidas. Os níveis mais altos incluem instâncias pré-aquecidas. Determine se os recursos com níveis mais caros valem o investimento.
Redundância de edifícios
A redundância oferece resiliência, mas também implica custos. Os objetivos de nível de serviço (SLOs) para sua carga de trabalho determinam limites de desempenho aceitáveis. Torna-se um desperdício se a redundância exceder os requisitos de SLO. Avalie se o excesso de redundância melhora os SLOs ou adiciona complexidade desnecessária.
Considere também as desvantagens. Por exemplo, a redundância de várias regiões fornece alta disponibilidade, mas adiciona complexidade e custo devido à sincronização de dados, mecanismos de failover e comunicação entre regiões. Determine se a redundância de zona pode atender aos seus SLOs.
Políticas do Azure
O Azure fornece um extenso conjunto de políticas internas relacionadas ao Serviço de Aplicativo e suas dependências. Um conjunto de políticas do Azure pode auditar algumas das recomendações anteriores. Por exemplo, pode verificar se:
Controles de rede adequados estão em vigor. Por exemplo, você pode incorporar a segmentação de rede colocando o Serviço de Aplicativo na Rede Virtual do Azure por meio da injeção de rede virtual para ter maior controle sobre a configuração da rede. O aplicativo não tem pontos de extremidade públicos e se conecta aos serviços do Azure por meio de pontos de extremidade privados.
Os controles de identidade estão em vigor. Por exemplo, o aplicativo usa identidades gerenciadas para autenticar-se em relação a outros recursos. A autenticação integrada do Serviço de Aplicativo (Autenticação Fácil) verifica as solicitações de entrada.
Recursos como depuração remota e autenticação básica são desativados, para reduzir a superfície de ataque.
Para obter uma governança abrangente, revise as definições internas da Política do Azure e outras políticas que podem afetar a segurança da camada de computação.
Recomendações do Assistente do Azure
O Azure Advisor é um consultor de nuvem personalizado que ajuda você a seguir as práticas recomendadas para otimizar suas implantações do Azure. Aqui estão algumas recomendações que podem ajudá-lo a melhorar a confiabilidade, a segurança, a relação custo-benefício, o desempenho e a excelência operacional de suas instâncias de aplicativos Web.
Próximos passos
Considere os seguintes artigos como recursos que demonstram as recomendações destacadas neste artigo.
Use essas arquiteturas de referência como exemplos de como aplicar essas recomendações a uma carga de trabalho.
Se você nunca implantou um aplicativo Web, consulte Aplicativo Web básico.
Para obter uma arquitetura fundamental como ponto de partida para uma implantação de nível de produção, consulte Aplicativo Web redundante de zona altamente disponível de linha de base.
Use a seguinte documentação do produto para desenvolver sua experiência em implementação: