Azure Spring Apps integrado com zonas de destino

Essa arquitetura de referência implanta a arquitetura de linha de base dos Aplicativos Spring do Azure nas zonas de aterrissagem 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 a identidades e políticas. Esta orientação pressupõe que a organização adotou zonas de aterrissagem do Azure para aplicar uma 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 este acelerador. Para obter mais informações, consulte Acelerador de zona de aterrissagem do Azure Spring Apps.

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 para a 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 Standard_v2 do Gateway de Aplicativo do Azure é o proxy reverso que roteia o tráfego Web de entrada para os Aplicativos Spring do Azure. Essa SKU integrou o Firewall de Aplicativo Web do Azure que inspeciona o tráfego em busca de vulnerabilidades do Open Web Application Security Project (OWASP).

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

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

• O Cofre de Chaves do Azure armazena segredos e configuração, 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á existem. 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 os custos.

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

• O Bastião do Azure fornece acesso seguro à caixa de salto 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 a 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 armazenamento PetClinic.

Descoberta de serviço

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

Os serviços devem poder 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 (Managed Spring Cloud Service Registry) está habilitado para os Aplicativos Spring do Azure. Esse serviço mantém um registro de instâncias de aplicativos em tempo real, habilita o balanceamento de carga do lado do cliente e desacopla provedores de serviços de clientes sem depender de um DNS (Serviço de Nome 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 tráfego externo. O gateway roteia 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 código aberto 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 oferece suporte a 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 máquina virtual (VM) subjacentes sejam distribuídos uniformemente em todas as zonas de disponibilidade. No entanto, a redundância de zona não garante nem mesmo a distribuição de instâncias de aplicativos. 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 nos Aplicativos Spring do Azure, 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

Os Aplicativos Spring do Azure fornecem 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 aumentar ou expandir em resposta à mudança de demanda.

Os Aplicativos Spring do Azure também dão suporte ao dimensionamento manual de seus aplicativos ajustando as contagens de CPU, Memória/GB por instância e Instância de aplicativo. Esse tipo de dimensionamento é adequado para atividades de dimensionamento único que você talvez queira 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 para cada atributo.

Considerações de rede

Nesse design, a carga de trabalho depende de 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 Acelerador de zona de aterrissagem 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 nessa 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 de equipe de plataforma estão no escopo dessa arquitetura:

• O Firewall do Azure controla o tráfego de saída para a Internet.
• O Bastião do Azure protege o acesso à caixa de salto de gerenciamento.

Rede virtual spoke

A zona de aterrissagem do aplicativo tem pelo menos uma rede virtual pré-provisionada que é emparelhada para a rede de 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 e sub-rede de rede VNet

O Azure Spring Apps é implantado 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 tempo de execução do serviço. O tráfego de entrada e saída do aplicativo é permitido ou negado com base em regras de rede.

O isolamento é obtido através de sub-redes. Você é responsável por alocar sub-redes na rede virtual falada. Os Aplicativos Spring do Azure exigem duas sub-redes dedicadas para o tempo de execução 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 os Aplicativos Spring do Azure podem suportar. Para obter mais informações, consulte Usando intervalos de sub-rede menores.

Controles de rede

O Gateway de Aplicativo do Azure com o Firewall de Aplicativo Web restringe o tráfego de entrada para a rede virtual spoke da Internet. As regras do Web Application Firewall 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 portas configurados. Nesse design, os NSGs são colocados em todas as sub-redes. A sub-rede do Bastião do Azure 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 para as redes virtuais é permitida a partir da sub-rede.

Os links privados são usados para controlar a conectividade entre os Aplicativos Spring do Azure 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 de identidade da carga de trabalho deve estar alinhada com as práticas recomendadas organizacionais para garantir que o aplicativo não viole a segurança organizacional ou os limites de governança. Para obter mais informações, consulte Acelerador de zona de aterrissagem 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 autoautentique em outros serviços. Nessa arquitetura, as identidades gerenciadas atribuídas pelo sistema são usadas para facilitar o gerenciamento.

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

Considerações de monitoramento

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

Essa arquitetura cria os seguintes recursos:

• O Azure Application Insights é a solução de Monitoramento de Desempenho de Aplicativo (APM) 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 espaço de trabalho do Azure Log Analytics é o coletor unificado de 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 espaço de trabalho 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 caixa de salto, 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 espaço de trabalho 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 espaços de trabalho

Os logs e as métricas gerados pela carga de trabalho e seus componentes de infraestrutura são salvos no espaço de trabalho 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 espaço de trabalho central do Log Analytics gerenciado por equipes de plataforma. Correlacionar dados de diferentes pias pode levar a complexidades.

Considere um cenário de um fluxo de usuários em que a carga de trabalho tenha dependências dos serviços centralizados. Parte dos dados pode ser coletada no nível da carga de trabalho e exportada para o espaço de trabalho central do Log Analytics, onde está 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 espaços de trabalho 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 incidentes de aplicativos.

Para ajudar nesse tipo de colaboração, familiarize-se com os procedimentos configurados pela sua organização. Quando ocorre um incidente de segurança, os administradores de nível de 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 adicional. 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 serviços de rede corporativa, segurança ou outros serviços de plataforma.

Investigações de integridade

O Gateway de Aplicativo do Azure usa testes de integridade para garantir que o tráfego de entrada seja roteado para instâncias de back-end responsivas. Recomendam-se os testes de Prontidão, Vivacidade e Inicialização dos Aplicativos Spring do Azure. Se houver uma falha, essas sondas podem ajudar na terminação graciosa. Para obter mais informações, consulte Como configurar testes de integridade.

Considerações sobre 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 Acelerador de zona de aterrissagem do Azure Spring Apps: Segurança.

Dados em repouso

Os dados inativos devem ser criptografados. O aplicativo em si é sem monitoração de estado. Todos os dados são persistentes em um banco de dados externo, onde 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 só aceita tráfego HTTPS e negocia handshake TLS. Essa verificação é imposta por meio de regras NSG na sub-rede do Application Gateway. 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 tempo de execução 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 tempo de execução do serviço ocorre por TLS.

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

Os dados em trânsito devem ser inspecionados em busca de vulnerabilidades. O Web Application Firewall é integrado ao Application Gateway e inspeciona ainda mais o tráfego que bloqueia vulnerabilidades OWASP. Você pode configurar o Web Application Firewall para detectar, monitorar e registrar alertas de ameaça. 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 está habilitada no nível de infraestrutura para que todos os serviços do Azure se defendam contra esses ataques. Considere atualizar para o serviço de Proteção contra DDoS do Azure para aproveitar recursos como monitoramento, alertas, os limites de capacidade definidos 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 os custos. A base dessa arquitetura é o Serviço de Kubernetes do Azure (AKS). 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 Azure Spring Apps. 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 Azure Spring Apps Landing Zone Accelerator no GitHub. 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 aterrissagem separadas para manter a carga de trabalho e as funções da 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 ao vivo, considere atualizar para a camada do Azure Spring Apps Enterprise. 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 suportados nesse 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. Nessa opção, há algumas alterações de arquitetura. Ele usa uma instância do Banco de Dados do Azure para servidor flexível 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

• Revise as áreas de design do acelerador de zona de aterrissagem do Azure Spring Apps.

Recursos relacionados

Para obter documentação do produto sobre os serviços do Azure usados nessa 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 Azure Spring Apps em várias regiões
• Expor os Aplicativos Spring do Azure por meio de um proxy reverso