Vue d’ensemble du pilier de fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. L’architecture de la fiabilité dans votre infrastructure d’application garantit que vos charges de travail sont disponibles et peuvent récupérer après des défaillances à n’importe quelle échelle.
Une conception visant la fiabilité comprend les éléments suivants :
- La conception d’une architecture à haute disponibilité
- La récupération suite à des défaillances, telles que la perte de données, les temps d’arrêt majeurs ou les incidents de ransomware
Pour évaluer la fiabilité de votre charge de travail à l’aide des principes trouvés dans Microsoft Azure Well-Architected Framework, passez en revue Microsoft Azure Well-Architected.
Pour plus d’informations, regardez la vidéo suivante pour en savoir plus sur la fiabilité de la charge de travail Azure :
Les développeurs d’applications se sont traditionnellement concentrés sur l’allongement du temps moyen entre les défaillances (MTBF). Ils se sont efforcés d’empêcher les défaillances du système. Le cloud computing ne nécessite pas le même état d’esprit en raison de plusieurs facteurs :
- Les systèmes distribués sont complexes. Une défaillance à un moment donné peut potentiellement être en cascade dans tout le système.
- Les coûts des environnements cloud restent faibles grâce au matériel de base. Des défaillances matérielles occasionnelles doivent être attendues.
- Les applications dépendent souvent de services externes. Ces services peuvent être temporairement indisponibles ou limiter les utilisateurs à volume élevé.
- Les utilisateurs actuels s’attendent à ce qu’une application soit disponible 24 heures sur 24 et 7 jours sur 7 sans jamais se déconnecter.
Tous ces facteurs impliquent que les applications de cloud soient conçues pour subir des défaillances occasionnelles et les résoudre. Azure dispose de nombreuses fonctionnalités de résilience déjà intégrées à la plateforme, telles que les exemples suivants :
- Stockage Azure, Azure SQL Database et Azure Cosmos DB fournissent une réplication de données intégrée entre les zones de disponibilité et les régions.
- Les disques managés Azure sont automatiquement placés dans diverses unités d’échelle de stockage pour limiter les effets liés aux défaillances matérielles.
- Les machines virtuelles d’un groupe à haute disponibilité sont réparties sur plusieurs domaines d’erreur. Un domaine d’erreur est un groupe de machines virtuelles qui partagent une source d’alimentation et un commutateur réseau communs. La répartition des machines virtuelles sur plusieurs domaines d’erreur limite l’effet des défaillances matérielles physiques, des pannes réseau ou des interruptions d’alimentation.
- Les zones de disponibilité sont des emplacements physiquement distincts au sein d’une région Azure. Chaque zone est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’une infrastructure réseau indépendants. Avec les zones de disponibilité, vous pouvez concevoir et utiliser des applications et des bases de données qui passent automatiquement d’une zone à l’autre sans interruption. Cette approche garantit la fiabilité si une zone est affectée. Pour plus d’informations, reportez-vous aux régions et aux zones de disponibilité Azure.
Même avec ces fonctionnalités, vous devez toujours créer une résilience dans votre application. Les stratégies de résilience peuvent être appliquées à tous les niveaux de l’architecture. Certaines atténuations sont de nature plus tactique, par exemple, la nouvelle tentative d’appel à distance après une défaillance réseau temporaire. Les autres solutions d’atténuation sont plus stratégiques, comme le basculement de l’ensemble de l’application vers une région secondaire.
Les solutions d’atténuation tactiques peuvent faire une grande différence. Bien qu’il soit rare qu’une région entière rencontre une interruption, les problèmes temporaires tels que la congestion du réseau sont plus courants. Ciblez d’abord ces problèmes. Le fait de disposer de l’analyse et des diagnostics adaptés est également important à la fois pour détecter les défaillances lorsqu’elles surviennent et pour rechercher les causes racines.
Lorsque vous concevez une application qui doit être résiliente, vous devez comprendre vos besoins en matière de disponibilité. Quel temps d’arrêt maximal est acceptable ? La quantité de temps d’arrêt est en partie liée au coût. Combien le temps d’arrêt potentiel coûte-t-il à votre entreprise ? Combien devriez-vous investir pour rendre l’application hautement disponible ?
Rubriques et meilleures pratiques
Le pilier de fiabilité couvre les rubriques et les meilleures pratiques suivantes pour vous aider à créer une charge de travail résiliente :
| Article sur la fiabilité | Description |
|---|---|
| Principes de conception de la fiabilité | Ces principes critiques sont utilisés comme objectifs pour évaluer la fiabilité d’une application déployée sur Azure. |
| Concevoir dans un souci de fiabilité | Réfléchissez à la façon dont les systèmes utilisent les zones de disponibilité, effectuent la scalabilité, répondent aux défaillances et d’autres stratégies qui optimisent la fiabilité de la conception des applications. |
| Liste de vérification de la résilience pour des services Azure spécifiques | Chaque technologie a ses propres modes d’échec, que vous devez prendre en compte lorsque vous concevez et implémentez votre application. Utilisez cette liste de vérification pour passer en revue les considérations relatives à la résilience de services Azure spécifiques. |
| Cibler les exigences fonctionnelles et non fonctionnelles | Les exigences fonctionnelles et non fonctionnelles cibles, telles que les cibles de disponibilité et les cibles de récupération, vous permettent de mesurer le temps d’activité et les temps d’arrêt de vos charges de travail. Disposer de cibles clairement définies est essentiel pour avoir un objectif de travail et auquel se référer. |
| Résilience et dépendances | La création d’une récupération après défaillance dans le système doit faire partie intégrante des phases d’architecture et de conception afin d’éviter le risque de défaillance. Le bon fonctionnement des applications requiert des dépendances. |
| Haute disponibilité à l’aide de zones de disponibilité | Les zones de disponibilité permettent répartir une solution sur plusieurs zones au sein d’une région, de sorte qu’une application puisse continuer à fonctionner en cas de défaillance d’une zone. |
| Services disponibles | La disponibilité des services dans les régions Azure dépend du type de région. La stratégie générale d’Azure pour le déploiement de services dans une région donnée est principalement pilotée par le type de région, les catégories de service et la demande des clients. |
| Terminologie des zones de disponibilité | Pour mieux comprendre les régions et les zones de disponibilité dans Azure, il est utile d’en comprendre les principaux termes ou concepts. |
| Meilleures pratiques en matière de fiabilité dans les applications | Pendant la phase de la conception architecturale, veillez à implémenter des pratiques qui respectent les exigences de votre entreprise, identifient les points de défaillance et limitent l’impact des défaillances. |
| Test de la fiabilité | Des tests doivent être effectués dans le cadre de chaque modification majeure pour valider les seuils, les cibles et les hypothèses existants. |
| Supervision de la fiabilité | Procurez-vous une vue d’ensemble de l’intégrité des applications. En cas de défaillance, vous devez savoir de quoi il s’agit, quand cela s’est produit et pourquoi. |
| Modèles de fiabilité | Les applications doivent être conçues et implémentées pour optimiser la disponibilité. |