Padrão de Aplicativo Web confiável para .NET

Serviço de aplicativo do Azure

Porta da frente do Azure

Cache Redis do Azure

.NET

Este artigo fornece diretrizes para implementar o padrão de Aplicativo Web Confiável. Esse padrão descreve como modificar aplicativos Web (replatformes) para migração na nuvem. Ele fornece diretrizes de arquitetura, código e configuração prescritivas alinhadas com os princípios do do Azure Well-Architected Framework.

Por que implementar o padrão de Aplicativo Web Confiável para .NET?

O padrão de Aplicativo Web Confiável é um conjunto de princípios e técnicas de implementação que definem como você deve replatar aplicativos Web ao migre-los para a nuvem. Ele se concentra nas atualizações mínimas de código que você precisa fazer para ter sucesso na nuvem. As diretrizes a seguir usam uma implementação de referência como exemplo. As diretrizes seguem a jornada de replatforme da empresa fictícia Relecloud para fornecer contexto de negócios para sua jornada. Antes de implementar o padrão de Aplicativo Web Confiável para .NET, o Relecloud tinha um aplicativo Web de tíquete local monolítico que usava a estrutura de ASP.NET.

Dica

Há uma implementação de referência (amostra) do padrão de Aplicativo Web Confiável. Ele representa o estado final da implementação do Reliable Web App para uma empresa fictícia chamada Relecloud. Trata-se de um aplicativo Web de nível de produção que apresenta todas as atualizações de código, arquitetura e configuração discutidas neste artigo. Implante e use a implementação de referência para orientar sua implementação do padrão de Aplicativo Web Confiável.

Como implementar o padrão de Aplicativo Web Confiável

Este artigo inclui diretrizes de arquitetura, código e configuração para implementar o padrão de Aplicativo Web Confiável. Use os links a seguir para acessar as diretrizes específicas necessárias:

• Contexto comercial. Alinhar essas diretrizes com seu contexto de negócios e aprender a definir metas imediatas e de longo prazo que impulsionam decisões de replatformação.
• diretrizes de arquitetura de . Saiba como selecionar os serviços de nuvem corretos e criar uma arquitetura que atenda aos seus requisitos de negócios.
• Diretrizes de código. Implementar três padrões de design para melhorar a confiabilidade e a eficiência de desempenho do seu aplicativo Web na nuvem: os padrões de repetição, disjuntor e Cache-Aside.
• diretrizes de configuração do . Configurar autenticação e autorização, identidades gerenciadas, ambientes com direitos, infraestrutura como código e monitoramento.

Contexto de negócios

A primeira etapa para reformular um aplicativo Web é definir seus objetivos de negócios. Você deve definir metas imediatas, como objetivos de nível de serviço (SLO) e metas de otimização de custo e também metas futuras para seu aplicativo Web. Esses objetivos influenciam sua escolha de serviços de nuvem e a arquitetura do seu aplicativo Web na nuvem. Defina um SLO de destino para seu aplicativo Web, tal como 99,9% de tempo de atividade. Calcule o SLA composto para todos os serviços que afetam a disponibilidade do seu aplicativo Web.

Por exemplo, 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 do aplicativo Web:

• Aplique alterações de código de baixo custo e de alto valor.
• Alcance um SLO de 99,9%.
• Adotar práticas de DevOps.
• Crie ambientes com otimização de custo.
• Aprimore a confiabilidade e a segurança.

A infraestrutura local da Relecloud não era uma solução econômica para atingir essas metas. Eles decidiram que migrar seu aplicativo Web para o Azure era a maneira mais econômica de alcançar seus objetivos imediatos e futuros.

Diretrizes para arquitetura

O padrão Aplicativo Web Confiável tem alguns elementos arquitetônicos essenciais. Você precisa de DNS para gerenciar a resolução de ponto de extremidade, um firewall de aplicativo Web para bloquear o tráfego HTTP mal-intencionado e um balanceador de carga para rotear e ajudar a proteger solicitações de usuário de entrada. A plataforma de aplicativos hospeda seu código de aplicativo Web e faz chamadas para todos os serviços de back-end por meio de pontos de extremidade privados em uma rede virtual. Uma ferramenta de monitoramento de desempenho do aplicativo captura métricas e logs para ajudá-lo a entender seu aplicativo Web.

Figura 1. Elementos arquitetônicos essenciais do padrão de Aplicativo Web Confiável.

Criar a arquitetura

Crie sua infraestrutura para dar suporte às métricas de recuperação , como o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação). O RTO afeta a disponibilidade e deve oferecer suporte ao seu SLO. Determine um RPO e configure de redundância de dados para atender ao RPO.

• Escolha a confiabilidade da infraestrutura. Determine quantas zonas de disponibilidade e regiões você precisa para atender aos seus requisitos de disponibilidade. Adicione zonas de disponibilidade e regiões até que o SLA composto atenda ao seu SLO. O padrão de Aplicativo Web Confiável dá suporte a várias regiões para uma configuração ativa-ativa ou ativa-passiva. Por exemplo, a implementação de referência usa uma configuração ativa-passiva para atender a um SLO de 99,9%.

  Para um aplicativo Web de várias regiões, configure o balanceador de carga para rotear o tráfego para a segunda região para dar suporte a uma configuração ativa-ativa ou ativa-passiva, dependendo da sua necessidade de negócios. As duas regiões exigem os mesmos serviços, exceto que uma região tem uma rede virtual de hub que conecta as regiões. Adote uma topologia de rede hub-and-spoke para centralizar e compartilhar recursos, como um firewall de rede. Se você tiver máquinas virtuais, adicione um host bastion à rede virtual do hub para gerenciá-las com segurança aprimorada. (Ver a figura 2.)

  

  Figura 2. O padrão de Aplicativo Web Confiável com uma segunda região e uma topologia hub-and-spoke.

• Escolha uma topologia de rede. Escolha a topologia de rede certa para seus requisitos de rede e da Web. Se você planeja usar várias redes virtuais, use uma topologia de rede hub-and-spoke. Ele fornece benefícios de custo, gerenciamento e segurança e opções de conectividade híbrida para redes virtuais e locais.

Escolha os serviços Azure corretos

Ao mover um aplicativo Web para a nuvem, você deve escolher os serviços do Azure que atendem aos seus requisitos de negócios e alinhar-se com os recursos atuais do aplicativo Web local. Esse alinhamento ajuda a minimizar o esforço de replatformação. 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ções para selecionar os serviços do Azure corretos para seu aplicativo Web.

Por exemplo, antes de ser movido para a nuvem, o aplicativo Web de tíquetes do Relecloud era um aplicativo de ASP.NET monolítico local. Ele foi executado em duas máquinas virtuais e usou um banco de dados do SQL Server. O aplicativo Web sofria de problemas comuns com escalabilidade e implantação de recursos. Esse ponto de partida, suas metas de negócios e SLO impulsionaram suas escolhas de serviço.

• Plataforma de aplicativo: use o Serviço de Aplicativo do Azure como sua plataforma de aplicativo. O Relecloud escolheu o Serviço de Aplicativo como a plataforma de aplicativo pelos seguintes motivos:

  • SLA (contrato de alto nível de serviço). Ele tem um SLA alto que atende ao ambiente de produção SLO 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 dá suporte à versão do .NET na qual o aplicativo está escrito.
  • Funcionalidade de contêinerização. O aplicativo Web pode convergir na nuvem sem contêineres, mas a plataforma de aplicativos também dá suporte à contêinerização sem alterar os serviços do Azure.
  • Dimensionamento automático. O aplicativo Web pode escalar e reduzir automaticamente com base no tráfego do usuário e nas configurações. A plataforma também dá suporte a escalar verticalmente para acomodar diferentes requisitos de hospedagem.

• Gerenciamento de identidade: use o Microsoft Entra ID como sua solução de gerenciamento de identidade e acesso. O Relecloud escolheu a ID do Microsoft Entra pelos seguintes motivos:

  • Autenticação e autorização. O aplicativo precisa autenticar e autorizar funcionários do call center.
  • Escalonável. A ID do Microsoft Entra é dimensionada para dar suporte a cenários maiores.
  • Controle de identidade do usuário. Os funcionários do call center podem usar suas identidades empresariais existentes.
  • Suporte ao protocolo de autorização. A ID do Microsoft Entra dá suporte ao OAuth 2.0 para identidades gerenciadas.

• Banco de dados: use um serviço que permita usar o mesmo mecanismo de banco de dados. Use a árvore de decisão do armazenamento de dados para orientar sua seleção. O aplicativo Web da Relecloud usava o SQL Server local. Eles queriam 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:

  • Fiabilidade. A camada de uso geral fornece um SLA alto e redundância de várias regiões. Ele pode dar suporte a uma alta carga de usuário.
  • Sobrecarga de gerenciamento reduzida. O Banco de Dados SQL fornece uma instância gerenciada do banco de dados SQL.
  • Suporte à migração. Ele dá suporte à migração de banco de dados do SQL Server local.
  • Consistência com configurações locais. Ele dá suporte aos procedimentos armazenados, funções e exibições existentes.
  • Resiliência. Ele dá suporte a backups e restauração pontual.
  • Experiência e retrabalho mínimo. O Banco de Dados SQL permite que o Relecloud aproveite a experiência existente e requer um trabalho mínimo para adotar.

• monitoramento de desempenho do aplicativo: usar do Application Insights para analisar a telemetria do aplicativo. A Relecloud escolheu usar o Application Insights pelos seguintes motivos:

  • Integração com o Azure Monitor. Ele fornece a melhor integração com o Azure Monitor.
  • Detecção de anomalias. Ele detecta automaticamente anomalias de desempenho.
  • Solucionando problemas. Ele ajuda a diagnosticar problemas no aplicativo em execução.
  • Monitorização. 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 uma solução de monitoramento de desempenho do aplicativo. O Application Insights fornece fácil integração com a plataforma e o código do aplicativo.

• cache : Escolha se deseja adicionar um cache à arquitetura do aplicativo Web. Cache do Azure para Redis é a solução de cache principal do Azure. É um repositório de dados gerenciado na memória baseado no software Redis. A carga do aplicativo Web do Relecloud é fortemente distorcida para exibir shows e detalhes do local. O Relecloud adicionou o Cache do Azure para Redis pelos seguintes motivos:

  • Sobrecarga de gerenciamento reduzida. É um serviço totalmente gerenciado.
  • Velocidade e volume. Ele tem alta taxa de transferência de dados e leituras de baixa latência para dados de alteração lenta e acessados com frequência.
  • Suporte diversificado. É 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 descarregou dados altamente frequentes e não pôde invalidar dados.
  • Sessões não aderente. A externalização do estado da sessão dá suporte a sessões não aderente.

• Balanceador de carga: aplicativos Web que usam soluções de PaaS devem usar o Azure Front Door, o Gateway de Aplicativo do Azure ou ambos, dependendo da arquitetura e dos requisitos do aplicativo Web. Use a árvore de decisão do balanceador de carga para escolher o balanceador de carga certo. A Relecloud precisava de um balanceador de carga de camada 7 que pudesse rotear o tráfego em várias regiões. A empresa precisava de um aplicativo Web de várias regiões 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 entre várias regiões.
  • Firewall do aplicativo Web. Ele se integra nativamente ao Firewall do Aplicativo Web do Azure.
  • Flexibilidade de roteamento. Ele permite que a equipe de aplicativos configure as necessidades de entrada para dar suporte a alterações futuras no aplicativo.
  • Aceleração de tráfego. Ele usa o anycast para alcançar o ponto de presença mais próximo do Azure e encontrar a rota mais rápida para o aplicativo Web.
  • Domínios personalizados. Ele dá suporte a nomes de domínio personalizados com validação de domínio flexível.
  • Investigações de integridade. O aplicativo requer monitoramento de investigação de integridade inteligente. O Azure Front Door usa respostas da investigação para determinar a melhor origem para roteamento de solicitações de cliente.
  • Suporte de monitoramento. Ele dá suporte a relatórios internos com um painel all-in-one para o Azure Front Door e padrões de segurança. Você pode configurar alertas que se integram ao Azure Monitor. O Azure Front Door permite que o aplicativo registre cada solicitação e teste de integridade com falha.
  • Proteção contra DDoS. Ele tem proteção interna contra DDoS da camada 3-4.
  • Rede de distribuição de conteúdo. Ele posiciona o Relecloud para usar uma rede de distribuição de conteúdo. A rede de entrega de conteúdo fornece aceleração do site.

• Firewall de Aplicativo Web: use o Firewall de Aplicativo Web do Azure para oferecer proteção centralizada contra explorações e vulnerabilidades Web comuns. O Relecloud usa o Firewall de Aplicativo Web do Azure pelos seguintes motivos:

  • Proteção global. Ele fornece proteção de aplicativo Web global aprimorada sem sacrificar o desempenho.
  • Proteção de botnet. A equipe pode monitorar e definir configurações para resolver preocupações de segurança relacionadas a botnets.
  • Paridade com o local. A solução local estava em execução por trás de um firewall de aplicativo Web gerenciado pela TI.
  • Facilidade de uso. O Firewall do Aplicativo Web integra-se ao Azure Front Door.

• Armazenamento de configuração: escolha se deseja adicionar o armazenamento de configuração de aplicativo ao seu aplicativo Web. A Configuração de Aplicativos do Azure é um serviço para gerenciar centralmente as configurações do aplicativo e os sinalizadores de recursos. Examine as práticas recomendadas da Configuração de Aplicativos para decidir se esse serviço é uma boa opção para seu aplicativo. A Relecloud queria substituir a configuração baseada em arquivo por um repositório de configuração central que se integre à plataforma e ao código do aplicativo. Eles adicionaram a Configuração do Aplicativo à arquitetura pelos seguintes motivos:

  • Flexibilidade. Ele dá suporte a sinalizadores de recursos. Os sinalizadores de recursos permitem que os usuários optem por entrar e sair dos recursos de visualização antecipada em um ambiente de produção sem a necessidade de reimplantação de aplicativo.
  • Suporte ao pipeline do Git. A fonte da verdade para os dados de configuração precisava ser um repositório Git. O pipeline necessário para atualizar os dados no repositório de configuração central.
  • Suporte à identidade gerenciada. Ele dá suporte a identidades gerenciadas para simplificar e ajudar a proteger a conexão com o repositório de configuração.

• Gerenciador de segredos: use o Azure Key Vault se você tiver segredos para gerenciar no Azure. Você pode incorporar o Key Vault em aplicativos .NET usando o objeto ConfigurationBuilder. O aplicativo Web local do Relecloud armazena segredos em arquivos de configuração de código, mas uma prática de segurança melhor é armazenar segredos em um local que dê suporte a CONTROLES RBAC e de auditoria. Embora identidades gerenciadas sejam a solução preferencial para se conectar aos recursos do Azure, o Relecloud tinha segredos de aplicativo necessários para gerenciar. A Relecloud usou o Key Vault pelos seguintes motivos:

  • Encriptação. Ele dá suporte à criptografia em repouso e em trânsito.
  • Suporte à identidade gerenciada. Os serviços de aplicativo podem usar identidades gerenciadas para acessar o repositório de segredos.
  • Monitoramento e registro em log. O Key Vault facilita o acesso à auditoria e gera alertas quando os segredos armazenados são alterados.
  • Integração. O Key Vault fornece integração nativa com o repositório de configuração do Azure (Configuração de Aplicativos) e a plataforma de hospedagem da Web (Serviço de Aplicativo).

• solução de armazenamento: Consulte opções de armazenamento do Azure para escolher a solução de armazenamento correta com base em suas necessidades. O aplicativo Web local da Relecloud montava o armazenamento em disco em cada servidor Web, mas a equipe queria usar uma solução de armazenamento de dados externo. A Relecloud escolheu o Armazenamento do Blobs do Azure pelos seguintes motivos:

  • Acesso aprimorado à segurança. O aplicativo Web pode eliminar pontos de extremidade para acessar o armazenamento exposto à Internet pública com acesso anônimo.
  • Encriptação. O Armazenamento de Blobs criptografa dados em repouso e em trânsito.
  • Resiliência. O Armazenamento de Blobs dá suporte ao ZRS (armazenamento com redundância de zona). O armazenamento redundante 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 é um local físico separado com energia, resfriamento e rede independentes. Essa configuração deve tornar as imagens dos ingressos resilientes contra perda.

• segurança do ponto de extremidade: usar de Link Privado do Azure para acessar soluções de PaaS (plataforma como serviço) em um ponto de extremidade privado em sua rede virtual. O tráfego entre sua rede virtual e o serviço viaja PELA rede de backbone da Microsoft. A Relecloud escolheu o Link Privado pelos seguintes motivos:

  • Comunicação de segurança aprimorada. O Link Privado permite que o aplicativo acesse serviços na plataforma do Azure e reduz o volume de rede de armazenamentos de dados para ajudar a proteger contra vazamento de dados.
  • Esforço mínimo. Os pontos de extremidade privados dão suporte à plataforma de aplicativo Web e à plataforma de banco de dados que o aplicativo Web usa. Ambas as plataformas espelham as configurações locais existentes, portanto, é necessária uma alteração mínima.

• Segurança de rede. Use do Firewall do Azure para controlar o tráfego de entrada e saída no nível da rede. Use do Azure Bastion para se conectar a máquinas virtuais com segurança aprimorada, sem expor portas RDP/SSH. O 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 spokes para aumentar a segurança da rede. O Relecloud precisava do Azure Bastion para implantações de segurança aprimorada de um host de salto na sub-rede de DevOps.

Orientações de código

Para mover com êxito um aplicativo Web para a nuvem, você precisa atualizar o código do aplicativo Web com o padrão de repetição, o padrão de Disjuntor e o padrão Cache-Aside.

Figura 3. Funções dos padrões de design.

Cada padrão de design fornece benefícios de design de carga de trabalho que se alinham a um ou mais pilares do Well-Architected Framework. Esta é uma visão geral dos padrões que você deve implementar:

1. Padrão de repetição. O padrão de repetição lida com falhas transitórias repetindo operações que podem falhar intermitentemente. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

2. Padrão de disjuntor. O padrão disjuntor impede que um aplicativo repita operações que não sejam transitórias. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

3. Cache-Aside padrão. O padrão Cache-Aside carrega dados sob demanda em um cache de um armazenamento de dados. Implemente esse padrão em solicitações para o banco de dados.

Padrão de design	Confiabilidade (RE)	Segurança (SE)	Otimização de custo (CO)	Excelência operacional (OE)	Eficiência de performance (PE)	Suporte aos princípios do WAF
Padrão de repetição	✔					RE:07
de padrão do Disjuntor	✔				✔	RE:03 RE:07 PE:07 PE: 11
Cache-Aside padrão	✔				✔	RE:05 PE: 08 PE: 12

Implementar o padrão Repetição

Adicione o padrão Repetição ao código do aplicativo para lidar com interrupções temporárias de serviço. Essas interrupções são chamadas de falhas transitórias. As falhas transitórias geralmente se resolvem em alguns segundos. O padrão de repetição permite que você reenviar solicitações com falha. Ele também permite que você configure o atraso entre novas tentativas e o número de tentativas a serem realizadas antes de conceder a falha.

• Use mecanismos de repetição internos. Use o mecanismo de repetição interno que a maioria dos serviços do Azure fornece para agilizar sua implementação. Por exemplo, a implementação de referência usa resiliência de conexão no Entity Framework Core para aplicar o padrão de repetição em solicitações ao Banco de Dados SQL:

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• Use bibliotecas de programação de repetição. Para comunicações HTTP, integre uma biblioteca de resiliência padrão, como Polly ou Microsoft.Extensions.Http.Resilience. Essas bibliotecas fornecem mecanismos de repetição abrangentes que são cruciais para gerenciar comunicações com serviços Web externos. Por exemplo, a implementação de referência usa Polly para impor o padrão de repetição sempre que o código constrói um objeto que chama o objeto IConcertSearchService:

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

Implementar o padrão de disjuntor

Use o padrão Circuit-Breaker para lidar com interrupções de serviço que não são falhas transitórias. O padrão de interruptor impede que um aplicativo tente acessar continuamente um serviço que não responde. Ele libera o aplicativo e ajuda a evitar o perda de ciclos de CPU para que o aplicativo mantenha sua integridade de desempenho para os usuários finais.

Por exemplo, a implementação de referência aplica o padrão Circuit-Breaker em todas as solicitações à API. Ele usa a lógica HandleTransientHttpError para detectar solicitações HTTP que ela pode tentar novamente com segurança, mas limita o número de falhas de agregação durante um período de tempo especificado:

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Implementar o padrão Cache-Aside

Adicione o padrão Cache-Aside ao seu aplicativo Web para melhorar o gerenciamento de dados na memória. O padrão atribui ao aplicativo a responsabilidade de lidar com solicitações de dados e garantir a consistência entre o cache e o armazenamento persistente, como um banco de dados. Isso reduz os tempos de resposta, aumenta a taxa de transferência e reduz a necessidade de mais dimensionamento. Também reduz a carga no armazenamento de dados primário, o que melhora a confiabilidade e a otimização de custos. Para implementar o padrão Cache-Aside , siga estas recomendações:

• Configure o aplicativo para usar um cache. Os aplicativos de produção devem usar um cache Redis distribuído. Esse cache melhora o desempenho reduzindo as consultas de banco de dados. Ele também habilita sessões não aderente para que o balanceador de carga possa distribuir o tráfego uniformemente. A implementação de referência usa um cache Redis distribuído. O método AddAzureCacheForRedis configura o aplicativo para usar o Cache do Azure para Redis:

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• Armazene em cache dados de alta necessidade. Aplique o padrão Cache-Aside em dados de alta necessidade para aprimorar sua eficácia. Use o Azure Monitor para controlar a CPU, a memória e o armazenamento do banco de dados. Essas métricas ajudam a determinar se você pode usar um SKU de banco de dados menor depois de aplicar o padrão de Cache-Aside. Por exemplo, a implementação de referência armazena em cache os dados de alta necessidade que dão suporte à página Próximos Shows. O método GetUpcomingConcertsAsync extrai dados para o cache Redis do Banco de Dados SQL e preenche o cache com os dados de concerto mais recentes:

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

• Mantenha os dados do cache atualizados. Agende atualizações regulares de cache para sincronizar com as alterações mais recentes do banco de dados. Use a volatilidade dos dados e o usuário precisa determinar a taxa de atualização ideal. Essa prática garante que o aplicativo use o padrão Cache-Aside para fornecer acesso rápido e informações atuais. Por exemplo, a implementação de referência armazena dados em cache apenas por uma hora e usa o método CreateConcertAsync para limpar a chave de cache quando os dados são alterados:

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

• Garanta a consistência dos dados. Implemente mecanismos para atualizar o cache imediatamente após qualquer operação de gravação no banco de dados. Use atualizações orientadas a eventos ou classes de gerenciamento de dados dedicadas para garantir a coerência do cache. A sincronização consistente do cache com modificações no banco de dados é fundamental para o padrão Cache-Aside. A implementação de referência usa o método UpdateConcertAsync para manter os dados no cache consistentes:

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

Orientações de configuração

As seções a seguir fornecem diretrizes sobre como implementar as atualizações de configuração. Cada seção alinha-se a um ou mais pilares do Well-Architected Framework.

Configuração	Confiabilidade (RE)	Segurança (SE)	Otimização de custo (CO)	Excelência operacional (OE)	Eficiência de performance (PE)	Suporte aos princípios do WAF
Configure a autenticação e a autorização do usuário		✔		✔		SE:05 OE: 10
Implementar identidades gerenciadas		✔		✔		SE:05 OE: 10
Ambientes de rightsize			✔			CO:05 CO: 06
Implementar o dimensionamento automático	✔		✔		✔	RE:06 CO: 12 PE:05
Automatizar implantação de recursos				✔		OE:05
Implementar o monitoramento			✔	✔	✔	OE:07 PE: 04

Configure a autenticação e a autorização do usuário

Ao migrar aplicativos Web para o Azure, configure mecanismos de autenticação e autorização do usuário. Siga essas recomendações:

• Use uma plataforma de identidade. Use a plataforma de Identidade da Microsoft para configurar a autenticação de aplicativo Web. Essa plataforma dá suporte a aplicativos que usam um único diretório do Microsoft Entra, vários diretórios do Microsoft Entra de diferentes organizações e identidades ou contas sociais da Microsoft.

• Crie um registro de aplicativo. O Microsoft Entra ID requer um registro de aplicativo no locatário principal. O registro do aplicativo ajuda a garantir que os usuários que têm acesso ao aplicativo Web tenham identidades no locatário primário.

• Use os recursos da plataforma. Minimize a necessidade de código de autenticação personalizado usando recursos da plataforma para autenticar usuários e acessar dados. Por exemplo, Serviço de Aplicativo fornece suporte à autenticação interna, para que você possa conectar usuários e acessar dados enquanto escreve o mínimo ou nenhum código em seu aplicativo Web.

• Imponha autorização no aplicativo. Use o RBAC para atribuir privilégios mínimos a funções de aplicativo . Defina funções específicas para diferentes ações do usuário para evitar sobreposições e garantir clareza. Mapeie os usuários para as funções apropriadas e verifique se eles têm acesso apenas a recursos e ações necessários.

• Dê preferência ao acesso temporário em vez de o armazenamento. Use permissões temporárias para proteger contra acesso e violações não autorizados. Por exemplo, você pode usar sas (assinaturas de acesso compartilhado) para limitar o acesso a um período de tempo. Use a SAS de delegação de usuário para maximizar a segurança ao conceder acesso temporário. Ele é a única SAS que usa credenciais do Microsoft Entra ID e não requer uma chave de conta permanente de armazenamento.

• Imponha a autorização no Azure. Use o RBAC do Azure para atribuir privilégios mínimos às identidades de usuário. O RBAC do Azure define os recursos do Azure aos quais as identidades podem acessar, o que podem fazer com esses recursos e as áreas às quais têm acesso.

• Evite permissões elevadas permanentes. Use o Microsoft Entra Privileged Identity Management para conceder acesso just-in-time para operações privilegiadas. Por exemplo, os desenvolvedores geralmente precisam de acesso no nível do administrador para criar/excluir bancos de dados, modificar esquemas de tabela e alterar permissões de usuário. Quando você usa o acesso just-in-time, as identidades de usuário recebem permissões temporárias para executar tarefas privilegiadas.

Usar identidades gerenciadas

Use identidades gerenciadas para todos os serviços do Azure que dão suporte a elas. Uma identidade gerenciada permite que os recursos do Azure (identidades de carga de trabalho) se autentiquem e interajam com outros serviços do Azure sem exigir que você gerencie credenciais. Para simplificar a migração, você pode continuar a usar soluções de autenticação locais para sistemas híbridos e herdados, mas você deve fazer a transição para identidades gerenciadas assim que possível. Para implementar identidades gerenciadas, siga estas recomendações:

• Escolha o tipo certo de identidade gerenciada. Dê preferências a identidades gerenciadas atribuídas pelo usuário quando você tiver dois ou mais recursos do Azure que precisem do mesmo conjunto de permissões. Essa abordagem é mais eficiente do que criar identidades gerenciadas atribuídas pelo sistema para cada um desses recursos e atribuir as mesmas permissões a todos eles. Caso contrário, use identidades gerenciadas atribuídas pelo sistema

• Configure privilégios mínimos. Use rbac do Azure para conceder apenas permissões que são essenciais para operações, como ações CRUD em bancos de dados ou acesso a segredos. As permissões de identidade de carga de trabalho são persistentes, portanto, você não pode fornecer permissões just-in-time ou de curto prazo para identidades de carga de trabalho. Se o RBAC do Azure não cobrir um cenário específico, complemente o RBAC do Azure com políticas de acesso de nível de serviço do Azure.

• Forneça segurança para os segredos restantes. Armazene todos os segredos restantes no Azure Key Vault. Carregue segredos do Key Vault na inicialização do aplicativo, e não durante cada solicitação HTTP. O acesso de alta frequência em solicitações HTTP pode exceder os limites de transação do Key Vault. Armazene as configurações do aplicativo na Configuração de Aplicativos do Azure.

A implementação de referência usa o argumento Authentication na cadeia de conexão do banco de dados SQL para que o Serviço de Aplicativo possa se conectar ao banco de dados SQL usando uma identidade gerenciada: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Ele usa DefaultAzureCredential para permitir que a API Web se conecte ao Key Vault usando uma identidade gerenciada:

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Ambientes de rightsize

Use SKUs (camadas de desempenho) de serviços do Azure que atendam às necessidades de cada ambiente sem excedê-las. Para rightsize seus ambientes, siga estas recomendações:

• Estimar os custos. Use a Calculadora de Preços do Azure para estimar o custo de cada ambiente.

• Ambientes de produção com otimização de custo. Os ambientes de produção precisam de SKUs que atendam aos SLAs (Contratos de Nível de Serviço), aos recursos e à escala necessários para a produção. Monitore continuamente o uso de recursos e ajuste as SKUs para se alinhar às necessidades reais de desempenho.

• ambientes de pré-produção de otimização de custo.ambientes de pré-produção devem usar recursos de menor custo e aproveitar descontos como de preços de Desenvolvimento/Teste do Azure. Nesses ambientes, você deve desabilitar serviços que não são necessários. Ao mesmo tempo, verifique se ambientes de pré-produção são suficientemente semelhantes aos ambientes de produção para evitar a introdução de riscos. Manter esse equilíbrio garante que o teste permaneça eficaz sem incorrer em custos desnecessários.

• Use a iac (infraestrutura como código) para definir SKUs. Implemente a IaC para selecionar e implantar dinamicamente as SKUs corretas com base no ambiente. Essa abordagem aumenta a consistência e simplifica o gerenciamento.

Por exemplo, a implementação de referência usa parâmetros Bicep para implantar SKUs (camadas mais caras) no ambiente de produção:

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

Implementar o dimensionamento automático

O dimensionamento automático ajuda a garantir que um aplicativo Web permaneça resiliente, responsivo e capaz de lidar com cargas de trabalho dinâmicas com eficiência. Para implementar o dimensionamento automático, siga estas recomendações:

• Automatize a expansão. Use o dimensionamento automático do Azure para automatizar o dimensionamento horizontal em ambientes de produção. Configure regras de dimensionamento automático para escalar horizontalmente com base nas principais métricas de desempenho para que seu aplicativo possa lidar com cargas variadas.

• Refine os gatilhos de dimensionamento. Use a utilização da CPU como gatilho de dimensionamento inicial se você não estiver familiarizado com os requisitos de dimensionamento do aplicativo. Refinar os gatilhos de dimensionamento para incluir outras métricas, como RAM, taxa de transferência de rede e E/S de disco. O objetivo é corresponder ao comportamento do seu aplicativo Web para obter uma performance melhor.

• Forneça um buffer de expansão. Defina seus limites de dimensionamento para disparar antes que a capacidade máxima seja atingida. Por exemplo, configure o dimensionamento para ocorrer com 85% de utilização da CPU, em vez de esperar até atingir 100%. Essa abordagem proativa ajuda a manter o desempenho e evitar possíveis gargalos.

Automatizar implantação de recursos

Use a automação para implantar e atualizar recursos e código do Azure em todos os ambientes. Siga essas recomendações:

• Use a infraestrutura como código. Implante infraestrutura como de código usando pipelines de CI/CD (integração contínua e entrega contínua). O Azure fornece modelos Bicep, ARM (JSON) e Terraform predefinidos para cada recurso do Azure.

• Use um pipeline de integração/implantação contínua (CI/CD). Use um pipeline de CI/CD para implantar o código do controle do código-fonte em seus vários ambientes, como teste, preparo e produção. Use o Azure Pipelines se você estiver trabalhando com o Azure DevOps. Use o GitHub Actions para projetos do GitHub.

• Integre os testes de unidade. Priorize a execução e a aprovação de todos os testes de unidade em seu pipeline antes de qualquer implantação nos Serviços de Aplicativo. Incorpore ferramentas de qualidade e cobertura de código como SonarQube para alcançar uma cobertura abrangente de testes.

• Adote estruturas de zombaria. Para testes que envolvem pontos de extremidade externos, use estruturas de simulação. Essas estruturas permitem que você crie pontos de extremidade simulados. Eles eliminam a necessidade de configurar pontos de extremidade externos reais e garantem condições de teste uniformes em todos os ambientes.

• Execute varreduras de segurança. Use o SAST (teste de segurança de aplicativo estático) para encontrar falhas de segurança e erros de codificação no código-fonte. Além disso, realize a análise de composição de software (SCA) para examinar bibliotecas e componentes de terceiros quanto a riscos de segurança. As ferramentas para essas análises são fáceis de integrar ao GitHub e ao Azure DevOps.

Implementar o monitoramento

Implemente o monitoramento de aplicativos e plataformas para aprimorar a excelência operacional e a eficiência de performance do seu aplicativo Web. Para implementar o monitoramento, siga estas recomendações:

• Colete a telemetria do aplicativo. Use de autoinstrumentação no Azure Application Insights para coletar de telemetria do aplicativo, como taxa de transferência de solicitação, duração média da solicitação, erros e monitoramento de dependência. Você não precisa fazer alterações de código para usar essa telemetria.

  A implementação de referência usa AddApplicationInsightsTelemetry do pacote NuGet Microsoft.ApplicationInsights.AspNetCore para habilitar coleção de telemetria:

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• Crie métricas de aplicativo personalizadas. Use a instrumentação baseada em código para telemetria de aplicativo personalizada. Adicione o SDK do Application Insights ao seu código e use a API do Application Insights.

  A implementação de referência reúne telemetria em eventos relacionados à atividade do carrinho. this.telemetryClient.TrackEvent conta os ingressos adicionados ao carrinho. Ele fornece o nome do evento (AddToCart) e especifica um dicionário que tem o concertId e count:

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

• Monitore a plataforma. Habilite o diagnóstico para todos os serviços com suporte. Envie o diagnóstico para o mesmo destino que os logs de aplicativo para correlação. Os serviços do Azure criam logs de plataforma automaticamente, mas só os armazenam quando você habilita o diagnóstico. Habilite as configurações de diagnóstico para cada serviço que dá suporte ao diagnóstico.

Implantar a implementação de referência

A implementação de referência orienta os desenvolvedores por meio de uma migração simulada de um aplicativo ASP.NET local para o Azure, destacando as alterações necessárias durante a fase inicial de adoção. Este exemplo usa um aplicativo de venda de ingressos para shows para a empresa fictícia Relecloud, que vende ingressos por meio de seu aplicativo Web local. A Relecloud definiu as seguintes metas para seu aplicativo Web:

• Implemente alterações de código de baixo custo e de alto valor.
• Obter um SLO de 99,9%.
• Adotar práticas de DevOps.
• Crie ambientes com otimização de custo.
• Aprimore a confiabilidade e a segurança.

O Relecloud determinou que sua infraestrutura local não era uma solução econômica para atender a essas metas. Eles decidiram que a migração de seu aplicativo Web para o Azure era a maneira mais econômica de atingir suas metas imediatas e futuras. A arquitetura a seguir representa o estado final da implementação do padrão reliable web app do Relecloud.

Figura 4. Arquitetura da implementação de referência. Baixe um de arquivo do Visio dessa arquitetura.

Implementação de referência

Este artigo fornece diretrizes para implementar o padrão de Aplicativo Web Confiável. Esse padrão descreve como modificar aplicativos Web (replatformes) para migração na nuvem. Ele fornece diretrizes de arquitetura, código e configuração prescritivas alinhadas com os princípios do do Azure Well-Architected Framework.

Por que implementar o padrão de Aplicativo Web Confiável para .NET?

O padrão de Aplicativo Web Confiável é um conjunto de princípios e técnicas de implementação que definem como você deve replatar aplicativos Web ao migre-los para a nuvem. Ele se concentra nas atualizações mínimas de código que você precisa fazer para ter sucesso na nuvem. As diretrizes a seguir usam uma implementação de referência como exemplo. As diretrizes seguem a jornada de replatforme da empresa fictícia Relecloud para fornecer contexto de negócios para sua jornada. Antes de implementar o padrão de Aplicativo Web Confiável para .NET, o Relecloud tinha um aplicativo Web de tíquete local monolítico que usava a estrutura de ASP.NET.

Dica

Há uma implementação de referência (amostra) do padrão de Aplicativo Web Confiável. Ele representa o estado final da implementação do Reliable Web App para uma empresa fictícia chamada Relecloud. Trata-se de um aplicativo Web de nível de produção que apresenta todas as atualizações de código, arquitetura e configuração discutidas neste artigo. Implante e use a implementação de referência para orientar sua implementação do padrão de Aplicativo Web Confiável.

Como implementar o padrão de Aplicativo Web Confiável

Este artigo inclui diretrizes de arquitetura, código e configuração para implementar o padrão de Aplicativo Web Confiável. Use os links a seguir para acessar as diretrizes específicas necessárias:

• Contexto comercial. Alinhar essas diretrizes com seu contexto de negócios e aprender a definir metas imediatas e de longo prazo que impulsionam decisões de replatformação.
• diretrizes de arquitetura de . Saiba como selecionar os serviços de nuvem corretos e criar uma arquitetura que atenda aos seus requisitos de negócios.
• Diretrizes de código. Implementar três padrões de design para melhorar a confiabilidade e a eficiência de desempenho do seu aplicativo Web na nuvem: os padrões de repetição, disjuntor e Cache-Aside.
• diretrizes de configuração do . Configurar autenticação e autorização, identidades gerenciadas, ambientes com direitos, infraestrutura como código e monitoramento.

Contexto de negócios

A primeira etapa para reformular um aplicativo Web é definir seus objetivos de negócios. Você deve definir metas imediatas, como objetivos de nível de serviço (SLO) e metas de otimização de custo e também metas futuras para seu aplicativo Web. Esses objetivos influenciam sua escolha de serviços de nuvem e a arquitetura do seu aplicativo Web na nuvem. Defina um SLO de destino para seu aplicativo Web, tal como 99,9% de tempo de atividade. Calcule o SLA composto para todos os serviços que afetam a disponibilidade do seu aplicativo Web.

Por exemplo, 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 do aplicativo Web:

• Aplique alterações de código de baixo custo e de alto valor.
• Alcance um SLO de 99,9%.
• Adotar práticas de DevOps.
• Crie ambientes com otimização de custo.
• Aprimore a confiabilidade e a segurança.

A infraestrutura local da Relecloud não era uma solução econômica para atingir essas metas. Eles decidiram que migrar seu aplicativo Web para o Azure era a maneira mais econômica de alcançar seus objetivos imediatos e futuros.

Diretrizes para arquitetura

O padrão Aplicativo Web Confiável tem alguns elementos arquitetônicos essenciais. Você precisa de DNS para gerenciar a resolução de ponto de extremidade, um firewall de aplicativo Web para bloquear o tráfego HTTP mal-intencionado e um balanceador de carga para rotear e ajudar a proteger solicitações de usuário de entrada. A plataforma de aplicativos hospeda seu código de aplicativo Web e faz chamadas para todos os serviços de back-end por meio de pontos de extremidade privados em uma rede virtual. Uma ferramenta de monitoramento de desempenho do aplicativo captura métricas e logs para ajudá-lo a entender seu aplicativo Web.

Figura 1. Elementos arquitetônicos essenciais do padrão de Aplicativo Web Confiável.

Criar a arquitetura

Crie sua infraestrutura para dar suporte às métricas de recuperação , como o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação). O RTO afeta a disponibilidade e deve oferecer suporte ao seu SLO. Determine um RPO e configure de redundância de dados para atender ao RPO.

• Escolha a confiabilidade da infraestrutura. Determine quantas zonas de disponibilidade e regiões você precisa para atender aos seus requisitos de disponibilidade. Adicione zonas de disponibilidade e regiões até que o SLA composto atenda ao seu SLO. O padrão de Aplicativo Web Confiável dá suporte a várias regiões para uma configuração ativa-ativa ou ativa-passiva. Por exemplo, a implementação de referência usa uma configuração ativa-passiva para atender a um SLO de 99,9%.

  Para um aplicativo Web de várias regiões, configure o balanceador de carga para rotear o tráfego para a segunda região para dar suporte a uma configuração ativa-ativa ou ativa-passiva, dependendo da sua necessidade de negócios. As duas regiões exigem os mesmos serviços, exceto que uma região tem uma rede virtual de hub que conecta as regiões. Adote uma topologia de rede hub-and-spoke para centralizar e compartilhar recursos, como um firewall de rede. Se você tiver máquinas virtuais, adicione um host bastion à rede virtual do hub para gerenciá-las com segurança aprimorada. (Ver a figura 2.)

  

  Figura 2. O padrão de Aplicativo Web Confiável com uma segunda região e uma topologia hub-and-spoke.

• Escolha uma topologia de rede. Escolha a topologia de rede certa para seus requisitos de rede e da Web. Se você planeja usar várias redes virtuais, use uma topologia de rede hub-and-spoke. Ele fornece benefícios de custo, gerenciamento e segurança e opções de conectividade híbrida para redes virtuais e locais.

Escolha os serviços Azure corretos

Ao mover um aplicativo Web para a nuvem, você deve escolher os serviços do Azure que atendem aos seus requisitos de negócios e alinhar-se com os recursos atuais do aplicativo Web local. Esse alinhamento ajuda a minimizar o esforço de replatformação. 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ções para selecionar os serviços do Azure corretos para seu aplicativo Web.

Por exemplo, antes de ser movido para a nuvem, o aplicativo Web de tíquetes do Relecloud era um aplicativo de ASP.NET monolítico local. Ele foi executado em duas máquinas virtuais e usou um banco de dados do SQL Server. O aplicativo Web sofria de problemas comuns com escalabilidade e implantação de recursos. Esse ponto de partida, suas metas de negócios e SLO impulsionaram suas escolhas de serviço.

• Plataforma de aplicativo: use o Serviço de Aplicativo do Azure como sua plataforma de aplicativo. O Relecloud escolheu o Serviço de Aplicativo como a plataforma de aplicativo pelos seguintes motivos:

  • SLA (contrato de alto nível de serviço). Ele tem um SLA alto que atende ao ambiente de produção SLO 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 dá suporte à versão do .NET na qual o aplicativo está escrito.
  • Funcionalidade de contêinerização. O aplicativo Web pode convergir na nuvem sem contêineres, mas a plataforma de aplicativos também dá suporte à contêinerização sem alterar os serviços do Azure.
  • Dimensionamento automático. O aplicativo Web pode escalar e reduzir automaticamente com base no tráfego do usuário e nas configurações. A plataforma também dá suporte a escalar verticalmente para acomodar diferentes requisitos de hospedagem.

• Gerenciamento de identidade: use o Microsoft Entra ID como sua solução de gerenciamento de identidade e acesso. O Relecloud escolheu a ID do Microsoft Entra pelos seguintes motivos:

  • Autenticação e autorização. O aplicativo precisa autenticar e autorizar funcionários do call center.
  • Escalonável. A ID do Microsoft Entra é dimensionada para dar suporte a cenários maiores.
  • Controle de identidade do usuário. Os funcionários do call center podem usar suas identidades empresariais existentes.
  • Suporte ao protocolo de autorização. A ID do Microsoft Entra dá suporte ao OAuth 2.0 para identidades gerenciadas.

• Banco de dados: use um serviço que permita usar o mesmo mecanismo de banco de dados. Use a árvore de decisão do armazenamento de dados para orientar sua seleção. O aplicativo Web da Relecloud usava o SQL Server local. Eles queriam 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:

  • Fiabilidade. A camada de uso geral fornece um SLA alto e redundância de várias regiões. Ele pode dar suporte a uma alta carga de usuário.
  • Sobrecarga de gerenciamento reduzida. O Banco de Dados SQL fornece uma instância gerenciada do banco de dados SQL.
  • Suporte à migração. Ele dá suporte à migração de banco de dados do SQL Server local.
  • Consistência com configurações locais. Ele dá suporte aos procedimentos armazenados, funções e exibições existentes.
  • Resiliência. Ele dá suporte a backups e restauração pontual.
  • Experiência e retrabalho mínimo. O Banco de Dados SQL permite que o Relecloud aproveite a experiência existente e requer um trabalho mínimo para adotar.

• monitoramento de desempenho do aplicativo: usar do Application Insights para analisar a telemetria do aplicativo. A Relecloud escolheu usar o Application Insights pelos seguintes motivos:

  • Integração com o Azure Monitor. Ele fornece a melhor integração com o Azure Monitor.
  • Detecção de anomalias. Ele detecta automaticamente anomalias de desempenho.
  • Solucionando problemas. Ele ajuda a diagnosticar problemas no aplicativo em execução.
  • Monitorização. 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 uma solução de monitoramento de desempenho do aplicativo. O Application Insights fornece fácil integração com a plataforma e o código do aplicativo.

• cache : Escolha se deseja adicionar um cache à arquitetura do aplicativo Web. Cache do Azure para Redis é a solução de cache principal do Azure. É um repositório de dados gerenciado na memória baseado no software Redis. A carga do aplicativo Web do Relecloud é fortemente distorcida para exibir shows e detalhes do local. O Relecloud adicionou o Cache do Azure para Redis pelos seguintes motivos:

  • Sobrecarga de gerenciamento reduzida. É um serviço totalmente gerenciado.
  • Velocidade e volume. Ele tem alta taxa de transferência de dados e leituras de baixa latência para dados de alteração lenta e acessados com frequência.
  • Suporte diversificado. É 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 descarregou dados altamente frequentes e não pôde invalidar dados.
  • Sessões não aderente. A externalização do estado da sessão dá suporte a sessões não aderente.

• Balanceador de carga: aplicativos Web que usam soluções de PaaS devem usar o Azure Front Door, o Gateway de Aplicativo do Azure ou ambos, dependendo da arquitetura e dos requisitos do aplicativo Web. Use a árvore de decisão do balanceador de carga para escolher o balanceador de carga certo. A Relecloud precisava de um balanceador de carga de camada 7 que pudesse rotear o tráfego em várias regiões. A empresa precisava de um aplicativo Web de várias regiões 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 entre várias regiões.
  • Firewall do aplicativo Web. Ele se integra nativamente ao Firewall do Aplicativo Web do Azure.
  • Flexibilidade de roteamento. Ele permite que a equipe de aplicativos configure as necessidades de entrada para dar suporte a alterações futuras no aplicativo.
  • Aceleração de tráfego. Ele usa o anycast para alcançar o ponto de presença mais próximo do Azure e encontrar a rota mais rápida para o aplicativo Web.
  • Domínios personalizados. Ele dá suporte a nomes de domínio personalizados com validação de domínio flexível.
  • Investigações de integridade. O aplicativo requer monitoramento de investigação de integridade inteligente. O Azure Front Door usa respostas da investigação para determinar a melhor origem para roteamento de solicitações de cliente.
  • Suporte de monitoramento. Ele dá suporte a relatórios internos com um painel all-in-one para o Azure Front Door e padrões de segurança. Você pode configurar alertas que se integram ao Azure Monitor. O Azure Front Door permite que o aplicativo registre cada solicitação e teste de integridade com falha.
  • Proteção contra DDoS. Ele tem proteção interna contra DDoS da camada 3-4.
  • Rede de distribuição de conteúdo. Ele posiciona o Relecloud para usar uma rede de distribuição de conteúdo. A rede de entrega de conteúdo fornece aceleração do site.

• Firewall de Aplicativo Web: use o Firewall de Aplicativo Web do Azure para oferecer proteção centralizada contra explorações e vulnerabilidades Web comuns. O Relecloud usa o Firewall de Aplicativo Web do Azure pelos seguintes motivos:

  • Proteção global. Ele fornece proteção de aplicativo Web global aprimorada sem sacrificar o desempenho.
  • Proteção de botnet. A equipe pode monitorar e definir configurações para resolver preocupações de segurança relacionadas a botnets.
  • Paridade com o local. A solução local estava em execução por trás de um firewall de aplicativo Web gerenciado pela TI.
  • Facilidade de uso. O Firewall do Aplicativo Web integra-se ao Azure Front Door.

• Armazenamento de configuração: escolha se deseja adicionar o armazenamento de configuração de aplicativo ao seu aplicativo Web. A Configuração de Aplicativos do Azure é um serviço para gerenciar centralmente as configurações do aplicativo e os sinalizadores de recursos. Examine as práticas recomendadas da Configuração de Aplicativos para decidir se esse serviço é uma boa opção para seu aplicativo. A Relecloud queria substituir a configuração baseada em arquivo por um repositório de configuração central que se integre à plataforma e ao código do aplicativo. Eles adicionaram a Configuração do Aplicativo à arquitetura pelos seguintes motivos:

  • Flexibilidade. Ele dá suporte a sinalizadores de recursos. Os sinalizadores de recursos permitem que os usuários optem por entrar e sair dos recursos de visualização antecipada em um ambiente de produção sem a necessidade de reimplantação de aplicativo.
  • Suporte ao pipeline do Git. A fonte da verdade para os dados de configuração precisava ser um repositório Git. O pipeline necessário para atualizar os dados no repositório de configuração central.
  • Suporte à identidade gerenciada. Ele dá suporte a identidades gerenciadas para simplificar e ajudar a proteger a conexão com o repositório de configuração.

• Gerenciador de segredos: use o Azure Key Vault se você tiver segredos para gerenciar no Azure. Você pode incorporar o Key Vault em aplicativos .NET usando o objeto ConfigurationBuilder. O aplicativo Web local do Relecloud armazena segredos em arquivos de configuração de código, mas uma prática de segurança melhor é armazenar segredos em um local que dê suporte a CONTROLES RBAC e de auditoria. Embora identidades gerenciadas sejam a solução preferencial para se conectar aos recursos do Azure, o Relecloud tinha segredos de aplicativo necessários para gerenciar. A Relecloud usou o Key Vault pelos seguintes motivos:

  • Encriptação. Ele dá suporte à criptografia em repouso e em trânsito.
  • Suporte à identidade gerenciada. Os serviços de aplicativo podem usar identidades gerenciadas para acessar o repositório de segredos.
  • Monitoramento e registro em log. O Key Vault facilita o acesso à auditoria e gera alertas quando os segredos armazenados são alterados.
  • Integração. O Key Vault fornece integração nativa com o repositório de configuração do Azure (Configuração de Aplicativos) e a plataforma de hospedagem da Web (Serviço de Aplicativo).

• solução de armazenamento: Consulte opções de armazenamento do Azure para escolher a solução de armazenamento correta com base em suas necessidades. O aplicativo Web local da Relecloud montava o armazenamento em disco em cada servidor Web, mas a equipe queria usar uma solução de armazenamento de dados externo. A Relecloud escolheu o Armazenamento do Blobs do Azure pelos seguintes motivos:

  • Acesso aprimorado à segurança. O aplicativo Web pode eliminar pontos de extremidade para acessar o armazenamento exposto à Internet pública com acesso anônimo.
  • Encriptação. O Armazenamento de Blobs criptografa dados em repouso e em trânsito.
  • Resiliência. O Armazenamento de Blobs dá suporte ao ZRS (armazenamento com redundância de zona). O armazenamento redundante 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 é um local físico separado com energia, resfriamento e rede independentes. Essa configuração deve tornar as imagens dos ingressos resilientes contra perda.

• segurança do ponto de extremidade: usar de Link Privado do Azure para acessar soluções de PaaS (plataforma como serviço) em um ponto de extremidade privado em sua rede virtual. O tráfego entre sua rede virtual e o serviço viaja PELA rede de backbone da Microsoft. A Relecloud escolheu o Link Privado pelos seguintes motivos:

  • Comunicação de segurança aprimorada. O Link Privado permite que o aplicativo acesse serviços na plataforma do Azure e reduz o volume de rede de armazenamentos de dados para ajudar a proteger contra vazamento de dados.
  • Esforço mínimo. Os pontos de extremidade privados dão suporte à plataforma de aplicativo Web e à plataforma de banco de dados que o aplicativo Web usa. Ambas as plataformas espelham as configurações locais existentes, portanto, é necessária uma alteração mínima.

• Segurança de rede. Use do Firewall do Azure para controlar o tráfego de entrada e saída no nível da rede. Use do Azure Bastion para se conectar a máquinas virtuais com segurança aprimorada, sem expor portas RDP/SSH. O 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 spokes para aumentar a segurança da rede. O Relecloud precisava do Azure Bastion para implantações de segurança aprimorada de um host de salto na sub-rede de DevOps.

Orientações de código

Para mover com êxito um aplicativo Web para a nuvem, você precisa atualizar o código do aplicativo Web com o padrão de repetição, o padrão de Disjuntor e o padrão Cache-Aside.

Figura 3. Funções dos padrões de design.

Cada padrão de design fornece benefícios de design de carga de trabalho que se alinham a um ou mais pilares do Well-Architected Framework. Esta é uma visão geral dos padrões que você deve implementar:

1. Padrão de repetição. O padrão de repetição lida com falhas transitórias repetindo operações que podem falhar intermitentemente. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

2. Padrão de disjuntor. O padrão disjuntor impede que um aplicativo repita operações que não sejam transitórias. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

3. Cache-Aside padrão. O padrão Cache-Aside carrega dados sob demanda em um cache de um armazenamento de dados. Implemente esse padrão em solicitações para o banco de dados.

Padrão de design	Confiabilidade (RE)	Segurança (SE)	Otimização de custo (CO)	Excelência operacional (OE)	Eficiência de performance (PE)	Suporte aos princípios do WAF
Padrão de repetição	✔					RE:07
de padrão do Disjuntor	✔				✔	RE:03 RE:07 PE:07 PE: 11
Cache-Aside padrão	✔				✔	RE:05 PE: 08 PE: 12

Implementar o padrão Repetição

Adicione o padrão Repetição ao código do aplicativo para lidar com interrupções temporárias de serviço. Essas interrupções são chamadas de falhas transitórias. As falhas transitórias geralmente se resolvem em alguns segundos. O padrão de repetição permite que você reenviar solicitações com falha. Ele também permite que você configure o atraso entre novas tentativas e o número de tentativas a serem realizadas antes de conceder a falha.

• Use mecanismos de repetição internos. Use o mecanismo de repetição interno que a maioria dos serviços do Azure fornece para agilizar sua implementação. Por exemplo, a implementação de referência usa resiliência de conexão no Entity Framework Core para aplicar o padrão de repetição em solicitações ao Banco de Dados SQL:

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• Use bibliotecas de programação de repetição. Para comunicações HTTP, integre uma biblioteca de resiliência padrão, como Polly ou Microsoft.Extensions.Http.Resilience. Essas bibliotecas fornecem mecanismos de repetição abrangentes que são cruciais para gerenciar comunicações com serviços Web externos. Por exemplo, a implementação de referência usa Polly para impor o padrão de repetição sempre que o código constrói um objeto que chama o objeto IConcertSearchService:

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

Implementar o padrão de disjuntor

Use o padrão Circuit-Breaker para lidar com interrupções de serviço que não são falhas transitórias. O padrão de interruptor impede que um aplicativo tente acessar continuamente um serviço que não responde. Ele libera o aplicativo e ajuda a evitar o perda de ciclos de CPU para que o aplicativo mantenha sua integridade de desempenho para os usuários finais.

Por exemplo, a implementação de referência aplica o padrão Circuit-Breaker em todas as solicitações à API. Ele usa a lógica HandleTransientHttpError para detectar solicitações HTTP que ela pode tentar novamente com segurança, mas limita o número de falhas de agregação durante um período de tempo especificado:

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Implementar o padrão Cache-Aside

Adicione o padrão Cache-Aside ao seu aplicativo Web para melhorar o gerenciamento de dados na memória. O padrão atribui ao aplicativo a responsabilidade de lidar com solicitações de dados e garantir a consistência entre o cache e o armazenamento persistente, como um banco de dados. Isso reduz os tempos de resposta, aumenta a taxa de transferência e reduz a necessidade de mais dimensionamento. Também reduz a carga no armazenamento de dados primário, o que melhora a confiabilidade e a otimização de custos. Para implementar o padrão Cache-Aside , siga estas recomendações:

• Configure o aplicativo para usar um cache. Os aplicativos de produção devem usar um cache Redis distribuído. Esse cache melhora o desempenho reduzindo as consultas de banco de dados. Ele também habilita sessões não aderente para que o balanceador de carga possa distribuir o tráfego uniformemente. A implementação de referência usa um cache Redis distribuído. O método AddAzureCacheForRedis configura o aplicativo para usar o Cache do Azure para Redis:

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• Armazene em cache dados de alta necessidade. Aplique o padrão Cache-Aside em dados de alta necessidade para aprimorar sua eficácia. Use o Azure Monitor para controlar a CPU, a memória e o armazenamento do banco de dados. Essas métricas ajudam a determinar se você pode usar um SKU de banco de dados menor depois de aplicar o padrão de Cache-Aside. Por exemplo, a implementação de referência armazena em cache os dados de alta necessidade que dão suporte à página Próximos Shows. O método GetUpcomingConcertsAsync extrai dados para o cache Redis do Banco de Dados SQL e preenche o cache com os dados de concerto mais recentes:

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

• Mantenha os dados do cache atualizados. Agende atualizações regulares de cache para sincronizar com as alterações mais recentes do banco de dados. Use a volatilidade dos dados e o usuário precisa determinar a taxa de atualização ideal. Essa prática garante que o aplicativo use o padrão Cache-Aside para fornecer acesso rápido e informações atuais. Por exemplo, a implementação de referência armazena dados em cache apenas por uma hora e usa o método CreateConcertAsync para limpar a chave de cache quando os dados são alterados:

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

• Garanta a consistência dos dados. Implemente mecanismos para atualizar o cache imediatamente após qualquer operação de gravação no banco de dados. Use atualizações orientadas a eventos ou classes de gerenciamento de dados dedicadas para garantir a coerência do cache. A sincronização consistente do cache com modificações no banco de dados é fundamental para o padrão Cache-Aside. A implementação de referência usa o método UpdateConcertAsync para manter os dados no cache consistentes:

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

Orientações de configuração

As seções a seguir fornecem diretrizes sobre como implementar as atualizações de configuração. Cada seção alinha-se a um ou mais pilares do Well-Architected Framework.

Configuração	Confiabilidade (RE)	Segurança (SE)	Otimização de custo (CO)	Excelência operacional (OE)	Eficiência de performance (PE)	Suporte aos princípios do WAF
Configure a autenticação e a autorização do usuário		✔		✔		SE:05 OE: 10
Implementar identidades gerenciadas		✔		✔		SE:05 OE: 10
Ambientes de rightsize			✔			CO:05 CO: 06
Implementar o dimensionamento automático	✔		✔		✔	RE:06 CO: 12 PE:05
Automatizar implantação de recursos				✔		OE:05
Implementar o monitoramento			✔	✔	✔	OE:07 PE: 04

Configure a autenticação e a autorização do usuário

Ao migrar aplicativos Web para o Azure, configure mecanismos de autenticação e autorização do usuário. Siga essas recomendações:

• Use uma plataforma de identidade. Use a plataforma de Identidade da Microsoft para configurar a autenticação de aplicativo Web. Essa plataforma dá suporte a aplicativos que usam um único diretório do Microsoft Entra, vários diretórios do Microsoft Entra de diferentes organizações e identidades ou contas sociais da Microsoft.

• Crie um registro de aplicativo. O Microsoft Entra ID requer um registro de aplicativo no locatário principal. O registro do aplicativo ajuda a garantir que os usuários que têm acesso ao aplicativo Web tenham identidades no locatário primário.

• Use os recursos da plataforma. Minimize a necessidade de código de autenticação personalizado usando recursos da plataforma para autenticar usuários e acessar dados. Por exemplo, Serviço de Aplicativo fornece suporte à autenticação interna, para que você possa conectar usuários e acessar dados enquanto escreve o mínimo ou nenhum código em seu aplicativo Web.

• Imponha autorização no aplicativo. Use o RBAC para atribuir privilégios mínimos a funções de aplicativo . Defina funções específicas para diferentes ações do usuário para evitar sobreposições e garantir clareza. Mapeie os usuários para as funções apropriadas e verifique se eles têm acesso apenas a recursos e ações necessários.

• Dê preferência ao acesso temporário em vez de o armazenamento. Use permissões temporárias para proteger contra acesso e violações não autorizados. Por exemplo, você pode usar sas (assinaturas de acesso compartilhado) para limitar o acesso a um período de tempo. Use a SAS de delegação de usuário para maximizar a segurança ao conceder acesso temporário. Ele é a única SAS que usa credenciais do Microsoft Entra ID e não requer uma chave de conta permanente de armazenamento.

• Imponha a autorização no Azure. Use o RBAC do Azure para atribuir privilégios mínimos às identidades de usuário. O RBAC do Azure define os recursos do Azure aos quais as identidades podem acessar, o que podem fazer com esses recursos e as áreas às quais têm acesso.

• Evite permissões elevadas permanentes. Use o Microsoft Entra Privileged Identity Management para conceder acesso just-in-time para operações privilegiadas. Por exemplo, os desenvolvedores geralmente precisam de acesso no nível do administrador para criar/excluir bancos de dados, modificar esquemas de tabela e alterar permissões de usuário. Quando você usa o acesso just-in-time, as identidades de usuário recebem permissões temporárias para executar tarefas privilegiadas.

Usar identidades gerenciadas

Use identidades gerenciadas para todos os serviços do Azure que dão suporte a elas. Uma identidade gerenciada permite que os recursos do Azure (identidades de carga de trabalho) se autentiquem e interajam com outros serviços do Azure sem exigir que você gerencie credenciais. Para simplificar a migração, você pode continuar a usar soluções de autenticação locais para sistemas híbridos e herdados, mas você deve fazer a transição para identidades gerenciadas assim que possível. Para implementar identidades gerenciadas, siga estas recomendações:

• Escolha o tipo certo de identidade gerenciada. Dê preferências a identidades gerenciadas atribuídas pelo usuário quando você tiver dois ou mais recursos do Azure que precisem do mesmo conjunto de permissões. Essa abordagem é mais eficiente do que criar identidades gerenciadas atribuídas pelo sistema para cada um desses recursos e atribuir as mesmas permissões a todos eles. Caso contrário, use identidades gerenciadas atribuídas pelo sistema

• Configure privilégios mínimos. Use rbac do Azure para conceder apenas permissões que são essenciais para operações, como ações CRUD em bancos de dados ou acesso a segredos. As permissões de identidade de carga de trabalho são persistentes, portanto, você não pode fornecer permissões just-in-time ou de curto prazo para identidades de carga de trabalho. Se o RBAC do Azure não cobrir um cenário específico, complemente o RBAC do Azure com políticas de acesso de nível de serviço do Azure.

• Forneça segurança para os segredos restantes. Armazene todos os segredos restantes no Azure Key Vault. Carregue segredos do Key Vault na inicialização do aplicativo, e não durante cada solicitação HTTP. O acesso de alta frequência em solicitações HTTP pode exceder os limites de transação do Key Vault. Armazene as configurações do aplicativo na Configuração de Aplicativos do Azure.

A implementação de referência usa o argumento Authentication na cadeia de conexão do banco de dados SQL para que o Serviço de Aplicativo possa se conectar ao banco de dados SQL usando uma identidade gerenciada: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Ele usa DefaultAzureCredential para permitir que a API Web se conecte ao Key Vault usando uma identidade gerenciada:

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Ambientes de rightsize

Use SKUs (camadas de desempenho) de serviços do Azure que atendam às necessidades de cada ambiente sem excedê-las. Para rightsize seus ambientes, siga estas recomendações:

• Estimar os custos. Use a Calculadora de Preços do Azure para estimar o custo de cada ambiente.

• Ambientes de produção com otimização de custo. Os ambientes de produção precisam de SKUs que atendam aos SLAs (Contratos de Nível de Serviço), aos recursos e à escala necessários para a produção. Monitore continuamente o uso de recursos e ajuste as SKUs para se alinhar às necessidades reais de desempenho.

• ambientes de pré-produção de otimização de custo.ambientes de pré-produção devem usar recursos de menor custo e aproveitar descontos como de preços de Desenvolvimento/Teste do Azure. Nesses ambientes, você deve desabilitar serviços que não são necessários. Ao mesmo tempo, verifique se ambientes de pré-produção são suficientemente semelhantes aos ambientes de produção para evitar a introdução de riscos. Manter esse equilíbrio garante que o teste permaneça eficaz sem incorrer em custos desnecessários.

• Use a iac (infraestrutura como código) para definir SKUs. Implemente a IaC para selecionar e implantar dinamicamente as SKUs corretas com base no ambiente. Essa abordagem aumenta a consistência e simplifica o gerenciamento.

Por exemplo, a implementação de referência usa parâmetros Bicep para implantar SKUs (camadas mais caras) no ambiente de produção:

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

Implementar o dimensionamento automático

O dimensionamento automático ajuda a garantir que um aplicativo Web permaneça resiliente, responsivo e capaz de lidar com cargas de trabalho dinâmicas com eficiência. Para implementar o dimensionamento automático, siga estas recomendações:

• Automatize a expansão. Use o dimensionamento automático do Azure para automatizar o dimensionamento horizontal em ambientes de produção. Configure regras de dimensionamento automático para escalar horizontalmente com base nas principais métricas de desempenho para que seu aplicativo possa lidar com cargas variadas.

• Refine os gatilhos de dimensionamento. Use a utilização da CPU como gatilho de dimensionamento inicial se você não estiver familiarizado com os requisitos de dimensionamento do aplicativo. Refinar os gatilhos de dimensionamento para incluir outras métricas, como RAM, taxa de transferência de rede e E/S de disco. O objetivo é corresponder ao comportamento do seu aplicativo Web para obter uma performance melhor.

• Forneça um buffer de expansão. Defina seus limites de dimensionamento para disparar antes que a capacidade máxima seja atingida. Por exemplo, configure o dimensionamento para ocorrer com 85% de utilização da CPU, em vez de esperar até atingir 100%. Essa abordagem proativa ajuda a manter o desempenho e evitar possíveis gargalos.

Automatizar implantação de recursos

Use a automação para implantar e atualizar recursos e código do Azure em todos os ambientes. Siga essas recomendações:

• Use a infraestrutura como código. Implante infraestrutura como de código usando pipelines de CI/CD (integração contínua e entrega contínua). O Azure fornece modelos Bicep, ARM (JSON) e Terraform predefinidos para cada recurso do Azure.

• Use um pipeline de integração/implantação contínua (CI/CD). Use um pipeline de CI/CD para implantar o código do controle do código-fonte em seus vários ambientes, como teste, preparo e produção. Use o Azure Pipelines se você estiver trabalhando com o Azure DevOps. Use o GitHub Actions para projetos do GitHub.

• Integre os testes de unidade. Priorize a execução e a aprovação de todos os testes de unidade em seu pipeline antes de qualquer implantação nos Serviços de Aplicativo. Incorpore ferramentas de qualidade e cobertura de código como SonarQube para alcançar uma cobertura abrangente de testes.

• Adote estruturas de zombaria. Para testes que envolvem pontos de extremidade externos, use estruturas de simulação. Essas estruturas permitem que você crie pontos de extremidade simulados. Eles eliminam a necessidade de configurar pontos de extremidade externos reais e garantem condições de teste uniformes em todos os ambientes.

• Execute varreduras de segurança. Use o SAST (teste de segurança de aplicativo estático) para encontrar falhas de segurança e erros de codificação no código-fonte. Além disso, realize a análise de composição de software (SCA) para examinar bibliotecas e componentes de terceiros quanto a riscos de segurança. As ferramentas para essas análises são fáceis de integrar ao GitHub e ao Azure DevOps.

Implementar o monitoramento

Implemente o monitoramento de aplicativos e plataformas para aprimorar a excelência operacional e a eficiência de performance do seu aplicativo Web. Para implementar o monitoramento, siga estas recomendações:

• Colete a telemetria do aplicativo. Use de autoinstrumentação no Azure Application Insights para coletar de telemetria do aplicativo, como taxa de transferência de solicitação, duração média da solicitação, erros e monitoramento de dependência. Você não precisa fazer alterações de código para usar essa telemetria.

  A implementação de referência usa AddApplicationInsightsTelemetry do pacote NuGet Microsoft.ApplicationInsights.AspNetCore para habilitar coleção de telemetria:

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• Crie métricas de aplicativo personalizadas. Use a instrumentação baseada em código para telemetria de aplicativo personalizada. Adicione o SDK do Application Insights ao seu código e use a API do Application Insights.

  A implementação de referência reúne telemetria em eventos relacionados à atividade do carrinho. this.telemetryClient.TrackEvent conta os ingressos adicionados ao carrinho. Ele fornece o nome do evento (AddToCart) e especifica um dicionário que tem o concertId e count:

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

• Monitore a plataforma. Habilite o diagnóstico para todos os serviços com suporte. Envie o diagnóstico para o mesmo destino que os logs de aplicativo para correlação. Os serviços do Azure criam logs de plataforma automaticamente, mas só os armazenam quando você habilita o diagnóstico. Habilite as configurações de diagnóstico para cada serviço que dá suporte ao diagnóstico.

Implantar a implementação de referência

A implementação de referência orienta os desenvolvedores por meio de uma migração simulada de um aplicativo ASP.NET local para o Azure, destacando as alterações necessárias durante a fase inicial de adoção. Este exemplo usa um aplicativo de venda de ingressos para shows para a empresa fictícia Relecloud, que vende ingressos por meio de seu aplicativo Web local. A Relecloud definiu as seguintes metas para seu aplicativo Web:

• Implemente alterações de código de baixo custo e de alto valor.
• Obter um SLO de 99,9%.
• Adotar práticas de DevOps.
• Crie ambientes com otimização de custo.
• Aprimore a confiabilidade e a segurança.

O Relecloud determinou que sua infraestrutura local não era uma solução econômica para atender a essas metas. Eles decidiram que a migração de seu aplicativo Web para o Azure era a maneira mais econômica de atingir suas metas imediatas e futuras. A arquitetura a seguir representa o estado final da implementação do padrão reliable web app do Relecloud.

Figura 4. Arquitetura da implementação de referência. Baixe um de arquivo do Visio dessa arquitetura.

Implementação de referência