Modèle d’application web fiable pour Java : planifier l’implémentation

Cet article vous montre comment planifier une implémentation du modèle d’application web fiable. Le modèle d’application web fiable est un ensemble de principes et de techniques d’implémentation qui définissent la façon dont vous devez modifier des applications web (création d'une nouvelle plateforme d'applications) lors de la migration vers le cloud. Il met l'accent sur les mises à jour minimales du code que vous devez effectuer pour tirer une expérience positive du cloud.

Pour faciliter la mise en œuvre de ces conseils, vous pouvez déployer l'implémentation de référence du modèle d'application web fiable.

Architecture de l'implémentation de référence. Téléchargez un fichier Visio de cette architecture.

Les instructions suivantes utilisent l’implémentation de référence comme exemple tout au long de cet article. Pour planifier une implémentation du modèle d'application web fiable, procédez comme suit :

Définir les objectifs métier

La première étape de la transition vers le cloud computing consiste à définir vos objectifs métier. Le modèle d'application web fiable met l’accent sur l’importance de définir des objectifs immédiats et futurs pour votre application web. Ces objectifs influencent votre choix de services cloud et l’architecture de votre application web dans le cloud.

Exemple : La société fictive Contoso Fiber souhaitait étendre son application web CAMS (Customer Account Management System) locale à d'autres régions. Pour répondre à la demande croissante de l'application web, elle s'est fixé les objectifs suivants :

• Appliquer des modifications de code à faible coût et à forte valeur ajoutée
• Atteindre un objectif de niveau de service (SLO) de 99,9 %
• Adopter des pratiques DevOps
• Créer des environnements à coût optimisé
• Améliorer la fiabilité et la sécurité

Contoso Fiber a déterminé que son infrastructure locale n'était pas une solution rentable pour mettre à l’échelle l’application. La société a donc décidé que la migration de son application web CAMS vers Azure était le moyen le plus rentable d'atteindre ses objectifs immédiats et futurs.

Choisir les services gérés appropriés

Lorsque vous migrez une application web vers le cloud, vous devez sélectionner des services Azure qui répondent à vos exigences métier et s'alignent sur les fonctionnalités actuelles de l'application web locale. Cet alignement permet de réduire l'effort de replatforming. Par exemple, optez pour des services qui vous permettent de conserver le même moteur de base de données et de prendre en charge les middleware et frameworks existants. Les sections suivantes fournissent des conseils pour sélectionner les services Azure appropriés pour votre application web.

Exemple : Avant la migration vers le cloud, l’application web CAMS de Contoso Fiber était une application web Java monolithique locale. Il s’agit d’une application Spring Boot avec une base de données PostgreSQL. L’application web est une application d’assistance métier. Il est accessible aux employés. Les employés de Contoso Fiber utilisent l'application pour traiter les demandes d'assistance de leurs clients. L’application web locale souffre de problèmes courants. Ces défis incluent des chronologies étendues pour générer et expédier de nouvelles fonctionnalités et difficultés à mettre à l’échelle différents composants de l’application sous une charge plus élevée.

Plateforme d’application

Choisissez la meilleure plateforme d’hébergement d’applications pour votre application web. Azure propose de nombreuses options de calcul pour répondre aux exigences des applications web. Pour vous aider dans votre démarche, consultez l'arbre de décision de calcul Azure.

Exemple : Contoso Fiber a choisi Azure App Service comme plateforme d’application pour les raisons suivantes :

• Progression naturelle. Contoso Fiber a déployé un fichier jar Spring Boot sur son serveur local et souhaitait réduire la quantité de restructuration de ce modèle de déploiement. App Service fournit une prise en charge robuste de l’exécution d’applications Spring Boot, et il était dans la suite logique pour Contoso Fiber d'utiliser App Service. Azure Spring Apps est également une alternative intéressante pour cette application. Si l'application web CAMS de Contoso Fiber utilisait Jakarta EE au lieu de Spring Boot, Azure Spring Apps serait mieux adapté. Pour plus d’informations, consultez Qu’est-ce qu’Azure Spring Apps ? et Java EE, Jakarta EE et MicroProfile sur Azure.

• SLA haut. Il dispose d’un contrat SLA élevé qui répond aux exigences de l’environnement de production.

• Charge de gestion réduite. Il s’agit d’une solution d’hébergement entièrement managée.

• Fonctionnalité de conteneurisation. App Service fonctionne avec des registres d’images de conteneur privés comme Azure Container Registry. Contoso Fiber peut utiliser ces registres pour conteneuriser l’application web à l’avenir.

• Mise à l’échelle automatique. L’application web peut rapidement effectuer un scale-up, un scale-down, un scale-in et un scale-out en fonction du trafic utilisateur.

Gestion des identités

Choisissez la meilleure solution de gestion des identités pour votre application web. Pour plus d’informations, consultez la documentation relative à la comparaison des solutions de gestion des identités et aux méthodes d’authentification.

Exemple : Contoso Fiber a choisi Microsoft Entra ID pour les raisons suivantes :

• Authentification et autorisation. Il gère l’authentification et l’autorisation des employés.

• Scalabilité. Il est mis à l’échelle pour prendre en charge des scénarios plus grands.

• Contrôle d’identité utilisateur. Les employés peuvent utiliser leurs identités d’entreprise existantes.

• Prendre en charge les protocoles d’autorisation. Il prend en charge OAuth 2.0 pour les identités managées.

Base de données

Choisissez la meilleure base de données pour votre application web. Pour vous aider dans votre démarche, consultez l'arbre de décision de magasin de données Azure.

Exemple : Contoso Fiber a choisi Azure Database pour PostgreSQL et l’option de serveur flexible pour les raisons suivantes :

• Fiabilité. Le modèle de déploiement de serveur flexible prend en charge la haute disponibilité redondante interzone sur plusieurs zones de disponibilité. Cette configuration maintient un serveur de secours actif dans une autre zone de disponibilité au sein de la même région Azure. La configuration réplique les données de manière synchrone sur le serveur de secours.

• Réplication entre régions. Il dispose d’une fonctionnalité de lecture réplica qui vous permet de répliquer de manière asynchrone des données vers une base de données réplica en lecture seule dans une autre région.

• Les performances. Il fournit des performances prévisibles et un réglage intelligent pour améliorer les performances de votre base de données en utilisant des données d’utilisation réelles.

• Charge de gestion réduite. Il s’agit d’un service Azure entièrement managé qui réduit les obligations de gestion.

• Prise en charge de la migration. Il prend en charge la migration de bases de données à partir de bases de données PostgreSQL à serveur unique locaux. La société peut utiliser l'outil de migration pour simplifier le processus.

• Cohérence avec les configurations locales. Il prend en charge différentes versions de communauté de PostgreSQL, y compris la version actuellement utilisée par Contoso Fiber.

• Résilience. Le déploiement de serveur flexible crée automatiquement des sauvegardes de serveur et les conserve en utilisant un stockage redondant interzone (ZRS) dans la même région. Contoso Fiber peut restaurer sa base de données à n’importe quel instant dans le passé s’inscrivant dans la période de rétention des sauvegardes. La fonctionnalité de sauvegarde et de restauration offre un meilleur RPO (quantité acceptable de perte de données) que Contoso Fiber pourrait créer localement.

Analyse des performances des applications

Choisissez un outil de monitoring des performances des applications pour votre application web. Application Insights est la solution de gestion des performances des applications (APM) native d'Azure. Il s’agit d’une fonctionnalité de la solution de supervision Azure, Azure Monitor.

Exemple : Contoso Fiber a ajouté Application Insights pour les raisons suivantes :

• Détection des anomalies. Il détecte automatiquement les problèmes de performances.

• Résolution des problèmes. Elle aide à diagnostiquer les problèmes dans l’application en cours d’exécution.

• Données de télémétrie. Elle collecte des informations sur la façon dont les utilisateurs utilisent l’application et vous permet d’envoyer facilement des événements personnalisés que vous souhaitez suivre dans votre application.

• Manque de visibilité locale. La solution locale n’a pas de solution de supervision des performances des applications. Application Insights offre une intégration facile à la plateforme et au code de l’application.

Cache

Choisissez si vous souhaitez ajouter du cache à votre architecture d’application web. Azure Cache pour Redis est la solution de cache principale d’Azure. Il s'agit d'un magasin de données managé en mémoire basé sur le logiciel Redis.

Exemple : Contoso Fiber avait besoin d'un cache offrant les avantages suivants :

• Vitesse et volume. Avoir un débit de données élevé et des lectures à faible latence pour les données couramment sollicitées et à variation lente.

• Prise en charge diversifiée. Il s’agit d’un emplacement de cache unifié que toutes les instances de l’application web peuvent utiliser.

• Magasin de données externe. Les serveurs d’applications locaux ont effectué la mise en cache locale de la machine virtuelle. Cette configuration n’a pas déchargé les données très fréquentées et n’a pas pu invalider les données.

• Sessions non persistantes. Le cache permet à l’application web d’externaliser l’état de session à l’aide de sessions non persistantes. La plupart des applications web Java exécutées localement utilisent la mise en cache côté client en mémoire. En mémoire, la mise en cache côté client n’est pas correctement mise à l’échelle et augmente l’empreinte mémoire sur l’hôte. En utilisant Azure Cache pour Redis, Contoso Fiber dispose d’un service de cache évolutif entièrement managé pour améliorer la scalabilité et les performances de ses applications. Contoso Fiber utilisait une infrastructure d’abstraction de cache (Spring Cache) et n'a eu besoin que de changements de configuration minimes pour remplacer le fournisseur de cache. Cela leur a permis de passer d’un fournisseur Ehcache au fournisseur Redis.

Équilibreur de charge

Choisissez le meilleur équilibreur de charge pour votre application web. Azure dispose de plusieurs équilibreurs de charge. Pour vous aider dans votre démarche, consultez la documentation relative au choix du meilleur équilibreur de charge pour votre application.

Exemple : Contoso Fiber a choisi Front Door comme équilibreur de charge global pour les raisons suivantes :

• Flexibilité du routage. Il permet à l’équipe de l’application de configurer les besoins d’entrée pour prendre en charge les modifications futures de l’application.

• Accélération du trafic. Il utilise anycast pour atteindre le point de présence Azure le plus proche et trouver l’itinéraire le plus rapide vers l’application web.

• Domaines personnalisés. Il prend en charge les noms de domaine personnalisés avec la validation de domaine flexible.

• Sondes d’intégrité. L’application a besoin d’une surveillance intelligente de la sonde d’intégrité. Azure Front Door utilise alors les réponses fournies par la sonde pour identifier la « meilleure » origine vers lesquels acheminer les requêtes de vos clients.

• Surveillance de la prise en charge. Il prend en charge des rapports intégrés avec un tableau de bord tout-en-un pour Front Door et pour les modèles de sécurité. Vous pouvez configurer des alertes qui s’intègrent à Azure Monitor. Il permet à l’application de journaliser chaque requête et les sondes d’intégrité ayant échoué.

• Protection DDoS. Il dispose d’une protection DDoS de couche 3 à 4 intégrée.

Pare-feu d’application web

Choisissez un pare-feu d’applications web pour protéger votre application web contre les attaques web. Azure Web Application Firewall (WAF) est le pare-feu d’applications web d'Azure, qui fournit une protection centralisée de vos applications web contre les vulnérabilités et exploitations web courantes.

Exemple : Contoso Fiber a choisi Web Application Firewall pour les raisons suivantes :

• Protection globale. Il offre une protection globale améliorée des applications web sans sacrifier les performances.

• Protection contre les botnets. Vous pouvez configurer des règles de protection bot pour surveiller les attaques botnet.

• Parité avec l’environnement local. La solution locale est exécutée derrière un pare-feu d’applications web géré par TI.

Gestionnaire de secrets

Utilisez Azure Key Vault si vous gérez des secrets dans Azure.

Exemple : Contoso Fiber gère des secrets. La société a utilisé Key Vault pour les raisons suivantes :

• Chiffrement. Il prend en charge le chiffrement au repos et en transit.

• Prise en charge des identités managées. Les services d’application peuvent utiliser des identités managées pour accéder au magasin de secrets.

• Supervision et journalisation. Il facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés changent.

• Intégration. Elle prend en charge deux méthodes pour que l’application web accède aux secrets. Contoso Fiber peut utiliser les paramètres de l’application dans la plateforme d’hébergement (App Service) ou référencer le secret dans son code d’application (fichier de propriétés de l’application).

Sécurité des points de terminaison

Choisissez d’activer l’accès privé uniquement aux services Azure. Azure Private Link permet d’accéder à des solutions de plateforme en tant que service via un point de terminaison privé sur votre réseau virtuel. Le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft.

Exemple : Contoso Fiber a choisi Private Link pour les raisons suivantes :

• Sécurité renforcée. Il permet à l’application d’accéder en privé aux services sur Azure et réduit l’empreinte réseau des magasins de données pour aider à se protéger contre les fuites de données.

• Effort minimal. Les points de terminaison privés prennent en charge la plateforme d’application web et la plateforme de base de données utilisées par l’application. Les deux plateformes reflètent l’installation locale existante, de sorte que des modifications minimales sont nécessaires.

Choisir l’architecture appropriée

Après avoir défini les moyens disponibles pour votre application web et sélectionné les services cloud appropriés, vous devez déterminer la meilleure architecture pour votre application web. Votre architecture doit prendre en charge vos exigences métier, les exigences techniques et l’objectif de niveau de service.

Choisir la redondance d’architecture

Les objectifs métier déterminent le niveau d’infrastructure et de redondance des données dont votre application web a besoin. Le SLO de l’application web fournit une bonne base de référence pour comprendre vos exigences de redondance. Calculez le contrat SLA composite en tenant compte de toutes les dépendances sur le chemin critique de disponibilité. Les dépendances doivent inclure des services Azure et des solutions non Microsoft.

Attribuez une estimation de disponibilité à chaque dépendance. Les contrats de niveau de service (SLA) fournissent un bon point de départ, mais ils ne tiennent pas compte du code, des stratégies de déploiement et des décisions architecturales en matière de connectivité.

Exemple : L’implémentation de référence prévoit l'utilisation de deux régions dans une configuration active-passive. Contoso Fiber avait un SLO de 99,9 % et devait utiliser deux régions pour atteindre le SLO. La configuration active-passive s’aligne sur l’objectif de Contoso Fiber de réduire autant que possible les modifications de code pour cette phase de la transition vers le cloud. La configuration actif-passive fournit une stratégie de données simple. Elle évite d’avoir à configurer la synchronisation des données basée sur les événements, les partitions de données ou une autre stratégie de gestion des données. Tout le trafic entrant se dirige vers la région active. En cas de défaillance dans la région active, Contoso Fiber lance manuellement son plan de basculement et achemine tout le trafic vers la région passive.

Choisir une topologie de réseau

Choisissez la topologie de réseau adaptée à vos exigences web et de mise en réseau. La topologie de réseau hub-and-spoke est la configuration standard d'Azure. Elle offre des avantages en matière de coût, de gestion et de sécurité. Elle prend également en charge les options de connectivité hybride pour les réseaux locaux.

Exemple : Contoso Fiber a choisi une topologie de réseau hub-and-spoke pour renforcer la sécurité de son déploiement multirégion tout en réduisant les coûts et les frais généraux de gestion.

Choisir la redondance des données

Assurez la fiabilité des données en les répartissant entre les régions et les zones de disponibilité d'Azure ; plus la séparation géographique est importante, plus la fiabilité est élevée.

• Définissez un objectif de point de récupération (RPO). Le RPO définit la perte maximale de données tolérable pendant une panne, ce qui détermine la fréquence à laquelle les données doivent être répliquées. Par exemple, pour un RPO d'une heure, il faut accepter de perdre jusqu'à une heure de données récentes.

• Implémentez la réplication de données. Alignez la réplication de données sur votre architecture et votre RPO. Azure prend généralement en charge la réplication synchrone dans les zones de disponibilité. L'utilisation de plusieurs zones permet d'améliorer facilement la fiabilité. Pour les applications web multirégions dans une configuration active et passive, répliquez les données dans la région passive en fonction du RPO de l’application web, en veillant à ce que la fréquence de réplication soit supérieure au RPO. Les configurations actives-actives nécessitent une synchronisation des données en quasi-temps réel entre les régions, ce qui peut nécessiter des modifications du code.

• Créez un plan de basculement. Élaborez un plan de basculement (reprise d’activité après sinistre) décrivant les stratégies de réponse aux pannes, caractérisées par un temps d'arrêt ou une perte de fonctionnalité. Spécifiez les objectifs de temps de récupération (RTO) pour le temps d’arrêt maximal acceptable. Veillez à ce que le processus de basculement soit plus rapide que le RTO. Optez pour des mécanismes de basculement automatisés ou manuels afin d'assurer la cohérence et le contrôle, et détaillez le processus de retour à la normale. Testez le plan de basculement pour s'assurer de son efficacité.

Exemple : Pour Azure Database pour PostgreSQL, l’implémentation de référence utilise la haute disponibilité redondante interzone avec des serveurs de secours dans deux zones de disponibilité. La base de données est également répliquée de manière asynchrone vers le réplica en lecture dans la région passive. Contoso Fiber a créé un exemple de plan de basculement. Le réplica en lecture Azure Database pour PostgreSQL est au cœur du plan de basculement de Contoso Fiber.

Étape suivante

Cet article vous a montré comment planifier une implémentation du modèle d’application web fiable. L’étape suivante consiste à mettre en application les techniques d’implémentation du modèle d'application web fiable.