Padrão de Aplicativo Web confiável para Java

Este artigo fornece orientações sobre como implementar o padrão de Aplicativo Web Confiável. Esse padrão descreve como modificar (reformular) aplicativos Web para migração para a nuvem. Ele oferece arquitetura prescritiva, código e orientações de configuração alinhadas com os princípios do Well-Architected Framework.

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

O padrão de Aplicativo Web confiável é um conjunto de princípios e técnicas de implementação que definem como você deve reformular aplicativos Web 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. As orientações a seguir usam a implementação de referência como exemplo e seguem a jornada de replataforma da empresa fictícia, Contoso Fiber, para fornecer contexto de negócios para sua jornada. Antes de implementar o padrão de Aplicativo Web Confiável para Java, a Contoso Fiber tinha um Sistema de Gerenciamento de Conta de Cliente (CAMS) monolítico e local que usava a estrutura Spring Boot.

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

Este artigo inclui orientações de arquitetura, código e configuração para implementar o padrão de Aplicativo Web Confiável. Use os links a seguir para navegar até as orientações específicas de que você precisa:

• Contexto de negócios: alinhe essas orientações com seu contexto de negócios e saiba como definir metas imediatas e de longo prazo que orientam as decisões de mudança de plataforma.
• Orientações de arquitetura: saiba como selecionar os serviços de nuvem certos e projetar uma arquitetura que atenda aos seus requisitos de negócios.
• Orientações de código: implemente três padrões de design para melhorar a confiabilidade e a eficiência de desempenho do seu aplicativo Web na nuvem: padrões Repetição, Circuit-Breaker e Cache-Aside
• Orientações de configuração: configure autenticação e autorização, identidades gerenciadas, ambientes do tamanho correto, 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 e metas de otimização de custos, além de 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 Contoso Fiber, queria expandir seu aplicativo Web CAMS (Sistema de gerenciamento de conta de cliente) local para alcançar outras regiões. Para atender ao aumento da demanda no aplicativo Web, eles estabeleceram as seguintes metas:

• Aplicar alterações de código de baixo custo e de alto valor
• Atingir um objetivo de nível de serviço (SLO) de 99,9%
• Adotar práticas de DevOps
• Criar ambientes com otimização de custo
• Melhorar a confiabilidade e a segurança

A Contoso Fiber determinou que sua infraestrutura local não era uma solução econômica para dimensionar o aplicativo. Então, eles decidiram que migrar seu aplicativo Web CAMS para o Azure era a maneira mais econômica de atingir seus objetivos imediatos e futuros.

Diretrizes para arquitetura

O padrão Aplicativo Web Confiável tem alguns elementos arquitetônicos essenciais. Você precisa do DNS para gerenciar a resolução do ponto de extremidade, um firewall do aplicativo Web para bloquear o tráfego HTTP mal-intencionado e um balanceador de carga para proteger e rotear solicitações de usuário de entrada. A plataforma de aplicativo hospeda o código do 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 performance de aplicativos captura métricas e logs para entender seu aplicativo Web.

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

Criar a arquitetura

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

• Escolha a confiabilidade da infraestrutura. Determine quantas zonas de disponibilidade e regiões você precisa para atender às suas necessidades 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%.

  Adote uma topologia de rede hub-and-spoke para centralizar e compartilhar recursos, como um firewall de rede. As duas regiões exigem os mesmos serviços, mas 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 (consulte 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ê pretende ter várias redes virtuais, use uma topologia de rede hub-spoke. Ela fornece benefícios de custo, gerenciamento e segurança com opções de conectividade híbrida para redes locais e virtuais.

Escolha os serviços Azure corretos

Ao migrar um aplicativo Web para a nuvem, você deve selecionar os serviços do Azure que atendam aos seus requisitos de negócios e se alinhem aos 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ções para selecionar os serviços do Azure corretos para seu aplicativo Web.

Por exemplo, antes de migrar para a nuvem, o aplicativo Web CAMS da Contoso Fiber era um aplicativo Web Java monolítico local. É um aplicativo Spring Boot com um banco de dados PostgreSQL. O aplicativo Web é um aplicativo de suporte de linha de negócios. Ele é voltado para os funcionários. Os funcionários da Contoso Fiber usam o aplicativo para gerenciar casos de suporte de seus clientes. O aplicativo Web sofria com desafios comuns em 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. A Contoso Fiber escolheu o Serviço de Aplicativo do Azure como a plataforma de aplicativo pelos seguintes motivos:

  • Progressão natural: a Contoso Fiber implantou um arquivo Spring Boot jar em seu servidor local e queria minimizar a quantidade de rearquitetura para esse modelo de implantação. O Serviço de Aplicativo fornece suporte robusto para executar aplicativos Spring Boot e foi uma progressão natural para a Contoso Fiber usar o Serviço de Aplicativo. Os Aplicativos de Contêiner do Azure também são uma alternativa interessante a esse aplicativo. Para obter mais informações, consulte O que são Aplicativos Spring do Azure? e Visão geral do Java em Aplicativos de Contêiner do Azure.
  • Alto SLA: oferece um alto SLA que atende aos requisitos do ambiente de produção.
  • Redução da sobrecarga de gerenciamento: é uma solução de hospedagem totalmente gerenciada.
  • Capacidade de conteinerização: o Serviço de Aplicativo funciona com registros de imagem de contêiner privado, como o Registro de Contêiner do Azure. A Contoso Fiber pode usar esses registros para conteinerizar o aplicativo Web no futuro.
  • Dimensionamento automático: o aplicativo Web pode escalar verticalmente e reduzir rapidamente com base no tráfego do usuário.

• Gerenciamento de identidade: use o Microsoft Entra ID como sua solução de gerenciamento de identidade e acesso. A Contoso Fiber escolheu o Microsoft Entra ID pelos seguintes motivos:

  • Autenticação e autorização: o aplicativo precisa autenticar e autorizar os funcionários do Call Center.
  • Escalonável: ele é dimensionado 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: oferece suporte a 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 de armazenamento de dados. A Contoso Fiber escolheu o Banco de Dados do Azure para PostgreSQL e a opção de servidor flexível pelos seguintes motivos:

  • Confiabilidade: o modelo de implantação de servidor flexível oferece suporte à alta disponibilidade com redundância de zona em várias zonas de disponibilidade. Essa configuração mantém um servidor em espera passiva em uma zona de disponibilidade diferente dentro da mesma região do Azure. A configuração replica os dados de forma síncrona para o servidor em espera.
  • Replicação entre regiões: ele tem um recurso de réplica de leitura que permite replicar dados de forma assíncrona para um banco de dados de réplica somente leitura em outra região.
  • Performance: ele fornece desempenho previsível e ajuste inteligente para melhorar o desempenho do banco de dados utilizando dados de uso real.
  • Redução na sobrecarga de gerenciamento: é um serviço do Azure totalmente gerenciado que reduz as obrigações de gerenciamento.
  • Suporte de migração: oferece suporte à migração de banco de dados PostgreSQL de servidor único local. Eles podem usar a ferramenta de migração para simplificar o processo de migração.
  • Consistência com configurações locais: ele oferece suporte a diferentes versões da comunidade do PostgreSQL, incluindo a versão que a Contoso Fiber atualmente usa.
  • Resiliência. A implantação de servidor flexível cria automaticamente backups de servidor e os armazena usando ZRS (armazenamento com redundância de zona) na mesma região. Eles podem restaurar seu banco de dados para qualquer momento dentro do período de retenção de backup. O recurso de backup e restauração cria um RPO (quantidade aceitável de perda de dados) melhor do que a Contoso Fiber poderia criar localmente.

• Monitoramento de performance do aplicativo: use o Application Insights para analisar a telemetria no seu aplicativo. A Contoso Fiber 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: detecta automaticamente anomalias de desempenho.
  • Solução de problemas: ele ajuda a diagnosticar problemas no aplicativo 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 solução de monitoramento de desempenho de aplicativo. O Application Insights fornece 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 do Azure para Redis é a principal solução de cache do Azure. É um armazenamento de dados na memória gerenciado com base no software Redis. A Contoso Fiber adicionou o Cache do Azure para Redis pelos seguintes motivos:

  • Velocidade e volume: tem alta taxa de transferência de dados e leituras de baixa latência para dados de alteração lenta e comumente acessados.
  • Suporte diversificado: é um local de cache unificado que todas as instâncias do aplicativo Web podem usar.
  • 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 autoadesivas: o cache permite que o aplicativo Web externalize o estado da sessão e use sessões não adesivas. A maioria dos aplicativos Web Java em execução no local usa cache do lado do cliente na memória. Na memória, o cache do lado do cliente não é bem dimensionado e aumenta o volume de memória no host. Usando o Cache do Azure para Redis, a Contoso Fiber tem um serviço de cache escalonável e totalmente gerenciado para melhorar a escalabilidade e o desempenho de seus aplicativos. A Contoso Fiber estava usando uma estrutura de abstração de cache (Spring Cache) e só precisava de alterações mínimas de configuração para trocar o provedor de cache. Isso permitiu que eles mudassem de um provedor Ehcache para o provedor Redis.

• Balanceador de carga: os aplicativos Web que usam soluções de PaaS devem usar o Azure Front Door, o Gateway de Aplicativo do Azure ou ambos com base na arquitetura e nos requisitos do aplicativo Web. Use a árvore de decisão do balanceador de carga para escolher o balanceador de carga certo. A Contoso Fiber precisava de um balanceador de carga de camada 7 que pudesse rotear o tráfego em várias regiões. A Contoso Fiber precisava de um aplicativo Web multirregião para atender ao SLO de 99,9%. A Contoso Fiber 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: 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 precisa de 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 ao monitoramento: ele oferece suporte a relatórios integrados com um painel completo para Front Door 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 teste de integridade com falha.
  • Proteção contra DDoS: ele tem proteção interna contra DDoS da camada 3-4.
  • Rede de entrega de conteúdo: posiciona a Contoso Fiber para usar uma rede de entrega 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. A Contoso Fiber 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 contra botnet: a equipe pode monitorar e configurar definições para resolver preocupações de segurança relacionadas a botnets.
  • Paridade com o local: a solução local estava sendo executada atrás de um firewall do aplicativo Web gerenciado pela TI.
  • Facilidade de uso: o Firewall de Aplicativo Web se integra ao Azure Front Door.

• Gerenciador de segredos: use o Azure Key Vault se você tiver segredos para gerenciar no Azure. A Contoso Fiber usou o Key Vault pelos seguintes motivos:

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

• Segurança de ponto de extremidade: o Link Privado do Azure permite acessar soluções de 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 Contoso Fiber escolheu o Link Privado pelos seguintes motivos:

  • Comunicação de segurança aprimorada: 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 oferecem 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 para alteração mínima.

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

Orientações de código

Para mover um aplicativo Web para a nuvem com êxito, é necessário atualizar o código do aplicativo Web com o padrão Repetição, o padrão Circuit-Breaker e o padrão de design Cache-Aside.

Figura 3. Papel 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 Repetição: o padrão 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 Circuit-Breaker: o padrão Circuit-Breaker impede que um aplicativo repita operações que não são transitórias. Implemente esse padrão em todas as chamadas de saída para outros serviços do Azure.

3. Padrão Cache-Aside: o padrão Cache-Aside adiciona e recupera dados de um cache com mais frequência que um repositório de dados. Implemente esse padrão em solicitações para o banco de dados.

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 Repetição permite que você reenvie solicitações com falha. Ele também permite que você configure os atrasos da solicitação e o número de tentativas antes que a falha seja concedida.

Use Resilience4j, uma biblioteca leve e de tolerância a falhas, para implementar o padrão de repetição em Java. Por exemplo, a implementação de referência adiciona o padrão de Repetição decorando o método listServicePlans do Controlador de Plano de Serviço com anotações de repetição. O código tentará novamente a chamada para uma lista de planos de serviço do banco de dados se a chamada inicial falhar. A implementação de referência configura a política de repetição incluindo tentativas máximas, duração da espera e quais exceções devem ser repetidas. A política de repetição é configurada em application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

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 evita o desperdício de ciclos de CPU para que o aplicativo mantenha sua integridade de desempenho para os usuários finais.

Use a documentação Spring Circuit Breaker e Resilience4j para implementar o padrão Circuit-Breaker. Por exemplo, a implementação de referência implementa o padrão de Circuit Breaker decorando métodos com o atributo de Circuit Breaker.

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 manipular solicitações de dados e garantir a consistência entre o cache e um 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. Isso também reduz a carga no armazenamento de dados primário, melhorando a confiabilidade e a otimização de custos. Para implementar o padrão Cache-Aside , siga estas recomendações:

• Configure um aplicativo para usar um cache. Para habilitar o cache, adicione o spring-boot-starter-cache pacote como uma dependência no arquivo pom.xml. Este pacote fornece configurações padrão para o Cache Redis.

• Armazene em cache dados de alta necessidade. Aplique o padrão Cache-Aside em dados de alta necessidade para ampliar 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 Cache-Aside. Para armazenar dados específicos no cache do seu código, adicione a anotação @Cacheable. Essa anotação informa ao Spring os resultados de quais métodos devem ser armazenados em cache.

• Mantenha os dados do cache atualizados. Agende atualizações regulares de cache para sincronizar com as alterações mais recentes do banco de dados. Determine a taxa de atualização ideal com base na volatilidade dos dados e nas necessidades do usuário. Essa prática garante que o aplicativo use o padrão Cache-Aside para fornecer acesso rápido e informações atuais. As configurações de cache padrão podem não se adequar ao seu aplicativo Web. É possível personalizar essas configurações no arquivo application.properties ou nas variáveis de ambiente. Por exemplo, você pode modificar o valor spring.cache.redis.time-to-live (expresso em milissegundos) para controlar por quanto tempo os dados devem permanecer no cache antes de serem removidos.

• 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.

Orientações de configuração

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

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.

  O Spring Boot Starter para Microsoft Entra ID simplifica esse processo, utilizando o Spring Security e o Spring Boot para facilitar a configuração. Ele oferece fluxos de autenticação variados, gerenciamento automático de tokens e políticas de autorização personalizáveis, junto com recursos de integração com componentes do Spring Cloud. Isso permite a integração direta do Microsoft Entra ID e do OAuth 2.0 a aplicativos Spring Boot sem biblioteca manual ou definição de configurações.

  Por exemplo, a implementação de referência usa a plataforma de identidade da Microsoft (Microsoft Entra ID) como o provedor de identidade para o aplicativo Web. Ele usa a concessão de código de autorização OAuth 2.0 para fazer logon em um usuário com uma conta do Microsoft Entra. O snippet XML a seguir define as duas dependências necessárias do fluxo de concessão de código de autorização do OAuth 2.0. A dependência com.azure.spring: spring-cloud-azure-starter-active-directory habilita a autenticação e autorização do Microsoft Entra em um aplicativo Spring Boot. A dependência org.springframework.boot: spring-boot-starter-oauth2-client oferece suporte à autenticação e autorização do OAuth 2.0 em um aplicativo Spring Boot.

  <dependency>
      <groupid>com.azure.spring</groupid>
      <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
  </dependency>
  <dependency>
      <groupid>org.springframework.boot</groupid>
      <artifactid>spring-boot-starter-oauth2-client</artifactid>
  </dependency>
  

• Criar um registro de aplicativo. O Microsoft Entra ID requer um registro de aplicativo no locatário principal. O registro do aplicativo garante que os usuários que obtêm acesso ao aplicativo Web tenham identidades no locatário principal. Por exemplo, a implementação de referência usa o Terraform para criar um registro de aplicativo do Microsoft Entra ID junto com uma função de Gerente de Contas específica do aplicativo.

  resource "azuread_application" "app_registration" {
    display_name     = "${azurecaf_name.app_service.result}-app"
    owners           = [data.azuread_client_config.current.object_id]
    sign_in_audience = "AzureADMyOrg"  # single tenant
  
    app_role {
      allowed_member_types = ["User"]
      description          = "Account Managers"
      display_name         = "Account Manager"
      enabled              = true
      id                   = random_uuid.account_manager_role_id.result
      value                = "AccountManager"
    }
  }
  

• Imponha autorização no aplicativo. Use RBAC (controles de acesso baseados em função) para atribuir privilégios mínimos às 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 garanta que eles tenham acesso somente aos recursos e ações necessários. Configure o Spring Security para usar o Spring Boot Starter para Microsoft Entra ID. Essa biblioteca permite a integração com o Microsoft Entra ID e ajuda a garantir que os usuários sejam autenticados com segurança. A configuração e a habilitação da Microsoft Authentication Library (MSAL) dão acesso a mais recursos de segurança. Esses recursos incluem cache de token e atualização automática de token.

  Por exemplo, a implementação de referência cria funções de aplicativo que refletem os tipos de funções de usuário no sistema de gerenciamento de contas da Contoso Fiber. As funções são convertidas em permissões durante a autorização. Exemplos de funções específicas do aplicativo no CAMS incluem o gerente de conta, o representante de suporte de nível um (L1) e o representante do Field Service. A função de Gerente de Contas tem permissões para adicionar novos usuários e clientes do aplicativo. Um representante do Field Service pode criar tíquetes de suporte. O atributo PreAuthorize restringe o acesso a funções específicas.

      @GetMapping("/new")
      @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
      public String newAccount(Model model) {
          if (model.getAttribute("account") == null) {
              List<ServicePlan> servicePlans = accountService.findAllServicePlans();
              ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
              NewAccountRequest accountFormData = new NewAccountRequest();
              accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
              model.addAttribute("account", accountFormData);
              model.addAttribute("servicePlans", servicePlans);
          }
          model.addAttribute("servicePlans", accountService.findAllServicePlans());
          return "pages/account/new";
      }
      ...
  

  Para integrar com o Microsoft Entra ID, a implementação de referência usa o fluxo de concessão de código de autorização do OAuth 2.0. Esse fluxo permite que um usuário entre com uma conta da Microsoft. O snippet de código a seguir mostra como configurar o SecurityFilterChain para usar o Microsoft Entra ID para autenticação e autorização.

  @Configuration(proxyBeanMethods = false)
  @EnableWebSecurity
  @EnableMethodSecurity
  public class AadOAuth2LoginSecurityConfig {
      @Bean
      SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
          http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
              .and()
                  .authorizeHttpRequests()
              .requestMatchers(EndpointRequest.to("health")).permitAll()
              .anyRequest().authenticated()
              .and()
                  .logout(logout -> logout
                              .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                              .clearAuthentication(true)
                              .invalidateHttpSession(true));
          return http.build();
      }
  }
  ...
  

• Dê preferência ao acesso temporário em vez de o armazenamento. Use permissões temporárias para proteger contra acesso não autorizado e violações, tais como AACs (assinaturas de acesso compartilhado). Use as AACs 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 determina quais implantes do Azure as identidades podem acessar, o que elas podem fazer com esses recursos e a quais áreas elas 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. Com o acesso just-in-time, as identidades de usuário recebem permissões temporárias para realizar tarefas privilegiadas.

Implementar identidades gerenciadas

Use identidades gerenciadas para todos os serviços do Azure que dão suporte a identidades gerenciadas. Uma identidade gerenciada permite que os implantes do Azure (identidades de carga de trabalho) sejam autenticadas e interajam com outros serviços do Azure sem gerenciar credenciais. Os sistemas híbridos e herdados podem manter soluções de autenticação local para simplificar a migração, mas precisam fazer a transição para identidades gerenciadas o mais rápido 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 configuração é mais eficiente do que criar identidades gerenciadas atribuídas pelo sistema para cada um desses implantes e atribuir as mesmas permissões a todas elas. Caso contrário, use identidades gerenciadas atribuídas pelo sistema

• Configure privilégios mínimos. Use o RBAC do Azure para conceder somente as permissões críticas para as 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.

• Proteja 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.

Ambientes do tamanho certo

Use os níveis de desempenho (SKUs) dos serviços do Azure que atendem às necessidades de cada ambiente sem excesso. Para dimensionar corretamente seus ambientes, siga estas recomendações:

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

• Otimize os custos dos ambientes de produção. 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.

• Otimize custos de ambientes de pré-produção. Os ambientes de pré-produção devem usar implantes de custo mais baixo, desativar serviços desnecessários e aplicar descontos, tais como Preço de Desenvolvimento/Teste do Azure. Certifique-se de que os ambientes de pré-produção sejam suficientemente semelhantes à produção para evitar a introdução de riscos. Esse equilíbrio garante que os testes permaneçam eficazes sem incorrer em custos desnecessários.

• Defina SKUs usando infraestrutura como código (IaC). 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 tem um parâmetro opcional que implanta SKUs diferentes. Um parâmetro de ambiente instrui o modelo Terraform a selecionar SKUs de desenvolvimento.

azd env set APP_ENVIRONMENT prod

Implementar o dimensionamento automático

O dimensionamento automático garante 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 expansão com base nas principais métricas de desempenho, para que seu aplicativo possa lidar com cargas variadas.

• Refine os gatilhos de dimensionamento. Comece pela utilização de CPU como seu gatilho de dimensionamento inicial caso você não esteja familiarizado com os requisitos de dimensionamento do seu aplicativo. Refine seus gatilhos de dimensionamento para que incluam 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 de atingir a capacidade máxima. 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 a infraestrutura como código por meio de pipelines de CI/CD (integração contínua e entrega contínua). O Azure pré-definiu o Bicep, ARM (JSON) e Terraform para cada implante 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. Utilize o Azure Pipelines se estiver trabalhando com o Azure DevOps ou as Ações do GitHub 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 a estrutura de simulação. Para testes envolvendo pontos de extremidade externos, utilize 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. Utilize o teste de segurança de aplicativo estático (SAST) para encontrar falhas de segurança e erros de codificação em seu 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 prontamente integradas ao GitHub e ao Azure DevOps.

Configurar 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 a instrumentação automática no Azure Application Insights para coletar telemetria de aplicativos, como taxa de transferência de solicitação, duração média da solicitação, erros e monitoramento de dependência, sem alterações de código. O Spring Boot registra várias métricas principais no Application Insights, como Java virtual machine (JVM), CPU, Tomcat e outros. O Application Insights coleta automaticamente de estruturas de registro como Log4j e Logback. Por exemplo, a implementação de referência usa o Application Insights habilitado por meio do Terraform como parte da configuração do app_settings Serviço de Aplicativo. (consulte o seguinte código).

  app_settings = {
      APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
      ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
      ...
  }
  

  Para saber mais, veja:

  • Configurar o Application Insights do Azure Monitor para Spring Boot
  • Application Insights do Azure Monitor para Java
  • Habilite o Azure Monitor OpenTelemetry para aplicativos Java
  • Usar o Application Insights do Azure Monitor com o Spring Boot

• Crie métricas de aplicativo personalizadas. Implemente a instrumentação baseada em código para capturar a telemetria de aplicativo personalizada adicionando o SDK do Application Insights e usando sua API.

• Monitore a plataforma. Habilite o diagnóstico para todos os serviços compatíveis e envie diagnósticos para o mesmo destino que os logs do 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. A implementação de referência usa o Terraform para habilitar o diagnóstico do Azure em todos os serviços com suporte. O código Terraform a seguir define as configurações de diagnóstico para o Serviço de Aplicativo.

  # Configure Diagnostic Settings for App Service
  resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
    name                           = "app-service-diagnostic-settings"
    target_resource_id             = azurerm_linux_web_app.application.id
    log_analytics_workspace_id     = var.log_analytics_workspace_id
    #log_analytics_destination_type = "AzureDiagnostics"
  
    enabled_log {
      category_group = "allLogs"
  
    }
  
    metric {
      category = "AllMetrics"
      enabled  = true
    }
  }
  

Implantar a implementação de referência

A implementação de referência orienta os desenvolvedores por meio da simulação de uma migração de um aplicativo Java local para o Azure, destacando as alterações necessárias durante a fase inicial de adoção. Este exemplo usa um aplicativo Web de CAMs (Sistema de Gerenciamento de Conta de Cliente) para a empresa fictícia Contoso Fiber. A Contoso Fiber definiu as seguintes metas para seu aplicativo Web:

• Implementar alterações de código de baixo custo e de alto valor
• Realizar um objetivo de nível de serviço (SLO) de 99,9%
• Adotar práticas de DevOps
• Criar ambientes com otimização de custo
• Aprimorar a confiabilidade e a segurança

A Contoso Fiber determinou que sua infraestrutura local não era uma solução econômica para atender a esses objetivos. Eles decidiram que migrar seu aplicativo Web CAMS para o Azure era a maneira mais econômica de atingir seus objetivos imediatos e futuros. A seguinte arquitetura representa o estado final da implementação do padrão do Aplicativo Web Confiável da Contoso Fiber.

Figura 4: arquitetura da implementação de referência. Faça download de um Arquivo Visio dessa arquitetura.