REL10-BP04 Utiliser des architectures cloisonnées pour limiter la portée de l'impact - AWS Well-Architected Framework

REL10-BP04 Utiliser des architectures cloisonnées pour limiter la portée de l'impact

Mettez en œuvre des architectures de cloisonnement (également connues sous le nom d'architectures cellulaires) pour restreindre l'effet d'une panne au sein d'une charge de travail à un nombre limité de composants.

Résultat souhaité : une architecture cellulaire utilise plusieurs instances isolées d'une charge de travail, où chaque instance est appelée cellule. Chaque cellule est indépendante, ne partage pas d'état avec les autres cellules et traite un sous-ensemble des demandes de la charge de travail globale. Cela réduit l'impact potentiel d'une panne, telle qu'une mauvaise mise à jour logicielle, sur une cellule individuelle et les demandes qu'elle traite. Si une charge de travail utilise 10 cellules pour traiter 100 demandes, lorsqu'une panne survient, 90 % des demandes globales ne sont pas affectées par la panne.

Anti-modèles courants :

  • Permettre aux cellules de se développer sans limites.

  • Appliquer des mises à jour ou des déploiements de code à toutes les cellules en même temps.

  • Partage de l'état ou des composants entre les cellules (à l'exception de la couche routeur).

  • Ajout d'une logique métier ou de routage complexe à la couche routeur.

  • Ne pas minimiser les interactions entre les cellules.

Avantages liés au respect de cette bonne pratique : avec les architectures cellulaires, de nombreux types de pannes courants sont contenus dans la cellule elle-même, ce qui permet un isolement supplémentaire des pannes. Ces limites de défaillance peuvent fournir une résilience contre des types de panne qui seraient autrement difficiles à contenir, tels que des déploiements de code infructueux ou des requêtes corrompues ou déclenchant un mode de défaillance spécifique (également connues sous le nom de requêtes empoisonnées).

Directives d'implémentation

Sur un navire, les cloisons permettent de contenir une brèche dans la coque dans une seule section de la coque. Dans les systèmes complexes, ce modèle est souvent répliqué pour permettre d'isoler des pannes. Les limites isolées pour les défaillances restreignent l'effet d'une panne au sein d'une charge de travail à un nombre limité de composants. Les composants en dehors de la limite ne sont pas affectés par la défaillance. En utilisant plusieurs limites isolées par défaut, vous pouvez limiter l'impact sur votre charge de travail. Sur AWS, les clients peuvent utiliser plusieurs zones de disponibilité et régions pour isoler des pannes, mais le concept d'isolement des pannes peut également être étendu à l'architecture de votre charge de travail.

La charge de travail globale est divisée en cellules par une clé de partition. Cette clé doit s'aligner sur la base de granularité du service, ou sur la manière naturelle dont la charge de travail d'un service peut être subdivisée avec un minimum d'interactions entre les cellules. Des exemples de clés de partition sont l'ID du client, l'ID de la ressource ou tout autre paramètre facilement accessible dans la plupart des appels d'API. Une couche de routage des cellules distribue les requêtes aux cellules individuelles en fonction de la clé de partition et présente un point de terminaison unique aux clients.

Diagramme illustrant une architecture cellulaire

Figure 11 : Architecture cellulaire

Étapes d'implémentation

Lors de la conception d'une architecture cellulaire, vous devez tenir compte de plusieurs éléments :

  1. Clé de partition : il convient d'accorder une attention particulière au choix de la clé de partition.

    • Celle-ci doit s'aligner sur la base de granularité du service, ou sur la manière naturelle dont la charge de travail d'un service peut être subdivisée avec un minimum d'interactions entre les cellules. Voici quelques exemples : ID du client ou ID de la ressource. »

    • La clé de partition doit être disponible dans toutes les requêtes, soit directement, soit d'une manière qui pourrait être facilement déduite de façon déterministe par d'autres paramètres.

  2. Mappage persistant des cellules : les services en amont ne doivent interagir qu'avec une seule cellule pendant le cycle de vie de leurs ressources.

    • En fonction de la charge de travail, vous devrez peut-être concevoir une stratégie de migration de cellules pour faire migrer les données d'une cellule à l'autre. La migration d'une cellule peut s'avérer nécessaire si un utilisateur ou une ressource particulière de votre charge de travail devient trop importante et nécessite une cellule dédiée.

    • Les cellules ne doivent pas partager d'état ou de composants entre elles.

    • Par conséquent, les interactions entre cellules doivent être évitées ou réduites au minimum, car elles créent des dépendances entre les cellules et diminuent donc les bénéfices de l'isolement des défaillances.

  3. Couche routeur : la couche routeur est un composant partagé entre les cellules, et ne peut donc pas suivre la stratégie de compartimentage des cellules.

    • Nous recommandons de paramétrer la couche routeur pour distribuer les requêtes à des cellules individuelles à l'aide d'un algorithme de mappage de partition d'une manière efficace sur le plan des calculs. Par exemple, en combinant des fonctions de hachage cryptographiques et de l'arithmétique modulaire pour mapper les clés de partition aux cellules.

    • Pour éviter les impacts sur plusieurs cellules, la couche de routage doit rester aussi simple et évolutive horizontalement que possible, ce qui nécessite d'éviter toute logique métier complexe au sein de cette couche. Cela présente l'avantage supplémentaire de faciliter la compréhension de son comportement attendu à tout moment, favorisant ainsi une testabilité approfondie. Comme l'explique Colm MacCárthaigh dans son article Reliability, constant work, and a good cup of coffee (Fiabilité, travail constant, et une bonne tasse de café), les conceptions simples et les modèles de travail constants produisent des systèmes fiables et réduisent le phénomène d'antifragilité.

  4. Taille des cellules : les cellules doivent comporter une taille maximale définie et ne doivent pas être autorisées à se développer au-delà.

    • La taille maximale doit être identifiée en effectuant des tests approfondis, jusqu'à ce que les points de rupture soient atteints et que des marges de fonctionnement sûres soient établies. Pour obtenir plus de détails sur la mise en œuvre des pratiques de test, consultez REL07-BP04 Effectuer un test de charge de votre charge de travail

    • La charge de travail globale doit se développer en ajoutant des cellules supplémentaires, ce qui lui permet de s'adapter à l'augmentation de la demande.

  5. Stratégies multi-AZ ou multirégion : il convient de tirer parti de plusieurs couches de résilience pour se protéger contre différents domaines de panne.

    • Pour la résilience, vous devez adopter une approche qui repose sur des couches de défense. Une couche protège contre les perturbations de petite envergure et courantes en créant une architecture hautement disponible à l'aide de plusieurs AZ. Une autre couche de défense est destinée à protéger contre les événements rares tels que les catastrophes naturelles généralisées et les perturbations au niveau régional. Cette deuxième couche implique de concevoir l'architecture de votre application pour qu'elle s'étende sur plusieurs Régions AWS. La mise en œuvre d'une stratégie multirégion pour votre charge de travail permet de la protéger contre les catastrophes naturelles généralisées qui affectent une grande région géographique d'un pays, ou les défaillances techniques à l'échelle régionale. Sachez que la mise en œuvre d'une architecture multirégion peut être très complexe et n'est généralement pas requise pour la plupart des charges de travail. Pour en savoir plus, consultez REL10-BP02 Sélectionner les emplacements appropriés pour votre déploiement multisite. »

  6. Déploiement du code : il faut privilégier une stratégie de déploiement de code échelonnée plutôt que de déployer les modifications de code dans toutes les cellules en même temps.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : élevé

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Exemples connexes :