Perspectiva 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 transfere a responsabilidade de criar, implantar e dimensionar para a plataforma. Um serviço de aplicativo é executado em um Plano do Serviço de Aplicativo. 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. A orientação neste artigo fornece recomendações de arquitetura mapeadas de acordo com 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 de preocupação arquitetônicas juntamente com estratégias de projeto localizadas para o escopo da tecnologia.
Também estão incluídas recomendações sobre os recursos tecnológicos 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 perspectivas 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.
Escopo da tecnologia
Esta revisão se concentra nas decisões inter-relacionadas para os seguintes recursos do Azure:
- Planos do Serviço de Aplicativo
- Aplicativos 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.
Confiabilidade
O objetivo do pilar Confiabilidade é fornecer funcionalidade contínua, criando 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 ao sistema como um todo.
Lista de verificação de projeto
Inicie sua estratégia de design com base na lista de verificação de revisão de design 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. Estender a estratégia para 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 design. O design do 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.
Talvez você precise 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 abstraídos do Serviço de Aplicativo Tenha 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 Repetir e o padrão Disjuntor. Monitore as dependências externas e defina tempos limite apropriados. Falha devido ao tráfego sendo roteado para instâncias não íntegras Monitorar 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 de modo de falha para aplicativos do Azure.
Redundância de compilação: 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 é roteado para outras zonas se uma zona falhar. Implante seu aplicativo em várias regiões para garantir que ele permaneça disponível, mesmo se uma região inteira passar por uma interrupção.
Crie níveis semelhantes de redundância em serviços dependentes. Por exemplo, instâncias de aplicativo se vinculam ao armazenamento de blob. Considere configurar a conta de armazenamento associada com ZRS (zone-redundant storage, armazenamento com redundância de zona) se um aplicativo usar uma implantação com redundância de zona.
Ter redundância nos 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 em suas características de 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 sejam aquecidas rapidamente e possam receber solicitações.
Esforce-se para 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. O armazenamento do 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 espalhar 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 em um plano, o que pode afetar a confiabilidade do dimensionamento. Uma estratégia é usar carimbos de implantação idênticos, cada um executando a instância do plano do Serviço de Aplicativo 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 em que a confiabilidade é crucial. Para obter mais informações, consulte Linha de base de missão 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 detectar 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 design para lidar com a degradação normal para falhas transitórias, como problemas de conectividade de rede, e eventos de grande escala, como paralisaçõ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 enfila itens de trabalho que servem como um buffer para suavizar picos de tráfego.
O padrão Repetir lida com falhas transitórias devido a falhas de rede, conexões de banco de dados descartadas ou serviços ocupados.
O padrão 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 agenda ou com base em gatilhos orientados a 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 aplicativo sob carga. Os planos de teste devem incluir cenários que validem suas operações de recuperação automatizada.
Use a injeção de falhas para introduzir falhas intencionalmente e validar seus mecanismos de auto-recuperação e autopreservação. Explore a biblioteca de falhas fornecida pelo Azure Chaos Studio.
O Serviço de Aplicativo impõe limites de recursos a aplicativos hospedados. O plano do Serviço de Aplicativo determina esses limites. Certifique-se de que seus testes confirmem que o aplicativo é executado dentro desses limites de recursos. Para saber mais, confira Assinatura e limites de serviço, cotas e restrições do Azure.
Use testes de integridade para identificar trabalhadores que não respondem: o Serviço de Aplicativo tem recursos internos que executam ping periodicamente 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 aumentar a tolerância a falhas. Verifique o suporte regional para redundância de zona, pois nem todas as regiões oferecem esse recurso. |
Seu aplicativo pode suportar 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 desabilitar 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 manipulou 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 perfeitamente 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 linha de base de desempenho. Considere essa configuração como parte de sua estratégia de dimensionamento. | As regras de reparo automático 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 detectar problemas precocemente. Em seguida, o sistema pode executar automaticamente ações corretivas quando uma solicitação de verificação de integridade falhar. O balanceador de carga roteia o tráfego para longe 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 à 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 projeto
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. Estender a estratégia para 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 detectar 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.
Criar segmentação por meio de limites de isolamento para conter violação: aplique segmentação de identidade. Por exemplo, implemente o RBAC (controle de acesso baseado em função) para atribuir permissões específicas com base em funções. Siga o princípio do privilégio mínimo para limitar os direitos de acesso apenas ao necessário. Crie também segmentação no 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 a ID do Microsoft Entra para todas as necessidades de autenticação e autorização. Use funções internas, como um Colaborador de Plano Web, um Colaborador de 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 à Internet pública. Em vez disso, adicione um ponto de extremidade privado no aplicativo Web que é colocado em uma sub-rede dedicada. Lidere seu aplicativo com um proxy reverso que se comunica com esse ponto de extremidade privado. Considere usar o Gateway de Aplicativo ou o Azure Front Door para essa finalidade.
Implante um WAF (Web Application Firewall) para proteger 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 atingir o nível desejado de segurança e controle. Por exemplo, adicione regras NSG na sub-rede de ponto de extremidade privado para aceitar apenas o tráfego do proxy reverso.
O tráfego de saída do aplicativo para outros serviços de 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 evitam 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 completa de 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 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 que você não precisa. Por exemplo, desabilite 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 dos domínios, cabeçalhos e outros critérios permitidos. Aplique políticas CORS com definições de política internas do Azure.
Proteger 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 de Chaves 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.
Habilitar logs de recursos para seu aplicativo: habilite logs de recursos para seu aplicativo para criar trilhas de atividades abrangentes que forneçam dados valiosos durante investigações que se seguem a incidentes de segurança.
Considere o registro em log como parte do 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 que você se conecta com segurança ao registro de contêiner se usar contêineres para sua implantação. |
O aplicativo recupera segredos do Cofre de Chaves para autenticar a comunicação externa do aplicativo. O Azure gerencia a identidade e não exige que você provisione ou gire 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) Configurar domínios personalizados para aplicativos. Desative HTTP e aceite apenas solicitações HTTPS. |
Os domínios personalizados permitem a comunicação segura por meio de HTTPS usando o protocolo TLS (Transport Layer Security), que garante a proteção de dados confidenciais e aumenta 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 se integra 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 entrada e oferece suporte ao 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. Roteie a extração da imagem do contêiner pela 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 com segurança os recursos dentro da rede. Adicione um ponto de extremidade privado para ajudar a proteger seu aplicativo. Os pontos de extremidade privados limitam a exposição direta à rede pública e permitem o acesso controlado por meio do proxy reverso. |
| (Serviço de Aplicativo) Para implementar a proteção: - 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. - Habilitar políticas de CORS para apertar as solicitações recebidas. - Desabilitar 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) Sempre use referências do Cofre de Chaves 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 para o Serviço de Aplicativo. | Obtenha proteção em tempo real para recursos executados em um plano do Serviço de Aplicativo. Proteja-se contra ameaças e melhore 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 com suporte. | 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 se concentra em detectar padrões de gastos, priorizar investimentos em áreas críticas e otimizar 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 atingir essas metas 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 projeto
Inicie sua estratégia de design com base na lista de verificação de revisão de design para Otimização de custos para investimentos e ajuste o design 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 seu 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 opções de computação diferentes.
Monitore continuamente o modelo de custos para acompanhar os gastos.
Avalie as opções com desconto: as camadas mais altas 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 adequado à 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. Os encargos se aplicam a cada instância expandida em seu plano, com base no tempo em que você aloca a instância de VM. Preste atenção aos recursos de computação subutilizados que podem aumentar seus custos como resultado da superalocação devido à seleção de SKU abaixo do ideal ou à configuração de escalabilidade de escala 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 horizontal e dimensionamento ao implementar o dimensionamento automático. Estabeleça limites máximos e mínimos precisos no dimensionamento automático.
Inicialize proativamente o aplicativo para 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, essa estratégia pode levar à capacidade não utilizada.
Recomendamos que você combine e equilibre mecanismos para aumentar e dimensionar. Por exemplo, um aplicativo pode ser ampliado por algum tempo e, em seguida, dimensionado conforme necessário. Explore níveis altos que oferecem grande capacidade e uso eficiente de recursos. Com base nos padrões de uso, os níveis Premium mais altos geralmente são mais econômicos porque são mais capazes.
Otimize os custos do ambiente: considere a camada Básica ou Gratuita 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 carga de trabalho. Considere o uso de padrões como o padrão Backends para Frontends e o padrão de Agregação de Gateway, que podem minimizar o número de solicitações e reduzir custos.
Verifique regularmente os custos relacionados aos dados: períodos prolongados 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 do 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-verdes 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 testar completamente 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 as camadas Gratuita ou Básica para ambientes inferiores. Recomendamos essas camadas para uso experimental. Remova as camadas quando você 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 e não precisam de todos os recursos e desempenho dos planos premium. |
| (plano do Serviço de Aplicativo) Aproveite os descontos e explore os preços preferidos para: - Ambientes inferiores com planos de desenvolvimento/teste. - Reservas do Azure e planos de economia 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 que tenham 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 em que os recursos do Serviço de Aplicativo incorrem. 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 desperdícios e reduza gastos desnecessários. |
Excelência operacional
A Excelência Operacional concentra-se principalmente em procedimentos para práticas de desenvolvimento, observabilidade e gerenciamento de versões.
Os princípios de design de Excelência Operacional fornecem uma estratégia de design de alto nível para atingir esses objetivos em direção aos requisitos operacionais da carga de trabalho.
Lista de verificação de projeto
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 o aplicativo perfeitamente 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.
Executar 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 Carimbos de Implantação para compartimentar o Serviço de Aplicativo em um carimbo imutável. O Serviço de Aplicativo oferece suporte ao 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 nesse selo são temporárias e sem estado. 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 de missão crítica com o Serviço de Aplicativo.
Use uma tecnologia de infraestrutura como 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 teste antes de promover alterações na produção.
Use ambientes baixos para explorar novos recursos e configurações de maneira isolada. Mantenha os ambientes de desenvolvimento e teste efêmeros.
Gerenciar certificados: para domínios personalizados, você precisa gerenciar certificados TLS.
Tenha processos em vigor para adquirir, renovar e validar certificados. Descarregue esses processos para o Serviço de Aplicativo, se possível. Se você usar seu próprio certificado, deverá gerenciar sua renovação. Escolha uma abordagem que melhor se alinhe com seus requisitos de segurança.
| Recomendação | Benefício |
|---|---|
| (Serviço de Aplicativo) Monitore a integridade de suas instâncias e ative os testes de integridade da instância. Configure um caminho específico para lidar com solicitações de teste de integridade. |
Você pode detectar problemas prontamente e tomar as ações necessárias para manter a disponibilidade e o desempenho. |
| (Serviço de Aplicativo) Habilite 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 apresentar 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 trilha 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 do 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 de Chaves 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 detectar 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 da capacidade. A estratégia inclui dimensionar recursos, identificar e otimizar possíveis gargalos e otimizar o desempenho máximo.
Os princípios de design de Eficiência de Desempenho fornecem uma estratégia de design de alto nível para atingir essas metas de capacidade em relação ao uso esperado.
Lista de verificação de projeto
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 de entrada, o tempo que o aplicativo leva para responder a solicitações, solicitações pendentes e erros em respostas HTTP. Considere os 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 de indicadores de desempenho. Colete logs para obter insights sobre o uso de recursos e atividades. Use ferramentas de monitoramento de desempenho de aplicativo (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 criação de 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 que você só precise definir limites.
Tenha recursos suficientes prontamente disponíveis para garantir o desempenho ideal. Aloque recursos adequadamente para manter metas de desempenho, como tempo de resposta ou taxa de transferência. Considere a superalocação de recursos quando necessário.
Ao definir regras de dimensionamento automático, considere o tempo necessário para que seu aplicativo seja 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 repetidas viagens de ida e volta ao banco de dados ou back-end e reduza 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.
Antipadrão Descrição Front-end ocupado Tarefas de uso intensivo de recursos podem aumentar os tempos de resposta para solicitações de usuário e causar alta latência.
Mova os processos que consomem recursos significativos para um back-end separado. Use um agente de mensagens para enfileirar tarefas com uso intensivo de recursos que o back-end pega para processar de forma assíncrona.Sem cache Atenda às solicitações de um cache intermediário na frente do banco de dados back-end para reduzir a latência. Vizinho barulhento Sistemas multilocatários compartilham recursos entre locatários. A atividade de um locatário pode ter um efeito negativo no uso do sistema por outro locatário. 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 dispara uma inicialização 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 o HTTP/2 multiplexa totalmente as conexões, reutiliza conexões para reduzir a sobrecarga e compacta cabeçalhos para minimizar a transferência de dados. |
Compensações
Talvez seja necessário fazer compensações de design se você 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 no 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. 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 fornece melhor controle sobre a segurança e a proteção de dados, pois 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 de uma perspectiva de desempenho. O isolamento permite o dimensionamento independente com base na demanda específica e no planejamento de capacidade individual.
Como desvantagem, essa abordagem é mais cara e requer 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 para que possa processar solicitações com eficiência. Você pode provisionar recursos em excesso (instâncias pré-quentes) 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 superprovisionados custam mais. Você é cobrado por segundo para todas as instâncias, incluindo instâncias pré-aquecidas. As camadas mais altas incluem instâncias pré-aquecidas. Determine se os recursos com níveis mais caros valem o investimento.
Redundância de construção
A redundância oferece resiliência, mas também incorre em custos. Os SLOs (Objetivos de Nível de Serviço) 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 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, você 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 de 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 interna 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 desabilitados para reduzir a superfície de ataque.
Para 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 Assistente do Azure é um consultor de nuvem personalizado que ajuda a seguir as práticas recomendadas para otimizar as 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óximas etapas
Considere os artigos a seguir 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 com redundância de zona altamente disponível da linha de base.
Use a documentação do produto a seguir para criar sua experiência em implementação: