Compartilhar via


Padrão de aplicativo Web confiável para Java

Este artigo fornece diretrizes para implementar o padrão de Aplicativo Web Confiável. Esse padrão descreve como replatar aplicativos Web para migração na nuvem. Ele fornece diretrizes de arquitetura, código e configuração prescritivas que se alinham aos princípios do Azure Well-Architected Framework.

Por que usar 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 replatar aplicativos Web quando você os migra para a nuvem. Ele enfatiza atualizações mínimas de código para garantir o sucesso na nuvem. Essa orientação usa uma implementação de referência como um exemplo consistente por toda parte. Segue a jornada de replatformação da empresa fictícia Contoso Fiber para fornecer contexto de negócios para sua própria migração. Antes da Contoso Fiber implementar o padrão de Aplicativo Web Confiável para Java, ele opera um CAMS (Sistema de Gerenciamento de Conta de Cliente) monolítico local criado com a estrutura spring boot.

Dica

Logotipo do GitHub. A implementação de referência (exemplo) do padrão Reliable Web App representa o estado final de uma implementação concluída. Este aplicativo Web de nível de produção inclui todas as atualizações de código, arquitetura e configuração descritas neste artigo. Implante e use a implementação de referência para ajudar a orientar sua própria implementação do padrão de Aplicativo Web Confiável.

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

Encontre as diretrizes específicas necessárias nas seções a seguir deste artigo:

  • Contexto de negócios: alinhe essas diretrizes com seu contexto de negócios e aprenda a definir metas imediatas e de longo prazo que impulsionam decisões de replatamento.

  • Diretrizes de arquitetura: selecione os serviços de nuvem corretos e crie uma arquitetura que atenda aos seus requisitos de negócios.

  • Diretrizes de código: implementar os padrões de design Retry, Circuit Breaker e Cache-Aside para melhorar a confiabilidade e a eficiência de desempenho do seu aplicativo web na nuvem.

  • Diretrizes de configuração: configurar autenticação e autorização, identidades gerenciadas, ambientes com direitos, IaC (infraestrutura como código) e monitoramento.

Contexto empresarial

A primeira etapa na replataformação de uma aplicação web é definir os objetivos empresariais. Defina metas imediatas, como objetivos de nível de serviço (SLOs) e metas de otimização de custos, juntamente com metas futuras para seu aplicativo Web. Esses objetivos influenciam sua escolha de serviços de nuvem e a arquitetura do aplicativo na nuvem. Defina um SLO alvo para seu aplicativo web, como 99,9% de disponibilidade. Calcule o SLA (contrato de nível de serviço) composto para todos os serviços que afetam a disponibilidade do aplicativo Web.

A Contoso Fiber deseja expandir seu aplicativo Web CAMS local para alcançar outras regiões. Para atender ao aumento da demanda no aplicativo Web, a empresa estabelece as seguintes metas:

  • 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.
  • Melhore a confiabilidade e a segurança.

A Contoso Fiber determina que sua infraestrutura local não é uma solução econômica para dimensionar o aplicativo. A empresa decide que a migração do aplicativo Web CAMS para o Azure é a maneira mais econômica de alcançar seus objetivos imediatos e futuros.

Diretrizes para arquitetura

O padrão de Aplicativo Web Confiável tem alguns elementos de arquitetura essenciais. Você precisa do DNS (Sistema de Nomes de Domínio) para gerenciar a resolução de endpoints, um firewall de aplicativo web para bloquear o tráfego HTTP mal-intencionado e um balanceador de carga para rotear e ajudar a proteger as solicitações de usuárias de entrada. A plataforma de aplicativos hospeda o código da aplicação Web e chama 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.

Diagrama que mostra os elementos de arquitetura essenciais do padrão Reliable Web App.

Projetar a arquitetura

Projete 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 dar suporte ao seu SLO. Determine um RPO e configure a redundância de dados para atender ao RPO.

Selecione os serviços corretos do Azure

Ao mover um aplicativo Web para a nuvem, escolha os serviços do Azure que atendem aos seus requisitos de negócios e alinhe com os recursos 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 dar suporte a middleware e estruturas existentes.

Antes da migração, o aplicativo Web CAMS da Contoso Fiber é um aplicativo 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 (LOB) para funcionários. Eles o usam para gerenciar casos de suporte ao cliente. O aplicativo enfrenta desafios comuns com escalabilidade e implantação de recursos. Esse ponto de partida, juntamente com metas de negócios e SLOs, influencia suas opções de serviço.

A lista a seguir fornece diretrizes para selecionar os serviços corretos do Azure para seu aplicativo Web e descreve por que a Contoso Fiber seleciona serviços específicos:

  • Plataforma de aplicativo: Use o Serviço de Aplicativo do Azure como sua plataforma de aplicativo. A Contoso Fiber usa o Serviço de Aplicativo pelos seguintes motivos:

    • Progressão natural: A Contoso Fiber implanta um arquivo JAR do Spring Boot em seu servidor local e deseja minimizar a quantidade de rearquitecagem para esse modelo de implantação. O Serviço de Aplicativo fornece suporte robusto para executar aplicativos spring boot, o que o torna uma opção adequada. Os Aplicativos de Contêiner do Azure também são uma opção adequada para este aplicativo. Para obter mais informações, consulte a visão geral dos Aplicativos de Contêiner e a visão geral do Java sobre Aplicativos de Contêiner.

    • SLA alto: O Serviço de Aplicativo fornece um SLA alto que atende aos requisitos de produção.

    • Sobrecarga de gerenciamento reduzida: O Serviço de Aplicativo é uma solução de hospedagem gerenciada.

    • Capacidade de contêinerização: O Serviço de Aplicativo integra-se com registros de imagem de contêiner privado, como o Registro de Contêiner do Azure. A Contoso Fiber pode usar esses registros para colocar o aplicativo Web em contêiner no futuro.

    • Dimensionamento automático: O aplicativo Web pode escalar verticalmente, reduzir verticalmente, escalar verticalmente e escalar horizontalmente com base no tráfego do usuário.

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

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

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

  • Base de dados: Use um serviço que permite manter o mesmo mecanismo de banco de dados. Use a árvore de decisão do armazenamento de dados para orientar sua seleção. A Contoso Fiber usa o modelo de implantação de servidor flexível do Banco de Dados do Azure para PostgreSQL pelos seguintes motivos:

    • Fiabilidade: O modelo de implantação de servidor flexível dá suporte à alta disponibilidade com redundância de zona em várias zonas de disponibilidade. Essa configuração mantém um servidor em espera quente em uma zona de disponibilidade diferente na mesma região do Azure. A configuração replica dados de forma síncrona para o servidor em espera.

    • Replicação entre regiões: O Azure Database for PostgreSQL oferece uma réplica de leitura para replicar dados de forma assíncrona em um banco de dados réplica somente leitura em outra região.

    • Desempenho: O Banco de Dados do Azure para PostgreSQL fornece desempenho previsível e ajuste inteligente que melhora o desempenho do banco de dados usando dados reais de uso.

    • Sobrecarga de gerenciamento reduzida: Esse serviço gerenciado do Azure reduz as obrigações de gerenciamento.

    • Suporte à migração: Ele dá suporte à migração de banco de dados de bancos de dados PostgreSQL de servidor único local. A Contoso Fiber pode usar a ferramenta de migração para simplificar o processo de migração.

    • Consistência com configurações locais: Ele dá suporte a diferentes versões da comunidade do PostgreSQL, incluindo a versão que a Contoso Fiber usa atualmente.

    • Recuperabilidade: A implantação do servidor flexível cria automaticamente backups de servidor e os armazena no armazenamento com redundância de zona (ZRS) na mesma região. A Contoso Fiber pode restaurar o banco de dados a qualquer ponto no tempo dentro do período de retenção de backup. A funcionalidade de backup e restauração cria um RPO melhor em comparação com ambientes locais.

  • Monitoramento de desempenho do aplicativo: Use o Application Insights para analisar a telemetria em seu aplicativo. A Contoso Fiber usa 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 dados de uso para o aplicativo e rastreia eventos personalizados.

    • Lacuna de visibilidade: A solução local não tem 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. O Redis Gerenciado do Azure é a principal solução de cache do Azure. É um armazenamento de dados gerenciado na memória com base no software Redis. A Contoso Fiber adiciona o Redis Gerenciado do Azure pelos seguintes motivos:

    • Velocidade e volume: Ele fornece 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 que todas as instâncias do aplicativo Web podem usar.

    • Armazenamento de dados externo: Os servidores de aplicativos locais usam o cache local da VM. Essa configuração não descarrega dados acessados com frequência e não pode invalidar dados obsoletos.

    • Sessões não aderente: O cache permite que o aplicativo Web externalize o estado da sessão e use sessões antiaderente. A maioria dos aplicativos Web Java que são executados localmente dependem do cache do lado do cliente na memória. Essa abordagem não é bem dimensionada e aumenta o volume de memória no host. O Redis Gerenciado do Azure fornece um serviço de cache gerenciado e escalonável para melhorar a escalabilidade e o desempenho dos aplicativos. A Contoso Fiber usou o Spring Cache como sua estrutura de abstração de cache e precisava apenas de alterações mínimas de configuração para mudar de um provedor Ehcache para o provedor Redis.

  • Balanceador de carga: Os aplicativos Web que usam soluções paaS (plataforma como serviço) 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 selecionar o balanceador de carga correto. A Contoso Fiber precisa de um balanceador de carga de camada 7 que possa rotear o tráfego entre várias regiões e um aplicativo Web de várias regiões para atender ao SLO de 99,9%. A empresa usa o Azure Front Door pelos seguintes motivos:

    • Balanceamento de carga global: Esse balanceador de carga de camada 7 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 roteamento 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.

    • Sondas de saúde: O aplicativo precisa de monitoramento inteligente de sondas de saúde. O Azure Front Door usa respostas da investigação para determinar a melhor origem para roteamento de solicitações de cliente.

    • Suporte de monitoramento: O Azure Front Door dá suporte a relatórios internos com um painel all-in-one para o Azure Front Door e padrões de segurança. Ele fornece 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 de DDoS (negação de serviço distribuído): Ele tem proteção interna contra DDoS na camada 3 e 4.

    • Rede de distribuição de conteúdo: Ele posiciona a Contoso Fiber para usar uma rede de distribuição de conteúdo. A rede de distribuição de conteúdo fornece aceleração do site.

  • Firewall do aplicativo Web: Use o Firewall de Aplicativo Web do Azure para fornecer proteção centralizada contra explorações e vulnerabilidades comuns da Web. A Contoso Fiber usa o Firewall de Aplicativo Web do Azure pelos seguintes motivos:

    • Proteção global: Ele fornece proteção de aplicativo Web global aprimorada, mantendo 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 é executada por trás de um firewall de aplicativo Web gerenciado por TI.

    • Facilidade de uso: O Firewall do Aplicativo Web do Azure integra-se ao Azure Front Door.

  • Gerenciador de segredos: Use o Azure Key Vault se você tiver segredos para gerenciar no Azure. A Contoso Fiber usa 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 do Azure) e a plataforma de hospedagem da Web (Serviço de Aplicativo).

  • Segurança do ponto de extremidade: Use o Link Privado do Azure para acessar soluções de PaaS em um ponto de extremidade privado em sua rede virtual. O tráfego entre sua rede virtual e o serviço percorre a rede de backbone da Microsoft. A Contoso Fiber usa o Link Privado pelos seguintes motivos:

    • Comunicação com segurança aprimorada: Permite que o aplicativo acesse serviços de forma privada na plataforma Azure e reduz a exposição de rede dos 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 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 VMs com segurança aprimorada, sem expor portas RDP/SSH (Protocolo de Área de Trabalho Remota/Secure Shell). A Contoso Fiber adota uma topologia de rede hub-and-spoke e coloca os serviços de segurança de rede compartilhados no hub. O Firewall do Azure inspeciona o tráfego de saída dos spokes para aprimorar a segurança de rede. A empresa usa o Azure Bastion para implantações com segurança aprimorada a partir de um jump host na sub-rede de DevOps.

Diretrizes de código

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

Diagrama que mostra as funções de padrões de design no padrão de Aplicativo Web Confiável.

Os seguintes padrões de projeto proporcionam benefícios para a carga de trabalho que se alinham a um ou mais dos pilares do Well-Architected Framework.

  1. 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. O padrão Circuit Breaker impede que um aplicativo tente novamente 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. 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 Custos (CO) Excelência Operacional (OE) Eficiência de Desempenho (PE) Suporte aos princípios do WAF
Padrão de repetição RE:07
Padrão de disjuntor RE:03
RE:07
PE:07
PE:11
Padrão Cache-Aside RE:05
PE:08
PE:12

Implementar o padrão de repetição

Adicione o padrão de repetição ao código do aplicativo para resolver interrupções temporárias do serviço. Essas interrupções são chamadas de falhas transitórias. Falhas transitórias geralmente se resolvem em segundos. Você pode usar o padrão de repetição para reenviar solicitações com falha. Ele também permite que você configure o atraso entre tentativas e o número de tentativas que devem ser feitas antes de admitir a falha.

Use Resilience4j, uma biblioteca leve de tolerância a falhas, para implementar o padrão de tentativa em Java. Para adicionar o padrão Retry, a implementação de referência aplica anotações Retry ao método do controlador do plano de serviço listServicePlans. O código repetirá a chamada para uma lista de planos de serviço do banco de dados se a chamada inicial falhar. A política de repetição para a implementação de referência inclui tentativas máximas, duração de espera e exceções para tentar novamente. Configure a política de repetição no arquivo 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 Circuit Breaker

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 Circuit Breaker impede que um aplicativo tente acessar continuamente um serviço não responsivo. Ele libera o aplicativo e ajuda a evitar o perda de ciclos de CPU (unidade de processamento central) para que o aplicativo mantenha sua integridade de desempenho para os usuários.

Use Spring Cloud Circuit Breaker e Resilience4j para implementar o padrão Circuit Breaker. A implementação de referência aplica o padrão Circuit Breaker decorando métodos com o atributo Circuit Breaker.

Implementar o padrão de Cache-Aside

Adicione o padrãoCache-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. Ele 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 de Cache-Aside, siga estas recomendações:

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

  • Armazenar dados de alta necessidade em cache. Aplique o padrão Cache-Aside em dados de alta necessidade para aprimorar sua eficácia. Use o Azure Monitor para acompanhar 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. Para armazenar dados específicos em cache em seu código, adicione a anotação @Cacheable. Essa anotação especifica ao Spring quais métodos devem ter seus resultados 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. 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. As configurações de cache padrão podem não se adequar ao aplicativo Web. Você pode personalizar essas configurações no application.properties arquivo ou nas variáveis de ambiente. Por exemplo, você pode modificar o spring.cache.redis.time-to-live valor (expresso em milissegundos) para controlar por quanto tempo os dados devem permanecer no cache antes de serem removidos.

  • Verifique a consistência dos dados. Implemente mecanismos para atualizar o cache imediatamente após as operações de gravação do banco de dados. Use atualizações controladas por eventos ou classes de gerenciamento de dados dedicadas para garantir a coerência do cache. Sincronizar consistentemente o cache com modificações de banco de dados é central para o padrão Cache-Aside.

Instruções de configuração

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

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

Configurar 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 estas recomendações:

  • Use uma plataforma de identidade. Use a plataforma de identidade da Microsoft para desenvolvedorespara 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 da Microsoft ou contas sociais.

    O [Spring Boot Starter for Microsoft Entra ID](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide usa Spring Security e Spring Boot para garantir uma configuração e integração fáceis. Ele fornece vários fluxos de autenticação, gerenciamento automático de tokens, políticas de autorização personalizáveis e recursos de integração com componentes do Spring Cloud. Essa ferramenta permite a integração direta da ID do Microsoft Entra e do OAuth 2.0 aos aplicativos Spring Boot sem a configuração de configurações ou biblioteca manual.

    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 do OAuth 2.0 para conectar um usuário que tenha 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 permite a autenticação e a autorização do Microsoft Entra em um aplicativo Spring Boot. A dependência org.springframework.boot: spring-boot-starter-oauth2-client habilita a autenticação e a 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>
    
  • Crie um registro de aplicativo. A ID do Microsoft Entra requer um registro de aplicativo no locatário primário. 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. A implementação de referência usa o Terraform para criar um registro de aplicativo do Microsoft Entra ID junto com uma função do Gerenciador 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 a autorização no aplicativo. Use o RBAC (controle de acesso baseado em função) para atribuir privilégios mínimos a funções de aplicativo. Defina funções específicas para ações de usuário diferentes para evitar sobreposição e garantir clareza. Mapeie os usuários para as funções apropriadas e verifique se eles têm acesso apenas aos recursos e ações necessários. Configure o Spring Security para usar o Spring Boot Starter com o Microsoft Entra ID. Essa biblioteca permite a integração com a ID do Microsoft Entra e ajuda a garantir que os usuários sejam autenticados com segurança. Configure e habilite a MSAL (Biblioteca de Autenticação da Microsoft) para obter acesso a mais recursos de segurança. Esses recursos incluem cache de token e atualização automática de token.

    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 se traduzem em permissões durante a autorização. Exemplos de funções específicas do aplicativo no CAMS incluem o Gerenciador de Contas, o Representante de Suporte de Nível Um (L1) e o Representante do Serviço de Campo. A função Gerenciador de Contas tem permissões para adicionar novos usuários e clientes do aplicativo. Um Representante de Serviço de Campo pode criar tíquetes de suporte. O atributo PreAuthorize restringe o acesso a papéis específicos.

        @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-se ao ID do Microsoft Entra, a implementação de referência usa o fluxo de concessão de código de autorização OAuth 2.0. Esse fluxo permite que um usuário entre usando uma conta da Microsoft. O trecho 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 ao 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. É o único SAS que utiliza credenciais do Microsoft Entra ID e não requer uma chave permanente da conta de armazenamento.

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

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

Implementar 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, especificamente 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:

  • Selecione o tipo certo de identidade gerenciada. Prefira identidades gerenciadas atribuídas pelo usuário quando você tiver dois ou mais recursos do Azure que precisam 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 o RBAC do Azure para conceder apenas permissões críticas para operações, como criar, ler, atualizar e excluir ações (CRUD) em bancos de dados ou acessar segredos. As permissões de identidade de carga de trabalho são persistentes, portanto, você não pode fornecer permissões JIT ou de curto prazo para identidades de carga de trabalho. Se o RBAC do Azure não abrange um cenário específico, complemente o RBAC do Azure com políticas de acesso no nível de serviço do Azure.

  • Forneça segurança para os segredos restantes. Armazene todos os segredos restantes no Key Vault. Carregue segredos do Key Vault na inicialização do aplicativo em vez de 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.

Ambientes Otimizados

Use SKUs (camadas de desempenho) de serviços do Azure que atendam às necessidades de cada ambiente sem excedê-las. Para ajustar corretamente o tamanho de seus ambientes, execute as seguintes etapas:

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

  • Otimizar ambientes de produção. Os ambientes de produção precisam de SKUs que atendam ao SLA, aos recursos e à escala necessários para a produção. Monitore continuamente o uso de recursos e ajuste SKUs para se alinhar às necessidades reais de desempenho.

  • Otimizar ambientes de pré-produção.Os ambientes de pré-produção devem usar recursos de menor custo e aproveitar descontos como o plano do Azure para preços de desenvolvimento/teste. Nesses ambientes, desabilite os serviços que não são necessários. Além disso, verifique se os ambientes de pré-produção são suficientemente semelhantes aos ambientes de produção para evitar a introdução de riscos. Mantenha esse equilíbrio para garantir que o teste permaneça eficaz sem incorrer em custos desnecessários.

  • Use IaC para definir SKUs. Implemente IaC para selecionar e implantar dinamicamente as SKUs corretas com base no ambiente. Essa abordagem aprimora a consistência e simplifica o gerenciamento.

Por exemplo, a implementação de referência tem um parâmetro opcional que especifica o SKU a ser implantado. Um parâmetro de ambiente especifica que o template Terraform deve implantar SKUs de desenvolvimento:

azd env set APP_ENVIRONMENT prod

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.

  • Refinar 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 entrada/saída de disco (E/S). O objetivo é corresponder ao comportamento do aplicativo Web para melhorar o desempenho.

  • Forneça um buffer de expansão. Defina seus limites de dimensionamento para iniciar o dimensionamento antes que a capacidade máxima seja atingida. Por exemplo, configure o dimensionamento para ocorrer aos 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 a implantação de recursos

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

  • Use IaC. Implante IaC usando pipelines de CI/CD (Continuous Integration/Continuous Delivery). O Azure fornece modelos Bicep predefinidos, modelos do ARM e modelos Terraform predefinidos para cada recurso do Azure.

  • Use um pipeline de CI/CD. Use um pipeline de CI/CD para implantar 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ê trabalhar com o Azure DevOps. Use o GitHub Actions para projetos do GitHub.

  • Integrar testes de unidade. Priorize a execução e a validação de todos os testes de unidade em seu pipeline antes da implantação no Serviço de Aplicativo. Incorpore ferramentas de qualidade e cobertura de código, como o SonarQube, para obter uma cobertura de teste abrangente.

  • 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 garantir condições uniformes de teste entre ambientes.

  • Execute verificações 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. Realize a SCA (análise de composição de software) para examinar bibliotecas e componentes que não são da Microsoft quanto a riscos de segurança. Integre ferramentas para essas análises no GitHub e no Azure DevOps.

Configurar monitoramento

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

  • Coletar telemetria da aplicação. Use a autoinstrumentação no Application Insights para coletar a 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 alterar nenhum código para usar essa telemetria. O Spring Boot registra várias métricas principais no Application Insights, como JVM (máquina virtual Java), CPU e Tomcat. O Application Insights coleta automaticamente de estruturas de log, como Log4j e Logback.

    A implementação de referência habilita o Application Insights na configuração do serviço de aplicativo por meio do Terraform.

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

    Para obter mais informações, consulte os seguintes artigos:

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

  • Monitore a plataforma. Habilite o diagnóstico para todos os serviços com suporte. Envie os diagnósticos para o mesmo destino que os registros 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 a diagnósticos.

    A implementação de referência usa o Terraform para habilitar o diagnóstico do Azure em 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 você pela migração simulada da Contoso Fiber de um aplicativo Java local para o Azure. Ele também destaca as alterações necessárias durante a fase inicial de adoção.

A arquitetura a seguir representa o estado final da implementação do padrão Reliable Web App da Contoso Fiber com base em suas metas.

Diagrama que mostra a arquitetura da implementação de referência.

Diagrama que mostra uma arquitetura de aplicativo Web Java confiável no Azure que usa uma topologia de rede hub-and-spoke. Os usuários acessam o aplicativo por meio do Azure Front Door, que fornece balanceamento de carga global, firewall de aplicativo Web e proteção contra DDoS. O Azure Front Door roteia o tráfego para instâncias do Serviço de Aplicativo em uma região primária e região secundária. Cada instância do Serviço de Aplicativo hospeda um aplicativo Web Java Spring Boot e é integrada ao Application Insights para monitoramento. A autenticação e a autorização são gerenciadas pela ID do Microsoft Entra. O aplicativo usa o servidor flexível do Banco de Dados do Azure para PostgreSQL para armazenamento de dados, configurado para alta disponibilidade e réplicas de leitura, e Redis Gerenciado do Azure para cache distribuído. O Key Vault armazena segredos, acessados por meio de identidades gerenciadas. O Link Privado protege conexões entre o aplicativo, o banco de dados e outros recursos de PaaS. A arquitetura é implantada em uma rede virtual do tipo hub-and-spoke. O hub na região primária contém o Firewall do Azure e o Azure Bastion para segurança e gerenciamento de rede e a sub-rede de ponto de extremidade privado do Key Vault. Os spokes nas regiões primária e secundária hospedam o aplicativo e o banco de dados. As sub-redes incluem a sub-rede de outros pontos de extremidade privados, a sub-rede DevOps, a sub-rede de integração de aplicativos Web e a sub-rede do ponto de extremidade privado do aplicativo Web. Os logs de diagnóstico e as métricas são enviados ao Azure Monitor e ao Log Analytics. Um ícone de zonas DNS privadas reside entre a região primária e secundária. As setas indicam o fluxo de dados e as relações entre componentes, ilustrando um padrão pronto para produção, escalonável e seguro para migrar um aplicativo Web Java monolítico para o Azure.

Baixe um arquivo do Visio dessa arquitetura.

Próxima etapa