Résumé

  • 2 minutes

Contoso Shoes est un magasin de chaussures en ligne qui veut avoir une haute disponibilité lors d’un lancement à venir. Ils ont migré leurs déploiements locaux vers le cloud il y a deux ans et profitent de l’adoption du modèle OpEx. Au cours des six derniers mois, ils ont rencontré des problèmes de disponibilité que les opérateurs ne peuvent pas résoudre rapidement. L’organisation souhaite maintenant investir pour que la charge de travail devienne critique pour l’entreprise, et se concentrer sur le renforcement de la fiabilité et de l’observabilité générales du système.

Dans l’architecture précédente, l’application était déployée dans une seule région et ne résistait pas aux pannes régionales. Azure App Service et les outils de monitoring externes n’avaient pas de moyen de vérifier l’état d’intégrité de l’application elle-même. Cette lacune a obligé le routage du trafic vers des instances App Service non saines entraînant l’échec des demandes. L’équipe n’a pas pu voir l’impact en cascade des problèmes, liés à un composant d’API qui affectait ses dépendances de plateforme.

En relevant ce défi, vous avez exploré une conception de haut niveau critique pour l’entreprise. Vous avez appliqué ce que vous avez appris à travers des exercices afin de répondre aux besoins de Contoso.

La conception améliorée détecte les performances dégradées d’un ou de plusieurs composants en utilisant un modèle d’intégrité. L’équipe SRE peut désormais rapidement identifier et résoudre les problèmes avant qu’ils n’entraînent une panne totale. Maintenant que la solution est déployée sur plusieurs régions dans un modèle actif-actif, elle peut supporter une défaillance régionale totale tout en donnant à l’équipe des opérateurs davantage d’insights sur l’intégrité du système. Contoso a également amélioré son expérience client en servant les clients plus rapidement dans une région géographiquement plus proche d’eux.

Félicitations ! Vous avez réussi ce projet de défi. Vous avez validé vos compétences en analysant un exemple de solution existant et en concevant une architecture améliorée.

Étapes suivantes suggérées

Les exercices que vous avez effectués sont un excellent début, mais ils ne couvrent pas tous les aspects d’une charge de travail critique pour l’entreprise. Continuez à explorer les principes de conception et les domaines indiqués dans Charges de travail Well-Architected critiques pour l’entreprise. Nous vous recommandons ces domaines clés :

  • Validation et test continus

    Vous devez vérifier entièrement l’intégrité du code d’application et de l’infrastructure. Le sujet doit couvrir les exigences définies pour la fiabilité, les performances, la disponibilité, la sécurité, la qualité et l’échelle.

    En savoir plus : Validation et test continus

  • Utiliser plusieurs environnements d’application

    Nous recommandons vivement que les environnements dev/test ne partagent pas de ressources avec l’environnement de production. Chaque environnement a son propre ensemble d’exigences en termes de fiabilité, capacité et sécurité. Pouvez-vous identifier les services de cette architecture qui sont partagés par les environnements ? Comment changer la conception pour tenir compte de cette recommandation ?

    En savoir plus : Environnements d’application

  • Environnements de déploiement étendus

    Les systèmes critiques pour l’entreprise nécessitent des tests de préversion rigoureux et des pratiques de cycle de vie de développement logiciel (SDLC) solides. Au lieu d’un seul environnement de développement partagé, utilisez plusieurs environnements éphémères plus adaptés à la préproduction et la production. Vous devez utiliser un environnement intermédiaire dédié pour les tests de charge et de performance, les tests de chaos, les tests d’acceptation utilisateur (UAT) et les tests de sécurité.

    En savoir plus : Déploiements bleu/vert éphémères

  • Ajouter une résilience avec les répartiteurs de messages

    Introduisez un répartiteur de messages pour vous aider à gérer les transactions complexes nécessitant une coordination entre plusieurs points de terminaison. Les demandes à traiter peuvent être mises en file d’attente au lieu de risquer de perdre une vente à cause de l’échec d’un seul composant.

    En savoir plus : Architecture faiblement couplée pilotée par les événements

En savoir plus

Pour plus d’informations sur la conception de solutions sur Azure, consultez le guide Azure Well-Architected Framework.

Explorez ces architectures de référence dans le Centre des architectures Azure, comme moyen de développer votre conception :