VENTES: 1-800-867-1389

Failsafe: Guidance for Resilient Cloud Architectures

Mis à jour: juin 2014

Auteur : Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott et Andrew Townhill

Réviseurs : Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

Date de publication : juin 2014

Prévention de défaillance nom. Élément conçu pour fonctionner ou s'exécuter automatiquement afin d'empêcher la répartition d'un mécanisme, d'un système ou autre.

Des personnes, dans le contexte d'un employé, d'un citoyen ou d'un consommateur, demandent l'accès instantané à des services d'applications, de calcul et de données. Le nombre d'utilisateurs connectés et les périphériques qu'ils utilisent pour se connecter à ces services sont en constante augmentation. Dans ce monde de services toujours disponibles, les systèmes qui les prennent en charge doivent être conçus pour être disponibles et résilients.

Ces services seront déployés dans des environnements de cloud remplis en fonction des configurations prédéfinies. Par le passé, vous avez peut-être acheté du matériel haut de gamme pour procéder à une évolution horizontale. Cependant, dans les environnements de cloud, vous devez plutôt procéder à une montée en charge. Vous utilisez du matériel de base pour que les coûts de ces environnements de cloud restent bas. Le matériel de base va tomber en panne et le cloud nécessite une architecture prenant en compte les risques de pannes. Vous êtes habituellement concentré sur le fait d'empêcher les pannes et d'optimiser « la disponibilité entre deux pannes ». Dans ce nouvel environnement, vous serez plutôt focalisé sur le fait d'optimiser « le délai de restauration avec un impact minimal ».

Il y a de fortes chances que vous développiez des services composites. Ils seront constitués d'une ou plusieurs plateformes propriétaires ou tierces, ainsi que de services de fournisseur tiers. Ces services seront développés sur une infrastructure de cloud qui tombera en panne. L'architecture doit également être conçue en tenant compte du fait que les services utilisés tomberont aussi en panne. Tout comme l'architecture de l'infrastructure, l'architecture de l'application doit être conçue pour faire face aux risques de pannes.

L'initiative de prévention de défaillance Microsoft est conçue pour fournir une aide générale pour la création d'architectures résilientes de cloud, des instructions pour l'implémentation de ces architectures sur des technologies Microsoft et des recettes pour implémenter les architectures pour des scénarios spécifiques. Les auteurs de ce document sont membres des services Cloud + Enterprise, TwC (Trustworthy Computing) et Consulting Services de Microsoft.

Ce document traite des considérations sur l'architecture pour concevoir des systèmes évolutifs et résilients.

Il comprend les sections suivantes :

  • Décomposer l'application par charge de travail : la définition d'une approche centrée sur la charge de travail offre un meilleur contrôle sur les coûts, plus de souplesse dans le choix des technologies les mieux adaptées à la charge de travail et permet une approche plus précise de la disponibilité et de la résilience.

  • Établir un modèle de cycle de vie : le fait d'établir un modèle de cycle de vie des applications permet de définir le comportement attendu d'une application dans un environnement de production et fournit la configuration requise et l'analyse de l'architecture globale.

  • Établir un modèle de disponibilité et un plan : le modèle de disponibilité identifie le niveau de disponibilité prévu pour votre charge de travail. Il est essentiel, car il fournit des précisions sur nombre de décisions que vous prendrez lors de l'établissement de votre service.

  • Identifier les points, les modes et les effets d'échec : pour créer une architecture résiliente, il est important de comprendre et d'identifier les points et les modes d'échec. En particulier, faire un effort proactif pour comprendre et documenter ce qui peut entraîner un échec permettra d'établir un plan qui pourra être utilisé lors de l'analyse et de la planification.

  • Modèles de résilience et considérations : cette section constitue la majorité du document et contient les points clés sur les services de calcul, de stockage et de plateforme. Ces considérations portent sur des pratiques éprouvées pour fournir une application saine aux points clés sur les services de calcul, de stockage et de plateforme.

  • Conception des opérations : dans un monde qui s'attend à ce que les services soient toujours disponibles, il est essentiel que les services soient conçus pour les opérations. Cette section présente des méthodes éprouvées de conception pour les opérations qui reflètent le cycle de vie, notamment la création d'un modèle d'intégrité, l'implémentation de télémesure et la visualisation de ces informations de télémesure pour les opérations et les développeurs.

Les applications sont en général composées de plusieurs charges de travail.

Les différentes charges de travail ont différentes configurations, différents niveaux d'importance dans l'entreprise et différents niveaux de considérations financières associés. En décomposant une application en charges de travail, une organisation bénéficie d'une souplesse précieuse. Une approche centrée sur la charge de travail offre un meilleur contrôle sur les coûts, plus de souplesse dans le choix des technologies les mieux adaptées à la charge de travail, des approches spécifiques à la charge de travail pour la disponibilité, la sécurité, la souplesse et l'agilité lors de l'ajout et du déploiement de nouvelles fonctions, etc.

En matière de résilience, il est parfois utile de l'envisager dans le contexte de scénarios. Voici quelques exemples de scénarios par défaut :

  • Service de données sportives

    Un client met à disposition un service de données qui fournit des informations sportives. Le service est composé de deux charges de travail principales. La première fournit des statistiques pour le joueur et les équipes. La deuxième fournit des scores et des commentaires pour les jeux qui sont actuellement en cours.

  • Site web de commerce électronique

    Un site de vente en ligne vend des marchandises via un site Web selon un modèle bien établi. L'application a plusieurs charges de travail, les plus utilisées étant « rechercher et parcourir » et « valider ».

  • Social

    Un site de réseau social bien connu permet aux membres d'une communauté de prendre part aux expériences partagées dans des forums, au contenu fourni par l'utilisateur et à des jeux occasionnels. L'application a plusieurs charges de travail, y compris inscription, recherche et navigation, interaction sociale, jeux, courrier électronique, etc.

  • Web

    Une organisation souhaite offrir une expérience aux clients via son site Web. L'application doit fournir les expériences sur les navigateurs pour PC, ainsi que sur les types de périphérique mobiles les plus utilisés (téléphone, tablette). Elle est composée de plusieurs charges de travail notamment inscription, recherche et navigation, publication de contenu, commentaires sociaux, modération, jeux, etc.

Examinons de plus près un des scénarios et décomposons-le en charges de travail enfants. Un site web de commerce électronique peut être composé de plusieurs charges de travail : navigation et recherche, validation et gestion, inscription des utilisateurs, contenu généré par l'utilisateur (examen et évaluation), personnalisation, etc.

Exemples de définition de deux des principales charges de travail du scénario :

  • Navigation et recherche permet aux utilisateurs de parcourir un catalogue de produits, rechercher des éléments spécifiques et éventuellement de gérer les paniers ou les listes de souhaits. Cette charge de travail peut avoir des attributs tels que l'accès anonyme, les temps de réponse en fractions de seconde et la mise en cache. Une dégradation des performances peut se produire sous la forme de temps de réponse accrus avec une charge utilisateur inattendue ou des interruptions de tolérance d'applications lors de l'actualisation du stock des produits. Dans ce cas, l'application peut choisir de continuer à servir les informations à partir du cache.

  • Validation et gestion permet aux clients de passer, suivre et annuler des commandes ; sélectionner les modes de livraison et les options de paiement ; et de gérer les profils. Cette charge de travail peut avoir des attributs tels que accès sécurisé, traitement en file d'attente, accès à des passerelles de paiement tierces et connectivité aux systèmes principaux sur site. Alors que l'application peut tolérer un temps de réponse accru, elle ne peut pas tolérer une perte de commandes ; par conséquent, elle est conçue de façon à garantir que les commandes des clients sont toujours acceptées et capturées, que l'application puisse ou non traiter le paiement ou organiser la livraison.

Un modèle de cycle de vie des applications définit le comportement attendu d'une application opérationnelle. À différentes phases et heures, une application envoie différentes demandes sur le système à un niveau fonctionnel ou d'échelle. Le ou les modèles de cycle de vie reflètent cela.

Les charges de travail doivent posséder des modèles de cycle de vie définis pour tous les scénarios concernés et applicables selon le niveau de granularité adéquat. Les services peuvent comporter des différences de cycle de vie horaire, quotidien, hebdomadaire ou saisonnier qui, une fois modélisées, identifient la capacité, la disponibilité, les performances et les conditions d'évolutivité au fil du temps appropriées.

Prévention de défaillance_03

Figure 1 : exemples de cycles de vie pour différents secteurs et scénarios

Ils suivront souvent leur propre cycle de vie :

  • durant un pic lié à la demande au cours d'une période de congé ;

  • pendant l'augmentation du taux de remplissage des déclarations de revenus juste avant la date d'échéance ;

  • lors des fenêtres de temps de transport le matin et l'après-midi ;

  • ou au moment des évaluations de performances des employés remplies en fin d'année.

De nombreuses organisations identifient ces types de scénarios et les cycles de vie qui leurs sont propres.

La décomposition vous permet d'avoir différents contrats de niveau de service en fonction du niveau de charge de travail. Par exemple, prenez l'API de données sportives ayant un contrat de niveau de service (SLA) cible de 99,99 %. Vous pouvez diviser cette API en deux charges de travail : « Scores en direct + commentaires » et « Statistiques sur les équipes, les joueurs et la ligue »

Pour la charge de travail « Scores en direct + commentaires », le cycle de vie suit un modèle « actif et inactif ». Cependant, la disponibilité de « Statistiques sur les équipes, les joueurs et la ligue » doit être constante. La décomposition en différentes charges de travail vous permet d'ajuster vos contrats SLA aux besoins de disponibilité de la charge de travail agrégée du service composite.

Prévention de défaillance_12

Figure 2

Une fois qu'un modèle de cycle de vie est identifié, l'étape suivante consiste à créer un modèle de disponibilité et un plan. Un modèle de disponibilité pour votre application identifie le niveau de disponibilité attendu avec votre charge de travail. Il est essentiel, car il fournit des précisions sur nombre de décisions que vous prendrez lors de l'établissement de votre service.

Plusieurs points doivent être pris en considération et nombre de mesures possibles peuvent être prises.

Lorsque vous développez votre plan de disponibilité, il est important de comprendre le niveau de disponibilité souhaité pour votre application, les charges de travail de cette application et les services utilisés lors de l'exécution de ces charges de travail.

La compréhension du cycle de vie de votre charge de travail vous aidera à choisir le contrat SLA que vous voulez fournir. Il est possible qu'un contrat SLA ne soit pas fourni publiquement à votre service. Cependant, votre architecture doit viser une disponibilité de base que vous veillerez à respecter.

Selon le type de solution que vous développez, vous devrez prendre en compte différentes options et considérations pour fournir une disponibilité élevée. Les fournisseurs de services commerciaux n'offrent pas de contrats SLA à 100 %, car ils seraient trop complexes et coûteux pour être véritablement réalisables et rentables. La décomposition de votre application en différentes charges de travail vous permet de prendre des décisions et d'implémenter des approches de disponibilité. La haute disponibilité à 99,99 % pour l'intégralité de votre application peut s'avérer impossible, mais pas pour une charge de travail de cette application.

Même au niveau de la charge de travail, vous ne pouvez pas choisir d'implémenter toutes les solutions. Les solutions que vous choisissez d'implémenter ou non dépendent de vos besoins. Quelles que soient les solutions sélectionnées, vous devez faire un choix en connaissance de cause et tenir compte de toutes les solutions.

L'autonomie est une question d'indépendance et de limitation de la dépendance entre les éléments qui constituent le service. La dépendance sur les composants, les données et les entités externes doit être vérifiée lorsque vous concevez des services, en prenant en considération la création de fonctionnalités associées dans des unités autonomes du service. Ce faisant, vous offrez la souplesse nécessaire pour mettre à jour les versions d'unités distinctes autonomes, mieux contrôler la montée en puissance de ces unités autonomes, etc.

Les architectures de charge de travail contiennent souvent des composants indépendants qui ne reposent pas sur une intervention manuelle et ne tombent pas en panne lorsque les entités dont elles dépendent ne sont pas disponibles. Les applications composées d'éléments autonomes présentent les caractéristiques suivantes :

  • elles sont disponibles et opérationnelles ;

  • elles sont résilientes et facilement récupérables en cas d'erreurs ;

  • elles présentent un risque plus faible d'états d'échec d'intégrité ;

  • elles peuvent aisément faire l'objet d'une montée en puissance par réplication ;

  • elles nécessitent généralement moins d'interventions manuelles.

Ces unités autonomes tireront souvent parti de la communication asynchrone, du traitement des données basé sur l'extraction et de l'automation pour garantir un service continu.

Tourné vers l'avenir, le marché va évoluer jusqu'à un point où il existera des interfaces standardisées pour certains types de fonctionnalités destinées aux scénarios horizontaux et verticaux. Lorsque cette vision se concrétisera, un fournisseur de services pourra collaborer avec d'autres fournisseurs et s'adapter à différentes implémentations qui permettront de résoudre les tâches spécifiées de l'unité autonome. En ce qui concerne les services continus, cela se fera de manière autonome et basée sur des stratégies.

Si l'autonomie est une aspiration, la plupart des services auront une dépendance sur un service tiers, ne fût-ce que pour l'hébergement. Il est impératif de comprendre les contrats de niveau service de ces services dépendants et de les intégrer à votre plan de disponibilité.

Cette section décrit les différents types de contrat SLA qui peuvent convenir pour votre service. Pour chacun de ces types de service, il existe des considérations et des approches clés, ainsi que des questions qui doivent être posées.

Services de plateforme du cloud public

Les services fournis par une plateforme commerciale de cloud computing, tels que les services de calcul ou de stockage, disposent de contrats de niveau de service conçus pour tenir compte d'une multitude de clients à grande échelle. De ce fait, les contrats de niveau de service de ces services ne sont pas négociables. Un fournisseur peut fournir plusieurs niveaux du service avec différents contrats de niveau de service, mais ces niveaux ne sont pas négociables. Le fournisseur de service utilise plusieurs niveaux de contrats SLA avec différents niveaux de disponibilité pour fournir une qualité de service prévisible.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il une limite sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Services « gratuits » fournis par des tiers

Nombre de tiers fournissent des services « gratuits » à la communauté. Pour les organisations du secteur privé, cela permet surtout de créer un écosystème d'applications autour de leur produit ou service de base. Pour le secteur public, cela permet de mettre des données à disposition des citoyens et entreprises qui ont payé leur collecte au moyen du financement des administrations par des taxes.

La plupart de ces services ne seront pas fournis avec des contrats de niveau de service. Par conséquent, la disponibilité n'est pas garantie. Lorsque des contrats de niveau de service sont fournis, ils mettent généralement l'accent sur les limitations appliquées sur des applications et mécanismes qui seront utilisés pour les mettre en place. Les exemples de limitations peuvent inclure la limitation de bande passante ou l'inscription de votre solution sur la liste noire si elle dépasse un certain nombre d'appels de service, si elle dépasse un certain nombre d'appels dans une période donnée (x par minute) ou si elle dépasse le nombre de serveurs autorisés qui appellent le service.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il des limites sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • S'agit-il d'un service de produit dont les fonctionnalités et/ou les données requises sont disponibles auprès de plusieurs fournisseurs de services ?

  • S'il s'agit d'un service de produit, l'interface est-elle interopérable sur d'autres fournisseurs de services (directement ou via une couche d'abstraction disponible) ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Services commerciaux fournis par des tiers

Les services commerciaux fournis par des tiers disposent de contrats de niveau de service conçus pour répondre aux besoins des clients qui payent. Un fournisseur peut fournir plusieurs niveaux de contrats de service avec différents niveaux de disponibilité, mais ces contrats de niveau de service ne sont pas négociables.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il des limites sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • S'agit-il d'un service de produit dont les fonctionnalités et/ou les données requises sont disponibles auprès de plusieurs fournisseurs de services ?

  • S'il s'agit d'un service de produit, l'interface est-elle interopérable sur d'autres fournisseurs de services (directement ou via une couche d'abstraction disponible) ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Services de cloud computing de la communauté

Une communauté d'organisations, telle qu'une chaîne d'approvisionnement, peut mettre des services à la disposition des organisations membres.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il des limites sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • En tant que membre de la communauté, est-il possible de négocier un autre contrat de niveau de service ?

  • S'agit-il d'un service de produit dont les fonctionnalités et/ou les données requises sont disponibles auprès de plusieurs fournisseurs de services ?

  • S'il s'agit d'un service de produit, l'interface est-elle interopérable sur d'autres fournisseurs de services (directement ou via une couche d'abstraction disponible) ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Services de cloud computing internes de l'entreprise de première partie

Une entreprise peut mettre des services de base, tels que les données de cotation ou les métadonnées des produits, à la disposition de ses divisions et services.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il des limites sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • En tant que membre de l'organisation, est-il possible de négocier un autre contrat de niveau de service ?

  • S'agit-il d'un service de produit dont les fonctionnalités et/ou les données requises sont disponibles auprès de plusieurs fournisseurs de services ?

  • S'il s'agit d'un service de produit, l'interface est-elle interopérable sur d'autres fournisseurs de services (directement ou via une couche d'abstraction disponible) ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Services de cloud computing internes d'une division ou d'un service de première partie

Une division ou un service d'entreprise peut rendre les services disponibles pour d'autres membres de leur organisation immédiate.

Questions à examiner pour ce type de service :

  • Ce service permet-il uniquement un certain nombre d'appels à l'API de service ?

  • Ce service impose-t-il des limites sur la fréquence des appels à l'API de service ?

  • Le service limite-il le nombre de serveurs qui peuvent appeler l'API de service ?

  • Quelles sont les informations disponibles publiquement sur la façon dont le service tient sa promesse de disponibilité ?

  • Comment ce service communique-t-il son état d'intégrité ?

  • Quel est le contrat de niveau de service (SLA) indiqué ?

  • En tant que membre de la division, est-il possible de négocier un autre contrat de niveau de service ?

  • S'agit-il d'un service de produit dont les fonctionnalités et/ou les données requises sont disponibles auprès de plusieurs fournisseurs de services ?

  • S'il s'agit d'un service de produit, l'interface est-elle interopérable sur d'autres fournisseurs de services (directement ou via une couche d'abstraction disponible) ?

  • Quels sont les services de plateforme équivalents fournis par d'autres fournisseurs tiers ?

Disponibilité des services composites en nombre de neuf

Tirer parti des services existants peut fournir une agilité significative lors de la mise en œuvre de solutions pour votre organisation ou pour les ventes commerciales. Bien qu'intéressantes, il est important de comprendre réellement les incidences de ces dépendances sur le contrat de niveau de service global de la charge de travail.

La disponibilité est généralement exprimée en pourcentage de temps de fonctionnement pour une année donnée. Ce pourcentage de disponibilité exprimé est appelé « nombre de 9 ». Par exemple, 99,9 représente un service avec « trois neuf » et 99,999 représente un service avec « cinq neuf ».

 

Pourcentage de disponibilité

Temps mort par an

Temps mort par mois

Temps mort par semaine

90 % (« un neuf »)

36,5 jours

72 heures

16,8 heures

95%

18,25 jours

36 heures

8,4 heures

97%

10,96 jours

21,6 heures

5,04 heures

98%

7,30 jours

14,4 heures

3,36 heures

99 % (« deux neuf »)

3,65 jours

7,20 heures

1,68 heures

99.5%

1,83 jours

3,60 heures

50,4 minutes

99.8%

17,52 heures

86,23 minutes

20,16 minutes

99,9 % (« trois neuf »)

8,76 heures

43,2 minutes

10,1 minutes

99.95%

4,38 heures

21,56 minutes

5,04 minutes

99,99 % (« quatre neuf »)

52,56 minutes

4,32 minutes

1,01 minutes

99.999 % (« cinq neuf »)

5,26 minutes

25,9 secondes

6,05 secondes

99,9999 % (« six neuf »)

31,5 secondes

2,59 secondes

0,605 secondes

99,99999 % (« sept neuf »)

3,15 secondes

0,259 secondes

0,0605 secondes

Une idée fausse couramment véhiculée est liée au nombre de neuf offert par un service composite. Plus particulièrement, il est souvent considéré que si un service donné est composé de 5 services, chacun ayant un temps de fonctionnement de 99,99 % promis dans les contrats SLA, que le service composite résultant offre un pourcentage de disponibilité de 99,99 %. Ce n'est pas le cas.

Prévention de défaillance_13

Figure 3 : Temps mort associé au nombre de neuf le plus courant

Le contrat SLA composite est en fait un calcul qui prend en compte le temps mort par an. Un service avec un contrat de niveau de service de « quatre neuf » (99,99 %) peut être hors connexion au plus 52,56 minutes.

Le fait d'incorporer 5 de ces services avec un contrat SLA de 99,99 % dans un contrat SLA composite introduit un risque de contrat SLA identifié de 262,8 minutes ou 4,38 heures. Cela réduit la disponibilité à 99,95 % avant l'écriture d'une seule ligne de code.

En règle générale, vous ne pouvez pas modifier la disponibilité d'un service tiers. Cependant, lorsque vous écrivez votre code, vous pouvez augmenter la disponibilité globale de votre application en utilisant des techniques semblables à celles présentées dans ce document.

noteRemarque
Certains services peuvent fournir différents niveaux de service selon différents prix d'entrées ou partenariats commerciaux.

Revenons à notre exemple d'API de données sportives. Les utilisateurs ne jouent qu'à certains jours et horaires définis. Durant ces périodes, le contrat SLA doit être de 100 %. Lorsqu'il n'y a pas de match, cette charge de travail doit avoir un contrat SLA de 0 %. Le modèle de cycle de vie de la charge de travail « Statistiques sur les équipes, les joueurs et la ligue » est plus cohérent. Cette charge de travail doit avoir un contrat SLA de 99 % à tout moment.

Prévention de défaillance_14

Figure 4

Lorsque vous exploitez des services externes, on ne saurait trop insister sur le fait qu'il est important de comprendre les contrats SLA individuellement, ainsi que leur impact sur le service composite.

Pour créer une architecture résiliente, il est important de la comprendre. En particulier, il faut faire un effort proactif pour comprendre et documenter ce qui peut entraîner une indisponibilité.

Le fait de comprendre les points et les modes d'échec d'une application et de ses services associés de charge de travail peut vous permettre de prendre des décisions avisées et ciblées sur des stratégies de résilience et de disponibilité.

Les points d'échec correspondent à des emplacements où une panne peut provoquer l'arrêt d'un service. L'accent est mis sur les éléments de conception qui peuvent faire l'objet de modifications externes.

Voici des exemples de points d'échec :

  • Connexions de base de données

  • Connexions au site Web

  • Fichiers de configuration

  • Clés de Registre

Catégories de points d'échec courants :

  • Listes de contrôle d'accès

  • Accès à la base de données

  • Accès au site Web/service externe

  • Transactions

  • Configuration

  • Capacité

  • virtuel

Alors que les points d'échec définissent des zones qui peuvent entraîner une indisponibilité, les modes d'échec identifient la source potentielle d'une panne.

Voici des exemples de modes d'échec :

  • Fichier de configuration manquant

  • Trafic significatif dépassant la capacité des ressources

  • Capacité maximale de base de données dépassée

Les effets d'échec représentent les conséquences d'une panne sur une fonctionnalité. Apprenez les effets des pannes et leur fréquence. Ce faisant, vous pouvez définir des priorités et des méthodes de résolution des points et des modes d'échec de votre application ou service.

Ce document présente des points clés sur les services de calcul, de stockage et de plateforme. Avant de traiter ces sujets, il est important de récapituler plusieurs sujets de base qui ont un impact sur la résilience et qui sont souvent mal compris et/ou pas implémentés.

Comme mentionné précédemment, une architecture résiliente doit être optimisée pour l'autonomie. Une des méthodes pour obtenir l'autonomie consiste à rendre les communications asynchrones. Une architecture résiliente doit avoir comme valeur par défaut l'interaction asynchrone, avec des interactions synchrones qui se produisent uniquement à la suite d'une exception.

Les couches Web avec ou sans état et un cache distribué offrent cette fonctionnalité sur le frontal d'une solution. Les files d'attente peuvent fournir cette fonctionnalité pour les communications de l'interaction entre les services de charge de travail ou des services dans un service de charge de travail.

Ces derniers permettent de placer les messages dans des files d'attente et les services secondaires peuvent les récupérer. Cela peut être accompli en fonction de la logique, du temps ou de la logique prévenante de volume. En plus de rendre le processus asynchrone, les couches d'envoi ou d'extraction peuvent monter en puissance dans les files d'attente selon les besoins.

L'une des raisons les plus courantes pour lesquelles les erreurs temporaires se produiront est lorsque votre architecture se connecte à un service ou à une ressource telle qu'une base de données. Lorsque vous consommez des services, il est recommandé d'implémenter la logique qui introduit le concept de délai d'attente. Cette logique identifie une plage de temps acceptable pendant laquelle une réponse est attendue et génèrera une erreur identifiable si cette plage de temps est dépassée. Basées sur la survenance de l'erreur de délai d'attente, les mesures appropriées seront prises en fonction du contexte dans lequel l'erreur s'est produite. Le contexte peut inclure le nombre de fois où cette erreur s'est produite, l'impact potentiel d'une ressource indisponible, les garanties du contrat de niveau de service pour la période actuelle pour un client donné, etc.

Lors de la conception des services qui exécuteront votre charge de travail, vous devez accepter et prévoir que des erreurs se produiront et prendre les mesures appropriées pour les résoudre.

Les erreurs temporaires constituent un des problèmes les plus courants à résoudre. Aucun service n'a un temps de fonctionnement de 100 %. Par conséquent, il est réaliste de vous attendre à ne pas pouvoir vous connecter à un service sur lequel une charge de travail a pris une dépendance. L'incapacité de vous connecter ou les erreurs visibles de l'un de ces services peuvent être passagères (inférieures à une seconde) ou constantes (un fournisseur s'est arrêté).

Dégradation normale

Le service de charge de travail doit aspirer à gérer ces erreurs temporaires normalement. Netflix, par exemple, pendant une panne du fournisseur de cloud, a utilisé une file d'attente de vidéos plus ancienne pour les clients lorsque la banque de données primaire n'était pas disponible. Un site de commerce électronique continuant de recueillir des commandes si la passerelle de paiement n'est pas disponible constitue un autre exemple. Cela permet de traiter les commandes lorsque la passerelle de paiement redevient disponible ou après avoir basculé vers une passerelle de paiement secondaire.

Considérations générales sur la dégradation progressive

Voici quelques points clés en matière de dégradation progressive :

  • Les composants n'ayant pas le contexte intégral de la requête vont échouer et envoyer un message d'exception. Pour résoudre ceci, implémentez un disjoncteur (cette opération est décrite ultérieurement dans ce document), pour provoquer une interruption immédiate lorsque vous atteignez les seuils du nombre d'échecs.

  • Les pannes temporaires sont courantes. Leur gestion à l'aide du modèle de nouvelle tentative est décrite ultérieurement dans ce document.

  • L'appelant peut être capable de corriger certaines requêtes ayant échoué en renvoyant la requête en utilisant différents paramètres ou un autre chemin d'accès.

  • Si la réussite de la requête n'est pas essentielle pour le déroulement du scénario, vous pouvez gérer l'échec en utilisant une simple omission.

  • Vous pouvez gérer les échecs en renvoyant un message de réussite et en mettant en attente les requêtes ayant échoué pour les traiter ultérieurement lorsque vos ressources reviendront à l'état normal.

  • Vous pouvez renvoyer un élément correct, comme par exemple, des informations d'identification mises en cache, des données obsolètes à partir du cache, etc.

  • Vous pouvez gérer certains échecs en fournissant une expérience presque correcte, comme par exemple : un accès temporaire, des valeurs approximatives, une meilleure hypothèse, une balise noscript, etc.

  • Au lieu de générer une erreur, vous pouvez fournir une alternative, comme par exemple, des valeurs aléatoires, des droits anonymes, des images par défaut, etc.

Considérations relatives à la gestion des erreurs temporaires

Il existe plusieurs points clés pour l'implémentation de la gestion des erreurs temporaires, tel que le détaillent les sections suivantes.

  • Logique de nouvelle tentative

    La forme la plus simple de gestion des erreurs temporaires consiste à recommencer l'opération qui a échoué. Si vous utilisez un service tiers d'entreprise, l'implémentation de la logique de nouvelle tentative résout souvent ce problème.

    Notez que les conceptions doivent généralement limiter le nombre de fois où la logique peut faire l'objet d'une nouvelle tentative. La logique tentera généralement d'exécuter la ou les actions plusieurs fois, en enregistrant une erreur et/ou à l'aide d'un service ou d'un flux de travail secondaire si l'erreur persiste.

  • Interruption exponentielle

    Si le résultat de l'erreur temporaire est causé par une limitation de la bande passante par le service en raison d'une charge importante, les tentatives répétées d'appel du service étendront uniquement la limitation de la bande passante et auront un impact sur la disponibilité globale.

    Il est souvent souhaitable de réduire le volume d'appels au service pour éviter ou réduire la limitation de bande passante. Cette opération s'effectue en général par algorithme, par exemple effectuer une nouvelle tentative immédiatement après le premier échec, attendre une seconde après le deuxième échec, cinq secondes après le troisième échec, etc., jusqu'à ce qu'une réussite soit obtenue ou qu'un seuil d'échecs défini par l'application soit atteint.

    Cette approche est appelée « interruption exponentielle ».

  • Idempotence

    Une hypothèse concernant les services connectés est qu'ils ne seront pas disponibles à 100 % et que la gestion des erreurs temporaires avec une logique de nouvelle tentative est la principale méthode d'implémentation. Dans les cas où la logique de nouvelle tentative est implémentée, il existe un risque que le même message soit envoyé plusieurs fois, que les messages soient envoyés hors séquence, etc.

    Les opérations doivent être conçues de façon à être idempotentes, ce qui garantit que l'envoi du même message à plusieurs reprises n'entraîne pas une banque de données inattendue ou polluée.

    Par exemple, l'insertion de données issues de toutes les demandes risque de générer l'ajout de plusieurs enregistrements si l'opération de service est appelée plusieurs fois. Une autre approche consiste à implémenter le code en tant que « upsert » intelligent. Un horodateur ou un identificateur global peut être utilisé pour identifier les nouveaux messages parmi les messages traités précédemment, en insérant uniquement les plus récents dans la base de données et en mettant à jour les enregistrements existants si le message est plus récent que celui reçu précédemment.

  • Comportement de compensation

    Outre l'idempotence, un autre point à prendre en compte est le concept de comportement de compensation. Dans un monde où un jeu de systèmes connectés ne cesse de croître et les services composites sont émergents, il est essentiel de comprendre comment gérer le comportement de compensation.

    Pour nombre de développeurs d'applications métiers, les concepts des transactions ne sont pas nouveaux, mais le cadre de référence est souvent lié aux fonctionnalités transactionnelles exposées par les technologies de données locales et les bibliothèques de code associées. En examinant le concept pour le cloud, cette perspective doit prendre en compte de nouvelles considérations liées à l'orchestration des services distribués.

    L'orchestration des services peut s'étendre sur plusieurs systèmes distribués, être longue et avec état. L'orchestration est rarement synchrone, peut s'étendre sur plusieurs systèmes et durer de quelques secondes à des années selon le scénario d'entreprise.

    Dans un scénario de chaîne d'approvisionnement qui peut lier vingt-cinq organisations dans la même activité de charge de travail, par exemple, il peut y avoir un ensemble de vingt-cinq systèmes ou plus qui sont interconnectés dans une ou plusieurs orchestrations de services.

    En cas de réussite, les vingt-cinq systèmes doivent être informés que l'activité est terminée. Pour chaque point de connexion de l'activité, les systèmes participants peuvent fournir un ID de corrélation pour les messages envoyés par d'autres systèmes. Selon le type d'activité, la réception de cet ID de corrélation peut satisfaire la partie pour laquelle la transaction est théoriquement terminée. Dans d'autres cas, lors de l'achèvement des interactions des vingt-cinq parties, un message de confirmation peut être envoyé à toutes les parties (directement à partir d'un seul service ou via les points d'interaction de l'orchestration pour chaque système).

    Pour gérer les erreurs d'activités composites et/ou distribuées, chaque service doit afficher une interface de service et une ou plusieurs opérations afin de recevoir les demandes d'annulation d'une transaction donnée par un identificateur unique. Derrière la façade du service, des flux de travail sont en place de façon à compenser l'annulation de cette activité. Idéalement ce sont des procédures automatiques, mais elles peuvent être aussi simples que le routage vers une personne de l'organisation de façon à remédier manuellement au problème.

Un disjoncteur est un commutateur qui interrompt automatiquement le flux de courant électrique si le courant dépasse la limite prédéfinie. Les disjoncteurs sont utilisés le plus souvent en tant que mesure de sécurité lorsqu'une intensité excessive dans un circuit peut être dangereuse. Contrairement à un fusible, un disjoncteur peut être réinitialisé et réutilisé.

Le même modèle est applicable à la conception de logiciels, et en particulier aux services pour lesquels la disponibilité et la résilience constituent un point clé.

Dans le cas d'une ressource indisponible, l'implémentation d'un disjoncteur logiciel peut répondre par l'action appropriée et répondre convenablement.

Un disjoncteur peut avoir l'un de ces trois états : Fermé, Ouvert et Demi-ouvert.

L'état Fermé est l'état normal pour l'application ou le service. Dans cet état, les requêtes sont acheminées via le chemin d'accès standard. Un compteur effectue le suivi des taux d'échec et les compare à un seuil. Si un taux d'échec dépasse le seuil, le disjoncteur définit l'état sur Ouvert. Si un appel à une ressource de base de données a échoué à l'issue de 100 tentatives consécutives de connexion, il est inutile de continuer à appeler la base de données. Un disjoncteur peut être déclenché à ce seuil et les mesures appropriées peuvent être prises.

En état Ouvert, le disjoncteur achemine les requêtes vers le ou les chemins d'accès de limitation des risques. Il peut s'agir d'une interruption immédiate ou d'une autre forme de dégradation progressive. En passant à l'état Ouvert, le disjoncteur va également démarrer un minuteur. Une fois celui-ci expiré, le disjoncteur passe à l'état Demi-ouvert.

Cet état commence à acheminer un nombre limité de requêtes via le chemin d'accès standard. En cas de réussite, le disjoncteur passe à l'état Fermé. Si ce nombre limité de requêtes échoue, le disjoncteur repasse à l'état Ouvert.

En incluant un modèle de disjoncteur dans votre architecture, tenez compte des éléments suivants :

  • Un disjoncteur peut appeler différentes migrations ou limitations ou différents délais lorsqu'il est en état Ouvert, en fonction du type d'exception levé à partir de l'opération.

  • Un disjoncteur doit consigner tous les états de transition. Ceci permet aux opérateurs de surveiller le comportement de transition et d'affiner les minuteurs pour empêcher des états Ouvert prolongés ou des passages trop fréquents de l'état Ouvert à l'état Demi-ouvert.

  • Au lieu d'utiliser un minuteur pour passer de l'état Ouvert à Demi-ouvert, le disjoncteur peut régulièrement tester le chemin d'accès standard pour déterminer s'il peut être utilisé de nouveau normalement.

  • Faites attention lors de l'utilisation d'un disjoncteur durant le traitement d'une opération menant à plusieurs partitions. Dans un tel cas, le problème est que l'intégrité peut être au niveau des partitions et peut entraîner deux scénarios indésirables :

    • Le passage à l'état Ouvert alors qu'une seule partition a échoué.

    • Le passage accidentel à un état Fermé lorsqu'une ou plusieurs partitions sont normales.

Une implémentation courante de ce modèle est associée à l'accès aux bases de données ou services de données. Une fois qu'un type est établi et un niveau d'activité échoue, le disjoncteur doit réagir. Avec des données, cela est généralement causé par l'incapacité de se connecter à une base de données ou à un service de données devant la base de données.

Si un appel à une ressource de base de données a échoué à l'issue de 100 tentatives consécutives de connexion, il est inutile de continuer à appeler la base de données. Un disjoncteur peut être déclenché à ce seuil et les mesures appropriées peuvent être prises.

Dans certains cas, notamment pour la connexion aux services de données, cela peut être le résultat de la limitation de la bande passante sur un client qui a dépassé le nombre d'appels autorisés au cours d'une période donnée. Le disjoncteur peut définir la valeur de délai entre les appels jusqu'au moment où les connexions sont établies et satisfont les niveaux de tolérance.

Dans d'autres cas, la banque de données peut ne pas être disponible. Si une copie redondante des données est disponible, le système peut basculer vers ce réplica. Si un réplica est indisponible ou si le service de base de données est arrêté sur tous les centres de données d'un fournisseur, une approche secondaire peut être adoptée. Cela peut inclure des données sources d'une version des données demandées au moyen d'un autre fournisseur de services de données. Cette autre source peut être issue d'un cache, d'un autre type de banque de données persistantes sur le fournisseur actuel de cloud, d'un autre fournisseur de cloud ou d'un centre de données sur site. Lorsque cette alternative n'est pas disponible, le service peut également retourner une erreur reconnaissable qui peut être gérée correctement par le client.

Exemple de disjoncteur : Netflix

Netflix, une société de diffusion de contenu multimédia, est souvent citée en tant qu'exemple d'architecture résiliente. Lorsque nous avons abordé le sujet du modèle de disjoncteur chez Netflix, l'équipe a mentionné plusieurs critères inclus dans leur disjoncteur dans leur Blog sur les technologies Netflix. Ceux-ci comprennent notamment :

  1. Une demande envoyée au service distant arrive à expiration.

  2. Le pool de threads et la file d'attente des tâches associées utilisés pour interagir avec une dépendance de service sont à 100 % de leur capacité.

  3. La bibliothèque cliente utilisée pour interagir avec une dépendance du service lève une exception.

Tout cela contribue au taux d'erreur global. Lorsque ce taux d'erreur dépasse les seuils définis, le disjoncteur « est activé » et le circuit de ce service sert immédiatement de circuit de secours même sans tentative de connexion au service distant.

Dans cette même entrée de blog, l'équipe de Netflix indique que le disjoncteur de chacun de ses services implémente un circuit de secours à l'aide de l'une des trois méthodes suivantes :

  1. Interruption personnalisée : une bibliothèque cliente du service offre une méthode de secours invocable ou des données disponibles localement sur un serveur d'API (par exemple, un cookie ou un cache local) permettent de générer une réponse de secours.

  2. Échec sans avertissement : une méthode retourne la valeur NULL au client demandeur, ce qui fonctionne bien lorsque les données demandées sont facultatives.

  3. Interruption immédiate : lorsque des données sont nécessaires ou si aucune solution de secours n'est disponible, une réponse 5xx est retournée au client. Cette approche privilégie la conservation de serveurs d'API sains et l'activation d'une récupération rapide lorsque les services affectés reviennent en ligne, mais au détriment d'un impact négatif sur l'interface utilisateur du client.

Pour appliquer un contrat de niveau de service, une entreprise doit aborder la façon dont son service de données va traiter deux catégories d'aberrations : les parties approuvées et les mauvais acteurs.

Parties approuvées et liste blanche

Les parties approuvées sont des organisations avec lesquelles l'organisation peut prendre des dispositions particulières, et pour lesquelles des exceptions au contrat de niveau de service standard peuvent être faites.

  • Tiers avec des contrats personnalisés

    Il peut y avoir des utilisateurs d'un service qui souhaitent négocier des stratégies ou des tarifs spéciaux. Dans certains cas, un volume élevé d'appels au service de données peut justifier un tarif particulier. Dans d'autres cas, la demande d'un service de données spécifique peut dépasser le volume spécifié dans les couches standard d'utilisation. Ces clients doivent être définis en tant que parties de confiance pour éviter de les marquer par inadvertance comme étant des mauvais acteurs.

  • Liste blanche

    L'approche par défaut de gestion des parties de confiance consiste à créer une liste blanche. Une liste blanche, qui identifie la liste des parties approuvées, est utilisée par le service lorsqu'il détermine les règles métier à appliquer lors du traitement de l'utilisation du client. La liste blanche est généralement créée en autorisant une plage d'adresses IP ou une clé d'API.

    Lors de l'établissement d'une stratégie de consommation, une entreprise doit déterminer si la liste blanche est prise en charge ; la façon dont un client doit procéder pour figurer sur la liste blanche ; comment ajouter un utilisateur à la liste blanche ; et dans quelles circonstances un client est supprimé de la liste blanche.

  • Gestion des mauvais acteurs

    Si les parties approuvées se trouvent à une extrémité du spectre des clients, le groupe à l'autre extrémité est celui des « mauvais acteurs ». Les mauvais acteurs placent une charge sur le service, généralement issue d'une tentative de « surconsommation excessive ». Dans certains cas, le mauvais comportement est réellement accidentel. Dans d'autres cas, il est intentionnel et, dans quelques cas, il est malveillant. Ces acteurs sont étiquetés comme étant « mauvais », car les actions intentionnelles ou autres, peuvent avoir un impact sur la disponibilité d'un ou de plusieurs services.

    La charge des mauvais acteurs peut introduire des coûts inutiles pour le fournisseur de services de données et compromettre l'accès des consommateurs qui respectent les conditions d'utilisation et ont des attentes raisonnables en ce qui concerne le service, comme le définit le contrat de niveau de service. Les mauvais acteurs devront par conséquent être traités de manière prescrite et cohérente. Les réponses classiques données aux mauvais acteurs sont la limitation et l'inscription sur liste noire.

  • Limitation

    Les organisations doivent définir une stratégie pour traiter les pics d'utilisation par les consommateurs du service de données. Les augmentations significatives du trafic de tout consommateur peuvent placer une charge inattendue sur le service de données. Si de tels pics se produisent, l'organisation peut souhaiter limiter l'accès de ce consommateur pendant un certain temps. Dans ce cas le service refuse toutes les demandes du consommateur pendant une période donnée, telle qu'une minute, cinq minutes ou dix minutes. Durant ce laps de temps, les demandes de service du consommateur ciblé génèrent un message d'erreur lui indiquant que son accès est limité en raison d'une surutilisation.

    Le consommateur à l'origine des demandes peut réagir en conséquence, par exemple en modifiant son comportement.

    L'organisation doit déterminer si elle souhaite implémenter la limitation et définir des règles métier connexes. Si elle détermine que les consommateurs peuvent être limités, elle doit également choisir les comportements qui déclenchent la réponse de limitation.

  • Liste noire

    Même si la limitation doit corriger le comportement des mauvais acteurs, la réussite n'est pas toujours au rendez-vous. Dans les cas où cela ne fonctionne pas, l'organisation peut vouloir interdire un consommateur. L'inverse d'une liste blanche, une liste noire identifie les consommateurs qui ne sont pas autorisés à accéder au service. Le service répondra aux demandes d'accès des clients figurant sur la liste noire de manière appropriée, et d'une façon qui réduit l'utilisation des ressources du service de données.

    La liste noire, comme la liste blanche, est en général créée en utilisant une clé d'API ou une plage d'adresses IP.

    Lors de l'établissement d'une stratégie de consommation, l'organisation doit spécifier les comportements qui placeront un consommateur sur liste noire ; la façon dont la liste noire peut être appelée ; et comment un consommateur peut être supprimé de la liste noire.

Les utilisateurs font des erreurs. Qu'il s'agisse d'un développeur qui apporte une modification au code pouvant avoir des conséquences inattendues, d'un administrateur de base de données qui supprime accidentellement une table dans une base de données ou d'un utilisateur qui apporte une modification sans la documenter, il existe de nombreuses possibilités pour qu'un utilisateur rende par inadvertance un service moins résilient.

Pour réduire l'erreur humaine, une approche logique consiste à limiter le nombre de personnes impliquées dans le processus. Grâce à l'introduction de l'automation, vous limitez la possibilité de compromettre le service à partir des deltas ad hoc et involontaires du comportement inattendu.

Il existe un mime dans la communauté DevOps avec un personnage de dessin animé disant « Automate All the Things ». Dans le cloud, la plupart des services sont affichés avec une API. Des outils de développement à l'infrastructure virtualisée en passant par les services de plateforme aux solutions fournies comme Software as a Service (SaaS), la plupart des éléments peuvent faire l'objet d'un script.

L'écriture de script est fortement recommandée. Un script simplifie le déploiement et la gestion cohérents et prédictibles et dégage des dividendes significatifs pour l'investissement.

Automatisation du déploiement

L'un des points clés de l'automation réside dans la génération et le déploiement d'une solution. L'automation peut faciliter le test et le déploiement dans plusieurs environnements pour une équipe de développement. Le développement, le test, la mise en lots, la version bêta et la production peuvent tous être déployés facilement et de manière cohérente à l'aide de builds automatisées. La possibilité d'effectuer un déploiement cohérent entre les différents environnements vise à garantir que les éléments en production sont représentatifs des éléments testés.

Considérez les éléments suivants comme du « code » : les scripts, les fichiers de configuration et les métadonnées associés au déploiement. Le code comprend également la gestion de ces artefacts dans le contrôle de code source pour :

  • les modifications de documents ;

  • l'autorisation du contrôle de version ;

  • l'autorisation de contrôle d'accès basé sur des rôles ;

  • la vérification de sauvegarde des contenus ;

  • l'obtention d'une source unique d'approbation.

Établir et automatiser un atelier de test

Le test est un autre point qui peut être automatisé. Comme le déploiement automatisé, la création d'un test automatisé est précieuse pour vérifier que votre système est résilient et demeure résilient dans le temps. À mesure que le code et l'utilisation de votre service évoluent, il est essentiel de conserver tout test approprié qui est terminé, du point de vue fonctionnel et de l'échelle.

Automatiser l'archivage et la purge des données

L'un des points qui reçoit peu d'attention est celui de l'archivage et de la purge des données. Le volume de données croît et continue de croître dans des volumes plus élevés et plus variés et ce, plus que jamais. Selon la technologie de base de données et les types de requêtes requis, les données inutiles peuvent réduire le temps de réponse de votre système et augmenter les coûts inutilement. Pour les plans de résilience qui incluent un ou plusieurs réplicas d'une banque de données, le fait de supprimer toutes les données exceptées celles nécessaires peut accélérer les activités de gestion, telles que la sauvegarde et la restauration des données.

Identifiez les conditions requises pour votre solution liée aux données nécessaires à la fonctionnalité principale, les données nécessaires à des fins de conformité mais pouvant être archivées et les données qui ne sont plus nécessaires et peuvent être purgées.

Utilisez les API disponibles dans les produits et les services associés pour automatiser l'implémentation de ces conditions.

Lorsque vous créez une architecture résiliente, il est aussi essentiel de comprendre les concepts des domaines d'erreur et de mise à niveau.

Domaines d'erreur

Les domaines d'erreur limitent l'installation des services en fonction de limites matérielles connues et de la probabilité qu'un type spécial de panne affecte un ensemble d'ordinateurs. Un domaine d'erreur est défini comme une série d'ordinateurs pouvant tomber en panne simultanément et, est généralement défini par des propriétés physiques (un rack spécifique d'ordinateur, une série d'ordinateurs qui partagent la même source d'alimentation, etc.).

Domaines de mise à niveau

Les domaines de mise à niveau sont semblables aux domaines d'erreur. Ils définissent un ensemble physique de services qui sont mis à jour simultanément par le système. Le programme d'équilibrage de charge chez le fournisseur de cloud doit avoir connaissance des domaines de mise à niveau pour garantir que si un domaine particulier est mis à jour le système global est équilibré et les services sont disponibles.

Les mises à niveau peuvent survenir :

  • au niveau de l'hyperviseur (« mise à niveau HostOS ») ;

  • au niveau du système d'exploitation (« mise à niveau du système d'exploitation invité ») ;

  • dans le cadre du déploiement d'une mise à niveau d'application ou de service dans l'environnement.

Selon le fournisseur de cloud et les services de plateforme utilisés, les domaines d'erreur et les domaines de mise à niveau peuvent être fournis automatiquement, être une option à laquelle votre service peut souscrire via une API ou nécessiter une solution de première partie ou de tiers.

Résilience durant un échec de domaine d'erreur pendant une mise à niveau

Même si les domaines d'erreur et de mise à niveau sont différents, ils peuvent se croiser dans un scénario. Dans celui-ci, une défaillance matérielle fait passer une machine virtuelle hors ligne, tandis qu'une mise à niveau se déroule simultanément sur une autre instance de machine virtuelle. Dans ce cas, deux machines virtuelles seront hors ligne. Si le déploiement du service contient uniquement deux machines virtuelles, le service sera alors hors ligne. Pensez à cela lorsque vous évaluerez le nombre d'instances à fournir avec le contrat SLA de votre choix.

Les plateformes cloud permettent généralement d'identifier un niveau d'affinités pour un groupe de ressources. Nous nommons ces ressources « groupe d'affinités » ou « ensemble d'affinités ». Ceci aide la plateforme sous-jacente à placer les ressources associées ensemble et à attribuer des instances entre les domaines d'erreur et de mise à niveau.

Les solutions sur site sont souvent fondées sur la redondance de façon à faciliter la disponibilité et l'évolutivité. Du point de vue de la disponibilité, les centres de données redondants permettaient d'augmenter la probabilité de continuité des activités face aux échecs d'infrastructure dans un centre de données spécifique ou dans une partie d'un centre de données.

Pour les applications dont les consommateurs sont répartis géographiquement, la gestion du trafic et les implémentations redondantes routaient les utilisateurs vers les ressources locales, souvent avec une latence faible.

noteRemarque
La résilience des données, qui inclut la redondance, est traitée en tant que sujet distinct dans la section intitulée Établir une approche de résilience des données.

Redondance et cloud

Sur site, la redondance a été historiquement obtenue à l'aide d'ensembles en double de matériel, de logiciels et de réseau. Elle est parfois implémentée dans un cluster dans un seul emplacement ou distribuée dans plusieurs centres de données.

Lorsque vous concevez une stratégie pour le cloud, il est important de rationaliser le besoin de redondance entre trois vecteurs. Ces vecteurs incluent le code déployé dans l'environnement d'un fournisseur de cloud, la redondance des fournisseurs eux-même et la redondance entre le cloud et le site.

Redondance de déploiement

Lorsqu'une organisation a sélectionné un fournisseur de cloud, il est important de créer une stratégie de redondance pour le déploiement au sein du fournisseur.

En cas de déploiement en tant que Platform as a Service (PaaS), nombre de ces opérations peuvent être gérées par la plateforme sous-jacente. Dans un modèle Infrastructure as a Service (IaaS), ce n'est pas le cas.

  • Déployer un nombre n de rôles dans un centre de données

    La forme la plus simple de redondance consiste à déployer votre solution dans plusieurs instances dans un seul fournisseur de cloud. Grâce au déploiement dans plusieurs instances, la solution réduit le temps mort qui se produit lorsqu'un seul nœud est déployé.

    Dans de nombreux environnements Platform as a Service, l'état de l'ordinateur virtuel qui héberge le code est analysé et les ordinateurs virtuels détectés comme n'étant pas sains peuvent être automatiquement remplacés par un nœud sain.

  • Déployer dans plusieurs centres de données

    Alors que le déploiement de plusieurs nœuds dans un seul centre de données présente des avantages, les architectures doivent tenir compte du fait qu'un centre de données entier peut être indisponible. Bien que cela ne soit pas fréquent, des événements tels que des catastrophes naturelles, guerre, etc., peuvent entraîner une interruption de service dans un emplacement géographique spécifique.

    Pour atteindre les objectifs de votre contrat de niveau de service, il peut être nécessaire de déployer la solution dans plusieurs centres de données pour le fournisseur de cloud sélectionné. Il existe plusieurs approches possibles pour cela, tel qu'indiqué ci-dessous.

    1. Déploiements entièrement redondants dans plusieurs centres de données

      La première option est une solution entièrement redondante dans plusieurs centres de données réalisée conjointement avec un fournisseur de gestion du trafic. Un aspect clé de cette solution est l'impact des coûts liés au calcul pour ce type de redondance, qui augmentera de 100 % pour chaque déploiement de centre de données supplémentaire.

    2. Déploiement partiel dans un ou plusieurs centres de données secondaires pour le basculement

      Une autre méthode consiste à effectuer un déploiement partiel dans un centre de données secondaire de taille réduite. Par exemple, si la configuration standard utilise 12 instances de calcul, le centre de données secondaire contient un déploiement composé de 6 instances de calcul.

      Cette approche, utilisée conjointement avec la gestion du trafic, permet la continuité des activités avec un service dégradé après un problème grave qui a uniquement affecté le centre principal.

      Étant donné le nombre limité de fois où un centre de données est mis entièrement hors connexion, cette approche est généralement perçue comme étant rentable pour le calcul (surtout si une plateforme permet à l'organisation d'intégrer facilement de nouvelles instances dans le deuxième centre de données).

    3. Déploiements répartis dans plusieurs centres de données avec nœuds de sauvegarde

      Pour certaines charges de travail, en particulier dans l'environnement vertical des services financiers, il existe une quantité importante de données qui doivent être traitées dans une fenêtre de temps courte et immuable. Dans ce cas, le travail est effectué dans des temps plus courts et les coûts de redondance se justifient pour obtenir des résultats dans cette fenêtre.

      Dans ce cas, le code est déployé dans plusieurs centres de données. Le travail est divisé et distribué entre les nœuds à des fins de traitement. Dans l'instance dans laquelle un centre de données devient indisponible, le travail prévu pour ce nœud est remis au nœud de sauvegarde qui achèvera la tâche.

    4. Plusieurs déploiements de centres de données avec taille de région appropriée par centre de données

      Cette méthode utilise les déploiements redondants qui existent dans plusieurs centres de données, mais qui sont dimensionnés correctement pour l'échelle du public de la zone géographique concernée.

Redondance de fournisseur

Lorsque la redondance centrée sur le centre de données est correcte, les contrats SLA sont au niveau du service par rapport au centre de données. De nombreux services commerciaux actuels déploient de nouvelles versions vers une « partie » de l'environnement de production pour valider le code en production. Cependant, il existe un risque que les services proposés par un fournisseur puissent devenir indisponibles sur plusieurs ou l'ensemble des centres de données.

Selon les contrats de niveau de service d'une solution, il peut être souhaitable d'intégrer également la redondance de fournisseur. Pour réaliser cette opération, les produits déployables dans le cloud ou les services du cloud qui fonctionnent sur plusieurs plateformes du cloud doivent être identifiés. Microsoft SQL Server, par exemple, peut être déployé dans un ordinateur virtuel dans le cadre de l'offre Infrastructure as a Service de la plupart des fournisseurs.

Pour les services fournis par le cloud, cela peut s'avérer plus difficile, car il n'existe aucune interface standard en place, même pour les services de base, tels que le calcul, le stockage, les files d'attente, etc. Si la redondance de fournisseur est souhaitée pour ces services, elle n'est réalisable qu'au moyen d'une couche d'abstraction. Une couche d'abstraction peut fournir suffisamment de fonctionnalités pour une solution, mais elle ne fera pas l'objet d'innovations aussi rapidement que les services sous-jacents et peut empêcher une organisation d'adopter facilement de nouvelles fonctionnalités offertes par un fournisseur.

Si les services de fournisseur redondant se justifient, cela peut être à un des différents niveaux : une application complète, une charge de travail ou un aspect d'une charge de travail. Au niveau approprié, évaluez les besoins en services de calcul, de données et de plateforme et déterminez ce qui doit vraiment être redondant et ce qui peut être géré à l'aide de méthodes de façon à fournir une dégradation progressive.

Redondance sur site

Alors qu'une dépendance sur un fournisseur de cloud peut avoir un sens du point de vue fiscal, il peut arriver que certaines règles d'entreprise requièrent la redondance sur site pour la continuité de la conformité et/ou des activités.

Selon les contrats de niveau de service d'une solution, il peut être souhaitable d'intégrer également la redondance sur site. Pour réaliser cette opération, les produits déployables dans le cloud privé ou les services de cloud computing qui fonctionnent sur plusieurs types de cloud doivent être identifiés. Comme dans le cas de la redondance de fournisseur, Microsoft SQL Server est un bon exemple de produit qui peut être déployé sur site ou dans le cadre d'une offre IaaS.

Pour les services fournis par le cloud, cela peut s'avérer plus délicat, car il n'existe souvent aucun équivalent sur site avec une symétrie des interfaces et des fonctionnalités.

Si des services de fournisseur redondant sont nécessaires sur site, cela peut être à un des différents niveaux : une application complète, une charge de travail ou un aspect d'une charge de travail. Au niveau approprié, évaluez les besoins en services de calcul, de données et de plateforme et déterminez ce qui doit vraiment être redondant et ce qui peut être géré à l'aide de méthodes de façon à fournir une dégradation progressive.

Approches de configuration de redondance

Lorsque vous identifiez les approches de configuration de la redondance, les classifications qui existaient avant le cloud s'appliquent également. Selon les types des services utilisés dans votre solution, une partie peut être gérée par la plateforme sous-jacente automatiquement. Dans d'autres cas, cette fonctionnalité est gérée à l'aide de technologies telles que Windows Fabric.

  1. Active/active — Le trafic destiné à un nœud est passé à un nœud existant ou la charge est équilibrée entre les autres nœuds. Cela n'est possible que lorsque les nœuds utilisent une configuration logicielle homogène.

  2. Active/passive — Fournit une instance entièrement redondante de chaque nœud, qui n'est mise en ligne qu'en cas d'échec du nœud principal associé. Cette configuration requiert généralement le plus de matériel supplémentaire.

  3. N+1 — Fournit un seul nœud supplémentaire qui est mis en ligne pour assurer le rôle du nœud défaillant. Dans le cas d'une configuration logicielle hétérogène sur chaque nœud principal, le nœud supplémentaire doit être universellement capable d'assumer les rôles des nœuds principaux dont il a la charge. Cela fait référence aux clusters qui ont plusieurs services exécutés simultanément ; dans le cas d'un seul service, cela dégénère à active/passive.

  4. N+M — Dans les cas où un seul cluster gère plusieurs services, disposer d'un seul nœud de basculement dédié peut ne pas offrir une redondance suffisante. Dans ce cas, plusieurs serveurs de secours (M) sont inclus et disponibles. Le nombre de serveurs de secours est un compromis entre les coûts et les exigences de fiabilité.

  5. N-to-1 — Permet de basculer le nœud de secours de façon à ce qu'il devienne temporairement le nœud actif, jusqu'à ce que le nœud d'origine puisse être restauré ou remis en ligne, au point auquel les services ou les instances doivent rebasculer afin de restaurer une haute disponibilité.

  6. N-to-N — Une combinaison active/active et N+M, N to N redistribue les services, les instances ou les connexions du nœud défaillant entre les autres nœuds actifs, ce qui supprime (comme avec active/active) la nécessité du nœud de secours, mais introduit la nécessité d'une capacité supplémentaire sur tous les nœuds actifs.

Si le trafic est toujours réparti dans différents points géographiques ou routé vers différents centres de données pour satisfaire des scénarios de continuité des activités, les fonctionnalités de gestion du trafic sont essentielles pour garantir que les demandes dans votre solution sont acheminées vers la ou les instances concernées.

Il est important de noter qu'une dépendance sur un service de gestion du trafic introduit un seul point de défaillance. Il est important d'étudier le contrat de niveau de service du service de gestion du trafic principal de votre application et de déterminer si d'autres fonctionnalités de gestion du trafic sont justifiées par vos besoins.

Alors que de nombreuses applications du cloud à grande échelle ont très bien partitionné leur couche Web, elles réussissent moins bien à mettre à l'échelle leur couche Données dans le cloud. Avec une diversité des périphériques connectés en croissance constante, le volume de données générées et interrogées se développe à des niveaux jamais vus auparavant. La nécessité de prendre en charge 500 000 nouveaux utilisateurs par jour, par exemple, est désormais considérée comme étant raisonnable.

Disposer d'une stratégie de partitionnement est essentiel entre plusieurs dimensions, notamment stockage, interrogation et gestion de ces données.

Décomposition et partitionnement

En raison des avantages et des inconvénients liés aux différentes technologies, il est courant de tirer parti des technologies les plus adaptées pour la charge de travail donnée.

Disposer d'une solution qui est décomposée par charges de travail vous permet de choisir les technologies de données adaptées pour une charge de travail donnée. Par exemple, un site Web peut utiliser le stockage de table pour le contenu d'une personne, en utilisant des partitions au niveau utilisateur pour une expérience de réponse. Ces lignes de table peuvent être agrégées périodiquement dans une base de données relationnelle à des fins de création de rapports et d'analyse.

Les stratégies de partitionnement peuvent varier et varieront souvent selon les technologies sélectionnées.

Lorsque vous définissez votre stratégie, il est aussi important d'identifier les aberrations qui vont nécessiter une stratégie modifiée ou parallèle. Par exemple, imaginez que vous avez développé un site de réseau social dans lequel un utilisateur normal peut établir 500 connexions, tandis qu'une célébrité peut en établir 5 000 000.

Si le site est prévu pour 100 000 000 d'utilisateurs et que ce nombre contient moins de 50 000 célébrités, la stratégie de partitionnement principale sera optimisée pour un utilisateur normal. Vous devriez gérer les célébrités différemment. Tandis qu'un grand nombre d'utilisateurs pourrait être regroupé sur une seule partition, chaque célébrité pourrait avoir sa propre partition.

Présentation des 3 V

Pour créer correctement une stratégie de partitionnement, une entreprise doit d'abord la comprendre.

Les 3 V, fréquemment utilisés par Gartner, examinent trois différents aspects des données. Comprendre la façon dont les 3 V sont liés à vos données vous aidera lors d'une prise de décision en connaissance de cause sur les stratégies de partitionnement.

  • Volume

    Le volume fait référence à la taille des données. Il a très peu d'incidences réelles sur la stratégie de partitionnement. Les limitations de volume sur une technologie de données particulière peuvent forcer le partitionnement en raison des limitations de taille, de la vitesse des requêtes sur le volume, etc.

  • Vitesse

    La vitesse fait référence à la fréquence à laquelle vos données augmentent. Vous concevrez probablement une stratégie de partitionnement différente pour une banque de données à croissance lente et pour une qui doit tenir compte de 500 000 utilisateurs par jour.

  • Variété

    La variété fait référence aux différents types de données appropriés pour la charge de travail. Qu'il s'agisse de données relationnelles, de paires clé-valeur, de profils de média social, d'images, de fichiers audio, de vidéos ou d'autres types de données, il est important de les comprendre. Cela permet à la fois de choisir la technologie de données appropriée et de prendre des décisions avisées pour votre stratégie de partitionnement.

Partitionnement horizontal

L'approche la plus utilisée de partitionnement des données est le partitionnement horizontal. Lors du partitionnement horizontal, une décision est prise sur des critères permettant de partitionner une banque de données en plusieurs partitions. Chaque partition contient le schéma entier, avec les critères gérant le positionnement des données dans les partitions appropriées.

Selon le type de données et l'utilisation des données, cette opération peut être effectuée de différentes manières. Par exemple, une organisation peut choisir de partitionner ses données en fonction du nom d'un client. Dans un autre cas, la partition peut être centrée sur les données, le partitionnement étant effectué sur l'intervalle calendaire approprié d'heure, du jour, de la semaine ou du mois.

Diagramme de partitionnement horizontal.

Figure 5 : Exemple de partitionnement horizontal par nom

Partitionnement vertical

Le partitionnement vertical constitue une autre approche. Cette approche optimise le positionnement des données dans différents magasins, souvent lié à la diversité des données. La figure 5 illustre un exemple où les métadonnées relatives à un client sont insérées dans une banque alors que les miniatures et les photos sont insérées dans des banques distinctes.

Le partitionnement vertical améliore le stockage et la remise des données. Sur la figure 5, par exemple, si la photo est rarement affichée pour un client, retourner 3 mégaoctets par enregistrements peut ajouter des coûts inutiles dans un modèle par répartition.

Diagramme de partitionnement verticale.

Figure 6 : Exemple de partitionnement vertical

Partitionnement hybride

Dans de nombreux cas, il est nécessaire de créer une stratégie de partitionnement hybride. Cette approche procure les avantages des deux approches dans une solution unique.

La figure 6 illustre un exemple de cette approche, où le partitionnement vertical vu précédemment est maintenant augmenté pour tirer parti du partitionnement horizontal des métadonnées du client.

Diagramme de partitionnement horizontal.

Figure 7 : Exemple de partitionnement horizontal

Le réseau se trouve au cœur du cloud computing. Il est essentiel, car il fournit la structure ou la dorsale principale de façon à ce que les périphériques se connectent à des services et que les services se connectent à d'autres services. Il existe trois limites réseau à prendre en compte dans toute application de prévention de défaillance.

Celles-ci sont détaillées ci-dessous avec Azure utilisé comme exemple pour fournir le contexte :

  1. Les limites de rôle sont traditionnellement appelées couches. Les exemples classiques sont une couche Web ou une couche de logique métier. Si nous examinons Azure comme exemple, il a introduit des rôles dans le cadre de sa conception de base pour permettre la prise en charge par l'infrastructure des applications modernes distribuées à plusieurs couches. Azure garantit que les instances de rôle qui appartiennent au même service sont hébergées dans l'étendue d'un seul environnement réseau et gérées par un seul contrôleur de structure.

  2. Les limites de service représentent des dépendances sur les fonctionnalités fournies par d'autres services. Les exemples classiques sont un environnement SQL pour l'accès à la base de données relationnelle et un Service Bus de prise en charge de la messagerie pub/sub. Dans Azure, par exemple, les limites de service sont appliquées via le réseau : aucune garantie n'est donnée qu'une dépendance du service fera partie du même environnement du contrôleur réseau ou de structure. Cela peut se produire, mais l'hypothèse de conception pour toute application doit être que toute dépendance du service se trouve sur un réseau géré par un autre contrôleur de structure.

    Diagramme des instances de rôle de service cloud
    Figure 8

  3. Les limites de point de terminaison sont externes au cloud. Elles incluent les points de terminaison de consommation, en général une unité, qui se connectent au cloud pour utiliser des services. Vous devez examiner des considérations spéciales dans cette partie de la conception en raison de la nature variable et non fiable du réseau. Les limites de rôle et les limites de service sont dans les limites de l'environnement du cloud et on peut supposer un certain niveau de fiabilité et de bande passante. Pour les dépendances externes, aucune hypothèse ne peut être effectuée et une attention supplémentaire doit être apportée à la capacité de l'unité de consommer des services, c'est-à-dire des données et des interactions.

    Le réseau de par sa nature même introduit une latence à mesure qu'il achemine des informations d'un point à un autre. Pour enrichir l'expérience des utilisateurs et en tant que services dépendants ou rôles, l'architecture et la conception de l'application doivent chercher des méthodes pour réduire la latence de façon judicieuse et gérer la latence inévitable explicitement. L'une des méthodes les plus courantes pour limiter la latence consiste à éviter les appels de services impliquant le réseau ; l'accès local aux données et aux services constitue une approche clé pour réduire la latence et introduire une meilleure réactivité. Les données et services locaux fournissent également une autre couche de sécurité en cas de défaillance. Tant que les demandes de l'utilisateur ou de l'application peuvent être servies dans l'environnement local, il est inutile d'interagir avec d'autres rôles ou services, ce qui élimine la possibilité d'indisponibilité du module dépendant comme point d'échec.

Caching

La mise en cache est une technique qui peut être utilisée pour améliorer la vitesse d'accès aux données lorsqu'il n'est pas possible de stocker des données localement. Elle est utilisée de manière efficace dans la plupart des services de cloud computing fonctionnant à grande échelle aujourd'hui. Comme le souligne la définition fournie par Wikipedia, un cache offre un accès local aux données qui sont régulièrement demandées par les applications. La mise en cache repose sur deux choses :

  • Les modèles d'utilisation des données par les utilisateurs et les applications dépendantes sont principalement en lecture seule. Dans certains scénarios, tels que les sites Web de commerce électronique, le pourcentage d'accès en lecture seule (parfois appelé navigation) représente jusqu'à 95 % des interventions de l'utilisateur sur le site.

  • Le modèle CIM de l'application fournit une couche supplémentaire de données sémantiques qui prend en charge l'identification des données stables et singulières optimales pour la mise en cache.

Mise en cache d'unité

Bien que ce ne soit pas l'objet de l'initiative de prévention de défaillance, la mise en cache d'unité est l'une des façons les plus efficaces pour faciliter l'utilisation et la robustesse des unités et de l'application de services. Il existe de nombreuses méthodes pour proposer des services de mise en cache sur l'unité ou la couche client, allant de la spécification HTML5 qui fournit des fonctionnalités natives de mise en cache implémentées dans tous les navigateurs standard aux instances de base de données locales telles que SQL Server Compact Edition ou autres.

Mise en cache distribuée

La mise en cache distribuée est un puissant ensemble de fonctionnalités, mais son objectif n'est pas de remplacer une base de données relationnelle ou une autre banque persistante ; en revanche, il vise à augmenter la réactivité des applications distribuées qui sont par nature centrées sur le processeur et donc sensibles à la latence. Un avantage secondaire lié à l'introduction de la mise en cache est la réduction du trafic vers la banque de données persistante, ce qui limite les interactions avec le service de données au minimum.

  • Modèles CIM optimisés pour la mise en cache

    noteRemarque
    La majeure partie du contenu de cette section repose sur le travail réalisé par Pat Helland lorsqu'il pensait aux données dans un monde d'architecture orientée services. Il est possible de lire la totalité de l'article sur MSDN (Microsoft Developer Network).

    Les données mises en cache sont par nature des données obsolètes, c.-à-d. des données qui ne sont plus actualisées. Un exemple de données en mémoire cache dans un domaine très différent est un catalogue de produits qui est envoyé à des milliers de foyers. Les données utilisées pour créer le catalogue de produits étaient à jour au moment de la création du catalogue. Une fois les presses lancées, les données, au fil du temps pendant le processus de production du catalogue, sont devenues obsolètes. Les données mises en cache étant obsolètes, les attributs des données par rapport à la stabilité et la singularité sont essentiels dans la conception de la mise en cache :

    • Stabilité : données dont l'interprétation n'est pas ambiguë dans l'espace et le temps. Cela signifie souvent que les valeurs des données ne changent pas. Par exemple, la plupart des entreprises ne recyclent jamais les ID des clients ou les numéros de SKU. Une autre technique pour créer des données stables consiste à ajouter des dates d'expiration aux données existantes. Le catalogue de produits imprimé ci-avant est un bon exemple. En règle générale, les détaillants acceptent des commandes issues d'un catalogue donné pendant deux périodes de publication. Si un catalogue est publié quatre fois par an, les données du catalogue de produits sont stables pendant six mois et peuvent être utilisées pour le traitement des informations telles que le passage et le traitement des commandes.

      Les données stables sont souvent référencées en tant que données maîtres ou données de référence. Dans l'initiative de prévention de défaillance, nous utiliserons le terme données de référence, car il s'agit d'un terme sémantiquement plus inclusif que données maîtres. Dans de nombreuses entreprises, les données maîtres ont une signification très spécifique et sont moins vastes que les données de référence.

    • Singularité : données pouvant être isolées par l'association à des instances identifiables avec aucune ou peu de mises à jour simultanées. Prenons l'exemple d'un panier d'achat. Le panier d'achat sera mis à jour, mais les mises à jour sont peu fréquentes et peuvent être totalement isolées du point de vue du stockage et du traitement.

      Les données pouvant être isolées, tel qu'indiqué ci-dessus, sont appelées données d'activité ou données de session.

      Avec ces deux attributs en tête, le schéma suivant émerge :

      Diagramme des types de données
      Figure 9

  • Modélisation des informations

    De nombreux architectes ou développeurs d'applications pensent aux modèles d'objet ou d'entité lorsqu'ils pensent à la modélisation CIM. Alors que les modèles d'objet ou d'entité font partie de l'art et de la science de modélisation CIM, beaucoup plus entrent dans un modèle CIM pour une application de prévention de défaillance. 

    Une première conception de l'analyse nécessaire pour le monde distribué actuel est axée sur la stabilité et la singularité. Un autre élément clé consiste à saisir la façon dont les données sont utilisées dans l'interaction avec l'utilisateur/unité ou dans le cadre des processus métiers à implémenter. La modélisation orientée objets doit faire partie de la conception des informations de plusieurs manières :

    • Masquage des informations : masquer ou ne pas donner accès aux informations qui ne sont pas utiles pour l'utilisateur ou le processus métier constitue une des meilleures méthodes pour éviter les conflits avec la ressource ou les données partagées stockées et gérées dans une base de données relationnelle.

      Un bon exemple montrant l'utilisation de manière efficace du masquage des informations pour améliorer la simultanéité réside dans la différence entre un système ERP classique et la façon dont Amazon.com gère la plupart des scénarios de suivi des stocks. Dans une implémentation classique d'un système ERP, la table de suivi des stocks représente l'une des tables les plus congestionnées ou réactives (dans une implémentation de base de données relationnelle). L'application ERP tente généralement de verrouiller les stocks jusqu'à ce que l'utilisateur ait terminé la transaction, indiquant le nombre exact d'éléments en stock à l'application lors du démarrage de la transaction. Certains systèmes, comme SAP, évitent le verrou de base de données mais acquièrent un verrou d'application dans le système d'empilage. Un grand nombre de techniques de la couche base de données ont été développées afin d'améliorer cette congestion : contrôle d'accès concurrentiel optimiste, lectures erronées, etc. Aucune ne fonctionne réellement proprement et toutes présentent des effets secondaires. Dans certains scénarios vous souhaitez verrouiller la table, mais ceux-ci doivent être peu nombreux et éloignés les uns des autres.

      Amazon.com a résolu le problème de manière beaucoup plus simple : la société a proposé à l'utilisateur un objectif de niveau de service (SLO) auquel il peut s'abonner de façon à l'accepter ou le refuser. Le SLO était le plus souvent exprimé sous la forme « généralement disponible dans N heures » ; l'utilisateur ne voyait pas le nombre réel d'ouvrages ou autres éléments disponibles, mais il disposait néanmoins d'informations sur la disponibilité. Aucun verrou de base de données n'était nécessaire. En fait, aucune connectivité de base de données n'était requise. Si le système n'était pas en mesure de respecter le SLO, il envoyait des excuses à l'acheteur (généralement par courrier électronique) et lui proposait un SLO mis à jour.

    • Ressources fongibles : The dictionary defines fungible as follows: « fongible (notamment des marchandises) se dit de choses pouvant être échangées ou remplacées, intégralement ou partiellement, par des choses de même nature ou qualité. » L'idée principale, encore une fois dans le but de réduire la friction d'accès aux données partagées, est d'utiliser la modélisation CIM de façon à permettre à l'utilisateur d'interagir avec une instance fongible des données plutôt qu'avec une instance spécifique. La réservation d'une chambre d'hôtel est un bon exemple. Il est possible d'exprimer nombre de spécificités, telles que nombre de lits, vue sur l'océan, fumeur/non fumeur, etc., sans jamais faire référence à la chambre « 123 ». En utilisant la modélisation de cette façon, il est possible de mettre en cache des informations sur des groupes de données fongibles, d'exécuter le processus d'entreprise par rapport au groupe et uniquement après la finalisation du processus d'extraction d'affecter une chambre spécifique hors de ce groupe. Des modèles hybrides de suppression d'une chambre spécifique d'un groupe une fois le processus d'extraction terminé sont également réalisables.

  • Gestion du cache

    Mettre en cache les informations uniquement au bon moment constitue une partie essentielle d'une stratégie de mise en cache réussie. Il existe de nombreuses techniques pour charger le cache : vous trouverez une présentation dans l'article « Mise en cache de l'environnement distribué ». En outre, les sections ci-dessous présentent quelques considérations sur la conception des applications de prévention de défaillance qui dépend de la mise en cache distribuée.

    • Données de référence : si l'environnement d'hébergement (contrôleur de structure ou centre de données) rencontre un problème, votre application sera déplacée vers un autre environnement. Dans le cas où une instance active de votre application est déjà active (conception active-active), la probabilité que le cache contienne déjà nombre des informations appropriées (notamment les données de référence) est élevée. Dans le cas où une nouvelle instance de votre application serait adaptée, aucune information ne se trouvera dans les nœuds de cache. Vous devez concevoir votre application de façon à ce que lors d'une absence dans le cache, elle charge automatiquement les données souhaitées. Dans le cas d'une nouvelle instance, vous pouvez disposer d'une routine de démarrage qui charge les données de référence en masse dans le cache. Une combinaison des deux est souhaitable, car les utilisateurs peuvent être actifs dès que l'application est servie par l'infrastructure du cloud.

    • Données d'activité : les techniques de base décrites pour les données de référence se vérifient également pour les données d'activité. Toutefois, il existe une tournure spécifique aux données d'activité. Il est supposé que les données de référence sont disponibles dans n'importe quelle banque persistante de l'application. Comme elles changent moins fréquemment, la synchronisation ne doit pas être un problème, bien qu'elle doive être prise en compte. Toutefois, les données d'activité, même si elles sont mises à jour en isolement et à une fréquence faible, seront plus volatiles que les données de référence. Idéalement le cache distribué rend les données d'activité persistantes régulièrement et réplique les données entre les différentes instances de l'application. Veillez à ce que les intervalles de persistance et de synchronisation soient suffisamment espacés pour éviter toute contention, mais suffisamment proches pour limiter la perte de données au minimum.

Il existe un malentendu très répandu sur la relation, notamment les domaines de responsabilité, entre la plateforme et l'application. L'un des domaines où cela est le plus gênant concerne les données.

Lorsqu'une plateforme comme Azure réalisera les promesses de stockage de plusieurs copies des données (et dans certains services en fournissant même la redondance dans différents points géographiques), les données stockées seront pilotées par l'application, la charge de travail et les services de composants. Si l'application prend une mesure qui endommage ses données d'application, la plateforme en stocke plusieurs copies.

Lors de l'établissement des modes et points d'échec, il est important d'identifier les domaines d'application qui pourraient endommager les données. Lorsque le point d'origine peut varier du code erroné à des messages incohérents dans votre service, il est important d'identifier les modes et points d'échec associés.

Mise à jour au niveau de l'application

  • Idempotence

    Une hypothèse concernant les services connectés est qu'ils ne seront pas disponibles à 100 % et que la gestion des erreurs temporaires avec une logique de nouvelle tentative est la principale méthode d'implémentation. Dans les cas où la logique de nouvelle tentative est implémentée, il existe un risque que le même message soit envoyé plusieurs fois, que les messages soient envoyés hors séquence, etc.

    Les opérations doivent être conçues de façon à être idempotentes, ce qui garantit que l'envoi du même message à plusieurs reprises n'entraîne pas une banque de données inattendue ou polluée.

    Par exemple, l'insertion de données issues de toutes les demandes risque de générer l'ajout de plusieurs enregistrements si l'opération de service est appelée plusieurs fois. Une autre approche consiste à implémenter le code en tant que « upsert » intelligent qui effectue une mise à jour si un enregistrement existe ou une insertion dans le cas contraire. Un horodateur ou un identificateur global peut être utilisé pour identifier les nouveaux messages parmi les messages traités précédemment, en insérant uniquement les plus récents dans la base de données et en mettant à jour les enregistrements existants si le message est plus récent que celui reçu précédemment.

  • Activités de charge de travail et comportement de compensation

    Outre l'idempotence, un autre point à prendre en compte est le concept de comportement de compensation.

    Un exemple réel de comportement de compensation est illustré lors du retour d'un produit qui a été payé avec une carte de crédit. Dans ce scénario, un consommateur visite un site de vente, fournit une carte de crédit et son compte est débité. Si le consommateur retourne le produit au site de vente, une stratégie est évaluée et si le retour est conforme à la stratégie, le site de vente émet un crédit correspondant au montant de l'achat sur le compte du consommateur.

    Dans un monde où un jeu de systèmes connectés ne cesse de croître et les services composites sont émergents, il est essentiel de comprendre comment gérer le comportement de compensation.

    Pour nombre de développeurs d'applications métiers, les concepts des transactions ne sont pas nouveaux, mais le cadre de référence est souvent lié aux fonctionnalités transactionnelles exposées par les technologies de données locales et les bibliothèques de code associées. En examinant le concept pour le cloud, cette perspective doit prendre en compte de nouvelles considérations liées à l'orchestration des services distribués.

    L'orchestration des services peut s'étendre sur plusieurs systèmes distribués, être longue et avec état. Elle est rarement synchrone, peut s'étendre sur plusieurs systèmes et durer de quelques secondes à des années selon le scénario d'entreprise.

    Dans un scénario de chaîne d'approvisionnement, vingt-cinq organisations peuvent être liées dans la même activité de charge de travail. Par exemple, il peut y avoir un ensemble de vingt-cinq systèmes ou plus qui sont interconnectés dans une ou plusieurs orchestrations de services.

    En cas de réussite, les vingt-cinq systèmes doivent être informés que l'activité est terminée. Pour chaque point de connexion de l'activité, les systèmes participants peuvent fournir un ID de corrélation pour les messages envoyés par d'autres systèmes. Selon le type d'activité, la réception de cet ID de corrélation peut satisfaire la partie pour laquelle la transaction est théoriquement terminée. Dans d'autres cas, lors de l'achèvement des interactions des vingt-cinq parties, un message de confirmation peut être envoyé à toutes les parties (directement à partir d'un seul service ou via les points d'interaction de l'orchestration pour chaque système).

    Pour gérer les erreurs d'activités composites et/ou distribuées, chaque service doit afficher une interface de service et une ou plusieurs opérations afin de recevoir les demandes d'annulation d'une transaction donnée par un identificateur unique. Derrière la façade du service, des flux de travail sont en place de façon à compenser l'annulation de cette activité. Idéalement ce sont des procédures automatiques, mais elles peuvent être aussi simples que le routage vers une personne de l'organisation de façon à remédier manuellement au problème.

Sauvegardes

En plus de la mise à jour au niveau de l'application pour éviter les données endommagées, il existe également une mise à jour qui est mise en place pour fournir des options si la mise à jour de l'application échoue.

Les processus de création et restauration des copies de sauvegarde de votre banque de données, intégralement ou partiellement, doivent faire partie de votre plan de résilience. Alors que les concepts de sauvegarde et de restauration des données ne sont pas nouveaux, il existe de nouvelles tournures dans le cloud.

Votre stratégie de sauvegarde doit être définie avec une présentation consciente des besoins pour restaurer les données. Si une banque de données est endommagée ou mise hors connexion en raison d'un scénario d'urgence, vous devez connaître le type de données qui doit être restauré, le volume qui doit être restauré et le rythme requis pour l'entreprise. Cela aura un impact sur votre plan de disponibilité global et doit justifier votre planification de la sauvegarde et de la restauration.

  • Bases de données relationnelles

    La sauvegarde des bases de données relationnelles n'est pas une nouveauté. De nombreuses organisations disposent d'outils, d'approches et de processus pour la sauvegarde des données de façon à répondre aux besoins de récupération d'urgence ou de conformité. Dans de nombreux cas, les outils, les méthodes et les processus de sauvegarde traditionnels fonctionnent sans modification ou avec des modifications minimes. De plus, il existe de nouvelles alternatives ou variantes, telles que la sauvegarde des données et le stockage d'une copie dans le stockage d'objets blob informatique, qui peuvent être prises en compte.

    Lorsque vous évaluez les processus et les outils existants, il est important d'évaluer l'approche appropriée pour la solution informatique. Dans de nombreux cas, une ou plusieurs des approches répertoriées ci-dessous seront appliquées pour corriger les différents modes d'échec.

    1. Sauvegarde totale : il s'agit d'une sauvegarde d'une banque de données dans son intégralité. Les sauvegardes totales doivent se produire en fonction d'une planification dictée par le volume et la vitesse des données. Une sauvegarde totale est le jeu de données complet nécessaire pour respecter le contrat de niveau de service pour le service. Les mécanismes de ce type de sauvegarde sont généralement disponibles auprès du fournisseur de base de données/service de base de données ou de son écosystème de fournisseurs.

    2. Limite dans le temps : la limite de sauvegarde dans le temps est une sauvegarde qui reflète un moment donné dans l'existence des bases de données. Si une erreur se produit dans l'après-midi et endommage la banque de données, par exemple, une limite de sauvegarde dans le temps effectuée à midi peut être restaurée pour réduire l'impact sur l'entreprise.

      Étant donné le niveau toujours croissant de connexions des utilisateurs, la perspective d'utiliser votre service à toute heure du jour rend la possibilité de restauration rapide à un point récent nécessaire.

    3. Synchronisation : outre les sauvegardes traditionnelles, une autre option consiste à synchroniser les données. Les données peuvent être stockées dans plusieurs centres de données, par exemple, avec une synchronisation périodique des données d'un centre de données vers un autre. Outre la mise à disposition de données synchronisées dans des solutions qui utilisent la gestion du trafic dans le cadre d'un plan de disponibilité normal, elle peut également être utilisée pour basculer sur un deuxième centre de données en cas de problème de continuité des activités.

      Étant donné la connectivité constante des utilisateurs des services, le temps mort devient de moins en moins acceptable pour plusieurs scénarios et la synchronisation peut être une approche souhaitable.

      Les modèles de synchronisation peuvent inclure les éléments suivants :

      - centre de données à centre de données d'un fournisseur de cloud donné

      - centre de données à centre de données de plusieurs fournisseurs de cloud

      - centre de données à centre de données sur site d'un fournisseur de cloud donné

      - centre de données à synchronisation de périphérique pour les segments de données spécifiques à l'utilisateur

  • Bases de données relationnelles éclatées

    Pour la plupart, le passage au cloud est motivé par un besoin de simplifier les scénarios de trafic élevé avec un grand nombre d'utilisateurs tels que ceux liés aux applications mobiles ou sociales. Dans ces scénarios, le modèle d'application implique fréquemment le déplacement d'un modèle de base de données vers plusieurs partitions de base de données qui contiennent une partie du jeu de données total et sont optimisées pour l'engagement à grande échelle. Un projet récent de réseau social reposant sur Azure a été lancé avec un total de 400 partitions de base de données.

    Chaque partition est une base de données autonome et votre architecture et gestion doivent faciliter les sauvegardes totales, les sauvegardes dans le temps et la restauration des sauvegardes pour les deux partitions et un jeu de données complet comprenant toutes les partitions.

  • Banques de données NoSQL

    Outre les banques de données relationnelles, les stratégies de sauvegarde doivent également être prises en compte pour les banques de données « Not only SQL » ou NoSQL. Le type le plus utilisé de bases de données NoSQL fourni par les principaux fournisseurs de cloud est une forme de magasin haute disponibilité de paires clé-valeur, souvent appelé magasin de tables.

    Les magasins NoSQL peuvent être hautement disponibles. Dans certains cas, ils sont également redondants dans plusieurs points géographiques , ce qui permet d'empêcher la perte dans le cas d'une défaillance irrémédiable dans un centre de données spécifique. Ces magasins ne fournissent généralement pas de protections contre le remplacement ou la suppression involontaire des applications. Les erreurs d'application ou de l'utilisateur ne sont pas gérées automatiquement par les services de la plateforme, tels que le stockage d'objets blob et une stratégie de sauvegarde doit être évaluée.

    Alors que les bases de données relationnelles possèdent généralement des outils existants et bien établis pour effectuer des sauvegardes, ce n'est pas le cas pour de nombreux magasins NoSQL. Une approche architecturale courante consiste à créer une copie dupliquée des données dans une banque NoSQL de réplicas et utiliser une table de recherche d'un certain type pour identifier les lignes de la banque source qui ont été placées dans la banque de réplicas. Pour restaurer les données, la même table doit être utilisée, en lisant dans la table pour identifier le contenu de la banque de réplicas disponible à restaurer.

    Selon les problèmes de continuité des activités, le positionnement de ce réplica peut être hébergé par le même fournisseur de cloud, dans le même centre de données et/ou la même banque de données NoSQL. Il peut également se trouver dans un autre centre de données, un autre fournisseur de cloud et/ou une variante différente de la banque de données NoSQL. Le moteur pour le positionnement est largement influencé par le contrat de niveau de service souhaité pour votre service de charge de travail et les considérations concernant les conditions réglementaires.

    Ce facteur doit être pris en considération lors de la détermination des coûts, et plus particulièrement, car il est lié à l'entrée et la sortie des données. Les fournisseurs de cloud peuvent proposer la libre circulation des données dans leur(s) centre(s) de données et permettre le libre passage des données dans leur environnement. Aucun fournisseur de cloud ne propose la libre sortie des données, et les coûts de transfert des données vers un fournisseur de données secondaire du cloud peuvent être significatifs à grande échelle.

    noteRemarque
    La table de recherche est un point d'échec potentiel et un réplica de celle-ci doit être pris en compte dans le cadre de la planification de la résilience.

  • Stockage d'objets blob

    Comme les banques de données relationnelles et les banques NoSQL, une idée faussement véhiculée est que les fonctionnalités de disponibilité implémentées pour une offre de stockage d'objets blob suppriment la nécessité d'envisager d'implémenter une stratégie de sauvegarde.

    Le stockage d'objets blob peut également être redondant à plusieurs points géographiques, comme indiqué plus haut, mais cela ne protège pas contre les erreurs d'application. Les erreurs d'application ou de l'utilisateur ne sont pas gérées automatiquement par les services de la plateforme, tels que le stockage d'objets blob et une stratégie de sauvegarde doit être évaluée.

    Les stratégies de sauvegarde peuvent être très semblables à celles utilisées pour les banques NoSQL. En raison de la très grande taille possible des objets blob, le coût et le temps nécessaires pour déplacer les données seront des éléments essentiels d'une stratégie de sauvegarde et de restauration.

  • Restauration des sauvegardes

    À ce jour, la plupart des personnes ont entendu la mise en garde de l'organisation qui a créé et suivi des stratégies de sauvegarde, mais jamais testé la restauration des données. Ce jour fatidique lorsqu'un incident s'est produit, elle a restauré la sauvegarde de base de données uniquement pour découvrir qu'elle avait configuré sa sauvegarde de manière incorrecte et les bandes qu'elle avait envoyé hors site pendant des années ne contenaient pas les informations dont elle avait besoin.

    Quels que soient les processus de sauvegarde en place, il est important d'effectuer des tests pour vérifier que les données peuvent être restaurées correctement et que la restauration se produit en temps voulu et avec un impact minimal sur les activités.

Les réseaux de diffusion de contenu (CDN) sont une méthode courante pour assurer la disponibilité et améliorer l'expérience utilisateur liée aux fichiers fréquemment demandés. Le contenu d'un CDN est copié sur un nœud local lors de sa première utilisation, puis servi à partir de ce nœud local pour les demandes suivantes. Le contenu expire à l'issue d'une période indiquée, après quoi il doit être recopié sur le nœud local lors de la requête suivante.

L'utilisation d'un CDN offre un certain nombre d'avantages, mais elle ajoute également une dépendance. Comme c'est le cas avec toute dépendance, la mise à jour d'un échec de service doit être vérifiée de façon proactive.

Utilisation appropriée d'un réseau de diffusion de contenu

Une idée fausse couramment véhiculée est que les CDN constituent une solution à grande échelle. Dans un scénario, un utilisateur était sûr qu'il s'agissait de la solution appropriée pour un site de vente de livres électroniques en ligne. Ce n'était pas le cas. Pourquoi ? Dans un catalogue contenant un million de livres, il existe un petit sous-ensemble de livres fréquemment demandés (les plus demandés) et une très longue file de livres qui sont demandés avec très peu de prévisibilité. Les titres fréquemment demandés sont copiés dans le nœud local lors de la première requête et fournissent une échelle locale rentable et une expérience utilisateur agréable. Pour une longue file, presque chaque demande est copiée deux fois, une fois sur le nœud local, puis pour le client, car les requêtes peu fréquentes génèrent du contenu qui arrive régulièrement à expiration. Il s'agit de la preuve qu'un CDN incorrect aura l'inverse de l'effet escompté : une solution plus lente et plus coûteuse.

Dans de nombreux cas, les opérations d'une solution ne peuvent pas être organisées indéfiniment dans le cycle de vie. Pour créer des applications réellement résilientes, elles doivent être conçues pour les opérations. La conception des opérations inclut en général des activités clés telles que la création d'un modèle d'intégrité, la capture des informations de télémesure, l'incorporation des services de contrôle d'intégrité et des flux de travail et rendre ces données utilisables par les opérations et les développeurs.

Les équipes de développement négligent souvent et parfois ignorent complètement l'« intégrité » des applications. Par conséquent, les services passent généralement en production avec deux états connus : démarré ou arrêté. Les concepteurs de services résilients doivent développer des modèles d'intégrité qui définissent les critères d'intégrité des applications, l'état d'intégrité diminué, l'échec et les dépendances d'intégrité.

Le développement proactif d'un modèle d'intégrité souligne les modes et les points d'échec, ce qui demande aux développeurs d'identifier et d'étudier des scénarios dans les phases de conception d'application. Pour configurer un modèle d'intégrité, un service doit pouvoir communiquer son intégrité. Il doit posséder un moyen de programmation pour distribuer ces informations, fournir une interface pour interroger cet état d'intégrité de façon proactive, fournir les mécanismes (ou repères dans les mécanismes existants) au moyen desquels les administrateurs peuvent surveiller l'intégrité des applications en temps réel et créer des mécanismes au moyen desquels les administrateurs peuvent au besoin fournir des mesures correctives pour restaurer l'état sain de l'application.

Définir les caractéristiques

Pour un service ou une application donnée, le diagnostic doit être effectué pour identifier les points de données et les plages de valeurs qui indiquent au moins trois catégories d'état d'intégrité (sain, intégrité diminuée et non sain). Ces informations peuvent être utilisées pour automatiser l'auto-adaptation des services.

Définir les interfaces

Les états d'intégrité étant définis, un service peut exposer les interfaces relatives à l'intégrité. Ces interfaces fourniront les catégories suivantes d'opérations.

  • Émettre l'état d'intégrité dans les services partenaires abonnés

    Un service doit émettre les informations d'intégrité dans les services partenaires abonnés. Cet état doit être concis, avec une intégrité de niveau supérieur et des diagnostics de base.

    Le service doit fournir la possibilité pour un service partenaire de s'abonner aux messages d'intégrité. La remise des messages d'intégrité peut se produire dans les chemins d'accès appropriés pour la solution. Un chemin d'accès peut avoir des mises à jour d'état d'intégrité de place de service dans une file d'attente qui peut être récupérée par les abonnés.

    Une autre méthode consiste à autoriser les abonnés à fournir un point de terminaison auquel une interface de rapports d'intégrité connue est exposée. Lorsque les informations d'intégrité sont modifiées, elle peut émettre les informations sur les abonnés à leurs points de terminaison fournis.

  • Interfaces d'exposition pour remettre des données de télémesure

    La télémesure est importante pour les opérations, car elle permet d'identifier l'intégrité active de l'application et/ou des services à plusieurs niveaux. Elle permet également d'identifier le moment où un événement atypique se produit dans l'environnement. Cela fournit une vue granulaire du service et est exposé au personnel des opérations, aux services et aux tableaux de bord du fournisseur de services.

    Pour les opérations, les mesures de télémesure peuvent inclure, par exemple, le pourcentage moyen d'utilisation de l'UC, les erreurs, les connexions et les files d'attente de différents rôles, services et services basés sur des applications composites.

    La télémesurespécifique à l'application n'est en général pas activée automatiquement ni analysée directement par la plateforme ; par conséquent, la télémesure doit être activée par le service et l'application.

  • Interfaces d'exposition pour rechercher dans le service des informations de diagnostic d'intégrité supplémentaires

    Un service doit idéalement fournir des interfaces permettant de rechercher des informations de diagnostic d'intégrité supplémentaires. Les services abonnés, en fonction des informations de premier niveau reçues dans l'état d'intégrité, peuvent demander des informations supplémentaires pour déterminer la marche à suivre avec leur relation avec le service qui met à disposition ses informations d'intégrité.

    Spécifiquement, si le service est dans un faible état d'intégrité, des informations supplémentaires peuvent permettre à un service consommateur de prendre une décision de façon à continuer d'utiliser le service ou à basculer vers un autre fournisseur.

  • Interfaces d'exposition pour mettre à jour l'intégrité du service au niveau du service et de l'application

    Si le consommateur des informations d'intégrité est un service interne ou associé, activez le service de façon à ce qu'il corrige automatiquement les problèmes connus. Tout comme avec les mesures humaines, la compréhension de l'intégrité du service va évoluer dans le temps et les données d'intégrité peuvent entraîner différentes méthodes de traitement.

    Un service doit présenter une interface pour permettre la remise de ce traitement. Dans sa forme la plus simple, cela peut aller du déclenchement d'un redémarrage ou de la recréation d'images d'un service au basculement vers un autre fournisseur de données ou de services interne.

    La compréhension de l'intégrité d'un service peut permettre au fournisseur de services de déterminer rapidement si un service n'est pas sain. Les opérations automatisées peuvent contribuer à la mise à jour rapide, cohérente et normative des problèmes connus et à l'auto-adaptation du service. Cette section examine les différents aspects de l'intégrité plus en détail.

Télémétrie : « utilisation d'équipements spécifiques pour mesurer un élément (comme la pression, la vitesse ou la température) et d'envoyer les résultats ailleurs par radio ».

Il est important de collecter les données de télémétrie de votre service. La télémétrie est généralement répartie en quatre catégories : l'utilisateur, l'entreprise, l'application et l'infrastructure.

La télémétrie d'utilisateur cible le comportement d'un individu, d'un utilisateur particulier. Elle fournit des indications sur le comportement d'un utilisateur et peut faciliter la conception d'une expérience individuelle.

La télémétrie d'entreprise contient des données liées aux activités de l'entreprise et des indicateurs de performance clé pour l'entreprise. Cette catégorie de télémétrie permet, par exemple, de connaître le nombre d'utilisateurs actifs sur un site, le nombre de vidéos regardées, etc.

La télémétrie d'application contient des détails sur l'intégrité, les performances et l'activité de la couche Application et ses services dépendants. La télémétrie d'application peut contenir, par exemple, des informations sur les appels et les connexions de données clientes, les exceptions, les appels API, les sessions, etc.

La télémétrie d'infrastructure contient des informations sur l'intégrité de l'infrastructure système sous-jacente. Ces informations peuvent porter sur les ressources telles qu'une unité centrale, une mémoire, un réseau, une capacité disponible, etc.

Lorsque vous identifiez les données à collecter et les méthodes de collecte, vous devez bien comprendre à quel type de données vous avez affaire et ce que vous voulez faire avec.

Commencez par déterminer si les données collectées vous permettront d'obtenir des informations ou de mettre en place une action. Vous devez vous poser cette question : « à quelle vitesse dois-je réagir ? » Ces données seront-elles utilisées en temps réel (ou presque) pour mettre en place une action ? Ou allez-vous les utiliser pour établir des rapports d'un mois sur l'autre ? Les réponses à ces questions vont orienter l'approche de télémétrie et les technologies utilisées dans l'architecture.

Ensuite, identifiez le type de question que vous allez appliquer aux données de télémétrie collectées. Seront-elles utilisées pour répondre à des questions existantes ou à des fins d'exploration ? Par exemple, pour une entreprise, les indicateurs de performance clé répondent à des questions existantes. Cependant, un fabricant qui souhaite explorer les données de ses appareils pour établir des modèles d'erreurs s'aventure dans l'inconnu. Pour le fabricant, les erreurs proviennent d'un ou plusieurs éléments du système. Il va devoir procéder à une exploration qui exigera des données supplémentaires.

Lorsque vous utilisez la télémétrie pour obtenir des informations, vous devez tenir compte du temps que cela prendra. Dans certains cas, vous utiliserez la télémétrie pour détecter un pic dans le détecteur d'un appareil qui correspond à une durée de quelques secondes ou minutes. Dans d'autres cas, vous pouvez utiliser la télémétrie pour calculer l'augmentation hebdomadaire des utilisateurs d'un site web, ce qui s'établit sur une plus longue durée.

Enfin, vous devez prendre en compte la quantité de données que vous pouvez collecter à partir d'une source de signal dans le délai d'exécution requis pour obtenir vos informations. Vous devez connaître la quantité du signal source dont vous avez besoin. Vous pourrez ensuite déterminer la meilleure méthode de partition de ce signal, puis établir les proportions adéquates de calculs locaux et globaux.

Vous devez également réfléchir à la méthode d'enregistrement de la séquence d'événements de votre télémétrie. De nombreuses organisations utilisent par défaut des horodatages. Cependant, ces horodatages peuvent s'avérer difficiles à utiliser, car les horloges des serveurs des différents centres de données sont incohérentes. Si les heures peuvent être synchronisées périodiquement, de nombreuses études mettent en évidence une dérive des horloges des serveurs (elles diffèrent progressivement). Cette dérive entraîne des modifications pouvant fausser les analyses. Dans le cas des scénarios nécessitant une certaine précision, il vaut mieux envisager d'autres solutions, comme l'implémentation d'une horloge vectorielle.

Après avoir identifié une approche de télémétrie, vous allez passer à la caractérisation du signal.

Vous pouvez classer le signal comme continu ou discret. Les données d'événement en temps réel constituent un exemple de signal continu. Les entrées de fichier journal constituent un exemple de signal discret.

Pour répondre aux besoins de votre approche, vous devez identifier la quantité de données du signal. Si les informations sont continues, vous devez établir un taux d'échantillonnage. Si elles sont discrètes, vous devez identifier les enregistrements à conserver ou à filtrer.

Vous devez également identifier le type d'accès. Dans certains cas, vous allez transmettre les données de télémétrie. Dans d'autres cas, vous allez récupérer les données de télémétrie par extraction.

Dans les systèmes les plus évolués, les informations obtenues à partir de télémétries transmises existantes peuvent vous permettre de procéder à une extraction pour obtenir d'autres informations. Par exemple, si une télémétrie transmise indique un état qui n'est pas optimal, vous pouvez récupérer des données de diagnostic supplémentaires en procédant à une extraction.

Toutes les données collectées peuvent être pertinentes sous certaines conditions, mais vous ne devez pas toutes les transmettre tout le temps. En vous basant sur le type de télémétrie et la quantité de données requise pour obtenir des informations, vous pouvez vous concentrer sur la récupération de petites quantités de données. Vous pouvez utiliser des calculs locaux pour générer des agrégations, des échantillonnages ou des sous-ensembles, puis transmettre ces données à un service. Si les données reçues depuis une télémétrie standard indiquent un état qui n'est pas optimal, le service peut demander des données supplémentaires.

Lorsque vous développez une stratégie de télémétrie, pensez aux stratégies appropriées. La télémétrie requiert une connectivité disponible et la transmission de données a un coût. Développez des stratégies tenant compte du contexte, de la connectivité et des coûts, puis utilisez-les pour ajuster vos télémétries.

Vos stratégies doivent prendre en compte le contexte de l'état actuel pour déterminer la télémétrie adéquate. Ce contexte se compose des informations obtenues à partir des télémétries précédentes et des besoins de votre entreprise. Il vous permet d'orienter vos collectes de télémétries et de définir leurs priorités.

Vos appareils peuvent avoir différents types de connectivités (WiFi, LTE, 4G, 3G, etc.) et leur efficacité peut varier. La connectivité immédiate d'un appareil permet de déterminer les données à transmettre. Dans les scénarios où la connectivité n'est pas fiable ou la vitesse de connexion est lente, votre stratégie peut vous permettre de définir des priorités pour la transmission des télémétries.

La connectivité a souvent un coût. Les stratégies doivent tenir compte du fait qu'une connexion est limitée ou non. Si une connexion est limitée, les stratégies doivent identifier ses coûts et, le cas échéant, ses plafonds d'utilisation. De nombreux appareils utilisent différents types de connexions quotidiennement. Vous pouvez définir des priorités ou annuler certaines priorités pour certaines télémétries, en fonction du coût de leur transmission.

Les données de télémétrie sont généralement reçues et visualisées par différents publics. Les opérations et les développeurs sont deux types de publics particulièrement concernés. Cependant, comme cela est décrit ci-dessous, les besoins de chaque public requièrent différents niveaux de granularité.

La visualisation d'un état d'opération de haut niveau et de données de télémétrie de niveau inférieur est essentielle pour le personnel chargé des opérations. Il est fort probable que des notifications automatisées soient mises en place en fonction des données de télémétrie. Cependant, le personnel chargé des opérations aura besoin d'un tableau de bord pour visualiser les performances historiques et actuelles du service.

Dans le cas des applications à grande échelle, ces informations peuvent rapidement aider à déterminer si un problème se produit ou est sur le point de se produire. Elles peuvent également permettre au personnel chargé des opérations d'identifier les incidences possibles et les causes premières.

Diagramme de tableau de bord des performances

Figure 10

Le diagramme ci-dessus d'un site social de grande taille examine le pourcentage d'UC moyen utilisé par les rôles d'API, les erreurs d'API, les utilisateurs en ligne, les connexions Web actives, le pourcentage d'UC utilise par les rôles Web, les erreurs Web, les connexions Web physiques, les connexions Web regroupées, la file d'attente d'applications Web, les connexions Web logicielles.

La télémesure et le type de rapport indiqués ci-dessus sont particulièrement utiles dans les cas où les opérations corrigent les erreurs sans modifications de code dans les services eux-mêmes. Parmi les exemples d'activités que les opérations peuvent effectuer, citons le déploiement d'autres rôles et le recyclage des instances.

Vous pouvez exploiter la visualisation des données de télémesure historiques et en temps réel pour différents objectifs :

  • Résolution de problèmes

  • Bilans post-mortem pour des problèmes touchant un site en direct

  • Formation des nouveaux membres du personnel chargé des opérations

Outre le personnel chargé des opérations, les développeurs de logiciels sont un grand consommateur de données de télémesure. Les erreurs ne sont peut-être pas liées à l'environnement de production mais plutôt au code d'application sous-jacent. Posséder un tableau de bord de télémesure pour les développeurs leur permet de prendre la mesure appropriée.

Voici deux captures d'écran d'un exemple d'utilitaire créé pour un tel objectif. Le tableau de bord fournit des informations sur le nombre d'erreurs, les catégories des erreurs, ainsi que des données spécifiques associées à chacune de ces catégories. Cela inclut un examen des données, notamment le nombre total d'erreurs, le nombre total d'instances de rôle qui rencontrent des erreurs et le nombre total de bases de données comportant des erreurs.

Diagramme de tableau de bord

Figure 11

Diagramme de tableau de bord

Figure 12

Pour les sites de grande taille avec des millions d'utilisateurs, un nombre d'erreurs plus élevé se produira et peut être parfaitement acceptable. Posséder un tableau de bord centré sur le développement qui interprète les télémesures peut permettre de déterminer s'il existe réellement un problème, s'il convient de prendre des mesures et l'emplacement où se produisent les erreurs dans le code.

Voir aussi

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft