Cibler les exigences fonctionnelles et non fonctionnelles

  • Article

Les exigences fonctionnelles et non fonctionnelles des cibles incluent des cibles de disponibilité et descibles de récupération. Ces exigences vous permettent de mesurer le temps d’activité et les temps d’arrêt de vos charges de travail. Il est essentiel d’avoir des objectifs clairement définis pour que vous ayez un objectif à atteindre et à mesurer. Vous devez prendre en compte de nombreuses autres exigences qui améliorent les exigences de fiabilité et répondent aux attentes de l’entreprise.

La résilience signifie la possibilité de récupérer après des défaillances. La disponibilité signifie s’exécuter dans un état sain sans temps d’arrêt important. La création de la résilience et de la disponibilité dans vos applications commence par la collecte des exigences. Par exemple, combien de temps d’arrêt est acceptable et combien coûte un temps d’arrêt potentiel à votre entreprise ?

Points clés

  • Déterminez le niveau de disponibilité acceptable pour vos charges de travail.
  • Déterminez la durée pendant laquelle les charges de travail peuvent être indisponibles et la quantité de données pouvant être perdue pendant un sinistre.
  • Tenez compte des exigences des plateformes de données et des applications pour améliorer la résilience et la disponibilité.
  • Assurez la disponibilité des connexions et améliorez la fiabilité avec les services Azure.
  • Évaluez l’intégrité globale d’application des charges de travail.

Objectifs de disponibilité

Un contrat de niveau de service (SLA) est une cible de disponibilité qui représente un engagement en matière de performances et de disponibilité de l’application. Il est essentiel de comprendre le contrat SLA de composants individuels au sein du système pour définir des cibles de fiabilité. Connaître le contrat SLA des dépendances fournit également une justification pour des dépenses supplémentaires lors de la mise à disposition des dépendances hautement disponibles et avec des contrats de support appropriés. Les cibles de disponibilité pour toutes les dépendances utilisées par l’application doivent être comprises et, dans l’idéal, s’aligner sur les cibles d’application doivent également être prises en compte.

Il est essentiel de comprendre vos attentes en matière de disponibilité pour passer en revue les opérations globales de l’application. Si vous souhaitez atteindre un objectif de niveau de service d’application (SLO) de 99,999 %, le niveau d’action opérationnelle inhérente requis par l’application sera bien supérieur à celui de l’objectif d’un SLO de 99,9 %.

La surveillance et la mesure de la disponibilité des applications sont essentielles pour déterminer l’intégrité globale des applications et la progression vers des cibles définies. Veillez à mesurer et à surveiller les cibles principales, telles que :

  • Temps moyen entre échecs (MTBF). Temps moyen entre les défaillances d’un composant particulier.
  • Temps moyen de récupération (MTTR). Temps moyen nécessaire pour restaurer un composant après une défaillance.

Considérations relatives aux cibles de disponibilité

Gardez à l’esprit les questions suivantes.

Les contrats SLA/SLO/SLI pour toutes les dépendances appliquées sont-ils compris ?

Les cibles de disponibilité pour toutes les dépendances utilisées par l’application doivent être comprises et idéalement alignées sur les cibles d’application. Assurez-vous que les sla/SLO/indicateurs de niveau de service (SLO) pour toutes les dépendances appliquées sont compris.

Un contrat SLA composite a-t-il été calculé pour les scénarios d’application et de clé à l’aide des contrats SLA Azure ?

Un SLA composite capture le contrat SLA de bout en bout sur l’ensemble des composants et dépendances d’application. Il est calculé à l’aide des contrats SLA individuels des services Azure hébergeant des composants d’application. Un contrat SLA composite fournit un indicateur important de la disponibilité conçue par rapport aux attentes et aux objectifs des clients. Assurez-vous que le contrat SLA composite de tous les composants et dépendances sur les chemins critiques est compris. Pour plus d’informations, consultez Contrats SLA composites.

Notes

Si vous avez des engagements contractuels envers un contrat SLA pour votre solution Azure, des allocations en plus du contrat SLA composite Azure doivent être prises en charge pour prendre en charge les pannes provoquées par des problèmes et des déploiements au niveau du code. Ce fait est souvent négligé. Vous pouvez directement transmettre le contrat SLA composite à vos clients.

Les cibles de disponibilité sont-elles prises en compte lorsque le système s’exécute en mode de récupération d’urgence ?

Les cibles de disponibilité peuvent être appliquées ou non lorsque le système s’exécute en mode de récupération d’urgence. Cela dépend de l’application. Si les cibles doivent également s’appliquer dans un état d’échec, un modèle N+1 doit être utilisé pour obtenir une plus grande disponibilité et résilience. Dans ce scénario, N est la capacité nécessaire pour assurer la disponibilité requise. Il y a aussi un coût. Une infrastructure plus résiliente est généralement plus coûteuse.

Quelles sont les conséquences si les objectifs de disponibilité ne sont pas satisfaits ?

Y a-t-il des pénalités, telles que des frais financiers, associées au non-respect des engagements liés au SLA ? D’autres mesures peuvent être utilisées pour éviter des pénalités, mais cela entraîne également des coûts supplémentaires pour l’exploitation de l’infrastructure. Ce fait doit être pris en compte et évalué. Les conséquences si les objectifs de disponibilité ne sont pas satisfaits doivent être entièrement compris. Cette approche indique également quand lancer un cas de basculement.

Cibles de récupération

Les cibles de récupération identifient la durée pendant laquelle la charge de travail peut être indisponible et la quantité de données pouvant être perdue pendant un sinistre. Définissez des rapports cibles pour l’application et les scénarios clés. Les rapports cibles nécessaires sont les suivants :

  • Objectif de délai de récupération (RTO). Durée maximale acceptable pendant laquelle une application n’est pas disponible après un incident.
  • Objectif de point de récupération (RPO). Il s’agit de la durée maximale de perte de données acceptable pendant une panne.

Les cibles de récupération sont des exigences non fonctionnelles d’un système et doivent être dictées par les besoins de l’entreprise. Les cibles de récupération doivent être définies conformément aux objectifs RTO et RPO requis pour les charges de travail.

Répondre aux exigences de la plateforme d’application

Les services de plateforme d’applications Azure offrent des fonctionnalités de résilience pour prendre en charge la fiabilité des applications. Elles ne peuvent s’appliquer qu’à une certaine référence SKU et à une certaine configuration ou déploiement. Par exemple, elles peuvent s’appliquer si un contrat SLA dépend du nombre d’instances déployées ou d’une fonctionnalité spécifique activée.

Nous vous recommandons de passer en revue le contrat SLA pour les services utilisés. Par exemple, la référence SKU Service Bus Premium fournit une latence et un débit prévisibles pour atténuer les scénarios de voisins bruyants. Il vous permet également de mettre à l’échelle et de répliquer automatiquement les métadonnées vers un autre instance Service Bus à des fins de basculement.

Pour plus d’informations, consultez Couches messagerie Service Bus Premium et Standard.

Utiliser des zones de disponibilité

De nombreuses régions Azure fournissent des zones de disponibilité, qui sont des groupes séparés de centres de données. Au sein d’une région, chaque zone de disponibilité est suffisamment proche l’une de l’autre pour avoir des connexions à très faible latence vers d’autres zones de disponibilité, mais elles sont suffisamment éloignées pour garantir qu’elles disposent d’une infrastructure indépendante d’alimentation, de refroidissement et de mise en réseau. Les zones de disponibilité sont conçues de sorte que si une zone est en panne, les services régionaux, la capacité et la haute disponibilité sont pris en charge par les autres zones.

Si vous effectuez un déploiement dans une région Azure qui contient des zones de disponibilité, vous pouvez utiliser plusieurs zones de disponibilité ensemble. En utilisant plusieurs zones de disponibilité, vous pouvez conserver des copies distinctes de votre application et de vos données dans des centres de données physiques distincts dans une vaste zone métropolitaine.

Il existe deux façons d’utiliser des zones de disponibilité au sein d’une solution :

  • Les ressources zonales sont épinglées à une zone de disponibilité spécifique. Vous pouvez combiner plusieurs déploiements zonaux dans différentes zones pour répondre à des exigences de fiabilité élevées. Vous êtes responsable de la gestion de la réplication des données et de la distribution des demandes entre les zones. Si une panne se produit dans une seule zone de disponibilité, vous êtes responsable du basculement vers une autre zone de disponibilité.
  • Les ressources redondantes interzones sont réparties sur plusieurs zones de disponibilité. Microsoft gère la répartition des demandes entre les zones et la réplication des données entre les zones, pour vous. Si une panne se produit dans une seule zone de disponibilité, Microsoft gère le basculement automatiquement.

Différents services Azure prennent en charge l’une de ces approches ou les deux. En général, les services PaaS prennent généralement en charge les déploiements redondants interzones, et les services IaaS prennent généralement en charge les déploiements zonaux. Pour plus d’informations sur le fonctionnement des services Azure avec les zones de disponibilité, consultez Services Azure avec prise en charge des zones de disponibilité.

Il existe des considérations relatives aux performances et aux coûts dans lesquelles les applications sont extrêmement bavardes entre les zones en raison de la séparation physique et des frais de bande passante interzone.

Pour plus d’informations sur la conception de zones de disponibilité et d’autres façons d’atteindre la résilience dans Azure, consultez Création de solutions pour la haute disponibilité à l’aide de zones de disponibilité et Continuité d’activité avec résilience des données.

Utiliser plusieurs régions Azure

La capacité à répondre aux scénarios de sinistre pour la disponibilité globale de la plateforme de calcul et la fiabilité des applications dépend de l’utilisation de plusieurs zones ou régions de disponibilité. Si vous disposez d’une solution stratégique, vous pouvez envisager de la déployer dans plusieurs régions Azure. Toutefois, si vous n’avez pas explicitement besoin d’une conception multirégion, il est moins coûteux et moins complexe d’utiliser des zones de disponibilité à la place.

Conseil

Pour la plupart des charges de travail, une architecture basée sur les zones de disponibilité offre le meilleur équilibre entre résilience, performances, coûts et complexité.

Envisagez des déploiements multirégions si l’une de ces situations s’applique à votre charge de travail :

  • Les contrats SLA donnés par une configuration multizone à une seule région sont insuffisants.
  • Vos utilisateurs sont géographiquement répartis et il est logique d’avoir des instances de votre charge de travail à proximité de vos bases d’utilisateurs. Par exemple, vous pouvez suivre le modèle Empreintes de déploiement ou le modèle Geode.

De nombreuses régions ont également une région jumelée. Les régions jumelées prennent en charge certains types d’approches de déploiement multirégion, telles que les fonctionnalités de réplication natives telles que la réplication asynchrone de stockage géoredondant (GRS). Certaines régions plus récentes ont plusieurs zones de disponibilité et n’ont pas de région jumelée. Vous pouvez toujours déployer des solutions multirégions dans ces régions, mais les approches que vous utilisez peuvent être différentes.

Si vous planifiez la maintenance, les mises à jour d’une région sont effectuées séquentiellement. Pour plus d’informations, consultez la réplication interrégion dans Azure.

Considérations relatives à la disponibilité

Il existe plusieurs considérations relatives à la disponibilité.

L’application est-elle hébergée sur au moins deux nœuds de plateforme d’application ?

Pour garantir la fiabilité de la plateforme d’application, il est essentiel que l’application soit hébergée sur au moins deux nœuds. Cette approche garantit qu’il n’existe aucun point de défaillance unique. Dans l’idéal, un modèle N+1 doit être appliqué pour la disponibilité du calcul, où N est le nombre d’instances requises pour prendre en charge les exigences de disponibilité et de performances des applications.

Notes

Les contrats SLA plus élevés fournis pour les machines virtuelles et les services de plateforme associés associés nécessitent au moins deux nœuds réplica déployés sur un groupe à haute disponibilité ou sur plusieurs zones de disponibilité. Pour plus d’informations, consultez CONTRAT SLA pour Machines Virtuelles.

Comment le trafic client est-il acheminé vers l’application en cas de région, de zone de disponibilité ou de panne réseau ?

En cas de panne majeure, le trafic client doit être routable vers les déploiements d’applications qui restent disponibles dans d’autres régions ou zones de disponibilité. C’est dans cette situation que la connectivité intersite et l’équilibrage de charge global doivent être utilisés, selon que l’application est interne ou externe. Des services tels qu’Azure Front Door, Azure Traffic Manager ou des réseaux de distribution de contenu tiers peuvent acheminer le trafic entre les régions en fonction de l’intégrité des applications découverte à l’aide de sondes d’intégrité. Pour plus d’informations, consultez Surveillance des points de terminaison Traffic Manager.

Répondre aux exigences de la plateforme de données

Les services de données et de stockage doivent s’exécuter dans une configuration ou une référence SKU hautement disponible. Les services de plateforme de données Azure offrent des fonctionnalités de fiabilité pour prendre en charge la fiabilité des applications. Elles ne peuvent être applicables qu’à une certaine référence SKU. Par exemple, Azure SQL références SKU de base de données critique pour l'entreprise et stockage redondant dans une zone de stockage (ZRS) Azure avec trois réplicas synchrones répartis entre les zones de disponibilité.

Cohérence des données

Les types de données doivent être catégorisés par les exigences de cohérence des données. Les exigences de cohérence des données, telles que la cohérence forte ou éventuelle, doivent être comprises pour tous les types de données et utilisées pour informer le regroupement et la catégorisation des données. Les exigences de cohérence doivent indiquer quelles stratégies de réplication et de synchronisation des données peuvent être considérées pour atteindre les objectifs de fiabilité des applications.

Le théorème CAP prouve qu’il est impossible pour un magasin de données distribué d’offrir simultanément plus de deux garanties dans les mesures suivantes :

  • Cohérence. Chaque lecture reçoit l’écriture la plus récente ou une erreur.
  • Disponibilité. Chaque requête reçoit une réponse non-terroriste, sans la garantie qu’elle contient l’écriture la plus récente.
  • Tolérance de partition. Un système continue de fonctionner malgré un nombre arbitraire de transactions supprimées ou retardées par le réseau entre les nœuds.

Il est essentiel de déterminer lesquelles de ces garanties sont les plus importantes dans le contexte des exigences de l’application.

Réplication et redondance

La réplication de données dans des zones de disponibilité ou des régions prend en charge les objectifs de disponibilité des applications pour limiter l’effet des scénarios d’échec. La possibilité de restaurer des données à partir d’une sauvegarde est essentielle lors de la récupération après des situations d’altération des données et des scénarios de défaillance. Pour garantir une redondance et une disponibilité suffisantes pendant les scénarios de zone de disponibilité et de défaillance régionale, les sauvegardes doivent être stockées dans des zones de disponibilité ou des régions.

Définissez et testez un processus de restauration des données pour garantir un état cohérent de l’application. Les tests réguliers du processus de restauration des données favorisent l’excellence opérationnelle et la confiance dans la capacité à récupérer des données en fonction des objectifs de récupération définis pour l’application.

Réfléchissez à la façon dont le trafic de votre application est routé vers des sources de données en cas de région, de zone de disponibilité ou de panne réseau. Il est essentiel de comprendre la méthode utilisée pour acheminer le trafic d’application vers des sources de données en cas d’événement d’échec majeur pour déterminer si les processus de basculement répondent aux objectifs de récupération. De nombreux services de plateforme de données Azure offrent des fonctionnalités de fiabilité natives pour gérer les défaillances majeures, telles que le basculement automatique Azure Cosmos DB et la géoréplication active de la base de données Azure SQL.

Notes

Certaines fonctionnalités, telles que le stockage géoredondant avec accès en lecture Azure et la géoréplication active Azure SQL base de données, nécessitent un basculement côté application vers d’autres points de terminaison dans certains scénarios de défaillance. La logique d’application doit être développée pour gérer ces scénarios.

Exigences de connectivité et de réseau

Tenez compte des instructions suivantes pour garantir la disponibilité des connexions et améliorer la fiabilité avec les services Azure.

Connectivité

  • Utilisez un équilibreur de charge global pour distribuer le trafic et le basculement entre les régions.

    Azure Front Door, Azure Traffic Manager ou des services réseau de distribution de contenu tiers peuvent être utilisés pour diriger les demandes entrantes vers des points de terminaison d’application externes déployés dans plusieurs régions. Traffic Manager étant un équilibreur de charge basé sur DNS, le basculement doit attendre que la propagation DNS se produise. Une valeur de durée de vie (TTL) suffisamment faible doit être utilisée pour les enregistrements DNS, mais tous les fournisseurs de services Web ne respectent pas ce paramètre. Pour les scénarios d’application qui nécessitent un basculement transparent, Azure Front Door doit être utilisé. Pour plus d’informations, consultez Récupération d’urgence à l’aide d’Azure Traffic Manager et Vue d’ensemble de l’architecture de routage.

  • Pour la connectivité intersite, à l’aide d’Azure ExpressRoute ou d’un VPN, assurez-vous qu’il existe des connexions redondantes à partir de différents emplacements.

    Au moins deux connexions redondantes doivent être établies entre plusieurs régions Azure et emplacements de peering pour garantir qu’il n’y a aucun point de défaillance unique. Une configuration de charge partagée active/active fournit une diversité de chemins d’accès et favorise la disponibilité des chemins de connexion réseau. Pour plus d’informations, consultez Connectivité entre réseaux.

  • Simulez un chemin d’accès d’échec pour vous assurer que la connectivité est disponible sur d’autres chemins.

    L’échec d’un chemin de connexion sur d’autres chemins de connexion doit être testé pour valider la connectivité et l’efficacité opérationnelle. L’utilisation de la connectivité VPN de site à site comme chemin de sauvegarde pour ExpressRoute fournit une couche supplémentaire de résilience réseau pour la connectivité intersite. Pour plus d’informations, consultez Utilisation d’un VPN de site à site comme sauvegarde pour le peering privé ExpressRoute.

  • Éliminez tous les points de défaillance uniques du chemin des données, à la fois localement et hébergées sur Azure.

    Les appliances virtuelles réseau mono-instance présentent un risque de connectivité important, qu’elles soient déployées dans Azure ou dans un centre de données local. Pour plus d’informations, consultez Déployer des appliances virtuelles réseau hautement disponibles.

Services sensibles aux zones

  • Utilisez ExpressRoute ou des passerelles de réseau virtuel redondantes interzone VPN.

    Les passerelles de réseau virtuel redondant interzone distribuent les instances de passerelle entre les zones de disponibilité pour améliorer la fiabilité et garantir la disponibilité pendant les scénarios de défaillance qui affectent un centre de données dans une région. Pour plus d’informations, consultez À propos de la passerelle de réseau virtuel redondant interzone dans les zones de disponibilité Azure.

  • Si elle est utilisée, déployez Azure Application Gateway v2 dans une configuration redondante interzone.

    Azure Application Gateway v2 peut être déployé dans une configuration redondante interzone pour déployer des instances de passerelle sur plusieurs zones afin d’améliorer la fiabilité et la disponibilité pendant les scénarios de défaillance qui affectent un centre de données dans une région. Pour plus d’informations, consultez l’article Mettre à l’échelle Application Gateway v2 et WAF v2.

  • Utilisez Azure Load Balancer Standard pour équilibrer la charge du trafic entre les zones de disponibilité.

    Azure Load Balancer Standard prend en charge les zones pour répartir le trafic entre les zones de disponibilité. Il peut également être configuré dans une configuration redondante interzone pour améliorer la fiabilité et garantir la disponibilité pendant les scénarios de défaillance qui affectent un centre de données au sein d’une région. Pour plus d’informations, consultez Load Balancer et zones de disponibilité.

  • Configurez des sondes d’intégrité pour les passerelles Azure Load Balancer et Azure Application.

    Les sondes d’intégrité permettent Azure Load Balancer d’évaluer l’intégrité des points de terminaison principaux pour empêcher l’envoi du trafic à des instances non saines. Pour plus d’informations, consultez sondes d’intégrité Azure Load Balancer.

  • Évaluez les dépendances d’applications critiques avec les sondes d’intégrité.

    Les sondes d’intégrité personnalisées doivent être utilisées pour évaluer l’intégrité globale de l’application, y compris les composants en aval et les services dépendants, tels que les API et les magasins de données. Dans cette approche, le trafic n’est pas envoyé aux instances principales qui ne peuvent pas traiter correctement les demandes en raison d’échecs de dépendance. Pour plus d’informations, consultez Modèle Supervision de point de terminaison d’intégrité.

Étapes suivantes

Concevoir des applications Azure fiables

Retour à l’article main : Conception pour la fiabilité