Editar

Padrão confiável de aplicativo Web para .NET - Planejar a implementação

Azure App Service
Azure Front Door
Azure Cache for Redis
.NET

Este artigo mostra como aplicar o padrão Reliable Web App. O padrão Reliable Web App é um conjunto de princípios e técnicas de implementação que definem como você deve modificar aplicativos Web (replataforma) ao migrar para a nuvem. Ele se concentra nas atualizações mínimas de código que você precisa fazer para ter sucesso na nuvem.

Para facilitar a aplicação dessas diretrizes, há uma implementação de referência do padrão Reliable Web App que você pode implantar.

Diagrama mostrando a arquitetura da implementação de referência.Arquitetura da implementação de referência. Baixe um arquivo Visio desta arquitetura.

As orientações a seguir usam a implementação de referência como um exemplo em todo o texto. Para planejar uma implementação do padrão Reliable Web App, siga estas etapas:

Definir objetivos de negócio

O passo inicial na transição para a computação em nuvem é articular seus objetivos de negócios. O padrão Reliable Web App enfatiza a importância de definir objetivos imediatos e futuros para seu aplicativo Web. Estes objetivos influenciam a sua escolha de serviços na nuvem e a arquitetura da sua aplicação Web na nuvem.

Exemplo: A empresa fictícia Relecloud vende bilhetes através da sua aplicação Web no local. A Relecloud tem uma previsão de vendas positiva e antecipa o aumento da demanda em seu aplicativo web de emissão de ingressos. Para atender a essa demanda, eles definiram as metas para a aplicação web:

  • Aplique alterações de código de baixo custo e alto valor
  • Atingir um objetivo de nível de serviço (SLO) de 99,9%
  • Adote práticas de DevOps
  • Crie ambientes otimizados em termos de custos
  • Melhorar a fiabilidade e a segurança

A infraestrutura local do Relecloud não era uma solução econômica para atingir esses objetivos. Então, eles decidiram que migrar seu aplicativo Web para o Azure era a maneira mais econômica de alcançar seus objetivos imediatos e futuros.

Escolha os serviços gerenciados certos

Ao mover um aplicativo Web para a nuvem, você deve selecionar os serviços do Azure que atendem aos seus requisitos de negócios e se alinham com os recursos atuais do aplicativo Web local. O alinhamento ajuda a minimizar o esforço de replataforma. Por exemplo, use serviços que permitem manter o mesmo mecanismo de banco de dados e oferecer suporte a middleware e estruturas existentes. As seções a seguir fornecem orientação para selecionar os serviços do Azure certos para seu aplicativo Web.

Exemplo: Antes da mudança para a nuvem, o aplicativo Web de emissão de tíquetes do Relecloud era um aplicativo local, monolítico e ASP.NET. Ele era executado em duas máquinas virtuais e tinha um banco de dados Microsoft SQL Server. O aplicativo Web sofreu desafios comuns em escalabilidade e implantação de recursos. Esse ponto de partida, seus objetivos de negócios e SLO impulsionaram suas escolhas de serviço.

Plataforma de aplicação

Escolha a melhor plataforma de hospedagem de aplicativos para seu aplicativo web. O Azure tem muitas opções de computação diferentes para atender a uma variedade de requisitos de aplicativos Web. Para obter ajuda com opções de estreitamento, consulte a árvore de decisão de computação do Azure.

Exemplo: a Relecloud escolheu o Serviço de Aplicativo do Azure como a plataforma de aplicativo pelos seguintes motivos:

  • Acordo de alto nível de serviço (SLA): Possui um SLA alto que atende ao SLO do ambiente de produção de 99,9%.

  • Sobrecarga de gerenciamento reduzida: é uma solução totalmente gerenciada que lida com dimensionamento, verificações de integridade e balanceamento de carga.

  • Suporte ao .NET: Ele suporta a versão do .NET na qual o aplicativo está escrito.

  • Capacidade de conteinerização: o aplicativo Web pode convergir para a nuvem sem contentorização, mas a plataforma de aplicativo também oferece suporte à conteinerização sem alterar os serviços do Azure

  • Dimensionamento automático: o aplicativo Web pode ser dimensionado automaticamente, para baixo, para dentro e para fora com base no tráfego e nas configurações do usuário.

Gestão de identidades

Escolha a melhor solução de gerenciamento de identidade para seu aplicativo Web. Para obter mais informações, consulte comparar soluções de gerenciamento de identidade e métodos de autenticação.

Exemplo: Relecloud escolheu o Microsoft Entra ID pelos seguintes motivos:

  • Autenticação e autorização: O aplicativo precisa autenticar e autorizar funcionários de call center.

  • Escalável: é dimensionado para suportar cenários maiores.

  • Controle de identidade do usuário: os funcionários do call center podem usar suas identidades corporativas existentes.

  • Suporte ao protocolo de autorização: Ele suporta OAuth 2.0 para identidades gerenciadas.

Base de Dados

Escolha o melhor banco de dados para seu aplicativo Web. Para obter ajuda com o estreitamento das opções, consulte a árvore de decisão do repositório de dados do Azure.

Exemplo: O aplicativo Web usava o SQL Server local e o Relecloud queria usar o esquema de banco de dados, os procedimentos armazenados e as funções existentes. Vários produtos SQL estão disponíveis no Azure, mas a Relecloud escolheu o Banco de Dados SQL do Azure pelos seguintes motivos:

  • Confiabilidade: A camada de uso geral fornece um SLA alto e redundância de várias regiões. Ele pode suportar uma alta carga de usuário.

  • Sobrecarga de gerenciamento reduzida: fornece uma instância de banco de dados SQL gerenciada.

  • Suporte à migração: ele oferece suporte à migração de banco de dados do SQL Server local.

  • Consistência com configurações locais: Ele suporta os procedimentos armazenados, funções e exibições existentes.

  • Resiliência: Suporta backups e restauração point-in-time.

  • Experiência e retrabalho mínimo: o Banco de dados SQL aproveita a experiência interna e requer trabalho mínimo para ser adotado.

Monitoramento de desempenho de aplicativos

Escolha um monitoramento de desempenho de aplicativo para seu aplicativo Web. O Application Insights é a solução de gerenciamento de desempenho de aplicativos (APM) nativa do Azure. É um recurso da solução de monitoramento do Azure, o Azure Monitor.

Exemplo: a Relecloud escolheu usar o Application Insights pelos seguintes motivos:

  • Integração com o Azure Monitor: fornece a melhor integração com o Azure Monitor.

  • Deteção de anomalias: Deteta automaticamente anomalias de desempenho.

  • Resolução de problemas: ajuda-o a diagnosticar problemas na aplicação em execução.

  • Monitoramento: Ele coleta informações sobre como os usuários estão usando o aplicativo e permite que você acompanhe facilmente eventos personalizados.

  • Lacuna de visibilidade: a solução local não tinha a solução de monitoramento de desempenho de aplicativos. O Application Insights oferece fácil integração com a plataforma e o código do aplicativo.

Cache

Escolha se deseja adicionar cache à arquitetura do seu aplicativo Web. O Cache Redis do Azure é a principal solução de cache do Azure. É um armazenamento de dados gerenciado na memória baseado no software Redis.

Exemplo: a carga do aplicativo Web do Relecloud é fortemente enviesada para a visualização de shows e detalhes do local. Ele adicionou o Cache Redis do Azure pelos seguintes motivos:

  • Despesas gerais de gerenciamento reduzidas: é um serviço totalmente gerenciado.

  • Velocidade e volume: Possui alta taxa de transferência de dados e leituras de baixa latência para dados comumente acessados e de mudança lenta.

  • Capacidade de suporte diversificada: é um local de cache unificado para todas as instâncias do aplicativo Web usarem.

  • Armazenamento de dados externo: os servidores de aplicativos locais executaram o cache local da VM. Essa configuração não descarregava dados muito frequentados e não podia invalidar dados.

  • Sessões não aderentes: a externalização do estado da sessão suporta sessões não aderentes.

Balanceador de carga

Escolha o melhor balanceador de carga para seu aplicativo Web. O Azure tem vários balanceadores de carga. Para obter ajuda com o estreitamento das opções, consulte Escolher o melhor balanceador de carga para seu aplicativo.

Exemplo: o Relecloud precisava de um balanceador de carga de camada 7 que pudesse rotear o tráfego em várias regiões. A Relecloud precisava de um aplicativo Web multirregião para atender ao SLO de 99,9%. A Relecloud escolheu o Azure Front Door pelos seguintes motivos:

  • Balanceamento de carga global: é um balanceador de carga de camada 7 que pode rotear o tráfego em várias regiões.

  • Firewall de aplicativo Web: ele se integra nativamente ao Firewall de Aplicativo Web do Azure.

  • Flexibilidade de roteamento: Permite que a equipe do aplicativo configure as necessidades de entrada para suportar alterações futuras no aplicativo.

  • Aceleração de tráfego: usa anycast para chegar ao ponto de presença do Azure mais próximo e encontrar a rota mais rápida para o aplicativo Web.

  • Domínios personalizados: Suporta nomes de domínio personalizados com validação de domínio flexível.

  • Sondas de integridade: o aplicativo precisa de monitoramento inteligente de sonda de integridade. O Azure Front Door usa respostas da sonda para determinar a melhor origem para rotear solicitações de clientes.

  • Suporte de monitoramento: Ele suporta relatórios integrados com um painel tudo-em-um para portas frontais e padrões de segurança. Você pode configurar alertas que se integram ao Azure Monitor. Ele permite que o aplicativo registre cada solicitação e testes de integridade com falha.

  • Proteção contra DDoS: Possui proteção contra DDoS de camada 3-4 integrada.

  • Rede de entrega de conteúdo: Posiciona a Relecloud para usar uma rede de entrega de conteúdo. A rede de entrega de conteúdo fornece aceleração do site.

Firewall de aplicações Web

Escolha um firewall de aplicativo Web para proteger seu aplicativo Web contra ataques da Web. O Azure Web Application Firewall (WAF) é o firewall de aplicativos Web do Azure e fornece proteção centralizada contra vulnerabilidades e explorações da Web comuns.

Exemplo: o Relecloud é necessário para proteger o aplicativo Web contra ataques da Web. Eles usaram o Firewall de Aplicativo Web do Azure pelos seguintes motivos:

  • Proteção global: fornece proteção aprimorada de aplicativos Web globais sem sacrificar o desempenho.

  • Proteção contra botnets: a equipe pode monitorar e configurar para resolver problemas de segurança de botnets.

  • Paridade com o local: a solução local estava sendo executada atrás de um firewall de aplicativo Web gerenciado pela TI.

  • Facilidade de uso: o Web Application Firewall integra-se ao Azure Front Door.

Armazenamento de configuração

Escolha se deseja adicionar armazenamento de configuração de aplicativo ao seu aplicativo Web. A Configuração de Aplicativo do Azure é um serviço para gerenciar centralmente configurações de aplicativos e sinalizadores de recursos. Analise as práticas recomendadas de Configuração do Aplicativo para decidir se esse serviço é adequado para seu aplicativo.

Exemplo: o Relecloud queria substituir a configuração baseada em arquivo por um armazenamento de configuração central que se integrasse à plataforma e ao código do aplicativo. Eles adicionaram a Configuração do Aplicativo à arquitetura pelos seguintes motivos:

  • Flexibilidade: Suporta sinalizadores de funcionalidades. Os sinalizadores de recursos permitem que os usuários aceitem e desativem os recursos de visualização antecipada em um ambiente de produção sem reimplantar o aplicativo.

  • Suporta pipeline Git: A fonte da verdade para os dados de configuração precisava ser um repositório Git. O pipeline precisava atualizar os dados no repositório de configuração central.

  • Suporta identidades gerenciadas: Ele suporta identidades gerenciadas para simplificar e ajudar a proteger a conexão com o repositório de configuração.

Gestor de segredos

Use o Azure Key Vault se tiver segredos para gerenciar no Azure. Você pode incorporar o Cofre da Chave em aplicativos .NET usando o objeto ConfigurationBuilder.

Exemplo: o aplicativo Web local do Relecloud armazenava segredos em arquivos de configuração de código, mas é uma prática de segurança melhor externalizar segredos. Embora as identidades gerenciadas sejam a solução preferida para se conectar aos recursos do Azure, o Relecloud tinha segredos de aplicativos que precisavam gerenciar. A Relecloud usou o Key Vault pelos seguintes motivos:

  • Encriptação: Suporta encriptação em repouso e em trânsito.

  • Identidades gerenciadas: os serviços de aplicativos podem usar identidades gerenciadas para acessar o armazenamento secreto.

  • Monitoramento e registro: facilita o acesso à auditoria e gera alertas quando os segredos armazenados mudam.

  • Integração: fornece integração nativa com o repositório de configuração do Azure (Configuração do Aplicativo) e a plataforma de hospedagem na Web (Serviço de Aplicativo).

Solução de armazenamento

Escolha a melhor solução de armazenamento para seu aplicativo Web. Para obter mais informações, consulte Revisar suas opções de armazenamento.

Exemplo: No local, o aplicativo Web tinha armazenamento em disco montado em cada servidor Web, mas a equipe queria usar uma solução externa de armazenamento de dados. A Relecloud escolheu o Armazenamento de Blobs do Azure pelos seguintes motivos:

  • Acesso seguro: o aplicativo Web pode eliminar pontos de extremidade para acessar o armazenamento exposto à Internet pública com acesso anônimo.

  • Encriptação: encripta dados em repouso e em trânsito.

  • Resiliência: suporta armazenamento com redundância de zona (ZRS). O armazenamento com redundância de zona replica dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade está em um local físico separado que tem energia, resfriamento e rede independentes. Essa configuração deve tornar as imagens de tíquete resilientes contra perdas.

Segurança de pontos finais

Escolha habilitar o acesso privado somente aos serviços do Azure. O Azure Private Link fornece acesso a soluções de plataforma como serviço através de um ponto de extremidade privado na sua rede virtual. O tráfego entre a sua rede virtual e o serviço viaja através da rede de backbone da Microsoft.

Exemplo: o Relecloud usou o Private Link pelos seguintes motivos:

  • Comunicação de segurança aprimorada: permite que o aplicativo acesse serviços de forma privada na plataforma Azure e reduz a pegada de rede dos armazenamentos de dados para ajudar a proteger contra vazamento de dados.

  • Esforço mínimo: os endpoints privados suportam a plataforma de aplicativo Web e a plataforma de banco de dados que o aplicativo Web usa. Ambas as plataformas espelham as configurações locais existentes para alterações mínimas.

Segurança da rede

Escolha se deseja adicionar serviços de segurança de rede às suas redes virtuais. O Firewall do Azure é um firewall de rede com monitoração de estado que inspeciona o tráfego de rede. O Azure Bastion permite que você se conecte a máquinas virtuais com segurança sem expor portas RDP/SSH.

Exemplo: a Relecloud adotou uma topologia de rede hub and spoke e queria colocar serviços de segurança de rede compartilhados no hub. O Firewall do Azure melhora a segurança inspecionando todo o tráfego de saída dos raios para aumentar a segurança da rede. O Relecloud precisava do Azure Bastion para implantações seguras de um host de salto na sub-rede DevOps.

Escolha a arquitetura certa

Depois de definir o que significa disponível para seu aplicativo Web e selecionar os melhores serviços de nuvem, você precisa determinar a melhor arquitetura para seu aplicativo Web. Sua arquitetura precisa dar suporte aos requisitos de negócios, requisitos técnicos e SLO.

Escolher redundância de arquitetura

As metas de negócios determinam o nível de infraestrutura e redundância de dados de que seu aplicativo Web precisa. O SLO do aplicativo Web fornece uma boa linha de base para entender seus requisitos de redundância. Calcule o SLA composto todas as dependências no caminho crítico de disponibilidade. As dependências devem incluir serviços do Azure e soluções que não sejam da Microsoft.

Atribua uma estimativa de disponibilidade para cada dependência. Os contratos de nível de serviço (SLAs) fornecem um bom ponto de partida, mas os SLAs não levam em conta o código, as estratégias de implantação e as decisões de conectividade de arquitetura.

Exemplo: o Relecloud identificou os serviços no caminho crítico de disponibilidade. Eles usaram SLAs do Azure para estimativas de disponibilidade. Com base no cálculo do SLA composto, a Relecloud precisava de uma arquitetura multirregião para atender ao SLO de 99,9%.

Escolha uma topologia de rede

Escolha a topologia de rede certa para seus requisitos da Web e de rede. Uma topologia de rede hub e spoke é a configuração padrão no Azure. Ele oferece benefícios de custo, gerenciamento e segurança. Ele também suporta opções de conectividade híbrida para redes locais.

Exemplo: a Relecloud escolheu uma topologia de rede hub and spoke para aumentar a segurança de sua implantação em várias regiões com custo reduzido e sobrecarga de gerenciamento.

Escolher redundância de dados

Garanta a confiabilidade dos dados distribuindo-os pelas regiões e zonas de disponibilidade do Azure; quanto maior for a sua separação geográfica, maior será a fiabilidade.

  • Defina um RPO (Recovery Point Objetive, objetivo de ponto de recuperação). O RPO define a perda máxima tolerável de dados durante uma interrupção, orientando a frequência com que os dados precisam de replicação. Por exemplo, um RPO de uma hora significa aceitar até uma hora de perda de dados recente.

  • Implemente a replicação de dados. Alinhe a replicação de dados com sua arquitetura e RPO. O Azure normalmente dá suporte à replicação síncrona em zonas de disponibilidade. Utilize várias zonas para melhorar a confiabilidade facilmente. Para aplicativos Web de várias regiões em uma configuração ativo-passivo, replique dados para a região passiva de acordo com o RPO do aplicativo Web, garantindo que a frequência de replicação supere o RPO. As configurações ativo-ativo exigem sincronização de dados quase em tempo real entre regiões, o que pode exigir ajustes de código.

  • Crie um plano de failover. Desenvolva um plano de failover (recuperação de desastres) descrevendo estratégias de resposta a interrupções, determinadas por tempo de inatividade ou perda de funcionalidade. Especifique os objetivos de tempo de recuperação (RTO) para o tempo de inatividade máximo aceitável. Verifique se o processo de failover é mais rápido do que o RTO. Decida sobre mecanismos de failover automatizados ou manuais para consistência e controle e detalhe o processo de retorno às operações normais. Teste o plano de failover para garantir a eficácia.

Próximo passo

Este artigo mostrou como planejar uma implementação do padrão Reliable Web App. A próxima etapa é aplicar as técnicas de implementação do padrão Reliable Web App.