Modifier

Partager via

Architecture de base Azure Spring Apps

Azure Application Gateway
Azure Key Vault
Azure Spring Apps
Azure Database pour MySQL

Cette architecture de référence décrit comment exécuter des charges de travail Java Spring Boot sur Azure Spring Apps. La conception utilise la redondance de zone pour parvenir à une haute disponibilité. Implémentez cette conception pour empêcher l’échec d’une application en cas d’interruption dans tous les centres de données d’une zone.

Cette architecture vous permet de :

  • Augmentez la disponibilité de votre application sur un déploiement de zone unique.
  • Augmenter la résilience globale et l’objectif de niveau de service (SLO) de votre application.

Cette solution présente une stratégie de base pour le déploiement d'Azure Spring Apps. Pour découvrir d’autres solutions générant sur cette architecture, voir Déployer Azure Spring Apps dans plusieurs régions et Azure Spring Apps intégré aux zones d’atterrissage.

Conseil

Logo GitHub Consultez un exemple d’implémentation illustrant certains choix de conception de cette architecture. Envisagez cette implémentation comme votre première étape vers la production.

Architecture

Le schéma suivant montre l’architecture de cette approche :

Diagramme montrant une architecture de référence Azure Spring Apps multirégion.Téléchargez un fichier Visio de cette architecture.

Workflow

Ce flux de travail correspond au diagramme précédent :

  1. L’utilisateur accède à l’application en utilisant le nom d’hôte HTTP de l’application, tel que www.contoso.com. Azure DNS est utilisé pour résoudre la requête pour ce nom d’hôte sur le point de terminaison public d’Azure Application Gateway.

  2. Application Gateway est utilisé pour examiner la requête. Il est également utilisé pour transférer le trafic autorisé vers l’adresse IP de l’équilibreur de charge dans l’instance Azure Spring Apps approvisionnée. Application Gateway est intégré à Azure Web Application Firewall.

  3. L’équilibreur de charge interne est utilisé pour acheminer le trafic vers les services principaux.

  4. Pendant le traitement de la requête, l’application communique avec d’autres services Azure au sein du réseau virtuel. Par exemple, il est possible que l’application reçoive des secrets d’Azure Key Vault ou l’état de stockage à partir de la base de données.

Composants

Les services Azure suivants sont les composants de cette architecture :

  • La version standard d’Azure Spring Apps est utilisée pour héberger un exemple d’application Java Spring Boot implémentée en tant que microservices.

  • La version v2 standard d’Application Gateway est utilisée pour gérer le trafic vers les applications. Elle fait office de proxy inverse local dans la région exécutée par votre application.

    Cette référence SKU intègre le service Web Application Firewall pour protéger vos applications web contre des codes malveillants exploitant une faille de sécurité ou des vulnérabilités. Web Application Firewall sur Application Gateway piste les codes malveillants exploitant une faille de sécurité d'Open Web Application Security Project (OWASP).

  • Le service Azure DNS est utilisé pour résoudre des requêtes envoyées au nom d’hôte de l’application. Il résout ces requêtes dans le point de terminaison public Application Gateway. Les Zones privées Azure DNS sont utilisées pour résoudre des requêtes dans des points de terminaison privés qui accèdent aux ressources Azure Private Link nommées.

  • Le service Azure Database pour MySQL est utilisé pour stocker l’état dans une base de données relationnelle principale.

  • La solution Azure Key Vault est utilisée pour stocker les secrets et certificats d’applications. Les microservices qui s’exécutent dans Azure Spring Apps utilisent les secrets de l’application. Azure Spring Apps et Application Gateway utilisent les certificats pour préserver le nom d’hôte.

Autres solutions

Azure Database pour MySQL n’est pas la seule option pour une base de données. Vous pouvez aussi utiliser :

Redondance

Créez une redondance dans votre charge de travail pour réduire des points de défaillance uniques. Dans cette architecture, vous répliquez des composants dans les zones d’une région. Dans votre architecture, veillez à utiliser des zones de disponibilité pour tous les composants dans votre configuration.

Les services Azure ne sont pas pris en charge dans toutes les régions et toutes les régions ne prennent pas en charge les zones. Avant de sélectionner une région, vérifiez sa zone géographique et sa prise en charge de zone.

Les services redondants interzones répliquent ou distribuent les ressources sur plusieurs zones. Les services toujours disponibles sont constamment disponibles dans toutes les zones géographiques Azure et résistent aux interruptions à l’échelle d’une zone et d’une région.

Le tableau suivant montre les types de résilience pour les services dans cette architecture :

Service Résilience
Azure DNS Toujours disponible
Application Gateway Redondant interzone
Azure Spring Apps Redondant interzone
Azure Database pour MySQL Redondant interzone
Key Vault Redondant interzone
Réseau virtuel Azure Redondant interzone
Points de terminaison privés Azure Redondant interzone

Azure Spring Apps prend en charge la redondance de zone. Avec celle-ci, toute l’infrastructure sous-jacente du service est répartie sur plusieurs zones de disponibilité et fournit donc une disponibilité supérieure pour l’application. Les applications effectuent une mise à l’échelle horizontale sans aucune modification du code. Un réseau hautes performances connecte des zones de disponibilité Azure. La connexion a une latence aller-retour de moins de 2 millisecondes (ms). Vous n’avez pas besoin de vous appuyer sur une réplication asynchrone pour des charges de travail de données, ce qui présente souvent des problèmes de conception.

Plusieurs zones de disponibilité sont configurées pour Application Gateway, notamment l’adresse IP publique utilisée par Application Gateway. Les adresses IP publiques avec une référence SKU standard prennent en charge les zones de disponibilité.

Cette architecture utilise Azure Database pour MySQL avec l’option de déploiement de serveur flexible pour prendre en charge la haute disponibilité avec basculement automatique. En fonction de vos exigences de latence, choisissez haute disponibilité redondante interzone ou haute disponibilité dans la même zone. Avec une configuration de haute disponibilité, l’option de serveur flexible fournit et gère automatiquement un réplica de secours. Les données validées ne sont pas perdues en cas de panne.

Key Vault est automatiquement redondant interzone dans n’importe quelle région où les zones de disponibilité sont disponibles. L’instance Key Vault utilisée dans cette architecture est déployée afin de stocker des secrets pour des services principaux.

Extensibilité

La scalabilité indique la capacité de la charge de travail à répondre efficacement aux demandes placées par des utilisateurs. L’approche multizone est mieux adaptée pour la scalabilité qu’un déploiement à zone unique, car elle répartit la charge entre les zones de disponibilité.

Cette architecture comporte plusieurs composants qui peuvent être mis à l’échelle automatiquement en fonction des métriques :

En fonction de la configuration de votre base de données, il est possible que vous produisiez davantage de latence lorsque des données doivent être synchronisées entre des zones.

Sécurité du réseau

Protégez votre application contre les accès non autorisés à partir d’Internet, des systèmes de réseaux privés, d’autres services Azure et de certaines dépendances fortement couplées.

Le service Réseau virtuel est l’élément fondamental d’un réseau privé dans Azure. Cette architecture utilise un réseau virtuel pour la région du déploiement. Placez des composants dans des sous-réseaux pour créer une isolation supplémentaire. Azure Spring Apps nécessite un sous-réseau dédié pour l'exécution du service, ainsi qu'un sous-réseau distinct pour les applications Java Spring Boot.

Protégez vos réseaux virtuels avec Azure DDoS Protection. Associez la protection du déni de service distribué (DDoS) aux meilleures pratiques de conception d’applications afin de fournir des atténuations améliorées pour lutter contre des attaques DDoS.

La conception d’architecture incorpore plusieurs solutions platform as a service (PaaS) qui permettent de traiter la requête d’un utilisateur. Placez des contrôles réseau stricts sur ces services pour veiller à ce que l’application ne soit pas touchée.

Connectivité privée

Utilisez des points de terminaison privés ou une intégration réseau pour assurer la communication entre Azure Spring Apps et des services associés, tels que Key Vault et Azure Database pour MySQL.

Utiliser des points de terminaison privés pour contrôler l’accès. Les interfaces réseau utilisent des adresses IP privées pour transférer les services dans le réseau virtuel. Cette architecture utilise des services Azure qui configurent automatiquement les points de terminaison privés.

Déployez Azure Spring Apps sur le réseau via le processus d’injection sur le réseau virtuel. L’application est accessible en accédant à l’adresse IP privée.

La base de données suit un modèle similaire. Le mode de déploiement de serveur flexible d’Azure Database pour MySQL prend en charge l’intégration de réseau virtuel via un sous-réseau dédié.

D’autres services, dont Azure Key Vault, sont connectés au réseau virtuel via Private Link. Pour Private Link, vous devez activer un point de terminaison privé pour désactiver l’accès au réseau public. Si vous souhaitez obtenir plus d’informations, consultez Intégrer Key Vault avec Azure Private Link.

Les points de terminaison privés ne nécessitent aucun sous-réseau dédié, mais il est recommandé de les placer dans un sous-réseau distinct. Les adresses IP privées des points de terminaison privés sont attribuées à partir de ce sous-réseau.

Le point de terminaison privé et les connexions intégrées au réseau utilisent une zone privée Azure DNS.

Contrôles du flux de trafic

Grâce à cette architecture, les requêtes entrantes sont uniquement autorisées via le point de terminaison public exposé par Application Gateway. Le trafic doit toujours être inspecté pour bloquer des codes malveillants exploitant une faille de sécurité et des vulnérabilités. Web Application Firewall sur Application Gateway surveille les vulnérabilités OWASP (Open Web Application Security Project). Le trafic entrant est inspecté en fonction des règles configurées, avec une action à suivre.

L'instance Azure Spring Apps dispose d'un équilibreur de charge interne qui achemine et distribue le trafic vers les services back-end. L'équilibreur de charge est configuré pour accepter le trafic provenant uniquement d'Application Gateway.

L’application peut avoir besoin de se connecter à d’autres points de terminaison via l’Internet public. Pour limiter ce flux, envisagez de placer le Pare-feu Azure sur le chemin de sortie.

Configuration du proxy inverse

Cette solution utilise Application Gateway comme proxy inverse. Mais vous pouvez utiliser différents proxys inverses devant Azure Spring Apps. Vous pouvez associer Application Gateway à Azure Front Door ou utiliser Azure Front Door au lieu d’Application Gateway.

Si vous souhaitez obtenir plus d’informations sur les scénarios de proxy inverse, sur la façon de les configurer et sur leurs points de sécurité, consultez Exposer Azure Spring Apps via un proxy inverse.

Gestion des identités et des accès

Outre l’utilisation de contrôles réseau, renforcez la posture de sécurité en utilisant une identité en tant que périmètre.

L’application doit s’authentifier lorsqu’elle se connecte aux services principaux, par exemple lorsqu’elle récupère des secrets à partir de Key Vault. Dans l’application, l’approche recommandée consiste à activer identités managées Microsoft Entra pour les ressources Azure. Cette méthode de configuration affecte une identité à l’application et lui permet d’obtenir des jetons Microsoft Entra ID, ce qui réduit la surcharge liée à la gestion des informations d’identification.

Cette architecture utilise des identités managées affectées par le système pour plusieurs interactions.

Les services principaux doivent permettre l'accès au principal de service qui est alloué à l'identité managée. Le service doit définir des stratégies d’accès minimales pour certaines actions. Dans cette architecture, la solution Key Vault est utilisée pour permettre à l’application d’accéder aux secrets, certificats et clés.

Gestion des secrets

Cette architecture stocke les secrets et certificats d'application dans un seul coffre de clés. Les secrets et certificats d’application pour la préservation des noms d’hôte sont des problèmes différents. Par conséquent, vous pouvez les stocker dans des coffres de clés distincts. Cette approche alternative ajoute un autre coffre de clés à votre architecture.

Surveillance

Azure Monitor est une solution de monitoring qui permet de collecter, d’analyser et de répondre aux données de monitoring à partir de vos environnements cloud et locaux.

Ajoutez une instrumentation à votre application pour émettre des journaux et des métriques au niveau du code. Envisagez d’activer le suivi distribué pour obtenir l’observabilité entre les différents services au sein de l’instance Azure Spring Apps. Utilisez un outil de gestion des performances des applications (APM) pour collecter des données de métriques et des journaux. L’agent Java Application Insights pour Azure Monitor est un bon choix d’outil APM.

Utilisez les diagnostics de plateforme pour obtenir des journaux et des métriques de tous les services Azure, tels qu’Azure Database pour MySQL. Intégrez toutes les données aux Journaux Azure Monitor pour fournir un insight de bout en bout dans les services de la plateforme et votre application.

L’espace de travail Log Analytics est le récepteur de données de monitoring qui collecte des journaux et des métriques à partir de ressources Azure et d’Application Insights. Cette solution de journalisation offre une visibilité pour automatiser les processus pour la mise à l’échelle de composants en temps réel. L’analyse des données de journal peut également révéler des inefficacités dans le code d’application que vous pouvez corriger pour améliorer les coûts et les performances.

Si vous souhaitez obtenir des conseils sur le monitoring spécifique à Spring Apps, consultez Démarrage rapide : Surveiller les applications de bout en bout et Surveiller avec Dynatrace Java OneAgent.

Déploiement automatisé

Automatisez autant que possible le déploiement de votre infrastructure et les déploiements de code d'application.

L’automatisation des déploiements d’infrastructure veille à ce que l’infrastructure soit configurée de manière identique, ce qui permet d’éviter la dérive de configuration, potentiellement entre des environnements. Vous pouvez également utiliser l’automatisation d’infrastructure pour tester des opérations de basculement.

Vous pouvez utiliser une stratégie de déploiement bleu-vert ou Canary pour vos applications.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Les considérations suivantes fournissent des conseils sur l’implémentation des fondements d’Azure Well-Architected Framework​ dans le contexte de cette architecture.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Implémentez les suggestions suivantes pour créer une application plus fiable :

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Implémentez les suggestions suivantes pour créer une application plus sécurisée :

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Pour cette architecture, prévoyez un coût supérieur, car vous déployez des composants dans plusieurs zones. Au lieu d’une instance Azure Spring Apps, vous exécutez deux voire trois instances. Mais l’activation de la redondance de zone sur le service n’entraîne aucun coût supplémentaire. Si vous souhaitez obtenir d’informations, consultez Tarifs Azure Spring Apps.

Envisagez les choix d'implémentation suivants pour réduire les coûts :

  • Vous pouvez déployer différentes applications et différents types d’applications sur une instance unique d’Azure Spring Apps. Lorsque vous déployez plusieurs applications, le coût de l'infrastructure sous-jacente est partagé entre les applications.

  • Azure Spring Apps prend en charge la mise à l’échelle automatique des applications déclenchée par des métriques ou des planifications, ce qui peut améliorer l’utilisation et la rentabilité.

  • Vous pouvez utiliser Application Insights dans Azure Monitor pour baisser les coûts d’exploitation. Une surveillance continue peut aider à résoudre plus rapidement les problèmes, ainsi qu’à améliorer les coûts et les performances.

  • Choisissez le meilleur niveau tarifaire en fonction de vos exigences :

  • Utilisez une mise à l’échelle automatique des applications pour effectuer un scale-up et un scale-down suivant la demande.

Pour obtenir un coût estimé des services pour cette architecture, voir la calculatrice de prix Azure. Cette estimation utilise des valeurs par défaut raisonnables pour une application à petite échelle. Vous pouvez mettre à jour l’estimation en fonction des valeurs de débit attendues pour votre application.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Outre les conseils sur le monitoring abordés antérieurement, implémentez les suggestions suivantes pour vous aider à déployer et surveiller votre application.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Implémentez les suggestions suivantes pour créer une application plus efficace :

Déployer ce scénario

Pour déployer cette architecture, suivez les instructions pas à pas dans Architecture de référence multizone Azure Spring Apps. Le déploiement utilise des modèles Terraform.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes