Ce navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Cet article présente un modèle clé pour les architectures critiques sur Azure. Appliquez ce modèle lorsque vous démarrez votre processus de conception, puis sélectionnez les composants les mieux adaptés à vos besoins métier. L’article recommande une approche de conception star nord et inclut d’autres exemples avec des composants technologiques courants.
Nous vous recommandons d’évaluer les domaines de conception clés, de définir les flux d’utilisateurs et de systèmes critiques qui utilisent les composants sous-jacents et de développer une matrice des ressources Azure et de leur configuration tout en gardant à l’esprit les caractéristiques suivantes.
| Caractéristique | Considérations |
|---|---|
| Durée de vie | Quelle est la durée de vie attendue de la ressource, par rapport aux autres ressources de la solution ? La ressource doit-elle survivre, partager la durée de vie avec le système ou la région, ou être temporaire ? |
| State | Quel impact l’état persistant dant cette couche aura-t-il sur la fiabilité ou la gestion ? |
| Reach | La ressource doit-elle être distribuée globalement ? La ressource peut-elle communiquer avec d’autres ressources, situées globalement ou dans cette région ? |
| Les dépendances | Quelles sont les dépendances sur les autres ressources ? |
| Limites de mise à l’échelle | Quel est le débit attendu pour cette ressource ? Quelle échelle la ressource fournit-elle pour répondre à cette demande ? |
| Disponibilité et récupération d’urgence | Quel est l’impact sur la disponibilité d’un sinistre au niveau de cette couche ? Cela entraînerait-il une panne systémique ou uniquement un problème de capacité ou de disponibilité localisé ? |
Important
Cet article fait partie de la série de charges de travail critiques Azure Well-Architected . Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par qu’est-ce qu’une charge de travail stratégique ?
Certaines ressources sont partagées globalement par les ressources déployées dans chaque région. Les ressources utilisées pour distribuer le trafic entre plusieurs régions, stocker l’état permanent de l’ensemble de l’application et surveiller les ressources sont des exemples courants.
| Caractéristique | Considérations |
|---|---|
| Durée de vie | Ces ressources sont censées être durables (non éphémères). Elle est égale ou supérieure à la durée de vie du système. Souvent, les ressources sont gérées avec des mises à jour de plan de contrôle et de données sur place, supposant qu’elles prennent en charge les opérations de mise à jour sans temps d’arrêt. |
| State | Ces ressources existant pendant au moins la durée de vie du système, cette couche est souvent responsable du stockage de l’état géo-répliqué global. |
| Reach | Les ressources doivent être distribuées à l’échelle mondiale et répliquées dans les régions qui hébergent ces ressources. Il est recommandé que ces ressources communiquent avec des ressources régionales ou autres présentant une faible latence et la cohérence souhaitée. |
| Les dépendances | Les ressources doivent éviter les dépendances vis-à-vis des ressources régionales, car leur indisponibilité peut être une cause de défaillance globale. Par exemple, des certificats ou secrets conservés dans un seul coffre pourraient avoir un impact global en cas de défaillance de la région où se trouve le coffre. |
| Limites de mise à l’échelle | Souvent, ces ressources sont des instances singleton dans le système, et elles doivent pouvoir être mises à l’échelle de telle sorte qu’elles puissent gérer le débit du système dans son ensemble. |
| Disponibilité et récupération d’urgence | Les ressources régionales et de tampons peuvent utiliser des ressources globales. Il est essentiel que les ressources globales soient configurées avec une haute disponibilité et une récupération d’urgence pour l’intégrité de l’ensemble du système. |
Le tampon contient l’application et les ressources qui participent à l’exécution des transactions commerciales. Une empreinte correspond généralement à un déploiement dans une région Azure. Une région peut néanmoins avoir plusieurs empreintes.
| Caractéristique | Considérations |
|---|---|
| Durée de vie | Les ressources sont censées avoir une durée de vie éphémère, l’intention étant qu’elles puissent être ajoutées et supprimées de façon dynamique, tandis que les ressources régionales en dehors de l’empreinte continuent de persister. La nature éphémère est nécessaire pour offrir une plus grande résilience, une mise à l’échelle et une proximité avec les utilisateurs. |
| State | Étant donné que les empreintes sont éphémères et qu’elles seront détruites à chaque déploiement, elles doivent être sans état autant que possible. |
| Reach | Peut communiquer avec des ressources régionales et globales. Toutefois, la communication avec d’autres régions ou d’autres empreintes devrait être évitée. |
| Les dépendances | Les ressources d’empreinte doivent être indépendantes. Ils sont censés avoir des dépendances régionales et globales, mais ne doivent pas s’appuyer sur des composants dans d’autres empreintes dans la même région ou dans d’autres régions. |
| Limites de mise à l’échelle | Le débit est établi par le biais de tests. Le débit de l’empreinte globale est limité à la ressource la moins performante. Le débit d’empreinte doit estimer le niveau élevé de la demande causée par un basculement vers un autre tampon. |
| Disponibilité et récupération d’urgence | En raison de la nature temporaire des empreintes, la récupération d’urgence est effectuée en redéployant l’empreinte. Si l’état de certaines ressources est non sain, l’empreinte, dans son ensemble, peut être détruite et redéployée. |
Un système peut avoir des ressources déployées dans une région, qui survivent aux ressources d’empreinte. Par exemple, les ressources d’observabilité qui surveillent les ressources au niveau régional, y compris les empreintes.
| Caractéristique | Considération |
|---|---|
| Durée de vie | Les ressources ont la même durée de vie que la région et survivent aux ressources d’empreinte. |
| State | L’état stocké dans une région ne peut pas vivre au-delà de la durée de vie de la région. Si l’état doit être partagé entre plusieurs régions, envisagez d’utiliser un magasin de données global. |
| Reach | Les ressources n’ont pas besoin d’être distribuées globalement. Une communication directe avec d’autres régions doit être évitée à tout prix. |
| Les dépendances | Les ressources peuvent présenter des dépendances à des ressources globales, mais pas à des ressources d’empreinte, car les empreintes sont censées être de courte durée. |
| Limites de mise à l’échelle | Déterminez la limite d’échelle des ressources régionales en combinant tous les empreintes au sein de la région. |
Ces exemples de base servent d’architecture nord-star recommandée pour les applications stratégiques. La base de référence recommande vivement la conteneurisation et l’utilisation d’un orchestrateur de conteneurs pour la plateforme d’application. La base de référence utilise Azure Kubernetes Service (AKS).
Reportez-vous à Charges de travail stratégiques Well-Architected : Conteneurisation.
Si vous commencez tout juste votre parcours stratégique, utilisez cette architecture comme référence. La charge de travail est accessible via un point de terminaison public et ne nécessite pas de connectivité réseau privé à d’autres ressources de l’entreprise.
Cette architecture s’appuie sur l’architecture de base. La conception est étendue pour fournir des contrôles réseau stricts pour empêcher l’accès public non autorisé à partir d’Internet aux ressources de charge de travail.
Cette architecture est appropriée si vous déployez la charge de travail dans une configuration d’entreprise où l’intégration au sein d’une organization plus large est nécessaire. La charge de travail utilise des services partagés centralisés, a besoin d’une connectivité locale et s’intègre à d’autres charges de travail au sein de l’entreprise. Il est déployé dans un abonnement de zone d’atterrissage Azure qui hérite du groupe d’administration Corp.
Cette architecture étend la référence de base en considérant App Services comme technologie d’hébergement d’application principale, fournissant un environnement facile à utiliser pour les déploiements de conteneurs.
Nous vous recommandons d’utiliser les conseils de conception fournis pour parcourir les décisions de conception clés afin d’atteindre une solution optimale. Pour plus d’informations, consultez Quels sont les principaux domaines de conception ?
Passez en revue les meilleures pratiques pour la conception de scénarios d’application stratégiques.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour