Partager via


Principes de conception d’une charge de travail stratégique

La méthodologie de conception critique est soutenue par cinq principes de conception clés qui servent de boussole pour les décisions de conception ultérieures dans les domaines de conception critiques. Nous vous recommandons vivement de vous familiariser avec ces principes pour mieux comprendre leur impact et les compromis associés à la non-adhésion.

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 ?

Principes de conception critiques

Ces principes de conception stratégiques font écho et étendent les piliers de qualité d’Azure Well-Architected Framework : fiabilité, sécurité, optimisation des coûts, excellence opérationnelle et efficacité des performances.

Fiabilité

Fiabilité maximale : recherche fondamentale de la solution la plus fiable, garantissant ainsi que les compromis sont bien compris.

Principe de conception Considérations
Conception active/active Pour optimiser la disponibilité et obtenir une tolérance de panne régionale, les composants de la solution doivent être distribués sur plusieurs régions Zones de disponibilité et Azure à l’aide d’un modèle de déploiement actif/actif, si possible.
Réduction du rayon d’explosion et isolation des pannes L’échec est impossible à éviter dans un environnement cloud multilocataire hautement distribué comme Azure. En anticipant les défaillances et l’impact corrélé, des composants individuels aux régions Azure entières, une solution peut être conçue et développée de manière résiliente.
Observer l’intégrité de l’application Avant de pouvoir atténuer les problèmes affectant la fiabilité des applications, vous devez d’abord les détecter et les comprendre. En surveillant le fonctionnement d’une application par rapport à un état sain connu, il devient possible de détecter ou même de prédire les problèmes de fiabilité, ce qui permet de prendre rapidement des mesures correctives.
Encourager l’automatisation L’une des principales causes de temps d’arrêt de l’application est l’erreur humaine, qu’elle soit due au déploiement de logiciels insuffisamment testés ou à une configuration incorrecte. Pour minimiser la possibilité et l’impact des erreurs humaines, il est essentiel de s’efforcer d’automatiser tous les aspects d’une solution cloud afin d’améliorer la fiabilité . tests, déploiement et gestion automatisés.
Conception de la réparation spontanée La réparation automatique décrit la capacité d’un système à gérer automatiquement les défaillances par le biais de protocoles de correction prédéfinis connectés aux modes d’échec au sein de la solution. Il s’agit d’un concept avancé qui nécessite un haut niveau de maturité du système avec la surveillance et l’automatisation, mais qui doit être une aspiration dès le début pour optimiser la fiabilité.
Évitement de la complexité Évitez une complexité inutile lors de la conception de la solution et de tous les processus opérationnels pour améliorer la fiabilité et l’efficacité de la gestion, ce qui réduit la probabilité de défaillances.

Efficacité des performances

Performances et scalabilité durables : conception de la scalabilité dans l’ensemble de la solution de bout en bout sans goulots d’étranglement des performances.

Principe de conception Considérations
Concevoir en vue d’un scale-out Le scale-out est un concept qui se concentre sur la capacité d’un système à répondre à la demande par le biais d’une croissance horizontale. Cela signifie qu’à mesure que le trafic augmente, davantage d’unités de ressources sont ajoutées en parallèle au lieu d’augmenter la taille des ressources existantes. Une capacité des systèmes à gérer les augmentations de trafic attendues et inattendues par le biais d’unités d’échelle est essentielle pour les performances globales et la fiabilité en réduisant davantage l’impact d’une seule défaillance de ressource.
Automatisation pour hyperscale Les opérations de mise à l’échelle dans l’ensemble de la solution doivent être entièrement automatisées afin de réduire l’impact sur les performances et la disponibilité des augmentations inattendues ou attendues du trafic, en veillant à ce que le temps nécessaire pour effectuer des opérations de mise à l’échelle soit compris et aligné sur un modèle d’intégrité de l’application.
Validation et test continus Des tests automatisés doivent être effectués dans les processus CI/CD pour générer une validation continue pour chaque modification d’application. Les tests de charge par rapport à une base de référence de performances avec une expérimentation de chaos synchronisée doivent être inclus pour valider les seuils, les cibles et les hypothèses existants, ainsi que pour aider à identifier rapidement les risques liés à la résilience et à la disponibilité. Ces tests doivent être effectués dans des environnements intermédiaires et de test, mais aussi éventuellement dans des environnements de développement. Il peut également être utile d’exécuter un sous-ensemble de tests sur l’environnement de production, en particulier conjointement avec un modèle de déploiement bleu/vert pour valider les nouveaux tampons de déploiement avant de recevoir le trafic de production.
Réduire la surcharge avec les services de calcul managés L’utilisation de services de calcul managés et d’architectures conteneurisées réduit considérablement la surcharge administrative et opérationnelle en cours de conception, d’exploitation et de mise à l’échelle des applications en déplaçant le déploiement et la maintenance de l’infrastructure vers le fournisseur de services managés.
Performances de référence et identifier les goulots d’étranglement Les tests de performances avec des données de télémétrie détaillées de chaque composant système permettent d’identifier les goulots d’étranglement au sein du système, y compris les composants qui doivent être mis à l’échelle par rapport à d’autres composants, et ces informations doivent être incorporées dans un modèle de capacité.
Capacité du modèle Un modèle de capacité permet de planifier les niveaux d’échelle des ressources pour un profil de charge donné, et expose également la façon dont les composants système fonctionnent les uns par rapport aux autres, ce qui permet de planifier l’allocation de capacité à l’échelle du système.

Excellence opérationnelle

Opérations par conception : conçues pour durer avec une gestion opérationnelle robuste et assertive.

Principe de conception Considérations
Composants faiblement couplés Le couplage libre permet des tests, des déploiements et des mises à jour indépendants et à la demande pour les composants de l’application tout en réduisant les dépendances entre équipes pour le support, les services, les ressources ou les approbations.
Automatiser les processus de génération et de mise en production Les processus de génération et de mise en production entièrement automatisés réduisent les frictions et augmentent la rapidité de déploiement des mises à jour, ce qui apporte répétabilité et cohérence entre les environnements. L’automatisation raccourcit la boucle de commentaires des développeurs qui poussent des modifications pour obtenir des insights sur la qualité du code, la couverture des tests, la résilience, la sécurité et les performances, ce qui augmente la productivité des développeurs.
Agilité du développeur L’automatisation de l’intégration continue et du déploiement continu (CI/CD) permet d’utiliser des environnements de développement de courte durée avec des cycles de vie liés à celui d’un branche de fonctionnalité associé, ce qui favorise l’agilité des développeurs et favorise la validation le plus tôt possible dans le cycle d’ingénierie afin de réduire le coût d’ingénierie des bogues.
Quantifier l’intégrité opérationnelle L’instrumentation de diagnostic complète de tous les composants et ressources permet une observabilité continue des journaux, des métriques et des traces, mais facilite également la modélisation de l’intégrité pour quantifier l’intégrité des applications dans le contexte des exigences de disponibilité et de performances.
Se préparer à la récupération et aux défaillances Les exercices de planification et de pratique de continuité des activités et de reprise d’activité sont essentiels et doivent être effectués fréquemment, car les apprentissages peuvent améliorer de manière itérative les plans et les procédures pour optimiser la résilience en cas de temps d’arrêt non planifié.
Adopter l’amélioration opérationnelle continue Donnez la priorité à l’amélioration de routine du système et de l’expérience utilisateur, en utilisant un modèle d’intégrité pour comprendre et mesurer l’efficacité opérationnelle avec des mécanismes de rétroaction pour permettre aux équipes d’application de comprendre et de combler les lacunes de manière itérative.

Sécurité

Toujours sécurisé : conception pour une sécurité de bout en bout afin de maintenir la stabilité de l’application et de garantir la disponibilité.

Principe de conception Considérations
Surveiller la sécurité de l’ensemble de la solution et planifier les réponses aux incidents Mettre en corrélation les événements de sécurité et d’audit pour modéliser l’intégrité de l’application et identifier les menaces actives. Établissez des procédures automatisées et manuelles pour répondre aux incidents à l’aide des outils SIEM (Security Information and Event Management) pour le suivi.
Modélisation et tests contre les menaces potentielles Assurez un renforcement des ressources approprié et établissez des procédures pour identifier et atténuer les menaces connues, à l’aide de tests d’intrusion pour vérifier l’atténuation des menaces, ainsi que l’analyse statique du code et l’analyse du code.
Identifier et protéger les points de terminaison Surveillez et protégez l’intégrité réseau des points de terminaison internes et externes via des fonctionnalités de sécurité et des appliances, telles que des pare-feu ou des pare-feu d’applications web. Utilisez des approches standard du secteur pour vous protéger contre les vecteurs d’attaque courants tels que les attaques par déni de service distribué (DDoS), comme SlowLoris.
Protéger contre les vulnérabilités au niveau du code Identifiez et atténuez les vulnérabilités au niveau du code, telles que les scripts intersites ou l’injection SQL, et incorporez la mise à jour corrective de sécurité dans les cycles de vie opérationnels pour toutes les parties du codebase, y compris les dépendances.
Automatisation et utilisation du principe des privilèges minimum Favoriser l’automatisation pour réduire le besoin d’interaction humaine et implémenter les privilèges minimum sur l’application et le plan de contrôle pour vous protéger contre l’exfiltration de données et les scénarios d’acteur malveillant.
Classification et chiffrement des données Classifiez les données en fonction du risque et appliquez le chiffrement standard au repos et en transit, en veillant à ce que les clés et les certificats soient stockés de manière sécurisée et gérés correctement.

Optimisation des coûts

Il existe des compromis de coût évidents associés à l’introduction d’une plus grande fiabilité, qui doivent être soigneusement examinés dans le contexte des exigences de charge de travail.

L’optimisation de la fiabilité peut avoir un impact sur le coût financier global de la solution. Par exemple, la duplication des ressources et la distribution des ressources entre les régions pour atteindre la haute disponibilité ont des implications évidentes sur les coûts. Pour éviter des coûts excessifs, ne surprovisionnez pas ou surprovisionnez au-delà des exigences métier pertinentes.

En outre, il y a un coût supplémentaire associé à l’investissement en ingénierie dans les concepts de fiabilité fondamentaux, tels que l’adoption de l’infrastructure en tant que code, l’automatisation du déploiement et l’ingénierie du chaos. Cela a un coût en termes de temps et d’effort, qui pourrait être investi ailleurs pour fournir de nouvelles fonctionnalités et fonctionnalités d’application.

Conception native cloud

  • Services managés natifs Azure : les services managés natifs Azure sont hiérarchisés en raison de leur faible surcharge administrative et opérationnelle, ainsi que de leur intégration étroite avec une configuration et une instrumentation cohérentes dans la pile d’applications.

  • Alignement de la feuille de route : incorporez les fonctionnalités de service Azure nouvelles et améliorées à mesure qu’elles deviennent en disponibilité générale pour rester proche de la pointe d’Azure.

  • Adopter les fonctionnalités de préversion et atténuer les lacunes connues : alors que les services en disponibilité générale (GA) sont prioritaires pour la prise en charge, les préversions du service Azure sont activement explorées pour une incorporation rapide, en fournissant des commentaires techniques et actionnables aux groupes de produits Azure pour combler les lacunes.

  • Alignement de la zone d’atterrissage Azure : déployable dans une zone d’atterrissage Azure et aligné sur la méthodologie de conception de zone d’atterrissage Azure, mais également entièrement fonctionnel et déployable dans un environnement nu en dehors d’une zone d’atterrissage.

Étape suivante

Passez en revue les préoccupations transversales associées aux charges de travail stratégiques.