# REL10-BP04 Usar arquitecturas herméticas para limitar el alcance del impacto
Al igual que las cubiertas de un barco, este patrón garantiza que los errores estén contenidos en un pequeño subconjunto de solicitudes o usuarios para limitar el número de solicitudes con errores y que la mayoría pueda continuar sin producir error. Las cubiertas de los datos se denominan a menudo particiones y las de los servicios, celdas.
En una *arquitectura basada en celdas*, cada celda es una instancia completa e independiente del servicio y tiene un tamaño máximo fijo. Cuando aumenta la carga, aumentan también las cargas de trabajo con más celdas. En el tráfico entrante, se usa una clave de partición para determinar la celda que procesará la solicitud. Cualquier error está contenido en la celda en la que se produce, con lo que se limita el número de solicitudes con error y las demás celdas pueden continuar funcionando sin errores. Es importante identificar la clave de partición adecuada para reducir al mínimo las interacciones entre celdas y evitar tener que recurrir a servicios de asignación complejos en cada solicitud. Los servicios que requieren asignación compleja terminan trasladando el problema a los servicios de asignación, mientras que los servicios que requieren interacciones entre celdas crean dependencias entre ellas (y, por lo tanto, reducen las supuestas mejoras en la disponibilidad de hacerlo).
![\[Diagrama que muestra una arquitectura basada en celdas\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
En esta publicación de blog de AWS, Colm MacCarthaigh explica cómo utiliza Amazon Route 53 el concepto 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/) para aislar las solicitudes de los clientes en particiones. En este caso, una partición consiste en dos o más celdas. En función de la clave de partición, el tráfico procedente de un cliente (o de recursos, o de lo que quiera aislar) se enruta a su partición asignada. En el caso de ocho celdas con dos celdas por partición, y si los clientes están divididos entre las cuatro particiones, el 25 % de los clientes experimentaría un impacto en caso de que hubiese un problema.
![\[Diagrama que muestra un servicio dividido en particiones tradicionales\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Con la partición aleatoria, crea particiones virtuales de dos celdas cada una y asigna a sus clientes a una de esas particiones virtuales. Cuando ocurre un problema, puede seguir perdiendo una cuarta parte de ese servicio, pero la forma en que se asignan los clientes o los recursos supone que el ámbito del impacto con la partición aleatoria es considerablemente menor al 25 %. Con ocho celdas, hay 28 combinaciones únicas de dos celdas, lo que significa que hay 28 particiones aleatorias posibles (particiones virtuales). Si tiene cientos o miles de clientes y asigna cada cliente a una partición aleatoria, el ámbito del impacto debido a un problema es solamente de 1/28. Esto es siete veces mejor que la partición ordinaria.
![\[Diagrama que muestra un servicio dividido en particiones aleatorias.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Una partición se puede usar para servidores, colas u otros recursos además de las celdas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Use arquitecturas herméticas. Al igual que las cubiertas de un barco, este patrón garantiza que los errores estén contenidos en un pequeño subconjunto de solicitudes o usuarios para limitar el número de solicitudes con errores y que la mayoría pueda continuar sin producir error. Las cubiertas de los datos se denominan a menudo particiones y las de los servicios, celdas.
+ [Laboratorio de Well-Architected: aislamiento de errores con particionamiento aleatorio](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Particionamiento aleatorio: AWS re:Invent 2019: Presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: cómo minimiza AWS el radio de alcance de los errores (ARC338)](https://youtu.be/swQbA4zub20)
+ Evalúe la arquitectura basada en celdas de la carga de trabajo. En una arquitectura basada en celdas, cada celda es una instancia completa e independiente del servicio y tiene un tamaño máximo fijo. Cuando aumenta la carga, aumentan también las cargas de trabajo con más celdas. En el tráfico entrante, se usa una clave de partición para determinar la celda que procesará la solicitud. Cualquier error está contenido en la celda en la que se produce, con lo que se limita el número de solicitudes con error y las demás celdas pueden continuar funcionando sin errores. Es importante identificar la clave de partición adecuada para reducir al mínimo las interacciones entre celdas y evitar tener que recurrir a servicios de asignación complejos en cada solicitud. Los servicios que requieren asignación compleja terminan trasladando el problema a los servicios de asignación, mientras que los servicios que requieren interacciones entre celdas reducen la autonomía de estas celdas (y, por lo tanto, las supuestas mejoras en la disponibilidad de hacerlo).
+ En su entrada de blog de AWS, Colm MacCarthaigh explica cómo usa Amazon Route 53 el concepto de particionamiento aleatorio para aislar las solicitudes de los clientes en particiones.
+ [Particionamiento aleatorio: aislamiento de errores masivo y mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Recursos
**Documentos relacionados:**
+ [Particionamiento aleatorio: aislamiento de errores masivo y mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [La Amazon Builders' Library: Aislamiento de cargas de trabajo con particionamiento aleatorio](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: cómo minimiza AWS el radio de alcance de los errores (ARC338)](https://youtu.be/swQbA4zub20)
+ [Particionamiento aleatorio: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: aislamiento de errores con particionamiento aleatorio](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)