# 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\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Dans son billet de blog AWS, Colm MacCarthaigh explique comment Amazon Route 53 utilise le concept de [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) 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\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
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.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
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.
+ [Atelier Well-Architected : Isolement des pannes avec le partitionnement aléatoire](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ É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).
+ 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 dans des partitions
+ [Partitionnement aléatoire : Isolement massif et magique des pannes](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Ressources
**Documents connexes :**
+ [Partitionnement aléatoire : Isolement massif et magique des pannes](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [L'Amazon Builders' Library : isolement de la charge de travail à l'aide du partitionnement aléatoire](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vidéos connexes :**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Exemples connexes :**
+ [Atelier Well-Architected : Isolement des pannes avec le partitionnement aléatoire](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)