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

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

À l'instar des cloisons d'un navire, ce modèle garantit qu'une panne reste limitée à un petit sous-ensemble de requêtes ou de clients afin que le nombre de requêtes compromises soit limité et que la plupart puissent continuer sans erreur. Les cloisons des données sont souvent appelées partitions, tandis que les cloisons des services sont appelées cellules.

Dans une architecture cellulaire,chaque cellule est une instance complète et indépendante du service et a une taille maximale fixe. Les charges de travail augmentent en même temps que la charge par l'ajout de cellules. Une clé de partition est utilisée sur le trafic entrant pour déterminer la cellule qui traitera la requête. Toute défaillance est contenue dans la seule cellule dans laquelle elle se produit, de sorte que le nombre de requêtes compromises soit limité et que les autres puissent continuer sans erreur. Il est important de choisir la bonne clé de partition afin de minimiser les interactions entre cellules et d'éviter d'avoir à utiliser des services de mappage complexes pour chaque requête. Les services qui nécessitent un mappage complexe ne font finalement que déplacer le problème vers les services de mappage, tandis que les services qui nécessitent des interactions entre cellules créent des dépendances entre les cellules (et, par conséquent, réduisent les améliorations de disponibilité présumées qui en découlent).

Diagramme illustrant une architecture cellulaire

Figure 11 : Architecture cellulaire

Dans son billet de blog AWS, Colm MacCarthaigh explique comment Amazon Route 53 utilise le concept de partitionnement aléatoire pour isoler les demandes des clients en partitions. Dans ce cas, une partition se compose d’au moins deux cellules. En fonction de la clé de partition, le trafic d'un client (ou des ressources, ou tout ce que vous souhaitez isoler) est acheminé vers la partition qui lui est attribuée. Par exemple, avec huit cellules et deux cellules par partition et des clients répartis entre les quatre partitions, 25 % des clients subiraient un impact en cas de problème.

Diagramme illustrant un service divisé en partitions traditionnelles

Figure 12 : Service divisé en quatre partitions standard de deux cellules chacune

Avec le partitionnement aléatoire, vous créez des partitions virtuelles de deux cellules chacune et attribuez vos clients à l'une de ces partitions virtuelles. Lorsqu'un problème se produit, vous pouvez toujours perdre un quart de l'ensemble du service, mais la façon dont les clients ou les ressources sont attribués signifie que la portée de l'impact du partitionnement aléatoire est considérablement inférieure à 25 %. Avec huit cellules, il existe 28 combinaisons uniques de deux cellules, soit 28 partitions aléatoires possibles (partitions virtuelles). Si vous avez des centaines ou des milliers de clients et que vous assignez chaque client à une partition aléatoire, l'impact lié à un problème est seulement de 1/28e. C'est sept fois mieux que le partitionnement standard.

Diagramme illustrant un service divisé en partitions aléatoires.

Figure 13 : Service divisé en 28 partitions aléatoires (partagées virtuellement) de deux cellules chacune (seules deux partitions aléatoires sur les 28 possibles sont affichées)

Une partition peut être utilisée pour les serveurs, les files d'attente ou d'autres ressources en plus des cellules.

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

Directives d'implémentation

  • Utilisez des architectures cloisonnées. À l'instar des cloisons d'un navire, ce modèle garantit qu'une panne reste limitée à un petit sous-ensemble de requêtes ou d'utilisateurs afin que le nombre de requêtes compromises soit limité et que la plupart puissent continuer sans erreur. Les cloisons des données sont souvent appelées partitions, tandis que les cloisons des services sont appelées cellules.

  • Évaluez l'architecture basée sur les cellules pour votre charge de travail. Dans une architecture basée sur les cellules, chaque cellule est une instance complète et indépendante du service et a une taille maximale fixe. Les charges de travail augmentent en même temps que la charge par l'ajout de cellules. Une clé de partition est utilisée sur le trafic entrant pour déterminer la cellule qui traitera la requête. Toute défaillance est contenue dans la seule cellule dans laquelle elle se produit, de sorte que le nombre de requêtes compromises soit limité et que les autres puissent continuer sans erreur. Il est important de choisir la bonne clé de partition afin de minimiser les interactions entre cellules et d'éviter d'avoir à utiliser des services de mappage complexes pour chaque requête. Les services qui nécessitent un mappage complexe ne font finalement que déplacer le problème vers les services de mappage, tandis que les services qui nécessitent des interactions entre cellules réduisent l'autonomie des cellules (et, par conséquent, les améliorations de disponibilité présumées qui en découlent).

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :