Aplicativos Spring do Azure integrado com zonas de destino

Essa arquitetura de referência implanta a arquitetura de linha de base do Azure Spring Apps nas zonas de destino do Azure.

Nesse cenário, sua organização espera que a carga de trabalho use recursos federados gerenciados por equipes centrais (plataforma) Os exemplos de gerenciamento centralizado incluem rede para conectividade local, gerenciamento de acesso de identidade e políticas. Essas diretrizes pressupõem que a organização adotou zonas de destino do Azure para aplicar governança consistente e economizar custos em várias cargas de trabalho.

As escolhas de design feitas nesta arquitetura são abordadas nas principais áreas de design técnico. Para obter mais informações, consulte Zona de destino do Azure Spring Apps no Cloud Adoption Framework.

Arquitetura

O diagrama a seguir mostra a arquitetura dessa abordagem:

Alguns usos típicos dessa arquitetura:

• Aplicativos privados: aplicativos internos implantados em ambientes de nuvem híbrida.
• Aplicativos públicos: aplicativos voltados para o exterior.

Esses casos de uso são semelhantes, exceto pela configuração de regras de segurança e tráfego de rede.

Componentes

As seções a seguir descrevem os componentes dessa arquitetura. Os componentes são divididos de acordo com as responsabilidades de propriedade para ajudá-lo a identificar o que compartilhar com as equipes de plataforma da organização. Para obter a documentação do produto sobre os serviços do Azure, consulte a seção Recursos relacionados.

Recursos de propriedade da equipe do aplicativo

Sua equipe é responsável por criar e manter os seguintes recursos.

• O Azure Spring Apps Standard hospeda seus aplicativos Java Spring Boot no Azure.

• O Gateway de Aplicativo do Azure Standard_v2 é o proxy reverso que roteia o tráfego da Web de entrada para o Azure Spring Apps. Esse SKU integrou o Firewall de Aplicativo Web do Azure que inspeciona o tráfego em busca de vulnerabilidades do OWASP (Open Web Application Security Project).

• As Máquinas Virtuais do Azure atuam como uma caixa auxiliar para operações de gerenciamento.

• O Banco de Dados do Azure para MySQL armazena dados do aplicativo.

• O Azure Key Vault armazena segredos e configurações, como uma cadeia de conexão com o banco de dados.

• O Log Analytics é um recurso do Azure Monitor que também é conhecido como Logs do Azure Monitor. O Log Analytics é o coletor de monitoramento que armazena logs e métricas do aplicativo e dos serviços do Azure.

• O Azure Application Insights é usado como uma ferramenta de Gerenciamento de Desempenho de Aplicativo (APM) para coletar todos os dados de monitoramento de aplicativos e armazená-los diretamente no Log Analytics.

Recursos de propriedade da equipe da plataforma

Essa arquitetura pressupõe que os seguintes recursos já existam. As equipes centrais da organização possuem e mantêm esses recursos. Seu aplicativo depende desses serviços para reduzir a sobrecarga operacional e otimizar o custo.

• O Firewall do Azure inspeciona e restringe o tráfego de saída.

• O Azure Bastion fornece acesso seguro à jump box de gerenciamento.

• O Azure ExpressRoute fornece conectividade privada do local para a infraestrutura do Azure.

• O DNS do Azure fornece resolução de nomes entre locais.

• O Gateway de VPN do Azure conecta o aplicativo com equipes remotas em sua rede local.

Considerações sobre o aplicativo

A implementação de referência inclui um aplicativo de exemplo que ilustra um aplicativo de microsserviços típico hospedado em uma instância do Azure Spring Apps. As seções a seguir fornecem detalhes sobre o aplicativo hospedado. Para obter mais informações, consulte Exemplo de loja PetClinic.

Descoberta de serviço

Em um padrão de microsserviços, o recurso de registro de serviço deve ter suporte para rotear solicitações de usuário e comunicação de serviço a serviço.

Os serviços devem ser capazes de se comunicar com outros serviços. Quando novas instâncias são geradas, elas são adicionadas ao registro para que possam ser descobertas dinamicamente. Nessa arquitetura, o OSS (Registro de Serviço de Nuvem Gerenciado) do Spring está habilitado para o Azure Spring Apps. Esse serviço mantém um registro de instâncias de aplicativos ativos, permite o balanceamento de carga do lado do cliente e desacopla provedores de serviços de clientes sem depender de um DNS (Serviço de Nomes de Domínio).

A instância do Azure Spring Apps implementa o padrão de roteamento de gateway, que fornece um único ponto de entrada para o tráfego externo. O gateway roteia as solicitações de entrada para as instâncias de serviço ativas encontradas no registro. Neste design, o padrão é implementado com uma implementação de software livre do Spring Cloud Gateway. Ele oferece um conjunto de recursos que inclui autenticação e autorização, recursos de resiliência e limitação de taxa.

Servidor de configuração

Para microsserviços, os dados de configuração devem ser separados do código. Nessa arquitetura, o Azure Spring Apps Config Server permite o gerenciamento de recursos por meio de um repositório conectável que dá suporte ao armazenamento local e repositórios Git.

Redundância

Você pode usar zonas de disponibilidade ao criar uma instância do Azure Spring Apps.

Com esse recurso, o Azure Spring Apps distribui automaticamente recursos fundamentais entre seções lógicas da infraestrutura subjacente do Azure. Essa distribuição fornece um nível de disponibilidade superior e proteção contra uma falha de hardware ou eventos de manutenção planejada.

A redundância de zona garante que os nós de VM (máquina virtual) subjacentes sejam distribuídos uniformemente em todas as zonas de disponibilidade. No entanto, a redundância de zona não garante a distribuição uniforme de instâncias do aplicativo. Se uma instância de aplicativo falhar porque sua zona ficar inoperante, o serviço Aplicativos Spring do Azure criará outra instância desse aplicativo, em nós, em outras zonas de disponibilidade.

Se você habilitar seu próprio recurso no Azure Spring Apps, como seu próprio armazenamento persistente, habilite a redundância de zona para o recurso. Para obter mais informações, configura Como habilitar seu armazenamento persistente nos Aplicativos Spring do Azure.

Não há suporte para zonas de disponibilidade em todas as regiões. Para ver quais regiões dão suporte a zonas de disponibilidade, confira Regiões do Azure com suporte para zonas de disponibilidade.

Escalabilidade

O Azure Spring Apps fornece recursos de dimensionamento automático prontos para uso que permitem que os aplicativos sejam dimensionados com base em limites de métrica ou durante uma janela de tempo específica. O dimensionamento automático é recomendado quando os aplicativos precisam ser escalados ou escalados horizontalmente em resposta à mudança na demanda.

O Azure Spring Apps também dá suporte ao dimensionamento manual de seus aplicativos ajustando a CPU, a memória/GB por instância e as contagens de instâncias do aplicativo. Esse tipo de escalabilidade é adequado para atividades de escalabilidade única que você pode querer executar para determinados aplicativos. Ajuste os valores para atender às necessidades de dimensionamento do aplicativo e verifique se as configurações estão dentro dos limites máximos de cada atributo.

Considerações de rede

Nesse design, a carga de trabalho depende dos recursos pertencentes à equipe da plataforma para acessar recursos locais, controlar o tráfego de saída e assim por diante. Para obter mais informações, consulte Zona de destino do Azure Spring Apps: topologia de rede e conectividade.

Topologia de rede

A equipe da plataforma determina a topologia de rede. Uma topologia hub-spoke é assumida nesta arquitetura.

Rede virtual de hub

A assinatura de conectividade contém uma rede virtual de hub compartilhada por toda a organização. A rede contém recursos de rede pertencentes e mantidos pela equipe da plataforma. Os seguintes recursos da equipe da plataforma estão no escopo dessa arquitetura:

• O Firewall do Azure controla o tráfego de saída para a Internet.
• O Azure Bastion protege o acesso à jump box de gerenciamento.

Rede virtual spoke

A zona de destino do aplicativo tem pelo menos uma rede virtual pré-provisionada emparelhada com a rede do hub. Você possui os recursos nessa rede, como o balanceador de carga que roteia e protege conexões HTTP/s de entrada para o Azure Spring Apps da Internet.

A rede virtual pré-provisionada e os emparelhamentos devem ser capazes de suportar o crescimento esperado da carga de trabalho. Estime o tamanho da rede virtual e avalie os requisitos com a equipe da plataforma regularmente. Para obter informações, consulte Requisitos de rede virtual.

Injeção de VNet e sub-rede

Os Aplicativos Spring do Azure são implantados na rede por meio do processo de injeção de VNET. Esse processo isola o aplicativo da Internet, sistemas em redes privadas, outros serviços do Azure e até mesmo o runtime do serviço. O tráfego de entrada e saída do aplicativo é permitido ou negado com base nas regras de rede.

O isolamento é obtido por meio de sub-redes. Você é responsável por alocar sub-redes na rede virtual spoke. O Azure Spring Apps requer duas sub-redes dedicadas para o runtime do serviço e para aplicativos Java Spring Boot.

As sub-redes devem ser dedicadas a uma única instância do Azure Spring Apps. Várias instâncias não podem compartilhar as mesmas sub-redes.

O tamanho mínimo de cada sub-rede é /28. O tamanho real depende do número de instâncias de aplicativo que o Azure Spring Apps pode dar suporte. Para obter mais informações, consulte Usando intervalos de sub-rede menores.

Controles de rede

O Gateway de Aplicativo do Azure com Firewall de Aplicativo Web restringe o tráfego de entrada para a rede virtual spoke da Internet. As regras do Firewall de Aplicativo Web permitem ou negam conexões HTTP/s.

O tráfego dentro da rede é controlado usando NSGs (grupos de segurança de rede) em sub-redes. Os NSGs filtram o tráfego de acordo com os endereços IP e as portas configurados. Nesse design, os NSGs são colocados em todas as sub-redes. A sub-rede do Azure Bastion permite o tráfego HTTPS da Internet, serviços de gateway, balanceadores de carga e da rede virtual. Somente a comunicação RDP e SSH com as redes virtuais é permitida da sub-rede.

Os links privados são usados para controlar a conectividade entre o Azure Spring Apps e outros serviços do Azure, como o acesso ao cofre de chaves e ao banco de dados. Os pontos de extremidade privados são colocados em uma sub-rede separada.

Os registros DNS do host do aplicativo devem ser armazenados no DNS privado do Azure para garantir a disponibilidade contínua durante uma falha geográfica.

Embora a assinatura de conectividade tenha zonas DNS privadas, crie suas próprias zonas DNS privadas do Azure para dar suporte aos serviços acessados por pontos de extremidade privados.

O tráfego de saída da rede virtual deve ser restrito para evitar ataques de exfiltração de dados. Esse tráfego é roteado por meio do Firewall do Azure centralizado (próximo salto) que permite ou nega o fluxo usando um FQDN (nome de domínio totalmente qualificado).

Gerenciamento de identidade e de acesso

A implementação da identidade da carga de trabalho deve estar alinhada com as melhores práticas organizacionais para garantir que o aplicativo não viole os limites de segurança ou governança organizacional. Para obter mais informações, consulte Zona de destino do Azure Spring Apps: gerenciamento de identidade e acesso.

A ID do Microsoft Entra é recomendada para autenticar usuários e serviços que interagem com a instância do Azure Spring Apps.

A abordagem recomendada é habilitar identidades gerenciadas do Microsoft Entra para recursos do Azure para o aplicativo para permitir que o aplicativo se autentique em outros serviços. Nessa arquitetura, as identidades gerenciadas atribuídas pelo sistema são usadas para facilitar o gerenciamento.

Para autorização, use o RBAC (Controle de Acesso Baseado em Função) do Azure aplicando o princípio de privilégios mínimos ao conceder permissões.

Considerações de monitoramento

A plataforma de zona de destino do Azure fornece recursos de observabilidade compartilhados como parte das assinaturas de gerenciamento. No entanto, o provisionamento de seus próprios recursos de monitoramento é recomendado para simplificar o gerenciamento geral da carga de trabalho. Para obter mais informações, consulte Zona de destino do Azure Spring Apps: monitorar operações.

Essa arquitetura cria os seguintes recursos:

• O Azure Application Insights é a solução de APM (Monitoramento de Desempenho de Aplicativos) e é totalmente integrado ao serviço por meio de um agente Java. Esse agente fornece visibilidade de todos os aplicativos e dependências implantados sem exigir código extra.
• O workspace do Azure Log Analytics é o coletor unificado para todos os logs e métricas coletados dos serviços do Azure e do aplicativo.

Configure a instância do Azure Spring Apps para enviar logs de diagnóstico do aplicativo para o workspace provisionado do Log Analytics. Para obter mais informações, consulte Monitorar aplicativos de ponta a ponta.

Colete logs e métricas para outros serviços do Azure. O diagnóstico de inicialização está habilitado para a jump box, para que você possa capturar eventos à medida que a máquina virtual é inicializada.

Defina as configurações de diagnóstico para enviar logs de recursos para todos os outros recursos do Azure para um workspace do Log Analytics. Os logs de recursos não são coletados até que sejam roteados para um destino. Cada recurso do Azure requer sua própria configuração de diagnóstico.

Correlação de dados de vários workspaces

Os logs e as métricas gerados pela carga de trabalho e seus componentes de infraestrutura são salvos no workspace do Log Analytics da carga de trabalho. No entanto, os logs e as métricas gerados por serviços centralizados, como o Active Directory e o Firewall do Azure, são salvos em um workspace central do Log Analytics gerenciado por equipes de plataforma. Correlacionar dados de diferentes coletores pode levar a complexidades.

Considere um cenário de um fluxo de usuário em que a carga de trabalho tem dependências nos serviços centralizados. Parte dos dados pode ser coletada no nível da carga de trabalho e exportada para o workspace central do Log Analytics, onde é correlacionada com os logs da plataforma.

No entanto, outras entradas podem existir apenas no espaço de trabalho da carga de trabalho devido a problemas como volume de dados, interoperabilidade de formato ou restrições de segurança. Entradas de log não correlacionadas que existem em dois ou mais workspaces para um único fluxo de usuário podem dificultar a solução de determinados problemas. Essas complexidades adicionais exigem que as equipes trabalhem juntas para solucionar problemas de incidentes de aplicativos.

Para ajudar nesse tipo de colaboração, familiarize-se com os procedimentos estabelecidos por sua organização. Quando ocorre um incidente de segurança, os administradores no nível da carga de trabalho podem ser solicitados a revisar os logs de seus sistemas em busca de sinais de atividade mal-intencionada ou fornecer cópias de seus logs aos manipuladores de incidentes para análise posterior. Quando os administradores de carga de trabalho estão solucionando problemas de aplicativos, eles podem precisar da ajuda dos administradores de plataforma para correlacionar entradas de log de rede corporativa, segurança ou outros serviços de plataforma.

Investigações de integridade

O Gateway de Aplicativo do Azure usa investigações de integridade para garantir que o tráfego de entrada seja roteado para instâncias de back-end responsivas. As investigações de Preparação, Atividade e Inicialização do Azure Spring Apps são recomendadas. Se houver uma falha, essas sondas podem ajudar no encerramento normal. Para obter mais informações, consulte Como configurar investigações de integridade.

Considerações de segurança

As equipes centralizadas fornecem controles de rede e identidade como parte da plataforma. No entanto, a carga de trabalho deve ter recursos de segurança para reduzir a superfície de ataque. Para obter mais informações, consulte Zona de destino do Azure Spring Apps: Segurança.

Dados em repouso

Os dados inativos devem ser criptografados. O aplicativo em si é stateless. Todos os dados são mantidos em um banco de dados externo, em que essa arquitetura usa o Banco de Dados do Azure para MySQL. Esse serviço criptografa os dados, incluindo backups e arquivos temporários criados durante a execução de consultas.

Dados em trânsito

Os dados em trânsito devem ser criptografados. O tráfego entre o navegador do usuário e o Gateway de Aplicativo do Azure deve ser criptografado para garantir que os dados permaneçam inalterados durante o trânsito. Nessa arquitetura, o Gateway de Aplicativo do Azure aceita apenas o tráfego HTTPS e negocia o handshake TLS. Essa verificação é imposta por meio de regras NSG na sub-rede do Gateway de Aplicativo. O certificado TLS é carregado diretamente durante a implantação.

O tráfego do Gateway de Aplicativo para a instância do Azure Spring Apps é criptografado novamente para garantir que apenas o tráfego seguro chegue ao aplicativo. O runtime do serviço Azure Spring Apps recebe esse tráfego e atua como o ponto de terminação TLS. A partir desse ponto, a comunicação entre serviços dentro do aplicativo não é criptografada. No entanto, a comunicação com outros serviços de PaaS do Azure e o runtime do serviço ocorre por TLS.

Você pode optar por implementar a comunicação TLS de ponta a ponta por meio do Azure Spring Apps. Considere compensações. Pode haver um efeito negativo na latência e nas operações.

Os dados em trânsito devem ser inspecionados quanto a vulnerabilidades. O Firewall de Aplicativo Web é integrado ao Gateway de Aplicativo e inspeciona ainda mais as vulnerabilidades do OWASP que bloqueiam o tráfego. Você pode configurar o Firewall de Aplicativo Web para detectar, monitorar e registrar alertas de ameaças. Ou você pode configurar o serviço para bloquear invasões e ataques detectados pelas regras.

Proteção contra DDoS

A negação de serviço distribuída (DDoS) pode derrubar um sistema sobrecarregando-o com solicitações. A proteção básica contra DDoS é habilitada no nível da infraestrutura para todos os serviços do Azure para se defender contra esses ataques. Considere atualizar para o serviço de Proteção contra DDoS do Azure para aproveitar recursos como monitoramento, alertas e limites de conjunto de capacidade para o aplicativo. Para obter mais informações, consulte Perguntas frequentes sobre o Serviço de Proteção contra DDoS do Azure.

Gerenciamento de segredos

A abordagem de segurança de Confiança Zero da Microsoft exige que segredos, certificados e credenciais sejam armazenados em um cofre seguro. O serviço recomendado é o Azure Key Vault.

Há maneiras alternativas de armazenar segredos, dependendo do serviço e da intenção do Azure. Essa arquitetura implementa a seguinte abordagem:

• Os certificados são carregados durante a implantação.
• A conexão com o MySQL é implementada usando o Service Connector.

Estratégias de otimização de custos

Devido à natureza do design do sistema distribuído, a expansão da infraestrutura é uma realidade. Essa realidade resulta em custos inesperados e não controláveis. O Azure Spring Apps é criado usando componentes que são dimensionados para ajudar a atender à demanda e otimizar o custo. A base dessa arquitetura é o AKS (Serviço de Kubernetes do Azure). O serviço foi projetado para reduzir a complexidade e a sobrecarga operacional do gerenciamento do Kubernetes e inclui eficiências no custo operacional do cluster.

Você pode implantar diferentes aplicativos e tipos de aplicativos em uma única instância do Aplicativos Spring do Azure. O serviço oferece suporte ao dimensionamento automático de aplicativos acionados por métricas ou agendamento que podem melhorar a utilização e a eficiência de custos.

Você também pode usar o Application Insights e o Azure Monitor para reduzir o custo operacional. Com a visibilidade fornecida pela solução de registro em log abrangente, você pode implementar a automação para dimensionar os componentes do sistema em tempo real. Você também pode analisar dados de log para revelar ineficiências no código do aplicativo que você pode abordar para melhorar o custo e o desempenho geral do sistema.

Implantação do cenário

Uma implantação para essa arquitetura de referência está disponível no repositório GitHub da zona de destino do Azure Spring Apps. A implantação usa modelos do Terraform.

Os artefatos neste repositório fornecem uma base que você pode personalizar para seu ambiente. A implementação cria uma rede de hub com recursos compartilhados, como o Firewall do Azure, para fins ilustrativos. Esse agrupamento pode ser mapeado para assinaturas de zona de destino separadas para manter as funções de carga de trabalho e plataforma separadas.

Para implantar a arquitetura, siga as instruções passo a passo.

Suporte VMware com o nível Enterprise

Se você quiser suporte gerenciado do VMware Tanzu® para sua implantação dinâmica, considere atualizar para a camada Enterprise do Azure Spring Apps. O VMware Tanzu® Service Registry é integrado ao Azure Spring Apps, o que permite a descoberta e o registro de serviços.

Para roteamento de gateway, você pode alternar para o VMware Spring Cloud Gateway. Ele oferece um conjunto de recursos que inclui autenticação e autorização, recursos de resiliência e limitação de taxa.

Na camada Enterprise, o Application Configuration Service for Tanzu® permite o gerenciamento de recursos ConfigMap nativos do Kubernetes que são preenchidos a partir de propriedades definidas em um ou mais repositórios Git.

Há outros serviços VMware compatíveis com esse nível. Para obter mais informações, confira Camada Enterprise no Azure Marketplace.

A implementação de referência dá suporte ao SKU do Azure Spring Apps Enterprise como uma opção de implantação. Nesta opção, existem algumas alterações de arquitetura. Ele usa uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL implantado com integração de Rede Virtual do Azure e Cache do Azure para Redis com ponto de extremidade privado. O aplicativo de exemplo é o aplicativo Fitness Store.

Próximas etapas

• Examine as áreas de design das diretrizes da zona de destino do Azure Spring Apps.

Recursos relacionados

Para obter a documentação do produto sobre os serviços do Azure usados nesta arquitetura, consulte os seguintes artigos:

• Azure Spring Apps Enterprise
• Gateway de Aplicativo do Azure v2
• Banco de Dados do Azure para MySQL
• Azure Key Vault
• Rede Virtual do Azure
• Tabelas de rotas

Para outros cenários de implementação, consulte os seguintes artigos:

• Implementar o Aplicativos Spring do Azure em várias regiões
• Expor os Aplicativos Spring do Azure por meio de um proxy reverso