Préparer

Effectué

Vous allez ajouter vos propres améliorations à une architecture existante qui répond aux exigences de haute fiabilité de l’organisation. Nous décrirons ici le contexte d’arrière-plan dont vous avez besoin pour réussir les exercices.

Contexte du problème

Contoso Shoes doit être prêt pour le prochain lancement de produit très médiatisé, qui devrait entraîner une augmentation significative du trafic. Au cours des deux dernières années, plusieurs incidents ont provoqué la mise hors connexion du site web pendant une demi-journée. Le système n’a pas été testé complètement dans l’environnement dev/test, et certains bogues sont passés en production. La résolution des problèmes a pris beaucoup de temps, car les opérateurs n’ont pas pu identifier rapidement les causes racines.

La société rencontrait des difficultés quand certains composants n’étaient pas disponibles. Les opérations de scale-out sur le calcul étaient impactées quand Azure Key Vault était mal configuré. Par ailleurs, il n’y a pas stratégie en place pour les pannes régionales. Lors d’un incident récent, l’ensemble de la région Europe Ouest est tombée en panne. Comme la charge de travail s’exécutait seulement dans cette région, l’entreprise a subi des pertes financières jusqu’à ce que la région soit à nouveau opérationnelle.

Architecture actuelle

Pour résoudre ce défi, vous devez avoir une bonne compréhension de l’architecture actuelle de Contoso Shoes. Concentrons-nous sur la couche API.

Composants

Tous les composants de cette architecture sont déployés dans une seule région.

• La référence SKU S2 Standard du plan Azure App Service fournit la plateforme de calcul qui héberge l’application. La mise à l’échelle automatique est activée. L’environnement de développement utilise la référence SKU B1 De base.

• Azure App Service fournit la plateforme d’application qui exécute le code d’API dans un conteneur. La fonctionnalité d’authentification App Service est activée pour l’autorisation.

• Les emplacements de déploiement vous permettent de préparer un déploiement, puis de l’échanger avec le déploiement de production. Ils sont utilisés en production uniquement.

• Azure Container Registry stocke le code d’API conteneurisé, et est poussé dans des pipelines d’intégration continue/livraison continue (CI/CD) créés et gérés par l’équipe de charge de travail. Les environnements de production et de développement/test utilisent tous deux le registre de conteneurs.

• Azure Cosmos DB avec l’API SQL stocke tous les états liés à la charge de travail. Le compte de base de données Cosmos DB a une base de données unique qui contient quelques conteneurs dans le modèle de débit partagé. Le compte Azure Cosmos utilise le mode de capacité Serverless. Il y a une instance pour la production et une pour dev/test.

• Azure Key Vault stocke les secrets nécessaires à l’API pour effectuer un appel HTTP POST vers une API externe tierce dans le cadre d’un flux de requête. L’application accède aux secrets par le biais d’une référence Key Vault dans la configuration d’application Azure App Service. Il y a un coffre de clés pour la production et un pour dev/test.

• Azure Log Analytics est utilisé comme récepteur unifié afin de stocker les journaux et les métriques pour tous les paramètres de diagnostics Azure de tous les composants utilisés dans la solution. Il y a un espace de travail pour la production et un pour dev/test.

• Azure Application Insights est utilisé pour capturer les données de télémétrie et les journaux de l’API. Application Insights utilise le mode autonome et n’écrit pas dans un espace de travail Log Analytics dédié. La production et dev/test ne partagent pas d’instance commune.

• Azure Pipelines est utilisé pour CI/CD qui génère, teste et déploie la charge de travail dans les environnements de préproduction et de production. L’équipe de charge de travail gère les pipelines, qui gèrent également l’ensemble de l’infrastructure dans la solution. Bicep est la technologie choisie pour l’infrastructure en tant que code (IaC).

Choix de conception

Dans la liste des composants, le tampon de déploiement se compose de services qui participent au traitement d’une requête. Ces services incluent App Services ainsi que le code de l’API et Cosmos DB. Le tampon inclut également des composants non fonctionnels : Key Vault et Container Registry. L’application a une dépendance tierce sur un framework de performances et de résilience. Des identités gérées par le système sont utilisées entre les composants de l’unité d’échelle.

Dans l’unité d’échelle, App Services est configuré pour être mis à l’échelle automatiquement en fonction de la charge.

Des environnements distincts sont utilisés pour la production et dev/test. L’environnement de production utilise la référence SKU Standard du plan App Service. L’entreprise a fait ce choix afin de pouvoir préchauffer l’application sur un emplacement avant de la déployer en production. L’environnement de développement/test utilise la référence SKU De base afin d’optimiser les coûts. Les deux environnements ont leurs propres instances de services. Les environnements partagent uniquement le registre de conteneurs.

Le code d’API conteneurisé est remis dans une même image conteneur qui s’exécute dans App Service. L’API a plusieurs points de terminaison HTTP utilisés par divers front-ends pour les lectures et les écritures. Les front-ends ne constituent pas l’objet de ce module, mais ils doivent néanmoins être pris en compte lorsque l’on examine l’état stratégique de cette situation dans son ensemble. Le code a été instrumenté avec Application Insights pour capturer des données de télémétrie de base. L’équipe qui a développé ce code gère également le pipeline CI/CD de l’image conteneur de l’API et les pipelines CI/CD.

Compromis

Toutefois, comme partout, des compromis ont été faits avec l’architecture actuelle. Les exigences métier ont donné la priorité à l’optimisation des coûts par rapport à la fiabilité et aux opérations. Pour rester dans les limites de coût, l’architecture n’a pas évolué. Les composants ne sont pas à la hauteur pour tirer parti des fonctionnalités de fiabilité offertes par la plateforme. Par exemple, le choix de la référence SKU du calcul empêche la charge de travail d’utiliser des zones de disponibilité. Pour la télémétrie, une version antérieure d’Application Insights est utilisée qui n’est pas intégrée à Log Analytics.

Par ailleurs, l’accès à la charge de travail est trop généralisé. Par exemple, sans l’intégration d’un réseau virtuel, tous les services Azure peuvent être directement accessibles via l’Internet public.

Quand la solution a été développée, l’équipe de développement d’application n’a utilisé qu’un seul abonnement Azure, et a colocalisé les environnements dev/test et de production dans le même abonnement afin de simplifier l’utilisation des outils par les équipes DevOps. Toutefois, les ressources de production et les ressources dev/test ne sont pas complètement isolées. Certaines ressources sont partagées par les deux environnements, bien qu’elles aient obtenu un abonnement isolé du reste des solutions de Contoso Shoes.

Par ailleurs, l’environnement dev/test est partagé par tous les membres de l’équipe de développement et d’assurance qualité. Le choix était justifié compte tenu de la taille des équipes et du fait que la coordination entre elles n’avait pas besoin d’un degré plus élevé d’isolation. Avec l’évolution de l’équipe et de la solution, l’utilisation d’un seul environnement dev/test a rendu l’intégration de plus en plus complexe à cause de la collision entre les cycles de vie du flux de travail. L’évolution et son impact sur la fiabilité ont représenté un coût important.

Spécification de projet

L’entreprise veut ajouter des fonctionnalités à son architecture de solution pour pouvoir traiter l’augmentation attendue de la charge. Voici les exigences métier :

• Pouvoir résister aux défaillances régionales en étendant l’architecture sur plusieurs régions
• Améliorer l’expérience client en servant les clients plus rapidement dans une région géographiquement plus proche d’eux
• Suivre la feuille de route Azure et tirer parti des dernières fonctionnalités de fiabilité offertes par les services Azure
• Intercepter les problèmes avec anticipation et détecter leur impact en cascade dans le système en créant un modèle d’intégrité général

Ces exigences représentent seulement la liste prioritaire des plans d’amélioration. L’équipe d’application est consciente que tous les domaines de conception doivent être pris en compte pour que la fiabilité de cette solution réponde aux standards critiques pour l’entreprise. Rassurez-vous, ils n’arrêteront pas d’améliorer leur solution et leurs opérations une fois que vous les aurez aidés avec les aspects abordés dans les exercices à venir.

Bienvenue dans l’équipe ! Contoso Shoes est impatient d’entendre vos recommandations.

Programme d’installation

Dans ce projet de défi, vous allez jouer le rôle d’un architecte qui doit aider Contoso Shoes à atteindre ses objectifs de fiabilité, en commençant par les éléments prioritaires définis dans la section précédente.

• Nous vous recommandons d’utiliser l’outil de diagramme d’architecture pour visualiser l’architecture.
• Vous n’avez pas besoin d’un abonnement Azure pour ce défi si vous êtes à l’aise avec les services et leurs fonctionnalités.