Déployer Azure Spring Apps dans plusieurs régions

Cette architecture de référence décrit une approche pour exécuter plusieurs instances Azure Spring Apps dans les régions dans une configuration active/active.

Cette conception s’appuie sur l’architecture de base de Azure Spring Apps. La base de référence déploie une application Java Spring Boot dans plusieurs zones de disponibilité au sein d’une même région. Le déploiement multizone répartit la charge de travail de l'application entre plusieurs emplacements éloignés, de sorte que la charge de travail puisse tolérer des défaillances locales dans la région Azure.

Toutefois, si l'ensemble de la région rencontre une défaillance, la ligne de base devient indisponible pour l'utilisateur. L’objectif de cette conception est de créer une haute disponibilité qui peut résister à une panne régionale.

Cette architecture est utile pour atteindre les objectifs suivants :

• Augmenter la résilience globale et l’objectif de niveau de service (SLO) de l’application.
• Permettre à l'application d'avoir une portée globale.
• Rapprocher la charge de travail de l'utilisateur final et rendre la latence aussi faible que possible.
• Utiliser une région secondaire comme site de basculement pour la région primaire et opter pour une conception active-passive.

Vous pouvez déployer l’application dans plusieurs régions pour augmenter la résilience et la fiabilité de celle-ci. Pour cette conception, vous avez besoin d'un routeur global pour équilibrer la charge des demandes adressées à vos applications entre les régions. Le routeur global de cette architecture répond également à d'autres objectifs.

Le principal défi d’une configuration multirégion consiste à répliquer les données de votre application entre plusieurs régions. Ce problème ne se pose pas avec la configuration multizone. Les zones de disponibilité Azure sont connectées par un réseau hautes performances avec une latence aller-retour de moins de 2 ms. Cette période de latence est suffisante pour la plupart des applications.

Architecture

Le schéma ci-dessous illustre l'architecture de cette approche :

Composants

Les composants de cette architecture sont les mêmes que ceux de l'architecture de base. La liste suivante met uniquement en évidence les modifications apportées à l'architecture de base. Pour obtenir de la documentation sur les services Azure, reportez-vous à Ressources connexes.

• Azure Front Door joue le rôle d’équilibreur de charge global. Ce service est utilisé en raison de sa capacité à garantir une disponibilité plus élevée avec une latence plus faible, une plus grande capacité de mise à l'échelle et une mise en cache à la périphérie.

Workflow

L'architecture de référence met en œuvre le flux de travail suivant :

1. L'utilisateur envoie une requête vers le nom d'hôte HTTP de l'application, par exemple www.contoso.com. Azure DNS résout la requête pour ce nom d’hôte sur Azure Front Door.

2. Azure Front Door utilise différentes configurations d’équilibrage de charge pour transférer les requêtes entrantes au point de terminaison public de Azure Application Gateway dans chaque région. Les instances des passerelles applicatives sont configurées avec le même nom de domaine personnalisé et le même nom de certificat TLS qu'Azure Front Door.

3. Azure Application Gateway avec Azure Web Application Firewall intégré inspecte la requête. Web Application Firewall autorise les requêtes entrantes uniquement à partir du profil Azure Front Door spécifié.

4. Application Gateway transfère le trafic autorisé vers l'adresse IP de l'équilibreur de charge dans l'instance Spring Apps approvisionnée.

5. L'équilibreur de charge interne achemine uniquement le trafic de Application Gateway vers les services back-end. Ces services sont hébergés dans Spring Apps instance à l'intérieur d'un réseau virtuel dans chaque région.

6. Dans le cadre du traitement de la requête, l’application communique avec d’autres services Azure au sein du réseau virtuel. Par exemple, l'application communique avec Azure Key Vault pour les secrets et la base de données pour le stockage de l'état.

Diffusion mondiale

Si vous concevez pour une haute disponibilité, vous pouvez configurer cette architecture en mode actif-actif, actif-passif avec secours à chaud ou actif-passif avec secours à froid.

Votre choix dépend des exigences de disponibilités pour votre application. Cette architecture utilise le déploiement actif/actif dans deux régions, car l'échantillon de l'organisation souhaite avoir une présence mondiale avec un contrat SLA (Contrat de niveau de service) à durée de bon fonctionnement élevée. Si vous exécutez des applications stratégiques et que vous souhaitez une disponibilité plus élevée, vous devez utiliser plus de deux régions.

Actif/actif

En mode actif/actif, toutes les régions traitent les requêtes simultanément. Le plus grand défi avec le mode actif/actif est de maintenir la synchronisation des données entre les régions. Ce mode est une approche coûteuse parce que vous payez deux fois pour presque tous les composants.

Mode actif-passif avec serveur de secours

En mode actif/passif avec serveur de secours, la région secondaire ne reçoit aucune requête d'Azure Front Door tant que la région primaire est active. Veillez à répliquer vos données d’application de votre région primaire sur votre région secondaire. Si une défaillance se produit dans votre région primaire, vous devez changer les rôles de vos bases de données back-end et basculer tout le trafic via Azure Front Door vers votre région secondaire.

En mode actif/passif, le basculement devrait prendre un certain temps, ce qui facilite la synchronisation de toutes les données. Toutefois, le mode actif/passif avec serveur de secours est aussi coûteux que l'utilisation du mode actif-actif.

Mode actif/passif avec reprise progressive

En mode actif/passif avec reprise progressive, la région primaire dispose de toutes les ressources et sert le trafic. La région secondaire peut avoir moins de composants ou des composants avec des ressources de calcul inférieures. Les choix technologiques dépendent de la quantité de temps d'arrêt acceptable en fonction des besoins de l'entreprise. L’étendue de la configuration de votre région secondaire affecte également les coûts. Assurer-vous qu’au moins les données d’application sont présentes dans la région secondaire.

Comme nous l'avons mentionné, le mode actif/passif comprend un basculement qui prend un certain temps, de sorte qu'il est plus facile de maintenir toutes les données synchronisées. Le mode actif/passif en reprise progressive est l'approche la plus rentable, car il n'est pas nécessaire de déployer toutes les ressources dans les deux régions.

Si l'ensemble de votre configuration de solution utilise des modèles, vous pouvez facilement déployer une région secondaire de reprise progressive en créant ses ressources en fonction des besoins. Vous pouvez utiliser des modèles Terraform, Bicep ou Azure Resource Manager et automatiser la configuration de l’infrastructure dans un pipeline d’intégration continue/déploiement continu (CI/CD). Vous devez tester régulièrement votre configuration en recréant votre région secondaire pour vous assurer que vos modèles peuvent être déployés en cas d'urgence.

Le modèle empreintes de déploiement est recommandé, car plusieurs copies indépendantes d'une application ou d'un composant peuvent être déployées à partir d'un modèle unique vers plusieurs régions.

Comparaison des modes

Le tableau suivant résume l'effort nécessaire pour synchroniser les données pour chaque mode et compare les coûts.

Routage entre régions

Cette architecture de référence utilise des nœuds géographiques (géodes) où n'importe quelle région peut traiter n'importe quelle requête.

Azure Front Door est configuré avec un routage égal entre les deux régions de déploiement. Azure Front Door fournit également d’autres méthodes de routage du trafic vers l’origine. Si vous souhaitez acheminer les clients vers leur origine la plus proche, le routage basé sur la latence est le plus judicieux. Si vous concevez une solution active-passive, le routage basé sur les priorités convient mieux.

L'exemple d'architecture de référence utilise une règle d'équilibrage de charge à poids égal entre les deux régions. Azure Front Door est configuré avec :

• Un domaine personnalisé et un certificat TLS (Transport-Layer Security) portant le même nom que le nom d'hôte de l'application, tel que www.contoso.com.

• Une origine par région où l'application est déployée, où chaque origine est une instance Azure Application Gateway.

Disposition du groupe de ressources

Utilisez des groupes de ressources Azure pour gérer les ressources déployées dans chaque région comme une seule collection. Envisagez de placer la région primaire, la région secondaire et Azure Front Door dans des groupes de ressources distincts, comme montré dans le schéma suivant :

Le diagramme montre la configuration suivante des groupes de ressources :

• Azure Front Door est déployé dans le groupe de ressources Application-shared.
• Toutes les ressources hébergées dans la région Europe Ouest (weu) sont déployées dans le groupe de ressources Application-weu.
• Toutes les ressources hébergées dans la région USA Est (eus) sont déployées dans le groupe de ressources Application-eus.
• Toutes les ressources hébergées dans la région Japon Est (jae) sont déployées dans le groupe de ressources Application-jae.

Les ressources dans le même groupe de ressources partagent le même cycle de vie et peuvent être facilement créées et supprimées ensemble. Chaque région a son propre ensemble de ressources dans un groupe de ressources dédié qui suit une convention d'affectation de noms basée sur le nom de la région. Azure Front Door se trouve dans son propre groupe de ressources parce qu'il doit exister, même si d'autres régions sont ajoutées ou supprimées.

Configuration du proxy inverse

Azure Front Door procède à un équilibrage de charge mondial entre les régions. Ce proxy inverse permet de distribuer le trafic si vous déployez une charge de travail dans plusieurs régions. Vous pouvez également utiliser Azure Traffic Manager. Traffic Manager est un équilibreur de charge de trafic basé sur le DNS qui équilibre les charges uniquement au niveau du domaine.

Azure Front Door a intégré des réseaux de distribution de contenu (CDN) qui fournissent du contenu à partir du réseau de périphérie mondial de Microsoft avec des points de présence (PoP) distribués dans le monde entier.

La solution actuelle utilise deux proxys inverses pour maintenir la cohérence avec l’architecture de base. Azure Front Door est le routeur global. Application Gateway fait office d’équilibreur de charge par région. Dans la plupart des cas, cette configuration n'est pas nécessaire. Vous pouvez supprimer Application Gateway si vous répondez aux conditions suivantes :

• Comme Azure Web Application Firewall est attaché à Application Gateway, vous devez plutôt l'attacher au service Azure Front Door.
• Vous avez besoin d’un moyen de vous assurer que les appels entrants proviennent uniquement de l’instance Azure Front Door. Vous pouvez ajouter une vérification de X-Azure-FDID header et une vérification des plages d'adresses IP Azure Front Door dans l'application Spring Cloud Gateway. Pour plus d'informations, reportez-vous à Utiliser Azure Front Door comme proxy inverse avec la passerelle Spring Cloud.

Pour plus d’informations sur les différents 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.

Base de données back-end

Pour un déploiement multirégion, vous devez disposer d’une stratégie de réplication des données. Lorsque l'application est disponible dans plusieurs régions, les données doivent être synchronisées afin que les utilisateurs ne voient pas les données obsolètes.

L'architecture actuelle utilise une base de données MySQL pour la base de données dorsale, mais cette configuration ne tient pas compte de la synchronisation de données. Lorsque vous choisissez une technologie de base de données, case activée comment répliquer et synchroniser au mieux les données entre les régions. L'une des options est Azure SQL Database, qui dispose d'une fonction de géoréplication active qui fournit une base de données secondaire accessible en lecture synchronisée en permanence pour une base de données primaire.

Vous pouvez utiliser cette fonctionnalité dans les scénarios suivants :

• Si votre région secondaire est une région à reprise progressive qui ne reçoit pas de requêtes actives
• Pour basculer si votre région primaire échoue
• Pour configurer des bases de données primaires et secondaires avec des connexions de liaison privée à leurs régions respectives via l'appairage de réseaux virtuels entre les deux régions.

Une autre approche consiste à utiliser Azure Cosmos DB. Ce service peut distribuer à l'échelle mondiale des données en les répliquant de manière transparente dans toutes les régions de votre compte Azure Cosmos DB. Vous pouvez également configurer Azure Cosmos DB avec plusieurs régions d’écriture. Pour plus d’informations, consultez la rubrique Modèle Geode.

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 garantit que l'infrastructure est configurée de manière identique, ce qui aide à éviter la dérive de configuration, par exemple entre les régions. L’automatisation de l’infrastructure permet également de tester les opérations de basculement.

Pour le déploiement d'applications, assurez-vous que vos systèmes de déploiement ciblent les différentes régions dans lesquelles ils doivent être déployés. Vous pouvez également utiliser plusieurs régions dans une stratégie de déploiement bleu-vert ou canary. Avec ces stratégies de déploiement, vous déployez de nouvelles versions d'applications dans une région à des fins de test et dans d'autres régions une fois que le test réussit.

Performances et évolutivité

Cette architecture est mieux adaptée que l'architecture de base pour répondre aux demandes des applications, car elle répartit la charge entre des zones. Si vous configurez Azure Front Door pour acheminer les requêtes en fonction de la latence, les utilisateurs obtiennent de meilleurs temps de réponse parce que les requêtes sont acheminées vers les régions les plus proches.

Selon la configuration de votre base de données, vous risquez d’entraîner davantage de latence lorsque les données doivent être synchronisées entre les régions. Vous pouvez surmonter cette latence en utilisant Azure Cosmos DB avec un niveau de cohérence plus souple.

Cette architecture de référence comporte plusieurs composants qui peuvent être mis à l'échelle automatiquement en fonction des métriques :

• Azure Front Door peut être mis à l’échelle automatiquement en fonction de la demande. Vous pouvez utiliser d'autres fonctionnalités Azure Front Door comme l'accélération du trafic et les fonctions de mise en cache pour rapprocher les ressources de vos utilisateurs finaux.
• Application Gateway prend en charge la mise à l’échelle automatique. Pour plus d'informations, reportez-vous à Mettre à l'échelle Application Gateway v2 et Web Application Firewall v2.
• Azure Spring Apps prend également en charge la mise à l’échelle automatique. Pour plus d’informations, consultez Configurer la mise à l’échelle automatique pour les applications.

Considérations relatives au coût

Cette solution double les coûts estimés de l’architecture de base efficacement.

Les principaux facteurs de coûts associés à la solution multirégion sont les suivants :

• Les bases de données primaire et secondaire doivent utiliser le même niveau de service, sinon la base de données secondaire risque de ne pas suivre les modifications apportées à la réplication.
• Un trafic interrégion dense augmente les coûts. Le trafic réseau entre les régions Azure entraîne des frais.

Pour gérer ces coûts, tenez compte des suggestions suivantes pour votre mise en œuvre :

• Utilisez des versions réduite des ressources comme Azure Spring Apps et Application Gateway dans la région de secours, et effectuez une augmentation des ressources uniquement lorsque la région de secours devient active.
• Si les scénarios de votre entreprise le permettent, créez une configuration active-passive pour réduire les coûts.
• Mettez en place une configuration multizone dans une seule région pour répondre aux besoins de disponibilité et de résilience des entreprises. Cette option peut être plus rentable, car vous ne payez la plupart des ressources qu'une seule fois.
• Choisissez l'autre configuration qui n'utilise qu'un seul proxy inverse pour vous aider à réduire les coûts. Gardez à l'esprit que vous devez appliquer une configuration supplémentaire pour maintenir la sécurité de cette alternative.

Nous avons estimé le coût des services dans cette architecture avec la calculatrice de prix Azure en utilisant des valeurs par défaut raisonnables pour une application à petite échelle. Vous pouvez mettre à jour cette estimation en fonction des valeurs de débit attendues pour votre application.

Autres considérations

Les considérations relatives à la conception de l'architecture de ligne de base multizone s'appliquent également à la solution multirégion décrite dans cet article. Examinez les points suivants dans le contexte de l'architecture multirégion :

• Sécurité réseau. Il est important de contrôler la communication via le réseau. Cette solution n'autorise les appels entrants qu'à partir d'Azure Front Door, où les appels sont acheminés vers Application Gateway dans chaque région. À partir de la passerelle applicative, les appels sont acheminés vers le service Azure Spring Apps de back-end. La communication d'Azure Spring Apps vers les services secondaires comme Key Vault est également contrôlée à l'aide de points de terminaison privés. Pour plus d'informations, reportez-vous à architecture de base : sécurité réseau.

• Gestion des identités et des accès. Mettez en œuvre un accès plus sécurisé en utilisant des identités managées pour la connexion entre différents composants. Par exemple, Azure Spring Apps utilise une identité managée pour se connecter à Key Vault. Pour plus d'informations, reportez-vous à Architecture de base : gestion des identités et des accès.

• Supervision. Vous pouvez ajouter l'instrumentation et activer le suivi distribué pour collecter des données à partir de l'application. Combinez cette source de données avec des diagnostics de plateforme pour obtenir un aperçu de bout en bout de votre application. Pour plus d'informations, reportez-vous àarchitecture de base : supervision.

• Gestion des secrets. La solution multirégion stocke les secrets et certificats d'application dans un seul coffre de clés. Pour plus d'informations, reportez-vous à Architecture de ligne de base : gestion des secrets.

Déploiement de scénarios

Un déploiement pour cette architecture de référence est disponible dans Architecture de référence multirégion Azure Spring Apps sur GitHub. Le déploiement utilise des modèles Terraform.

Pour déployer l’architecture, suivez les instructions pas à pas.

Contributeurs

Microsoft gère ce contenu. Le contributeur suivant a développé le contenu original.

Auteur principal :

• Gitte Vermeiren | Ingénieur FastTrack pour Azure

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

Étapes suivantes

Pour intégrer cette charge de travail aux services partagés gérés par les équipes centrales de votre organisation, déployez-la dans une zone d'atterrissage de l'application Azure.

Ressources associées

Reportez-vous aux articles suivants pour obtenir de la documentation sur les services et fonctionnalités Azure utilisés dans cette architecture :

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database pour MySQL
• Azure Key Vault
• DNS Azure
• Pare-feu d’applications web Azure
• Azure Private Link
• Identités managées pour les ressources Azure Microsoft Entra

Nous recommandons les guides suivants pour une meilleure compréhension des choix de configuration de cette architecture :

• Exposer des applications Azure Spring Apps par le biais d’un proxy inverse
• Déploiement bleu/vert haute disponibilité pour les applications
• Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end

Cette architecture est conçue en conformité avec les piliers du Microsoft Azure Well-Architected Framework. Nous vous recommandons de passer en revue les principes de conception de chaque pilier.